チームで開発し事業を加速するための"良い"設計の考え方 @ サポーターズCoLab 2025-07-08

Transcript

1. Copyright © Henry, Inc. All rights reserved. チームで開発し事業を加速するための "良い"設計の考え方 @agatan_ サポーターズ Colab 勉強会 2025-07-08
2. Copyright © Henry, Inc. All rights reserved. 2 今日伝えたいこと
3. Copyright © Henry, Inc. All rights reserved. • 大前提: 万人にとっても正解となる設計なんてものは存在しない。 ◦ 結局は、自分たちの状況に合わせて考え、作り、改善し続けるしかない。 • だからこそ、考えるための指針 = 「考え方」を自分の中に持つことが重要。 • ここからは、僕個人の「考え方」を共有します。 • みなさんが持っている「考え方」を意識したり育てたりするきっかけになれ ばうれしいです。 ◦ 僕の考え方は別にベストでも網羅的でもないかもしれない。 ◦ 人の考え方との差分で自分の考え方が見えてきたりもする。 ◦ いろんな角度の考え方を組み合わせることがチームで開発するということ。 今日伝えたいこと
4. Copyright © Henry, Inc. All rights reserved. ぜひ、感想や質問、自分の考えなどなどをXに投稿してもらいたいです！ なるべく拾いながら進めたいと思っています！ ハッシュタグ: #spzcolab 感想・質問・意見をぜひリアルタイムで！
5. Copyright © Henry, Inc. All rights reserved. • 縣 直道 (@agatan_) ◦ 株式会社ヘンリーで、医事会計システムの開発チームのリーダーをしています。 ▪ 最近 「gRPCで分断されたモノリスを段階的にモジュラーモノリスに移行す る」 というブログを書きました！ ◦ 前職では toC サービスの新規事業立ち上げに従事していました。 • 株式会社ヘンリー ◦ クラウド型電子カルテ・医事会計システムを開発・提供している会社 ◦ https://henry.jp/ 󰳕 自己紹介
6. Copyright © Henry, Inc. All rights reserved. 6 設計ってなんだろう？
7. Copyright © Henry, Inc. All rights reserved. • 設計という言葉を含む単語の例 ◦ ドメイン駆動設計 ◦ API設計 ◦ データベース設計 ◦ 基本設計、詳細設計 • そのほか、関連が深い単語の例 ◦ クリーンアーキテクチャ ◦ マイクロサービス ◦ MVC • etc... 粒度も領域もまちまち... “設計”
8. Copyright © Henry, Inc. All rights reserved. • 設計とは、トレードオフの中でより良い状態を探索する活動である。 • その活動は、創造的で論理的で動的な性質を持つ。 • 実際には、こんなに単純な2軸ではなく、多次元のトレードオフがある。 この勉強会での "設計"
9. Copyright © Henry, Inc. All rights reserved. • 「大事にすべき要素はコレで、そのためならアレはこの程度までは犠牲にす ることを厭わない」、とロジックを持って決める必要がある。 • そのロジックの筋や通りが良ければ良いほど、"良い"設計である。 ◦ その要素は本当に捨てて良いものか？ ◦ その要素を捨てることで得られるものは本当に価値があるのか？ ◦ その要素を捨てれば本当に得たいものが得られるのか？ ◦ 捨てる量、得る量のバランスは適切か？ "良い"設計とは？
10. Copyright © Henry, Inc. All rights reserved. • 極端な例をあげると... ◦ 常に最新の流行り技術に乗っかりたい！ v.s. 実績のある枯れた技術しか使わな い！ ◦ 事前に設計書を完璧に書く！ v.s. 書いてみないとわからないから設計なんてせず に書く！ ◦ ガチガチに静的検証する！ v.s. 柔軟に書けることがすべて！ • どちらもある側面では正しく、ある側面では正しくない。 • 意見が割れるのは、大事にしている要素が違うから。 • 実際には中庸を取る。その判断こそが設計。 例えば...
11. Copyright © Henry, Inc. All rights reserved. • 「これを大事にします」という主張だけでは、設計判断としては不十分。 ◦ そりゃ全部大事にできたほうがいい • 犠牲にするものを明確にして初めて、設計判断がシャープになる。 • それが曖昧なら、設計も曖昧である可能性が高い。 ◦ （犠牲にするものが本当にないことも稀にあるし、それが理想ではある） 何を「犠牲」にしているかが大事
12. Copyright © Henry, Inc. All rights reserved. • 「DDD (ドメイン駆動設計) やってます」 • 「マイクロサービスやってます」 • 「クリーンアーキテクチャやってます」 これらの言葉は、（原義はどうあれ）解釈がゆらぎ、意味が希薄化しがち。 解釈が揺らぐと、「何を大事にし、何を犠牲にするか」という宣言が曖昧にな り、設計が本来もたらすはずだった効果が落ちてしまう。 （余談）「〇〇やってます」問題
13. Copyright © Henry, Inc. All rights reserved. • トレードオフの絶妙なパワーバランスは、いろんな理由で簡単に変わる。 • たとえば... ◦ 事業の方向性が変わって、指標Aはどうでも良くなった ◦ 新しい技術が出てきて、指標Aと指標Bは両立できるようになった ◦ 当初想定した通りに設計の効果が発揮されなかった / 違うものが見えてきた 設計は「育てる」もの
14. Copyright © Henry, Inc. All rights reserved. 14 どうやって設計判断をするか？
15. Copyright © Henry, Inc. All rights reserved. • 月なみだが、事業やサービスの特性を理解し、設計判断の材料を揃えること が重要。 • 加えて、現状の引力を正しく理解することも大事。 • これらは相互に影響し合っているので、その相互作用のメカニズムを理解す ることも大事。 判断材料を揃える
16. Copyright © Henry, Inc. All rights reserved. • 実際に開発をしているエンジニアが一番意識しやすい要素。 ◦ 既存のコードベース、実装済みの機能 ◦ 今の開発組織の文化やスキルセット ◦ すでに蓄積された技術的負債 ◦ etc... • これをないがしろすると、机上の空論になってしまう。 • どんなにカタログスペックが良い設計も、この引力に負けて失敗することは 非常に多い。 • また、現状と理想のギャップを埋めることで価値が出る。 現状の引力
17. Copyright © Henry, Inc. All rights reserved. • 作っているサービスの特性を知ることで、トレードオフの要素を適切に評価 できるようになる。 ◦ そのサービスはどう使われるものか？ ◦ どんな体験・価値を提供したいのか？ ◦ どんな変更・拡張が起きやすいのか？あるいは起きにくいのか？ • 特に非機能要件（パフォーマンス、信頼性、セキュリティ...）に注目するこ とで、採用すべき設計に強力な制約が生まれることがある。 ◦ 制約は設計を導いてくれるので、歓迎すべき。 サービス特性
18. Copyright © Henry, Inc. All rights reserved. • その事業はどういう性質を持っているか？ ◦ 外的要因によるちゃぶ台返しはあるか (法律改正など) ◦ 競合との戦い方、差別化要素 ◦ 将来のビジネス展開の方向性 ◦ どこまでスケールできる事業か • 実現までに時間のかかる大きな設計判断をする上で特に重要だが、考えきる ・読み切るのは難しいものでもある。 ◦ ここを加味した方針を示せると、より影響力のある設計判断を行えるようにな る。 事業特性
19. Copyright © Henry, Inc. All rights reserved. • 現状の引力 ◦ Kotlinで書かれた大規模なバックエンドサービスがすでにある ◦ 臨床と会計でそれぞれ独立したマイクロサービス構成を取っていた • サービス特性 ◦ 医療・会計なので、極めて高い信頼性が求められる ◦ 後発だからこそ、UXにこだわる必要がある ◦ 統合された体験を提供したいが、そのためにドメインの境界が曖昧になりやすい • 事業特性 ◦ 医療のもつ巨大なワークフローをカバーする必要がある ◦ クラウドサービスとして継続的に進化し続けることが期待される ヘンリーでの例
20. Copyright © Henry, Inc. All rights reserved. • 創業当初から存在していた2つのマイクロサービスを統合し、 モジュラーモノリスに移行することを決定し、現在も実践中。 ◦ まずモノレポ化を行い、物理的に触るコードの距離を縮めた。 ◦ その後、コードベースを徐々にパッケージとして切り出して、境界を模索した。 ◦ 段階的に2つのサービスをまたいだ処理を一方のサービスに集約した。 • 詳しくはヘンリーエンジニアブログを参照 ◦ “gRPCで分断されたモノリスを段階的にモジュラーモノリスに移行する” ◦ https://dev.henry.jp/entry/2025/06/13/145500 ヘンリーでの例: なぜモジュラーモノリスを志向したのか？ 1
21. Copyright © Henry, Inc. All rights reserved. • この設計判断を下した背景 ◦ ある機能を実現するのに、2つのサービスを同時に変更する必要があり、 分断モノリスになっていた（現状の引力） ◦ ドメイン境界が曖昧で、どのように分割すればいいかがわからなかった （サービス特性） ◦ 一方で、作るべきものの量は膨大で、機能の面も広いので、組織として スケールできる必要があった（事業特性） • 犠牲にしたもの ◦ デプロイの独立性（もともとあまり活きていなかった） ◦ 過渡期の様々な混乱（混乱以上に価値が出ると判断した） ヘンリーでの例: なぜモジュラーモノリスを志向したのか？ 2
22. Copyright © Henry, Inc. All rights reserved. • ここで描いたゴールは、まだ中間状態。 • これから事業が進捗するにつれて、さらに育てていく種である。 ◦ ドメイン境界が明らかになった暁には、「モジュールを分割してマイクロサービ ス化したほうがスケールする」、という判断をする可能性だってある。 ◦ 今の自分たちの状況の中で、最も価値が出せる設計を選んだ。 ◦ むしろ、不確実ななかでも行動したことで見えてきたものもある。 • 設計は動的であり、育てるもの ヘンリーでの例: なぜモジュラーモノリスを志向したのか？ 3
23. Copyright © Henry, Inc. All rights reserved. • 信頼性が求められる x ドメイン境界が曖昧で探索が必要 ◦ → 分散トランザクションを導入せずにできる設計を優先する。 • ドメイン境界が曖昧で探索が必要 x 統合された体験を提供したい ◦ → チーム構成が一定流動的になることに耐えるモジュール構成を構築する。 • 巨大なワークフローをカバーする必要がある x 継続的に進化し続けたい ◦ → チームを分割して、各チームが独立して開発できるようにする。 ヘンリーでの例: ほかにも
24. Copyright © Henry, Inc. All rights reserved. 24 どうやって設計を生み出し、 育てていくか
25. Copyright © Henry, Inc. All rights reserved. • 巷の設計論、他社の事例、技術的トレンドなど、とにかくインプットはして おくべき。 • 自分たちの状況にマッチする設計を導くには、多様な視点を持つことが 重要。 ◦ 正解を探して模倣するのではなく、自分たちの文脈に落とし込んで再構築する ための材料を集める。 とにかくいろんなものをインプットしておく
26. Copyright © Henry, Inc. All rights reserved. • 加えて、原則や著名な格言を知っておくと、コミュニケーションの助けにも なる。 • たとえばこんなもの ◦ KISS (Keep It Simple, Stupid) ◦ YAGNI (You Aren't Gonna Need It) ◦ Worse is Better ◦ リスコフの置換原則 • 自分の設計判断を言語化するための材料としても活用できる。 原則とされるものは知っておくと良い
27. Copyright © Henry, Inc. All rights reserved. • 「多くの人や状況に揉まれて形作られた知見は、多分優れている」という 前提に立つ。 • 社会レベルで存在する現状の引力に、無駄に抗うのは得策ではない。 ◦ AIの台頭もあり、これまで以上に「世に広く普及したものを採用する」価値が上 がってきた。 • とはいえ、個人として車輪の再発明は大好き。これをやることで理解できる ものはとても多い。 ◦ そこから新しいものを生み出せることだってある。 無駄な独自路線は避ける
28. Copyright © Henry, Inc. All rights reserved. • 知識から良い設計を生み出すには、ぼんやりとした理解では足りない。 • 「その設計やパターンを構成する要素」をなるべく要素に分解し、それぞれ が担う役割と相互作用を理解する。 • 特にアーキテクチャっぽい話題は、複数の要素が組み合わさっていることが 多い。 ◦ 複数の問題を同時に解くエレガントなアーキテクチャであるという見方ももちろ んできるが、それらすべてが自分たちの状況にマッチすることは稀。 ◦ （一方で、中途半端に部分的に採用すると、意義を失ったり逆に複雑化すること もある。） 曖昧なまま実践しない
29. Copyright © Henry, Inc. All rights reserved. • 設計の意図を自分たちの言葉で言語化することがチームにとって重要。 ◦ 何を大事にしているのか？何を犠牲にしているのか？それはなぜか？ ◦ 「〇〇設計/アーキテクチャをやります」で曖昧すぎる。 • 正しく実践されるようにする意味でもあるが、なにより設計を進化させるた めにとても大切。 ◦ 意図がわからないと、これまでの歩みが伝わらず、設計が育たない。 意図を言語化する
30. Copyright © Henry, Inc. All rights reserved. • 初手の実践で価値が出せないものは、やり切るのが難しい。 ◦ 逆に、小さくても初手で価値が出ると、そこに良い引力が生まれ、加速できる。 • そのためには、要素を分解して最小限の構成で始めることが有効。 ◦ 無駄な障壁を回避できる。 • 多少の妥協をしてでも、初速を稼ぐことを優先したほうがいいこともある。 ◦ 原理主義的に進めると、初速が稼げないことが多い。 いきなり価値を出すことを目指す
31. Copyright © Henry, Inc. All rights reserved. • 新しい設計の導入直後は、一時的に生産性が落ちる谷を必ず迎える。 • まずは個人として責任を持ち、チームを巻き込んで価値が出せるところまで やりきる。 ◦ コードを書くだけでなく、ドキュメンテーションや社内勉強会などの手段も活用 する。 やりきる
32. Copyright © Henry, Inc. All rights reserved. • 設計の正しさを支えていた「事業・サービス・現状」という前提は、時間と 共に簡単に変化する。 • 前提が変われば、最適な設計も変わる。 • ビジネスやサービスの全体に興味を持ち続け、変化を最前線で捉え続けるこ とが、設計者には求められる。 前提を常にウォッチする
33. Copyright © Henry, Inc. All rights reserved. 33 おわりに
34. Copyright © Henry, Inc. All rights reserved. 今回は、僕個人が普段「設計」をするときに意識していることを 共有しました。 最初にも述べた通り、設計の正解はなく、考え方にも正解はありません。 それでも、自分の中の「考え方」の形をはっきりさせておくことは、 チームでより良いソフトウェアを作っていくためにとても大切です。 ぜひ、みなさんも自分の「設計の考え方」を意識してみてください。 おわりに
35. Copyright © Henry, Inc. All rights reserved. 会社ブログ 採用サイト Thank you 技術ブログ Podcast