アウトプットとポートフォリオの重要性
（注：当日、福岡から東京に来て登壇する予定でしたが、体調不良の関係で急遽福岡からリモートでの登壇になりました）。
松本亮介氏（以下、松本）：ご紹介ありがとうございます。今日は本当にすみません。3日くらいずっと寝てて、3日くらい寝たら治ると思ってたんですけどなかなか治らなくて。ですので今日はリモートで発表させていただければなと思います。
まずアウトプットの重要性の前に、自分がどういう体験をして、「アウトプットが重要だ」「ポートフォリオが重要だ」と気づいていった経緯についてお話します。
ですので、まずは自分の体験を簡単にお話しさせていただいてから重要性を検討したほうが話として伝わりやすいかなと思ったので、そんな構成にさせていただきます。
僕についてご存知の方がいるかわかりませんが、GMOペパボでチーフエンジニアをやっていて、同時にペパボ研究所もやっています。
ちょうど9月末が最終出社日でして、10月末まで一応ペパボ所属なんですけれども最終出社日は終わってまして、ペパボは退職することになっています（注：イベント開催日は2018年10月9日）。ですので、今はForkwellの技術顧問1本ということで、全力でお手伝いしたいと意気込んでいたんですが、出だしがいきなりこんなことになって大変恐縮です。
もともとForkwellのPortfolioを触っていて、すごくいいサービスだったということと、自分が求めているものに一番近い、未来を感じるところがあったので、「Forkwellと一緒になにかやりたいですね」と言っていたら一緒にやれるようになったという大変ありがたいお話です。現在は、Portfolioをどうするか議論させていただくなど、いろいろやっているという状況です。
Forkwell Portfolioに見る松本氏のスキル
実際、最初に自分のGitHubに連携させてポートフォリオを見たときに、「人類を超越したCの神」みたいな感じで。これは大変嬉しかったです。
ここに書いていることは当たっていて、2012年というのはアプリ組み込みや機器組み込みのmrubyを使い始めました。mrubyがリリースされたのが2012年の4月で、ちょうどそこからmrubyやRubyにハマり出し、それがきっかけですごくRubyのコードを書きだしました。Cについてはずっと書いていました。
そういうこともあり、2012年からはRubyをガシガシ書きだしました。そこで一旦博士課程に行ったんですが、書きだしたという意味でわりと当たっているなと感じました。
真ん中あたりの解析を見ていると、「土日はほかの人より明らかに多くのコードを書きます」とか「深夜はほかの人より明らかに多くのコードを書きます」というのはまさに家族に迷惑かけている感じなので、逆にこれを見て、もう少し家族の時間を大切にしようと思いました。このあたりはとてもいいサービスだなと思いました。
ngx_mrubyは本当に便利です。自分がやっているリポジトリで、ngxをRubyで拡張するソフトウェアなど、諸々のことをやっています。
そして、「デフォルト好きのVimユーザー」ですね。これは何をしたらデフォルト好きじゃなくなるのかちょっと楽しみなんですが、そんな感じのことが書いています。
先ほど言ったとおり9月28日にペパボを退職しているので、10月末まで所属はペパボですのでペパボの宣伝というと変な感じがしますが、退職エントリを書きました。とてもいい会社なのでみなさんぜひ目を通していただければいいなと思います（注：GMOペパボ株式会社を退職しました）。
アウトプットし始めた理由
では、さっそく本題に入りたいと思います。僕は自分がアウトプットをしないといけないと思ってアウトプットをしだしたというより、アウトプットの流れに乗っているうちにアウトプットの意味を理解できたというか体験できたというところがありました。まずはその体験についてお話をさせていただきたいと思います。
今から遡ること6年。現在34歳なんですが、6年前なので28歳で一旦会社を辞めて博士課程に入り直しました。
現在、オープンソースソフトウェアとしてコードを公開しながら開発をすることは当たり前になってきています。これはWebに携わるエンジニアにとってはよくあるやり方です。ソフトウェアを開発してそのソースコードをGitHubで公開するのは当たり前だという考え方は、6年前でも当然のようにありました。
将来性があれば、まだ完成していなくても未成熟な状態からどんどん公開していって、それをブログに書いて徐々にフィードバックをもらいながらコミュニティとして作りあげていく。そんなことがされていました。
僕の場合は、一応ビルドは通るけれど、通ってもまだ何に活用できるのかわからない状態からオープンにしてやっていくということを、当時はやっていました。
自分や社内だけでなく、他人や社外や業界といった大きなコミュニティとして開発運用が可能になっていくことには、単純なメリットが存在していると感じています。
博士課程で感じたギャップ
一方で、僕が博士課程に入って一番驚いたのは、そもそも前職は技術をオープンにするには許可が必要だったりなど、あまりやりやすい環境ではありませんでした。
そこで、オープンに研究開発をしたいということで会社を辞めて大学に入り直したんですが、オープンに学術研究することは、実は意外と難しかったりします。
例えば研究なので論文を書くんですが、論文を書くまでにいろいろなアイデアや実装が出てくるわけです。サービスを作るにしても、サービスの完成品にもっていくまでにいろいろなノウハウやツールの使い方、公開したいことがたくさん出てくると思います。
それは学術研究だとなかなか公開できません。論文の形まで完成させて、初めて公開するということが当たり前になっていました。これは困りました。オープンにやりたいという目的で大学に入り直したにも関わらず、なかなかできないという現実がありました。
mrubyが出たということもありましたし、オープンソースのようなオープンにどんどんやってコミュニティでいろんな人にフィードバックを受けながら進めるという開発の仕方に漠然と魅力を感じていました。僕はそういう感じで研究をし始めたわけです。
そうすると、わりと怒られるというか、批判を受けるわけですね。例えば知り合いの研究者からDMとかが飛んでくるわけです。「研究家はそういうやり方しない」とか「論文にならないぞ」とか「研究実績にならないぞ」とかすごく言われるわけです。
「論文を書いてるのに、そもそも途中のネタをどんどん出したり、論文に書こうとしているネタをオープンにするのって何の意味があるの？」みたいな。「バカなの？」みたいな感じで批判を受けたわけです。
ですが僕は論文を書くために研究をしたかったわけではなくて、もっといいソフトウェアを作りたいという気持ちがありました。ですので、自分自身の研究をオープンにすることがなぜ間違っていると言われるのか、非常に疑問を感じていました。
つまり、間違ったことはしていないから、怒られたとしてもその研究をオープンでやっていこうと思っていたわけですね。やりたいようにやりたいなと思っていました。
自分を救った恩師の言葉
ですが、やはり自分より経験がある人がそういうことをおっしゃってくるのでずっと胸に引っかかるものがあって、なかなか前向きにはやれませんでした。
そんなときに、自分の指導教員にその話をしてみて、「実際どうなんですか？」と相談ベースでお話ししてみたら、このように言ってくださいました。
「昔のやり方に囚われなくてよくて、僕が良いと思うやり方で好きなようにやればいい」と。同時に「今のやり方はいいと思いますよ」ということをおっしゃっていただけて。
これだけ見るとすごく単純な言葉なんですが、今振り返ると、これは僕の研究分野であるということや、僕のモチベーションの持ち方など、そういうものを含めたいろいろなことを考慮しての発言だったと思います。
単純にそんな言葉だったから僕もすごく救われて、やっとオープンに研究開発ができると思いました。そこから、自分のやっていることを隠すよりも、やったらそれを当たり前に外に出していく。ブログにも書くし、それが広がっていくと嬉しくなるみたいな。そんなことをやり始めました。
研究をオープンにして得られたこと
最初は単純にオープンに研究することがなんとなくかっこいいというか、憧れがあったところから、批判はありつつも実際にやり出してみると、すごく楽しくなりました。
いざやってみると、徐々にフィードバックが増えていきました。最初は書いても書いても3はてブくらいしか付かなくて。3だと新着カテゴリーにも入らないくらいの数なので誰も見てくれませんでした。
ですが書いていくうちに、たまに有名な技術者に引っかかるとその人がバーっとツイートしてくれたりして、そこからすごい勢いで広がっていきました。これが2012年、2013年くらいの話です。
当然、中にはネガティブなコメントとかもあるんですが、技術はフェアというか平等なものなので、技術的にネガティブなことを言われるんだったらそれを見返すために、技術的にさらにいいアウトプットをしようと思いました。
そもそも大きな目標があるので、そうしたネガティブなコメントに対していちいち反応してられないなと思いました。逆に、それを技術で押し返していこうと、どんどんやっていったわけです。
するとその連鎖が徐々につながっていって。あるときいきなり講演依頼のメールが来たりするわけです。それが学術や企業での評価にどんどんつながってきて。
そのつながりを徐々に認識しだすとそれがすごくおもしろかったので、ただひたすらゲームのような感じでどんどんアウトプットをし続けました。
例えば、ゲームの物語を楽しみながらどんどんレベルが上がっていく状況というのは、レベルを上げていること自体をそれほど気にしないと思います。あるときラスボス前になるとすごくレベルアップしてるわけですね。振り返ると大きな成果になっていたんです。
それと同時にずっとアウトプットしていて、そのアウトプットを通じていろんな人と関わりを持ったり、いろんなコミュニティと関わりを持って情報が入ったり出したりしているうちに、なんとなく自分の立ち位置が見えてくるようになりました。
自分を最も活かせる分野が明確になる
例えばMatzさんなんて芸能人よりも遠い、本当に夢のまた夢みたいな人だったわけですね。でもなぜかそれが、mrubyに触る中で一緒にトークセッションしたり、オープンソースの開発の中で議論したり。
最初はちょっと怖かったけど、徐々にやっていく中で強い技術者がどんどん集まってくるわけです。その中に自分は置いていかれてるけど、みんなやってる中で自分も追いつけるようにがんばろうと思って、勉強しながらそういう人たちについていくと、すごい速度で知識が得られるわけです。
自分1人でやってるときや自分が相対的に高い位置にいるコミュニティでやっているときと比べると、なにもかもが自分の為になる。そうするともっと学びたいことが増えていきます。
さらにそこでやっている人たちは情熱の塊みたいな人ばかりで、「コード書くの楽しい」とか「とりあえずプルリク書くぞ」とか「プルリクを出すのが楽しい」とかそんな人たちばっかりで。
その情熱みたいなものが勝手に自分にも飛び火して、自分もこの人たちと一緒に世界を変えているんじゃないか、みたいな、そんな気持ちにさえなりました。
情熱みたいなものがどんどん増幅していくわけですね。気がつくと自分はコードで世界を変えている気分が常にありました。
なんとなく情熱と自分の立ち位置が見える中で、自分にとって遠い存在でその遠さもわからなかったところが、徐々に自分の得意分野がどこで、その分野における世界のトップレベルの人たちと比べて自分がどれくらい足りてないのか、少しずつ見えてきました。
逆にこの分野だったら自分はうまく戦えているから、この長所の部分を伸ばしていくとひょっとすると世界一になれるんじゃないかとか、そんな夢みたいなものも出てくるわけですね。
トップレベルの技術はどうかとか、人はどうかとか、企業はどこなのかということがどんどん明確になる。そうすると自分が生きていく道というか、自分を一番活かせる道がかなり明確になってきました。
アウトプットというのはいろんな自分のスキルを外に出していくわけなので、脳の中にふわっといろんな情報がある状態では整理できないものが、ちゃんとアウトプットすることによって、徐々に「なんとなく」から、自分の道はここで、ここだったらいけるんじゃないかというのが少しずつ明確になっていきます。
なので、昔感じていたトップレベルに対する自分の差みたいな、漠然としたすごさみたいなものが、差があることは変わりませんが、より明確になって夢じゃなくなってくるんですね。
この経験から、最初は憧れでアウトプットをやっていたんですが、振り返ってみたときに常にアウトプットするということは芋づる式にいろんなものにつながっていくということをすごく感じました。
エンジニア目線でのアウトプットの効果
そんな体験があったわけなんですが、ここからペパボに入社してエンジニアリングしたり、研究開発したり、人事系の採用や評価など、会社でのプレゼンスも向上する中で、これまでの経験を自分なりに整理してみました。
これはペパボ辞めたからこそよりフェアに話ができるかなと思っているのでいい機会だと思うんですが、まずはエンジニア目線でアウトプットの効果をまとめます。今ではアウトプットの効果を話す人が増えてきたので、おさらいになってしまうかもしれません。
やはり先ほどの体験でもあったとおり、自分のスキルの明確化と再認識、周りを巻き込むことができる、先を予測できるようになるという3つがポイントです。
いろいろやって漠然と自分の頭の中にあるノウハウだけだと、どうしても情報を処理し切れないというか。そこから自分に何が足りてなくて、次に何をやるべきかみたいなものは、そのままにしておくといずれ記憶からなくなっていきます。
そうしたモヤモヤした知識や経験はなかなか自分でうまく整理できません。人によってはできるかもしれませんが、僕の場合はできなくて。
日々整理してアウトプットしていくことで、自分のスキルの明確化や深い理解、足りないところがどこなのか。「あ、このあたりはちゃんと理解できていないな」というところが明らかにわかるようになりました。
不足箇所も認識してそこを学習できるということ。アウトプットの効果の1つ目です。
アウトプットは周囲を巻き込む
2つ目は、これは副次的ではありますが、アウトプットするとそれがどんどん周りを巻き込むことになるということです。
アウトプットをしつつスキルが上がって、そのスキルに応じたよりレベルの高いアウトプットができるようになると、それがいろんな人を巻き込み、どんどん情熱が飛び火して継続的に取り組むという。
1人では大変だったところを2人でやるとやり続けられるという。周りを巻き込んで結果につながっていくのをすごく感じました。
3つ目ですね、これは1つ目とすごく近いんですが、そうやっていろいろと整理していくと、その果てにアウトプットが徐々に自分のスキルに対するストーリーみたいなものになっていきます。
アウトプットして細かく自分のスキルをブログなどに書いていると、僕は今でも昔のブログで自分のやったことを調べたりして、それをもとにいろいろやったりするんですが、それが自ずとストーリーみたいなものになっていきます。
そうすると、自分がこの先目指す道ややりたいこと、「自分はこれがやりたかったんだ」「ここが得意なんだ」というところが徐々にわかっていって。その先の取り組みも意識的にやれるようになるんじゃないかなと感じました。
僕はエンジニアとしてもやっていましたし、評価や採用もしていました。今だからこそすごくフェアに言えますが、1時間の採用面接1つをとっても、それだけで見抜くのはすごく大変なんです。
例えばスタンフォード大学では、ポスドクや助教を採用するときは3日間かけて朝から晩まで採用プロセスをするわけです。
自分の専門分野の先生と数時間ディスカッションしたあとに、学生と数時間ディスカッションして、次はぜんぜん関係のない専門分野の人とディスカッションして、みたいなことを3日間くらいやったりするという話を聞きました。
単純に短時間で採用することは相当大変なんです。でも、時間の兼ね合いもあるので短時間で見抜かないといけません。そうなったときに、やはりアウトプットがある、ポートフォリオがあるというだけで、採用する側も評価される側も可能性を大きく上げられるわけです。
採用する側も評価する側も完璧な人間ではなくて。人間なのでなかなか適切な採用や適切な評価は難しいです。ですが、できるだけそこに適切な評価に乗せられるようにアウトプットをしておくのは当たり前ですが大きなポイントでした。
その中で、僕はスキルはもちろん、何ができるのかを見ているんですが、それに加えて下の3つをとくに重要視しています。
実績から客観的な価値。「なにかできました」と言うだけではなく、それが客観的に見てどれだけ価値があることなのか。その実績を通じてどれだけ周りの人に影響を与えて動かしてきたのか。
あとは、技術は変化するのが当たり前なので、どんどん環境が変わっても普遍的に活きるその人の強みは何なのか。この3つを見抜きたいなと考えています。
最終的にForkwellのPortfolioにつなげるとなんかやらしい感じがしますが、本当にそういうわけじゃなくて、個々のアウトプットとそれをストーリーとしてつなげたものがポートフォリオであると僕は思っています。
ポートフォリオとは、アウトプットを使ったストーリーである
今、人事目線でアウトプットで見たいことを3つ挙げました。客観的な価値を主導できるのかとか、どんな影響を与えたのかとか、環境が変わっても活きる強みというところ。
ここをアウトプットとポートフォリオというストーリーの中からうまく主張できるといいんじゃないかと思います。人事面でもそうですし、エンジニアとしてのキャリアを考えるうえでも同様にここができるとすごくいいんじゃないかなと思います。
また、アウトプットやそのストーリーから、その人の特筆すべき汎用的な力が見たいです。会社も変わるし、技術もどんどん変わっていくし。ずっとコード書かなくてよかったのが、急にコードを書かなきゃいけなくなったとか、常に変化を求められるところでいかに結果を出せるのかというところ。
何に熱中しているのか。その熱中している理由や、なぜそういうことをしだしたのか。そんなところにけっこう僕は興味があるし、わりと大事なポイントなんじゃないかなと思います。
ということでざっとまとめますと、こんな感じです。
アウトプットを永続的に残すという意味でもありますが、ポートフォリオはアウトプットを使ったストーリーでもあると思います。
エンジニア目線でそのストーリーに基づいてスキルを上げたり、人事目線では普遍的なスキルを人事に伝わるようにうまく表現できるといいなと思っています。
それもみなさんがどんどんアウトプットしていくことで、業界やコミュニティが活性化していくことにつながるんじゃないかと思っております。以上です。ありがとうございました。
（会場拍手）
