こちらのイベントに参加してきた(アーカイブを見た)ので、会の様子と感想を書いていこうと思います。
会の概要
以下、connpassのイベントページから引用です。
株式会社タイミーは「一人ひとりの時間を豊かに」をビジョンに掲げ、日々の開発を行っています。
そんな私たちが開発を通じて得ている学びを発信することで新しい取り組みを後押ししたり、アンチパターンに陥らない様に出来るのであればそれもまたエンジニア一人ひとりの時間を豊かに出来ているのではないかと考え、定期的に勉強会を通じて我々の学びを発信していく予定です。 第2回目はCTO亀田の愛読書でもあり、現在タイミーが向き合っているアーキテクチャについて学びの深い書籍である『ソフトウェアアーキテクチャの基礎』を題材にしたイベントを開催します。
今回は豪華ゲストとして『ソフトウェアアーキテクチャの基礎』の翻訳者 島田 浩二 氏をお迎えして、基調講演いただきます。 事例講演として弊社CTO亀田（@kameike）が今タイミーが向き合っている課題や成し遂げたいアーキテクチャ、何を考え、今に至って、これからどうしていくのかをお話します。 Q&Aセッションも設けますのでアーキテクチャに向き合ってきた講演者2名にぶつけたい質問もお待ちしております！
会の様子
ソフトウェアアーキテクチャの基礎〜島田 浩二さん〜
アーキテクチャとは？
アーキテクチャは構造を決定するものであるが、それはあくまでもアーキテクチャの部分でしかなく、構造として現れなかったもの*1もアーキテクチャであるというお話がありました。
また、構造として現れなかったものや構造として現れるものを実現させるソフトウェアアーキテクトの目的として、「内外からシステムに対して作用する力に対してシステムが崩壊しないようにする」ことがアーキテクチャの目的*2で、その目的を満たすために備わっている性質がアーキテクチャ特性だという整理がありました。
アーキテクティングのステップ
時間の都合上でだいぶ端折ってはいますが、アーキテクティングのステップについて説明がありました。
ステップ1 〜要件やドメインの関心ごとから優先すべきアーキテクチャ特性とその程度を定める〜
アーキテクチャ特性を全てサポートすることは難しい上、別のアーキテクチャ特性同士が干渉する性質もあるため、全部を考慮することは難しく、品質特性ウェブやトレードオフスライダーといったアクティビティを用いてフォーカス対象を絞ることが重要だというお話がありました。
ステップ2〜さまざまな影響を考慮してアーキテクチャ上の決定を行なっていく〜
ステップ1でフォーカスすることを決定したアーキテクチャ特性について、以下のような影響を考慮してアーキテクチャ上の決定を行っていくというお話がありました。
- 開発チームの能力・スキル・知識
- ソフトウェア開発エコシステムの変化
- 組織(コンウェイの法則)
- データ
ただし、言葉にすると整理されているように見えるものの、実際のソフトウェア開発の世界ではトレードオフがあって難しくて銀の弾丸はないため、以下のような点を意識しながらアーキテクティングを行っていくのが重要だということです。
組織スケールを目指す道しるべとしての、『ソフトウェアアーキテクチャの基礎』〜亀田 彗さん〜
最初にTimeeさんのサービスやアーキテクチャ構造や組織構造について説明があった後Timeeさんが重要にしているアーキテクチャ特性、アーキテクチャ決定とその背景、設計指針について話がありました。
アーキテクチャ特性
変更用意性や運用特性を重視している。
運用特性は常に重要だが、運用特性のどの部分が特に重要なのかがプロセスごとに変化していくため、フェーズごとに運用特性のどの部分が重要になるのか？を考えているそうです。
アーキテクチャ決定とその背景
モジュラモノリス/マルチモジュールを目指していこうと考えている。
これは、チームの独立性を保つこととアーキテクチャごとのコンポーネントを多様化することを目的にアーキテクチャ決定されたということでした。
ただし、ビジネス要件(出退勤を切り出して発展させていくことや別アプリをリリースしてそこからサービスを使えるようにする...)を一部切り捨てることが前提となっているということで、トレードオフ関係が生まれているというお話でした。
なお、モジュラモノリス/マルチモジュールを推進する上では、漸進的な成長が目指しやすいことや、shopifyという実例があることが追い風になって、実行確実性が高まっているということです。
設計指針
フロントエンドをSoE、バックエンドをSoRに変化させていくことで、フロントエンドとバックエンドの責務を明確にすることと、「境界」を機械可読にしていくにしていくことを重視しているとお話がありました。
パネルトーク
以下、パネルトークで挙げられていた話を簡単に書いていきます。
サービスベースアーキテクチャとモジュラーモノリスの違い
サービスベースアーキテクチャは、サービス間通信をしながらサービス単位で動くようなアーキテクチャである。
モジュラーモノリスは、一つのプロセスの中でモジュール単位でシステムを分割し、同期通信などを活用しながらシステムを動かす。
モジュラーモノリスを採用したことで失ったもの(発生したトレードオフ)
システムを小さい機能だけ別サービスに切り出すことは難しくなっている。
アーキテクチャスタイルの切り替えを技術戦略に組み込んだことは？
Timeeの場合、元々戦略性がなかったということのは正直ある。
実際問題、PMFした後に強く求められるアーキテクチャ特性に対して適応する形で、アーキテクチャスタイルを決定していくことが多い。
アーキテクチャスタイルやリアーキテクチャを実施するにあたっておすすめの本
がおすすめ。*3
アーキテクチャ特性はシステム全体としてみるのか？パッケージ単位といったモジュール単位でみるのか？
パッケージ単位で切り分けないと、ボトルネックとなっているアーキテクチャ特性に他のパッケージが引っ張られてしまうということが起きてしまうため、Timeeではパッケージ単位でみるようにした。
ADR運用のコツ(亀田さん→島田さん)
Proposalの段階からルールを守るための仕組みが作られるといいが、チームを巻き込んでいくという工夫では、正直泥臭くやっていくしかないと思う。
モジュラーモノリスにすると何回か分け方を間違えることがある。この時もとに戻すためにどういう工夫をしているか？(島田さん→亀田さん)
まだ移行していくぞ！という段階なこともあって、今は戻そうと感じたエピソードはTimeeではない。
逆に、不必要にマイクロサービスに分けてしまって、そこから戻すのが大変だったというエピソードはある。
アーキテクトに向いている人は？
(亀田さん) Timeeでは、興味を持っている人がいればいいと思っている。長くシステムにコミットする気持ちがあることが重要だと思っている。
(島田さん) 人やシステムで何か異変が起きていることに気づける人がアーキテクトに向いていると思う。ただ、アーキテクトは一人でなくてもいい。人にフォーカスする人やシステムにフォーカスする人が複数人集まってアーキテクトというロールを担っていくのでもいいと思う。
また、技術者としてエッジを効かせるには深みを目指さないといけないがアーキテクトとしては幅を目指さなくていけないところが、アーキテクトの難しさだと思う。
ただ、いきなり幅を目指すのは筋が悪いかもしれないと思っていて、まずは深みを作ることを目指してみて、深みに到達できれば他に幅を広げるというのがいいのではないかと思っている。
会全体を通した感想
Timeeさんがソフトウェアアーキテクチャの基礎をどのように実践されているかをわかりやすく説明してくれる講演でした。
正解がない世界でアーキテクティングについて考える難しさややり甲斐を感じると共に、アーキテクティングの楽しさやアーキテクティングのコツを実感することができてよかったです。
また、パネルトークでは、島田さんの染みるお話を聞くことができて、初めて島田さんの話を聞いたスクフェス札幌を思い出し、勝手に感慨に浸っていました笑
