|
||||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||||
| 計画の正確性を求めるより変化に柔軟かつ迅速に対応 | ||||||||||||
|
一方、ITに目を移せば、欧米ではITプロジェクトの不確実性が高いことを認め、柔軟に対応するプロジェクト管理手法を発展させてきた。 たとえばEVM(Earned Value Management)は、プロジェクトの実績完成度によって、プロジェクトの予実金額を管理する方法だ。また、タイム・アンド・マテリアル(T&M)という契約方式では、ITベンダが実際に掛かった人月分を、定期的に顧客に請求する。ただし、プロジェクトの期間中に進捗度を顧客と相互に確認し合うことが前提だ。これにより、ユーザ企業がベンダとともに、予算をオーバーしないようにプロジェクトを実行し、目標を達成していく。 これに対して、日本はどうだろうか。筆者が、はじめて企業の情報システム部門に勤務した際、パイロットだが十億円を越えるERP導入プロジェクトに参加した。 会社側は、はじめて外部から導入コンサルタントを起用し、T&M方式で契約した。コスト意識は非常に明確で、ユーザ部門から出た要件変更は、必ず会社の管理層と導入チームがコスト対効果を充分に議論して優先順位を決めていった。また毎月、各コンサルタントの貢献度と、プロジェクトの進捗度について、金額に換算して議論した。 その結果、プロジェクトは予算、納期とも計画を下回り、余った予算分でプロジェクトチームの旅行まで賄えたほどだ。当時、同システム部門で30年以上働いていたメンバーが、「今までのシステムプロジェクトは、少なくとも半年以上伸びるのは常識だったのに、このプロジェクトは奇跡だ!」といったことを憶えている。 振り返って見ると、成功の原因は様々だ。ユーザ側の管理者と経営者が積極的に参画した点も重要だ。また、ユーザとベンダ間に共通かつ明確な進捗指標が存在したことも見逃せない。つまり、T&Mが奏功したわけだ。 ところが多くの場合、日本では大規模のITプロジェクトでも、スコープと要件が曖昧な段階で、一括契約・固定予算で進める。 そのためユーザ企業側は、プロジェクト予算に対する責任を持たなくて良いと思い込み、計画段階で予想できない、または仕様書で表現しきれない要件をベンダに丸投げする。結局、要件定義だけで予算を消費してしまったり、要件をあれこれ取り込み過ぎて膨大なシステムになってしまったりする。 また、次のような声もよく耳にする。
表2:ユーザ企業の声 だが、どこの国の企業でも予算が承認されたら変更しにくいものだ。また、本当にすべてベンダの都合だとしたら、いずれの国のユーザ企業でも認めないだろう。 T&Mを実現するには、ベンダとユーザ企業が一体になって、実績進捗のためのマイルストーンを真剣に設定・評価する必要がある。そうすることで、プロジェクトの不確実性を抑えられるようになっているのだ。 |
||||||||||||
| 米国のITもトヨタに学びはじめた | ||||||||||||
|
米国には、日本のものづくりの思想をベースにしているシステム構築方法がある。代表的なのは開発手法の「アジャイル」と、プロジェクト管理手法「リーン・プロジェクト・マネジメント」だ。 前者の核は、「アジャイル・マニフェスト」というものに記述されている。「プロジェクトの進捗は動くプログラムで測る」や「開発チームのコミュニケーションはフェース・ツー・フェースが最も効率的」「契約より顧客」など、いずも日本的な発想を宣言している。 特にマニフェストの最後では、「計画の遵守より変化への対応」と「とりあえず作れ」と提言している。これは、事前計画を中心とするウォータフォール型とは対照的といえる(図2)。 ![]() 図2:アジャイル開発とウォーター型開発の違い 出典:雑誌Fujitsu 2005-11月号 vol.56,No6,606ページ 後者は、「ムダを排除する」という発想の下に、製造ラインの仕掛り在庫をできるだけ持たないようにする考え方だ。具体的には、ユースケースや設計書、テスト計画、手順書、変更要求など典型的なプロジェクト文書を必要な時までに作成しないようにしている。早すぎると作り過ぎてしまう。また、必要性と要件自体が変化してしまう可能性があるからだ。 そのため、プロジェクトタスクは、基本的に消費ポイントから上流タスクを引っ張るという「プル型」方式で進めていく。 |
||||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||


