ビジネスとテクノロジーを結びつけて戦略的思考を発揮する方法 (書評)

『The Value Flywheel Effect: Power the Future and Accelerate Your Organization to the Modern Cloud』
David Anderson、Mark McCann および Michael O’Reilly 著

この投稿では、注目の新刊書籍をご紹介したいと思います。これはビジネス、テクノロジー、そして人が交差する点について書かれた本です。新しいテクノロジーが及ぼすビジネスへの影響を最大化し、内部プロセスをスピードアップするために組織がどのように進化できるかを理解したい人にとっては素晴らしい読み物です。

去年の re: Invent で、David Anderson 氏とお目にかかる機会がありました。同氏は Liberty Mutual のテクノロジー担当ディレクターとして、1912 年に設立されたこの世界的な保険会社がサービスをクラウドに移行し、サーバーレスを主眼にした略を採用した際、テクノロジーの変革を推進しました。彼は、実験するのが常で、ソフトウェアエンジニアが時間と余裕を持って学習できる環境を作りました。これが非常に奏功し、ある時点で同氏の拡張チームには AWS ヒーローが 4 人いました。

数か月前、Mark McCann 氏と Michael O’Reilly 氏と共に本を執筆していると聞きました。彼らは皆、Liberty Mutual で一緒に働いており、他の組織が同様のアプローチを実施するのに役立てるために、学んだことをまとめていました。出会った当時は本が出版されて間もない頃で、タイトルを手始めに、もっと詳しく知りたいと思いました。出会ったのはエキスポ会場で、Anderson 氏は親切にもその書籍のサイン本をくれました。

この本は、私が好きな『The Phoenix Project』、『Team Topologies』、『Accelerate』などの本を出版している IT Revolution から出版されています。この本が The Value Flywheel Effect と題されているのは、組織の中のビジネスとテクノロジーを結びつけると、フライホイールが回り始めて小さな成功のたびに勢いを増すからです。

The Value Flywhell
Value Flywheel の 4 つのフェーズは次のとおりです。

1. 目的の明確化 – このパートでは、組織にとって何が本当に重要なのか、何が自社を差別化しているのかを見極め、共通の方向性を見出し、それとの距離を測る方法を探ります。このフェーズでは、CEO の視点から会社を見ます。
2. 課題と展望 – ここでは、組織の準備を整え、チームのための環境をセットアップします。技術チームの社会的側面を忘れがちですが、ここではチームが活動するための適切なレベルの心理的な安定性を打ち立てる方法に特に焦点が当てられています。このフェーズはエンジニア向けです。
3. 次のベストアクション – このフェーズでは、プロダクトリーダーのように考え、開発者のエクスペリエンスを向上させる方法に焦点を当てる形で次のステップの計画を練ります。重要な点の 1 つは、「コードは負担」であることです。ビジネス上の問題を解決するために作成するコードが少なければ少ないほど、スピードとメンテナンスの面で優れています。例えば、すべてカスタム実装するのではなく、その要件をクラウドプロバイダーが提供する機能に頼ることができます。
4. 長期的価値 – これは CTO の視点であり、よく設計されたシステムと、オブザーバビリティと持続持続性に焦点を当てた問題予防の文化をどのように築くかを検討します。ここに言う持続可能性は、地球環境だけでなく、組織で働くチームや人々も考慮に入れます。

フライホイール (弾み車) のように、この 4 つの段階を繰り返すことで、新しいスピンがより簡単に、より速くなるようにします。

Wardley マッピング
この本で私が本当に感謝していることの 1 つは、技術的なシナリオで Wardley マッピング (通常はビジネスコンテキストに適用) を簡単に利用できるようになったことです。Simon Wardley が考案した Wardley マップは、企業が事業を展開する風景を視覚的に見れるようにします。

各マップはバリューチェーンで構成され、そこで顧客が必要とするコンポーネントを描きます。コンポーネント同士が接続され、相互に依存している様子が分かります。コンポーネントの位置は、コンポーネントが顧客にどの程度見えるか (縦方向) と、発生から製品や商品になるまでの進化状況 (横方向) に基づいています。時間の経過とともに、一部のコンポーネントはカスタムビルドから製品やコモディティへと進化します。これは、物事が進展するにつれて自然に右に動いてマップ上に表示されます。例えば、データセンターは以前はカスタムビルドされていましたが、その後標準製品になり、クラウドコンピューティングによって商品として利用できるようになりました。

マップの基本要素 – Simon Wardley の厚意により提供されました (CC BY-SA 4.0)。

マッピングを利用すると、どのような改善が必要で、どのような技術ソリューションにどのようなギャップがあるかをより簡単に理解できます。このようにして、エンジニアは、影響を最大化するためにどのコンポーネントに焦点を当てるべきか、どの部分が戦略的ではなく、SaaS ソリューションにオフロードできるかを特定できます。これは一種の進化型アーキテクチャで、マッピングによって、システムが時間とともにどのように進化すべきかを先取りし、慣性によってシステムのどの部分の進化が遅れる可能性があるかが分かります。

同じベストプラクティスがどこにでも当てはまるように見えることもありますが、そうではありません。マッピングの利点は、マップ上の水平位置によって示されるコンポーネントの進化状況に基づいて、使用するのに最適なチームと方法論を特定できることです。例えば、「探検家」の姿勢は、その黎明期やカスタムメイドのコンポーネントに最も適しており、「村人」は製品に最も適して、何かが商品になったら「都市計画者」が必要です。

より多くのツールと少ないコード
著者は、利用できる多くのツールとフレームワークに注目しています。例えば、この本では、まず最も重要な指標 (共通の目標) を特定して製品を管理する手法である North Star Framework や、チームがソフトウェア製品に大きな影響を与えるのに役立つ主要な指標に焦点を当てた共同計画手法である Gojko Adzic の Impact Mapping が紹介されています。ちなみに、Gojko は AWS サーバーレスヒーローでもあります。

もうひとつ興味深いのは、エンジニアに学習に必要な時間と余裕をどう提供するかです。具体的には、社内イベントの呼びかけや、公開会議との比較などが気に入っています。社内イベントでは、エンジニアには会社の環境で新しいテクノロジーを使用する機会があり、実際のシナリオの限界を超えて何ができるかを簡単にデモンストレーションできます。

最後に、「コードは負担」という記述によってこの本の意図を明確に定義している部分を取り上げたいと思います。

「ソフトウェアチームに何かを構築するよう依頼すると、コードの行ではなくシステムを提供してきます。アセットはコードではなく、システムなのです。システム内のコードが少なければ少ないほど、費やしたオーバーヘッドも少なく済んだということになります。開発者の中には、自分が書いたコードの量を自慢する人もいるかもしれませんが、これは自慢できることではありません」

これはプログラミングの本ではなく、フライホイールを高速化する方法の例として、サーバーレステクノロジーが使われています。サーバーレステクノロジーに関する技術的な詳細については、サーバーレスコンピューティングに関する最新情報と学習リソースをまとめたサイトである Serverless Land、または AWS 上のサーバーレスアーキテクチャの本をご覧ください。

あらゆるビジネスがテクノロジービジネスとなった昨今、The Value Flywheel Effect は、いかに組織を加速させ、変革していくかということをテーマにしています。クラウドコンピューティングを採用してそのメリットを享受しようとするときに、アプリケーションを最新化するための適切な環境、目的、段階を設定するのに役立ちます。

Serverless Edge では、Anderson 氏、McCann 氏と O’Reilly 氏に会うことができます。そこでは、テクノロジーにこだわるエンジニア、テクノロジー愛好家、マーケティング担当者、オピニオンリーダーのチームが、サーバーレスがビジネスモデルをどのように変革できるかを理解し、伝える手助けをしています。

– Danilo

原文はこちらです。