プロダクトベースおよびプロジェクトベースの資金調達を比較する

Martin Fowler氏は先頃、“Agile IT Organisation Design”の著者であるSriram Narayan氏が執筆した、“Products over Projects”と題する記事を公開した。この記事では、プロジェクト指向チームとプロダクト指向チームとを比較している。Narayan氏は、長期的なチームのオーナシップの下で実施されるプロダクトディスカバリ(product discovery)に向けた資金調達とデリバリとして、プロダクトモード(Product Mode)という概念を説明している。“Lean-UX”、“Sense and Respond”という著書を持つJeff Gothelf氏も先日の記事で、プロダクトと連携したチームのメリットを取り上げている。同じように、アジャイルコメンテータのLeon Tranter氏も先頃、プロダクトに技術的破綻をもたらす要因のひとつとして、プロジェクトの資金調達モデルについて言及した。

記事の中でNarayan氏は、プロジェクトは“ビジネスケースに投影されたメリット”に基づいて資金供与され、“何らかのシステムあるいはアプリケーションの構築ないし拡張とその継続”を責務とし、“タレントのプールから人選される”ものだ、とした上で、これと比較する形で、プロダクトモードにおけるチームの資金調達を次のように説明している。

チームの資金は、一定期間にわたってビジネス上の問題ないしサービスに対する作業を行なうために提供されるものです。作業の性格は、提供する機能セットではなく、対象とするビジネス上の問題によって定義されます。このような作業のあり方を“プロダクトモード”と呼んでいるのです。

Narayan氏は、プロジェクトベースの資金モデルとプロダクトモードのチームを比較して、プロダクトを中心とするチームが“プロダクト/ビジネス戦略に基づいたロードマップの進展”に向けて取り組んでいる点を強調した。さらに、事前に計画されたソリューションに対するプロジェクト資金との比較において、プロダクトモードでの資金調達は“根本的な問題が検証可能な状態で解決されるまで、ソリューションの構築、実行、反復、場合によっては他のソリューションを提供する”ためのものだ、と述べている。

Gotherlf氏は先頃、プロダクトディスカバリにリーンスタートアップメソッドを使用することによって、GEがプロダクト指向チームから脱却を果たしたことを記事に書いた。リーンスタートアップはそれ自体がリスク軽減戦略だが、市場は利益やコスト、ROIの予測可能性を追求している、と氏は書いている。“それはもはや私たちが生きてきた世界ではなく、リーンスタートアッププラクティスによって初めて完全に明らかになる”のだ、とする氏は、さらに次のように述べている。

仮定や仮説、実験といったボキャブラリだけでは、それ自体が予算ミーティングですぐに危険信号として受け取られてしまいます。いずれも出荷されたプロダクト(あるいはメリット)ではなく、出荷遅れ、購入遅れ、利益遅れと言っているように聞こえるのです。

Tranter氏はプロジェクトの資金調達が、低品質なプロダクトや技術的負債の拡大に寄与する要因ではないのか、という考えから、次のように書いている。

ソフトウェアプロダクトの開発において、従来的な“プロジェクト”型の資金調達や作業管理は破滅的に愚かな方法です。チームは見放され、揚げ句の果てに解散し、プロダクト市場への不適合や恣意的な期限を満たすためのデスマーチが起こり、最後に残るのは技術的負債の山です。

技術的負債が原因で、新たなプロジェクトが“混乱状態の解決からやり直す”状況になることは少なくない、とTranter氏は指摘する。これは“変更のコスト曲線が制御不能になって負の価値を持ち、チームの労力をすべて消費している”状態であるとして、氏はこれを技術的破産(technical bankruptcy)点と定義する。これに対比する形で、Narayan氏は、プロダクトモードが“短い周期のイテレーションによるチームの再構築を可能にすると同時に、ソフトウェアの完全性を維持し、その有用性を長期間にわたって確保する”、と述べている。

Narayan氏は、プロジェクトがチームに対して近視眼的なアーキテクチャ選択を強いて、その判断がもたらす長期的なコストを無視している点について、次のように説明する。

プロジェクトモードに関連するインセンティブは、チームに対して、短期的な機能提供を優先する(ように思われる)ことを理由に、中期的なアーキテクチャの完全性を無視するように圧力をかけます。チームがそのトレードオフの結果に直面することはありませんが、長期的なオーナシップのある場合には、フィードバックからの恩恵を受けることができなくなります。

短期的な利益を最優先する従来のモデルを、“ほぼ誰もが、あらゆる種類のビジネスを、はるかに小さな投資とリスクで始めることのできる”現在の世界に適用することはできない、とGothelf氏は書いている。氏はまた、“リーンスタートアップはソフトウェア中心の世界にそぐわない、陳腐化した計画プラクティスを顕在化する虫眼鏡である”、とも言う。

プロダクトの段階的な改善に資金提供するだけでなく、もっと遅い、一歩一歩進むようなイノベーションをサポートできるように、資金調達モデルを変える必要がある、とGothelf氏は言う。氏の言によれば，

イノベーション活動に対して高い忍耐レベルをサポートするものと、新たなビジネスの構築と拡大という、異なる２つの資金調達経路を両立する必要があります。スタートアップの90パーセントは失敗に終わるのですから。あなたの企業は、新たな活動の90パーセントが失敗することを容認できる忍耐力を持っていますか？

プロジェクトベースの資金調達から離れるだけでは十分ではない、とTranter氏は警告する。氏は、“資金調達の継続的な価値のストリーム”のためのプロジェクトを放棄し、さらにそれを“プッシュ”システムに置き換えた例を引き合いに出した。“作業の目的は何か、期限はいつか、優先事項は何か、どうやって開発するのか、といったことに対して、レベルの低いチームは何も言うべきことを持っていない”、と氏は言う。Tranter氏は、チームがプロダクト全体のフルスタックなオーナシップを持つべきだとして、次のように主張する。

チームが開発したプロダクトはそのチームのものです。彼らは空間と時間の両面において、フルスタックでそれを所有します。空間におけるフルスタックとは、ユーザインターフェースからAPIやデータストアに至るまで、技術的スタック全体に責任を持つという意味です。ハンドオーバなし、ミドルウェア専門家なし、コンポーネントチームなし ... 時間的なフルスタックとは、サービスないしプロダクトの誕生から死まで、チームが所有するということです。ハンドオーバなし、メンテナンスグループなし、運用チームやBAUチームなし。開発し、実行し、修正するのです。

MartinFowler.comでのNarayan氏の記事の最終回は、感謝祭の後間もなく公開される予定である。