エンジニアにとっての“アウトプット”の意味––発信し続けるために必要なこと

企業に所属するエンジニアとしての社内と社外の実績の重ね方

松本亮介氏：さくらインターネット研究所の松本です。よろしくお願いします。今日は僕のほうから何を話すか考えましたが、やっぱり「社内でやっていることをできるだけ自分の実績にしたい」というか、ポートフォリオを書こうとしたときに、「社内の情報を出せなくて、自分はなんもアピールできない」みたいになったら困るなと思っていて、そのあたりで僕が意識していることなどをお話できたらいいなと思っています。

僕はForkwellさんの技術顧問もしていまして、そういう縁もあって（ForkWellさんに）ちょっと福岡に来ていただきました。この後にアウトプットの話とかをしていきたいなと思っていまして、また今日も資料を作りすぎたので、急いでいきたいなと思います。

（会場笑）

以前、東京で「ポートフォリオがどういうものなのか？」「なぜ必要なのか？」といった、もう少し抽象的な話をさせていただきました。

これもログミーさんですごくいい感じにまとめていただいたので、ぜひ今日の発表で興味を持っていただけたら、読んでいただけると幸いです。

「アウトプットしていたらスキルが上がった」みたいな話がよくあります。僕も含めて、そういう人は「楽しんでやってるうちに、いつの間にかスキルがついて、有名になった」みたいな話を「アウトプットすればスキルが上がるぞ」と言っているパターンが多いんですね。

僕自身もそうでしたが、あらためてみなさんにお伝えするときにどうすればいいかなと考えて、もう少し一般化して、「なんでそれがよかったのか？」を今日はお話ししたいなと思っています。

さらに、「アウトプットする」というのは、企業のなかでいろいろと取り組んでいることと比べると相反するというか、「外になんでも出せるのか？」といった話もあると思います。そこを「それにどう乗っていくか？」みたいな話を整理して考えてきました。

今日はこういう話をします。

前提となるエンジニア像と業界

「前提」というのは、Twitterで「エンジニア」というと「主語が大きい」といわれるので、スライドのなかではちゃんと「エンジニアはどういうところを指しているのか？」を整理します。

僕らのいるWeb業界は人材が非常に流動的です。そのなかで自分の価値をどう高めていくのか、他の人から見ても他の会社から見ても自分の価値があるということをどう示していくのか。そのあたりをやっていきたい人のことですね。

それで「とくにアウトプットするのがいい」と聞いて、「じゃあ、アウトプットしてみよう」と思うんですが、18時や19時まで仕事をして、家に帰ったらもうしんどくて寝ちゃったといったことがあると思います。

いろいろとすごくがんばっているんですけど、いまいち成長を実感できないみたいな人たちに（今日の話を）持って帰っていただければいいなと思っています。

業界というのは、先ほどの話のなかで出たとおりオープンソースを使っていて、その変化についていかないといけない状況にある業界……Webサービスや、先ほどのペパボさんのお話でいくと、いろいろなWebサービスやクラウド、ホスティングなども、オープンソースをよく使っているんですね。そういうところで、どうアウトプットしつつ技術を共有して自分の価値を高めていくかといったところですね。

よくある悩み

このあたりの話は、僕もいろんな人からよく質問を受けたり、悩みを相談されるんですけど、よくあるのがこういう感じですね。

今日はこの悩みに対して、前半と後半に分けて答えたいと思います。

「いっぱい書いたのに、誰も見てくれない」「ネガティブなコメントが怖い」といったことは、よくありますね。僕もイヤです。「いっぱいやってるけれど、あんまり質がよくないから見てくれないんじゃないか」「アウトプットしても意味ないんじゃないか」という話もけっこう聞きます。

先ほど申し上げたとおり、「プライベートな時間で（コードを）書くのが大変」というところですね。また、「社内の取り組みなので、どうすればいいのか？」などです。

最初なので、あえて厳しくいっておきたいところがあります。アウトプットというのは、アウトプットしたら有名になれるというものではまったくないです。

だから、数ヶ月の間、アウトプットしてスキルが上がったのを実感できたり、いろいろ知ってもらえるようになるかというと、「そんなことはあり得ない」と、あえてここでいっておきます。

では「アウトプットや、アウトプットに付随する大事なことってなんなのか？」を考えてみました。とくに、よくある悩みの前半ですね。

まず「アウトプットってなんだろう？」というところを考えてみます。

アウトプットとはなにか

これまで、企業でいろいろと学習してスキルを上げているエンジニアを見てきたなかで、あらためて実務を振り返ったり、「エンジニアリングのアウトプットはなんなのか？」を、自分のなかで整理しました。

つまり、「学んだことをいかに思考して実践するか」という、わりと単純な学習方法の1つなんです。だから、スポーツでも勉強でも、たくさん練習したり問題集を解いたり、いろいろやると思うんですけど、そのアウトプットとすごく似ています。さらに、（下の3行は僕の感覚でもありますが、勉強して頭のなかにある状態でいざしゃべろうとしたり、いざコードを書いたりしようとしても、なかなかうまくいかないんです。

なぜかというと、そこから実践するまでに、もう1ステップ「なにか」やらないといけないことがあるんですね。それが「アウトプット」に近いなと思っています。イメージとしては、「コンパイルして保存しておく」みたいな感じなんです。

だから、しゃべりたいとか、体を動かしたいとなったときに、すぐに結果が出せる。自分のなかでは、思考と実践のギャップを埋める作業なんだなと（いう感覚が）漠然とありました。

ここで茂木健一郎先生を例に出したいと思います。後付けでいろいろ調べていくと、茂木さんの『プロフェッショナルたちの脳活用法』で、まさに同じようなことが書かれているんです。

プロフェッショナルたちの脳活用法 (生活人新書)

一番上の情報をインプットする「感覚野」……これ、（読み方は）「かんかくや」で合ってますよね？　「の」じゃないですよね？

（会場笑）

この「感覚野」と、動きとしてアウトプットする「運動野」は、脳のなかで直接コミュニケーションを取れないらしいんですね。だから、感覚野は情報を収集したりする部分です。（スライド）2行目の「運動」は走ったり、スポーツもそうですし、勉強もそうですが、とにかく自分が表現する部分で、コードを書き出すというのもそうだと思います。

「これが脳のなかで直接コミュニケーションできないから、わかってるけどできないっていう状況にけっこう陥る」という話が書かれていて、「あ、まさにそうじゃん」と思ったんですね。

さすがは茂木先生、「では、どうやって情報を共有するか」にも触れています。直接つなぐものが脳のなかにないから、その回路をなにかしら、他のところでつながないといけない。その定番の方法が、「自分に言い聞かせること」なんですね。これは感覚野という思考をするところと、実際に動かす出力のところをうまく同調させる方法らしいです。

要するに、自分の頭のなかにあることをアウトプットして、そのアウトプットしたものをもう一度、自分のなかにあらためてインプットすることで、うまくつながるわけですね。

「まさにこれだな」と思ったわけです。だから、「アウトプットはなんでいいのか？」という話になったときには、脳科学的にはこういう話が関連しているんだなというのをあらためて思ったという話でした。

アウトプットによる脳へのキャッシュ

それに付随する話で、脳もアウトプットをどんどん繰り返して、自分のキャッシュみたいなところへ、どんどん情報を置いていっている感じがするんですよね。例えば、いま僕は発表のためのスライドを使っているんですけど、だいたいの内容は頭のなかにあって、あんまりスライドを見ておらず、雰囲気でしゃべっています。これは、頭のなかにキャッシュがあるから、ペラペラしゃべれる感じですね。

アウトプットしたり、登壇していると、どんどんキャッシュになって、頭のなかに入ってくるからだと思います。

例えば、（スライドの）4行目でエンジニアがなにか問題を見たときに、いろんな観点からササッと回答する状況も、これ（と同じこと）なんじゃないかと思うんですよ。

逆に、優れたエンジニアの人たちが、自分が思いつかないようなアイデアをバッと出すのは、意識してないけれど、キャッシュのなかにあるいろんな情報がうまく組み合わさって、新しいアイデアが創発的に生まれて、それが質になっていくんじゃないかと思います。これが、僕の「量と質の定義」みたいなところですね。

もう1つ、本当は根拠があれば言いたかったことがあるんです。どんどんアウトプットをしていくと、僕の頭のキャッシュの領域が拡張している感覚があります。「それ、本当なのかな？」というのは調べ中ですが、そういう効果を感じています。

だから、こうしてアウトプットをしていくと、経験や思考みたいな感覚野の情報が、自分が実際に動くところにうまくつながっていく。アウトプットはそのための学習法であり、方法論だろうなと理解しています。

アウトプットが市場価値につながるようになった

また、「市場価値」みたいな話などもいろいろありますが、それとどう関係するのかを考えます。アウトプット自体は飛び道具ではないので、ひたすら勉強するしかないんですよね。だから、1年やっただけですごく成長するなんてことは基本的にないです。

とにかくコツコツやっていく必要があるんですけど、インターネットやソーシャルなどがすごく普及してきたことによって、（スライド）4行目にある「フィードバック」など、別の人との双方向のコミュニケーションがかなり取りやすくなった気がするんですね。

この「コツコツとアウトプットする」という前提のもとに、それがいいものであれば拡散されて個人のアピールになるというのが、たぶん、これまでだとうまくいかなかった。だから、すごい才能を持った人が埋もれていることがあったと思うんですけど、そういう人がだいぶアウトプットすることで、伝わりやすくなりました。

アウトプットすることが市場価値に結びつきやすくなったというのはすごく大きなことだなと考えています。

そう考えると、さっきの@pyama86さんの話にもあったとおり、学習法なので、一度アウトプットしたら、どんどん勉強して、またアウトプットして、となると思いますが、アウトプットしてそれで終了ではないんです。

いまの話でいくと、アウトプットは前提で、インターネットを使ってどれだけ情報を拡散して知ってもらうか……市場価値を高めるための双方向のコミュニケーションを考えると、戦略的に宣伝することが同じぐらい大事です。

Webサービスを作っていてもそうなんですが、いくらいいものを作っても、例えば営業や広報やマーケティングなどがきちんと人に伝えないと、誰も見てくれないですし、誰も「いい」と思ってくれません。だから、「宣伝」というとあれなんですけど、とにかくこのアウトプットと同じぐらい、知ってもらったり使ってもらうというところをがんばって努力するのは大事ですね。

ネガティブなトレンドや揚げ足取りのようなコメントを受けた時に、自分が昔どう考えていたかというと、もちろんそれは嫌なのと、技術的にそう言われないようにしようと努力をしていました。もう1つは、コメントをしてくれるだけで別の可能性がないかということをちゃんと考えてみると、意外と良いことを言っている口の悪い人もいるわけですね。

ですので、本当にネガティブなことを言っているだけなのか、実は良いことを言っているのかをちゃんと考えることは大切です。フィードバックはすごく大事です。アウトプットした結果帰ってくる情報をどれだけ咀嚼するかですね。

あとは、宣伝についてお話すると、カンファレンスの後にはみんな感想を書くと思うんですが、ああいったことにちゃんと乗っかっていくことですね。

例えば僕もそうだったんですが、自分の持っているスキル以上の質を作ろうとするとすごく時間がかかってしまいます。その結果なかなか継続できなくなってしまって、継続できないと人は簡単に忘れてしまうので知られなくなってしまいます。ですので、やはりまずは量を質に転化していくことが大切だと思っています。

先ほども言いましたが、量を知っていると、ある時知っている知識の中から別のアイデアが創発的に生まれて、 それが質に繋がっていくので、その意味ではやはり量をこなしていくというのが非常に重要です。

登壇も、アウトプットをして訓練していると、おしゃべりするときも自分の考えを口に出せるようになります。そういうことを日々のアウトプットを通じて訓練しておくと、登壇の機会も有効活用できるようになります。

ですので、アウトプットをすることによる学習法と、インターネットを通じて自分を知ってもらうということは分けて考えたほうがいいです。知ってもらうためのアウトプットをしても、そのアウトプットを量的にしなければなかなか効果はありません。前提として、アウトプットは学習法としてコツコツとやっていくべきだと思います。

そして、ちゃんと宣伝をしながら続けていくと質に繋がりますし、これも「awesome!」と言いたかっただけなんですけど……。

（会場笑）

多面的な判断から創発的に生まれるものが「質」なのではないかと思います。これは感覚的なものなので参考にしていただければと思います。「量と質ってなんだろう？」と考えた時、こういう側面があるのではないかと思います。

社内の取り組みを自分の実績に重ねる

次に、「社内でエンジニアをやっている人がプライベートの時間で書くのは大変だから、やろうとしてもできない」ということに対して、どうすればいいのかを自分の経験から整理してみました。

プライベートでやるのはすごく大変なんですよね。僕も会社を辞めて大学に行っていたときは、会社に行かなくていいからすごく暇で、ずっとアウトプットできたんですけど、会社に行きだすと、会社に8時間……下手をしたら（残業時間が）2時間とかで、その後の深夜に家に帰って書くなんてことも、質の高いアウトプットをするのも難しいです。

先ほどの発表にもあったとおり、社内の取り組みをどうにかしてアウトプットにつなげるというのが、けっこう大事ではないかと思います。いろいろと（外部に）出したらダメな情報もあると思うんですけど、ここで盲目的に「公開したらダメ」と思わないようにしていただきたいんです。とくに（スライドの）下の2つですが、出せる情報や出せない情報は明確にあると思います。

これから話しますが、技術的解決のようなことをしないといけないとき、直接的にプロダクトのビジネスロジックみたいなところをどんどん触っていくようなものに対して、もう少し抽象化を重ねて解決していくという方法があります。その「抽象化した技術はアウトプットしやすい」という話をしたいと思います。

技術や課題を抽象化して解決する

もうずっと言っていることなんですけど、なにかを解決するときに、直接いろんなところを触って解決していくと、ある場所がおかしくなったときに、またそれを全部書き直さないといけなくなるんですよね。

コンピューターサイエンスやインターネットもそうですけど、いろんなプロダクトはレイヤーを重ねていきます。そこは抽象化されているから、そこに問題があっても、そこだけ変えればいい。そこが古くなっても、そこだけ置き換えれば、全体としては成立するんですね。

とくにオープンソースで変化についていかないといけないようなプロダクトでは、そういう抽象化がすごく重要です。つまり、「抽象化しないといけないよね」という話です。

そうすると、「抽象化した情報」はビジネスロジックというよりは、ビジネスロジックが細かく小さくなったもので、他の（大半の）ところは全部抽象化されて、自分たちの課題だけではなく、世の中の人がみんな課題に思うような技術になっていくところが多いため、そういう意味で、開発リソースや開発のコミュニティは、一緒に開発できるわけですね。

いま言ったとおり、抽象化させていき、そこをどんどん組み合わせられるようなものは、変化させやすいんです。

それがメリットなんですけど、「デメリットは何なのか？」というと、やっぱり抽象化は、直接やるよりも時間もかかるし、頭も使うし、コストもかかる。会社の状況で、とにかくすぐに直さないといけない状況では、なかなか時間をかけるのは難しい。

僕がいろんな会社でずっと言っていることですが、難しいからといって、常に短期的解決でやっていると、いずれそれが大きな負債になるんです。「負債」という言葉はあまり好きではないのですが、つまりプロダクトが硬直化しちゃうんですよね。

あるときになにかを変えたくなっても、ここを変えたら全部変えなきゃいけないし、時間もかかるからみたいなものが常にあると、そのプロダクトをいじられなくなって、イチから全部作り直しになり、結果的に、お客さんも自分たちも、すごく疲弊してしまいます。

だから、ある程度うまくバランスを取らなきゃいけません。これは、上司の役目でもあると思います。

ということで、抽象化かつ疎結合にして、変化に強くするというのは、いまの技術的にはかなりやるべきことになっていると思います。

抽象化に向けて大切なこと

そうすると、抽象化した話はアウトプットしやすいですし、@pyama86さんみたいな上司がいると、「うんうん」とすぐに聞いてくれると思うけど、あんまり理解できていないときなどに、ちゃんとそれを伝えてあげるというのは、僕らエンジニアの役目だなと思います。

エンジニアの僕らもちゃんと勉強して、抽象化を短時間でしっかりやれるように勉強する必要があります。

その抽象化の取り組みは、だいたいアウトプットできるようなことがほとんどなので、ちゃんと技術的に説明して、「長期的にはこうなる」というメリットや、「ここでやっておかないと本当にまずいです」という話をきちんと説明することが重要です。

この業界では、課題意識がかぶっている面もあるため、こういうサイクルを回すと注目もされやすいですし、内容もおもしろいものになります。

上司の話もしましたが、上司はそれがわかるように日々勉強しないといけないし、最近エンジニアリングマネージャーと呼ばれるような人たちは、きちんとこれを理解できるようにしないといけないです。

こうした技術投資をしたり、エンジニアの技術的な成長も投資だと思うんですが、これをうまくバランスを取って応援する。そういう上司がいると、抽象化もしやすいですし、アウトプットもしやすくなる。そういうサイクルが回るわけですね。

好きな技術の方が抽象化しやすい

これは追加的な話ですが、抽象化するところが好きなほうがやりやすいという話です。得意な場所をまず抽象化していけばいいということで、そのほうが説得もしやすいです。そういうサイクルを回すということですね。

好きなことだけをやればいいかというよりは、やりたい目的が好きなものだと、そのなかにある面倒くさいこともがんばれるんです。だから、これは大事なポイントなのかなと思っています。

アウトプットするためにというわけでもないんですけど、こういうサイクルを回すと、技術も抽象化されて正しい感じになっていきますし、そういう技術はアウトプットもできる。そうすると、自分がアウトプットした結果、宣伝になって、注目されてというサイクルが、どんどん回せていきます。

だから、こういうサイクルをうまく回していくとプロダクトもよくなるし、エンジニアもアウトプットして成長しやすくなるし、市場価値も上がる。ここで話したかったことは、こういうことです。

ここでようやく、世間一般でいうところのすごくなったエンジニアが「アウトプットしろ」といっているところに行きつきます。そういう人たちは、実際にやってみて、注目してもらって、影響力のある人がリツイートなどをして拡散してくれたから、楽しくなってどんどんサイクルを回している。実際にやってきたことというのは、だいたいさっきいったようなサイクルを回してきたんです。

そうして僕らも成長してくると、どんどん注目されて、楽しくなって、サイクルも回しやすくなるという感じですね。これがどんどん、サイクルがawesome的に成長していく感じです。

（会場笑）

アウトプットに近道はない

まとめますと、まずアウトプットは思考と実践をつなぐ方法論の1つであり、これは飛び道具ではないので、日々きちんとやりましょうというところです。最低でも月に2、3回ぐらいはちゃんと書いて、1年以上続けるとか……いろいろと目標を作ればいいと思いますが、そんなに簡単に成長するという話ではないです。

量を積み重ねると、そこから創発的に質が生まれるという話です。同時に、インターネットがあるので、アウトプットをするなら、ちゃんと市場価値につながるように宣伝して、フィードバックして、市場を巻き込んでみんなと成長していく。それが効率がいいです。

そして、実績です。社内外での実績を重ねるという話については、やっぱり好きなこととアウトプット、社内の取り組みをうまく重ねて、さっきお見せしたサイクルを回していく。上司はちゃんとそのあたりを理解することが大事です。

おまけです。

僕のアウトプットを「月に3回」と書いたんですけど、過去を振り返ってみてどれぐらいやっていたかというと、このあたりは大学生ですごく暇だったので、かなりアウトプットしているんですよ。暇だからいつでも書けるんです。

2015年ぐらいで社会人になってペパボに入って、1年目は僕も気合いが入っていたので、月4回ぐらいですかね、いっぱいブログを書きました。そこからちょっと減ってはいるものの、月に1回は必ず書いています。

でも、そこはいまは「ちゃんと質のいいブログを書こう」ということで、ちょっとえらそうな感じなんですけど、そう思ってやっているのが現状です。

以上になります。ありがとうございました。

（会場拍手）