◆開発管理とプロジェクトマネジメント

ＩＴ分野を中心にアジャイル開発への関心が高まってきている。一方で、アジャイル開発は大企業には適さないとか、日本では適さないといった意見も出始めている。適さないという意見には、ガバナンスを問題視する意見が多い。今回はこの問題を考えてみたい。

そのまえに、開発管理とプロジェクトマネジメントという言葉について整理しておきたい。プロジェクトマネジメントが普及してくる以前から、開発管理という言葉がある。プロジェクトマネジメントが普及するにつれて、言葉のニュアンスが変わってきているので、いまやどうでもいいのだが、このあとの話の展開上必要があるので、もともとの定義に触れておきたい。

開発においては、プロダクト（システムや製品）自体の実現が目的であり、開発管理は、開発手法（プロセス）、ツール、体制などに注目する。プロダクト開発は予算、納期の制約のもとに行われるが、プロダクトの実現が重視される。つまり、プロダクトの仕様（機能、品質）を実現するためには、予算をオーバーしたり、納期に遅れることもある。その意味で、予算オーバーや納期遅れを如何に小さく食い止めるかが管理としての役割だといえる。

ただし、ビジネスのスピードが速くなった中で、特に、スケジュールが努力目標になっていたのでは、開発の意味がなくなるケースが多くなっている。そこで、管理方法がプロジェクトマネジメントに移ってきている。

プロジェクトマネジメントも枠組みは同じであるが、プロダクト機能（プロダクトスコープ）や品質、予算、納期はすべて対等に目標として扱い、ベースラインとして計画化する。プロダクトはプロジェクトの成果物の一つに過ぎず、プロジェクトにはその成果物を構築することによって実現したい目的（成果）がある。そして、その目的を達成するという視点から、プロダクト機能、品質、予算、納期のトレードオフを行う。これがプロジェクトマネジメントである。

この背景にあるのは、プロダクトの機能や品質の一部を落としてもいいので、早く出荷したい、あるいは原価を下げたいといったモノ作りではあまりない多様なニーズである。


◆アジャイルは開発管理

さて、アジャイルの話に移ろう。まず、最初に議論したいのは、アジャイルというのは開発管理を指しているかか、プロジェクトマネジメントを指しているのかという問題である。アジャイルという場合、多くは開発プロセスが対象であり、開発管理を指している。

アジャイル開発の良さはよく分かるが、導入できないという意見は、ガバナンスの問題に起因する。組織として、スコープ、コスト、納期、品質を「保証する」方法がないのだ。開発管理であるのである意味で当たり前なのだが、上でも述べたように、今のビジネスの環境ではこのような方法では不十分である。

では、米国ではなぜ、このような開発方法が可能なのか。

アジャイルの本質は、プロジェクトではなく、プロダクトによるガバナンスにある。
ソフトウエアのプロダクトとは何か（システムなのか、ドキュメントも含むのか）という問題があるが、これはちょっとそばにおき、システムだと考える。システムでガバナンスを行うというのはどういうことかというと、実際に動かしてみて、期待通りに動くかどうかを確認しながら進めていくということだ。たとえば、機能単位でリリースしていき、それが期待通りに動けば、組織としてもそこまでは開発が終わったことが確認できる。プロジェクトという考え方を入れなくても、完成した（リリースした）プロダクトの積み上げによって投資に対する結果や効果の管理ができるわけだ。
そんなケースが出てき始めている。


◆日米の業界構造の違い

問題はこの背景に業界構造の違いがあることだ。米国ではＩＴエンジニアの７０％が一般企業に所属している。したがってＩＴプロジェクトは社内で主導できる。ところが、日本ではＩＴエンジニアの７０％がいわゆるＩＴベンダーに所属している。したがって、企業ができるのは企画と要求を出すことと、いわゆるエンドユーザーコンピューティングと呼ばれる部分くらいで、開発の大部分はベンダーに任せざるを得ない。ベンダーをマネジメントすらしていないケース（いわゆる丸投げ）すらある。

このようなガバナンスは開発の主体が社内にあって初めて可能になる。開発の主体がベンダーにある場合、ベンダーと利害関係が発生するので難しい。ＩＰＡはこの問題を契約上の工夫によって解消しようとし、契約ガイドラインを策定したが、今のところ、目だった成果はでていない。


◆業界構造を乗り越えるには？

では、アジャイル開発プロセスを実現するにはどうすればよいのか。一番、現実的な方法はＩＴベンダーが一般企業に対して、準委任ではなく、派遣を行うことだ。ただし、準委任であればともかく、派遣ではベンダーの技術力がどんどん細っていくので長期に亘って持続することは難しいだろう。そこで、考えられるのはアウトソーシングである。といっても、今のようにベンダー側の仕切りでは意味がないので、コラボレーションできるような形態を模索する必要がある。

もう一つの方法は、ガバナンスの視点をプロダクトにするのではなく、プロジェクトのままにしておくことである。これであれば今とさほど変わらない。プロダクトによる管理のように本当にビジネスに合せて自由自在とはいかないが、プログラムの考え方を導入し、プログラムマネジメントをうまくできれば、かなり近いベネフィットを得ることが可能になるように思える。


◆プログラムの枠組みでのアジャイル

実際に米国でも、「アジャイル＝プロダクトによるガバナンス」ではなく、ビジネス（事業）展開をプログラム化して、その中でシステム開発も個別プロジェクトの一つに位置づけているようなケースが多いようだ。これであれば、ＩＴ化のプロジェクトの部分は今までのようにベンダーに任せてもガバナンスは維持できる。あとは契約の問題だけであり、それに対してはＩＰＡのガイドラインは役立つ。

プロダクト主導の方がプロジェクト主導より望ましいというのは、開発側の感覚であり、ビジネス側の感覚はそうであるとは限らない。いくらビジネスの流れが速くなってきたといっても、方向性の修正の単位は四半期である。これ以上、流動化させることはＩＴによりマネジメントの環境としては実現できたとしても、方向を変えた際の慣性があることを考えると合理性があるビジネスはそんなに多くないだろう。

そう考えると、アジャイル開発をプロジェクトやプログラムの枠の中で使っていくという方法がしばらく続くのではないかと思える。

◆関連するセミナーを開催します
╋【開催概要】━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╋
◆アジャイルプロジェクトマネジメント実践　　　　　 　 　　　 ◆7PDU's　
　　日時：2015年02月 18日（水）　 10:00-18:00（9:40受付開始）
　　場所：ヴィラフォンテーヌ汐留（東京都港区）　　
　　講師：好川哲人（エムアンドティ・コンサルティング）
　　詳細・お申込　http://pmstyle.biz/smn/pm_agile_pra.htm
　　主催　プロジェクトマネジメントオフィス、共催：PMAJ
╋━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╋
　　【カリキュラム】
　　　１．実践上の課題
　　　２．アジャイルビジネスケース
　　　３．プロジェクトガバナンスと契約
　　　４．要求定義とスコープマネジメント
　　　５．コストとスケジュールの計画
　　　６．コストとスケジュールの見積もり
　　　７．チームマネジメント
　　　８．価値による出来高の管理
　　　９．ベネフィットの実現
╋━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╋