アジャイルアプローチへの挑戦のため信頼を積み重ねる
この時期の取り組みについて武智氏は「『信頼貯金』を積み重ねながら徐々に権限を広げていく地道な活動」とし、具体的な事例を3つ挙げた。その一つが、ウォーターフォール型が主流の製造業においてアジャイルアプローチに挑戦した経験だ。
この挑戦では、特に2つの課題が明らかになった。1つ目はプロダクトの機能が肥大化する問題だ。製造業では製品の信頼性や安全性が最優先される文化が根強く、初期段階から完璧を求める傾向が強い。その結果、プロダクトの構想段階で過剰に詳細な仕様が求められ、開発計画が肥大化してしまうことが多かった。
2つ目はユーザー視点の欠如だ。製造業では目に見える成果物や製造プロセスが重視される一方で、「なぜそのプロダクトを作るのか」「ユーザーがどのような課題を抱えているのか」といった検討が十分に行われない状況があった。こうした要因がアジャイルアプローチの導入を難しくしていた。
武智氏は「アジャイルアプローチを実現しようと試みましたが、当初はほとんどうまくいきませんでした。原因は自分のスキルや進め方の問題もありますが、最大の理由は『信頼貯金』がない状態で進めてしまったことです。事業部門の期待に応え、信頼を積み上げることに注力した結果、それを基盤にアジャイルアプローチが実現できるようになったと思います」と語った。
信頼を積み重ねた結果、顧客との共創関係が構築された。当初は顧客との距離が遠く、課題を直接把握するのが難しい状況だったが、アジャイルフレームワークの活用を重ねる中で関係を深められた。プロダクトの構想段階では、ユーザーインタビューを通じて顧客のニーズを把握し、それを基に開発の優先順位を設定。開発段階では、検索機能のみを搭載した初期プロダクトを顧客に提示してユーザビリティテストを実施し、フィードバックを反映させながら進めるプロセスを確立した。こうした取り組みは、顧客との距離を縮めただけでなく、開発効率と品質の向上にもつながった。
さらに、「オズの魔法使い」方式の適用もアジャイルアプローチを支える手法となった。この方式は、ユーザーが完成したプロダクトだと思うシステムやサービスを体験している間、裏側で人が手動で操作や処理を行う方法を指す。目的は、プロダクトのコンセプトや機能がユーザーに受け入れられるかを迅速かつ低コストで検証することにある。『オズの魔法使い』の物語に登場する「大魔法使いオズ」が、実際には仕掛けを操作する普通の人だったという設定に由来したものだ。
武智氏は、プロダクトの肥大化問題への対策として、最小限の機能、例えばボタンや通知機能のみを開発し、裏側の処理をすべて人力で対応する手法を導入した。その結果、機能の利用状況を確認し、本当に必要とされることが証明された後に自動化を進めるプロセスを実現した。このアプローチは、効率的な開発を可能にすると同時に、ユーザーの満足度向上にも寄与した。
データに基づく意思決定体制の確立
「0→1フェーズ」での2つ目の事例は、意思決定が鈍化する問題への挑戦だ。武智氏によれば、大企業では組織構造の複雑さやリスク回避志向、さらに合意形成の文化が意思決定を遅らせる一因となっているという。特に、上意下達の傾向が強く、上位者の意見が最優先される構造が問題を深刻化させていると感じていた。
代理プロダクトオーナーとして武智氏が行ったのは、軽微な仕様変更など小さな意思決定においても、複数の選択肢と推奨案、根拠を示すアプローチだった。意思決定をマトリックス化し、選択肢を具体的に提示することでプロセスの明確化を計ったが、定性的な情報に依存していたため、問題の根本的な解消には至らなかった。
意思決定の鈍化を招く背景にはさらに深い課題があった。目指すべき効果が事業部門と一致していなかったのだ。事業部門と協働型の取り組みを進めてはいたが、組織や文脈の違い、さらには定性的な目標設定により、方向性のズレが生じていた。また、自分たちが取るアクションとその先に期待される効果との間に距離があったことも、大きな障壁となっていた。
武智氏は、課題に対処するためデータを活用し、目指すべき効果を明確に定量化することで、事業部門との目標を一致させ、日々のアクションが迅速に意思決定につながる体制を構築していった。定性情報に依存していた場合、結果から成果、成果から効果への因果関係が不明確になるという課題が顕著だった。これに対し、因果ループ図や因数分解を活用して指標間の因果関係を徹底的に整理した。その上で、プロジェクトの成功に直結する重要な成果指標を特定する「Focused KR（Focused Key Results）」を明確化し、効果的な意思決定を支える体制を構築した。
課題の深掘りと見極めでは、従来は定性データに依存して優先度の高い課題を判断していたが、ロジックモデルに基づき定量データを活用することで、どの指標に課題が集中しているかを明確にした。そして、改善ポイントを特定し、最優先で取り組むべき指標を事業部門と共に決定した。何を作るかを決める段階では、ポイントとなる指標をさらに分解し、数値を基に改善すべき領域を絞り込むアプローチを採用した。
開発と効果検証の段階では、リリース後に定量データを活用して効果を迅速に検証。Focused KRの改善状況を確認しながら、プロダクトの方向性を柔軟に調整することが可能になった。武智氏は「データドリブンの取り組みは意思決定を加速するだけではなく、チーム全員がワクワクドキドキしながら、さらに効力感を得ながらプロダクト作りができるようになりました」と述べた。
「0→1フェーズ」での最後の事例は、個人の力不足問題の解消だ。武智氏はプロダクトオーナーに就任した当初、IT知識もマネジメント経験もほぼゼロの状態でスタートした。同じチームのエンジニアに対して初歩的な質問ばかりを繰り返し、事業部門だけでなく、チームメンバーからの信頼を得ることすら難しい状況にあった。
この課題に対し、武智氏は最初の2年間で15個の資格を取得するなど、基礎知識の習得に徹底的に取り組んだ。実践の中では多くの失敗を重ねたが、愚直に代理プロダクトオーナーとしての役割を果たし続けた。「徐々に周囲から信頼を得られるようになって、事業部門だけではなく、自組織内での権限も少しずつ拡大してきたと実感しています」と武智氏は強調した。
