持っていない情報では作れない

何かを作ること、特段、仕事で作業して資料を作るとかコードを書くとかプロジェクトの運営の仕組みを作るとか、何か具体的なアウトプットをするためには情報を集めることが肝心です。

なんだ、簡単なことじゃないかと思うかも知れないけれど、エンジニアの中でどれだけの数のエンジニアが自分に任された作業に必要な情報を自分自身が手と頭を使って集めているかといえば極端に少ないのが現実です。

ドキュメントレビューをしていると極めて限定的な範囲や極端な前提やあまりにも身勝手な暗黙が隠されている事がままあり、それについて説明をしてもらうとしどろもどろになったり、たまたま視界に入った情報だけでアウトプットを無理くりにでっち上げている事だってあります。

いやいや、こういった情報があるじゃないと思うけれどどこまで知っていて、どこから知らないかはそれを実現するエンジニア本人しか状態を周囲に教えられることはできません。どこまで知っているか知らないかはエンジニア本人が周囲にアクセスすることで周りも知る事ができるのですけれど。

ではどこまで知っているかをどうやってしればいいのか。今作業している仕事の情報を自分で取りに行ったか、と自問する事で自分で判別する事ができます。多くはお膳立てされて、情報を外から与えられて作業をさせられている環境を作られている事を考えれば、自分の頭を使ってどこまで情報を収集しようとしているかで自分でアウトプットを組み立てるときに必要となる情報の輪郭が見えてくるからです。

情報を集めるということはどういった情報が必要だろうとあたりをつけるところから自分でしなければなりません。一旦、この辺りの情報があれば実現しようとしているアウトプットを作れるだろうと仮説を立てて、この辺りとぐるっと必要だろうと思う範囲を決めるわけです。

この、この辺りまでと決めることでさえ、少ない手持ちの情報から推測して仮決めする意思決定を働かせる必要があります。この範囲を決めること自体にあまり意思決定の重さはなくて、どちらかと言えば意思決定した考えの軸の方が意味合いは重かったりします。それは事を進めていくとこれでいいんだっけという自分自身が行った過去の意思決定への問いかけだったり、他者からなぜこう判断した事が正しいのかと問いかけられたときに立ち戻る根拠となるからです。

軸を持って一旦は収集する情報を集め始めればいいのですが、次に考えなければならないのはどこまで集めればいいのかという判断です。時間をかければある程度は集める事ができるけれど時間をかければいいアウトプットができるかと言えばそうでもないのです。それを決めるのは情報を組み立てて輪郭を作れるかどうかで判断します。

輪郭を作れたら集める情報の軸で実現しようとしているアウトプットがイメージできれば先に進めましょう。イメージアップできないならまだ情報が足りないか軸がずれているかも知れません。アウトプットの完了基準に照らして検証しなければなりません。

ここのプロセスをやらないために情報不足がアウトプットのチープさを引き起こすんですよ。