エンジニアのための実践アウトプット入門　継続的に発信し続けるコツ

実践、アウトプット入門

塩谷啓氏（以下、塩谷）：「実戦的アウトプット入門　なぜ？　なにを？　どうやって？」という、小学校の教科書みたいなことになってますが、少し柔らかい話をさせていただこうかと思います。こんばんは！

会場：こんばんは！

塩谷：僕のほうからは具体的な話をゆるく聞いていただこうかなと思います。

自己紹介です。塩谷といいます。各種ID「kwappa」という、“w”が入るのがポイントですが、読まなくてよいです。ドワンゴの技術コミュニケーション室というところにいます。技術コミュニケーション室は、エンジニアの生産性を上げることをミッションにしていまして、採用や育成、技術広報なんかをしてます。

なので、こういう場に出ているのは、「ドワンゴではこんなことしてますよ。よかったら一度遊びに来ませんか？」ということを伝えるのがミッションだったりします。実は「こういう場でしゃべるときには会社紹介をしろ」という定石があることを最近知りましたので、ちょっと会社紹介をさせていただきます。

ドワンゴは「ネットに生まれて、ネットでつながる」という謎のキャッチコピーのもと、いろんなサービスを展開しております。

（会場笑）

一番有名なのがニコニコ動画に代表されるniconico系のサービスなんですが、その他にスマートフォン向けに音楽や映像、ボイスなんかを配信しているサービスがあったりします。

最近は、ガチの通信制の高校を始めました。2016年に開校して、僕は実はそこの生徒でもあります。いま3年生です。なので、いま一生懸命勉強して、今年卒業しないとカッコわるいなという状態です。それから右側はバーチャルキャストです。今年の7月にできた新しいサービスで、バーチャルの空間のなかで生放送ができます。

高校の横にバーチャル生放送が並んでいるのでさっぱりわからないですが、こうしたいろんなことをやっている会社から来ました。あまりガツガツ書いていませんが、エンジニア絶賛募集中ですので、気になった方はぜひ声をかけていただければと思います。

アウトプットとは何か？

ということで、「実践的アウトプット入門」のお話をしていきます。「アウトプットとは何ぞや？」「なぜ？　なにを？　どうやって？」「まとめ」という構成で進めていきます。

今回、「アウトプットとは？」ということで定義してみました。アウトプットとはなにか書いたりしゃべったりすることです。今日のポイントとしては、公開するしないは不問です。まあ、公開したほうがいいんですが、公開しなくても、つまり自分のためだけに書くことも、ここではアウトプットと定義します。

公開するしない、できればしたほうがいいという話はこの後の話になるんですが、エンジニアとしての成長に、アウトプットは不可欠だと思っています。「不可欠だと思っています」とか思っていたらですね、今週、……先週かな、ちょうどすごくいい記事がバズりました（注：イベントの開催日は2018年10月9日）。

Qiitaに書かれた記事で、「エンジニアは全員技術記事を書くことを習慣にしたほうがいいぞ」という海外の記事の翻訳なんですが、たくさんのいいねがついたすごくいい記事です。

要するに「自分でアウトプットして腕上げていかないと死ぬよ」ということが書いてあるんですが、だいたい「アウトプットしないと死ぬよ」的なことはこの記事に書いてあるので、ぜひ読んでいただければなと思います。

なぜアウトプットするのか

では、「なぜ？　なにを？　どうやって？」の「なぜ？」の部分ですね、なぜアウトプットするかという理由を3つまとめてみました。データソース、学びの定着と共有、コミュニケーションツールという側面ですね。

まずデータソースとして。いきなり、「僕は世の中に役の立つアウトプットをするのだ！」といって書ける人はいないですね。いたら、たぶんプロの作家として食っていけると思います。日本で技術書を書いて、技術書を書くことだけで食べられる人は3人ぐらいしかいないらしいです。というぐらい、技術的なアウトプットって実は難しいんですね。なので、いきなり公開できるものは書けません。

それなら、日々の経験を学び、問題とその解決方法をコツコツ書きためていく。今日の仕事のメモを書いても、それだけを読み返すとショボいんですが、それをコツコツと積み重ねていくことでネタ帳になります。

それからもう1つの理由、学びの定着と共有。まず、書くことで知識が定着するという側面があります。これ、ちょっとソースは忘れてしまったんですが、実は学校の授業でノートを取るじゃないですか。あれ、見返す必要ないらしいんです。

だから、きれいなノートを書くのは時間の無駄で、とにかく脳にインプットしたものをかみくだいて書くという行為がアウトプットになる、つまり、定着するそうです。これはまつもとりーさんのほうが詳しいと思いますですが、そういう効果があります。まず書く。それは別に物理、紙と鉛筆で書くんじゃなくて、キーボードで書くのでも、たぶん同じ効果があると思います。

それから、「公開するしないは不問」と書きましたが、見せる前提で書くと理解が深まります。なぜかというと、人になにかアウトプットを見せることになったら、自分でダダッと書いた下書きを見せるのはちょっと恥ずかしいじゃないですか。間違った情報が入っていないかとか、もっといい日本語で書いたほうがいいんじゃないかとか。

あと、技術的なことだと間違ってないほうがいいですが、コードを書くとかだと、コードは間違ってるいないのほかに、汚いきれいという軸もある。どうせ人に見せるんだったら、やっぱりきれいなコードがいいよね、という前提で書くと、例えばきれいなコード、よりよい設計を心がける。間違っていないかどうか調べたり、そういったことによって理解がより深まります。

そして公開する前提で伝える、実際に公開できるクオリティの情報を集めて公開しました。そうすると、世の中に出たその記事が誰かの悩みを解消したとしたら、誰かの30分ぶんの生産性を作ったことになる。情報公開って、たぶんそういうことの積み重ねだと思うんです。

あともう1つは、コミュニケーションツールとしての一面。これもまつもとりーさんのお話にあったのでササッといきますけども、エンジニアとしての技術や経験を伝える材料になりますと。ポートフォリオもそうだし、それから、書いてきたもの全部そうです。

アウトプットが役立つとき

そして、どんなときに役に立つかというと、例えば評価面談。ちょうどドワンゴは評価シーズンで面談をしなければいけないんですが、そのときに僕がやっているのは、「この評価期間の間にやったこと、アピールしたいこと、それから、次の評価期間にやりたいことを用意してきてね」だけ言っておきます。

そうすると、わかっている人はちゃんとその間になにをやってきたか、仕事のメモを紐解いて、「こういうことをやってきました」「こういう手柄がありました」というふうにしてきます。

同様に、「社内におもしろい仕事が発生しそうです。誰かいないかな？」って見回したときに、「はい！　僕できます」って言う材料としても、アウトプットはすごく重要です。なぜなら、「おもしろそうじゃん。君できんの？」「できます。なぜならこういう準備をしてるからです」。そういう材料にもなるわけです。

職務経歴書や採用面接。評価面談や配属希望は中に対してのアピールですが、今度は外にアピールすることも必要です。「自分はこんなことやってきました。こんなことできるんです。だから、僕を採用するとこんないいことがありますよ」というのを、伝えるためのいい材料になります。

これは手前味噌で恐縮なんですが、去年の年末に書いて、これも600ぐらいブクマが付いた記事です。

「エンジニアが読みたくなる職務経歴書」。僕は職務経歴書を書くときにどんなことを気を付けたほうがいいのか、というテーマで何回か話しているんですが、そのまとめ記事ですので、興味があったら読んでください。

何をアウトプットするか

続いて「なにを？」ですね。これはシンプルです。仕事メモ、技術メモ、プロダクト、そのどれかです。ポエムや創作は、この際は省くことにします。

仕事メモ、先ほどから「仕事メモ」と言っていますが、僕はデータソースという話をしました。データソースとして一番身近かつ手軽、「仕事中なにがありました」「なにに困りました」「どうやって調べた結果、このように解決しました」ということをメモしていきます。

もちろんメモするだけでもよくて、将来振り返るときにアピール材料に使う、評価面談の材料に使うときにも役に立つんですが、ここで1つ気を付けておくとさらにいいのが、ネタ帳です。

「こういうこと困りました」「こうやって解決をしました」ということを同じところにまとめて置きましょう。こういうネタがあったんだ、というふうに一覧性を、つまり一目で「このネタはこういう問題があって、こう解決しました」というのを、同じところにまとめておくところから意識して、ネタ帳を作るつもりで書いてもらえるといいかもしれません。

仕事のメモをすると、仕事を頼まれたときに忘れないじゃないですか。そうしたら、「あいつは仕事ができる奴だ」という評判も得られるかもしれません。……ちなみに、これ、笑うところですからね。仕事はちゃんとしよう、ということです。

技術メモを書く必要性

次に技術メモです。さっきのネタ帳の話を突き詰めて、技術的な問題解決、つまり「あなたの会社のなかで、こういう問題がありました。これをこう解決しました」というもののなかから、純粋に技術的な問題解決である部分をより分けて、1つのネタとしておきます。

これはどうしてかというと、可搬性、つまり、「あなたの会社のサービスはこういうもので、こういう構成で、こういう事情があって、この問題が発生しました」というのを、ただ単にメモったりするとまずそうじゃないですか。まあ、まずくないことならどんどん公開すればいいんですが、その会社特有のことにはいろいろと守秘義務があったり、競合に情報を与えてしまうとか、そのまま書くことはなかなかまずかったりします。

そういうときに可搬性を意識して、つまり、「これは公開できないけど、ここから先ならリスクなく公開できるな」という。エンジニアの場合、こうしたことは技術的な問題であればだいたい公開できるんです。オープンソースではないプロプライエタリなものでも、おそらくライセンスに書いてあるはずなので、ライセンスに違反しない範囲で公開するといいと思います。

という技術的な部分とそうでない自社特有のドメインの部分をより分けておくと可搬性が高まります。「公開できるかな」「ここは言っちゃまずそうだな」という意識を持つと、そのネタ帳をうまく使えるようになると思います。

いろいろ議論もあって、「仕事以外の時間に開発するの？　勉強するの？」「いいの？　悪いの？」という議論が今年も何度か持ち上がっていましたが、仕事以外にやったこと、自分で気になったこと、調べたこと、趣味でアプリ作ったということも、ぜひネタ帳に書くことを意識してください。

「おもしろい技術が出てきたな。ちょっと触ってみたよ」とやってみたのも、「触ってみた」でおしまいではなく、それを困ったこと、おもしろかったこと、役に立つことを、ネタ帳として記録しておくことを意識すると、これもアウトプットのメモとして蓄積されていくんじゃないかなと思います。

一番いいのはプロダクトですね。例えばWebサービスとか、スマートフォンのアプリとか、そういうわかりやすいかたちで公開する。そうすると、それがもし世の中に価値を届けるものだったら、みなさんが書いたコード、みなさんが出したサービスで世の中に価値が増えるかもしれません。

その結果、報酬というかお代をいただけたら、みなさんの生活もちょっと豊かになるかもしれない。エンジニアが副業でなにかして稼ぐのはなかなか大変なんですが、それでもちょっとビールを買えるぐらいのおこづかいがもらえたらうれしいじゃないですか。

解決したことをライブラリにする

それからもう1つ、「サービスやアプリって、自分ではアイデアもないし作れないよ」という場合でも、「面倒くさい処理をこう書いたら再利用性が高くて、ちゃんとテストも書いたから、次に同じ問題が起きても安心だよ」ということを、ライブラリに切り出しておく。

そうすると、みなさんも次の仕事のときに役立ちますし、もし同じ問題を抱えている人がいたら、その人に価値を提供することになります。これがオープンソースの世界の基本です。

なので、問題解決をして、それが可搬性がありそうな問題解決だと思ったら、ぜひライブラリにして、例えばRubyだったらRubyGems、JavaScriptだったらnpmなど、各言語にライブラリとして公開する仕組みがあると思いますので、そこでの公開を目標にしてみるといいのではないでしょうか。

さきほど「アウトプットは学びを深める」という話がありましたが、ライブラリに切り出すと、「もうちょっときれいなコードで書こうか」「テスト書こうか」「ドキュメントも書こうか」みたいな意識が働いて、ちょっとそういった手間をかけることで、ライブラリに対してさらに磨きがかかりますし、愛着がわいてくるという効果もあります。そこでGitHubでスターなんかをもらうと、非常にうれしいわけですね。

というわけで、自分にもいいことだらけだし、さらに世間にも、つまり世の中のエンジニアの役にも立つ可能性があるので、ぜひプロダクトとしてのアウトプットを念頭に置いてみてください。

OSSポリシーについて

これは今年の春先でしたか、サイボウズさんの「オープンソースソフトウェアポリシーを紹介します」という記事です。

実はオープンソースソフトウェアに対してポリシーを持ってる会社って、そこそこあるんです。僕はドワンゴを含めて2社知っています。

なぜなら僕の前職の当時のCTOに「オープンソースソフトウェアポリシーをくださいよ！」と言ってもらってきて、うち流にアレンジして、ドワンゴのオープンソースソフトウェアポリシーとして社内に公開しています。

ただ、いろいろな問題があって、（社外には）公開はしていません。全文をパブリックにはしてないんですが、そうしたらサイボウズさんがやってくれました。ちゃんと全文を公開したうえで、クリエイティブ・コモンズはCC0、「再利用してもいいよ」と言ってくれています。

これはなかなかネットでも議論があったんですが、けっこう踏み込んでいます。つまり、オープンソースソフトウェアの開発と会社の就業規則って、かなりバッティングするんですね。そういうところまで踏み込んで書かれたOSSポリシーであるという意味ですごくいい記事なので、プロダクトとしてのアウトプットをやるのであれば、ぜひ読んでみてください。

どうやってアウトプットするか

では、「どうやって？」の話をします。「どうやって？」、これは好きな方法でやればいいので、すごく一般的な方法を書きます。自分用に書く。それから、公開用に書く、人前でしゃべる。

自分用に書く。これは公開しない前提のアウトプットですね。データソースとしてとにかく書く。「なぜ？」と「なにを？」のところでも言いましたが、日々の仕事メモをどんどん書いていきましょう。気を付けるところは、ネタ帳にするであるとか、可搬性を意識するとか、先ほど申し上げたとおりです。

もう1つ、メモツールはぜひこだわってみてください。メモ帳とか、あとはMacだとメモやスティッキーズがありますが、すこし探すといいものがあります。

例えば僕は、MacとiOSでで同期できる「Day One」というアプリを使っています。これは書くとすぐプレビューに反映されて、同期もすぐ行われます。

それから、cliツールがあるんですが、コマンドラインからガーッとテキストを流し込むと、そのまま記事ができたり、逆に記事を読み込めたりします。バックエンドはSQLiteで作られているので、SQLiteからデータを引っ張ってきて、そのデータをもとにゴニョゴニョすることも簡単にできます。

そんなツールがたくさんありますし、メモツールの比較もWebには記事がたくさんありますので、ぜひいろいろ試してみて、自分のフィーリングややりたいことに合うものを探してみていただけたらなと思います。

再利用性は、先ほどから何度も申し上げてるネタ帳であるとか、可搬性であるとか、そういったこと。つまり、メモを取るだけでなく、どうやってそのメモを活かすか？　「メモは書くだけで勉強になる」という話をしたにもかかわらず真逆のことを言って申し訳ないんですが、書いたものをどう再利用するか？　例えば、評価の時期のアピール材料にする、ブログ記事のネタにする、みたいなことを意識して書いてもらうといいかなと思います。

人に見せる前提でアウトプットすること

今度は公開用に書くところ、これはブログ、Qiita、GitHubというよくある公開先を雑に書きました。はてなブログでもいいですし、無料でもホスティングしてくれるブログが山ほどあります。なかったら自分でレンタルサーバーにブログを立ててもいいと思います。

それから、技術メモを書くプラットフォームとして最近定番になりつつあるのがQiitaですね。「技術記事書かないと死ぬよ」という記事もQiitaで書かれていたので、Qiitaに書くと手っ取り早いと思います。

いいねとかストックなどのフィードバック、気軽でカジュアルなフィードバックの仕組みがあります。これはなにがいいかというと、モチベーションが上がります。いいねがつくとすごくうれしいです。なので、Qiitaというプラットフォームを使ってみてもいいかもしれません。

それから、ソースコードが公開できるものであれば、やっぱりグダグダ記事を書くよりも、ぜひ実ソースということで、GitHubをおすすめします。BitBucket系の方がいらしたら、ぜひその哲学を貫いていただければいいんですが、GitHubもプラットフォームとしてデファクトスタンダードになりつつあるので、こういったプラットフォームに書いていただければいいなと思います。

さらにもうちょっと進んで、雑誌記事や書籍。このすごくいいところは何かというと、1つは編集さんが付くことです。出版社さんが出してくれる雑誌や書籍には編集さんが付いてくれます。

編集さんが付いても熱意や力量はピンキリなんですが、レビューをしてくれます。自分が書いた記事や情報をレビューしてくれる、つまり編集をしてくれるという経験は、すごくいい経験になります。伝えるためにはこう書いたほうがいいということを編集という作業を通して学べるという意味ですごくいい経験になりますので、ぜひチャレンジしてみてください。

そんなお声がかかるのも日々のアウトプットがあってこそなので、ぜひ「いつか雑誌記事書くぞ」「本を書くぞ」みたいな気持ちで、日々のブログを書いていくというのもいいと思います。

ちょっと脱線しますが、著書を書くと、Amazonに著者セントラルを作れます。これ、実はプロフィールツールとしてすごく強いんですよ。例えばフリーランスのエンジニア、ちゃんと仕事をしていて収入があるんだけども、住宅ローンが組めないんですね。

でも「フリーランスでこういう収入があります。収入の証明を持ってきます」と言うと、銀行の担当者がなにするかというと、フルネームでググるらしいんですよ。そのときに著者セントラルが出てくると、「そうですか。あなたはちゃんとした人なんですね。じゃあ、お金を貸しましょう」なんてこともあるそうです。

今の自分を出すことに価値がある

ポイントは、謙虚に、でも萎縮せず。謙虚にというのは、やっぱりみなさんエンジニアとして成長していく途中なので、その時点で世界最高のエンジニアではないわけです。まつもとりーさんのお話でも「世界最高が見えてきた」というお話で、まだ世界最高とはちょっと距離があるわけです。僕のような平凡なエンジニアは世界最高には程遠いですが。なので、そういうときに謙虚に、萎縮せずというのはなかなか難しいんですが、ぜひ意識してほしいです。

謙虚にというのは、「俺の記事は正しいんだ！」とか、「おまえのこのプロダクトはダメだ」と人を攻撃するであるとか、自分を過度に高めるだとか、そういうことは嫌われます。なので謙虚に。そしてアウトプットに対してフィードバックがあったら、それも謙虚に受け止める。

というのが大事なのですが、同時に委縮しない。つまり、「こんなにレベルの低い記事を世の中に出したって、なんの価値もないよな」って思っちゃうのが実は一番いけないんです。

そうすると、世の中にある初心者向けの本はすべて価値がないものになってしまいます。でも、初心者本って毎年何冊も何冊も出て、そこそこ売れるんですね。なので、いまの自分にできる最高のアウトプットをしていればそれでよいと。世界最高の情報ではないかもしれませんが、いまの自分が出すことに価値がある。なので、萎縮しないで出しましょう。

出すことによって、あるいは、出してフィードバックをもらうことによって、よりレベルの高いアウトプットができるようになる。そういうループが回ることを意識して、萎縮せずに出してほしいなと思います。

人前でしゃべる経験をせよ

では、今度は人前でしゃべる話をします。ぜひ社内イベントでしゃべる練習をしてください。社内イベントでしゃべるとなにがいいかというと、あまり恥ずかしくない。社外で失敗するより社内で失敗したほうが、あんまり恥ずかしくない。

もし社内でそういうイベントがなかったら、ライトニングトークがおすすめです。ライトニングトークの本来の意味は、5分間だけしゃべる、5分経ったらドラがガーンと鳴って「はい、おしまい！」ってなるんですね。

なので、しゃべるほうも5分がんばればいい、聞くほうもどんな酷くても5分我慢すればいいというプレゼン方法で、社内にアウトプットの場がなかったり不足していたら、ぜひ「今度、ライトニングトーク大会をやってみない？」と提案するのもいいと思います。

コミュニティイベント、例えば言語ごとのRubyKaigiであるとか、あとはNode学園祭であるとか、ScalaMatsuriとか。あとは、言語によらず地域にコミュニティがあったりとか、そういうソフトエンジニアの集まるコミュニティでぜひしゃべってみてください。

これが一番勉強になります。やっぱり大勢の人の前で嘘八百言うのはすごく恥ずかしい。じゃあ、ちゃんとした本当のことをしゃべろうと思って調べると、そのことが勉強になります。

コミュニティイベントでもライトニングトークというコーナーが設けられてることが多いので、ぜひ最初はハードルの低い発表のプラットフォームとして、ライトニングトークというのを覚えて帰ってください。

アウトプットは謙虚に、しかし萎縮はせず

すいません、時間が過ぎてしまいましたがもう1個だけ。まさに昨日、技術書典5というエンジニアが書いた同人誌を展示即売するというイベントがありました。

入場待機列が1,000人とか、ブースが400とかあったのかな。みんながアウトプットしてみんなに売って、そこにそれを買いに1,000人くらい（注：公式発表では総来場者数のべ10,341人）のエンジニアが来るという、アウトプットの世界はこんなところまできていたというイベントです。僕も行って、8,000円ぐらいの買い物をしてきました。

そのぐらいアウトプットをすることと、そのフィードバックを受けるというループが盛り上がっているので、今度は来年の春にあるそうなので、気が向いたら行ってみてください。

ということで、まとめとしては、アウトプットをしましょう。それから、謙虚に、でも萎縮せず。一番言いたかったのはこれだなと気付いたので、まとめに入れておきました。