◆ＡＰＭのフレームワークと価値

ジムハイスミスが提案しているＡＰＭには、価値、原則、プロセス、プラクティスからなるフレームワークがある。

価値は前回説明したように、

（１）コミュニケーション＞プロセス
（２）プロダクト＞ドキュメント
（３）変化への対応＞計画
（４）市場や顧客との対話＞要求分析・市場調査
（５）自律＞統制

といったものだ。

━━[PR]━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
「アジャイルプロジェクトマネジメント入門【ＰＭＡＪ共催】」
http://www.pmstyle.biz/smn/pm_agile.htm
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

━━[PR]━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
「アジャイルプロジェクトマネジメント実践【ＰＭＡＪ共催】」
http://pmstyle.biz/smn/pm_agile_pra.htm
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

◆プラクティス

最後の要素はプラクティスだが、これはマネジメントとして行うべきことである。ＰＭＢＯＫ（Ｒ）でいえば、ツールと技法というのがあるが、これだ。詳細は追って説明するが、ツールと技法と同じようにプラクティスは自由に定義できる。PMstyleではＡＰＭのオリジナルのプラクティスにいくつかの要素を加えている。たとえば、構想プロセスであれば、

・商品ビジョンボックスとエレベータテストステートメント
・プロジェクト憲章
・ステークホルダ分析とコミュニケーションプラン
・顧客チーム・開発チーム間のインタフェース
・プロセスやプラクティスのテーラリング

といったプラクティスを準備している。以上から分かるように、フレームワークは計画重視型のプロジェクトマネジメントと同じようなものだ。この点はあとあと、実装上の重要なポイントになるので、頭に入れておいてほしい。


◆アジャイルの本質

アジャイルプロジェクトマネジメントの本質は管理コストをかけないようにして、その分を顧客対応コストに回すことにある。管理コストで大きいのは、リスク管理やコンフリクトの解消が上げられるが、これらのコストを顧客対応コストとして顧客への透明性を確保する。言ってみれば、そのためにどのようなプラクティスが必要かということを考えなくてはならない。

アジャイルには独特の価値観がある。従来のプロジェクトマネジメントとの対立軸を上げてみよう。右が従来の価値観であり、左がそれに対応するアジャイルの価値感だ。

（１）コミュニケーション＞プロセス
（２）プロダクト＞ドキュメント
（３）変化への対応＞計画
（４）市場や顧客との対話＞要求分析・市場調査
（５）自律＞統制

━━[PR]━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
「アジャイルプロジェクトマネジメント入門【ＰＭＡＪ共催】」
http://www.pmstyle.biz/smn/pm_agile.htm
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

◆アジャイルの前提

アジャイルプロジェクトマネジメントには、原則や価値があるが、それ以前に「前提」がある。この前提は、アジャイルプロジェクトマネジメントの手法に関わらず、つまり、ジムハイスミスのＡＰＭであって、ＳＣＲＵＭであっても同じように成り立つ。その多くは、精神的なものであり、アジャイルマインドと呼ぶことにしよう。

アジャイルマインドがもっとも象徴的なのは、リスクに対する態度（スタンス）である。プロジェクトマネジメントにとってリスクは敵である。そして、組織を上げて、徹底的にリスクと戦うのはプロジェクトマネジメントだといっても過言ではない。

アジャイルでは、リスクに対してどのような態度をとるのか？「戦わない」という態度である。もし、手元に今取り組んでいるプロジェクトのリスクリストがあれば、取り出して眺めてみてほしい。プロジェクトのタイプにもよるが、ＩＴのようなプロダクション（生産）型のプロジェクトだと、リスクの７～８割は上位組織、顧客、社内関係部門、プロジェクトメンバー、ベンダーなどのステークホルダとの利害関係がリスクの源泉になっているのではないかと思う。

◆透明性を確保し、リスクと戦わない

なぜ、リスクが起こるのかというと、壁があり、壁によってリスク関係の対立が発生するからだ。この壁の正体は、取引契約であったり、立場の違いだったりするので、そう単純な話ではないが、壁がなくなればリスクの多くは消えることになる。

では壁を取り除くにはどうすればよいか。透明性の確保である。誤解のないようにしてほしいが、これはすべてをオープンにするという意味ではない。取引である以上、Ｗｉｎ－Ｗｉｎの関係であっても、完全にオープンになることはない。むしろ、すべてのステークホルダが納得する場を作るというイメージに違い。

たとえば、ＩＴベンダーが顧客からのプロジェクトを行う場合に、リスクをどこまで共有するかが問題になる。この問題に対して、圧倒的に多いのは、出せるものと出せないものがあるという態度である。福島原発事故の初期対応で、政府や東電が情報隠ぺいをしたのはけしからんという人でも隠すべきだという。

◆オープンマインド

オープンであるときに、リスクは一切、隠すべきではない。ここでも誤解がないように言っておくがリスクを隠さないというのは、隠すべきことがあってはならないという意味である。最低限でも、オープンにすることによって露見した問題が確実に改善されなくてはならない。オープンマインドというのはそういうことだ。

このような態度をとれば、基本的にリスクはすべて共有できるし、そもそも、ほとんどはリスクにならない。たとえば、ＩＴプロジェクトで顧客が仕様追加を要求する。なぜ、この問題が多くのプロジェクトで深刻なリスクになっているかというと、顧客側の要求が不透明だからだ。その要求を行う理由についてそれなりの情報は開示されることが多いが、
全体像をきちんと説明されることはまずないので、トレードオフが見えない。つまり、要求にこたえるという結論ありきで、せいぜい、予算面で抵抗するくらいしかベンダーはなすすべがない。これは不透明性ゆえである。

透明性を確保できれば、この問題は消える。ただし、上のリスクの例でもわかるように、お互いの透明性の確保のために必要になるコストは大きい。おまけに、日本組織や、日本人が嫌う類のコストである。

◆ポジティブマインドを持つ

さて、アジャイルにはオープンマインドを並んで、もう一つ重要な前提がある。それは、ポジティブ思考である。上に述べた顧客の問題もそうだし、もっと顕著なのはチームの問題であるが、「信頼している」ことを前提にしている。

ところが、顧客にしろ、チームにしろ、実績があれば信頼できる。しかし、実績がない状況で信頼できないとアジャイルにはならない。別の言い方をすれば、走りながら信頼関係を作っていかないとアジャイルはできない。これが難しい。このためには、メンバーが何とかしてくれるだろう、顧客も同じ方向を向いて協力してくれるだろうといった、ポジティブな思考をする必要がある。これができないと、とてもではないが、アジャイルのような方法論は受け入れられないだろう。

信頼関係が実績ベースでしかできない根底にあるのは、失敗への恐怖である。詰まるところ、アジャイルにプロジェクトを進めていこうとすれば、失敗を覚悟で成功を勝ち取るという発想が必要だ。いわゆる「リスク」を取るという感覚ではない。リスクがあることを承知で、リスクを解消していくという発想だ。

たとえば、メンバーのスキルが十分ではないと感じている。このときに、できることをやらせて、育てることは難しい。できることをやらせていたのでは育たない。メンバーがプロジェクトの過程で育っていくことを前提に任せていく。プロジェクトだから、失敗もできない。ここで天秤にかけると、今回は任せられないという答えになる。

そうではなくて、今のスキルでは不十分だが、求めているスキルを持つように育つだろうと信じることが重要である。もちろん、そのためのサポートも必要だ。

つまり、ポジティブマインドを持って、最初の一歩を踏み出すことが重要なのだ。

◆開発マネジメントからプロジェクトマネジメントへ

１９９０年代後半から２０００年代前半にかけて、ウォーターフォール型の開発マネジメントがプロジェクトマネジメントに発展したように、２０００年代後半から、２０１０年代前半にかけて、アジャイル型の開発マネジメントはアジャイルプロジェクトマネジメントに発展していくだろう。アジャイルプロジェクトマネジメントは、今、やっとドミナントデザインが確立されたような時期で、いくつかの方法の代表的な方法が考案されている。

開発マネジメントがプロジェクトマネジメントに進化をした理由は、「戦略価値」の追求と安定性である。より、戦略に貢献できる成果を、より安定的に生み出すためには、開発マネジメントだけでは不十分だった。

なぜ、不安定になってきたのだろうか。理由は戦略の高度化によって、戦略実行のプロジェクトが大規模化、複雑化したためである。このため、開発は安定したスケジュールでできなくなってきた。それに伴って、品質が不安定になり、結果としてコストが暴れるという現象が起こるようになってきた。

そこで、プロジェクトマネジメントによって安定したスケジュールを取り戻し、品質を安定させ、コストを予算内に収めようとした。そのためのヒーローは、リスクマネジメントと、コミュニケーションマネジメント、および、統合変更管理（統合マネジメント）である。

アジャイルにも同じような構図がある。アジャイル開発がアジャイルプロジェクトマネジメントに進化すると思われる理由は、「顧客価値」の追求と安定性である。戦略価値の追求と、顧客価値の追求の違いが、プロジェクトマネジメントとアジャイルプロジェクトマネジメントの違いだといってもよい。一方で、安定性を求める点では、同じだ。

アジャイル開発が不安定になってきた理由は、顧客価値の高度化を背景にした顧客要求の複雑化したことだ。結果として、アジャイルにも、構造的・体系的に開発を進めていく必要が生じた。実は、この道は、ラピッドプロトタイピングが通ってきた道でもあった。違う点は、プロトタイピングは開発手法を複雑性に対応しようとした。しかし、アジャイル開発にプロジェクト管理の要素を取り入れればよいと考えた。そして、アジャイル開発に「バリュードリブン」と「ライフサイクル」を導入した。これがアジャイルプロジェクトマネジメントである。

このように考えてみると、アジャイルプロジェクトマネジメントに対するニーズは２つある。一つは、アジャイル開発を「安定化」させることである。もう一つは、（戦略的）プロジェクトマネジメントを顧客中心に変化させることである。

この連載で議論したいのは、主に後者の視点であるが、必要に応じて前者の視点からも議論をする。

◆アジャイルはリードタイム短縮とイコールではない

イントロダクションの最後に、アジャイルという言葉の意味に触れておきたい。よく知られているように、アジャイルは「機敏な」、「すばやい」という意味の英語である。この言葉と、ラピッドやスピーディーという言葉は異なることに注意をしておいてほしい。アジャイルは機敏であることであって、迅速ではない。つまり、アジャイルプロジェクトマネジメントは必ずしも、プロジェクトのリードタイムを短縮することは目的としないことだ。

アジャイルが議論される中で、短納期化という効果が言われることが多い。しかし、これは、納期そのものが短くなることではなく、延期と投機の議論である。アジャイルは基本的には延期のプロジェクトマネジメントである。

そして、延期戦略をとることによって、結果として納期が短くなることは珍しいことではない。この議論はこの連載の中で別途したいと思っているが、今のところは、こちらの記事を参考にしておいてほしい。

プロジェクトの補助線「延期戦略のプロジェクトマネジメント」

第１４８回（2007.06.19）　「プロジェクトにおける延期と投機」