読者です 読者をやめる 読者になる 読者になる

methaneのブログ

このブログに乗せているサンプルコードはすべてNYSLです。

プロセス改善に関する意見の食い違い

http://proger.blog10.fc2.com/blog-entry-69.html

現場の人間が「プロセス改善は工数の無駄だ」といった時に、つい「長期的な視野に立ってないからだ」ということがよく言われます。大抵の場合、それも一理あるとは思いますが、決してそれだけではありません。それよりも、「もっと他にすべきことがある」というのがあるからでしょう。プロセス改善の目的は、開発効率の改善や品質の向上にあります。そして現場の人の多くは、その目的のための近道がドキュメント管理や、手順の定義がネックであるとは思っていないのです。

言えてる。
たとえば、CMM Lv2のKPAの一つにある、要求管理。「顧客が欲しいと思うモノと開発側が作ろうとしているモノを一致させましょう」というもの。
確かに大事だけど、「本当に欲しいモノは顧客自身もよく判っていない」場合が多し、内部設計をしてみてから気づく外部設計の穴もあるので、「要求を聞いて要件をリストアップし、精密な外部仕様書をつくって顧客の承認を貰うまで、内部設計に取りかからない」なんてルールを押しつけられると時間の無駄になる。
構成管理も大事だけど、全てのコードの変更に対してなんの要件に必要だったのかを書くというルールを作ってしまうと、リファクタリングしにくいし、いろいろな機能に関係する汎用モジュールを作りにくくなったりする。
進捗管理ができてないと、「遅れが発生したときに早い段階で管理者が対応する」ことができないけど、上の都合で勝手に作られた何故かα版が必要以上に早いスケジュールに対する進捗管理をしても、ホントは余裕があるのに何故か休出や残業を強いられる。(そしてα版完成後すこししたら、やることがなくなる)

プロセス改善は現場主導であるべきだ。管理者がプロセス改善したい場合、目的(問題意識)を開発者と共有し、ルールの押しつけはしないこと。管理者は長期的な問題意識を持っているかもしれないが、その問題を解決するために先に解決しないと行けない目の前の問題*1を意識しているのは開発者だ。

*1:バグ曲線を早く立ち上げようとする間違った目的でα版を必要以上に早くしているために、やっつけ仕事が蔓延しているとか