アライメントマップ

2015年8月18日

アライメントマップは、進行中の作業とビジネス成果との整合性を可視化するのに役立つ組織の情報ラジエーターです。作業は、通常の機能追加や、アーキテクチャの再構築、技術的負債の返済、ビルドとデプロイメントのパイプラインの改善などの技術的な作業である場合があります。チームメンバーは、アライメントマップを使用して、日々の作業がどのビジネス成果を改善することを目的としているかを理解します。ビジネスおよびITのスポンサーは、これらのマップを使用して、進行中の作業が、彼らが関心を持つビジネス成果にどのように関連しているかを理解します。

これらのマップがどのように役立つかを示す、実際の事例から着想を得たシナリオの例を次に示します。開発者のチームは、カタログ検索機能をN+1回呼び出しとして非効率的に実装していました。カタログインデックスへの最初の呼び出しは、SKU IDのセットを返しました。返された各IDについて、製品詳細を取得するためのクエリが作成されました。この実装は、パフォーマンステストに失敗したときに、アーキテクトの注意を引きました。彼はチームにN+1の実装を削除するようにアドバイスしました。

「Search-in-one」は、彼がチームに目標を思い出す方法として提供したマントラでした。アーキテクトと開発者の間の組織的な境界と、彼らの間のコミュニケーションの頻度が低いことを考えると、そのマントラは文字通りに受け止められました。チームは、単一の呼び出しで結合されたインデックスクエリと詳細クエリを実装するために全力を尽くしました。彼らは検索パフォーマンスを向上させるという真の目標を見失い、正確に1回の呼び出しで許容できるパフォーマンスを達成しようと努力しました。数か月で資金が不足し、白熱した議論の末、プロジェクトはキャンセルされ、チームは解散しました。

上記の例は不合理に見えるかもしれませんが、悲しいことに、エンタープライズITは、最初に資金が提供された理由を見失ったために、しばらくしてキャンセルされるアーキテクチャおよびビジネスプロジェクトによく見られます。組織設計の用語では、これらはアライメントの問題です。

アライメントの可視化

大まかに言えば、IT戦略はビジネス戦略と、IT成果は望ましいビジネス成果と整合している必要があります。ビジネス成果は、1つ以上のIT成果によって（部分的に）サポートされる場合があります。各IT成果は、1つ以上のイニシアチブ（作業プログラム、アーキテクチャまたはビジネス）によって実現される場合があります。この時点で、イニシアチブのオーナーを特定することも役立つ可能性があります。そのオーナーは、イニシアチブの実行の一環として、複数のチームにわたる作業（アクションアイテム）をスポンサーします。イニシアチブによっては、オーナーはプロダクトオーナー、アーキテクト、技術リーダー、またはマネージャーである場合があります。これが、「search-in-one」の場合のアライメントマップです。チームの作業エリアに公開表示されていれば、誰かが一歩下がって、自分の作業が実際に何を達成することを目的としているのかを尋ねるきっかけになったかもしれません。

グローバルマップ

IT（アプリ開発+運用）組織のグローバルアライメントマップは、次のようになります（ただし、実際のマップははるかに大きくなる傾向があります）。

すべての情報ラジエーターと同様に、このようなマップは特定時点でのスナップショットであり、定期的に（たとえば月に1回）更新する必要があります。各チームは、グローバルマップの大きな印刷物を作業エリアに表示します。

大規模な組織は、誰もが同意するそのようなマップのバージョン1.0を作成するために協力することで、この演習の早い段階で価値を実現する可能性があります。誰がどのイニシアチブを所有し、イニシアチブがどの成果に貢献するかについての議論は、誰もが何をしているかについての組織的な明確さにつながります。通常、明確に表現され、共通に理解されているビジネスおよびIT戦略がないことが、ビジネスおよびIT成果のセットに収束する妨げになります。組織の関連部分全体にわたる深く幅広い参加を得た、十分に促進されたワークショップは、この問題に対処するのに役立ちます。

アライメントパスの追跡

グローバルアライメントマップが配置されると、どちらの端からでもアライメントを追跡できます。ITおよびビジネスのスポンサーは、特定のイニシアチブの下で実行中のアクションアイテムを追跡できます。開発チームのメンバーは、マップをたどって、自分が取り組んでいるアイテムの真の目的を理解できます。進行中のアイテムに加えて、計画、完了、またはブロックされているアクションアイテムを含めることもできます。

上記のマップに示すように、各チームはグローバルマップのコピーでマップのセクションを強調表示します。

定性的な利点の検証

月に1回（または四半期に1回）、ITとビジネスの人々が集まり、すべてのIT活動がビジネス成果に何らかの変化をもたらしたかどうかを検証します。ビジネスの人々は、ビジネス成果に対する赤-黄-緑（RAG）のステータスを付けて会議に出席し、ITの人々はマップの自分の側面のRAGステータスを付けて会議に出席する場合があります。両当事者は、RAG評価をデータや現場からの実際のストーリー（ナラティブ証拠）で裏付ける必要があります。

これらのマップは組み合わせることができます

これにより、グループは次のことを理解する可能性があります。

一部の成果は、前回の会議と比較してグリーンに変わりました。おそらく、レスポンシブな書き換えイニシアチブの最後のリリース後、顧客維持率がグリーンに変わりました。
すべてのIT活動が、ビジネス成果に期待される変化をもたらしているわけではありません。これは、その理由について話し合う機会を提供します。おそらく、
- 少し早すぎます。違いを期待する前に、他の計画されたアイテムを完了する必要があります。これが、上記のマップで、サイトUXがグリーンであっても、顧客獲得が赤である理由である可能性があります。プラットフォームのアンバンドリングはまだ不完全です。
- イニシアチブとアクションアイテムは理にかなっていますが、異なる実行アプローチが必要です（これが「search-in-one」の場合の理由です）。
- 異なるイニシアチブまたはアクションのセットが必要であり、既存のイニシアチブはキャンセルする方が適切です。ビジネスが価値を実現する前に、IT以外の何かが適切に配置される必要があります。
関連するITイニシアチブがそうではない場合でも、いくつかのビジネス成果がグリーンです。これは、ITが他のIT以外の要因よりもこの成果にとって重要ではないことを意味する可能性があります。上記のマップでは、サイトのパフォーマンスがそうではない場合でも、顧客維持率がグリーンである理由はおそらくこれです。おそらくITは、パフォーマンスが本来あるべき場所ではないが、それがまだ維持率に影響を与えていないと言うつもりです。

要約すると、アライメントマップは、さまざまなITイニシアチブがどの程度効果を発揮しているかを議論するための、組織全体に共通のツールを提供します。また、進行中の作業を理解し、ビジネス目標との整合性を高める能力を向上させる可能性もあります。私はこの手法を十分に試していないため、一般的な有効性を主張することはできませんが、十分な有望性を示していると思います。これを試してみる場合は、その経験についてお聞かせいただければ幸いです。

謝辞

ご意見をいただいたJim Gumbley、Kief Morris、Vinod Sankaranarayananに感謝します。コンテンツに関するガイダンスと出版へのご協力いただいたMartin Fowlerに特に感謝します。

参考文献

私は、組織のアジリティを促進するのに役立つ他の情報ラジエーターを、著書「Agile IT Organization Design」で説明しています。私のコンパニオンウェブサイトwww.agileorgdesign.comには、さらに詳しい記事と私の講演へのリンクが含まれています。

Lars Barkmanは、graphvizでアライメントマップを構築する方法の詳細を投稿しました。