この記事は、何？

この記事は以下動画の台本です。
補足に使ってくださいまし。

「アーキテクチャを会社組織に例えて完全に理解する」
https://youtu.be/rFaiphQUEbE

[Why care about software architecture?]
https://youtu.be/D_9Fzp2lHnc

全く同じ内容の英語版も用意したので
エンジニアの英語勉強にぜひご活用ください

以下、台本

Hello youtube,
Hello Japan,
Gutenacht in Deutschland

さて今日は
ソフトウェアアーキテクチャについて考えよう。

2年目ぐらいのエンジニアになると
コードのアーキテクチャを考える機会が増える。

とりあえず動くコードを考えるんじゃなくて
誰がみてもわかりやすいコードを考えるようになる。

そんなときに大事なのが
ソフトウェアのアーキテクチャだ。

君は先輩にこんな事を
言われたことはあるかな？

「それはインフラ層に書くべきじゃない」とか
「ビジネスロジックにミドルウェアの知識を持たせるな」とか
「責務を分担しろ」とか

でも、どうして責任分担すると
いいコードになるのか
よくわからない。

もし君がそう感じたのだとしたら、
この動画を君に捧げよう。
なぜアーキテクチャが重要なのか、
ソフトウェアを会社に例えて説明しよう。

君が自動車を作る会社の
社長だとしよう。
社員1万人ぐらいの
立派な会社だ。

最近の世の中の動きを見て
今年は車が売れると考えた君は
今までの２倍、
自動車を100万台作る事を決めた。

さて、社長である君は何をするか？
今までの２倍の車を作るんだから、
自ら製造ラインに飛び込んで、
ものすごい勢いで
車を作り始めるだろうか？

そんなことはしないよな。

まず、社長である君は
車の組み立て方を
細かくは知らないだろう。

イチから勉強してもいいが、
勉強してる間は
社長の仕事は止まっちまう。

だから君は、
車を作る作業の詳細は
現場の作業員に任せるだろう。

作業員は毎日、
車の作り方を勉強してるから
お願いすれば、すぐに作ってくれる。

でも逆に、作業員一人一人が
為替とか国際情勢を常にみて
どれだけ車が
売れるか考える必要はない。

作業員が考えるべきは
「車の作り方」
社長が考えるべきは
「どれだけ車を作るか」

こんな風に社長から
細かな知識を切り離して
仕事を分担するのが
普通の会社だよな。

自分の会社に関することを
全部知ろうとすると頭がパンクしちゃう。

ここが大事なポイント１だ。
社長は車の作り方を全部詳しく知らなくていい。
全部知ろうとすると、頭がパンクしちゃう。

ここを覚えておこう。

さて、車の作り方は
作業員が知ってる事がわかった。

じゃあ社長である君が
作業員全員に声をかけて

「明日から一人当たり
２倍の車を作ってよ」

とお願いして回るだろうか？

そんなことはしないよな。
普通は、まず事業部長に
お願いするだろう。

部長さん、
今年は去年の２倍、車を作ってください、
ってな。

さて部長もおそらく
車の作り方を細かくは知らないだろうが、
車を作るために
何をすればいいかは知っている。

例えば工場ラインを増設して、
作業員を増やして、
部品の発注を増やす必要がある。

だから部長はそれぞれの課長にお願いする。
製造課長さん、工場ラインを２倍にして。
人事課長さん、従業員を２倍にして。
購買課長さん、部品を２倍にして。

そしてそれぞれの課長が
自分のメンバーにお願いする。
工場ラインの拡張計画を作れ。
採用計画を考えろ。
調達先を増やせ。

こんな具合に
社長から部長から課長から平社員と
作業が細かくなって上から下に伝わっていく。

ここですごく大事なのは、
社長が直接指示を出すのは
部長だけってことだ。

社長がいきなり採用担当者に
「採用を２倍にしろ」
って命令したら
そりゃ社長命令だから
２倍の人を採用するだろうけど、
人事課長はびっくりするよな。

自分が指示したわけでもないのに
いきなり予定の２倍も採用されてたら
Oh my godって感じだ。

社長がいきなり工場に行って
「来年の車は全部オレンジにしろ」
って指示を出したら、
現場の人は従うかもしれないが、
出来上がった車を見て
デザイナーはびっくりするよな。

自分が指示したわけでもないのに
いきなり車の色が
変わっちゃうんだから。

こんな風に、
社長が組織の構造を飛び越えて
細かくいろんなところに
指示を飛ばすようになると
現場は大混乱する。

社長の指示だから全員が従うけど、
中間管理職トネガワは
たまったもんじゃない。

どこから指示が飛んできて、
自分の計画を邪魔するか
わからないんだからな。

ここがアーキテクチャの
大事なポイント２だ。
社長が現場に直接指示を飛ばしちゃいけない。
現場が混乱する。

さらに大事なポイント３。
上長が指示を出すときは、
ちょっと抽象的な指示を伝えるよな。

例えば部長が人事課長に指示を出すときに
「人を２倍採用しろ、
　でも求人の文言はこれを使え、
　このサイトに載せろ、今日の17時に載せろ」なんて
具体的な指示まで出すことはない。

事業部長が欲しいのは
人を２倍にする結果だけで、
その手段は課長に任せる。

求人の文言とか、載せるサイトは
人事部の中で考えることだ。

これが大事なポイント３。
上長が指示を出すときは、
何が欲しいかまで指示するけど、
その手段までは指示しない。

さて、大事なポイントをおさらいしよう。

ポイント１。
社長は車の作り方を知らなくていい。

ポイント２。
社長が現場に直接指示を飛ばすと現場が大混乱する。

ポイント３。
指示を出すときは、
その手段までは指定しない。

ソフトウェアアーキテクチャで
気をつけるべきポイントは
基本的にこの3つだ。

会社組織でやっちゃいけないことは
アーキテクチャでも
基本的にやっちゃいけない。

例えば君がフルーツの
ECサイトを作っているとしよう。

ユーザが購入ボタンを押したら、
フルーツ購入のリクエストが送られてくる。

ナイーブなエンジニアなら
こんなコードを書くかもしれない。

リクエストを受け取って
同じクラスで在庫確認して
同じクラスで決済をして
同じクラスで購入履歴を保存する。

こんなコードは
社長が直接現場に
指示しているのと同じだ。

DB課長とか決済課長は
自分の部下が、だれの指示で動いているのか
さっぱりわからないし
場合によっては、
自分が部下に出した指示と
社長が直接出した指示が
食い違うかもしれない。

社長が現場に口出ししちゃいけないように、
リクエストを受け取ったコードが
そのままDBに口出ししちゃいけない。

これは、やっちゃいけないアーキテクチャだ。
というかアーキテクチャと呼べない。

じゃあどうすればいいのか？

逆に今から、正しい組織の形を
ソフトウェアの世界に落とし込んでみよう。

ここからはオニオンアーキテクチャの用語を
いくつか借りて比較していく。
厳密には異なる部分もあるが、
大まかなイメージを掴むために聞いてくれ。

ECサイトを使っているユーザの
入力情報やリクエストを受け付ける部分は
ユーザインターフェースと呼ぶ。

これが社長だ。
社長が市場の変化を察知して
指示を飛ばし始めたのと同じように、
ユーザインターフェースは
ユーザの操作を察知して
指示を飛ばし始める。

社長の指示を受けるのは部長だ。
車の細かな作り方まで知らないけど、
車を作るために何が必要かは知っている。
この部長をアプリケーションと呼ぶ。

事業部長は次に課長に指示を出す。
ラインを増やせ、人を増やせ。
具体的な業務内容は指示しないが
大まかに何が欲しいか指示する。

指示を受けて業務内容を詳しく考える課長を
ドメインサービスと呼んでみよう。

さて課長も最近の技術の細かな変化までは
完璧に追えていないから
実際に車を設計したり
組み立てる作業は
平社員にお願いする。

一番具体的な業務の内容を知っているのは平社員だ。
彼らをドメインモデルと呼んでみよう。

さて、一回ここまでの仕事の流れを振り返ろうか。

社長が「指示を出し」
部長が「計画を作り」
課長が「業務を指示して」
平社員が「業務を遂行する」

こんな組織の構造が見えてきたよな？
ソフトウェアアーキテクチャも似た事をしている。

ユーザインターフェースが「指示を出し」
アプリケーションが「計画を作り」
ドメインサービスが「業務を指示して」
ドメインモデルが「業務を遂行する」

こんな風に役割分担をして、
ちょっとずつ指示を細かく
上から下に伝えていくことで
現場は混乱せず、
社長の指示を処理できるようになる。

こうしてみると、
そんなに分かりにくい話をしている訳じゃないよな？

社長が全ての業務を細かく知ってる訳じゃないし、
社長が直接現場に指示を出すと混乱する

これはみんなも身に覚えがあるだろ？

ドメインとかインターフェースとか
普段使わない英語が出てくるから
めちゃくちゃ分かりづらいだけで
日常的な言葉に置き換えたら
アーキテクチャの概念なんて
凄くイージーだ。

それぞれの部署が何を知っておくべきか、
部署の間でどうやってコミュニケーションするのか。

それを明確にして
分かりやすい組織を作るのが
ソフトウェアアーキテクチャだ。

さて、今日はここまで。
アーキテクチャを会社に例えて解説してみた。
アーキテクチャを考える意味とか
その効果について
感じてもらえたんじゃないだろうか。

アーキテクチャに興味を持ったら、
次は具体的に何か一つのモデルを選んで
勉強してみるといい。

今回使ったオニオンアーキテクチャの他にも
いろんなモデルがあるけど、
やりたいことは全部同じだ。

まとめ方とか、
呼び方がちょっと違うだけだ。

一気にいろんなのを覚えようとすると混乱するから
何か一つ選んで覚えるといいと思うぞ。bye bye