エムスリーエンジニアリンググループ製薬企業向けプラットフォームチームの三浦 (@yuba)です。エンジニアリンググループ内では技術書の輪読会が有志によりいくつか立ち上がっています*1。そうした勉強会の一つで発表した内容が社内で少々バズったので、これは社内だけじゃもったいないとご紹介させていただきます。
本は、「ソフトウェアアーキテクチャの基礎（オライリー・ジャパン、Mark Richards/Neal Ford著 島田浩二訳）」。その第2章です。
- 謝辞をまず
- この章は
- 知識の”幅”と”深さ”だ
- 幅広さ→候補とメリデメ→ビジネス動機に即した判断
- 深さ→最新アップデートに追いつき続けること→偏らない判断
- まとめ
- 参加者の感想など
- We are hiring!
謝辞をまず
この本の輪読会を立ち上げてくれた北川さん（テックブログ記事一覧）は新卒2年目に入ったところです。良さげな本をキャッチするアンテナ、これやろうと呼びかける行動力、それでちゃんと人が集まってくる人望、そしてちゃんと会を動かす運営力のどれをとっても尊敬と感謝しかありません*2。
この章は
第2章は、この本の総論的な章です。第1章も総論でしたが、それをすごく具体的にわかるようにしてくれる章です。
実は第1章だけ読むと、「なんか良いことは書いてあると思うんだけど抽象的なことの羅列で明日自分の仕事にどう役立つのかわからない⋯」的な感想になってしまいそうなところがあります（私はそうでした）。しかし第2章でこれが一気に話がつながり具体化します。この見事さにはちょっと脳汁が出ます。控えめに言って神回！
もしこの本を読み始めて第1章で「not for meかも⋯」と挫折しておられる方いらしたら第2章もちょっと読んでみてください。いや、もちろん上記の発表資料を先に読んでくださってからでもいいですよ！
「アーキテクチャと設計はどう違うの？」という問いに、アーキテクトと開発者の仕事の違いを述べることで、そのためにアーキテクトと開発者のものの考え方の違いを述べることで答えていきます。 開発者なら期待を抱かざるを得ない内容ですね。では読んでいきましょう。
知識の”幅”と”深さ”だ
開発者なら自分の扱う技術とか言語、ツールには詳しいですし、詳しくあり続けるために最新のアップデートをキャッチし続けているものです（ですよね？）。これが、知識の「深さ」。
それとは違う方向、自分の詳しくない技術やツールについてもどんなものが存在しているかは使い所とか強み弱み程度まで幅広く知っておくこと、そういうのが知識の「幅広さ」、そのように定義されています。
開発者であるためには深さがあればいい、アーキテクトは幅広さが最重要でそれに加えて自分なりの専門性、深さも持っていなければならないと説きます。 それは当たり前のようではありますが当たり前だで終わらず、それってどうしてだっけ？ をちゃんと掘っていくところこそ、この第2章が「具体的」であると私が言うわけです。続けましょう。まずは大事な方、幅の方からです。
幅広さ→候補とメリデメ→ビジネス動機に即した判断
幅広さのことを説明するにあたって、実はすごく重要なポイントが、第1章で説明されていました。それも特に関連付けられずに。何かというと、
- どんなアーキテクチャにもトレードオフが、つまりメリットとデメリットの両方がある。デメリットが無いように見えるなら気づいていないだけだ
- アーキテクトはビジネスドメイン知識を持っていろ、あと関係者の政治を理解していろ
- あるアーキテクチャを説明する4つの軸のひとつに「アーキテクチャ特性」というのがある。非機能要件という呼ばれ方をすることもあるが、「なんとかビリティ（Availability, Reliability, Testabilityなどなど）」のどれが高くてどれが低いかという特性のこと
なにかシステムを設計するにあたって、方式選定なり技術選定なりする場面はたくさん出てくるわけです。
そのとき開発者だったら、選択肢のメリットは大抵言えるわけです。深く知っていますから。本で紹介されている例だと、pub/sub方式によるイベント分配には「疎結合にできるし、それゆえ利用側サブシステムの追加も容易で拡張性が高いですからね！ pub/subトピックを作ってやってきましょう！」と言えると。
アーキテクトはそれだけでなく、選択肢を他にも複数挙げて、しかもそれらのメリット・デメリットを挙げられないといけない。そしてそれができるために知識の幅広さが必要になってきます。ということは幅広さというのは相当大変ですね。単に紹介記事を読んだことがあるとかいうレベルではなく実際それでコーディングしたことがある程度の深さも要求されていると言えます。へたな開発者の「深さ」並みの深さを幅広く持つようなレベル⋯
そして、たくさん候補出してどれにもメリット・デメリットがあってどれを選択したら良いんだ！？ ここで、アーキテクトはビジネスドメイン知識・政治理解からシステムが実現したいビジネスの動機を理解し、それをシステム開発の言葉、「なんとかビリティ」、つまりアーキテクチャ特性の優先順位に翻訳できるだろ、というわけです。それによってメリデメの優先順位を付けて選択肢から選定ができる。
そういう考え方でシステムの形を決めるのがアーキテクトの仕事であり、そうして決められる形がアーキテクチャである、そういうことです。
余談になるのですが、私は実は医師免許を持っており、持っているだけってレベルなんですがそれでも初期研修までやっています。
そこで習ったことで、「名医とは、鑑別疾患をたくさん挙げられる医師だ」という教えがありました。患者さんを診た瞬間に「これは膵炎だ！」とか見抜くブラックジャックみたいなのも漫画的にはかっこいいのですが、現症を診たときに候補の病名をいかに大量に挙げて、それらをいかに制約の中で効率よく絞り込んでいくか、制約ってのは時間も医療資源も、あと患者さんの身体的負担もですね、それができるのが医師の能力だっていうんです。
非常に共通点のある教訓だなと思い出しました。
深さ→最新アップデートに追いつき続けること→偏らない判断
実は本の本文中では、アーキテクトが自分なりの専門性を持つべき理由についてははっきりと書かれていません。
ただ、読み手なりに解釈しますと、こうです。
深さというのは単に詳しいだけでなく、アップデートし続けることを含んでいます。このアップデートを怠るとヤバいことになるという話です。
「氷漬け原人アンチパターン」と名付けられて紹介されているのですが、アップデートが停滞することで古い知識や偏った経験知によってチームをミスリードしてしまうおそれがある、だから自分が詳しいと思っている分野にもアップデートを怠ってはいけないと。
ではそのアップデートを続けるにはというと、結局アーキテクトもコーディングの仕事を続けないといけません。クソ忙しいアーキテクトがどうやって？
それをなんとか両立するヒントがいくつか紹介されていますが、こんなのですね。
- クリティカルパスを握ったり、イテレーションのお尻が決まっていないような仕事をやる。忙しくて遅延しても開発全体に迷惑をかけないあたり
- バグ修正、コードレビューなど、開発現場の問題を把握するのも兼ねたタスク
私が今いる開発チームでも、リードエンジニアは直接の商用機能開発から一歩引いてこういう裏方の支援開発をやっていることが多く、ということはこれらもきっと著者の経験から自然にこうならざるを得ないだろうとわかったことでしょうね。そう思いました。
まとめ
- 幅広さ→候補とメリデメ→ビジネス動機に即した判断
- 深さ→最新アップデートに追いつき続けること→偏らない判断
そういう考え方で判断を下せるのがアーキテクトで、そういう判断で作られるシステムの形がアーキテクチャです。
ウォーターフォール型開発モデルだと、アーキテクチャとは「大きな単位のコンポーネント分け」であってアーキテクトの成果物、それをインプットとして開発チームは「よりミクロなクラス構造設計など」をしていく、みたいなスケール感と開発段階における分け方みたいな認識をされているわけですし私も当初何となくそのように考えていました。
この本では、そういう一方通行が諸悪の根源だったよね、ぜんぜん違うよと数行でばっさり斬り捨てられています。私ももう捨てました。
参加者の感想など
もちろんいくつも感想が出ましたが、その中ではこんな議論がありました。
- もしかしてこの本では、アーキテクトと開発者は順繰りにやるもの、つまり職種ではなくプロジェクトごとのロールくらいに捉えている？
アーキテクチャリングもやりコーディングもやりといつもやっていたら体が持たない、ときには開発に専念、次のプロジェクトではまたアーキテクト、みたいに交代しながらやっていくものとするならこの無茶さもまあ受け入れられます。アーキテクトだけ続けていたら、開発チームのメンバーというよりは”先生”みたいですしね。
それに、こんな緻密な思考でチームをリードするアーキテクトがいたら、チームメンバーもおそらくメキメキとアーキテクト思考を身に着けて皆がアーキテクトとして活躍できるようにもなりそう。
このあたりは、本の最後、第24章にキャリアパスの話があるのでここで詳しく語られるものと思います。楽しみに読み進めていくことにします。
We are hiring!
勉強会にも自主的に時間を使えるわがエンジニアリンググループの文化、これはグループがエンジニアに求めているのが即戦力的な能力ではなく成長力であるところに由来していると私は思っています。
だって、私がここに入ったときだって39歳にもなっていたのに「成長力に期待しました」と採用されたくらいです。
「自慢できるほどのスキルはないからとても自分を売り込んだりなんて⋯」と尻込みすることはありません。スキルをもっと”深く”、”広く”していきたいっていう意志と行動力、それこそがあなたの最大の武器です！ 是非切り込んで来てください。
