Technology / Development Issues
コンウェイの法則 - 「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」
組織とアーキテクチャの関係について論ずる時、必ずと言って良いほど引用されるのが、このコンウェイの法則です。この法則は多くの組織とアーキテクチャについて当てはまり、Everforthもその例外ではありません。Everforthの歴史を紐解きながら、採用してきたアーキテクチャ戦略について紹介します。
1. 好きな時間に好きな場所で開発する
Everforthは働く場所も時間も自由な会社です。社員は北海道から沖縄まで点在し、海外を拠点とする人もいますし、日中に働く人もいれば深夜に働く人もいます。ですから必然的に集まる場所はオンラインが中心になり、ビデオ会議などのリアルタイムなコミュニケーションよりも、チャットを利用した非同期なコミュニケーションが中心となります。連絡や相談はChatwork、Slackなどで行ない、ソースコードなどはGitHubやBacklogで管理、またドキュメントなどもGoogle Workspaceで共有しています。
もちろんそれだけでは人と人のコミュニケーションは上手くいかず、意思疎通で齟齬が起きたり、非効率であったり、あるいは関係が希薄になりがちですから、Web会議での定例やオフィスでのミーティングなどを各プロジェクトで方針を決めて行っています。またオフィスやホテルに集まるイベントなども年に何度か開催しています。
Everforthでは設立以来このようなオンラインとオフラインを組み合わせた自由な働き方をして、それを前提とした開発プロセスを採用していましたから、2020年に社会の状況が一変した際にも皆の働き方が大きく変化することはありませんでした。
2. 自由の中にも規律を作って成果を出す
Everforthは作ることが好きなエンジニアたちが自由に働く会社ですが、好きなことだけやって好き勝手に作っていても上手くはいきません。会社として成り立たせるためにはエンジニアたちが連携して、ビジネス的な成果を出すことが求められます。そのためにはある程度の規律や基盤が必要となるのです。
そのためにEverforthが十数年前に設立した時点で採用した方針は、頭抜けた技術力を持つCTOが開発の中心として立ち、それを周りのメンバーがサポートするような開発体制を採ることでした。このEngineのアーキテクチャは当時の組織にとてもよくマッチし、CTOがEngineの開発を担うことで中核となる機能の品質・性能を担保し、他の開発メンバーはEngineを信頼することで、ビジネスに特化したサービスの開発に注力することができました。規律を重視した体制だと言えます。
一方で、この十数年の間にEverforthのビジネスは変化し続け、Everforthの組織や働き方に共感して一緒に働く仲間も増え、様々な個性を持つエンジニアが増えました。そのような変化の中で、中央集権的な開発体制よりも、新しく増えたメンバー達が自律的に動きながら協調するような開発体制に変わっていく必要があったのです。ちょうど、モノリシックなアーキテクチャからマイクロサービスなアーキテクチャへの移り変わりのような移行が求められたとも言えます。
この自由と規律のバランスこそがEverforthをEverforthたらしめる中核です。
3. 組織の技術力を高める
「あの会社は技術力が高い（低い）」という評判は、何によるものでしょうか？
組織の技術力は、基本的にはそれぞれの案件にアサインされた個人の技術力によるものです。たとえ組織に優秀で尖ったエンジニアが所属していたとしても、他のエンジニアがその能力をコピーできるわけではないため、組織としての技術力などあってないようなものと考えられがちです。
しかしながら、その組織の中で「当たり前」となっている技術は属するエンジニア全体に影響します。テストやCI/CDは自動化して当たり前、監視環境は整っていて当たり前、クラウドネイティブになっていて当たり前など例を挙げればきりがありませんが、いずれにせよ組織の中で当たり前となっていることで各エンジニアが早期に習得・利用できる環境が整っていることになりますし、何よりマインドに強く影響します。逆に「テストは手動で当たり前」となっている組織では、なかなかテストが自動化されない様を見たことがあるのではないでしょうか。この「当たり前」のレベルを上げることが組織の技術力を底上げすることとなります。
では当たり前のレベルを上げるために何ができるでしょうか。ひとつは標準的な技術をある程度定めることです。皆がバラバラの技術を使っていれば当たり前も何もないのですが、標準的なプラットフォームやライブラリをある程度選定することで、「この技術をこのレベルで使おう」という当たり前のラインを引き、それを段階的に引き上げていくことができます。
Everforthでは自由と規律のバランスを重要視しているため、ゆるい標準化を行うようにしています。
4. 抽象化能力を重視し、向上させる
組織の視点だけでなく、もう少し個人にフォーカスを当ててみましょう。Everforthが各エンジニアに求める共通的な要素として、抽象化能力があります。この抽象化能力はマネジメントにおいてもアーキテクチャ検討においても役立つものです。もう少し言えばマネージャとアーキテクトの違いは、抽象化的に捉えて手を打つ対象が「チーム」なのか「技術」なのかの違いであって、本質的に必要な能力にはあまり差がないと考えています。
システム開発の文脈において「言われたものを言われたとおりに作るだけではいけない」とは言い古された言葉ですが、それはEverforthでも変わりありません。顧客のリクエストを表面的に捉えるのではなく、その背景やニーズ、また関係する他者の視点も踏まえ、真の要求を引き出すことが重要です。そのためにはリクエストを文字通りに受け取るのではなく、抽象化して捉える必要があります。
抽象化というと、別のものに置き換えて考える（メタファー）や、複数のものから共通点を抜き出して捉える（帰納）などの手法がよく知られていますが、その手法をなぞるだけでは不十分です。抽象化する際に「どの視点」で整理するかを忘れてはいけません。たとえば「犬」「猫」「豚」「牛」「鶏」などをまとめる時に、ただただ「動物」とまとめるだけでなく「ペット屋さん」の視点なのか、「肉屋さん」の視点なのかでまとめ方は異なります。目的や視点を正しく捉えて抽象化できるエンジニアこそ、Everforthが求めるエンジニアの姿です。
抽象化能力は個人の資質や性格に依るところが大きいことは確かですが、日常的なトレーニングにより鍛えることができます。その具体的な例のひとつが、日常的なモデリングです。重要なリクエストを受けた際やアプリケーションの設計を行う際に、ただただテキストで書き出すだけでなく、構造や関連を図として描くことを習慣づけることで抽象化能力を高めることができます。このモデリングの習慣をEverforthのエンジニアには身につけてもらいます。
Everforthでは「抽象化能力が高くて当たり前」と言えるよう、日々研鑽してもらいます。