生産性を底上げする「検索力」について

「自己解決能力を磨くことで生産性を底上げできると思ってますよ」って趣旨の記事です。

# 目次

1. はじめに：モチベーション
2. 前提：問題について
3. 情報を集める
4. 業務一般に適用する
5. おわりに

# 1. はじめに：モチベーション

ある、ぶち当たっている問題を自ら解決できない際、問題について「詳しい人に聞く」ことはわかりやすい解決方法かと思う。
しかし、詳しい人に聞くとすると、「（聞きたいことについて）詳しい人が近くにいない場合どうするか？」「1から10まで全て知っている人に聞くのか？」など、際どい論点が残ってしまう。
人に話を聞くのは、近くに詳しい人が複数人いる状況で、かつ話しかけやすい（など一定の関係性がある）状況においては大変有利であるが、他方において効果が期待できない場面が多く存在すると考えている。

自分で調べたり考えることで、解決できないまでもある程度のところまでたどり着ければそれに越したことはない。
調査コストを小さくできるし、人の時間を奪わない。
そして何より、そのような自己解決能力には汎用性がある。
プログラミングや財務経理、法律関連など一定の専門性やコンテキストを持つドメインに対しては自己解決能力によってやりたいことや達成したいことに小さい労力でたどり着けるのではないかと思う。

最近、ジュニアなメンバーと働く中で「ここまではたどり着けるのではないか？」「もっとショートカットできそうだ」と複数回感じ、上記のような自己解決に関する考えを述べることがこの記事を書くモチベーションとなっている。


# 2. 前提：問題について
本文で想定する問題とは、業務を行うことで遭遇する「成果物に向かうにあたり障壁となっている事象」の意味で書いている。
なにか第三者により決められた「正解」がないような論点、とも言い換えられる。

ただし、ここで言及している論点はAか？Bか？に答えることで、有用かどうかはともかくなにがしかの結果を生むことが見えているものでもある。

# 3. 情報を集める
当たり前のことだが、検索はウェブ上の検索にも様々な方法がある。
プログラミングの学習をおこなう際は、私の観測範囲ではどんな検索方法で、どんなページにあたるか、このプロセスによって
問題の解決にいたる速度や精度に大きく差が出る。
普段自分がやっていて特に差が出やすい使い方、ソースを決して網羅的ではないが、何個か上げてみる。

## 公式ドキュメントにあたる
*期待効用 ... 確実で必要十分な情報を得ることができる*

「ドキュメントにあたって正しい情報を得る」のはある種の技術である。
つまり、習得可能なもので身につければ得られる情報の量、質を底上げすることができる。
そして、初見ではとっつきづらく有用度を判別しづらいのも公式ドキュメントである。

たとえば、Javaを勉強していてStringについて知りたいとする。知りたい情報にもよるが、多くの場合真っ先に公式のJavadocにあたるほうがよい。
[クラス String](https://docs.oracle.com/javase/jp/8/docs/api/java/lang/String.html)
とにかく、確実な情報を入手できる。
インターネットを徘徊していると遭遇してしまう記事群は内容の成否を判別する「デューデリコスト」が高い（自分でこんな記事を書いておいてアレですね、超ブーメラン...）。
特別な理由がない場合はまっさきに公式ドキュメントにあたるようにしたい。

では、それらにいきあたるためにどのような検索語を入れるだろうか？

上記のJavaのStringであれば、自分なら「Java String」で打ってだいたいのあたりをつける。
プログラミング言語なら、「言語名 調べたいこと」みたいな入れ方で90%以上はカバーできる気がする。

## ソースコードを直に参照する
*期待効用 ... ドキュメントからだと推測のつかないより深い事実を直に確認できる*

「ドキュメントにあたる」のに近い種類の方法。
ドキュメントは「利用者」の目線に立った使用方法を説明するものであるのに対し、ソースコードはやっていることの実体を眺めることができる。

ドキュメントはふんわりやりたいことを掴みたいときや、すでにある程度中身や挙動を理解していて、使用方法を再確認したい際に有用な印象である。
対して、ドキュメントにある使用方法の裏とりをしたい際や、挙動を細かく把握する必要がある場合は直接ソースコードを参照するほうが有効な状況も多い。

ソースコードの参照はやらなくてもよいケースが多いのと、多少技術が必要なので情報収集方法としてはややハードルが高いかなとは感じる。
自分の記事で恐縮だが、過去の記事も参考までに引用させていただく。
[プログラミング言語の標準APIを掘る](https://qiita.com/s_nozaki/items/70a7a2626c0bb598e077#7-%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E%E3%81%AE%E6%A8%99%E6%BA%96api%E3%82%92%E6%8E%98%E3%82%8B)

## 記事にあたる
*期待効用 ... サンプル、やった結果といった具体例を得られる*

公式ドキュメントやソースコードは、正しい情報を網羅的に伝えてくれる反面、（自分の観測範囲では）利用サンプルがあまり掲載されてない。
つまり、インスタンスを初期化してコンストラクタに必要な引数を渡せばよいことはドキュメントで理解できるが、具体的なイメージがわかない。

ブログやQiitaなどの記事は、「やってみた」系の利用サンプルが大量に流通している。
私は、はじめてのツールを触る際などはまず記事を何個か読み、ふんわり雰囲気を掴んでから公式ドキュメントを読むことで
やりたいこと全体像のアウトラインを描くようにするケースが多い。
つまり、具体利用例と公式ドキュメントという抽象をそれぞれさっくりインプットしている。

ただし、上述したようにネット上の記事は間違えていることもあるので公式ドキュメントにあたり情報の真偽を確認しておくことで
不要な誤りを排除する。

## 書籍にあたる
*期待効用 ... 確度の高い情報を体系的に得られる*

書籍は正確性の高い情報を体系的に入手するのに適した情報ソースである。
他の情報源と比較すると、特に体系性や理論の理解に一日の長がある。
プログラミング学習においては、「node.jsで簡単なAPIを作るまでの0-10」や「Kotlin言語リファレンス」といった
重厚になりやすい情報の獲得手段として有効な印象がある。


# 4. 業務一般に適用する
効率のよい、意味のある情報収集は当然プログラミング以外の領域でも大変役立つ。
施策やアクションをいつ？どのように？誰に？とるべきか、持っている情報の量と確度は業務のレベルを大きく変化させる。
プログラミング以外の業務でも同じように、

- 社内記事やWikiを探す
- 公開用のドキュメントや設計書にあたる
- （ITサービスであれば）動いているソースコードを読む
- 業務ドメインと関係のある書籍を読む

など、情報収集の手法を磨くことで意思決定の精度を高めやすくなるはずである。
そのように考えると、プログラマに限らず他職種のメンバーも情報収集の方法を磨くことがより仕事の精度を高める
一要素となるのではないか、と考える次第である。


# 5. おわりに
この記事にも時間をかけてしまった...もはや技術記事ですらない気がしてきました...

そもそも、なぜ情報収集するのか？
冒頭でも少し触れたように「Aか？Bか？に答えることで、有用かどうかはともかくなにがしかの結果を得たい」から。
つまり、情報収集をもとに意思決定を行いなにがしかのインパクトを生み出したいんですよね。

考察するとあと3倍くらい紙面使いそうなので諦めてしまいましたが、情報の収集には「どこから？」「どのように？」収集するか
で結構大きめのマトリクスがしけるかもしれない。そうすると、きれいな整理になるかもなと。

また、言及しきれなかったものとして「海外のソースに当たる」もあります。これも超大事だが考察しきれず、取り急ぎは
言及を諦めます。