伊藤淳一流「効果的アウトプット」の極意。これでどこにでもいる平凡エンジニアが有名ITエンジニアになれた

前回および前々回では、筆者のこれまでの経歴を振り返りながら、読者のみなさんのキャリア設計やスキルアップに役立ちそうな情報をいろいろ書いてみました（まだ読んでない方はそちらもぜひ！）。最終回となる今回のテーマは、ズバリ「ITエンジニアのアウトプット」です。

決して「有名になりたい」とか、「本を出してお金持ちになりたい」といった動機はなかったのですが、なぜか筆者はRuby界隈を中心に、日本ではそこそこ有名なITエンジニアになっていたり、「プロを目指す人のためのRuby入門」というRubyの入門書を出したりしています。

プログラマ・ITエンジニアとしての実績（2023年9月現在）

人によってはもしかすると、筆者の今の状況を見て「伊藤さんってどうして本を出せたりするぐらい、すごいエンジニアになれたんだろう」と不思議に思っている人がいるかもしれません。その疑問にひとことで答えるなら「がんばってアウトプットしてたから」ということになるでしょうか。しかし、漠然とアウトプットするだけでは、今のような状況にはなっていなかったと思います。

そこで、今回は筆者自身が考える「効果的なITエンジニアのアウトプット」について書いてみようと思います。

なお、今回の記事では「アウトプット」の定義を「ITエンジニアが技術記事を自分のブログやQiita/Zennに書くこと」とします。もちろん、技術記事を書くこと以外にもさまざまなアウトプットの形態が考えられますが、この記事の中ではとりあえず「アウトプット＝技術記事を書くこと」とさせてください。

• keyboard_arrow_down アウトプットは自由！だが……
• keyboard_arrow_down WIIFYとgiverという2つのキーワード
• keyboard_arrow_down アウトプットは「インターネットへの恩返し」
• keyboard_arrow_down 直接的な金銭ではなく、レピュテーションという無形資産を貯める
• keyboard_arrow_down コラム：鉄は熱いうちに打て。記事も熱いうちに書け！
• keyboard_arrow_down まとめ：運と努力と勇気が成功の秘訣？

まず、「ITエンジニアのアウトプットはこうあるべき」という絶対的なルールや指針はありません。「なぜアウトプットするんですか？」とか「どれくらい時間をかけたらいいですか？」といった質問をエンジニアにしたら、十人十色の返事が返ってくるはずです。そもそもの話として「アウトプットなんてしなくてもよい」と答えるエンジニアだって中にはいるでしょう。ですので、基本的にはアウトプットは自由ですし、万人が納得する「正しいアウトプット」や「間違ったアウトプット」があるわけでもありません。

とはいえ、筆者がここで「アウトプットは自由です。みんな好きなように書いてください。以上！」で終わってしまうとまったく実のない記事になってしまうので、今回はあくまで「筆者はこう考えていますよ」というスタンスで話をさせてもらいます。

まあ、自分で言うのもなんですが、筆者はQiitaのランキングで1位になったり、自分の名前で技術書を出したりと、それなりにアウトプットで実績を上げている人間なので、このあとに書く内容は決して「無意味な持論」ではないと信じています。

筆者がアウトプットをするときに大事にしている考え方は、「WIIFY」と「giverになること」です。

WIIFYは”What’s in it for you?”の略語で「ウィッフィー」と読みます。日本語にすると「それがあなたにとってどんな意味があるのか？」という意味です。この用語は筆者が過去に読んだ『パワー・プレゼンテーション』という書籍で知りました（ただし、この書籍はタイトル通り効果的なプレゼンテーションの方法を解説している本です）。

技術記事における「あなた」はこの場合、記事の読者を指しています。つまり、WIIFYを考えるということは「自分の記事が（自分自身ではなく）読者の役に立つことを第一に考えるべき」となります。

そして、その役立つ情報は見返りを求めず、無償で届けることが原則です。すなわち、自らすすんで与える人＝giverになるということです。

読者の役に立つ情報を無償で提供するーーーこのマインドで筆者はこれまでアウトプットしてきました。

情けは人のためならず、アウトプットも人のためならず

「情けは人のためならず」という格言があります。これは「他人にかける情けは、その人のためになるだけではなく、めぐりめぐって、やがて自分のためにもなる」という意味です*1。

これはエンジニアのアウトプットにも同じことが言えます。「人に役立つ情報を無償で提供する」というと、あたかも自分一人が損をしているように聞こえるかもしれませんが、決してそんなことはありません。

「読者のために徹底的にわかりやすく書こう」と考えながら書くと、自分が書こうとしている技術の細かい部分が気になってきます。たとえば、「たしかにここはこんなふうに動いてるけど、そもそもなんでこんな仕様になってるんだろう？この機能が実装されたときのGitHubのissueをちょっと覗いてみるか」といった具合です。「自分が読者だったらここは疑問を抱きそうだし、自分自身もちょっと気になるな」と思った部分を放置せず詳しく調べると、その技術をより深く理解できます。また、そうやって詳しく調べた内容を自分の言葉でわかりやすくアウトプットすると、自分の記憶としても定着しやすいです。

筆者はこんなふうに、アウトプットを通じてRubyやRailsに関する技術知識をたくさん増やしていきました。

※1 出典:ことわざを知る辞典 「情けは人の為ならず」の解説、コトバンク

自分のアウトプットで自分自身が助かるケースも

先ほどは「詳しく調べてアウトプットすれば記憶として定着しやすい」と書いたものの、残念ながら全部が全部暗記できるわけではありません。中には時間が経つにつれて記憶が薄れていく技術知識もあります。しかし、忘れてしまっても大きな問題にはなりません。なぜなら、忘れてしまった場合は自分で自分の記事を読み返せばいいからです。

筆者はときどき困りごとをググってトップに出てきた記事をクリックしたときに、筆者自身が過去に書いた記事に遭遇することがあります。つまり、自分がその記事を書いたことすら忘れちゃってるわけです（苦笑）。これは自分のアウトプットがそっくりそのまま自分の役に立つパターンです。

また、筆者が誰かのコードレビューをするときは1から10までコメントせずに、「詳しい話はこの記事に載ってるから読んでみて」と自分の書いた記事のURLを貼り付けることもよくやります。プログラマだったら何度も登場するロジックはコピペせずにメソッド化して再利用しますよね。これと同じで、コードレビューでよく指摘する内容は技術記事にして再利用すれば、コードレビューの工数削減に役立ちます。

良質なアウトプットを続ければ、あなたも本を出せるかも！？

そして何より、良質なアウトプットを無償で提供すれば、その人自身の評価や知名度が高まっていきます。

多くの人に役立つ記事は、はてなブックマークのホットエントリーやQiitaの週間ランキングに掲載されて、さらに多くの人の目に触れます（いわゆる「バズった」状態）。

たくさんの人が記事を読んでくれると、一部の人は筆者のTwitterアカウントをフォローしてくれたり、ブログの購読者になってくれたりします。

Twitterのフォロワーやブログの購読者が増えると、新しい記事を公開したときにリーチできる読者が増えます。そうすると、自分の記事がまたバズりやすくなります。

これを何度か繰り返すと、雪だるま式にTwitterのフォロワーやブログの購読者が増えていき、「ちょっとした有名人」になれます。

知名度が上がると、突然見知らぬ人から声をかけられることが出てきます。

「今度開催するイベントで登壇してくれませんか」
「雑誌の特集記事に寄稿してくれませんか」
「インタビュー取材させてもらえませんか」

といった具合です。

筆者は2017年に『プロを目指す人のためのRuby入門』というRubyの入門書を執筆しました。

「いったいどういうきっかけで本を書いたんですか？」といろんな人に聞かれますが、これは前述したとおり、最初は「雑誌に寄稿しませんか？」という声を出版社の方からかけていただき、何度か雑誌に寄稿したあと「今度は本を執筆してみませんか？」と持ちかけられたのがきっかけです。ですので、筆者としては「自分の本を出すためにこんなに努力してきました！」という感覚は皆無で、アウトプットを繰り返していたら、向こうから出版のお誘いがやってきた、という認識です。

さて、こんなふうにアウトプットの効能をあれこれ書いていると「なるほど、じゃあ自分もちょっとアウトプットしてみようかな」と思い始めた読者の方もいらっしゃるかもしれません。しかし、実際に着手してみると……「めちゃくちゃ時間がかかるやん！！」と驚かれるのではないでしょうか？

はい、いわゆる「チラシの裏」レベルの技術記事ではなく、WIIFYを意識しながら読者のために徹底的にわかりやすく書こうとすると、かなり時間がかかります。筆者の場合、短い記事なら30分から1時間、平均的な記事で2〜3時間、長めの記事だと半日から数日かけて1本の記事を書き上げます。アウトプットに慣れていない人だと筆者の倍ぐらい時間がかかるかもしれません。ひとことで言うと、「まあ大変」です（苦笑）。

アウトプットの大変さがわかると、つい、アウトプットする苦労と得られるメリットを天秤にかけたくなると思います。そのとき、天秤の腕がどちらを上げて、どちらを下げるのかは人それぞれだと思いますが、筆者はいつも「多少苦労してでも良い記事を書きあげたい」と考えます。それはなぜかというと、「読者の役に立ちたい」という思いが第一にあるからです。

これまで筆者は見知らぬ誰かが書いた技術記事にたくさん助けられてきました。たくさん助けられてきたからこそ、自分も誰かを助けたい、誰かの役に立ちたい。このようなギブアンドテイクの精神でアウトプットをスタートし、今までずっとアウトプットし続けてきました。それゆえ「この記事を書けば、きっと誰かが喜んでくれるはず」と思いながら、多少時間をかけてでも記事を書き上げるようにしています。

SNSなどでときどき筆者の書いた記事を読んでくれた人が「助かった、ありがとう！」と書いてくれているのを見かけると、「がんばって書いて良かったなあ」と筆者はしみじみ喜んでいます。自分がネット上の記事に助けられたから、自分もネット上にアウトプットする。これを筆者は「インターネットへの恩返し」と呼んでいます。

こんな感じで、惜しみなく・無料で提供したアウトプットを受け取った誰かが「素晴らしい情報を提供してくれてありがとう！」と思ってくれれば、それは自分のレピュテーション（reputation＝評価や信頼）になります。

レピュテーションは知名度を上げることとほぼイコールですが、単に有名になるだけではなく、ポジティブな評価で有名になることが重要です。有名だけどアンチも多いとか、頻繁に炎上して賛否両論を巻き起こす、というような目立ち方だとレピュテーションは貯まりません。

筆者はアウトプットで直接的な金銭を得たいとは考えてはいませんが、レピュテーションはたくさん貯めたいと考えています。第1回の記事では「突然自分の勤めている会社がなくなっても大丈夫か自問自答してみよう」という話を書きました。筆者はそれなりにレピュテーションを貯めてきたので、今勤めているソニックガーデンが突然なくなっても何かしらの形で働き口を見つけられるんじゃないかと考えています。

また、先ほどは知名度が上がると「登壇しませんか」「記事を書いてくれませんか」といった依頼が増える、という話を書きました。こうした依頼の中には、登壇料や原稿料を支払ってもらえるケースもあります。なので、レピュテーションは間接的な収入にもつながります。技術書を一冊書けば、「技術書を書いた人」という意味でレピュテーションが増えますし、それと同時に印税という形で直接的な収入を得ることもできます。

このように「惜しみなく・無料で与える人」は一見、与えているばかりでずっと損しているように見えるかもしれませんが、レピュテーションをコツコツ貯めれば、巡り巡って自分の大事な資産を築くことができるのです。

長年の執筆経験で培った、技術記事を書くための筆者なりのコツやテクニックもいろいろあるのですが、それらを全部書いていくと一冊の本ができてしまいそうなので、それはまた別の機会にお話できればと思います。今回はその中からひとつだけ、「鉄は熱いうちに打て」というアウトプットのコツを紹介します。

「鉄は熱いうちに打て」とは、「あ、これはアウトプットにちょうどいいかも」と自分の中でピンと来るネタに遭遇したら、できるだけ早いうちに記事を書き始めた方がいい、ということです。「これで一本記事が書けそう」とか「このネタを書けば喜んでくれる人がたくさんいるのでは？」といった気持ちの熱量は、思いついたその瞬間がピークです。あとは時間が経つにつれ、その熱量はゆっくり下がっていきます。そして、その熱量が一定のラインを下回ってしまうと、「また時間があるときに」を無限に繰り返して、最終的に「完全お蔵入り」となります。ええ、何を隠そう筆者自身がこんな調子で様々な技術ネタをお蔵入りにしてきました😅

もちろん、業務中などで物理的な時間が確保できない場合は仕方ありませんが、そうでなければ後回しにせず、なるはやで執筆に着手してください。いわば「勢いが大事」ってやつです。

「勢いが大事」というスローガンは「読者のために徹底的にわかりやすく書こう」というスローガンと対立するように聞こえるかもしれません。ですが、とりあえず書き始めて、書きながら詳しく調べることはできます。また、いったん公開してから、あとでわかった内容や補足説明などを追記することもできます。

本文を一定量書いてしまえば、その勢いでなんとか公開まで持っていけるはずです。しかし、何も書かないまま「またあとで」にしてしまうと、前述したとおり自分の中の熱量が徐々に下がってお蔵入りになります。

「なんか書けそうかも」と思ったらそれがアウトプットのチャンスです。とりあえず記事の入力画面を開いて「はじめに」を書いてしまいましょう！

さて、レバテックLABの連載コラム「キャリアを創る思考法」ですが、筆者＝伊藤淳一のコラムはこれでおしまいです。

筆者は知名度だけでいえば「日本のITエンジニアの中では有名な方」には入るかもしれませんが、前回や前々回の記事でも書いたように、筆者も元々はどこにでもいる平凡なエンジニアの一人でした。ですが、筆者なりの工夫や努力を積み重ねた結果、現在の筆者があります。もちろん、これはn=1でしかない個人的な体験談ですし、「今思えばあれはすごく運が良かった」と思うようなことも多いので、同じようにやっても再現性があるとは限りません。というか、ぶっちゃけ「ない」でしょう。

とはいえ、運以外の要素もあります。それは努力と勇気です。運はコントロールできませんが、努力と勇気は自分でコントロールできます。これまでのエンジニア人生を振り返ってみると、筆者はこんなステップをたびたび踏んできたような気がします。

努力は必ずしも報われるとは限りませんが、努力なしでは成功しません。また、努力するほど成功する可能性を上げられます。

何かにチャレンジするときは「失敗するのが怖い」とか「失敗したら恥ずかしい」という恐怖や恥の気持ちが沸き起こってきがちですが、そんなときは「でも死ぬわけじゃないし*2」とか「やらぬ後悔よりやる後悔」と自分に言い聞かせ、“give it a try”（やってみよう）の精神で勇気を出しましょう。特に、何かをチャレンジする上で「恥ずかしい」という気持ちはマイナスになることはあってもプラスになることはないので、「恥」は窓から投げ捨てるのが正解です。

努力と勇気のおかげで成功すれば万々歳ですが、もし運が悪くて失敗してしまったとしても、そこまでの努力はいつか思いがけないところで役に立ったりするものです。また、失敗から得られる「学び」もたくさんあります。失敗をマイナスで終わらせるのではなく、プラスに変えていきましょう。ちなみに筆者の場合は自分の失敗をブログのネタにしてプラスに変えます（苦笑）。

というわけで、このコラムがみなさんの今後のキャリアに何か役立てば幸いです。最後まで読んでいただき、どうもありがとうございました！

※2 本当に生命に関わるようなチャレンジの場合は別ですよ！