メリークリスマス

初めましての人は初めまして、11代目のwatnow代表のしゅんやです。
本日はwatnowアドベントカレンダーの25日目を担当させていただきます。

メリークリスマス

ってよくいうと思うのですが、冷静にこれどういう意味かわからないですよね。
そこで調べてみたところ、どうやらメリークリスマス（Merry Christmas）のMerryには「陽気な、楽しい」という意味が込められているらしく、「楽しいクリスマスを」という意味らしいです。

いいですね〜

まあそんな話は置いといて、ここから本題に入ります

はじめに

自分は今までエンジニアとして進んでいたのですが、今年度学生団体の代表を務めることになり、組織戦略について考えるようになりました。

そこで今回はコンウェイの法則と自分の感じた点について書いていきたいと思います。

なぜ似ていると感じたのか

事の発端はインターン先でアーキテクチャを勉強している際にドメイン層ではUI側がどのような実装になっているかを知る必要がない疎結合な設計がいいんだよ（単一責任の原則)。という風に教えられたことがきっかけでした。
たまたま少し前にwatnowで組織構造が原因で少しうまくいかなかった時期がありました。

簡単に話すと、役職はあるがそこまで主体的に動いていない状態（自分の役職で何を求められているのかが曖昧な状態）で運営しており、毎週MTGはしていたのですが、意思疎通がうまくいかず、自分（代表）からはやらないといけないことが沢山あるのに運営メンバー（以下メンバー）が何をしたらいいかわからないという状況が生まれていました。

自分からしても、誰になんのタスクをどの程度任せればいいかを完全に把握できておらず、全てのタスクに自分が突っ込んで中途半端な状態でメンバーに渡してしまっていたため、メンバーが何をすればいいかがわからなくてうまくいかないという状況が続いていました。

ただでさえみんな普段から忙しいのに中途半端な状態での週1回のMTGでは完全なタスクの整理と方針の決定ができなかったため、メンバーそれぞれの役割に対して「やって欲しいこと」「理想の姿」を言語化して伝えるようにしました。

例えば外部交渉という役割があります。役職の内容としては他団体、企業様との連携を行う役職になります。
今までは、自分が他団体、企業様とご縁があることが多く、連絡をするようにしていたのですが、どこからが外部交渉の仕事でどこからが代表としての仕事かが曖昧でした。

そこで、外部交渉と1on1で話す時間を設け、「外部交渉としてやってほしいこと」「現状の不満」を2人で言語化していきそれぞれが責任を持つことを決めました。

その結果お互いやること、やらないことが具体的になり、お互いが主体的に動ける環境にすることができました。
また、他の役職についても1on1をしたことにより、MTGでその週に決める必要があることを誰に相談すればいいのかが具体的になったため、会議がスムーズに進むようになりました。

ここでアーキテクチャの話に戻ります。
例えば、個人開発のあるあるだと思うのですが、UIを記述するファイルの中にビジネスロジックを全て実装してしまうことってありませんか？
例えばこんな実装です。


<button id="myButton">Click me</button>

document.getElementById("myButton").onpressed = function() {
    // データの取得と処理
    fetchData().then(data => {
        processData(data);
    });

    // UIの更新
    // エラーハンドリング
    // などなど...

自分は今でも経験することでその度にリファクタリングしないとなと感じるのですが、これも1メソッドに処理が集中しているせいで可読性の低下やバグの追跡が難しくなっています。

この問題を解決するためにビジネスロジックやデータの状態管理などは別ファイルで管理するようにするためにアーキテクチャがあると思います。

そこで「firebase関連はまとめた方がいいよね！」という考えでなんとなくアーキテクチャを導入して以下のように構成しました。

root/
　├ data/
　├ domain/
　│　└ firebase
　└ presentation/
└ firstPage/
　│　　　└ secondPage/

初めは役割を分けれているのでいいじゃんと思っていても、ログイン機能やFireStoreとの接続やログイン状態の管理などを実装しようとすると、結局domainのfirebaseファイルに全て記載してしまったり、UIを完全に分けるためにアーキテクチャを入れたのにpresentationに入力フォームの処理とか書いてしまうなんてことが起こってしまいます。
これもdomain層での役割を細分化し、「domain層では何を記述するべきなのか」＝「domain層の責任はどこまで持つのか」ということにつながっていきます。

先ほどの運営での例とこのアーキテクチャ問題にていませんか？

もっと話を広げると、実務の場ではエンジニアは人事の仕事や経営方針を知らなくても会社自体は前に進んでいるしメンバーも入っている。マーケティング部がどんな施策を練っていて、どんな課題を抱えているかを知っていなくてもプロジェクト自体が進んでいるということがあると思います。これは、エンジニアはエンジニアで人事は人事でそれぞれ役割が明確になっていて、それぞれが持つべき責任を理解しているから目の前にあるタスクをやればマーケティング部がうまくやっていればエンジニアからは特別人事施策やマーケティング施策を見る必要がない組織構造になっているからだと考えました。

この考えを持っていた時、ちょうどインターンに行っていたので「組織とアーキテクチャの考え方って似てますよね？」と聞いたところ、「コンウェイの法則」を教えていただき辿り着きました。

コンウェイの法則とは

1967年にメルビン・コンウェイさんが提唱した理論で、
「組織が設計するシステムは、その組織のコミュニケーション構造を反映する」
と述べられています。

例えば弊団体の運営の例で言うと、代表と外部交渉などで責務を分離し、それぞれの結果をMTGやslackなどのコミュニケーションで相談するといった一種のマイクロサービスアーキテクチャのような構造にすることで運営がうまく進めるということです。

ただ、これをうまく実現するためには1人の責任を重くし過ぎることでプレッシャーを感じさせたり、キャパオーバーさせないための工夫が必要です。これはアーキテクチャでも同様です。

大切なのは現状をさらに良くするためにはどうするべきなのかを常に考え、検討し続けることです。

結論

アーキテクチャに正解がないのと同じで組織にも正解がないと思います。各企業のミッションやValueに基づいた設計になっている結果各組織の雰囲気の違いや、特色が生まれているからこそ自分に合った環境を探すのが大切です。
もしかしたらアーキテクチャ戦略に悩んだら組織構造の知識を入れてみるのもいいのかもしれませんね。

ここまで読んでいただきありがとうございました！
watnowアドベントカレンダーでは様々な分野での記事が書かれているので興味を持っていただいた方はぜひご覧ください！