今日の午後は、新世代ネットワーク関係のプロジェクトの打合せ。 この案件は、依頼元から異なるパートを受託した四つの会社が取り組んできた。 今年は、これらの総合的な仕上げを目指すので、相互に連携して統合されたシステムをつくる。 そこで、システム全体の視点からの調整などのマネージメント的な部分を、僕も手伝うことになった。
明確な外部仕様のある個別の製品開発と異なり、研究的要素の濃いシステム開発では、往々にしてスタート時点での要求仕様や要件定義に曖昧さが残り、それが全体の日程や成果に大きな齟齬を生む事が多い。 そこで、極めて当たり前だけど、最初にコンセプチュアルなゴールを明確にし共有することや仕様や検査、評価手法等を明確にするために、必要なドキュメントを明確にし、マイルストーンとしてこれらの発行を定義するなどを提案した。
昔から、良きコードは可読性が高く、それ自体がマニュアル、または仕様書たりうるとか言うが、これは構成要素が一つに閉じた場合の話でしたか無い。 システムとして、複数の構成要素が連携して所要の機能を実現する場合は、ここの要素以外にシステムそのものに対する記述が必要であり、そこには仕様書などのドキュメントが存在する。
しかし、優秀な開発者の中には、ドキュメトンをつくるのを嫌がる人も結構いる。 「会社で仕様書とかの書類書きばかりでさぁ、俺はコード書きたいんだよね 」という愚痴を、聞いた事のある人は沢山いるだろう。 また、ハード系の開発でも、「最近は、仕様書とかの書類書きばかりでさぁ、俺はモノ作りたいんだよ」というのも同様だ。
これは、仕様書などの書類を書く事が、開発行為ではないと思ってるからだし、実際に仕様書が無くてもコードとハードがあれば、モノは完成するし動く。 ところが、複数の構成要素からなり、複数の異なる開発者が関与するシステムでは、残念ながらこれでは何も動かない。
逆に、設計がきちんとできれば、その実装をどうするかには、いくつかの選択手法があり、そこには色々な意味での冗長性がでてくる。 僕の経験では、いきなりコードを書いたり、半田コテを持ったりする人は、ある範囲を越えた規模の開発には向かない。 もちろん、特定部分のインプリに徹底的に拘り続けて、その道の職人になる人もいるけど、そういう人の活躍できる部分はとても少なく、かつ減少している。
というわけで、僕の回りにいる中堅の開発者で、今後のキャリアパスとして、システム開発を目指す人には、是非書類書きが実はシステム開発行為そのものなんだということを理解ほしいと思った日であった。