waterfall

知っていると当たり前ですが、意外と気づいていない事実。それは情報は必ず上から下に流れるものではないということです。 これを意識することで物事の理解が捗るようになります。

情報の流れ

書物やドキュメントを読んでいると、必ず上から下、もしくは右から左へ読むようになっているかと思います。なので、順番に読んでいけば全体像が理解できるようになるそのようなことを無意識で考えている人が多いはずです。

しかしこれは大きな誤りで、実は文書を書いている書き手が技術を使い、順々に理解できるように文書を書いているからそのような構成になっているだけです。情報を無理やり文字というフォーマットに当てはめて伝達しようとしているため、このような形式をとってしまっていることになります。

逆に絵画を見た時を想像してみるとわかりますが、絵画の情報を言葉で伝えることは非常に難しいです。流れるような文書を書き、絵画を見ていない人が同じ絵を想像してもらうことが容易ではないことは間違いなく理解できるかと思います。このように情報というものは我々が想像しているような順番に並んでいるものではないのです。

プログラミングも同じ

ソースコードは頭から読むようにできていないんです。頭から読むのは、学生の頃にやって失敗しまくった。要するに心が乱れるんですよ。本は前から読むように最適化されるんだけど、それは著者がそうなるように頑張ってるからなんです。生の情報は最適化されていないんです。だから、ソースコードを本のように読むのは、かなり非効率な読み方なんです。

カーネルハッカー・小崎資広の「コードを読む技術」http://cybozushiki.cybozu.co.jp/articles/m000316.html

小崎氏が指摘している通り、ソースコードも一緒で上から下に読むものではないのです。細かい所は、処理の始まっている所をベースにして、タグのジャンプなどでどんどん移動して理解する必要があります。

いかにして相手に情報を伝えるか

ITのプロジェクトの現場では、仕様書を策定するなどして、共通の認識を持たせることは必須です。 ついプログラマーだと文書のみで頑張って伝えようとしてしまいがちですが、やはり絵も同時に用いて伝えるのがベストです。パワーポイントを使って、画像や図形、表のマトリックスなど2次元で表現できる方法はいくらでも使うべきと私は考えています。これを意識するようになってから、パワーポイントを使うことが好きになりました。

ITのスタートアップなどの現場での仕様書で重要な点は、「相手に伝わって実際に参考にして実装が出来ること」これだと思います。もちろん大きな会社や契約によっては文書を書くことによる納品や法的根拠などのために冗長な文書を作成する必要があるケースも多いかもしれません。しかし、スタートアップやチームで作る時にはこのようなSIerごっこは間違いなく本質ではありません。「共通認識を得られること」これが最も重要です。

あと図形などを記載する以外に重要なことは、具体例です。「GithubのようなPull Requestの仕組み」「RedmineのカスタマイズページのようなDB設計」「Facadeパターン」たったこれだけの言葉で非常に多くの情報を伝えることが出来ます。しかも、認識のずれの可能性が限りなく低いです。もし言語がないと物事を伝えるのが難しいように、具体例があるだけでとてつもなく情報伝達がスムーズになります。頭にボンヤリしたアイディアがある場合、とにかく似たような例がないかを探すことがかなり重要であったりします。

具体例、具体例、具体例

「犬」という言葉より、「ダックスフンド」という言葉のほうが情報が詰まっています。 これはダックスフンドという言葉の抽象度が低い、すなわち具体的だからです。 我々はダックスフンドという言葉から犬という上位概念を瞬時に類推することが出来ます。

ソフトウェアなどの開発現場において、この具体例は非常に重要です。 むしろソフトウェア開発というものは「具体化する作業」そのものです。 抽象的な言葉は色々な解釈ができるため、実際に作る場ではどんどん具体的な言葉に言い換えてあげる必要があります。具体的にすることで、相手も実際にイメージ出来き、はじめて物事が前に進みます。また、具体化とは決断することでもあるので、精神的にも非常に疲れます。ただこれを日頃から訓練することで大きく技術者としての腕も上がります。

適度な抽象化能力を身につけたあとは、原点回帰して具体化によって自分の能力を高めるのはいかがでしょうか。情報というものは何かを考えるだけでも奥が深いです。