開発プロセスを決めるということは進捗管理方法を決めるということ

開発プロセスに対する幻想を破壊する
http://www.atmarkit.co.jp/farc/rensai/process01/process01.html

----
　開発プロジェクトにおける開発プロセスとはまさに、登山における最初のルートです。開発チームの経験、技術、関係各社（者）の状況から、最適と思われる開発プロセスを“作る”のです。この開発プロセスを作るときに、毎回ゼロから作るのではなく、基本的な作業の流れと、個々の作業の実施要綱をあらかじめ標準プロセスとして用意しておき、それを適宜修正しながら活用すると、初心者でも忘れ物をしないくらいにはできます。標準プロセスとは、その程度のものと考えるのがよいのです。
----

ソフトウェア開発における「開発プロセス」とは、個人の作業を規定するもの、という認識が一般的なようだが、ちょっと違和感を感じている。開発プロセス＝開発者を縛るものという理解ではなかなか現場にうまく浸透しないだろう。

素晴らしい開発プロセスがあったとして、その開発プロセスを使うと何が素晴らしいのだろうか。素晴らしい開発プロセスを利用すると、「誰がやっても成功する」というわけではない。「誰がやっていても、外から見てどれくらい進んでいるかがわかる」ということが出来るのが、素晴らしい開発プロセスだと思う。

要するに開発プロセス＝進捗確認方法という位置付けである。そこには成功とか失敗とかいう言葉はなく、同じ開発プロセスを使っても、１つ１つのプロセスの作業が遅ければ納期に間に合わなくて失敗だし、優秀な人でも高コストになって納期に間に合ったが予算オーバーで失敗ということも当然ありえる。

開発プロセスを決めることで、進捗確認が外から見えるようになり、プロジェクトをどうするかの判断が逐次可能になるというのは、経営者やマネージャーや発注側の立場から見ると非常にありがたい。開発プロセスがあれば成功するのではなくて、失敗しそうなプロジェクトのリカバリーをしやすくすることが出来る。それ以上の期待はしてはいけないし、期待したいのなら開発プロセス以外に求めて欲しいところだ。

また、１つ注意したいのは、ソフトウェア開発の特徴として進捗は前に進むだけでなく後ろに戻ることがある。要は仕様変更により開発内容が変わったり、いくつか作ったものがいらなくなったりするのである。しかし、そのことが悪いと言っているのではなく、進捗が動くことが外から把握できる、ということが大事なのである。

開発プロセスを決めて、進捗をトラッキングできるようになれば、その進捗の履歴をたどることで、仕様変更にどう対応するべきか、どこで人員がピークになるのか、進捗が止まっているように見えるのは開発プロセスが悪いのかどうか等が解るようになるのではないだろうか。ある軸が定まっていると他の評価がやりやすくなると言えるだろう。

ついでに言うと、作業の標準化というのは、開発プロセスで決めることではなくて、プロジェクトチーム内で説明したり教育して浸透させていくべきことであり、頭ごなしにおしつけるものではない。それを今まで開発プロセスと呼んで来たのであれば、単純に開発TIPSとでも呼ぶべきであり、経営陣にまで影響がある開発プロセスとは切り離す方がよいと思う。

技術者のための開発プロセスではなくて、会社全体のための開発プロセスであるという意識がないと、開発プロセスという名前だけが一人歩きしてしまうし誰も使わない。せっかく何か作るのであればちゃんと使えるものにしないといけませんね。