はじめに
こんにちは、アプリエンジニアの小林です。
前回紹介させていただいた、AWS re:Invent 2024でのWerner博士のKeynoteの「複雑さへのアプローチ」の部分について、考察をしていこうと思います。
私自身リーダーとして要件定義やアーキテクチャ設計まで携わっている中で参考になる部分が多い内容であったため、似たようなポジションの人の参考になればと思います。
複雑さがシステムに与える影響の実例
私は社会人歴9年目ということもあり、これまでにいくつかのシステム開発に携わってきました。 その中で似たような機能を持っているにも関わらず、アーキテクチャが全く異なるシステムを見たことがあります。 この2つのシステムを仮にAとBとします。
システムAの構成は以下です。
- 管理サイトとユーザサイトで同じデータベースを利用している
- APIを提供するバックエンドサーバが存在する
- ユーザに画面を提供するフロントサーバが管理サイト、ユーザサイトでそれぞれ存在する
システムBの構成は以下です。
- 管理サイトとユーザサイトでそれぞれ別のデータベースを利用している
- 管理サイトとユーザサイト間でデータを連携するための中間テーブルがある
- バックエンドとフロントエンドを分けず、管理サイトとユーザサイトでそれぞれのサーバが存在する
システムAは同じデータベースを利用しているため管理サイトとユーザサイトで取得できるデータはリアルタイムで同期されています。しかしシステムBではユーザサイトと管理サイトでそれぞれ別のデータベースを利用しているため、定期実行されるバッチで中間テーブルを介してデータを連携しています。そのため、データはリアルタイムで同期されていません。
システムAとBのどちらのほうがより複雑かは、容易に想像がつくかと思います。似た機能を持ったシステムであるにも関わらず、なぜこれほどアーキテクチャが違うのかというと、これにはコンウェイの法則が関係しています。コンウェイの法則とは、開発を行うチーム単位でシステムに疎結合な部分ができてしまう、という原則です。
つまり、システムAでは管理サイトとユーザサイトを同じチームで開発していますが、システムBでは管理サイトとユーザサイトを別のチームが開発しているのです。
ではエンジニアがこの「複雑さ」を解決するためにはどうすれば良いのでしょうか。下流工程を担当するエンジニアの場合、すでに意思決定がされてしまったこの「複雑さ」を解決するのはかなり難しいかもしれません。一方で、上流工程を担当するエンジニアの場合は、アーキテクチャ設計の段階でリスクを洗い出し、組織構成の変更について相談するなどの方法をとれる可能性があります。ただし、相談した結果、なんらかの事情があり組織変更ができないため「複雑さ」をシステムで管理すると決めたのであればそれを受け入れる必要があります。
このようにシステムの「複雑さ」をうまく管理するためには、組織的な課題と向き合わなければならないケースが存在しています。 Werner博士がKeynoteの中で話していた「Align organization to architecture (組織をアーキテクチャに合わせる)」に当たる部分だと思います。なお、近年ではアーキテクチャに合わせた組織を作ることを逆コンウェイの法則と呼ぶこともあるようです。
システムは誰が作っても同じなのか？
少し話は変わってしまうのですが、私は新卒の頃NRIネットコムとは別のいわゆるメガベンチャーで働いていました。その頃に先輩社員との座談会があり、そこでWebディレクターの先輩社員から「システムなんて誰が作っても同じ」と言われた記憶があります。
その当時はそんなことはないと思いつつ、機能要件と非機能要件を満たせていればそうとも言えるな、とも思ってしまい、うまく思いを言語化することができませんでした。今回Werner博士のKeynoteを聞いて当時のことを振り返り、要件を満たせていてもアーキテクチャレベルの「複雑さ」を作ってしまうケースもあるため、「複雑さ」を管理できるエンジニアが必要であり、誰が作っても同じとは言えないと改めて思いました。
エンジニアの当事者意識とはなにか？
またまた新卒の頃の話になるのですが、その会社には「課題解決」「圧倒的当事者意識」というスローガンがありました。当時は「課題解決」はそのとおりだなと思いつつ、事業やサービスの責任者でなければ「当事者意識」は芽生えないと思っていました。同じことを言っているエンジニアの方は社内にもたくさんいた記憶があります。
ではエンジニアにとっての「当事者意識」とはなんなのでしょうか。私は今回Werner博士のKeynoteを聞いて、「複雑さ」を管理しようとすることが当事者意識なのではないかと思いました。システムやそれに付随する業務、つまりはサービス全体を向上させるためには「複雑さ」を管理する必要があります。「複雑さ」をうまく管理することは非常に難しく、Werner博士のKeynoteで語られた手法だけでなくDDDなど様々な方法が著名な技術者によって発表されています。
「複雑さ」を管理しようとすると、必然的にいくつもの課題が発見されるはずです。その「課題解決」をしていくことがサービスの向上につながります。つまりサービスの責任者としてビジネス的な視点でサービスの向上を考える以外にも、エンジニアの視点からサービスの向上を行うことができます。それがエンジニアの「当事者意識」であり、価値を発揮する方法の一つではないかと感じました。
ちなみにNRIネットコムで入社時からお世話になっているPMの先輩社員がいるのですが、その解決方法を選んだ理由が明確でない仕事をすると「当事者意識がない」と怒られてしまいます。含蓄がありますね。
まとめ
Werner博士のKeynoteは抽象的な内容が多く含まれており、取り上げている内容も難しいため、私個人まだしっかりと内容を噛み砕けていないところもあります。そのためすべての内容について考察を書くことは難しいのですが、今回は「複雑さ」がシステムに与える影響と、「複雑さ」を管理しようとすることが世間でよく言われる「課題解決」「当事者意識」に繋がるのではないかという意見についてまとめさせていただきました。
Werner博士のKeynoteは非常に難解であるため、新卒の頃の自分であれば今の考えには至らなかったと思います。さらに経験を経てエンジニアとしてレベルアップするにつれ、Werner博士のKeynoteに対する解像度が上がっていくといいなと思いました。
