大事なのは「自分自身へのハードルをできるだけ下げること」　アウトプットの達人が贈る、良質な技術記事を量産する秘訣　

モチベーションや得意なことは人それぞれ

伊藤淳一氏：では後半にいきます。ここまで「世界を良くしたい」と話してきたわけですが、もしかすると一部の人は「なるほどな。さすが伊藤さんだわ」と思いつつ、「でもそんなことができるのは伊藤さんしかいないですよ」とか、「僕には真似ができないな、だって僕は〇〇だし」と、できない理由を考えるかもしれません。これはぜんぜん責める気はないですよ。当たり前だと思います。

モチベーションや得意なことは人それぞれだと思っています。例えば、Qiitaの1位から5位の人に「なぜあなたは記事を書くんですか？」と聞いたら、その動機は人それぞれ違うと思っています。だからそれでいいと思います。

そもそもアウトプットにもいろいろな種類があると思います。エンジニアのアウトプットというと「記事を書きましょう！」とよく言われますが、「自作のWebサービスを作りましたよ」とか「私はOSS活動をがんばっています」とか「自分で勉強会を主催していますよ」というのも広い意味でアウトプットだと思いますし、ネット上だけではなく「社内向けに技術記事を書きました」とか、「お願いされていないけど、自発的に手順書を作ってみました」というのも、いいと思っています。

僕の中でアウトプットというのは、ギブ＆テイクの関係で見た時に、自分がギブ側に回っている。もしくはコンシューマーとプロデューサーの関係で見た時にプロデューサー側、つまりモノを作る側に回っていて、その活動の結果、誰かの役に立ったり、誰かから感謝されたり、ということにつながっていれば、それは一種のアウトプットだと考えていいと思います。みなさんの得意なこと・やりやすいことから始めるのがいいと思います。

「エンジニアだから技術記事を書かなきゃ」と思うかもしれませんが、ここもそんなにこだわりすぎなくていいのかなと思っています。たまには「生活家電で最近買ったこれがすごく便利でした」というレビューや「最近見たこの映画がすごくおもしろかったです」とか「最近20kg痩せたのでダイエット方法を紹介します」みたいな話を書いてもいいと思います。

ネット上に「その話を知りたかったよ！」って思ってくれる人がいる話であれば、なんでもいいと思います。そういう人のために記事を書けば、その人たちに感謝してもらえると考えています。

（スライドを示して）というわけで、僕がみなさんに伝えたいのは「自分自身へのハードルをできるだけ下げてください」ということです。記事を書くだけがアウトプットではないですし、何が何でも技術ネタにこだわる必要もないと思っています。広い意味でのアウトプットとはギブ側に回ることで、その活動の結果、誰かの役に立つこと・感謝されることかなと思っています。

オススメのネタとよくある残念なアウトプット

そう考えると「自分もこういうことができるかもしれない」「私はこういうことが得意だな」と、なにかできるような気がしてこないでしょうか？　ただ、そうはいってもOSS活動や生活家電と言い出すと話が広がりすぎてしまうので、またここからは技術記事の話に戻していこうと思います。

（スライドを示して）技術記事を書く上で、どんなネタがあるかなと、よくあるネタをリストアップしてみました。定番はトラブルシューティング系で「こんなエラーが出た。こうやったら直った」というものかなと思っています。あとはHow-To系で「こんなことをやりたい。こんな手順でやればできました」という記事ですね。

こういうのが定番ですが、ほかにもコードレビューをしているのであれば、「しょっちゅうこんな指摘を自分はしている」もしくは「こんな指摘を受けている」という話を書いてみたり、もしくは新しく出たツールやライブラリの新機能を紹介したり、「〇〇をやってみた」というタイトルで自作サービスを作ったよとか、ライブラリを作ったよとか、こんな実験をしたらこんな結果になったよ、というような記事を書いてみる。

あとは技術書の書評や、難しい技術を理解するための自分なりのアプローチで、「犬でもわかるSQL」とか「犬でもわかるオブジェクト指向」みたいな話を書いてみるとか。ほかにはエッセイで、「最近、私はこんなことを感じています、考えています、経験しました」みたいなことを書く。

それから最後に挙げたのが、イベントや勉強会の参加レポートですね。みなさんはちょうど今日この勉強会に参加しているので、「伊藤さんのこんな話を聞きました」「私はこう思いました」というのは、とても書きやすいんじゃないかなと思います。

（スライドを示して）そんな中で、こういうアウトプットはあまりしないほうがいいかなと僕が思う、ちょっと残念なアウトプットの例を挙げておきます。例えばQiitaを見ていると、「チェリー本のまとめ」という記事があって、中を読んでみると僕の本の内容がほとんど転載されているということがよくあります。

「アウトプットをして感謝されるのは大事だよ」とは言ったのですが、「あなたのおかげで本を買わずに済みました」という感謝のされ方だと、本を書いている人としてはすごく泣きそうになっちゃうので、止めてほしいなと思っています。書評はあくまで自分の感想ですね。「こんなことが書いてあって、私はこう思いました」「ここが良いと思いました」「これがわかりやすかったです」「ここがちょっと難しかったです」みたいな感想を書きましょう。

内容のまとめはほどほどにしておきましょう。同じように、記事にはなっているけれど、参考文献を見ると、ほとんど同じ内容が書かれていたり、もしくはリンクだけを載せておしまいというものもありますね。

これも1つの無断転載ですし、もう1つ大事なこととして、「自分の言葉で説明できない技術は、まだきちんと理解できていない技術だろう」という考えが僕にはあります。小学生にオブジェクト指向を説明するとして、自分の中から説明する言葉がぜんぜん出てこないのであれば、それは技術を理解できていない証拠じゃないのかなと思うので、自分の言葉で説明できているかどうかを意識してみるといいと思います。

仮想読者を決めれば初歩的な内容でも大丈夫

これはよくある質問で、「私はプログラミング初心者で、初歩的な内容しか書けないんですよ」と言う人がいますが、初歩的な内容でもぜんぜんOKだと思います。「いやいや、でも伊藤さん。私がこんな簡単な内容を書いていたら、世の中のつよつよエンジニアに『バカじゃないの？』と思われてしまいそうです」と思うかもしれませんが、そういう人たちにアドバイスしたいのは、ぜひペルソナ、仮想読者を決めてほしいなと思います。

記事の中で「私はRubyの初心者で、この記事は私と同じRuby初心者の人のために書いています」と宣言をすれば、このリーナス（リーナス・トーバルズ氏）という世界的にメチャクチャすごいエンジニアの人があなたのブログを読んで「こんな簡単なのを書きやがって」と言ってきても、「いやいや、これはあなたみたいなつよつよエンジニアのためではなく、Ruby初心者のために書いたものですよ」「"not for you"なので、おかえりください」と答えることができるわけですね。

ペルソナが明確であれば、その仮想読者の評価は多少気にするべきですが、つよつよエンジニアの評価は気にせずに書けるはずです。

オススメは3日前の自分が大喜びするような記事を書くこと

「ペルソナ」という話が出てきたのでついでに話しておくと、オススメなのは3日前の自分です。3ヶ月前でも3年前でもいいんですが、とにかくその知識を知らなかった頃の自分を思い出しながら書くといいです。

例えば、タイムマシンで3日前に戻って「これわからん、どういうことだろう」と、困っている自分に「ちょっとこれを読んでみ？　すごくわかりやすいから」と言って自分の記事を見せるとしたらどうかなと。

自分が「なるほど！　メチャクチャ簡単じゃん！」「最初からそう教えてくれたらよかったのに」と大喜びする内容になっていれば、その記事は良い記事だと思います。なぜなら世の中には3日前の自分がたくさんいますし、これからもいっぱい出てくるからです。そんな人のために役立つ記事になるはずです。

Qiita、Zenn、ブログ…何をどこに書くか？

（スライドを示して）これもよくある質問ですね。どこに書くかという問題です。Qiita、Zenn、ブログとありますが、僕は使い分けしています。基準はこんな感じです。Qiitaの場合は、もちろん技術ネタしか書きません。記事の主役は技術で、私見はなるべく弱いほうがいいかなと思っています。

それからQiitaやZennにはガイドラインやルールがあるので、そのルールを守りながら記事を書く必要があります。イメージとしてはみんなの公園かなと思っています。

ブログやnoteは技術ネタに限らず生活のネタでもOKだし、主役は自分です。強めの私見でもOKだし、Qiitaはルールを守ろうと言いましたが、ブログだったら「俺がルールだ！」と言ってしまっても問題ありません。イメージは自分の庭かなと思っています。

僕はこの2つの基準で「このネタだったらQiitaかな？　このネタだったらブログかな？」と考えるようにしています。よく初心者の方で日々の学習記録を（Qiitaに）書く人がいますが、どちらかというとそれはブログに書くほうが向いているのかなと思いますね。

（スライドを示して）その学習記録と同じ感じで、よくQiitaとかで見かけるのが自分用メモです。「Ruby（自分用メモ）」みたいな記事をよく見かけます。これは公開すべきか、公開しないほうがいいのかという話ですね。僕自身は、そういった個人用メモ・自分用メモは非公開です。書いていますが公開はしません。なぜなら、わかりやすく書いておらず僕のポリシーに反するからです。

ちなみに僕はQuiverというMarkdownエディタを持っていて、そこに自分用のメモをいろいろ書いています。非公開だからといって無価値というわけではありません。自分用のメモなので自分の役には立ちます。ただ、自分用メモという建て付けで書いていると、他の人の役に立つかどうかはちょっと不明です。僕は公開はしませんが、もしそういうものも公開したい場合、僕だったら自分の庭であるブログに書くかなと思っています。

きれいに書き直せばQiitaでもいいのではないかと思います。これはQiita公式の意見ではなくて僕の個人的な意見です。そんな感じで僕は考えています。

まずは実践してみよう

ここまで、アウトプットに関する話をいろいろしてきました。ここからみなさんに実践していただきましょう、ということで実践編です。「何の話だ？」ということなんですが、今日この勉強会でアウトプットについて話をしたので、この週末になにか記事を1つ書いてほしいなと思います。「私はこんな記事を書きます」と宣言をTwitterにぜひツイートしてください。

（スライドを示して）何を書こうか悩んでいる人は、このリストを思い出してください。「最近あんなエラーが起きたな。あれはこんなふうに解決したな」とか「最近コードレビューであんな指摘を受けたな」という話をぜひ書きましょう。技術系のネタじゃなくてもいいですよ。「最近買ったダイソンの掃除機がすごく便利だった」というのもOKです。

一番簡単なのは今日の勉強会の参加レポートですね。これが一番簡単ですが、なんでもいいです。ぜひ、こんなのを書きたい・書こうと思っているというのを宣言してください。スペシャルボーナスを勝手に企画してみました。記事を書いて、書き終わったらそれに#MeetsProのタグを付けてTwitterにシェアしてください。僕がそれを見つけたらリツイートします。

僕はフォロワーが1万人以上いるので、ふだん読んでもらえない記事が読んでもらえるチャンスかもしれません。一応期間限定で考えていますが、いつ終わるかはよくわからないです。僕の気分で終わりますから（笑）。早めに記事を公開してください。

みなさんもアウトプットにレッツトライ

というわけで、長々としゃべってきましたが、本日のまとめです。今日は「良質な技術記事を量産する秘訣」というタイトルでお話ししました。質と量があって、質より量なのか・量より質なのかではなく、質と量を両立する秘訣があるかなというお話をしてきました。

もう何度もお話ししているとおり、僕は「知見を共有して困っている技術者を助けたい、技術者の世界を良くしたい」と思っています。「これは絶対同じように困っているよな」と思ったら記事を書かずにはいられないので、量が増えていきます。嘘はつきたくないからメチャクチャ調べるぞと、わかりやすく書くぞということで質が上がります。つまり最初に挙げたモチベーションが僕にとっての秘訣になっているというか、記事の質と量の両方に寄与していると考えています。

だけど、こういうことができるのは全員だとは思っていません。モチベーションや得意なことは人それぞれなので、自分の得意なことをやりましょうというお話をしました。OSSや社内限定でもいいと思います。少なくとも何かしらギブ＆テイクのギブする側に回る。誰かの役に立つ・感謝されることをやっていると徐々に「〇〇さんすごい」と思われるようになって、評価されて有名になれるかもしれません。

N2iのみなさんからいただいた疑問にもだいたいお答えできたかなと思っています。アウトプットを始めたきっかけは、インターネットへの恩返しという話をしました。

なぜRubyを主軸にしているんですか？　という質問ですが、これは僕はぜんぜん意図していないです。今日のこの発表の中で「僕はある時を境にRubyの記事を100本書くと決めました」というような話はぜんぜんしていませんよね。

たまたま仕事でよく使うのがRuby、RSpec、Railsで、「あぁ、これは使えるぞ」と思っていっぱい記事を書いていただけです。外から見たらRubyを主軸にしていると思われているだけですね。もちろんRubyやRSpecが好きなので、そういうのもあってたくさん増えているとは思いますが、「なぜ主軸にしているんですか？」という質問に対して自分の中では特に理由はありません。

あとはPV数が少ない時の折り合いですが、「いつか読んでくれるだろう」「誰かに役立てばいいかな」ぐらいの感じで思っています。ハードルがすごく低いです。

本を書くきっかけは出版社の人から声がかかったからです。

「記事を書くための知識はどこからインプットしたのですか？」ですが、基本的には仕事で書いているコードからが多いです。そこからいっぱい自分で調べて、いっぱい深掘りするので、それが記事のインプットにもなっています。

という話をしてきたので、みなさんもアウトプットにレッツトライと。ぜひチャレンジしてみてください。

これで終わりますが、最後にちょっとだけお知らせをさせてください。みなさん、スキルアップをしたくないですか？　YES・NOでお答えくださいと聞いて「したくありません」という人はほとんどいないんじゃないかなと思います。ちょうどよいタイミングで、また『Software Design』さんに記事を書きました。寄稿記事が載ります。

2023年3月号の「ITエンジニアのスキルアッププログラム」という特集で、「テクニカルスキルを磨く」という記事を11ページほど執筆させてもらいました。「こうやったら技術力が上がるんじゃないでしょうか」ということを自分なりにいろいろ書いてみました。アウトプット関連の話も載っています！　「マサカリが来たらどうしましょう」みたいな話もありますので、ぜひみなさん手に取って読んでいただきたいです。

ちょうど2週間後の2月17日に発売されます。よろしくお願いします。ではこれで、僕の発表は終わります。みなさんご清聴どうもありがとうございました。

（次回へつづく）