ネット環境の進化、クラウドの普及などで企業の情報システムが軽量化しつつある。それに伴い、システム導入のプロジェクトマネジメントにも変化が起き始めている。

　多くのシステム開発会社（SIer）やシステム系コンサルティング会社では、WBS（作業分解構成図：Work Breakdown Structure）を引いて、課題管理やリスク管理を決まった帳票でやって・・・、という「手順」を教えられ、プロジェクトマネジメントとはそういうものだと刷り込まれ、それが実際に現場で行われてきた。

　確かにシステム開発にプロジェクトマネジメントが導入されたことで、プロジェクトの進行は格段に効率化された。しかし最近は過大な管理業務をしているのを見て、逆にむなしさを感じるようなシーンも多い。

　そしていまだに現実問題として、プロジェクトマネジメントの手法に沿っていながら「うまくいかないプロジェクト」は世の中にあふれかえっている。

　現場の感覚では、これまでのプロジェクトマネジメントのやり方が通用しない領域が増えてきているような気がしてならない。

これまでのプロジェクトマネジメントに違和感を覚える3つの理由

　そのような違和感が生じる理由は3つほど考えられる。

　1つ目は、昨今の経営環境の変化の速さである。プロジェクトがスタートした時点の経営環境が完了予定時点では変わっていて、必要な機能も変わってしまっている可能性が高いということだ。

　経営者が確認、参照したいデータは常に変わるし、仕事のやり方も変えていかないと競争に生き残れない。ビジネスモデルや企業規模だって変わるかもしれない。そういった激しい変化によって生じる当然のニーズに、システム開発の現場は対応できているだろうか？　当初のスコープを遵守することに躍起になって本末転倒になっていないだろうか？

　2つ目は、プロジェクトの課題管理の中での「解決」部分の重要性の高まりである。通常、プロジェクト推進上の課題を整理して解決状況を管理する、というのが一般に行われているわけだが、「どう解決するか」に手を入れられないと話にならない。

　経営環境の変化が激しくなると、システム開発中に出てくる課題も難易度が高いものが増えてくる。要は、決まらない要件に対してどこかで折り合いをつける必要が出てくるということだ。

　しかし、現在のプロジェクトマネジメント体系の中では、そのあたりの課題を「解決する」という部分がスコープに入っているとは思えない。しかし本質論で考えると、課題の解決に力を注がないとプロジェクトは成功しないはず。

　例えば、「今はこういう要件だが、もしこういうことが起きたら、こういう画面が必要になるはずだ」「それを考慮すると、今はこういう作りにしておかないといけない」といった判断が必要になるだろう。こういったことを合理的に判断し、関係者で合意を取る。その機能が重要なのである。