ITシステム開発プロセスについて（過去のプロジェクト振り返りその11）

システム開発プロセスについては様々な方法論があるが、ここでは個々の方法論については述べない。
過去のプロジェクトにおいてよく体験してしてきたことだが、開発方法論の大枠（ウォーターフォールでいくとか）は、計画段階で決めるものの、方法論を実際に実行するための細部にわたるプロセスは、必要性が見えてきたときに初めて検討され始める傾向がある。

初期段階において、開発プロセスの「実際の」運用を決めておかないと、必要性が高まってきたときに、決め始めるのではオーバーヘッドが大きいとよく感じる。

スティーブマコネルの「ソフトゥエアプロジェクトサバイバルガイド」には、計画段階でのプロセスの決定を推奨している。例としては以下のプロセスを事前に決定する必要があると述べている。

• 変更管理
• 品質保証
• 欠陥追跡
• システム統合（システム間インターフェースの考え方）
• ソースコードのバージョン管理
• スケジュール（見積含め）

例えば、変更管理を例にとると「変更を誰がどのように評価し、受け入れるのか」が実際に変更が大量に積みあがるまで管理プロセスが決定していないことがよくあった。

またスケジュールに関しても、当初のスケジュール（ドンブリ勘定でとりあえず置いてみたもの）が、やはりうまくいかないので３ヶ月から２週間ごとに再見積もりとスケジュールの引き直しを求められたことが、よくあった。

ちなみに当初スケジュールを自分で見積もらせてもらったことは、ほとんどない。どこかの誰かが適当に引いたものの順守を求められるという理不尽なことがよくある。

プロセスの実際の運用が遅れれば遅れるほど、プロセス運用の試行錯誤（突貫工事で作らなければならなくなるため）と本来の作業が重なり合い非効率な、場合によっては本来の作業を阻害するような事態が引き起こされる。