著名エンジニアが、独自の視点で「おすすめ書籍」の紹介を行う本連載。今回の語り手は『エンジニアリング組織論への招待』（技術評論社）の著者であり、株式会社レクター代表取締役の広木大地さんだ。

広木さん曰く、アーキテクチャ設計は「孤独な作業」になりがちとのこと。自身もテックリード時代、多くのステークホルダーの意見を集約し、ビジネスサイドの要望もくみ取りながら意思決定に必要な情報交換を行うことに関して、やり方もセオリーも分からず試行錯誤していたという。

そんな広木さんが「もしあの時に出会っていれば、もっとうまく立ち回れた」と感じているのが、今回紹介するアーキテクチャ設計に関する名著『Design It！ -プログラマーのためのアーキテクティング入門』（オライリー・ジャパン）だ。

本書をピックアップした背景

技術的な側面ばかりが注目されがちなアーキテクチャ設計ですが、本書では「アーキテクチャ」ではなく、それを造る行為としての「アーキテクティング」に注目しています。アーキテクチャ設計の社会活動としての側面に注目した、数少ない書籍といえます。

日々の業務や組織支援の中で、アーキテクチャ設計を組織として取り組むことの難しさに直面していた私にとっては、当時非常に魅力的なテーマの書籍でした。

本書の特徴と印象に残った章

本書は優れたソフトウエアアーキテクチャの設計方法を、具体的な原則と実践を通して解説しています。象牙の塔の理論ではなく、現実世界の問題解決に役立つ実践的な内容が紹介されています。

というのも本書で目指されているのは「必要十分な事前設計(Enough Design Up Front)」です。簡単に言うと、詳細な設計は事前にし過ぎてしまうのもよくないし、逆に軽視しすぎるのもよくないという問題提起。つまり、事前設計は“必要な分”だけで良いという考え方は、非常に現代的で現実的だといえるでしょう。

また著者は、継続的にサービス開発を進めるチームの中で、どのように漸進的にアーキテクチャ設計を進めていくべきかを自身の経験に基づいて語っています。特に、設計の為に必要な共同作業を「アクティビティ」という単位で具体的に示している点が、本書の大きな特徴です。

数あるアクティビティの中でも、特に印象に残ったものを紹介します。

ステークホルダーに共感する（第4章）

ソフトウエアアーキテクチャは、ステークホルダーのニーズを満たすものでなければなりません。本書では、ステークホルダーに共感し、彼らの真のニーズを理解することの重要性を繰り返し説いています。具体的なアクティビティとして、「共感マップ（アクティビティ6）の作成」や「ステークホルダーインタビュー（アクティビティ24）の実施」などが挙げられます。

アーキテクチャ上重要な要求を掘り下げる（第5章）

品質特性のような機能要求以外の要求は、見過ごされがちです。本書では、アーキテクチャ上重要な要求(ASR)として、「品質特性」「制約」「技術的負債」などを定義し、それらを明確化することの重要性を述べています。具体的なアクティビティとして、「ミニ品質特性ワークショップ（アクティビティ7）」や「技術的負債アイスバーグ（アクティビティ11）の作成」などが紹介されています。

チームのアーキテクト力を強める（第13章）

アーキテクチャ設計は孤独な作業になりがちですが、チーム全体で取り組むべき課題です。本書では、チームのアーキテクチャスキルを高め、全員が設計に参加できるような環境作りが重要だと述べています。具体的なアクティビティとして、「ペア設計（13.3.1項）」や「足場を作る（13.3.2項）」などが挙げられます。

本書で得られた教訓・学び

本書で提案されている、「ステークホルダーインタビュー」や「ワークショップ」といったアクティビティの数々は、まさにテックリード時代の私が当時欲しかったものです。もしあの時に本書があれば、もっとうまく立ち回れたのではないかと感じています。

また本書を通じて、アーキテクチャ設計は「アートに近い領域」であることに気付かされました。開発チームと共に、さまざまな制約やトレードオフを考慮しながら最適な解決策を探求していくプロセスは、まさに創造的な活動といえます。特に、本書で繰り返し述べられている「デザイン思考」のアプローチは、アーキテクチャ設計においても非常に有効であると感じています。

例えば10年以上昔の話になるのですが、私の所属していた会社でサービス開発をしているときのことです。徐々に開発組織が大きくなってきたタイミングで、複数のチームが平行して様々な機能の開発を手掛けていました。ただ、多くのユーザーが利用する大規模な機能開発だったため、チーム間の衝突も多発し、ひいては障害が発生するリスクも非常に高くなっていました。

私は当初直感的に、各人のエンジニアリングスキルやプロジェクトマネジメントの仕方が問題ではないかと、個人に問題を帰結させる考え方をしてしまっていました。ところが、注意深く開発チームやプロダクトマネジャーたちを観察してみると、組織全体がどうにもならない「ジレンマ」に陥っていることに気が付きました。機能の大きさとその影響範囲が大きくなる度に、パフォーマンステストやサーバー調達などのプロセスが鈍重になり、そのせいでプロジェクトをより大きくせざるを得ない状態にあったのです。

このような状況に対して、まずは共感し理解するところから始めると、その問題の本質が見えてきます。このケースでは「開発段階における影響範囲のコントロールの難しさ」が、本来解くべき課題だと理解できました。

そして解くべき課題を探求していくと、ビジネス要求の要素が見えてきます。

「開発中の機能を従業員でドッグフーディングしやすくすること」
「障害の影響範囲をコントロールすること」
「段階的に顧客にリリースして負荷を確かめながら提供すること」

これらの要求を満たすことが、問題を根本的に解決するために必要だと分かりました。

そこで私は、これら三つの要求を一手にコントロールできる「DI(依存性注入)のアーキテクチャ」を設計し、システムに組み込むことにしました。現在で言うと、FeatureFlagやダークローンチ、A/Bテスト基盤、サーキットブレーカーを、全て一つの抽象で提供したようなものです。（実装方法はより原始的ですが）

このようなアーキテクチャ要素を段階的・進化的に提供することで、プロダクトチームの行動が徐々に変化していきました。影響範囲を小さくすることでより挑戦的になったり、新しい企画を試しながらデータをもとに判断したりすることが可能になったのです。

このようなサービス開発の機構は、現在ではSaaSとして提供されるなどしてありふれたものになってきましたが、当時はまだ存在しない（存在しても局所的・限定的な）ものだったと思います。

私自身がそのようなことを考えついたのは、単に技術的な知識を持っていたからではありません。アーキテクトとして、人々を観察し、共感し、解決策を探求する。手触りのある方法で試作を作り試してみるという「デザイン思考的プロセス」を取ることができたからだと考えています。

まとめ

本書は、ソフトウエアアーキテクチャ設計の本質を捉え、実践的な手法を提示してくれる良書です。この本で得た知識やノウハウを、今後のアーキテクチャ設計に活かしていきたいと考えています。アーキテクチャ設計に携わる全ての人に、自信を持ってお勧めできる一冊です。

株式会社レクター代表取締役
一般社団法人日本CTO協会理事
広木大地さん（＠hiroki_daichi）

1983年生まれ。筑波大学大学院を卒業後、2008年に新卒第1期として株式会社ミクシィに入社。同社のアーキテクトとして、技術戦略から組織構築などに携わる。同社メディア開発部長、開発部部長、サービス本部長執行役員を務めた後、2015年退社。現在は、株式会社レクターを創業し、技術と経営をつなぐ技術組織のアドバイザリーとして、多数の会社の経営支援を行っている。著書『エンジニアリング組織論への招待～不確実性に向き合う思考と組織のリファクタング』が第6回ブクログ大賞・ビジネス書部門大賞、翔泳社ITエンジニアに読んでほしい技術書大賞2019・技術書大賞受賞。一般社団法人日本CTO協会理事。朝日新聞社社外CTO。

文／広木大地　編集／今中康達（編集部）