品質と規律

プロジェクトの品質
プロジェクトの品質とは、顧客と契約したdeliverablesを契約したとおりの形で届けることである。有形のdeliverablesであれば、とても容易く、実物サンプルがあれば顧客は事前に期日に届けられるdeliverablesを確認し、実際に納入されたdeliverablesがその契約書とおりであることを確認できる。ソフトウェアのような無形のdeliverablesはそれに対して無形であるがゆえに契約したdeliverablesが契約書とおりの仕様で受け取れるかが確認しにくいものだ。
人は形として目の前に並べられれば、容易く、理解を相互共有できるが、形のないものを一から作るようなソフトウェアの場合、ッ夫々の理解を言葉や図、表など一旦別の表現に変換してから共有を図ろうとするために、夫々の頭の中の理解が外に出た瞬間に情報が減衰し、少しずつ劣化していく。その減衰した情報から受け手が再構成し、別の頭で理解するために更に別のものに置き換わる。ソフトウェアも分業化が著しく進んでいるために、顧客を親情報とすれば、受け手が子情報で実際にソフトウェアを設計し、コードを書くエンジニアは孫かそれ以下になってしまう。
多くのエンジニアが介在するようなプロジェクトでは、契約したdeliverablesをそのとおり確保すべく、品質としてそれを維持するために多くのリソースを使うことになる。その品質を確保するために開発プロセス手法や標準化に取り組み、プロジェクトとしての最低限のラインを死守することを努めようと試みる。いずれにしても、ソフトウェアのような無形のdeliverablesの品質の実現は、介在者が多いことから難しいのである。

プロジェクトと規律
実際のプロジェクトのプロジェクトマネージャやチームのメンバは、そのプロジェクトのスポンサーである顧客が要求する品質をどれだけ理解して取り組んでいるかは怪しいものだ。仮に、顧客が要求する品質を理解しているなら、実現できない提案はしないだろうし、プロジェクトが開始となったときに、顧客が要求するdeliverablesの品質を理解することからはじめ、その実現化に細心の注意を払うだろう。その注意の中に、品質を確保するための標準なりルールがあるのであって、それを適用することに何ら躊躇いや抵抗はありえない。その観点からも、ルールや規則に対してネガティブな発言や行動を取るエンジニアがいるとすれば、不適格の烙印を押されたとしても間違った判断ではない。顧客の要求と言う品質が最優先されるからだ。
標準やルールのような“規律”は、品質を確保するためのプロジェクトというチームが実際に実行するために欠かすことの出来ない、学習する必要のある手法やロジックなのである。チームとしての作法でもあり、エンジニアが必然と身に着けなければならないコンピテンシなのである。