ソフトウェアアーキテクチャとどう向き合うべきか

皆さん、「ソフトウェアアーキテクチャ」と聞いて、何をイメージされるでしょうか？私自身、以前はクリーンアーキテクチャ、マイクロサービス、モジュラーモノリス、PubSub、Event Sourcing、CQRSといった、構造やインフラを強く連想していました。しかし、本日はもう少し根本的なところから、ソフトウェアアーキテクチャについて考えてみたいと思います。

まず、「アーキテクチャ」という言葉の語源に立ち返ってみましょう。この言葉は建築から派生したものです。建築物の設計や構造を指し示す言葉であり、家やビルを建てる際の設計図にあたります。設計図には平面図や正面図などさまざまな種類がありますが、これらの設計図があることで、間取りや部屋の配置、使用する材料、配管、電気配線などの計画を適切に立てることができ、結果として良い建物を作ることができます。

ソフトウェアアーキテクチャにおいても、基本的な概念は同じです。システム全体の設計図として、どのような部品・コンポーネントで構成されているのかを明らかにし、それらがどのように連携してソフトウェアとして動作するのかを示すものです。適切なソフトウェアアーキテクチャが確立されていれば、システムの性能、拡張性、保守性が向上すると一般的に言われています。

ここで一つ、重要な問いかけをしたいと思います。ソフトウェアアーキテクチャの目的は、良い設計図を書くことでしょうか？
建築を例に考えてみましょう。良い設計図があれば、良い建物が建てられるのでしょうか？実際には、必ずしもそうだとは言えません。作業員の方々のスキルや工法など、さまざまな要素が関連します。

ここで、建築とソフトウェアには決定的な違いがあるということについて述べておきます。建築の場合、基本的に最初に作った設計図を変更することはあまりありません。しかし、ソフトウェアはそうではありません。

アジャイル開発のように継続的にインクリメンタルに開発を進める手法や、ドメイン駆動開発のようにビジネスの変化に柔軟に対応することを重視する設計手法が提唱されているのは、まさにそのためです。つまり、誰かが最初に良い設計をするだけでは不十分なのです。

私は、ソフトウェアアーキテクチャの目的は、良い設計図を継続的にチームで進化させ続けることができる仕組みのことだと考えています。正直に申し上げますと、私のチームでもこれが完全にできているわけではなく、まだまだ改善の余地は多分にあります。しかし、約半年前と比べるとかなり改善していると自負しています。

これから、「良い設計図を継続的にチームで進化させ続けることができる仕組み」をつくるために、具体的に何をして、どのように改善できたのか。そしてチームで設計を改善していくなかで、どのような設計図に進化させることができたのかについて、私の経験をもとにお話しします。

本日、私が皆さんにお伝えしたいことは、大きく2つあります。

1つ目は、先ほどお話しした通り、ソフトウェアアーキテクチャの目的を「良い設計図を継続的にチームで進化させ続けることができる仕組み」とすることの重要性です。2つ目は、その実現のための具体的なアプローチとして、モブプログラミング（モブプロ）、BDD（振る舞い駆動開発）、そしてイベントストーミングという3つの手法を組み合わせることが非常に効果的だということです。

もし今日のセッションを聞いて「良いな」と思っていただけたら、ぜひ実践していただきたいと思います。

モブプロ×BDD×イベントストーミングの組み合わせが良い理由

私が所属していたチームには、もともと次のような課題がありました。

• 実装されているファイルごとに設計の仕方や実装の仕方がバラバラで、可読性が低い
• メンバー間でスキルや知識に格差があり、人によって設計方針が異なる
• 属人性が高く、なぜそのような実装になっているのかを作成者以外が理解できない
• メンバーの入れ替わりが激しい時期があり、作りっぱなしでメンテナンスされていないソースコードや機能について、チーム内で詳しい人がいない

その結果、問題が発生した際に、修正コストが非常に高くなることや、そもそもなぜそのような設計・実装になっているのかという意図がわからず、適切な修正方法の判断が難しいといった問題が蔓延していました。

こういった課題を改善するために採用したのが、モブプロ、BDD、そしてイベントストーミングという3つの手法の組み合わせです。まず、これらの3つの手法について簡単に説明させていただきます。

まず、モブプロ。これは文字どおり「みんなでプログラミングをする」手法で、タイピストやナビゲーターといった役割を設け、全員でディスカッションしながら進めます。一方、進行の難しさや事前準備の必要性という課題があります。

BDD（振る舞い駆動開発）は、振る舞いを自然言語で定義し、それを実現するためのテストを最初に書いてから実装を行う手法です。Given/When/Thenという形式で「どういう前提で、何をしたら、どうなるべきか」を明確にしていくのですが、この振る舞いの明確化が難しく、考慮漏れが発生すると対応が複雑になるのが課題です。

イベントストーミングは、主にDDD（ドメイン駆動開発）で用いられる手法で、ビジネス要件を整理するために開発メンバーとドメインエキスパートが共同でフローを可視化します。この手法では、ディスカッションを通じて要件を整理しますが、その過程や内容を実装に落とし込むことは簡単ではありません。

私は、モブプロ、BDD、イベントストーミングを組み合わせることに大きな意義があると考えています。それぞれの手法には課題がありますが、組み合わせることで相乗効果を得られるからです。

「モブプロ × BDD」の場合、BDDで振る舞いやテスト観点を事前に洗い出すことで、モブプロの進行がスムーズになります。テスト→実装→リファクタリングという明確なサイクルができ、次に何をすべきか迷う時間が減少しました。

「イベントストーミング × BDD」の場合、イベントストーミングにQAやビジネスサイドを巻き込むことで、品質視点や要件を整理しやすくなり、BDDでの振る舞い定義も容易になりました。これにより、考慮漏れを防げます。

「モブプロ × イベントストーミング」では、イベントストーミング後にモブプロで実装を進めることで、ドメイン知識が共有され、チーム全体の理解が深まりました。

私の場合、3つの手法を組み合わせることで、それぞれの課題を解決できただけでなく、追加の効果も得られました。

まず、プロセスが型化されたことで属人性が減少し、チームの自立性が大きく向上しました。さらに、ドメイン、タスク、内部・外部品質など、やるべきことが分割されました。分割すると関心ごとが限定され、取り組みやすくなったのです。加えて、チーム内外の対話が増え、設計やモデリングの質が向上しました。

このように、「良い設計図を継続的にチームで進化させ続けることができる仕組み」を、3つの組み合わせで確立できたと考えています。

事例：ビットキーでの具体的な取り組みと成果

ここからは、社内での取り組みの事例とともに、具体的にどのような効果があったのか、なぜこの方法が効果的なのかについて説明します。

まずは、外部品質の観点で客観的な成果。品質保証チームによる評価期間中の「評価戻り」が減少し、特にクリティカルな問題は半分以上削減されました。また、仕様に関する疑問が生じた際に確認できる基準が整備され、誰でも対応可能な状態を実現しました。

QAチームとの関係も改善し、不具合報告に加え、機能追加の提案が行われるようになりました。さらに、モブプロ導入による生産性低下を懸念していたのですが、開発のベロシティは維持され、大規模なリプレース案件も問題なくリリース・運用できました。

メンバーに対して実施した匿名アンケートでは、75%のメンバーが「働きやすくなった」と回答しており、チームの雰囲気やモチベーションが大きく向上しました。

総じて、他チームとの連携、チーム内の雰囲気、外部品質、アウトプット量においてポジティブな成果を得ることができました。

次に、「チームで継続的に設計図を進化させる仕組み」について、具体的にどのように進化したのかを、内部品質の観点から説明します。

まず、弊社ビットキーの事業内容について簡単にご説明します。「つなげよう。人は、もっと自由になれる。」というビジョンのもと、「体験の分断」を解消するためのサービスを提供しています。住宅を軸としたhomehub、オフィス向けのworkhubの2つの領域にてリアルとデジタルをつなぐソリューションを展開しています。

私たちは限られたリソースの中で、汎用的な機能を組み合わせることで多くのソリューションを提供してきました。例えば、スマートロックの機能としては、解錠、オートロック設定、解錠ログの確認などが求められますが、利用シーンは多岐にわたります。個人での利用から、家族や友人との共同利用、さらには管理会社や清掃会社による業務利用まで、用途は広範囲に及びます。

また、解錠方式もアプリケーション、顔認証、QRコード、ICカード、パスコードなど多岐にわたり、設置場所も一般的な扉からオートロック、エレベーター、ロッカー、個室ブースまでさまざまです。これらの組み合わせごとに異なるルールと使用方法が存在し、システムの複雑化が課題となっていました。

この課題に対し、私たちは「誰が、いつ、どこで、何で解錠できるか」という観点で抽象化を行い、アクセスコントロールという新しいレイヤーを設計しました。このレイヤーでは、アクセス権限の付与や確認を統一的に処理することが可能です。

さらに、システム全体を「人」「空間」「デバイス」という三つの要素で抽象化しました。特にデバイスについては、機能に基づいて4つのカテゴリーに整理しました。物理的な解錠を行うLock Device、認証機能を提供するAuth Device、必要に応じてネットワーク接続を行うLink Device、そして物品保管機能を持つStorage Deviceです。

このアプローチにより、異なる利用シーンや認証方式、設置場所の違いを吸収し、統一的な方法でアクセス管理を行うことが可能となりました。しかし、ここに落とし穴があったんです。

当初作成した汎用的なデバイスモデルには、デバイスの設置や設定変更といったユースケースも含まれていました。各デバイスには固有の設定値や設置方法があるため、すべての機能を1つのモデルに集約したことで、システムの使いづらさが顕在化してしまいました。

この問題を解決するきっかけとなったのが、イベントストーミングによるドメインの見直しです。関連性の強い機能をまとめてマッピングする過程で、解錠と設置はまったく異なるコンテキストを持つことが明確になりました。当初はデバイスという単位で機能を共通化することを重視していましたが、これが逆に設計を複雑にしていたのです。

この気づきをもとに、システムを解錠コンテキストと設定コンテキストに分割することに。設定や設置については、各デバイスの特性に応じた固有のモデルを採用しました。一方、解錠機能については、共通のクエリモデル（リードモデル）を用意し、各デバイスのモデルから必要な情報を生成する方式に変更しました。この「分割」によって、それぞれのコンテキストに最適化された設計が可能になり、システムの使いやすさが大きく向上しました。

おわりに：ソフトウェアアーキテクチャで大切な3つのこと

この開発経験から、私は3つの重要な学びを得ました。1つ目は「分割の重要性」です。私は当初、共通化・汎用化を重視するあまり、分割をあまり好ましくないと考えていました。しかし、イベントストーミングを通じて適切な分割を行うことで、各部分の責務をより明確にできることを学びました。

2つ目は「モデルの目的を明確に」です。最初にデバイスモデルを設計した際、解錠機能に焦点を当てていたはずでしたが、その意図をチームと十分に共有できていませんでした。機能開発に必要な範囲の知識や情報のみを考慮して実装を進めており、システム全体を通した整理や各領域の意味づけについての対話が不足していました。

3つ目は「チームで対話を」です。デバイスの設置プロセスには、物理的な取り付けに加え、認証管理やデータベースなど複数のレイヤーが関係します。暗号化、鍵穴登録、ファームウェア更新など、多岐にわたる作業が必要で、特にダブルロックなど複数デバイスの連動時は設定が複雑になりました。

当初は単一の大きなデバイスモデルで管理しようとしましたが、これでは意図しない状態遷移や値の欠落などの問題が発生しました。しかし、ドメインエキスパートとの対話から生まれた言葉をもとにモデルを細分化することで、各モデルの責務や状態遷移の条件をより明確に定義できるようになりました。

この経験を通じて、対話から生まれる言葉を大切にし、インターフェースでできることとできないことを明確にすること、そして十分な対話の時間を確保することの重要性を学びました。これにより、設計・実装後のレビューよりも、開発プロセスの中でより深い議論ができるようになりました。

このように、ソフトウェアアーキテクチャの本質的な目的は、優れた設計図を作ることではありません。むしろ、チームが継続的に設計図を進化させ続けることができる仕組みを確立することにあります。もちろん個々のスキルや知識は重要ですが、それらに過度に依存せず、チーム全体で改善サイクルを回せる状態を作ることが望ましいと考えています。

そして、その仕組みを実現する手段として、モブプロ、BDD、イベントストーミングの組み合わせが有効であることを、この経験を通じて学びました。