このブログでは、ビズリーチが推進するSODA構想（SODA : Software Outcome Delivery Architecture）についてプロダクト組織の観点から説明しています。プロダクト組織が進むべき未来に向かうための「計器飛行」とは何か、計器飛行のポイントやプロダクト組織が目指すべき方向について解説します。また、航空機が「空の上でなんの標識もないのに」ちゃんと目的地に行ける秘密と照らし合わせて、プロダクト組織における「ロードマップ」と「マイルストーン」の重要性に触れます。全3回（前編・中編・後編）の前編。
はじめに
ビズリーチでは、プロダクト組織が進むべきゴールに向かうための「計器飛行」を実現すべく、その土台となるSODA構想（SODA : Software Outcome Delivery Architecture）を進めています。
今回のブログでは、SODA構想とは何かを語る前にそもそもプロダクト組織になぜ「計器飛行」というメタファーを持ち込んだかについて説明します。
プロダクト組織と計器飛行
まず、プロダクト組織の定義ですが、製品またはサービスを開発、実装、維持するための専門チームが組織された形態とします。この形態は、プロダクトマネージャーやプロダクトオーナー、エンジニアやデザイナーなどの専門家から構成されます。
プロダクト組織と計器飛行には、一見関連性がないように思われるかもしれません。しかし、プロダクトの力で事業を行うことと、航空機を操縦して目的地を目指すことには共通点が多くあります。
航空業界において、悪天候や夜間など視認が困難な状況で、航空機が計器や航空管制の指示に従って飛行する方法を「計器飛行方式（Instrument Flight Rules, IFR）」と言います。これには、計器の利用、飛行計画の作成、航空管制との連携、標準化された手順とチェックリストの使用、計器着陸システム（Instrument Landing System,ILS）の活用が含まれます。そして、なによりも適切な訓練を受けたパイロットと適切な装備を持つ航空機が必要です。
以下の動画では、濃い霧の中で視界が悪く夜間で何も見えない中、計器着陸システム（ILS）を使って着陸を試みる様子が映っています。
まずは、動画をご覧ください。
この動画では、はじめはライトが明るく雲を照らしていますが（視界はゼロ）、ライトOFFにより真っ暗闇になります。そしてしばらくすると突然滑走路のアプローチライトが現れます。素人からするとなかなかの恐怖です。しかし、コックピットの計器に表示される様々なデータを参照しながら目視に頼らずに着陸できるテクノロジーは素晴らしいですね。
このように、プロダクト組織においてもデータを参照しながら「計器飛行」のようなマネジメントを実現することは、VUCA（変動性、不確実性、複雑性、曖昧性）の時代と言われる中で、とても重要になっています。
開発チームがパイロットで、経営者は航空管制官
数値化は、プロダクト組織が未来に向かって進んでいるかどうかを確認するための目安です。「計器飛行」とは、決められた空のルートを航空管制官からの指示と計器類を使って飛行する方法を指します。この「パイロットと航空管制官」の関係は、プロダクト組織における「開発チームと経営者」の関係にとても似ています。どちらが欠けても安全な運行ができません。以下の表にそれぞれの類似点をまとめました。
表1. 「パイロットと開発チーム」の類似点
| 類似点 | パイロット | 開発チーム |
|---|---|---|
| 専門的知識や技術が必要なこと | 飛行機の操作やナビゲーション、気象や機械の知識が必要 | コンピューターシステムやプログラミング、データベースやネットワークの知識が必要 |
| 持続的な学習が必要なこと | 新しい機材や技術の習得、法規やルールの更新に対応するために、常に学習し続ける必要がある | 新しい技術や言語、フレームワークの習得、セキュリティー対策など、常に最新の知識を学び続ける必要がある |
| チームワークが必要なこと | 操縦士やグランドクルー、管制官などと協力して安全なフライトを実現する必要がある | チーム開発やプロジェクトにおいて、チームメンバーと協力してプロダクトを開発する必要がある |
| プレッシャーに耐える能力が必要なこと | 緊急事態やトラブル時に冷静さを保ち、的確な対応をする必要がある | 締め切りやシステムダウンの際に冷静さを保ち、迅速かつ正確な対応が求められる |
表2. 「航空管制官と経営者」の類似点
| 類似点 | 航空管制官 | 経営者 |
|---|---|---|
| 意思決定能力が必要なこと | 緊急事態やトラブル時に素早い判断力が必要 | 戦略的な意思決定が必要 |
| 責任が大きいこと | 航空安全の確保に責任を負う | 企業の成長や利益の最大化に責任を負う |
| チームワークが必要なこと | パイロットやグランドクルーと協力して安全なフライトを実現 | 部門や社員と協力して目標達成を目指す |
| プレッシャーに耐える能力が必要なこと | 多忙な状況下で迅速に対応するためのプレッシャーに直面 | 市場の変化や競合他社の動向などのプレッシャーに直面 |
すごく似ていると思いませんか？
道と目印
ところで、航空機はなぜ空に目印がないのに迷わずに目的地にたどり着けるのでしょうか？
その答えの一つは「ウェイポイント(way point)」です。ウェイポイントとは、緯度と経度で決められた特定の1点で、航空機が目的地に向かうための目印や、航空路と航空路の交差点になる場所です。重複しないアルファベット5文字の名前が付いており、例えば和歌山から大阪までの航空路にあるウェイポイントは「HONMA」や「KAINA」と名付けられています。ほんまかいな？
ウェイポイントを利用した飛行機の飛び方は、ぜひチコちゃんに聞いてください。
「ロードマップ」と「マイルストーン」
では、プロダクト組織における道や目印とはなんでしょう。
航空機が「航路（飛行ルート）」と「ウェイポイント」を頼りに目的地に向かうように、プロダクトにも道と目印が必要です。それぞれ「ロードマップ」と「マイルストーン」といいます。
| 飛行機の計器飛行 | プロダクト組織の計器飛行 | |
|---|---|---|
| 道 | 航路（飛行ルート） | ロードマップ |
| 目印 | ウェイポイント（通過座標） | マイルストーン |
「計器飛行」を導入することで、開発チームが「ロードマップ」通りに進んでいるか、「マイルストーン」をきちんと達成しているかが確認できるようになります。これにより、「私たちはどこを飛んでいるのか？」が明確になり、チームの透明性が高まります。
ビズリーチのプロダクト組織は、ソフトウェアの力を活用してプロダクトを継続的にデリバリーします。製品やサービスを顧客に長期間利用してもらうためには、製品開発サイクルを短縮しながら、市場の動向に合わせたプロダクトを提供することが重要です。
しかし、変化の激しい時代であるためゴール達成への道のりは容易ではありません。
ご存知の通り、この3年間はCOVID-19の影響で仕事や生活に大きな影響を受けており、世界的情勢不安や原材料費の高騰なども起きています。
このように、VUCAの時代と言われる中ではあらゆることを正確に予測することは困難です。すなわち、ゴールは1つ・ルートも1本という状況はほぼありえないのです。プロダクト開発の文脈で言えば「最初に立てた計画は、きっとすぐ変わる」ということです。
プロダクト組織は、「顧客の成果」「組織の能力」「ビジネスの結果」といったエビデンスを検証しながら「計器飛行」する必要があります。そして、定期的に立ち止まり、きちんと「ゴール」を目指せているか、計測結果を検証しながら確認をします。もし、ズレているようであれば、進む方向の修正を行うのです。つまり、最初に立てた計画は適宜アップデートされるということです。
これを「エビデンスベースの計器飛行」と呼びます。
なお、一概に「ゴール」といってもいくつかのカテゴリーがあります。長くなるので本ブログでは触れませんが、興味のある方はサーバントワークス長沢智治さんの訳した、Ralph Jochamさんによる「Deciphering Goals」を参考にしてください。
さて、プロダクト組織で「計器飛行」を実現するには2つのポイントがあります。
| 1 | プロダクト・ロードマップを描き、そこから計画を立てる |
|---|---|
| 2 | 重要な指標を特定し自動で計測できるように仕込む |
順番に説明して行きましょう。
プロダクト・ロードマップを描き、そこから計画を立てる
言葉というのは、時代と共に意味が変わったり、もともとの意味が失われるものが沢山ありますが「ロードマップ」もそのひとつかもしれません。GPSシステムによるカーナビが普及する以前は、車には必ず地図帳（ロードマップ）が積んであったものです。遠出するときほど、助手席のひとに地図読み（リアル・ナビゲーション）をしてもらうのは重要なミッションでした。道に迷ったら、一旦車を脇に停めて、とにかく地図を確認する…なんて時代が長くあったのです。
そういったわけで「ロードマップ」は道路や経路を表す地図を意味から転じて，製品開発や発表など，物事の展開していく過程を示した計画案・行程表の意味に使われるようになりました。
つまり「プロダクト・ロードマップ」というのは「現在」から「未来」までの道筋を表す「地図を作る」行為にほかなりません。きちんと「ものづくり」をナビゲーションが出来るかどうかは、「読みやすい地図」が書けることが条件となっていきます。
たとえば、ロードマップに「機能」だけ羅列してあったとしたら、それは「読みやすい地図」とは言えません。なぜなら「機能」は仮説検証を繰り返すなかで「実はあの機能も足りなかった」みたいにカタチを変えやすいからです。
また、ただプロセスが書いてあるロードマップも「読みやすい地図」とは言えません。プロセスはコトの流れを表すだけであり、何を成し遂げるべきかを描けないからです。
「読みやすい地図」としてのプロダクト・ロードマップには、顧客やユーザにどういった価値を与えたいのか「アウトカム」が書かれています。「アウトカム」を達成する手段としての「機能」開発ですので、開発目標（アウトカム）さえ理解できていれば様々な機能のアイデアが湧いてくる可能性だってあります。
この点に関するノウハウは、小城久美子さんのブログがとても参照になります。
ロードマップに機能を書くべからず｜小城久美子 / ozyozyo｜note
さて、プロダクト・ロードマップが描けたら次は計画です。
時折、ロードマップさえ描けたらプロダクトの計画が終わったと勘違いする人もいます。残念ながらそれは、地図だけ用意して「旅のしおり」が無いことと同じです。
下図は、PMBOKガイド第7版で記された、アジャイルアプローチにおけるプロダクト・ロードマップと計画の関連図です。
この場合、このロードマップをもとに「リリース計画」と「イテレーション計画」にブレークダウンされていきます。スクラムで言えば、バックログのプランニングやリファインメント、スプリントプランニングなど相当します。
なお、アジャイルアプローチだけに着目していると計画立案時に抜けがちな、プロジェクト・マネジメントの原理原則というものがあります。アジャイルなのにプロジェクト・マネジメント？と違和感を覚える方も多いと思いますが、現代のプロジェクトマネジメントは、前時代的なプロジェクトマネジメントとまったく違います。
PMBOK第7版においては、以下の12の原理・原則をガイドラインとして提示されていますので、アジャイルな計画にも考慮すると良いです。
| # | 12の原理・原則 | 内容 |
|---|---|---|
| 1 | スチュワードシップ | 勤勉で、敬意を払い、面倒見の良いスチュワードであること |
| 2 | チーム | 協働的なプロジェクト・チーム環境を構築すること |
| 3 | ステークホルダー | ステークホルダーと効果的に関わること |
| 4 | 価値 | 価値に焦点を当てること |
| 5 | システム思考 | システムの相互作用を認識し、評価し、対応すること |
| 6 | リーダーシップ | リーダーシップを発揮すること |
| 7 | テーラリング | 状況に応じてテーラリング（対応）すること |
| 8 | 品質 | プロセスと成果物に品質を組み込むこと |
| 9 | 複雑さ | 複雑さに対処すること |
| 10 | リスク | リスク対応を最適化すること |
| 11 | 適応性と回復力 | 適応力と回復力を持つこと |
| 12 | 変革 | 想定される未来の状態を達成するために変革できるようにすること |
私の経験では、アジャイルアプローチではよく「8.品質」と「10.リスク」の考慮が抜けやすいです。これらを考慮するだけでも、グッとものづくりの成功率は上がり、アウトカム達成に近づきます。
さらに、計画策定で気をつけたいのがやりたいこと(ユーザー・ストーリー)が多すぎる場合です。スクラムで言えば、見積もり済みのPBI(プロダクトバックログアイテム)がどっさりとバックログに積まれた状態を指します。
スタートアップの場合、実現したいことが山ほどあって、でもプロダクト開発が迷走すると、苦労して集めた資金が枯渇してしまうことになります。名著「ユーザーストーリーマッピング」の冒頭では、次のようなエピソードが書かれています。
ゲイリーはバックログを作り、開発チームは1つずつ作っていった。完成した部品に支払いを続けているうちに、ゲイリーの資金はどんどん減っていった。完成した部品はゆっくり形になってきたが、ゲイリーからすると、自分のビジョン通りのものにするにはまだまだ足りない。しかし、彼はそれよりもはるかに手前のところで資金を使い果たしそうになっていた。
【引用: パットン, J. (2015). ユーザーストーリーマッピング. 川口恭伸 & 長尾高弘 (訳). オライリー・ジャパン. (原著出版年 2014) p.24】
著者のジェフ・パットンはゲイリーを助けるためにコンサルを開始します。このとき真っ先用いた手法がユーザーストーリーマッピングです。これは、ユーザーが製品やサービスを利用するための「ストーリー」を（壁や床に付せん紙などで）マッピングしながら、そのストーリーに必要な機能や要素を整理する手法です。ユーザーの視点からストーリーを整理することで、製品やサービスの改善点や優先度を明確にすることができます。また、ビジネス上の課題や戦略的な観点からも、プロダクトのロードマップを策定する上で有用な手法とされています。
一見すると単純そうですが、並べ替えるには視座を高くして様々な考慮が必要になります。ゲイリーは、果たして無事プロダクトを成功させられたでしょうか？書籍「ユーザーストーリーマッピング」を未読の方は、「1章 全体像」だけでも読んで確かめてください。
ロードマップや計画作りについては、機会があれば別のブログで詳しく説明したいと思います。
次回のブログでは
ここまで「計器飛行」を実現するため重要な 「1. プロダクト・ロードマップを描き、そこから計画を立てる」 について説明しました。
計画まで順調にいけば、次は 「2. 重要な指標を特定し自動で計測できるように仕込む」 の番です。ところが、プロダクト組織ではこの「計測」に一番の障壁があるのです……。次回、エンジニアが計測に対して抱く苦手意識とその背景にある問題を「中編」として考察したいと思います。
⚠️ 注：日本の航空法においては 『計器飛行』 と 『計器飛行方式』 という2つの似た専門用語があり、それぞれで意味が異なります。当ブログ内のメタファーとしては『計器飛行方式』の意味で使っているのですが、航空の専門性を扱うブログではないことから日本語として自然な 『計器飛行』で統一 させて頂きました。 ＊『計器飛行』：航空機の姿勢、高度、位置及び針路の測定を計器にのみ依存して行う飛行行為を指す。視界が悪い状況下以外では行われない。 ＊『計器飛行方式』：国が指定する飛行場からの離陸・着陸や経路に従い、航空交通管制機関の指示や承認に基づいて行われる飛行の規則や手順。
