PMBOKでのアジャイルの位置付け|ウォーターフォールだけじゃない

  • このエントリーをはてなブックマークに追加
  •      
  • LINEで送る

どうも、マツバラヤスユキ(@yaspontax)です。

 

皆さんは、プロジェクトマネジメントの知識体系であるPMBOKと聞くと、

すぐに大規模システム開発向けのウォーターフォール型の

プロジェクトマネジメント手法だとイメージされるのではないでしょうか?

PMBOKはウォーターフォールに限らない

 

実は、PMBOKはウォーターフォール型に限ったものではないのです。

従来からウォーターフォール型のみを対象としていた訳ではなく、

プロジェクトマネジメントが建設業や製造業において開発されてきたことに由来して、

プロジェクト規模も期間も非常に大きく、基本的に後戻りが許されない為、

単純にウォーターフォール型のプロジェクトマネジメント手法がマッチしていたと言えます。

 

想像になってしまいますが、

プロジェクトマネジメントが開発され普及し始めの時代は、

技術革新と共に急成長を遂げていた時代であり現代のようにモノが溢れている状況ではなかったことから、

多少問題があったとしても目を瞑ることができたのではないかと思います(これは個人見解)。

 

IT業界とウォーターフォール型のアンマッチ

 

しかし、インターネットが普及し、ビジネスにおけるIT活用が当たり前の時代に突入し、

システム開発のニーズが高まり、案件数が爆発的に増えてきたことで、

IT業界にプロジェクトマネジメントが入ってきて、

従来の建設業や製造業でのプロジェクトマネジメント手法である

ウォーターフォール型の手法をそのまま適用することになったのだと思います。

 

国内においては、ユーザー企業のシステム開発案件をSIerが請け負って開発するケースが多いかと思いますが、

ユーザー企業の担当者はIT知識が豊富でシステム開発を深く理解しているケースは少なく、

ウォーターフォール型の基本的な考え方である上流工程が終わっていないと次の工程に進めないという点において、

要件定義が正しく完了できないという問題が発生してしまうのです。

そのまま、ズルズルと期間が過ぎていき、リリース予定日直前には徹夜の日々が続くといった通称デスマーチが起こるのです。

 

また、ITを活用して行うビジネスの変化のスピードは非常に早い為、

一度、要件定義を完了したとしても、

半年も1年も前の外部環境と同じ状況という訳にはいきませんので、

全体をもっと短い期間でプロジェクト完了できる手法が求められていたのです。

 

PMBOKにおけるアジャイル

eXtreme Programming(XP)や2001年にアジャイルマニフェストが発表されたことからアジャイルが広まっていき、

FDD(Feature-Driven Development)、リーン、DSDM(Dynamic System Development Method)、カンバン、スクラムと発展していった歴史となっているようです。

 

PMBOKにおいては、米PMI(Project Management Institute)が2017年9月に発行したPMBOKガイド第6版において、アジャイル型環境や適応型環境で適正なプロジェクトマネジメン ト実務慣行を適用するための初のガイダンスが追加されています。

 

PMBOKガイドには、アジャイルについての詳細説明がある訳ではなく、各知識エリアの「アジャイル型環境や適応型環境への考慮事項」にアジャイルの場合はチームの自律性を高める必要があり、ステークホルダー・エンゲージメントの重要性が高くなるといった全体像が読み取れる程度の内容となっています。

 

PMIから、アジャイル実務ガイドも出版されており、こちらがアジャイル導入を支援する内容となっています。

 

現在のPMBOKでのアジャイルの位置付けとしては、

ウォーターフォール型飲みに限っている訳ではなく、

IT業界やシステム開発プロジェクトの文脈からアジャイル適応の必要性を感じており、

プロジェクトマネジメント手法の一つとして知識体系の更新を行ったといった形となります。

 

アジャイル導入の課題

PMBOKにもアジャイルが明記されたことで、

ユーザー企業とSIer間で行われているシステム開発においても、

アジャイルの導入の検討が進んでいることと思います。

 

しかし、現在、アジャイル開発が上手くいっていると聞くケースは

往々にして、自社開発をしている企業です。

 

ユーザー企業とSIer間で行われているシステム開発においては、

契約形態が大きな課題になっているのではないでしょうか。

 

アジャイルにおいては、ウォーターフォールと違って、

一度に計画しきらない為、詳細なスコープを明確にした上で、

納品物を定義して契約することが困難となる為、

ユーザー企業側としてはリスクに感じてしまうケースがあるのです。

 

ユーザー企業側でのアジャイル導入の理解が進み、

デメリットよりもメリットを強く感じることができれば、

変わっていくのだと思います。

 

(個人見解ですが)

本来、アジャイルに移行した方が良いシステム開発をSIerに委託しているユーザー企業においては、

即刻アジャイル移行を進めるべきだと思います。

 

デメリットを強く感じるがあまりアジャイル移行ができずに、

衰退していってしまう企業が出てきてしまうのではないでしょうか。

 

現代の変化のスピードに対応していく為には、

あまりにもウォーターフォール一本では厳しいと感じています。

 

以上です。

スポンサーリンク

よろしければtwitterでフォローを!

twitterで積極的に情報発信しております!

 

主に以下のようなことをつぶやきます。

・PM関連の気付き・学んだこと

・チームメンバー育成に関する実体験

・日常のどうでもいいこともたまに(笑)

 

「記事の内容が参考になった」、「今後も記事を見たい」、「今後の成長に期待する」などと思っていただける方も、ぜひフォローください。


twitterへ移動する

SNSでもご購読できます。