今更ではありますが、IT開発プロジェクトのマネジメントで苦労されている人は多いと思います。
最近ではスクラム等のアジャイル開発手法が取り上げられることが増えましたが、今日はPMBOKという古典的なメソッドについてのお話です。
大きなテーマになりますので小出しにしていきたいと思います。今回はそのプロローグとして「スコープ管理」です。
PMBOKとは
PMBOKとは「Project Management Body of Knowledge」の略です。
簡単に言いますと、IT領域だけではなく一般的なプロジェクト型案件を成功させるためのノウハウ体系ということです。
「ピンボック」というなんだか可愛らしいネーミングからは想像できないお固い内容で構成されています。
その概要についてはネットを検索すれば沢山出てきますので私から説明はしません。
参考：Wikipedia
ただ、1996年にPMBOKの第1版が発行されて以来、時代の変化と共に発展しており、最新版の第7版ではアジャイルを取り込んだ内容に大きく変化していることは補足しておきます。
10の知識体系
PMBOKには膨大なナレッジが含まれていますが、ここではその中で定義されている「10 Knowledge areas」＝10個の知識体系から説明します。
10個というキレの良い数字で分類された領域毎に、プロジェクトマネジメントで必要なガイドが提示されています。
私が以前学んだ2001年辺りにはその10個を教科書的に直列に並べ、１つ１つ順番に読みながら知識として学んでいくスタイルが主流でした。
こんな感じです。
しかしこの10個のリストが自分にとっては理解しにくいものでした。
領域毎に講師の先生が変わったことも原因だったのかも知れませんが１つ１つの領域のナレッジが独立している印象が拭えず、どうもPMBOKの全体像が掴めなかったのです。
また、PMBOKにはもう１つの考え方として「5 process groups」＝5つのプロセスのガイドもあります。
こんな感じです。
これがまたあまり親切ではなく、簡単に言うと「この５つのプロセスを通じて10個のナレッジを上手に活用してね」というのが結論です。
そのため、自分にとっては10領域のナレッジがバラバラにインプットされており、実践においてもこの10個を有機的に連動させながら活用できていないと言うジレンマを抱えていました。
PMBOK全体の再構成
そこでこの10個を下図の様な全体像のイメージで理解して、実践でブラッシュアップすることにしたのです。
※枠と線、10個の箱の位置には意味があります。番号はPMBOKで説明される順番です。
スコープを決める前段階
スコープを決める前にまず最初は「統合管理」です。
いわゆる10個のナレッジを統合して活用する、ということなのですがまとめると概ね以下の3点が重要だと感じます。
・プロジェクトのGoal、達成目標、成功条件を定義して関係者と合意する
・10の知識体系をバランスよく活用してプロジェクト企画と計画立案をする
・変更発生時に９個の知識エリアへのインパクトを調整しQCDを再計画する
プロジェクトマネージャーの役割そのものが定義されていると思えばOKです。
スコープを決めること
そして次にまずは「スコープ」を仮決めすることです。
仮決めというのはスコープは特にプロジェクトの上流工程では変更に直面しますのでまずは仮に決める「=仮説を置く」ことで柔軟性が高まります。
スコープを決めることは簡単に言うとプロジェクトが取り扱う対象範囲を定義することです。
また、スコープは統合管理で設定するプロジェクトのGoal、達成目標、目的ねらい等と密接に結びついていることを忘れてはなりません。
例えば、
・解決すべき問題の範囲
・対策すべきニーズや要求事項の範囲
・システム化の対象となる業務範囲
・作成する成果物の範囲やレベル
・最終的には何を作るか、何の問題を解決するか
等々です。
しかし、近年ではITシステムへの要求が業務効率化からビジネス価値向上に大きくシフトしていることもあり、ビジネスや事業おいてどの様な価値の獲得を目指すのかにより、プロジェクトのスコープも単純ではなくなっています。
以前はシステムを開発して本稼働させるところまでをスコープとするのが当たり前でしたが、最近ではITを活用して価値を創造するまでをスコープとするようなプロジェクトも見受けられます。
とは言え、仮にでもスコープを決めないと後に続く「スケジュール」や「コスト」の議論が進まないので私はこれを最優先事項と考えています。
しかし、これを決めるのはなかなかやっかいです。
なぜならば、ソフトウェア開発プロジェクトの初期段階では見えていない要件が多いからです。
プロジェクトの後半で起こること
例えばプロジェクトを進める中で以下の様なことが起こり得ます。
・裏で動いていたプログラムがあった（しかもそれが巨大で仕様書もないやつ）
・現場利用者のニーズが後から出てきた（しかもそれが重要で至極まっとうな意見）
・コンシューマーが想定していない使い方をしている（使ってみないと判らない）
・そんな機能はあって当たり前、あなた達はプロなんだから言わなくても判ってるでしょ！
・影響力が大きい人物が途中から参画してきて今までの議論を無視した意見を言い始める
等々
笑い話の様ですが今まで私も経験してきたことですので一般的にも「プロジェクトのあるある」なのでしょう。
変化を許容する
DXが叫ばれる近年では、多くのスクラッチ開発型のプロジェクトの1年、2年先の環境変化を予言でもできない限り、上流工程ですべての要件を洗い出すのは至難の業です。
PMBOKもの第6版まではスコープはプロジェクトの初期段階で決められるもの、決めるべきもの、変化は「悪」でありできるだけ減らすものであるという大前提がありましたが、第7版では大きく変化しています。
アジャイル開発ではそもそも「スコープ」は最初から決められないもの、決めてはいけないもの、そして「変化」こそがプロジェクトの価値を高める機会である、という前提に立っているので真逆の発想です。
昨今ではウォーターフォール型のプロジェクトでもスコープが変化することを許容し、変更要求が発生したした時にどのような対応をするのかをあらかじめ決めておく、ということをやり始めています。これには変更管理、リスク管理の考え方を活用します。
さらに、変化することを見越したスモールスタート方式、ステップ展開的な計画にしておくことがより重要になってきていると思います。これらはスケジュール管理、コスト管理のノウハウを活用します。
この様に柔軟な考え方でプロジェクトスコープを捉えておくことが近年のプロジェクトマネジメントの１つ柱になっていると考えています。
そして次の領域へ
スコープを仮決めしたら次はQCDのマネジメント中核３要素を決めることです。
言い替えると、プロジェクト目標を達成するための、D:スケジュール（納期）、C:コスト（予算）、Q:品質（テスト検収条件）の制約に関する合意をするということです。
いつまでに、この位の予算で、こういう試験に合致できるレベルのシステムを開発してくれ！（開発します！） というイメージですね。
また、この中核３要素のナレッジは互いに連動しており、PMBOK以外の所からも様々な手法やメソッドが生み出されています。
C:コストの領域では、様々なプロジェクト規模の見積手法、コスト管理手法、生産性向上手法など
D:スケジュール領域では、WBSやスケジューリングツール、進捗管理手法など
Q:品質領域では、各種のテスト技法、レビュー技法、設計ドキュメント手法など
これらはとても一夜では語りつくせない奥深いものがありますので、それはまた別の機会に。
「スコープ管理」のお話しにお付き合い頂きありがとうございました。
〆
コメント