chap-continuous-output.md

定期的にアウトプットしよう

挫折しないための一つの方法が、定期的なアウトプットです。

進捗をブログに書く、LT会や勉強会で報告する、あるいは実装の過程を本（技術同人誌にする）などがよいでしょう。なかでも技術同人誌にすることはとってもおすすめです。

製作過程をアウトプットすることのメリット

製作過程をアウトプットすることにはメリットしかありません。

強いてデメリットをあげるとすると、アウトプットの労力がかかること？それでも、アウトプットにかかる労力のために製作の進捗が阻害されるということはありません。アウトプットすること自体がふりかえりになり、方向性の確認やったことの整理・体系化に寄与します。

また、アウトプットすることでその結果を見てくれる人がいることがわかり、モチベーションにつながります。アウトプットの形態は次節で触れますが、ブログであればアクセスログやコメント、LTなどでは実況や質問という形で、技術同人誌であれば頒布の時のやり取りや本自体の売り上げとして、見てくれている人を感じることができるでしょう。

アウトプットするメリットは、自分に対するメリット、他の人に対するメリット、コミュニティ・界隈へのメリットがあります。それぞれ簡単に整理しましょう。

自分へのメリット

まずは自分へのメリットです。

• ふりかえりになる
• 知識の体系化
• アウトプットの実績がたまる
• フィードバックをもらえるかも

ふりかえりになる

アウトプットすることで、ここまでにやった内容を俯瞰し、整理することができます。そして次に何をするのがよいのかなどを整理して製作を進めることができます。

一人で何かを作ろうとした場合、迷走することも少なくありません。間違った方向、あるいは遠回りをしていることに気づくことができるかもしれません。もちろんその遠回りが無駄だというつもりはありません。それ自体は得難い経験となるでしょう。ただ、つどふりかえりを行うことで、「次は」もっとうまくやれるかもしれません。また今回無駄になったことも、別のところで生きてくるかもしれません。

ふりかえりの手法については深入りしませんが、興味があればふりかえりの手法について本¹を読んでみるのもいいかもしれません。

知識の体系化

内容を整理してアウトプットすることで、知っていることと知らないことが可視化されます。足りない部分は後から補えばよく、知っていることは「知っていること」というラベルがついてあなたのスキルの引き出しに見えやすい形でしまわれます。しまいっぱなしではなく、必要な時にはすぐに取り出せるということ。

知っていることと知らないこと、得意と不得意を明確に整理できていることはスキルとして非常に強いですよね。

また、苦手な部分を少しづつ習得したり、逆にそれを回避する方法を考えるなどもできるでしょう。

一つのトピックスについて知識が深まってくると、その隣接領域に関しても自然と知識は深まります。

アウトプットの実績がたまる

ブログでも登壇でも執筆でも、やったらやっただけあなたの実績になります。ぜひカジュアルにアウトプットしましょう。のちにブログのアウトプットの仕方の項でも述べていますが、とりあえず書いてみて、あとでそれを再度整理するといった形で二段構えでアウトプットしてみるのも一つの案です。とりあえず書いてみる部分は、やったことを日記のように書きます。結論やオチはなくても構いません。その「やったこと」記事を編集・整理して、「やってみた」という形で体系化する、あるいは他のアウトプット媒体でアウトプットする、といった方法も手軽に質の高いアウトプットができる方法です。

ブログだって一定数書いていれば、そのブログ主として認知されるでしょう。いわんや著書や登壇もです。それらはあなたの「実績」としてスキルを雄弁に語ります。

アウトプットは質×量だといわれることがあります。ただし、個人の考え方としては、まずは量からやる方がよいと考えます。気軽に、カジュアルにアウトプットしていると、アウトプットに慣れ、どんどん洗練されます。文章が読みやすくなる、同じ量のアウトプットにかかる時間が短くなる、読者がついてフィードバックがもらいやすくなる、など。

最初から質を追求しすぎて手が止まるより、まずはアウトプットしてみましょう。

最近、「やってみた」的な根拠のない「技術記事」が検索結果を汚染しているという指摘もありました。そういう側面も否定はできませんが、裾野が広くないと、技術の頂は高くなりません。またそういう記事に助けられる人もいるでしょう。ですので、あまり気にしなくてかまいません。

フィードバックをもらえるかも

アウトプットすることで、フィードバックをもらえるかもしれません。フィードバックには様々なレベルがあることは事実です。いいねやRTが付くだけという場合もありますが、それだって言い値と思ってくれた人がいるということ。立派なフィードバックです。

あるいはコメントや質問がつくこともあります。何らかの登壇やブログなどをしたことのある方は体感しているでしょうが、質問やコメントが来ること自体、うれしいことですよね？

ポジティブなコメントは取り入れ、改善アドバイスなども参考にすればよいでしょう。なお、万一ネガティブなフィードバックが来たら、その時は無視してOKです。何かをやっている人はそれだけで正義です。外野の野次を気にする必要はありません。ミュートでもブロックでも何でもしちゃいましょう。マサカリ²も基本無視でかまいません。

そのフィードバックを経て、新しい繋がり（友人関係やコミュニティ）ができることもあります。

アウトプットのしかた

アウトプットの形として、次の4つを挙げておきましょう。

1. Twitter
2. ブログを書く
3. LT会で話す
4. 技術同人誌にする
5. 全部やる

それぞれ手軽さや届く範囲に差はありますが、いずれも素晴らしい方法、アウトプット先です。なんなら、5番目の全部やる、という方法もあります。そして、一番おすすめなのが5番目の「全部やる」です。

Twitterに流す

最もお手軽なアウトプット先はTwitterです。画像や動画も載せられます。140文字という制限があります。あるからこそ、深く考えなくとも短時間でアウトプットすることができます。ほんの一言でも構いません。やったことを流してみましょう。

また、作っていることをTweetすることで、その界隈の人とダイレクトにつながることができるでしょう。興味を持った人がフォローしてくれます。その人も何かを作っている人ならば、フォロバすることで徐々に界隈のつながりが増えてきます。いいねが付いたり、アドバイス的なコメントがつくこともあるでしょう。RTにより界隈にあなたの存在が徐々に浸透してきます。

また、定期的にTweetしておくことで、次の項のブログの素材となります。困ったことや解決のために探したこと、見つけたことなどをメモ代わりにTweetしていくことで、時系列を含めて記録することができます。

気軽さと、繋がりをカジュアルに作るという意味では最高の選択肢です。

ブログを書く

やったこと、調べたこと、困ったことは、ぜひブログに書きためておきましょう。

特につまづいたこと、困ったことは丁寧に記録しておくとよいでしょう。あなたがつまづいたことは他の人も同じようにつまづく可能性が高い内容です。環境依存などで全員が経験するわけではないでしょうが、困ってあなたのブログなどにたどり着く人もいるでしょう。ぐぐらびりてぃとかはいったん脇に置いておいて、とにかくやったことを書いていきましょう。

理由はいくつかあります。初心者だから困ったことというものは、中級者・上級者になってしまうと遭遇しなくなります。そういう問題が生じる可能性があるということ自体を忘れてしまいます。あるいは、無意識的に回避できるようになります。

たとえば、回路図を書くとき、初心者であればLEDの電流制限抵抗を入れ忘れることがあるかもしれません。あるいは都度意識して入れているかもしれません。中級者・上級者になれば、電源仕様を瞬時に判断してここは不要だなとしたり、無意識的に（あるいはおまじない？）として抵抗記号を入れるかもしれません。誰かに「この抵抗って何ですか？どうしてこの値なんですか？」と明示的に聞かれたらさらさらと説明はできるかもしれませんが、ブログに書くときにそこまで丁寧な説明はできないでしょう。あるいは、環境設定などのコツ（例えばパッケージの依存関係やインストールの順番などの細かいノウハウ）なども関係するかもしれません。そういった情報も書き残しておくと、誰かの助けになる可能性があります。

なお、この時点では、結論がなくても構いません。中途半端でも構いません。むしろ整理しようとしない方がいいかもしれません。整理しようとすると、試行錯誤の過程が抜け落ちたり、泥臭く苦労したところが抜け落ちます。せっかく記録を残すのですから、そういった生の情報こそ残したいものです。

そして、同じように困っている人がその記載にうまくたどり着いたら、とっても感謝されるでしょう。その感謝されていることが表明されるか、そしてあなたに伝わるかは別問題ですが、困っていた誰かを救ったという事実は揺るぎません。

さて、あまりにばらばらとやったことを書き連ねていては、結局どうなったかがわかりづらくなってしまう、ブログの見通しが悪くなるといった懸念が生じるでしょう。そういう時は、例えば「やったこと」「できたこと」という二つのタグを使って整理することができます。日々やったこと、試行錯誤の記録はやったことのカテゴリに入れ、とにかくいろいろな内容を書き出していきます。繰り返しになりますが、体系立っている必要はありません。困ったこと、やったことを丁寧に書きましょう。

「やったこと」カテゴリの記事がいくつかたまったら、これを整理して、「できたこと」タグをつけた記事を作ります。記事の本数を基準にするのもよいですが、（ある部分の）製作に一区切りがついたら、あるいは期間（例えば1週間、1か月、1プロジェクト）で区切ってもよいでしょう。いずれにせよ、試行錯誤の結果を整理して、どういう進捗があったのかを整理・体系化します。体系化の粒度は都度調整すればよいですが、例えば液晶モジュールを使うためにいろいろやったこと、そして結果こうしたら動いた、といった粒度を例示することができます。

「やったこと」の記事数本を、「できたこと」記事にまとめることで、記載内容は大幅に洗練・体系化されるでしょう。もちろん困ったことがあればその記事へのリンクを張るとか、その中身を参照するといったこともできます。概要を知りたい人、とりあえずやってみたいと思った人はその「できたこと」記事を読めばよいのです。そして何かつまづいたら、参照をたどって「やったこと」へ移動し、解決することができるかもしれませんね。

全体として、手軽に体系化することができるという意味ではとても素敵な選択です。ただし、フィードバックをもらいづらい方法です。ある程度記事がたまるなどするまでは手ごたえのなさに絶望するかもしれません。

LT会・勉強会・もくもく会で話す

せっかくいろいろなことを試したり、試行錯誤しながらものを作り上げたので、そこで得た実装・理論に関する知識や経験をLTや勉強会などで話してみるとよいでしょう。今やっていること、あるいは開発過程で得たノウハウを整理してトピックスとして説明するのです。

LTや勉強会で話す内容としては、時間も限られますし、すべてを話すことはできません。全体設計や困ったことなどのトピックスに絞り込む必要がある場合が多いでしょう。そのため、全体を俯瞰しつつ、トピックスの取捨選択を行うため、実装過程全体が整理されるでしょう。また、理解が足りなかったところが可視化されたり、試行錯誤をそぎ落として最短ルートで実装する手順を見出すことができるかもしれません。そして、ここで話した設計思想と実現の方法（の概要）は同じようなものを作りたいと思っている人にとても役立ちます。

逆に、大ハマりした部分に集中してトークするのも満足度が上がるでしょう。原因は何だったのか、解決の糸口をどうやって見出したのかなどは、他の人も知りたい部分です。

登壇資料・登壇内容を組み立てる中で、こういった形で体系化するのは非常に有益です。ここでいう有益とは、聴講者だけでなく、自分自身にとっても有益です。

さて、そのネタ元をブログから持ってくるのは非常に良い選択です。せっかく苦労したのに、細かい経緯を忘れてしまう、参照した別のブログが見つからない、2回目以降は自動的にできてしまうのでトピックスとしても残らない。などなど。思い出しながら登壇内容を組み立てるのは非常に大変ですが、もとになるブログがあると、それの再構築で組み立てることができますし、必要に応じて試行錯誤や細かいところまで取り出すことも容易です。また、TwitterのIDも資料に載せておくとフォローしてもらいやすくなるでしょう。

電子工作などの「現物」があるものなら、MFT(Maker Faire Tokyo)³やそのほかのMaker系イベントで展示をしてみるというのもいいですね。現物をみんなが見て、質問したり設計を説明したりするのはとても楽しいものです。

LT会などで話すという点は、人前で話すという（心理的な）ハードルの高さはあるものの、ダイレクトにフィードバックをもらう方法としてはかなり上位になります。やってみたレベルで構いませんので、カジュアルに話してみてください。必ずポジティブな反応がかえってきます。

技術同人誌にする

作りたいもの、作ったものの思想や実装過程を、技術同人誌にまとめてみませんか？ここまで述べてきたように、やりたいこと、やったことを文章として、本としてまとめるのです。

本書を読んでいるということは、技術同人誌について改めて説明するまでもないかもしれませんが、技術的なトピックスを扱う同人誌です。技書博⁴や技術書典⁵やコミケ⁶などのイベント、Booth⁷などのオンラインマーケット、とらのあななどの同人誌取扱ショップなどで入手することができます。

50ページから100ページくらいの本が多いでしょうか。筆者の推すニッチで尖った内容が盛りだくさんの本です。本そのものの作り方、頒布の仕方は、本を作ってイベントで販売するところまですべてをカバーするための本⁸を参照いただくとして、作りたいもの、作ったもの、困ったこと、その解決法などを「本」という形で整理するものです。

ブログやLT・講演と異なり、任意の内容を任意の粒度で整理することができます。LTのように時間制約のためにトピックスを端折る必要もありません。またブログより目次や章構成を自由かつ整理してつけることができます。

同人誌のメリットの一つは、読者の手元に本として残ります。必要に応じて見返したりもできますね。もちろん自分であとから参照しても構いません。「よくぞこのポイントを記録しておいた！自分天才！」と思うなんていうのも割とよくある話です。

また、ブログやLT会でのアウトプットと比較して、一つ大きく決定的に異なる部分があります。それは、その情報でお金を稼ぐことができる可能性があるという点です。50ページの同人誌を100部ないしは200部作ったとしましょう。500円～1000円で売ると、5万円～10万、あるいは20万円の売り上げになります。印刷費やイベント参加費などはかかりますが、数万円のお小遣いが手に入る可能性があります。そのお小遣いで、新しい基板やセンサ、部品や機器を購入しましょう。オシロとか。ブログのアフィリエイトでマネタイズするという方法もありますが、よほど確実で実入りは大きいですね。

この時にも、ブログやLTの内容を下地にするというのはよい選択です。同じ話なので繰り返しませんが。

また、技術同人誌を発行するタイミングはイベントに合わせて設定することが多いでしょう。足元コロナ禍で様々なイベントが中止・延期・縮小されていて厳しい情勢ではありますが、過去、そして将来は夏冬のコミケ、半年ごとに技書博や技術書典という風に、定期的にイベントが開催されることでしょう。そのイベントに合わせて半年スパンで進捗を本にまとめていくというスケジュールを立てることができます。ブログなどと異なり、イベントに合わせて本を発行するために「明確な締め切り」を設定することができます。締切があるというのは、非常に強いモチベーションになります。

発行する内容は、前回の本からの進捗を整理する形で、シリーズモノとして本を作ることができます。ある程度の実装規模を持つシステムであれば、関係する技術的な項目は多岐にわたるでしょう。それを網羅的かつ少しづつ本にしていくことで、いろいろな人にフックする本になるでしょう。また、どこかのトピックスにフックしたら、シリーズのほかの本も買ってくれる期待が生じます。ターゲットとするイベントを決め、締切を設定します。年2回のコミケをターゲットとするなら、8月と12月のイベントに対し、7月末頃と12月中旬頃が締め切りになります。開発・実装を少しづつ進め、執筆も少しづつ進めるとよいでしょう。ハイ、これは机上の空論です。もちろん順調に進捗を重ねられる人はぜひそのペースで頑張ってください。ほとんどの人は締め切り直前にならないと進捗が出ませんね。そういうものだと割り切って、無理をしないようにしてください。無理をしても進捗は出ません。嫌になってさらに進捗が落ちるだけです。

夏コミにここまでの進捗をまとめるとしましょう。スケジュールは以下のように逆算して下さい。夏コミの入稿期限はおよそ7月末です。これはあまり余裕がない（厳しい）締切ですので、7月20日を目標締切とします。順次逆算して、7月に入ったら文章を書く方にある8割くらいの力を注ぎます。文章を書きながら、バグが取れたり、テストしたりもしますから、2割くらいは実装に投入しますが、8割を実装に注入すると本ができません。したがって、7月にはある程度実装成果が必要です。ということは、実装を頑張るのは6月ということです。調査や計画は、気が乗らないとき、細切れの時間にもやりやすいので、その前にやります。夏休みの宿題のように、直前にまとめてやろう、というのはやめましょう。能力の限界を超えて、体調を崩したり、けっきょく動かなくて本もできないなんてことになりかねません。「計画性」は重要です。そして、そのための「締切の宣言」です。イベントの申し込み、当落、その他のきっかけに際して、都度計画を外に向けて宣言しておくことで、外的モチベーションあるいは強制力となります。そういう小手先のテクニックも使いつつ、成果物と本を並行して進めていきましょう。

本の横に実際に作ったものがあると、本の説明もやりやすく、光物、音、動きのあるものならば、通りゆく人の目も引きます。売り上げUp！

さらに、ある程度シリーズとして本が出来上がってくると、それを再編集して、総集編として発行することもできます。例えば、1冊目：作りたいものの計画と技術調査、部品選定、2冊目:機能A実装、機能Bについて実装（とトラブル）、3冊目：機能Aの実装ブラッシュアップ、機能C、・・・・といった形で本にしたとしましょう。半年に1回の発行だとして、1年半ほどかかりますね。最後に、この3冊(ないしは数冊)を総集編としてまとめます。この時に、最終実装に向けての実装をメインストーリーにし似たようなものを作りたい人に向けた入門書、実装説明書として解説します。そして、重複している部分を整理したり、やってみたけどダメだったところはTipsとして切り離したり、といった形で全体構成を整理すると、非常に読みやすく、レベルの高い本を作ることができます。

技術同人誌は、体系化という観点ではこれまでのなかでは最上級のアウトプットです。自分の積み重ねてきた内容を一冊の本として体系化することができます。ただし、その分準備は大変です。本としてまとめるには、執筆や組版といったこれまでとは違うアウトプットのテクニックが必要となる面もあります。ですがその分喜びもひとしおです。また、直接的にその成果を売り上げという形でお金に結びつけやすいともいえます。

全部やる

ここまで書いた方法を4つ全部やるのが5番目の選択です。アウトプットの量は3倍以上になりますが、準備・労力は3倍にはなりません。定期的にブログに書いたことを整理してLT会の登壇資料にしたり、勉強会でのフィードバックを反映してブログに書いたり、ブログの記事を整理して技術同人誌にまとめたり。そして、同人誌に書いた内容に追加が生じたら、ブログにサポート/追加ページとして記載する、なども可能ですね。

それぞれのアウトプットを単発に行うのではなく、どれかで行った・まとめた内容を別媒体に移すときに都度整理・体系化することで、さらにブラッシュアップすることができます。

もう少し具体的には、以下のような手順を経るというのはどうでしょうか？進捗や調査の経緯をブログとして残します。ブログが10本くらいたまったら、それを再構成して、LTのネタにします。すべての内容はすでにブログに書いてありますから、話す内容を一から作る必要はありません。内容の取捨選択とスライドづくりだけです。「何を話すか」を考えるのはかなり大変ですが、その部分をカットしてアウトプットすることができます。LTでのフィードバックや登壇レポートという形でさらにブログネタを増やしつつ、LTネタ、ブログ記事を再構成して、技術同人誌にします。同時に、こういう本を書きます、といった内容でLTをしたりブログを書いたり。

同じネタの形を変えて（あるいは進捗を加えたり切り口を変えたりして）何度も料理しておいしくいただきましょう。登壇スライドもある程度使いまわしができますし、ブログの写真を登壇スライドに載せたり、登壇用に作ったイラストをブログで使うなども可能です。

こうしていち一連のネタで何度もアウトプットすることで、最後まで走るモチベーションとなるとともに、その領域のアウトプット実績が付きます。界隈での認知度も上がることでしょう。

モチベーションが上がれば、製作のスピードも上がり、アウトプットもどんどん増えてくるでしょう。

Footnotes

1. ふりかえり実践会　https://hurikaeri.booth.pm/　や　アジャイルなチームをつくる ふりかえりガイドブック 始め方・ふりかえりの型・手法・マインドセット https://www.amazon.co.jp/exec/obidos/ASIN/4798168793/　などが参考になるかもしれません。 ↩

2. 経験者、知識のある人から飛んでくる鋭い指摘をマサカリと呼ぶことがあります。ただし、本当にすごい人はめったにマサカリを飛ばしたりしないもの。たいていの場合、聞きかじった人とかがとばしてくるものなので、ちょっと参考にする程度にしてもよいですが、真に受けてもしかたありません。 ↩

3. Maker Faire Tokyo https://makezine.jp/ ↩

4. 技書博(技術書同人誌博覧会)　https://gishohaku.dev ↩

5. 技術書典 https://techbookfest.org/ ↩

6. コミックマーケット。世界最大の同人誌即売会。評論情報などのジャンルの中に、電子工作やIT技術、その他の技術情報を扱う同人誌があります。 ↩

7. Booth https://booth.pm/ja/search/技術同人誌 ↩

8. 技術同人誌を書こう！　アウトプットのススメ (技術の泉シリーズ（NextPublishing）) 親方Project https://www.amazon.co.jp/dp/B07BY9YWCN/ ↩