（説明書）エンジニアはなぜ情報発信するのか
この記事の目的
「エンジニアはなぜ情報発信するのか」を非エンジニアの人に説明する機会がありました。
かくいう私も新卒から10年勤めた他業種の会社からエンジニアに転職したばかりで、この業界の情報発信のあり方にまだ慣れていないところがあります。
ざっくり調べた上で、とりあえず現状の理解の範囲で概要を説明できる資料として、この記事を作りました。
他業界から見たときにエンジニアの情報発信内容がムズカシソウに見えるのはなぜなのか？
本題に入る前に、まずこの説明が必要そうな理由を先に解消しておきたい。
エンジニアが書いたもの、あるいはエンジニア向けに書かれたものについて、「なんだか難しそう」という声はかなり聞いてきました。
いまや多くの人がエンジニアリングを必要とする時代なのに、とっつきにくいとか、抵抗感を感じてしまうのはなぜでしょうか？
前提知識が省略されているから
エンジニアの専門分野はいま高度化し、多岐に渡っています。
1記事の中でいちいち前提知識を全部書いてはいられないので、省略されるのがふつうです。
前提知識がない状態で記事を読んでも分からないのは当たり前です。
私もこのZennにある記事の大部分はぜんぜんわかりません。
そもそも「情報」が初等・中等教育のカリキュラムに加わったのが2003年で、それ以前のカリキュラムを受けている方は基本的な前提知識を省略されている状態といっても過言ではありません。
だから、多数の人にとってエンジニアの言っていることは「なんだか難しそう」に聞こえてしまうのです。
（この辺、「前提知識へのアクセス」をAIが繋いでくれる未来になったらいいなぁ～と思います）
内容が個別的だから
後述しますが、エンジニアの記事は基本的に特定の問題を解決することを使命としているので、具体的に書かれているのは良い記事です。
反面、個別性が高いので、その状況に遭った（遭う）人でなければ「共感のチャネルで理解する」ことも難しくなってきます。
極端な例ですが、会社の方針でクラウドサービス利用禁止になってる人がAWSの話をされても、メリットもよく分からないと思います。
（記事に「手段」だけでなく「目的」を含めると、この辺を緩和できそうです）
エンジニアが情報発信するのはなぜか？
本題に入りましょう。情報発信はエンジニアにとってどんな価値を持つのか？
記事が前提知識を削ぎ落としつつ個別具体的になっていく理由も多分そこにあります。
同業者への貢献のため
真っ先に思いつくのがこれです。
あなたがあるエラーに苦しんでいたとして、その解決策を情報共有したならば、
今後同じ目に遭う人はあなたよりもっと短時間で問題解決できることになります。
これを続けていくと、エンジニア界隈は群としての問題解決能力が上がることになります。
自分の能力を鍛えるため
これは私が情報発信の際に心がけていることですが、マネージャーとしてのスキルを上げる訓練にもなるということです。
プロジェクトマネージャにも資格試験があります。
手元にある参考書『情報処理教科書 プロジェクトマネージャ 2022年版』 (翔泳社, 2022)を再読しているところですが、論文答案構成時の注意点として「初対面の第三者に分かるように書くこと」が挙げられています。
たとえば以下のような表現を心がけるべきとのことです。
- 説明に必要な要素は省略することなく5W1Hで丁寧に説明すること。
- 定量的表現によって客観性をもたせること。
- 理想値と現実値の差を具体的に表現すること。
- 結論先行型の文章にすること。
つまり、普段からこういう物言いの訓練をしておけば、試験でも（実戦でも）役に立つといえるでしょう。
また、他人に貢献していく心がけそのものがマネージャーの徳を高めてくれるような気がしています。
ブランディングのため
特定の分野について情報発信が多く・詳しく・正確であれば、その分野について専門性が高いとみなされます。
つまり、採用側や一緒に仕事する側に専門性やスキル・経験をアピールできるわけです。
特に、自分が作ったサービスに関して意図や開発上の苦労を説明するのは、問題解決能力の高さをアピールできることになりそうです。
他の人の記事のほうが有用に見える問題への対処
さて、自分の立場から見た話です。
初心者エンジニアが情報発信するうえで不安に思うのが、「他の人のほうが同じような内容で有用な記事を書いているのだから自分が記事を書く意味はないのでは」ということです。
たしかにGoogleだって重複記事を嫌います。
では、重複しないように書けばいいということになります。
体験として書く
解決方法は一般的かもしれませんが、体験は唯一無二です。
（実際、プロジェクトマネージャ試験でも「あなたの体験」が問われることになります。）
この業界は人手が足りていませんので、初心者はたくさん入ってきます。
一方、初心者だった頃の体験を思い出すのは難しい。
どういう背景のもと、どういうことを調べ、どういう解決をしたか、という体験談を書き残しておくというのは初心者の頃こそ貴重な記事になります。
オンボーディング（入社説明）資料として再活用できますし。
発信範囲を絞る
全世界に情報を発信する記事ではなくて、社内とか身内とかの限られた範囲に発信することを考えます。
あるいはZennに記事を書いておいて、それを別観点から社内勉強会とかメールマガジンのネタにする。
そうすると、内容自体はありふれていても、「発信者の人柄を知ることができる」という価値が前面に出てきます。
まとめ
というわけで、エンジニアの情報発信は一見難しそうに見えるのですが
- 他人への貢献
- 自己研鑽
- ブランディング
の要素からできているところは他業界とそんなに変わらないと思います。比率は違うかもしれません。
他業界の方やこの業界に入ったばかりの人が、エンジニアの情報発信について理解するために有用な資料になってたら嬉しいです。
Discussion