コンセプチュアル・マネジメント

◆アジャイルプロジェクトのガバナンス　３つの壁

アジャイルスタイルのプロジェクトマネジメントを実践しようとしたときに、プロジェクトガバナンスの上で、問題になることが三つある。

一つは見積もりの位置づけである。二つ目はスコープにより統合マネジメントを行うことである。三つ目は、（社内）顧客とチームを組むことである。

逆にいえば、この３つが計画重視型のプロジェクトマネジメントとの本質的な違いだともいえる。アジャイルスタイルのプロジェクトマネジメントを実践するにあたって、これらの問題をどのように整理していけばよいのだろうか？

まず、この３つは完全に独立した問題ではなく、かなり、依存関係の強い問題である。たとえば、スコープ中心の統合マネジメントから考えてみると、だから見積もりは実績ベースでよいし、見積もり値事態にそんなに意味はないということになる。また、スコープ変更の必要性が生じたときに、即座に顧客の判断を仰ぐためには、顧客自身がチームに入っていることが重要である。こういう関係になっている。


◆見積もりの壁

さて、では一つずつみていこう。アジャイルのおける見積もりの位置づけは、そのプロジェクトが実現可能なものかどうかを判断することにある。言い換えると、数値そのものにあまり大きな意味はない。これは、従来の事業の慣行に合わない。商品開発の予算確保も、ＩＴプロジェクトの受注も、見積もりをベースにして行われる。つまり、事業計画化、あるいは受注される段階ではある程度スコープが詰められていることを前提にしている。

この前提が崩れると、見積もりが精緻に行われないと計画や提案ができないということになる。また、受注型のプロジェクトだと、契約の問題も出てくる。

この問題に対して、実務上取るべき方策は、コストやスケジュールの計画と（開発）見積もりを区別することである。従来の方法だと計画は見積もりをベースにして、リスクなどを追加する形で行われる。つまり、目標ではなく、制約条件に近い。だから、正確性にこだわる。

これに対して、見積もりをまったく無視するということではないが、計画はある程度見積もりを配慮した、「ビジネスケース」だと考える。ビジネスケースがプロジェクトガバナンスの起点になる。

これによって、見積もりの位置づけは、アジャイルの原理通り、生産性の実績に基づく数字に変わる。そして、実績ベースの見積もりで、コストとスケジュールの計画の中に入るように、スコープを調整することによって行う。


◆スコープ調整の壁

そのように考えると、次の問題はスコープによる統合マネジメント（調整）である。この話の源流は、人工ベースにある。ＩＴプロジェクトでは人工ベースで提案をすることを前提にしているので、その見積もりができるように要件（スコープ）の仮決めが必要になってくる。そして、契約はスコープベースで行われる。社内プロジェクトでもそこまで厳密ではないにしろ、同じような問題を抱えることになる。

この問題を解消するには、商談の仕方を考え直す必要がある。今のＩＴのやり方はずいぶん無駄がある。極論すれば、人工ベースでプロジェクトを動かしているので、ユーザ企業のシステム部門が必要であるとも言える。

そこで、人工ベースを価値ベースに変える。具体的には要件ベースで行っている取引を、要求ベースに変え、要求に対して価値を決めていく。アジャイルのやり方そのものであるが、そのように進めるためには、情報化投資のＲＯＩをもう少し細かなレベルで定義し、要求に対する対価を明確にしていかなくてはならない。

ここが問題の本質であるが、逆にここは顧客側のプロジェクトマネジメントの問題であり、端的にいえば、プログラムマネジメントを導入していく必要がある。米国の様子を見ていると、このような考え方は情報システムをコストから、バリューに変えていくために必須だとみられており、グローバルにそのような方向性がみられるようになっている。

逆に、このような方向性があるので、その枠組みの中でのアジャイルプロジェクトマネジメントが重視されるようになっているというのが正確な言い方である。


◆顧客のチーム参加を必須にする

この２つの問題が片付けは、３番目の問題は自然に片付く。価値をベースにしたスコープ調整を行うプロジェクトであれば、逆に顧客がプロジェクトチームに入っていないという状況は考えにくい。

逆説的にいえば、顧客が入らざるを得ないようなプロジェクトの運営をすることをアジャイルでは目標とすべきだと言える。