こんにちは。ストラテジー&コンルティング部のクドウです。
前回、アジャイル開発について紹介しましたが、今回は視点を変えてデリバリーを行ううえで開発体制がシステム設計に影響を及ぼすといったお話を紹介したいと思います。
突然ですが、コンウェイの法則といったワードはご存じでしょうか？
コンウェイの法則
- コンウェイの法則
-
- システムを設計する組織は、その構造をそっくりまねた構造の設計を生みだしてしまう
- つまり、組織構造は要求されるソフトウェアアーキテクチャと一致しなければならなく、さもないと意図しないリスクを生み出す可能性がある
上記のコンウェイの法則を教訓として、マイクロサービスが注目されるようになってきた昨今、逆コンウェイ戦略を用いたアプローチも生まれています。
逆コンウェイ戦略
- 逆コンウェイ戦略
- 必須のアーキテクチャ設計に従うようにチームを求めるのではなく、システムに反映したいアーキテクチャに合うようなチーム構造にする
要は、ソフトウェアアーキテクチャを独立した概念と捉え、独立して設計可能で、どんなチームの集まりでも実装できるという発想は間違いだということです。
これは、恐らく皆さんも思い当たる節はあるかなと思います。デリバリー当初はアーキテクチャは疎結合なブループリントを描いても、体制において明確な境界線がない場合や、責任反映が曖昧な場合、最終的には開発納期などの影響で密結合なソフトウェアを作成してしまうということです。
DXを推進するうえでのデリバリー体制
前回アジャイル開発を紹介したと思いますが、一昔前のプロダクトを作って終わりではなく、継続的デリバリーが求められています。継続的なデリバリーは疎結合なアーキテクチャが重要で、疎結合により継続開発時の影響範囲も最小限に留め、かつクイックなリリースが可能になります。
その場合、効果的なデリバリー体制としては、人に対して価値を求めるのではなく、チームに対して価値を求めることが重要であると言われています。チームはアーキテクチャに求められる疎結合な単位（細かすぎてはいけない）で存在し、チームごとに明確な責任の境界線を定義し、必要最低限のコラボレーションを行います。それによりAPIという概念が必然的に生まれ、結果として当初掲げていた疎結合なアーキテクチャが継続的に持続可能になります。
次回以降は具体的なチームの概念についてご紹介したいと思います。
