webライティング型システム研究会

プログラムのバグは、多くの場合、バグを出したプログラマ本人が対処します。

そして、プログラムのバグは、プログラマのマイナス評価に直結します。

それに対して仕様変更は、責任の所在が曖昧で、比較的問題視されません。

しかし、少し考えてみれば、誰に原因があったかは別にして、仕様変更のほとんどが、「顧客に対する仕様未確認」に端を発する一仕様策定のバグ」であることがわかります。

一仕様策定のバグ」による仕様変更は、「仕様訂正」と呼んで、明確に分けるべきかもしれません。

本当に誰のせいでもない、予測不能な仕様変更は、会社ごと買収されて業務が根本的に変わる場合や、法律改正などによって、それまでの前提条件が根本的に変わるような場合に限られます。

「仕様策定のバグ」は、仕様策定者が、実際の行動をイメージしながら、緊張感を持って情報を集め、考えをめぐらせていれば発生しないはずです。

顧客業務の正確な理解に加えて、顧客からの協力を得ることができれば、「仕様策定のバグ」は、プログラミング前から大幅に減らすことができます。

webライティング型プロジェクトメンバーが増えたあと、あるいは実装に取りかかってからの混乱は、追加コストの発生やスケジュールの遅延につながります。

スペックパターン開発プロセスの進め方であれば、プログラマとして投入するメンバーの人数や投入期間の予想精度が大きく向上し、開発側にとっても大幅なコスト減となるはずです。

考え方の変換が必要です。

今後は、テストで検出されたプログラムのバグを数えるのはやめましょう。

特に「XステップあたりY件のバグを発見しなければならない」という考え方は捨てましょう。

プログラマのモチベーションをおとしめるだけで、生産的な数字にはなりえません。

開発環境や言語が変わってしまったらなおさらです。

繰り返したところで、バグが減らずにプログラマが減っていくだけです。

バグを減らしたければ、できる限り早い時期に、ノゥハウを持ったシニアプログラマを、インプリメント・リーダーとしてwebライティング型プロジェクトに迎え入れ、インプリメント・リーダーが作りやすいと感じる環境を提供することです。

開発側は設計をできる限り少人数で行い、顧客側に全面的な協力をお願いします。

設計の一貫性が高まります。

設計に開発側から参画する理想の人数は、ふたりです。

webライティング型システム研究会は、上場企業基幹システム約100画面の設計・プログラミングを、仕様策定者とインプリメント・リーダーのふたりで対応したことがあります。

テストのみ別のメンバーに加わってもらいました。

繰り返しになりますが、webライティング型システム開発を混乱させずに進めるためのもっとも大切な条件は、顧客側と開発側が早い段階からうまくかみ合うことです。