Compass のエンジニアリング チームは問題を抱えていました。提供している機能は技術的には健全でしたが、何かが欠けていました。それは顧客に真に寄り添う姿勢です。コードの記述は効率的にこなしていましたが、正しい問題を解決できていたでしょうか。
Compass の開発に携わるアトラシアンのシニア エンジニアリング マネージャーとして、私はこの課題に何年も取り組んできました。私はチームとともに、開発チームがソフトウェア コンポーネントとリソースを大規模に管理するために役立つツールを構築する責任があります。私は最初に入社したとき、多くのエンジニアリング組織が直面しているパターンに気づきました。つまり、機能を提供することは得意でも、的確に価値を提供できていないことがあるということです。
私はこれまで、エンジニアリング文化がプロダクトの成功にいかに影響するかを現場で目の当たりにしてきました。アトラシアンでは、ソフトウェア チーム向けのツールを構築することにとどまらず、顧客が日々直面するのと同じ課題に向き合っています。そのため、エンジニアリング文化の変革について独自の視点が得られます。だからこそ、私は社内でのそのような学びを分かち合うことに情熱を注いでいるのです。
従来のエンジニアリングの断絶
架空のプロダクト チームを例に、聞いたことがありそうなストーリーを紹介します。
シニア開発者である Tina は、技術力の高さに定評があります。作成するコードは申し分のないものでしたが、要件を受け取ってコードを記述し、機能をデプロイする、という慣れ親しんだサイクルに陥っていることに気づきました。「私は背景を知らずにコードを記述していました」と Tina は認めます。「自分が構築したものが実際に顧客の問題を解決するかどうかはわかりませんでした」顧客のコンテキストをもっと知りたくても、実装に集中する中で限界を感じていました。
チームのプロダクト デザイナーである Rita には独自の苦労がありました。何週間もかけて細部まできちんと設計したところで、開発中に重要なフィードバックを受け取り、大幅な修正を余儀なくされました。「開発者が技術的な制約を指摘するタイミングが遅すぎて、当初の設計ビジョンを維持できなくなることが多いのです」と Rita は説明します。Rita は、開発プロセスとの統合を改善し、設計をより早期に検証する方法を必要としていました。
プロダクト マネージャーの Paul は連携維持に努めていました。長時間かけて詳細な要件ドキュメントを書いても、常に何かが欠落します。「伝言ゲームをしている気分です」と Paul は訴えます。「機能が顧客に届く頃には、当初想定していたものとは異なるものに変化しています」エンジニアリング チームと設計チームの間のコラボレーション改善を懸命に模索していましたが、従来の引き継ぎプロセスに阻まれ続けていました。
プログラム マネージャーの Rick は、おそらくすべての中で最も難しい役割を担っていました。デリバリーの速度と品質のバランスを取りながら、複数のチームにわたる依存関係を調整する作業に夜遅くまで取り組んでいました。「チームがサイロ化して作業していると、単純な変更が数週間の遅れにつながることがあります」と Rick は指摘します。チーム間のコラボレーションと可視性の改善を進める方法が必要でした。
エンジニアリング リーダーの Anna はすべてを監督する役割を担い、チームの運営方法を変革しようと奮闘していました。技術的卓越性の価値を認めながらも、何かが欠けていることを認識していました。「きわめて能力の高いエンジニアがいるものの、顧客が必要とする価値を一貫して提供しているわけではありません」と Anna は語ります。Anna はチームの文化を変えようと考えましたが、従来の開発モデルでは、優れた技術と顧客にとっての価値のバランスを取ることが困難でした。
このチームの経験は、ソフトウェア開発の幅広いパターンを反映しています。従来の順序に従ったアプローチは、整理されていて予測可能ですが、プロダクトを作る側と使う側の間に自ずと断絶が生じます。
文化: 変革の鍵
「文化は戦略を朝食に食べる」これは有名な経営学者であるピーター・ドラッカーのものとして引用されることが多い言葉ですが、広く知られるようになったきっかけは、2006 年にマーク・フィールズがフォードの戦略会議室に恒常的に掲示したことでした。このメッセージは単なるキャッチーなフレーズではありませんでした。非常に優れた戦略でも、組織文化と矛盾すれば失敗するという、テクノロジー業界で私たちが繰り返し見てきた基本的な真実を捉えたものだったのです。
Compass でエンジニアリング文化を変革すると決めたとき、重大な発見がありました。技術が優れているだけでは不十分だということです。エンジニアと顧客の間のギャップを埋める必要がありました。数字がこのことを裏付けています。強い文化を持つ企業は、競合他社と比較して収益の増加が 4 倍になっています。
Compass での私たちの変革の道のりには、まさにこのことが表れています。通常完了するまでに 6 から 8 週間かかっていた従来の機能ライフサイクル プロセスから反復的なディスカバリー プロセスに移行したことで、顧客の問題への距離が大幅に縮まりました。これは単なるプロセスの変更ではなく、「知っているはず」から「すべてを学ぶ」という考え方への根本的な転換であり、すべての機能が顧客から学ぶ機会となりました。
プロダクト エンジニアリングの進化
ソフトウェア エンジニアリングでは、従来、体系的な設計、開発、テストを通じて、要件を動作するコードに変えることを目指してきました。エンジニアは主に、効率的なコードの記述、システムの保守、品質の確保など、技術的な作業に重点を置きます。
一方、プロダクト エンジニアリングは、ソフトウェア構築についての考え方を根本的に変えるものです。ソフトウェア エンジニアリングの技術的な厳密さを維持しながら、顧客への深い理解と継続的な学びという重要な要素を加えています。プロダクト エンジニアは単にコードを記述するのではなく、顧客の問題の発見と解決、プロダクトに関する意思決定に技術的な知見を提供し、作業の結果に対する当事者となります。
従来のソフトウェア エンジニアリング モデル
従来のモデルでは、開発は直線的に進行します。要件は、プロダクト管理から設計を経由して実装するエンジニアリング チームに到達します。各チームが次のチームにバトンを渡すリレーのような状態です。
私たちのチームの古いワークフローは、この直線的なアプローチを反映していました。
- 要件ドキュメントの作成と承認に数か月かかっていました。
- アーキテクトとデザイナーは孤立して作業していました。
- エンジニアは正確な仕様に合わせてコーディングしていました。
- テストとデプロイは最後に実施していました。
- 顧客からのフィードバックは複数の層でフィルターされていました。
このアプローチは、要件が安定していて、変更に費用がかかる場合にうまく機能しました。しかし、今日の急速に進化する市場では、より適応的で顧客中心の何かが必要でした。
プロダクト エンジニアリングの継続的なループ
私たちの変革では、この線形的なプロセスを継続的な学びのループに置き換えることを中心に据えました。現在、開発は、リレー競技のように扱うのではなく、サッカー チームのように運営されています。全員がともに行動し、変化する状況に適応して、顧客に価値を提供するという目的を常に意識しています。
新しいモデルでは:
- エンジニアが顧客インタビューとディスカバリー セッションに参加します。
- 開発と設計がコラボレーションし、ラピッド プロトタイピングとテストを実施します。
- 技術的な意思決定を顧客のニーズに照らして検証します。
- デプロイが単なるデリバリーのマイルストーンではなく学ぶ機会になります。
- チームは技術的なメトリックだけでなく、顧客への影響を通じて成功を測ります。
実装から当事者意識へ
Tina のようなエンジニアにとって、この変革は純粋な実装から真の当事者意識への進化を意味しました。現在、エンジニアは次のような状態です。
- 問題の定義と解決策の探求に参加します。
- 技術的な視点を早い段階での議論にもたらします。
- 前提条件を顧客とともに直接検証します。
- 単なるコード品質にとどまらず機能の成果を当事者として意識します。
- ビジネス メトリックと市場への影響を追跡します。
結果自体がその効果を語っています。このモデルを採用している組織は、従来のエンジニアリング アプローチを採用している組織よりも、市場投入までの時間が短く、機能の導入率が高くなっています。おそらくより重要なことは、チームのエンゲージメントが高まり、技術的な意思決定が改善され、技術ソリューションと顧客のニーズとの連携が強化されたことです。
変革を実現した方法
エンジニアの働き方を変えるには、考え方の変化だけでなく、適切な基盤が必要でした。私たちのチームにとって、この基盤の重要な部分は Jira Product Discovery でした。これは、日常のワークフローに顧客のコンテキストを自然に取り入れるためのツールです。
最初に解決する必要があった課題は、誰もが顧客インサイトにアクセスできるようにすることでした。以前は、顧客からのフィードバックと製品要件は、Confluence ドキュメント、Slack スレッド、Jira チケットに含まれていました。Jira Product Discovery により、これらすべてのコンテキストが開発ワークフローに直接取り込まれました。エンジニアが、顧客インタビュー、フィードバック セッション、利用状況パターンを開発作業と並行して確認できるようになったことで、顧客のニーズが抽象的で遠いものではなく、具体的かつ身近なものになりました。
このようにアクセスしやすくなったことで、チームのコラボレーション方法が根本的に変わりました。Rita のようなデザイナーが新しい設計を作成したとき、エンジニアが見て理解できる顧客の問題点に設計を直接リンクできました。Paul が機能を優先順位づけしたとき、顧客への影響を技術的な複雑さに簡単に結合でき、意思決定により多くの情報を反映できました。最も重要なことは、エンジニアにようやく全体像、つまり、何を構築するかだけでなく、なぜそれが顧客にとって重要で、それが顧客の作業にどのように影響するかが見えるようになったのです。
同様の変革を検討しているチームは、技術的卓越性と顧客重視のどちらかを選ぶのではなく、両者を組み合わせて、顧客に本当に愛される製品を作ることが重要であることを忘れないでください。エンジニアが顧客のニーズを深く理解していれば、技術的な意思決定をより的確に行い、より洗練されたソリューションを設計し、その直接的な影響を確認できるため、自分の仕事に大きな意味を見出すことができます。
この変革を実現した方法についての詳細は、ウェビナー「The Magic Behind Product Engineering: Turning Customer Problems into Features They Love (プロダクト エンジニアリングの裏にある魔法: 顧客の問題を顧客が望む機能に変える)」をご覧ください。このウェビナーでは、私たちの取り組みを深く掘り下げ、チームで実践できる実践的な戦略や習慣を共有しています。