地方エンジニアが実践するアウトプット継続のための2つの戦略
7月25日（木）に仙台の「タガヤス：東北のITを盛り上げて行きたい！」という志のもと集まった団体で『好きな技術の学び方（ナレッジのI/O）』というテーマで1セッション担当することになりました。
はじめは「へー、ちょっとおもしろそう」みたいな感じだったのですが、改めて私の情報発信・アウトプット戦略の棚卸ししたら少し面白いかもなぁと思いながら、これをまとめています。
誰に向けて？
これはあくまで「私」の経験と考え方に基づく、より良い「学び方」「情報発信」「アウトプット」、そして「継続」のための戦略です。それは私が考えるエンジニアとしての生存戦略でもあります。
なので身近に存在している一般的（？）な地方エンジニアの一例として聞くのが吉ですが、なかなかアウトプットを継続できない、アウトプットがうまくできない、と悩んでいる方の一助になればとも思い書いています。なのでどちらかといえば、若手エンジニアや新入社員向けだと思います。
ちなみに、私がどんなアウトプットをしているのか、は以下の記事でざっくりまとめています。
アジェンダ
- 「アウトプット」とは何か？
- どうやって「アウトプット」をしているのか？
- どうやって「アウトプット」を継続しているか？
「アウトプット」とは何か？
さて、まず今回の主題である「アウトプット」とは何か？ を改めて考えてみます。
Blogへのアウトプット、SNSへのアウトプット、様々カタチ・要素・プラットフォームでのアウトプットがありますが、私のコトバで置き換えるのであればアウトプットはすべて「表現」です。
それはどんなプラットフォームでも問いません。Blog、SNSなどはもちろんのこと、メモ、会話、ディスカッションすべてアウトプットです。
ただ、Twitterでちょっとフォロワーの方と話したのですが、「腹落ち」では無いです。「腹から出す」までが大事で自分の中で咀嚼して貯め込むまではインプットです。
取り込んだものを自分の中にある要素を介在して、外に出すことを私は「表現」と私の中で定義しています。
なぜアウトプットをするのか？
「なぜアウトプットをするのか？」と聞かれると、そもそも「インプット」のみ、例えば
- 本を読んだところで
- 勉強会やセミナーに参加したところで
- 先輩や上司に教えてもらったところで
「技術やスキルは向上しない」という事実への向き合いのほかありません。
私達はインプットのみで何か「モノ」を作ることはできません。「アウトプット」することで初めて自分のモノにすることができます。
絵を描かなければ、上達しないように、プログラミングや技術スキルも何かしらのアウトプットを糧にしなければ上達するはずがありません。でも、なんとなく日本のITエンジニア職は、新卒研修やOJTのみで、プロとして現場に放り出されるから不思議ですね。
これを端的に捉えた説明は養老孟司先生の有名な書籍である「バカの壁」の一文ですね。
身体と学習
身体を動かすことと学習とは密接な関係があります。脳の中では入力と出力がセットになっていて、入力した情報から出力をすることが次の出力の変化につながっています。身近な例でいえば、歩けない赤ん坊が何度も転ぶうちに歩き方を憶える。出力の結果、つまりここでは転ぶという経験を経て、次の出力が変化する、ということを繰り返す。そのうちに転ばずに歩けるようになってくる。 養老孟司. バカの壁 (Kindle の位置No.861-865). 新潮社. Kindle 版.
入力だけでなく、出力、そして出力した結果のフィードバックを得て、それを繰り返すことで歩けるようになる（上達する）。
また、インプットからアウトプットへは、自分というフィルターを介在する以上、必ず出力結果にノイズや誤差が生じます。エンジニアの文脈で考えれば、プログラミングを行う際に、どんな粒度であれ「設計」を行うと思いますが、最終的な成果物との誤差を限りなく少なくする行為とも言えるでしょう。
つまるところ、私は別段人のためにとか、MVP獲得のためを目的としてアウトプットを行っていません。（イベントの登壇であれば、ターゲットとテーマ、何が刺さるのか？ 何を持って帰ってもらいたいのか？ は意識しますが）
私がアウトプットを行っている理由はこれだけです。（あ、もちろん面白いとか、いろんな人からフィードバックがもらえるとかはありますよ？ でもメインじゃありません）
ただ、学生時代の受験のためアウトプットと社会人のアウトプットは大きく違っていて、ただ単純に問題集を解く、みたいな形ではいい感じのアウトプットはできないよなと思っています。それをもう少し私の解釈で噛み砕いてみます。
そもそも「わかる(身につく・スキルが向上する)」とはどんなものと考えているのか
「私は、何を知らないのでしょうか」 野崎まど. know (Kindle の位置No.1846-1847). . Kindle 版.
私は学習過程において最も大事な要素は「表現（アウトプット）」に加えて、「未知化」であると考えています。「未知化」は、今手元に本が無いので、自信が無いんですが、おそらくデザイナー原研哉先生の「デザインのデザイン（14,5年くらい前、高校生時代に読んだ）」本で取り上げられていたキーワードです。
近いことが以下の記事で取り上げられています。
「未知化」、これはいわゆる「わからないことがわかる」です。
例えば、今回のBlogでもそうですが、一度そのキーワードや技術・テーマについて「これって結局なんなんだっけ？」を考えて、自分の中で再定義を行います。
私は「わかる」をそのテーマ・キーワードに対する解像度があがると表現しています。
以下のように、なんとなくわかっているものを、未知化を行うことで輪郭を捉え直し、少しづつ輪郭をはっきりさせて、解像度を増していく。これにより対象がどういったもので構成されているのかを捉え直すことで、「わかる」が進んでいきます。
これを「なんとなくわかっている」状態から以下のような形で「わかる」へ進めていきます。
- 「未知化」を行う
- 「情報」を集める（インプット）
- 「カテゴライズ」「答え合わせ」する（咀嚼）
- 「表現」する（アウトプット）
- 「わかる」
この1～4を繰り返すことで、「わからない部分」を「認識」し、自分の中での「定義」「わかる」を形作っていきます。
では、改めてアウトプット・表現がどこにあたるかと言えば、細分化の過程です。その過程が抜けてしまうと、フィードバックが無いので、細分化して解像度があがった要素に対して更に未知化を行うことが進みません。
解像度が上がると、例えば「大・小」しかできなかった表現が「大・中・小」、「特大・大・中・小・極小」といった形で、より仔細な表現に向かっていけます。
開発の過程でも、設計段階でより仔細に自分が描くソースコードや成果物のイメージを捉えることができるようになります。これが私の中の「わかる」です。
どうやって「アウトプット」をしているのか？
これで「アウトプット」の定義が見えてきました。次にどうやっていい感じにアウトプットしているのか？ を見てみたいと思います。
「いい感じ」のアウトプットってなんでしょうかね？ 前述の観点に基づくと、「解像度」を上げやすいアウトプットと考えることができます。それは様々な確度からのフィードバックを得やすいことが大事です。
私が主に意識しているものは以下の2つです。
- 「表現」先を多様に持つこと
- 「自分のコトバ」化すること
まず「表現先」ですが、手軽な表現手段とがっつりと時間を取って行う表現手段、まんべんなく持っているのがいるのがおすすめです。
私は主に以下の4種類をアウトプット手段として持っています。難易度や手軽さが「低→高」で並んでいて、それぞれを使い分けることで、継続的にアウトプットを行っています。
そしてそれぞれの「表現先」で2番の「自分のコトバ化」することを意識しています。
SNS（Twitter）
1番手軽かついいアウトプット手段は「SNS」が筆頭でしょう。「Facebook」「Twitter」「Linkedin」「Instagram」とやっていますが、主にアウトプット先として意識しているのは「Twitter」、続いて「Facebook」でしょうか。
主に以下の3種類＋私的なことをつぶやいています。
- テック系ニュースの引用・メモ
- 検証過程の記録
- 勉強会でのツイート
「1.テック系ニュースの引用・メモ」は最も簡単なアウトプットですが、1番意識していることは自分のコトバで引用文を形作ることです。これが結構頭を捻りますが、そこからそのニュースに関するより詳細な情報を調べたり、実際にそのニュースで紹介されていることを試したりするので大事な要素でもあります。ただ、ニュースを見てリツイートしたときよりも、解像度があがります。
「2. 検証過程の記録」も大事なアウトプットです。Blogにまとめるのはなかなか力がいるので、あとでBlogにまとめやすいように、そのテーマに触れた時に感じたことやメモ、リファレンスをまとめるという意味合いが強いですが、SNSでまとめることで足りない要素などのFeedbackをもらえたりするのがポイントです。
Blog
Blogは主に以下のTopicを中心として構成しています。
- やってみた、HelloWorld（新機能紹介）
- あとで見返すであろう技術メモ
- 勉強会参加レポート
- 技術解説
- ポエム・コラム
それなりにまとめた形の「各技術トピック」がメインですが、Microsoft系テクノロジーの最新情報を追っているので、新機能やってみた系が割合多いです。新しいトピックが自ずと入ってくるので、継続的な投稿に繋げやすいというのがありますね。
なお、私はOneNoteというアプリでBlogの下書きをまとめていますが、かなりいろんなトピックを並行して書いています。下書きのままで終わるものもありますが、アイディアベース、タイトルだけ思いついて、というのも書き残しておくことで、後々別なTopixの役に立てたりみたいなアプローチで書き上げています。
勉強会の参加
勉強会の参加はインプットの場じゃないかと思うかもですが、結構立派なアウトプットの場でもあります。
重要なのは「話を聞くための場」ではなくて、登壇者や周りの参加者との「対話」の場であると捉えること。コミュニティってそもそもそういうものですよね。だからこそ「アウトプット」の場として勉強会があります。
ポイントは参加する前に、事前にテーマや登壇者については調べておくことです。これにより参加する前から「疑問」と「質問」を持ち、何を自分が「求めているのか」ははっきりさせておくことができます。
もちろん勉強会の参加レポートやSNSでのツイートも立派なアウトプットですが、参加する前の下準備次第でより濃密なアウトプットが可能でしょう。
ちなみに、過去に一度勉強会の開催前にまとめ記事を書いたことがありますが、これは効果絶大でした。
勉強会当日に自分が何を重視して話を聞くのかが明確になっていますし、登壇者の方にも捕捉されていたので、交流会でも「あのBlogの方ですね！」と声をかけてもらえて、ディスカッションやフィードバックが大きく得られました。
勉強会・セミナーへの登壇
登壇は最も有効かつ自分にも身になるアウトプット方法ですが、何分敷居は高いです。でも、最近はどこの勉強会でもLT募集などがあるので、そういった部分から参加してみるのがいいでしょう。
個人的に1番いいなと思うのは登壇にからめて、BlogもYoutubeもTwitterにもアウトプットしてしまうことです。これだけでアウトプット量が2倍、3倍になります。Feedbackも多く受けることができるでしょう。
「私」はどうやって「アウトプット」を継続しているか？
最後に「アウトプット」の継続について、自分なりの見解をまとめておきたいと思います。結局すべては「継続できるかどうか」だけです。継続していくなかで、自分のアウトプット方法が確立していきます。
そんな私の「継続」のために意識していることはこの2つです。
- 「強制されている感」をいかに無くすか
- 「スコープ」をいかに絞るか
「強制されている感」をいかに無くすか
継続的なアウトプットを考える上で、自分が嫌にならないアウトプットというのは必須です。
私は土日や仕事帰りにBlogを書くとか調べ物をすることは苦痛ではないですが、締切のためにとか、仕事のためとか考え始めると嫌になります。そんな中で自然とストレスが無い形で継続でき、かつ土日でもそんなことができるのは、「キライなこと」「強制されている感」を無くしているからです。
では、何が「キライ」か？ 何が「強制されている感」を生み出すのか？ 4つピックアップしてみました。
- やらなきゃいけないがキライ（仕事上必要になって）
- やらされることもキライ（上司からの指示で）
- 誰かのためにするのもキライ（家庭のため、子供のために）
- 何かのためにするのもキライ（MS MVPのため、キャリアのために）
「3.」「4.」はちょっと難しい。もちろん結果的には何かのためにすべてやるんですが、興味や関心を軸にしたほうが気が楽です。適度なプレッシャーは「強制されている感」を生みます。なのでこの辺は「結果的に」キャリアのためになるとか、MS MVPになれたがいいのではないかなと思ってやっています。
では、この「1.」「2.」の「キライ」をどうくぐり抜けるのか？ について自分なりのアプローチを紹介したいと思います。
「仕事」と「趣味」の間くらいを狙う
「仕事が趣味です！」という方なら、関係無いかもしれませんが、私は別に仕事が趣味じゃありません。なので完全に仕事ではなく、完全に趣味でもなく、でもちょっとだけ仕事の予習にもなり、それでいて指示された感の無い領域を狙うのが個人的なおすすめです。
仕事に直結しすぎると、自分がやっていて嫌になりますが、これなら結果的に仕事でも評価されやすいです。
具体的なアウトプット例を上げると
- リリースされたばかりの新機能を検証してみる
すぐに仕事にはならない。でも将来的には役立つかも知れない。そんな要素を検証してみます。新しいAPIがリリースされたら検証してみるとかいいですね。
これがいいのは「スピード」だけが勝負という点です。先輩・後輩関係ありません。誰でも同じスタートラインに立てます。アウトプットするだけで、拡散されやすいしフィードバックも得やすいです。
- 次のプロジェクトで使いそうなものを実験してみる
アサインされるかどうかわからないけど、これからこの機能使いそうだなーとか、この言語使いそうだなーというラインを狙うのがいいです。
指示されたわけではないので、どこまでやるかも自由です。HelloWolrdで済ませてもいいし、アプリを一つ実装してみるとかでもいいです。とにかく「指示される前」というのが大事です。
「スコープ」をいかに絞るか
あとは如何にアウトプットのための「スコープ」を絞るか、ですね。兎に角、「小刻みに」「小さなものを」「数多く」アウトプットするのが、継続のためのポイントです。
ただ、最初は結構自分のアウトプットできる分量のイメージが沸かないので、結構大きなスコープで書いてしまいがちです。。
個人的おすすめはこの2つ。
- アウトプット過程をTwitterで連ツイート
機能検証などの過程を連ツイートでつぶやいておくのは結構いいです。それら単体がアウトプットにもなりますし、あとで画面キャプチャやリンク先などをBlog用にまとめやすいです。途中でフォロワーの方などからコメントやツッコミをもらえるのもいいですね。
例えば以下のような感じです。最終的にこれはLTとしてBlogとスライドにもまとめる予定。
というわけで、久しぶりにポータルを触る。#PowerAppsPortal pic.twitter.com/7z8N4qp82X
— Kazuya Sugimoto (@sugimomoto) 2019年7月19日
- 予め章立てを構成
最初から連作にしてしまう想定で、章立てを作ってしまうのもいいですね。以下の記事はかなりテーマライクに攻めたものですが、各検証要素が綺麗にわかれていたので、ざっくりと全体の枠組みを整えてから、個別に中身を埋めていった感じです。
ちなみに、全体構成が決まったら結構バラバラと書いています。あっちを書いて、こっちを書いて、そっちを直して、こっちを付け足して、みたいな書き方をします。綺麗に頭から書くことはしません。それにより相互作用で全体のクオリティをあげていきますし、途中で詰まったりすることが少なくなります。
最後に
こんな感じで書いていて思うんですが、やっぱりアウトプットも筋力ですね。一つ一つ出し切ると、大きなものが徐々にアウトプットできるようになってくるなと実感します。
はじめは限界値がわからなくて、疲れちゃったり、途中でやめちゃったりというのがあると思いますが、あまり気にせず次のトピックに手を出して書き上げられるものからやっていくのがいいと思っています。
そして、徐々に自分の限界を伸ばして、アウトプットの効率を上げていくのがいいでしょう。
今回はかなり自分の中での棚卸しの側面も強かったのですが、この記事を読んで、もっとアウトプットしてくれる人が増えると嬉しいです。むしろ、是非みなさんのアウトプット戦略について教えて下さい。
