プロジェクト・アプローチとプロダクト・アプローチ
今回はBTABoKのオペレーション・モデルから、Products & Projects (以下P&P) のご紹介です。プロダクトとプロジェクトとならべたとき、プロジェクトの帰結がプロダクト、という関係がまずは思い浮かびます。これは、世の中に存在しないプロダクトは買えませんが、それを生み出すためのプロジェクトは買うことが出来る、ということにもなります。ありていにいえば、まだ無いプロダクトが欲しいときの「おカネを出す理由」がプロジェクト、ということもできるわけですね。P&Pはこのような、ビジネスケースで一時的な支出を正当化する方法を「プロジェクト・アプローチ」と呼んでいます。本文中リンクで紹介されている記事では「プロジェクト・モード」とも呼ばれています。
プロジェクト・アプローチは、有形のプロダクトに対しては必須です。ITでもプロジェクト・アプローチはおなじみで、特にITを有形のモノ、つまり償却資産に対する設備投資として扱うケースでは良い結果が得られるでしょう。P&Pでは、かつてプロジェクト・アプローチがITでも上手く行っていた理由を「多くのシステムがよく理解されていて、進化が遅い手動のビジネスプロセスをデジタル化していたから」と述べられています。ひとくちにビジネスプロセスといっても様々で、制度会計のように時代が変わっても変えられない、または変えてはいけないものも多く、それらをいちどにデジタル化するケース、たとえばERP導入などではプロジェクト・アプローチが現在でも主流であると言えます。
もちろん一方で、カスタマー・エンゲージメントのように変えることができる、また変えなければならないビジネスプロセスも存在します。さらにはこれだけテクノロジーが進歩、普及してくると、デジタル・マーケティングのように、そもそもデジタルでないと成り立たないビジネスプロセスも必要とされるようになってきます。しかもテクノロジーは進歩し続けるので、これらのビジネスプロセスも絶えず変化してゆきます。こういった状況では「プロジェクト・アプローチによって出来るプロダクトの償却期間」＞「プロダクトの経済寿命」ということになってしまい、これでは商売に勝てません。それで代わりに普及してきたのが「アジャイル・アプローチ」です。プロジェクト・アプローチでは、プロジェクト・チームはプロダクトが出来たらそこで解散ですが、アジャイル・アプローチではアジャイルチームは最初のプロダクトを生み出した後も、ビジネスやテクノロジーの進化に合わせて、プロダクトの経済価値を継続的に高めていきます。また、ソリューションに対するそもそものニーズが消失するなどして、プロダクトの存在意義自体が無くなったときは、そのようなプロダクトは早々に引引き揚げて、別のプロダクトを用意することになります。
プロダクト・オーナーとアーキテクト
P&Pでは、アーキテクトの責任はアジャイル・アプローチによるプロダクトの継続的進化と「自然に一致」する、と述べられています。なぜならアーキテクトは「アーキテクチャ上の決定において、移行、総所有コスト、品質属性、システムの寿命などについて常に考えなければならない」ためです。
特に大きな、あるいは複雑なビジネスになればなるほど、アーキテクトの役割はますます重要になります。アジャイルチームが直接生み出すのはテクノロジー・プロダクトで、小さな、または単純なビジネスであればテクノロジー・プロダクトは同時に、直接ビジネス価値を生み出すビジネス・プロダクトでもありますが、大きな、あるいは複雑なビジネスとなると、ビジネス・プロダクトとテクノロジー・プロダクトとの関係は複雑になります。その例としてP&Pでは、「ビジネス・プロダクトを構成するビルディング・ブロックとしてのテクノロジー・プロダクト」「ひとつのテクノロジー・プロダクトの複数のビジネス・プロダクトによる共有」「ビジネスおよびテクノロジー・プロダクト間のライフサイクルの差異」の3つが挙げられています。
テクノロジー・プロダクトとビジネス・プロダクトとが常に1対1の関係であるなら、アジャイルチームにとってはアジリティの観点からは理想的ですが、ビジネスが拡大するにつれて膨大な重複が生じ、無駄なコストが膨らんで (これも有る意味複雑化と言えるでしょう)、結局ビジネスとしての競争力を失い、やがて立ち行かなくなってしまいます。そうなるとビジネス・プロダクトのライフサイクルもそこで終了することになります。
テクノロジー・プロダクトを生み出すアジャイルチームを指揮するのはプロダクト・オーナーですが、彼らと共同作業でアーキテクト上の正しい判断を導き、このような複雑性を減らし続け、プロダクトのビジネスバリューを高め続けて行くことが、アーキテクトの責任の一つであるといえます。
ビジネス、テクノロジーを問わず、プロダクトは「立ち上げ」「成長」「成熟」「衰退」の4つのフェーズをたどることがP&Pでも示されています。アーキテクトはまず、各プロダクトがそれぞれどのフェーズにあるのかを見極め、また異なるフェーズにあるさまざまなプロダクトに対し、フェーズごとにことなるフォーカス (例えば立ち上げフェーズなら提案されたイノベーションの受容度、成長フェーズなら技術負債の返済見込みなど) に基づいて、さまざまな助言をプロダクト・オーナーに与え、また異なるプロダクト間のトレードオフや利害関係、優先順位などを複数のプロダクト・オーナーの間で調整するといった重要な役割を担います。
事業はプロダクトかプロジェクトか
P&Pではあまりプロジェクトについてはふれられておらず、実質的には「プロジェクトよりプロダクト」といった内容になっていますが、そもそも事業 (エンタープライズ) という概念は、両方の側面を含むものです。エンタープライズは「継続的なプロダクトの集合体」「プロジェクト・イベントの連続」どちらにも見立てることが出来ます。あるいはそれらが組み合わさって一体化したものがエンタープライズ、と捉えるのがより正確なのかも知れません。いずれにせよ一つだけ確実に言えるのは「プロダクトの集合」も「イベントの連続」も、放置すればやがて「発散」するものなので、それをエンタープライズという一定の構造に収束させ続けるには、アーキテクトという仕事が必要、ということだと思います。
Iasa日本支部は、このようにビジネスに欠かせない役割であるアーキテクトのコミュニティとして設立されました。プロのアーキテクト、これからアーキテクトを目指される方、アーキテクチャに興味がある方はぜひ info@iasa-japan.org にお問い合わせください。