開発管理のシリーズでブログを書いていたが、ある意味一番重要な開発プロセスの話が後になった。開発プロセスというとピンとこない方も多いかもしれないが、開発手順書と考えた方がわかりやすいかもしれない。

　それでは、その開発プロセスであるが、企業／事業部などの単位で設定されていることが多い。よく開発計画書（プロジェクト計画書）との関係がわからなくなる人がいるが、開発プロセスは、複数のプロジェクト共通の手順書、開発計画書はプロジェクト（開発案件）毎の計画書である。従って、開発計画書をどのように作成するかも、開発プロセスで記載してあることになる。

　コンサランスでも、開発プロセスの作成コンサルティングを請け負うことも多い。しかし、ただ単に、”開発プロセスを作ってほしい”とか”開発プロセスが欲しい”という場合はお断りすることが多い。

　というのは、開発プロセスは、品質、コスト、納期を目的としたものでなければならいないが、開発製品毎にその状況（要求）は異なる。つまり、過剰品質になってもいけないし、組織にあった開発プロセスが必要になる。また、単に他人が作成した開発プロセスでは、その意図が不明であり、本当の意味で改善はできないからである。通常は問題発生による再発防止などを通じて、開発プロセスは積み上がっていく。

　ではコンサルティングではどうするかというと、下記の２通りを状況により使い分ける。

　①コンサルタントとして状況をヒアリングし改善案に繋がるヒントを提示する。

　　これを担当者側で考え、開発プロセスを作成していく。

　②コンサルタントとして状況をヒアリングし改善案を提案する。

　　それが理解されれば、開発プロセスの一部となる。それを繰り返し積み上げていく。

　実際にはコンサルタントも今までの経験では改善できないような状況の場合もある。この場合は、担当者と共に改善案を考えていく。話は元に戻るが、既に存在する開発プロセスを

提示するのはコンサルタントの仕事では無いと考えている。

　それでは、どのような項目を開発プロセスで規定すればよいのだろうか？

　（続きは次回のブログで）