こんにちは、リファクタリングが大好きなミノ駆動です。
この記事は READYFORアドベントカレンダー2022 、初日の記事です。
これはなに？
日々の開発をただ漫然とこなすだけでなく、獲得した技術や知識を外に向けて発信することは、他のエンジニアを助ける、自己の成長につながる、思わぬ機会を得られるなど、さまざまな恩恵をもたらします。
Qiitaアドベントカレンダー2022という折角の機会ですから、あらためて技術発信することの意義や恩恵を見直し、モチベーションアップに繋げられればと思います。
また、本記事に記したノウハウによって、発信内容のクオリティアップに少しでも貢献できればと思います。
この記事のゴール
以下の理解を得ることをゴールとします。
- 技術発信はさまざまな恩恵をもたらすこと
- 技術発信がより有効なものとなるノウハウを把握すること
筆者の発信実績
説得力を持たせるために一応記載します。
実績1 : Qiita
- 全記事数 ： 10
- 最大いいね数 : 2047
- 最小いいね数 : 487
- 総獲得いいね数 : 10251
- 平均獲得いいね数 : 1025
実績2 : Twitter
クソコード動画シリーズ
実績3 : 登壇発表など各種イベント依頼
2022年だけで16件。
以下代表的なもの。
- Qiita PodCast番組「エンジニアストーリー」 出演
- AWS Dev Day 2022 Japan 登壇
- 『良いコード／悪いコードで学ぶ設計入門』を一歩深める読み方 - FwLibrary #11
その他、 自社テックブログ での発信や 書籍 出版などの実績があります。
技術発信の恩恵
多くの恩恵をもたらします。
恩恵1 ： 自分のスキルが向上する
技術発信は他の方のためが第一のように思えるかも知れませんが、 自分のスキル向上が最初にもたらされるメリット だと思います。理由を列挙します。
恩恵1-1 ： 言語化すると理解が深まる
人はよく分かっていないことを上手く言語化できません。
自分が理解していることだけ言語化できます。
何か新しい知識を得た際、いざそれを言葉に表してみると、意外に実はよく分かっていなかった、ということが往々にしてあります。
私も記事を書く際、よく言葉に詰まります。
この「実はよく分かっていなかった」がとても良いのです。
分からないことに直面したとき、文献を調べたり、意味を咀嚼してみたり、表面的だった理解から深い理解へ進めることができます。そして成長します。
ラバーダッキング と呼ばれるデバッグ手法があります。
これはプログラミングで何か問題が発生したとき、それを誰かに説明すると自ら原因に気づき、自己解決する手法です。
ラバーダッキングの効果を鑑みると、自分の考えや理解を整理する上で、言語化は非常に有効な手段であると言えます。
恩恵1-2 ： 技術選択の精度が高まる
言われたことをただやるだけなのはエンジニアリングとは言いません。
さまざまな技術や解決手段がある中で、利益が出るよう、要求に見合う技術選択をすることがエンジニアリングです。
例えばドメイン駆動設計は機能性と変更容易性の向上を期待できますが、設計コスト以外に教育コストやコミュニケーションコストなど、さまざまな面において導入コストが高い、というデメリットがあります。
開発の状況と照らし合わせて、導入に相応しいかどうか判断する知識が必要になります。
自分の技術知識を言語化して整理し、理解を深めることは、こうした技術選択の妥当性を高めることに繋がります。
恩恵1-3 ： 銀の弾丸に陥りにくくなる
銀の弾丸とは、やっかいなあらゆる問題を撃退可能な、特効薬的な比喩です。
新しい技術を知ると素晴らしく感じられ、開発上のあらゆる問題を解決してくれそうな、銀の弾丸のように見えることがあります。
しかしソフトウェア開発には銀の弾丸はありません。
たったひとつの手法で解決可能なほど単純なものはなく、どれも複雑性の高い問題ばかりです。
言語化して理解を深め、技術の性質やデメリットを把握しておけば、銀の弾丸に陥りにくくなります。
恩恵1-4 ： 雑だった分析・判断が精緻になる
細かく言語化する習慣を身につけると、仕事における考え方も変わってきます。
それまで雑で解像度の悪かった分析・判断から、より精緻で細かく分析・判断できるようになります。
恩恵1-5 ： ドメイン駆動設計の実施に役立つ
局所的なメリットですが、取り上げておきます。
ユビキタス言語とはドメイン駆動設計に登場する考え方で、目的や意図を共有するための言葉です。ユビキタス言語はドメインモデルや境界付けられたコンテキストの設計に密接に関わります。
ユビキタス言語の策定には、認知外にある概念を探したり、概念の細かな違いを見分けて分離する、といった活動が必要です。
細かく言語化する習慣を身に着けておくと、概念解釈や分析の精度が向上し、ユビキタス言語の策定に非常に貢献します。そしてドメインモデルや境界付けられたコンテキストの設計精度が向上します。
恩恵2 ： 誰かを助けることになる
ここまで自分へのメリットとして書きました。
やっと他者貢献の話です。
技術の理解や言語化は、なかなか骨の折れる仕事です。
やろうと思っても、そうなかなかできることでありません。
つまり技術発信は、それだけ他の方の理解を助けることに繋がります。
助けられた方は嬉しいですし、技術発信した自分の自信が高まり、嬉しいものです。
多くの方が技術発信することは相互的技術交流であり、業界全体の技術力向上に繋がります。
恩恵3 ： 思わぬ機会に恵まれる（誰かが見ている）
「どうせ誰も見てくれない……」と思っていても、意外に見てくれているものです。きちんと丁寧に言語化された記事であれば、Qiitaのトレンドにも上がりますし、Twitterでもシェアされます。
習慣的に技術発信していると、そのうち「この人一体何者？」と興味を持たれるようになります。そして思わぬ機会に恵まれることがあります。
生存者バイアス だと思って話半分で読んでいただいて構いませんが、私の場合技術発信によって以下の機会に恵まれました。
- 入社のお誘い(3件)
- 登壇発表など各種イベント依頼(2022年だけで16件)
- 書籍 執筆依頼
こうした機会は私に限った話ではなく、世の中的にこれまでも大小さまざま含めて枚挙にいとまがありません。
私の知り合いで書籍の執筆依頼を受けた方がいるのですが、その方いわく、だいぶ前にTwitterでツイートした内容が出版社の目に止まり、書籍化しませんかと依頼が来たそうです。私の場合もTwitterが発端であり、「クソコード動画を書籍化しませんか」という依頼でした。
私自身、Twitter上で3度も入社勧誘を受けた経験が物語っているように、SNS上での採用や勧誘はもはや当たり前の流れです。
技術発信はエンジニアライフをより豊かなものにします。
発信の質を高めるノウハウ
獲得した知識をただ漫然と発信するのではなく、 発信内容のクオリティアップを目指すことで前述の恩恵はより一層大きくなります。
ノウハウ1 : 問題と理由を深堀りする
技術とは、なんらかの問題を効率的に解決するための仕組みや手法です。
つまり技術解説とは、技術が解決しようとしている問題は何か、どういった理由で解決に至るのかを説明することなのです。
従って、技術が対象する問題と、解決に至る理由を深堀りします。
そして問題に深くアプローチすることは、すなわち同じ問題に直面して困っている人たちを助けることに繋がります。
ノウハウ2 : 自分が直面した問題や失敗経験を絡める
問題に深くアプローチする上では、なんといっても自分が直面してきた問題や失敗経験と絡めるのが一番です。
泥臭い問題と絡めて解説された内容は、フワフワ浮いた空虚な理論などではなく、地に足のついた説得力のあるものへと昇華します。
そういう意味で、 自分が経験してきた辛い問題や失敗は、大きな宝になります。
ノウハウ3 : オリジナリティを発揮する、尖った内容にする
世の中のさまざまなシステムやサービスは、それぞれいろんなプログラミング言語やフレームワークで実装されています。
ある技術ひとつとっても、言語や開発環境などによってアプローチの仕方が違います。例えばデザインパターンは、言語ごとに実現方法が微妙に違ったりします。エンジニアは「この記事はJavaで書かれているけど、Rustだったらどういう書き方になるんだろう？」「Railsでは実現できるんだろうか？」など、興味を抱くものです。
こうした事情から、同じ技術でも、解説にいろんなバリエーションがあると、さまざまなエンジニアを助けたり、技術の幅が広がったりと、良いことが生じます。
市販の技術書は、広く読まれることを意図して、なるべく言語やフレームワークに依存しないよう抽象的に書かれるケースがあります。ゆえに、
- 自分が直面した問題や失敗経験
- 自分が使っている言語やフレームワーク、開発環境
などと絡め、独自の視点で書くだけで、相当な価値を発揮します。無理に抽象化する必要はありません。
ノウハウ4 : デメリットにも目を向ける
技術選択の精度を高め、銀の弾丸に陥らないようにするためにも、デメリットを調べておさえておきます。
ノウハウ5 : 不満は加工すること
技術発信の際、失敗経験や不満がベースになる場合があります。
ただし、失敗や不満をただ感情の赴くままに発信するのは避けるべきです。
人間は憤怒を起点に自己の正義を確信した瞬間、歯止めのかからない最も高い暴力性を無意識に発揮するので、特に注意が必要です。
多くの方が不快に感じるような発信は、たとえそれが技術的に優れた内容であっても見る人がいなくなってしまいます（もちろん何を不快と感じるかは人それぞれなので読み手の感情を気にしすぎるのも問題です）。
例えば恥ずかしながら私の場合、いっとき不満ばかりツイートしていた時期がありまして、そのときかなりの数のフォロワーさんが離れてしまいました。愚痴だらけの不快なツイートは誰だって見たくないものです。
一方でネガティブな感情は人間の性質の一部なので否定するものではありません。大事なのは、 失敗や不満をそのまま吐露せず、有用な形に表現を加工することです。
私の代表的な作品、クソコード動画シリーズは、技術的負債に対する私のネガティブな感情を、まさに有用な形になることを意図して加工したものです。
ノウハウ6 : 書籍の要約や丸写しに注意
技術発信する上では、技術が対象する問題と、解決に至る理由の深堀りが大事だと述べました。
この観点から鑑みると、書籍の要約 だけ 、丸写し だけ 、というのは技術の深堀りにほとんど貢献しません。
それどころか、著作権上問題になる可能性があります。
詳しくはこちらをご覧ください。
適切な 引用 をこころがけましょう。
ノウハウ7 : フォーマットに合わせて分析・執筆する
技術記事の投稿に慣れていない方にとって、まっさらな状態から一体どう書いていいものか迷ったり、伝えたいことがあっても上手く伝わる文面にならなかったり、困惑することが多いのではないでしょうか。
私が記事執筆時に基本にしている構成を以下にまとめてあります。
下記はあくまで一例ですが、技術の深堀りと執筆の手助けになるでしょう。
以上、ここまでが本記事でお伝えしたいことです。
ここから先は余談です。
「君が何を言いたいのかさっぱり分からん」と言われてた時期があった
私が以前勤めていた会社では、上司や同僚から「君が何を言いたいのかさっぱり分からん」と言われていた時期がありました。５、6年前(2016〜2017年)だったと記憶しております。そんなに昔の話ではありません。学生時代は国語が大の苦手でした。
技術発信や仕事で説明する機会など、さまざまなアウトプット経験を積んできたことで文章力や分析力が向上し、今では各種イベントの依頼や、書籍を執筆する機会までいただけました。
技術を噛み砕いて言語化し、読み手が分かりやすいよう平易な言葉で発信するのはなかなか骨の折れることです。慣れていない方にとっては、はじめは上手くいかないかもしれません。
しかし小さくてもひとつひとつ繰り返すことで上達し、人は成長します。
Twitterは1ツイート140文字なので発信しやすいです。
まずはTwitterで小さく発信していくことに慣れるのが良いでしょう。
書き慣れてきたらQiitaなどの技術投稿サイトで記事を書くのが良いでしょう。
技術発信で高みを目指していきましょう。
参考にした記事