プロジェクトルールやプロセスでどこまで縛れるか？

ここ半年くらいいろんなところで話題になっていて気になっていることがある。決め事、プロセス、プロジェクトルールでどこまで一定の品質、コスト、開発期間を守れるかということである。たとえば、PMBOKで定義されている範囲でプロジェクトルールを決めてしまえば、誰がやってもだいたい同じ結果が出るかどうか、CMMIだと状況はかわるか、という話である。前から言われていることだと思うが、なぜか最近よく耳にするようになったので書いてみる。

サンプル数が少ないので、結論を出すにはまだまだ足りない感じがするが、次を仮説として持ちつつある。人材や開発対象が比較的安定して、変化がそれほど大きくないところでは、プロセスさえ決めてしまえば、プロジェクトはまわせる、と考える人が多い。人材や開発対象の流動性が大きな組織では、プロセスも大事であるがモラル、モチベーション、文化も重視すべき、と考える人が多い。みなさんはどう思われるだろうか？

私自身も根拠が不十分と考えているので、十分な根拠やサンプル数が得られるまではこれに関する議論は避けたいところではあるが、なんとなく納得できる話のような気もする。

たとえば、プロセスである程度まわせると考える方々は比較的信頼感で成り立っているように思う。代表的な意見として、仕事としてやっている以上当たり前のことを書いているのだから、ある程度の記述をすればしばれるはず。決まりの定義の裏をかいてすり抜けるようなメンバはいない、という感じだ。

一方、モラル、モチベーション、文化も重視すべきと考える方の代表的な意見としては、あまりに煩雑なきまりやプロセスに対してはそれを無視する、もしくは形だけで繕ってしまう、というものがあった。政治の道具として大事な報告を敢えて実施しないというものや、極端なものだと、キーパーソンが精神的に病んでしまって会社に出てこなくなる、というような反例を挙げつつ、きまりやプロセスだけでは縛れないという意見もあった。

今回の話は、特にソフトウェア開発に限った話ではないが、ソフトウェア開発は人手の作業が中心に進んでいくため、きまりやプロセスで制御できるのかどうかという議論が起こりやすいのではないかと思う。前に書いたこのエントリと関連が深い話なのかもしれない。