一流エンジニアになるための Off-JT #2. 情報の精査

情報の精査：はじめに

みなさんは、“ある機能の実現方法を調べたいとき”、あるいは“新しい技術を習得するとき”、何から情報を仕入れることが多いですか？

インターネット
（検索サイトや SNS など）
チャットツール
メーリングリスト
書籍
セミナーや勉強会
カンファレンス、セッション、Meetup
有識者に直接尋ねる
その他

あるコミュニティで、このようなアンケートを実施したところ、その多くの回答が“インターネット”というものでした。
近年では、インターネットと技術の進化に伴い、“課題解決のスピード”が以前とは比べ物にならないほどの高速化が進んでいます。
言い換えれば、現場で課題解決に“求められるスピード”が早くなってきたことと、課題解決に“かけられる時間”が短くなってきたということでしょう。
それらが十数年前より可能になってきたというともいえます。

情報の精査：工程の違い

下記では、“課題解決のスピード”が高速化してきた事例として、“ある機能の実現方法を調べたいとき”の十数年前と近年の工程の違いを比較してみました。

例：数十年前

課題発生
社内の有識者に尋ねる
未回答
本屋へ行く
それっぽい本を物色する
立ち読みして整合性をとる
4 と 5 を何回か繰り返す
購入する本を何冊か決めてから一旦帰社する
書籍購入の稟議および決済
再び本屋へ行く
何冊か買う
帰社
熟読する
実装
テスト
解決

例：近年

課題発生
ググる、またはSNS やコミュニケーションツールでメンションする。
横断する、または返答がくる
（未解決なら有識者に尋ねる、あるいは書籍購入の流れも）
重要箇所をピックアップする
実装
テスト
解決

これらはあくまで、工程の一例でしかありませんが、このように一覧しただけでも、計 9 工程省略されているのが分かります。
このように、明らかに“情報の取得方法とスピード”に大きな変化があります。
以前を知ってる私たちからすると、便利になった反面ちょっと酷に思うこともあります。
私は購入した書籍を、会社の近くの砂浜で、先輩と一緒にビールを飲みながら読んでたので（笑

もちろん今でも、書籍購入はとても有効な手段でしょう。
しかしそれでさえ、Amazon などにおいては、電子版の購入までに何分とかかりません。
有料書籍の場合、金銭が発生するためでしょう、ほとんどの場合は“情報の精度”は高めに維持されていることでしょう。
その昔、書籍に誤った情報が記述されていた際には、私の上司や先輩方はその出版社に連絡をしていたものです。
それらの行為は、おそらく“情報の精度”の維持に役立っていたものと思われます。
しかし、いまやそれらの情報媒体の多くはインターネットが担っているのかもしれません。

情報の精査：ある出来事

ここで、ある現場で起きた極端な出来事を例示します。
あるエンジニアさんに、“ある機能の実現化”に向けて、“調査から実装まで”のアサインがされました。
その結果、結合テストで不具合が生じました。
コードレビューを担当した私は、ロジックが破綻した不具合箇所を見つけ
「なぜ、このようなロジックになったか？」
そのロジックの“意図”だけを確認するつもりでした。
そうすると、彼は
「このサイトにこう書いてあったからです。」
と答えるので、そのサイトを見せてもらいました。
そのサイトは、いわゆる“やってみた系“の情報サイトでした。
「でもこのサイトの情報は、そもそもバージョンが古くありませんか？」
と私が尋ねると、彼は
「でもそう書いてあったので。」
おそらく彼が言いたかったのは「特に自分の意思はない」ということだったのでしょう。
そう、この例の問題の本質は、実装ミスというよりは意識の問題です。
しかし、一つの“勝手サイト”の情報だけを鵜呑みした結果でもあります。
では、テクニカルマネージャーは、その“勝手サイト”の管理者に連絡をとって文句を言えばよいでしょうか？
仮に指摘はできたとしても、金銭の授受がない以上、ほとんどの場合はオープンソースの決まり文句のように、「自己責任でお願いします」というのが通例でしょう。
この事例では、無償で情報を得る側の立場として、自己責任になっていませんでした。

インターネット上の情報は、精度が担保されていない情報も多いのが現状であり、強く認識しておくべきです。
初学者は、その情報サイトに書いてある内容に、完全依存状態になってしまうものです。
これは当然の原理です。
しかし、よくある脱初級者クラスの例として、少しずつ応用が効くようになってきた頃、インターネット上の情報が誤っていることが分かると、必要以上に憤慨しているエンジニアさんをお見かけすることがあります。
私はこの事象を、“成長期”と呼んでいますが、必ずしもネガティブな事象ではありません。
なぜならこのような事象は、初級者の完全依存状態から抜け出しはじめた状態だと私は思うからです。

情報の精査：一流エンジニアの場合

一流エンジニアは、前回の記事の“テクニカルメモ”の例と同様に、“課題解決の調査から実装まで”の“生産性”が非常に高いものです。
“情報の精査”についても、ほんの短時間で見極めるエンジニアさんもたくさんいます。
これは、特に基礎技術をきちんと身につけてきたエンジニアさんほど、この傾向が強いように思います。
また、これは“エラー調査”の生産性においても如実に表れてきます。
では、彼らは一体どのようにしているのでしょうか？

情報の精査：スキル

この簡単な解決例は、およそ以下のようなものが考えられます。

“オフィシャルサイト”は最低限マークしておく。
一つの“勝手サイト”の情報だけを鵜呑みにしない。
同じ条件下の情報を横断的に複数調査し、共通してる箇所を抜き出し、その情報を繋げてまとめて行く。
“テクニカルメモ”を有効活用する。

インターネットで取得した“情報の精度”を上げるとするならば、オフィシャルコミュニティがある場合には、まずは必ず“オフィシャルサイト”は抑えておくべきでしょう。
ブックマークなり、Pocket なりしておけば良い話です。
これは、最終的な“情報の精度”の担保に非常に役にたちます。
しかし、“オフィシャルサイト”は、仕様を羅もうしなければならない任務からか、必ずしもユースケースにマッチする“分かりやすい情報”が載ってるとは限りません。
キャッチアップスピードを高めるためには、よりユースケースに近い“勝手サイト”の情報を参考にするケースもあるでしょう。
しかし、もし仮に検索結果の表示順位が一番目にあるからといって、その全てを鵜呑みにする行為は、“情報の精度”を上げる作業を怠っていると言ってもいいでしょう。
そこで、同じ条件下（OS 、バージョン、連携ツールなどが同じ条件）の情報を横断的に複数調査し、共通してる箇所を抜き出し、その情報を繋げてまとめ、“情報の精度”を上げていきます。
もし仮に、同じバージョンの情報がなければ、旧バージョンの情報を参考に、解決に向き合うことも必要になってくるでしょう。
まとめる作業は、“テクニカルメモ”を有効活用していくことをオススメします。
このようにして、“情報の精度”と“情報の分かりやすさ”を維持し、必要に応じてブラッシュアップして“情報の鮮度”と“情報の量”を確保していきます。
そして次回、似たようなユースケースでも、“テクニカルメモ”からすぐ引き出して応用できるようにしておく。
まずはシンプルにこれだけで、“課題解決の調査から実装まで”の“生産性”が一気に向上していくでしょう。
そして、違うユースケースでも、これを繰り返していくだけで、“情報の精度・分かりやすさ・鮮度・量”という、“情報の基礎力”も上がっていることでしょう。
そしていつしか、“情報の精査”スキルも身についていくことでしょう。

前述した、ある現場では
「もう少しだけ横断的に調べて、まずは共通点を抜き出し、正確な情報をまとめてみてはどうでしょう？」
ということで、解決に向かいました。

情報の精査：OJT において

私は OJT にトレーナーとして入る際、全てをテキストとして用意はしません。
例えば“サーバーの仮想化技術”や“ネットワークの OSI 参照モデル”について
「5 つくらいググって目を通しておいてください。」
という手法をよくとることがあります。
この際、必ずはじめに伝えてるのは、一つの情報サイトのみを鵜呑みにせずに、複数の情報サイトを横断的に調べるようアドバイスしておきます。
（これは、次回ポスト予定の“情報のフック”にも大きく関わってくるのですが。）
こうすることの目的は、以下のような効果が期待できるからです。

その技術に関する知識の習得
“情報の調査”スキルの向上
“情報の精査”スキルの向上
“テクニカルメモ”のインプットスキルの向上
技術に関する“多角的な視点”の向上
自ら情報をまとめることによる技術への“主体性”の向上

情報の精査：まとめ

このポストでは、“一流エンジニアになるための Off-JT”シリーズのテーマとして、“情報の精査”について解説しました。
インターネットから情報を得る以上、“情報の精度”を確保する作業は多くの場合は自己責任となります。

最終的な“情報の精度”の担保のために“オフィシャルサイト”をマークし、“勝手サイト”の情報を鵜呑みにせず、情報を横断的に複数調査し、共通してる箇所を抜き出し、その情報を繋げて“テクニカルメモ”にまとめ、“情報の精度”と“情報の分かりやすさ”を維持し、必要に応じてブラッシュアップして“情報の鮮度”と“情報の量”を確保していく。
次回、似たようなユースケースでも、“テクニカルメモ”からすぐ引き出して応用できるようにしておくだけで、“課題解決の調査から実装まで”の“生産性”が一気に向上していき、違うユースケースでもこれを繰り返していくだけで、“情報の精度・分かりやすさ・鮮度・量”という“情報の基礎力”も上がり、“情報の精査”スキルも身についていく。