nishida 三菱重工業株式会社様では、各事業部門がデジタルを活用して変革を推進していくため、伴走支援を行う専門部門が設立されました。EX（Employee eXperience）、CX（Customer eXperience）、PX（Product eXperience）の3つの軸で活動を進める中、直面した課題を解決するために行き着いたのが仮説検証型アジャイル開発です。レッドジャーニーは2022年よりアジャイルコーチとして伴走支援を行ってきました。
ウォーターフォール型の開発スタイルからアジャイル開発へ。2年半にわたる取り組みの結果、当初の課題に対して大きく進歩することができたそうですが、すぐにうまくいったわけではありません。どのような取り組みと工夫があったのでしょうか。2023年10月に開催したレッドジャーニーのカンファレンス「Red Conference 2023 October」での講演の概要をご紹介します。
※内容はイベント開催時（2023年10月）の情報です。
山本 浩道 様
三菱重工業株式会社
デジタルイノベーション本部 DPI部 SoEグループ グループ長
SoEプロダクトの開発で直面した3つの課題
三菱重工業の事業領域には3つの柱があり、発電所等の設備を製造する「パワー」、飛行機やロケットを製造する「航空・防衛・宇宙」、産業機械全般を製造する「インダストリー＆社会基盤」のそれぞれについて複数の事業部門から構成されています。
各事業部門が伸長していくにあたって、デジタルを活用し変革を推進したいというニーズが高まり、専門知識を持つ部門が伴走支援することとなりました。
2018年に事業ドメインの中に専門組織が設立され、2020年に全社組織化、2022年には従来の情報システム部門と統合されて一つのデジタル組織となりました。
活動には大きく3つの軸があります。
- EX（Employee eXperience）
従業員が働きやすくなるようにデジタルを活かす - CX（Customer eXperience）
お客様が取引をしやすくなるようにタッチポイントに対するデジタル化をする - PX（Product eXperience）
事業部門が作っている製品の高度化にデジタルを活かす
私がグループ長を務める「SoEグループ」は、主にEXとCXの分野を主体として取り組んでいます。
特にCXでは、アフターサービスにおいてお客様の体験を改善するウェブシステムの開発を行っています。
当初はウォーターフォール型によるプロダクト開発に取り組んでいましたが、主に「リーダー主導型開発からの脱却」「技術の手の内化に向けた内製化の促進」「プロダクト開発サイクルの全てにおけるユーザー思考の追求」の3つの課題に直面していました。
〔課題1〕リーダー主導型開発からの脱却
組織が大きくなるにつれ開発するプロダクトも大きくなっていきますが、リーダー主導型の開発ではリーダー層がボトルネックとなって価値の提供が広がらないという課題がありました。
〔課題2〕技術の手の内化に向けた内製化の促進
ビジネスパートナーである他組織にプロダクト開発を依頼していたため、技術の手の内化ができずブラックボックスができてしまっていました。また、機能の開発や改善にもビジネスパートナーに依存せざるを得ないためスピード感を欠くという課題がありました。
〔課題3〕プロダクト開発サイクルの全てにおけるユーザー思考の追求
当初は要件定義にはデザイン思考を導入していましたが、一方で開発はウォーターフォール型で進めていたため、いかに開発段階のプロセスにおいてもユーザーのことを考え続けていけるのかが課題となっていました。
こうした課題を解決するための方法を検討したところ、行き着いたのがアジャイル開発でした。
チーム開発を学び、アジャイル開発に取り組む基盤を作る
アジャイルに取り組みたいという思いは強かったものの、それまでのウォーターフォール型からいきなりアジャイルへ転換しては反動が大きいのではないかと考えました。
そこで、事前に「チーム開発」を学ぶ段階をはさむことにしました。
実際の取り組みは非常にシンプルです。これまでの働き方や開発方法を、レッドジャーニーのアジャイルコーチに観察してもらいながら、チーム開発の実践に向けてアドバイスをいただき、働き方を改革していきました。具体的にご紹介します。
協調と協働を推進するためのチームルール作り
まず、アジャイルコーチからの提案で「朝会」を始めました。よく分からないまま見よう見まねで始めたものの、しっくりこない日が続きましたが、「チームとして目線を合わせて動くためのルールを作っていく必要がある」とアドバイスをいただき、実践することにしました。
何のための「朝会」かを定義しながらルール化し、チームで目線を合わせながら進めます。
チームがチームとして活動する「ワーキングアグリーメント」作りにも取り組みました。
「我々はどんな形でチーム活動を行っていくのか」「その中でどんなコミュニケーションを行っていくのか」「ユーザーに対してどう向き合っていくのか」といったことを言語化しルール化していきました。
また、マネージャーとチームの間で「権限移譲」を行いました。
各々のカバーする範囲は「デリゲーションボード」を使って明確にしました。
これらの活動を通してチームの目線が合うようになり、チームの中に協調や協働を推進するための基盤ができあがっていきました。
心理的安全性を保つためのコミュニケーション
コミュニケーションルールを定めたことで、心理的安全性を保つためのコミュニケーションもできるようになりました。
コミュニケーションは一方向ではなく双方向で行う必要があります。また、必要なことはオブラートに包まずきっちりと伝えなくてはなりません。
そこで、批判ではなく改善に向けた重要なアドバイスである旨をルールとして定め、言う側も受け取る側もポジティブに発言を扱うようにしました。
細かいことではニックネームで呼び合うことで上下関係なくフラットなコミュニケーションを取っています。
チームが成長するための内省のあり方
コミュニケーションルールが整い心理的安全性が保たれることで、内省の場である「ふりかえり」の密度がより濃くなっていきました。
チームが成長するために必要なことをきちんと伝えて、チームが成長するために何をすべきかを議論できるようになりました。
振り返ってみると、チーム開発を学んだことで「HRT原則」の基礎を学べたと思います。
その基礎があったからこそ、アジャイル開発をスムーズに実践できたのではないでしょうか。
※HRT原則とは
チームで良好な人間関係を築くために重要とされる原則。Humility（謙虚）、Respect（尊敬）、Trust（信頼）の頭文字をとっている。
仮説検証型アジャイル開発の「型」を学ぶために
次に、仮説検証型アジャイル開発の「型」を学んでいきました。
「なんちゃってアジャイル」を回避・脱却するためにはプロのアジャイルコーチと共に歩むことが大事だと思います。
我々の現在地に応じて俯瞰した視点から的確にサポートしてくれますし、書籍に書いてあることの具体的な使いどころについてもプロの視点からアドバイスしてくれます。
こうしたサポートは効率的に成長していくために必要なものです。我々も、レッドジャーニーのアジャイルコーチに支援してもらいながら、仮説検証、アジャイル開発のそれぞれについて「型」を学び定着させていきました。
仮説検証に関しては、導入教育や実践現場で伴走してもらいながら学んでいきました。
支援してもらいながら、初心者でも理解できる仮説検証ガイド作りを進め、定着の仕組みを創っていきました。
アジャイル開発に関しては、アジャイルの定期的な勉強会を開催し、自組織だけでなく協働する事業部門も含めて教育の場を設けました。
さらに、外部企業との勉強会も開催することで自分たちの現在地と先行する方々との差分を意識し、目指すべき方向を見定めました。
また、チームが課題に気づくための率直な助言をいただくなど、チーム開発を強く支援していただきながらスクラムを定着させていきました。
ステークホルダーとの関係構築がカギ
こうして徐々に仮説検証型アジャイル開発を習得していきましたが、もちろん最初からうまくいったわけではありません。
「事業部門とワンチームになれていない問題」「エンドユーザーが見えていない問題」という、大きく2つの課題がありました。我々が取り組んだ対処法とその結果をご紹介します。
事業部門とワンチームになれていない問題
▶仮説検証の段階から、プロトタイプの検証まで事業部門を巻き込んで一緒に取り組んだ
我々なりに事業部門の方を向いて一生懸命やっていたつもりでしたが、どうしても自分たちの視点に偏った一方向のコミュニケーションになってしまっていました。
そのため、事業部門の方々からなかなか理解してもらえず、信頼関係がうまく築けていませんでした。
そこで、仮説検証の段階から、事業部門を含めアフターサービスの最前線にいる方々を巻き込み、全員で仮説検証に取り組みました。
我々で仮説検証を行い結果を説明するスタイルから、一緒に思い描くことで本音のコミュニケーションができるようになりました。
また、我々が正しいものを見極められているかを事業部門と一緒に確認できるように、複数のプロトタイプシステムを構築した上で事業部門と一緒に触りながら評価していきました。それによって、行きたいゴールについても目線を合わせることができました。
これらの取り組みを通して、事業部門と我々がワンチームとなってお客様の価値へ向けて進んでいくことができました。
エンドユーザーが見えていない問題
▶仮説検証から開発完了までお客様と共創する関係性づくりに注力した
当初は、自分たちが知りえた情報の中でお客様を想定しながら仮説検証を行っていましたが、蓋を開けてみると想定したお客様像が実際のお客様の思いや行動と一致しないことがありました。
そこで、仮説検証から開発完了まで、お客様と共創する関係性をつくることに注力しました。
仮説検証段階では、我々だけで検証するのではなく、お客様を訪問してユーザーインタビューを複数回重ねながら、お客様が抱える課題とその度合いを確かめ優先順位をつけていきました。
徐々にお客様との関係性ができていき、開発段階でもプロトシステムができた段階でお客様に操作していただきながらフィードバックをいただけるような機会を高頻度で設けられるようになりました。
これにより、プロダクトに対し早期にお客様の声を反映させながら、本当に必要なものを見極めることができるようになりました。
顧客志向を意識したイテレーティブな開発が実践できるようになったのは、関係性が構築できたからこそだと思っています。
アジャイルを「学び合う」土壌作り
現在は、仮説検証やアジャイルを「学ぶ・理解する」ところから、「学び合う」知の移転の段階へと進んできています。
例えば、プロダクトオーナーや開発者がそれぞれに学ぶ場を持ち、業務体験を共有しながら知識を深めていけるような場が、自律的に始動しています。
チーム間交流も活性化しています。他チームのスクラムイベントの見学を通して学びを深めたり、チームを越えた人材交流である「短期留学」を実践することでチームの底上げを図っています。
さらにおもしろいことに、我々の組織と一緒にアジャイルを経験した事業部門人材が、自部門で主体的に動くことにより、事業部門内にもアジャイルの概念が浸透しつつあります。
このようにアジャイルが当たり前になってくると、チームが主体となって新しい活動が生まれる好循環ができていきます。
アジャイルの経験を蓄積し、知の移転を図ることによって、組織文化として定着させることが重要です。
プロダクト検証・評価を、早く・正しく実行するには
アジャイルが定着し、チームが主体となって新しい活動が生まれていくことで、プロダクトの検証方法が多様化していきました。
プロダクト検証の基本サイクルでポイントとなる観点が3つあります。
- ニーズ
ソリューション仮説で抽出した機能を、ユーザーは本当に使うのだろうか？ - 便益
機能をユーザーが利用することにより、事業便益に繋がるだろうか？ - 機能
期待便益を獲得するためには、どこまでの機能が必要だろうか？
プロダクト検証・評価を早く・正しく実行するために、我々チームは「オズの魔法使い」という手法を適用しようと考えました。
プロトシステムの全てをシステム化せず、人が裏側で操作する部分を残すことにより、短期間でプロダクト検証を行うことができる手法です。
適用先は、お客様が補用部品を購入するE-Commerceの開発です。
プロダクトは既に出来上がっていたものの、買える部品と買えない部品があったため、お客様が我々に未登録部品のデータ登録を依頼する必要がありました。
発生するシチュエーションを細かく分類すると、お客様がデータ登録を依頼する⇒事業部門に通知が入る⇒事業部門がデータを登録⇒お客様へ連絡するという流れです。
この全てをシステム化すると非常に大規模になってしまいます。
そこで、「データ登録を依頼」というボタンだけを配置し、そのボタン選択をトリガーにして既存のSlackを通して事業部門に通知が入るようにしました。
事業部門では新たな業務フローを作り、手動で登録を行った後、お客様へ手動でメール送信を行います。
こうして四分の三を手動にすることで、価値探索に集中して検証できるようにした結果、プロト作成期間は実際使えるようになるまでわずか3週間で済みました。
この仕組みを使って6ヶ月間の検証を行った結果、その利用率からニーズがあることを確認できました。
また、期待便益が得られることも確認でき、機能面では手動部分の負荷が事業部門にとって許容範囲内であることが確認できました。
結果として、検証機能として作ったこの「オズの魔法使い」を、本番機能として継続することとなりました。
この経験は、プロダクト検証を早く・正しく行うことにより本当に必要な機能を最適な範囲で開発することができるという大きな学びとなりました。我々にとって非常に意義あるチャレンジだったと思います。
データ基点のプロダクト検証
チーム主体の新しい活動をもう一つご紹介します。データを基点としたプロダクト検証です。
プロダクト検証では、プロダクトの価値や効果を計測し、次の機能検証に繋げていく必要がありますが、従来は、お客様への訪問・アンケートにより取得したVoC（Voice of Customer）をもとにした定性評価が中心でした。
集めた情報を整理しながら、お客様の要望が高い改善機能に関する仮説を立案していましたが、作った機能やプロダクトが本当に事業便益や期待効果に繋がるのか、プロダクトを作って検証するまで分からないという課題がありました。
不確実性が高い状況下で、提供価値の向上に直結する機能を納得感を持って見極めるためには、プロダクトの主要指標であるKR（Key Result）を定め、定量的観察を継続的に行うことが必要と考えました。
前述の、補用部品購入を目的としたE-Commerceの開発において、お客様の部品購入の総計のうちECを通じて購入した分＝デジタル取引額をKRとし、計測を開始しました。
計測結果をグラフ化することで、デジタル取引額の絶対値がどう変遷しているのかが明確に分かるようになってきました。
また、大きな機能リリースをしたときに、どれくらい効果があったのかも見えるようになりました。
効果が具体的に測れるようになったことは大きな進歩です。
また、デジタル移行率の向上に向けて、KRをさらに詳細化し計測を進めました。
データの積み重ねをもとに必要な手法の問いを立て、定量評価を行い、仮説を立てて機能を見極めていきました。
定性評価と定量評価を組み合わせることにより、事業価値と顧客価値のバランスが取れたプロダクト検証が可能になることは、大きな学びでした。
2年半の取り組みを振り返って
2年半にわたる取り組みを振り返ってみると、当初抱えていた3つの課題に対して大きく進歩することができました。
まず、リーダー主導型開発からの脱却です。
チーム開発の基礎を学ぶことでHRT原則が常態化し、マネージャーからチームへの権限移譲を進めていった結果、自ら考えチャレンジする自律的なチームへと進化することができました。
次に、技術の手の内化に向けた内製化の促進です。
アジャイルに加えて、「小さくはじめ」「失敗を振り返り」「お互いが学び合う」を愚直に実践していくことを重視した結果、個人とチームの技術力が着実に向上し、内製化を推進する強いチームへと成長できました。
最後に、プロダクト開発サイクルの全てにおけるユーザー思考の追求です。
開発チーム内のコミュニケーションにとどまらず、常に事業部やお客様を巻き込みながらアウトカムを追求することが重要です。
これらが定着していくことにより、チームから自律的に新しい活動が始まっていきました。
チーム、組織として成長し、提供価値を高めていくためには、アジャイルをただ実践するのではなく、文化として組織に根付かせていくことが重要です。
我々もまだまだ始めたばかりで、今後も学ぶべきことが多々あります。
実践を重ねながら、より大きな提供価値を出せるよう推進していきたいと思います。
ご清聴ありがとうございました。
redjourney.jp
