伊藤 淳一氏
株式会社ソニックガーデン プログラマ
「プロを目指す人のためのRuby入門」の著者、および「Everyday Rails – RSpecによるRailsテスト入門」の翻訳者。プログラミングスクール「フィヨルドブートキャンプ」のメンターでもある。
Twitter: https://twitter.com/jnchito
Blog: https://blog.jnito.com
Qiita: https://qiita.com/jnchito
ITエンジニアにとって、アウトプットは大事だと思っている人はたくさんいると思います。ですがそれと同時に、大事だと思っているけど全然アウトプットできていない、と悩んでいる人も同じくらいたくさんいると思います。 その一方で、世の中には良質な技術記事を量産しているエンジニアもいます。思うようにアウトプットできなくて困っているエンジニアから見ると、すごく不思議に思えませんか？
そこで今回の講演ではQiitaでユーザーランキング1位（2023年1月現在）の伊藤淳一さんを講師に招き、良質な技術記事を量産する秘訣について語ってもらいます。
この講演を聞けば、あなたも明日からさくさくとアウトプットできるエンジニアになれる！・・・かもしれません。
ぜひご参加ください。
こんなエンジニアにおすすめ
ジュニア・ミドル層エンジニア
これから情報発信をしようとしているエンジニア
情報発信のメリットを知りたい方
実績
- Qiita 1位
- Software Design誌への寄稿 6回
：
ブログ歴14年
Qiita歴11年
ブログは毎年50本前後
Qiitaは30本前後
なぜ忙しいと言いながらこんなにブログを書いているか？
なぜQiita 1位だったりするのか？
反響の有無にかかわらず、なんでこんなに長く続けているか？
伊藤さん自身はよくわかっていなかった。
自己分析
みんなで知見を共有しあって、世界を良くしていきたいから
伊藤さんのことは、「リーダブルテストコード」の登壇で初めて知ったが、非常にわかりやすくためになる登壇だった。その時に受けた印象からも、なるほどなと思える自己分析内容だった。
アウトプットを始めたきっかけ
- Qiitaもない時代（15－20年前）
- 変なエラーが出た->ググる->同じエラー->直った
- 思いつかない解決策。ありがとう
という経験を何度もした。
-> インターネットへの恩返し
誰かが書いてくれた記事はありがたい。
ネット上の情報は勝手に湧き出たものではない。
誰かが書いてくれたからこそ、その情報がネット上にある。
目指すのは「助かった、ありがとう」の無限連鎖
確かに、この経験は数えきれないほどしているので、少しずつでもこうした記事は書いていきたい（まだ連携していないがZennでもそうした記事の方が読まれやすかった）。
このモチベーションがあれば、
「この知見はきっと誰かの役に立つはず」と思ったら書かずにはいられない。
「ありがとう」の気持ちはだれか一人で十分。バズることは目的ではない。
すぐに反応がなくても構わない。いつか誰かの役に立てばよい。
だから、長く続けられる。
さらに、嘘をつくわけにいかない。
分かりやすく書かないといけない。
だから、めちゃくちゃ調べるし、わかりやすいから感謝されやすい。
調べると、自分自身の勉強にもなる。
その結果得られるもの。
徐々にフォロワーが増える。徐々に知名度が上がる。すぐにではなく、徐々に。数年単位。
長く続けていれば、たまにバズる記事が出てくる。
記事がバズれ場、企業やメディアの人の目に触れることもある。
登壇しませんか？執筆しませんか？という声がかかるようになる。
まとめ
- 知見を共有して困っている技術者を助けたい。技術者の世界を良くしたい。
- 「これは同じように困ってる人が絶対いる」と思ったら書かずにはいられない。
以下の考えはNG。
有名になりたい
お金持ちになりたい
バズりたい
本を出したい
スキルアップしたい
から記事を書くというのは、目的と結果が逆。
最近のお悩み
お金の匂いがする技術記事が最近増えてきた印象。
そういう記事に限って信頼性が低い
そういう記事に限って検索の上位に出る
これは本当にそう思う。無駄にSEOが強いが、大した内容が無いのでやめてほしい。
個人ブログの方がよっぽど良いのに埋もれてしまったりもしている。
アウトプットは色々
ブログやQiita記事だけでない。
自作Webサービス
OSS活動
勉強会主催
インターネット上に発信することだけがアウトプットではない。
社内記事等
広義のアウトプットは、
ギブアンドていくのギブ側。
誰かの役に立つこと、感謝されること
プログラミングやIT技術に固執しない。
最近買った家電のレビューや最近見た映画や成功したダイエットとか。
それが知りたかった！書いてくれてありがとうと思われる話なら何でもＯＫ。
自分自身へのハードルを下げよう。
おすすめの技術ブログネタ
定番：トラブルシューティング、Ｈｏｗ－Ｔｏ系
コードレビューでしょっちゅう指摘している内容 or されている内容
ツールやライブラリの新機能紹介
ＯＯをやってみた。
技術書の書評
難しい技術を理解するための自分なりのアプローチ
技術系エッセイ
イベントや勉強会の参加レポート
残念なアウトプット
- 「チェリー本のまとめ」という名の無断転載
- 本を買わずに済みました。ありがとう！だと著者涙目
- 書評には自分の感想を書く。内容のまとめはほどほどに。
他の人が書いた記事の丸写し。またはリンクを載せただけ。
自分の言葉で説明できない技術は、まだちゃんと理解できていない技術。
何も見ずに小学生にＯＯを説明するとしたら？を考える。
技術を理解できていない証拠。かならず、自分の言葉で説明できているかを意識するべき。
初歩的な内容しか書けない
初歩的な内容で全然ＯＫ
ペルソナ（仮想読者）を決める。
この記事は、ＯＯの人のために買いている、と宣言する。
つよつよエンジニアが馬鹿にしてきてもnot for youと答えられる。
3日前の自分をペルソナにする。
つまり、その知識を知らなかった頃の自分。
タイムマシンで、困っている自分に自分が書いた記事を見せる。
世の中には、3日前の自分はいっぱいいる。
どこに書く？
Qiita/Zenn : 技術ネタのみ。主役は技術、私見は弱め。ルールを守る。イメージはみんなの公園
ブログ/note： 非技術ネタもＯＫ。主役は自分、強めの私見も可。イメージは自分の庭。日々の学習記録もこちら。
自分用メモは公開する？しない？
伊藤さんは非公開。なぜならわかりやすく書いていないから。
QuiverというMarkdownエディタに自分用メモをためている。
非公開＝無価値ではない。自分には役立つ。
公開する場合は、ブログ。清書すればQiita。
事前Q&A
アウトプットを始めたのはなぜか？ ＝恩返し
なぜRubyやRSpecを主軸にしているか？ ＝意図せず
自分が書きたいこととPV数は必ずしも一致しないが。 ＝いつか読んでもらえるはず
記事を書くためのネタ ＝業務等
Q&A
「良質な記事」の定義は？
読んだ人が良かったと思ってもらえる記事。3日前の自分が大喜びする記事。
伊藤さん自身も14年前の記事とかだと、うーんと思える内容だったかも。経験を経て、知らない人が読んでどう思うか？ということを常に考えながらアウトプットを続けていく必要がある。
記事を書くのにどれくらい時間をかけているか？
ぱっと書く場合は、1時間くらい。書くぞと意気込む場合は数日はかかる。最初にアウトラインをエバーノートに書いて構想を練って、書きながら推敲してと数日間はかかる。
Rubyを始めたきっかけは？元々はJavaやC#をやっていたそうだが。
Ruby on Railsは当時新しいWebフレームワークだった。面白そうとか憧れとかもあった。
オブジェクト指向が好き。オブジェクト指向言語を調べていたが、Rubyはこれでオブジェクト指向を書いたら面白そうと思ったこともある。
好奇心の源泉は？
ソフトウェア業界は、昔からプログラミングが大好きで、ゲーム作ったりしている人が多い。
しかし、伊藤さんは大学で初めてプログラミングやった。そもそも文系だった。
パソコン好きになったため、ソフトウェア業界に入った。新卒で入った会社は結構ひどいコードがあった。部署移動等して、わかりやすい、読みやすいコードに出会い感動した。そうしてエレガントに書きたい欲が出てきた。そこからコードを極める方向に進んでいった。技術者の目覚めはそうした経験だったと思う。
既存と同じような記事を書くか？
同じ記事は書かないタイプ。常にユーザー体験を想像しながら記事を書く。
エラーが出た。エラーメッセージをコピペして検索する。一番上に自分のブログが出たといったように。
なので、エラーメッセージでググって、1位がそれほどわかりやすいわけではない場合、もっとわかりやすく書いてやろうと思って記事を書く。
すでに記事がある場合は、結局はコピーとなってしまう。しかも劣化コピー。
ただ、そうすると上級者向けの記事の書き方にはなってしまうが、伊藤さんとしてはそういったことを心がけている。
読者やPVを増やすための施策は？
知ってもらわないと、結局意味がない。
なので、ツイッター等で何回かPushする。時間によって見ていない人もいるため。
この記事を読むメリットを一緒につけて、宣伝したりする。
恥ずかしいと思わずに、ガンガン行った方が良い。
ネタ集め方法は？
普段の業務や私生活でピンときたらメモっておいて、後で記事にする。
ネタ帳に書いていく。
自分の記事のクオリティを判断する指針は？自己満足なのではないか？と不安になってしまう。
第3者目線で書く。時間を空けてから読み直す。他の人が初めて読んだらどう思うか？
いきなり、こんな情報出てきたけど、他の人にはわからないのでは？といったことに気づいたりする。
反応が無かったらよくわからない。なので、自己満足でも良いと思う。
絶対バズるだろうと思って記事を書いたりするが、結局バズらないこともある。
そういった心持ちでやっている。
不安になってしまって下書きが溜まってしまう。
公開した後に修正したり追記したりする。しばらくしたら読み直して修正するのもあり。
下書きまでできているならもう少しなので公開してしまっても良い。
テックブログで、メンバーのモチベーションの上げ方に困っている。
仲間を増やしたい時にとる方法で良いものはあるか？記事を書くメリットは、業務等と比べると優先度が低くなってしまったりする。
伊藤さんとしては、正直経験がないからわからないということになってしまう。
記事を書いたら、社内の人も含めて記事に反応するとか。他社を参考にするのも良いと思う。
感想
非常にわかりやすい記事や登壇だなと思っていた伊藤さんが、正にその内容で登壇してくれていたので、ラッキーと思って受けてみた。
真似できない部分も当然あるが、少しずつでも良い記事になるようアウトプットしていきたいと思う。
伊藤さんでもやはり時間をかけて書いているんだなということや、ネタのとり方等参考になった。
Software Designにアウトプットについて寄稿したとのこと。読んでみたいと思う。
登壇で使ったスライドを上げていただいていたので、貼っておく。
コメント