update it, Inc.社長のブログ

会社の前から駅のほうに向かってとった写真です。

三角形の屋根の辺りから階段を降りたところに駅があります。先日ちょうどそのあたりで「深キョン」がドラマを撮っていました。

プロジェクトを確実に破綻させる方法としてご紹介する３つ目は、「曖昧プロセス」です。システム開発の開発プロセスが定義されているというのはすばらしいことなのですが、きちんと運用されていない場合にはかえって弊害になるという話です。

最近ではユーザ企業側でも自社の開発プロセスがきちんと定義されているところが多いです。これ自体は悪いことではありません。そしてシステムを開発する人・チームが常に同じであれば、長年の付き合いの中でそれらのプロセスは自然に理解され、伝承されていくでしょう。しかし、人は入れ替わるものです。またパートナー会社が変わるということもあります。

問題はそうしたときにドキュメントに書かれた開発プロセスに具体性が無く、実際の運用においてどうすべきかが曖昧な場合に発生します。ドキュメントにはいいことが一杯書いてあるんです。でもじゃあ、このときには何をどうしなければならないのか、っていう具体的な進め方が曖昧だと、プロセスについての議論が沸騰して、実際のプロジェクトが進まなくなる、なんていう馬鹿馬鹿しい経験をした人って多くありませんか？

ある意味、プロジェクト推進者が「ものがわかる人」ならば柔軟な対応で問題にはならないのですが、逆に厳密さを追求するタイプの人だと最悪です。

そもそもユーザ会社の開発プロセスって、せいぜい１つか２つのタイプしか定義されていないことが多く、その中でさまざまなタイプの開発を網羅しようとしているので、プロジェクトの種類によっては意味を成さないような項目が並んでいることが多いと思うのです。でもそのような場合にどれは行ってどれは行わないっていうことが曖昧だと、開発者側がそれに右往左往される。先に述べた「伝承された」人達にはここのあたりのことは自明だと思い込んでいるのですが、それがさらに曖昧さの入り込む原因になっているのです。

盛り込みすぎたプロセスも曖昧になりやすいです。プロセス定義書だけで厚さ？センチなんてものは、おそらく運用不可能です。で、結局これはやる、これはやらないなんてことが現場で判断せざるを得ない。ところがこの判断のやり方に明確な基準が示されていないと、人によってやったり、やらなかったり、となるわけです。この状態で先に述べた、厳密さを追求するタイプのプロジェクト推進者がいたりすると、開発プロセスを守るためだけの作業に時間を食われ、プロジェクトは確実に破綻します。

本来開発プロセスはプロジェクトをうまくまわすためのツールであって、それ以上のものではないはずです。目的と手段を取り違えないよう気をつけていれば、この手の問題は起こらないはずなのですが、みなさんのところはどうでしょうか？