ITのプロジェクトマネジメントの重要性

ITの開発プロジェクトにおけるマネジメントの重要性について考えたい。

IT開発プロジェクト

　ITにおける開発プロジェクトは、基本的に製造業や建設業のプロセスと同じである。
まず製品の開発コンセプトや機能性の「要件」を固め、「設計」書に落とし込み、「開発（プログラミング）」する。その後、検査のため機能「テスト」を行い納品される。納品後は、「運用」によるアフターフォローが開始する。

システム開発の難しさ

　システム開発は、製造業や建設業よりも私は難しいと思っている。
例えば以下のように、ＱＣＤの面で成功するためのリスクのポイントが多く潜んでいるためである。
　
①．システムの完成状況（出来高）が見えにくい
②．設計書からプログラミング化する際に、個人の裁量が高い
　（コーディングがプログラマーのスキルに依存する部分が多い）
③．データパターンを網羅した多くのテストケースが必要

　上記の理由として「無形性」という面が大きく影響している。
システムは無形資産に資産計上される通り、電子上の仕組である点や、その元になっているのはプログラムであり、それだけでは製品（例えばウェブ画面など）のイメージがわからない。そのため、ＱＣＤの測定を難しくしているためである。
　したがって、よく「プロジェクトが火を噴く」とか「炎上プロジェクト」という形で形容されるが、失敗するプロジェクトが散見される。

※そのため、先日のブログ（下記）でも説明したとおり、開発ベンダーとしては請負契約より準委任契約の方が好まれるというのはこういう点からも来ている。

プロジェクトマネジメント

　こうしたリスクを回避するため、開発プロジェクトをマネジメントすることが重要である。

　プロジェクトマネジメントの手法は建設業界から発展したと言われており、ＰＭＢＯＫなどのようなフレームワークとして体系化されている。私の最初の会社は某プラント建設会社のＩＴ子会社であったが、企業内の建設プロジェクトで使用されるその名もまさに「プロジェクトマネジメントシステム」を運用していた。そして、いまやこのプロジェクトマネジメントの手法がＩＴ業界でも広く適用されている。

マネジメントの重要性

　システム開発のマネジメントとは、プロジェクトの方向性を決めそこに対する道しるべを定め、プロジェクトをゴールまで導けるよう、リーディングする役割である。どこかで聞いたような、そう、企業の経営者と同じ役割である。

　特に、システムの最終的な姿や成果物のアウトプットのイメージを定め、認識合わせをすること。その上で、アウトプットに対しどういったプロセスを行うことで達成するのか、そのプロセスで使用する方法論や意思決定の基準などのメソッドや制約事項を整理することが非常に大事である。これをおろそかにすると失敗する。

　実は、私の現在携わっているプロジェクトもこの部分に課題を抱えている。
私も途中から参画したためすでに走り始めている状態であったのだが、開発ベンダーにこの部分をある意味丸投げしている状態であった（今もその傾向は続いている）。

　それなりの大手のコンサルベンダーなので、それっぽくリーディングしているように見えるが、たとえば、要件定義工程のアウトプットがどの粒度でどの内容までが必要なのかが合意できていなかったり、だれがどういった判断基準でその機能要件の採否を判断するのか、といった部分が共有できていない。その結果、発注者側が「現在のタスクの目的がわからず」ベンダーの言われるがままこなしているといった状態に近い。

今後への展望

　こういった状態を打破する必要があるため、是々非々で１つ１つコントロールしていくことが私には求められている。
　
　ベンダーに対しても、あくまでビジネスとして発注者側と線引きしたいという思いや、言われないから本来のプロセスを踏まないというやり方は今後は通用しなくなるだろう。単純にそういった知見が無い、という可能性もあるが。いずれにしろ、発注者側である顧客と同じ目線で「伴走型」で進めていくべきというのが、ベンダーにとってもＣＳの観点からも本来は必要なはずだ。

　こうした形で、プロジェクトを担うメンバーはベンダー限らず１つのチームであるため、それら全員が「共通目的」「協働意欲」「コミュニケーション」を持った組織体制が一番重要であり、求められている部分かと感じている。

　まさに診断士の知見が活かせそうである。