各種ID「kwappa」という、“w”が入るのがポイントですが、読まなくてよいです。ドワンゴの技術コミュニケーション室というところにいます。技術コミュニケーション室は、エンジニアの生産性を上げることをミッションにしていまして、採用や育成、技術広報なんかをしてます。いう場に出ているのは、「ドワンゴではこんなことしてますよ。よかったら一度遊びに来ませんか?」ということを伝えるのがミッションだったりします。実は「こういう場でしゃべるときには会社紹介をしろ」という定石があることを最近知りましたので、ちょっと会社紹介をさせていただきます。ドワンゴは「ネットに生まれて、ネットでつながる」という謎のキャッチコピーのもと、いろんなサービスを展開しております。(会場笑)一番有名なのがニコニコ動画に代表されるniconico系のサービスなんですが、その他にスマートフォン向けに音楽や映像、ボイスなんかを配信しているサービスがあったりします。最近は、ガチの通信制の高校を始めました。2016年に開校して、僕は実はそこの生徒でもあります。いま一生懸命勉強して、今年卒業しないとカッコわるいなという状態です。それから右側はバーチャルキャストです。今年の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だとメモやスティッキーズがありますが、すこし探すといいものがあります。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円ぐらいの買い物をしてきました。そのぐらいアウトプットをすることと、そのフィードバックを受けるというループが盛り上がっているので、今度は来年の春にあるそうなので、気が向いたら行ってみてください。いうことで、まとめとしては、アウトプットをしましょう。それから、謙虚に、でも萎縮せず。言いたかったのはこれだなと気付いたので、まとめに入れておきました。三方よしを目指すというのは何かというと、自分にも、それから自分のまわり、会社にもよい。「あいつ、アウトプットばっかりして仕事してねーじゃん」というのは、それはよろしくないんですね。自分のアウトプットが会社のメリットにもなるように心がけましょう。いうアウトプットを続けているときっと世間にもよいので、自分によい、自社によし、世間によしと、三方よしというアウトプットを目指していただければなと思います。いうわけで僕の話は以上です。ありがとうございました。Portfolioは、成長し続けるエンジニアを支援するポートフォリオサービスです。あなたの経歴や経験、作品、成果をまとめて、誰でも簡単にハイクオリティなポートフォリオを作成できます。11:35スピーカーの話が良かったらいいねしよう!ForkwellForkwellに関する記事をまとめています。コミュニティをフォローすることで、Forkwellに関する新着記事が公開された際に、通知を受け取ることができます。