プロジェクトではなく、プロダクトで思考せよ

プロダクトを中心に構築された組織は、エンドツーエンドで作業を監視する。Conwayの法則を逆転して、プロダクトに基づいた長期的なチームを確立することにより、組織が安定すると同時に、作業の管理と優先順序付けが容易になる。レトロスペクティブはプロダクト管理の強力なツールだ – 継続への自信を与え、組織に対するリスクや損失の可能性のあるものを素早く見つけ出せるようにしてくれる。

アジャイルコーチでトレーナ、講演者、コンサルタントのArdita Karaj氏は、eXperience Agile 2018で、“What’s my product”と題した講演を行う。同カンファレンスは10月1～2日、ポルトガルのリスボンで開催される。

InfoQではeXperience AgileをQ&Aや要約、記事などでお伝えする予定である。今年のテーマは“人々を通じた改善”だ。

世界各地から集まった業界のトップリーダたちによる、最先端のアジャイルプラクティスを堪能してください。eXperience Agileは、単なるアジャイルカンファレンスではありません。今日使用されている、最も革新的なアジャイルアプリケーションを提供するイベントなのです。

InfoQはKaraj氏にインタビューして、組織の人々はなぜプロジェクトで考えるのか、それによってどのような問題が発生するのか、プロダクトによる発想は新たな仕事の方法の発見と継続的改善にどのように寄与するのか、アジャイルのレトロスペクティブはプロダクト思考にどう関わるのか、プロジェクト思考からプロダクト思考への転換を実現するために組織にできることは何か、などを聞いた。

InfoQ: 今回のカンファレンスでは、何を予定していますか？

Ardita Karaj: 2つのセッションを実施します。ひとつは、アジャイルを初めて利用するチームがアジャイルプロジェクトを始めるためのワークショップです。価値、顧客、コラボレーションに焦点を当てます。ふたつめは、そのセッションの続きです。私たちは通常、最初のアジャイルプロジェクトで結果を確認し、それと同じことを繰り返すルーチンに入ることで、よりよい結果を期待します。プロジェクトに次ぐプロジェクト、という訳です。そこではアジャイルの基礎のひとつである、“検査と適応(Inspect and Adapt)”が忘れられています。最初にアジャイルプロジェクトで学ぶ必要があることは確かですが、その後は製品やサービス、顧客との進展に基づいて、より良い方法を検証し、適応する必要があります。

InfoQ: 企業がプロジェクトを重視するのはなぜでしょう？

Karaj: 企業によっては、それが簡単だからでしょう。プロジェクトを想定しないのは困難か、あるいは極めて難しいのです。それらの企業では、この方法が非常に長く運用されているために、このモデルをサポートし、保護する構造がすでに完成しているという事実があるからです。プロジェクトベースで資金が調達され、プロジェクトに基づいて人が割り当てられて、予測や目標もプロジェクトに基づいて設定されます。別の方法に切り換えて運用するには、企業の構造を大きく変えなくてはなりません。財務、人事、営業やサービス提供チーム、設備、運用、マーケティングなどの構造を作り直す必要があるのです。営業と開発/IT/運用との関係や、同じ企業内の各領域をパートナではなく“コストセンタ”として見るコンセプトも変えなくてはなりません。

このような変革は容易ではなく、知識の豊富な、強い指導者が必要です。変革の価値を原則として理解している幹部指導者はいますが、彼らの立場を持ってしても、このような変革を短期間に行うことはできません。多くの献身的な作業と政治的な忍耐力、時間の投資が必要です。これらは多くの場合、企業にとって、直面するには大き過ぎる課題です。そのため、ポテンシャルを最大限に発揮できていないのを知りながら、プロジェクトを(アジャルに適したユースケースで)続けることで、小幅な改善を得る方法が選択されることになります。

InfoQ: それによって、どのような問題が起きるのでしょうか？

Karaj: 高い視点から見れば、プロジェクトは部分最適化の活動です。顧客のために新機能を開発(あるいは既存の機能を改善)する人々のグループがいて、変更が何のために行われたのか、どのように解決ないし実装されたのかを知らないまま、私たちは彼らに仕事を託します。品質が低く、メンテナンスチームが問題に対処しなければならないことも少なくありません。これが低品質を許容する文化を作り上げて、メンテナンスないし運用を担当するチームがサービス提供チームの生み出した問題に対処する、という状況を受け入れるようになります。提供側のチームは自らの失敗に学ぶことができないので、同じ過ちを繰り返します。適切なデータのないまま予算が設定される、人が簡単に置き換え可能なものとして扱われる、という状況が生まれます。この文化は低い期待値を許容すると同時に、技術や製品、才能、革新といった多くの面で負債を積み上げる傾向にあります。そのため、このような企業は受け身的な行動を取ることが多く、競合他社が市場に投入するものを常にキャッチアップしようとする傾向にあります。変革は費用がかかる上に、成果が顧客の手に渡るまでに時間を要するのです。

他の人たちは知りませんが、私個人としては、このような企業の一員にはなりたくありません:) 自分のすることに誇りを感じることができませんし、そのような企業にいる自分自身の先行きにも不安を持つと思います。

InfoQ: プロダクトの考え方は、私たちが仕事をし、継続的に改善していくためのよりよい方法を見つける上で、どのように役立つのでしょうか？

Karaj: 製品(あるいはサービス)を中心として構築された組織には、自分たちの仕事をアイデアから顧客までのエンドツーエンドで、さらには顧客からのフィードバックや反応に基づいた新たなアイデアによって閉じられたサークル全体を監視できるように構成されている、というメリットがあります。これが重要なのは、提供するソリューションと品質、ユーザのエクスペリエンスと満足度に対して、チームが説明責任と所有権を持つからに他なりません。

価値の提供に関わるすべての領域を可視化することにより、プロダクトとその提供プロセスを理解し、ボトルネックを特定し、ユーザの声を聞いてデータを収集し、時間とともによりよい、よりスマートな判断を行なうことが可能になります。営業面では、投資した資金の行く先を理解し、売上に対して期待できる影響をより正確に予測できるようになります。マーケティングと製品管理については、企業の能力をよりよく理解すると同時に、インテリジェントな優先付けと、機能やサービスの実験という方向にシフトする必要があります。このようにして、顧客に対して価値の低い、あるいは無価値のものを提供するというリスクを軽減することができるのです。

この構造におけるもうひとつのメリットは、長期的なチームという考え方です。このようなチームは、多数の定まらないターゲットに対して多くの決断をする必要のあるビジネスの世界において、安定性をもたらすひとつの要素となります。チームの1ヶ月のコスト、組織の運営を維持するために必要なリソース(人という意味ではありません)のコストなどは既に分かっているので、作業の管理や優先順位の設定により集中することができるのです。長期的なチームには、よりよいプロダクトと構造を作り出すための試行と学習、調査と適用、革新と慣習の打破のためのチャンスがあります。

InfoQ: アジャイルのレトロスペクティブは、プロダクト思考とどのように関連するのでしょう？

Karaj: レトロスペクティブは、“調査と適用”、“継続的改善”、“継続的学習”といった、市場で力強く競争するプロダクトのための強力な要素となるプラクティスのひとつです。顧客が何に価値を見出して何を嫌っているのか、自分たちの機能やサービスが市場をどの程度リードしているか、あるいは競合他社にどれほど遅れをとっているか、ある機能に対して顧客はどれくらいの費用を払ってくれるか、その他の機能は提供とメンテナンスのコストをどの程度上昇させているだけなのか、といったことを立ち止まって評価しないプロダクト管理チームは、プロダクトをただ盲目的に管理しているに過ぎません。これらのことを立ち止まって見直す余地がなければ、うまくいっていないことや課題に直面する勇気がなければ、製品やサービスの状態に対する規律と適切な配慮がなければ、顧客が望むプロダクトを作り出すこと、最終的には市場において財務的に強靭な企業を維持することが難しくなります。

自らが行なっていることを継続する自信を持てること、あるいは企業のリスクや損失につながる可能性のあるものを素早く判断できることは、プロダクト管理チームにとって、最も強力なツールのひとつになります。

InfoQ: プロジェクト思考からプロダクト思考に転換したいと考えている企業に対して、どのようなアドバイスをしますか？

Karaj: プロダクト思考を意図的に運用できている企業の中には、Conwayの法則を使って、ソフトウェアの“形(shape)”を組織構造の形に結び付けているところもあります。この法則を逆転すれば、顧客のエクスペリエンスを重視するように、チームを構成することが可能になります。

プロジェクトに強く依存しているために自らのプロダクトが何であるかを明確に答えられない組織は、Conwayの法則を逆に利用することで、プロダクト思考に転換することが可能です。顧客に注目して、そのニーズや苦痛、利益を理解してください。それと同時に、市場の動向や、ユーザが何を使っているのか、あるいは自分たちの製品以外に何をテストしているのか、といったことにも注目する必要があります。これを起点として、自らのサービスや機能に対する理解に対するセンスを持ち、それらをエンドツーエンドでサポートするチーム構成に着手してください。これらの機能ないしサービスの提供に関わる全領域を確認して、たとえ小さくても、アイデアを顧客の手に素早く渡すことができるような変革を行いましょう。関係する人たちの意見や改善のアイデアに耳を傾けて、この変革において彼らが学ぶ余地を提供してください。多くの分野からのサポートとコラボレーションが必要になるはずです。先に述べたように、簡単ではありませんが、不可能ではありません。よい事例ができたならば、改善しながら繰り返しましょう。同じことを6ヶ月間続けているのであれば、これができていません。立ち止まって振り返り、見直すべきです。