【米SVPG社 翻訳記事】プロセスvs.モデル

作者：マーティ・ケーガン

翻訳者：インターンスタッフ（アーテリジェンス）

‍

プロダクト開発における「モデル」の意味

"すべてのモデルは間違っている、だが中には役に立つものもある"

統計学の世界で古くから言われている言葉があります。いつでもこの言葉が心に響いています。概念モデルは決して完璧ではありませんが、重要な概念を説明するための強力なツールであると思います。しかし、コンセプチュアルモデルを文字通りに捉えすぎたり、投影しすぎたりして、それを規定のプロセスとして解釈してしまうリスクが常にあります。

これは、継続的なディスカバリーとデリバリーのコンセプトを説明する際においても時折起こることです。

私は長い間、この2つの活動が並行して行われていることを示す概念モデルを使用してきました。

‍

‍

継続的なディスカバリーとデリバリーモデルについて

このコンセプチュアルモデルには、さまざまな名前があります。実際、多くの人がこのモデルをさまざまな名前で呼んでいることは、このモデルの根本的な真理を示していると思います。

「build the right product(正しいプロダクトを作れ) / build the product right (正しくプロダクトを作れ)」、「fake it before you make it(うまくいくまでは、うまくいっているふりをしろ)」、「build things that don’t scale(スケールしないものを作れ) / build things that do scale(スケールするものを作れ)」、「move fast (早く動かせ) / don’t break things (壊すな)」などと呼ばれているのを見たことがあります。そして、多くの人がこの継続的デリバリーとディスカバリーを並行して行うモデルを "デュアルトラック・アジャイル"、あるいはより一般的に "デュアルトラック・プロダクト開発 "と呼んでいます。

デュアルトラック・アジャイルの危険性

ジェフ・パットン（Jeff Patton）は最近、"デュアルトラック "という言葉の由来を取り上げた良い記事を発表しました。しかし、そんな彼の記事の中でさえ、ジェフがコンセプトモデルの中で、ディスカバリーとデリバリーの実際の現場でお紺われているプロセスをより多く捉えようと苦心している様子が伺えます。

本来であればシンプルだった筈のコンセプトモデルが、いかに複雑で難解ななプロセスフローチャートにかわってしまったか、私には容易に想像がつきます。

私はこれまでに多くの人から、本来はシンプルだったコンセプトモデルに以下のような要素を追加するように勧められました。

より戦術的なディスカバリー作業のフェーズの前に行われるベースラインのプロダクト製品ビジョン及び/またはユーザーリサーチ作業について
デリバリーで行われるべき仕事を説明する活動について
スクラムとカンバンでのデリバリープロセスの違いについて
開発時の学習と、ディスカバリーの間のフィードバックループについて

‍

私がこれらの提案に反対であるのは、どれも間違っているからではなく、単純な概念モデルからより複雑なプロダクト開発プロセスの検証へと移行していく中で、この提案が危険な道のりであるといえるからです。

プロダクト開発プロセスを教科書的に規定することは逆効果を招く

さらに重要なのは、このシンプルなモデルがプロセスにとらわれないという点です。ディスカバリーのプロセスやテクニックには様々なものがありますし、デリバリーのプロセスやテクニックにも様々なものがあります。

私が考えるさらに重要なポイントは

ディスカバリーとデリバリーの活動は、並行して継続的に行われるべきものであり、"フェーズ "に分けられるものではないこと。
ディスカバリーにおいて、顧客価値、使いやすさ、実現可能性、実行可能性などのプロダクト固有の大きなリスクに対してチームが正面から立ち向かうこと。
ディスカバリーにおいて、業務を縦割りにせず、プロダクトマネジメント、プロダクトデザイン、エンジニアリングなど、プロダクトチームが協力して問題を解決すること
プロダクトチームは、単に目玉商品を出荷するだけでなく、ビジネス上の成果を評価していること。
1つのプロダクトチームがディスカバリーとデリバリーの両方を担当していること（当然プロダクトマネージャーとデザイナーはディスカバリー活動に、またエンジニアはデリバリー活動にほとんどの時間を費やします）。

私は常にプロダクト担当者に、プロダクトの開発・納品プロセスが一つではないように、プロダクトの発見プロセスも一つではないことを強く主張しています。プロダクト開発やデリバリーのプロセスが単一でないように、プロダクトの発見プロセスも単一ではありません。例えば、ディスカバリースプリントとカスタマーディスカバリーは全く異なるものですが、どちらにも精通している必要があります。

プロセスやモデルを規定することよりも、「何を実現したいか」を考えよ

また、重要なことは、プロセスではなく、「何をするか」ということです。必要な文化を整え、重要な技術をチームに教え込むことの方がはるかに重要なのです。

ジェフ・ベゾスは最近の株主総会で、このような問題に言及しています。

「良いプロセスは、お客様にサービスを提供するために役立ちます。しかし、注意していないと、プロセスが（自己目的化してしまい）モノになってしまいます。これは大きな組織で起こるっ傾向にあります。プロセスが自分の望む結果の代わりとなってしまうのです。結果を見るのをやめて、ただプロセスを正しく行っているかどうかを確認するべきです。」