Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Avatar for Agata Naomichi

Agata Naomichi

July 07, 2025
Tweet

More Decks by Agata Naomichi

Other Decks in Programming

Transcript

  1. Copyright © Henry, Inc. All rights reserved. • 大前提: 万人にとっても正解となる設計なんてものは存在しない。

    ◦ 結局は、自分たちの状況に合わせて考え、作り、改善し続けるしかない。 • だからこそ、考えるための指針 = 「考え方」を自分の中に持つことが重要。 • ここからは、僕個人の「考え方」を共有します。 • みなさんが持っている「考え方」を意識したり育てたりするきっかけになれ ばうれしいです。 ◦ 僕の考え方は別にベストでも網羅的でもないかもしれない。 ◦ 人の考え方との差分で自分の考え方が見えてきたりもする。 ◦ いろんな角度の考え方を組み合わせることがチームで開発するということ。 今日伝えたいこと
  2. Copyright © Henry, Inc. All rights reserved. • 縣 直道

    (@agatan_) ◦ 株式会社ヘンリーで、医事会計システムの開発チームのリーダーをしています。 ▪ 最近 「gRPCで分断されたモノリスを段階的にモジュラーモノリスに移行す る」 というブログを書きました! ◦ 前職では toC サービスの新規事業立ち上げに従事していました。 • 株式会社ヘンリー ◦ クラウド型電子カルテ・医事会計システムを開発・提供している会社 ◦ https://henry.jp/ 󰳕 自己紹介
  3. Copyright © Henry, Inc. All rights reserved. • 設計という言葉を含む単語の例 ◦

    ドメイン駆動設計 ◦ API設計 ◦ データベース設計 ◦ 基本設計、詳細設計 • そのほか、関連が深い単語の例 ◦ クリーンアーキテクチャ ◦ マイクロサービス ◦ MVC • etc... 粒度も領域もまちまち... “設計”
  4. Copyright © Henry, Inc. All rights reserved. • 設計とは、トレードオフの中でより良い状態を探索する活動である。 •

    その活動は、創造的で論理的で動的な性質を持つ。 • 実際には、こんなに単純な2軸ではなく、多次元のトレードオフがある。 この勉強会での "設計"
  5. Copyright © Henry, Inc. All rights reserved. • 「大事にすべき要素はコレで、そのためならアレはこの程度までは犠牲にす ることを厭わない」、とロジックを持って決める必要がある。

    • そのロジックの筋や通りが良ければ良いほど、"良い"設計である。 ◦ その要素は本当に捨てて良いものか? ◦ その要素を捨てることで得られるものは本当に価値があるのか? ◦ その要素を捨てれば本当に得たいものが得られるのか? ◦ 捨てる量、得る量のバランスは適切か? "良い"設計とは?
  6. Copyright © Henry, Inc. All rights reserved. • 極端な例をあげると... ◦

    常に最新の流行り技術に乗っかりたい! v.s. 実績のある枯れた技術しか使わな い! ◦ 事前に設計書を完璧に書く! v.s. 書いてみないとわからないから設計なんてせず に書く! ◦ ガチガチに静的検証する! v.s. 柔軟に書けることがすべて! • どちらもある側面では正しく、ある側面では正しくない。 • 意見が割れるのは、大事にしている要素が違うから。 • 実際には中庸を取る。その判断こそが設計。 例えば...
  7. Copyright © Henry, Inc. All rights reserved. • 「これを大事にします」という主張だけでは、設計判断としては不十分。 ◦

    そりゃ全部大事にできたほうがいい • 犠牲にするものを明確にして初めて、設計判断がシャープになる。 • それが曖昧なら、設計も曖昧である可能性が高い。 ◦ (犠牲にするものが本当にないことも稀にあるし、それが理想ではある) 何を「犠牲」にしているかが大事
  8. Copyright © Henry, Inc. All rights reserved. • 「DDD (ドメイン駆動設計)

    やってます」 • 「マイクロサービスやってます」 • 「クリーンアーキテクチャやってます」 これらの言葉は、(原義はどうあれ)解釈がゆらぎ、意味が希薄化しがち。 解釈が揺らぐと、「何を大事にし、何を犠牲にするか」という宣言が曖昧にな り、設計が本来もたらすはずだった効果が落ちてしまう。 (余談)「〇〇やってます」問題
  9. Copyright © Henry, Inc. All rights reserved. • トレードオフの絶妙なパワーバランスは、いろんな理由で簡単に変わる。 •

    たとえば... ◦ 事業の方向性が変わって、指標Aはどうでも良くなった ◦ 新しい技術が出てきて、指標Aと指標Bは両立できるようになった ◦ 当初想定した通りに設計の効果が発揮されなかった / 違うものが見えてきた 設計は「育てる」もの
  10. Copyright © Henry, Inc. All rights reserved. • 月なみだが、事業やサービスの特性を理解し、設計判断の材料を揃えること が重要。

    • 加えて、現状の引力を正しく理解することも大事。 • これらは相互に影響し合っているので、その相互作用のメカニズムを理解す ることも大事。 判断材料を揃える
  11. Copyright © Henry, Inc. All rights reserved. • 実際に開発をしているエンジニアが一番意識しやすい要素。 ◦

    既存のコードベース、実装済みの機能 ◦ 今の開発組織の文化やスキルセット ◦ すでに蓄積された技術的負債 ◦ etc... • これをないがしろすると、机上の空論になってしまう。 • どんなにカタログスペックが良い設計も、この引力に負けて失敗することは 非常に多い。 • また、現状と理想のギャップを埋めることで価値が出る。 現状の引力
  12. Copyright © Henry, Inc. All rights reserved. • 作っているサービスの特性を知ることで、トレードオフの要素を適切に評価 できるようになる。

    ◦ そのサービスはどう使われるものか? ◦ どんな体験・価値を提供したいのか? ◦ どんな変更・拡張が起きやすいのか?あるいは起きにくいのか? • 特に非機能要件(パフォーマンス、信頼性、セキュリティ...)に注目するこ とで、採用すべき設計に強力な制約が生まれることがある。 ◦ 制約は設計を導いてくれるので、歓迎すべき。 サービス特性
  13. Copyright © Henry, Inc. All rights reserved. • その事業はどういう性質を持っているか? ◦

    外的要因によるちゃぶ台返しはあるか (法律改正など) ◦ 競合との戦い方、差別化要素 ◦ 将来のビジネス展開の方向性 ◦ どこまでスケールできる事業か • 実現までに時間のかかる大きな設計判断をする上で特に重要だが、考えきる ・読み切るのは難しいものでもある。 ◦ ここを加味した方針を示せると、より影響力のある設計判断を行えるようにな る。 事業特性
  14. Copyright © Henry, Inc. All rights reserved. • 現状の引力 ◦

    Kotlinで書かれた大規模なバックエンドサービスがすでにある ◦ 臨床と会計でそれぞれ独立したマイクロサービス構成を取っていた • サービス特性 ◦ 医療・会計なので、極めて高い信頼性が求められる ◦ 後発だからこそ、UXにこだわる必要がある ◦ 統合された体験を提供したいが、そのためにドメインの境界が曖昧になりやすい • 事業特性 ◦ 医療のもつ巨大なワークフローをカバーする必要がある ◦ クラウドサービスとして継続的に進化し続けることが期待される ヘンリーでの例
  15. Copyright © Henry, Inc. All rights reserved. • 創業当初から存在していた2つのマイクロサービスを統合し、 モジュラーモノリスに移行することを決定し、現在も実践中。

    ◦ まずモノレポ化を行い、物理的に触るコードの距離を縮めた。 ◦ その後、コードベースを徐々にパッケージとして切り出して、境界を模索した。 ◦ 段階的に2つのサービスをまたいだ処理を一方のサービスに集約した。 • 詳しくはヘンリーエンジニアブログを参照 ◦ “gRPCで分断されたモノリスを段階的にモジュラーモノリスに移行する” ◦ https://dev.henry.jp/entry/2025/06/13/145500 ヘンリーでの例: なぜモジュラーモノリスを志向したのか? 1
  16. Copyright © Henry, Inc. All rights reserved. • この設計判断を下した背景 ◦

    ある機能を実現するのに、2つのサービスを同時に変更する必要があり、 分断モノリスになっていた(現状の引力) ◦ ドメイン境界が曖昧で、どのように分割すればいいかがわからなかった (サービス特性) ◦ 一方で、作るべきものの量は膨大で、機能の面も広いので、組織として スケールできる必要があった(事業特性) • 犠牲にしたもの ◦ デプロイの独立性(もともとあまり活きていなかった) ◦ 過渡期の様々な混乱(混乱以上に価値が出ると判断した) ヘンリーでの例: なぜモジュラーモノリスを志向したのか? 2
  17. Copyright © Henry, Inc. All rights reserved. • ここで描いたゴールは、まだ中間状態。 •

    これから事業が進捗するにつれて、さらに育てていく種である。 ◦ ドメイン境界が明らかになった暁には、「モジュールを分割してマイクロサービ ス化したほうがスケールする」、という判断をする可能性だってある。 ◦ 今の自分たちの状況の中で、最も価値が出せる設計を選んだ。 ◦ むしろ、不確実ななかでも行動したことで見えてきたものもある。 • 設計は動的であり、育てるもの ヘンリーでの例: なぜモジュラーモノリスを志向したのか? 3
  18. Copyright © Henry, Inc. All rights reserved. • 信頼性が求められる x

    ドメイン境界が曖昧で探索が必要 ◦ → 分散トランザクションを導入せずにできる設計を優先する。 • ドメイン境界が曖昧で探索が必要 x 統合された体験を提供したい ◦ → チーム構成が一定流動的になることに耐えるモジュール構成を構築する。 • 巨大なワークフローをカバーする必要がある x 継続的に進化し続けたい ◦ → チームを分割して、各チームが独立して開発できるようにする。 ヘンリーでの例: ほかにも
  19. Copyright © Henry, Inc. All rights reserved. • 巷の設計論、他社の事例、技術的トレンドなど、とにかくインプットはして おくべき。

    • 自分たちの状況にマッチする設計を導くには、多様な視点を持つことが 重要。 ◦ 正解を探して模倣するのではなく、自分たちの文脈に落とし込んで再構築する ための材料を集める。 とにかくいろんなものをインプットしておく
  20. Copyright © Henry, Inc. All rights reserved. • 加えて、原則や著名な格言を知っておくと、コミュニケーションの助けにも なる。

    • たとえばこんなもの ◦ KISS (Keep It Simple, Stupid) ◦ YAGNI (You Aren't Gonna Need It) ◦ Worse is Better ◦ リスコフの置換原則 • 自分の設計判断を言語化するための材料としても活用できる。 原則とされるものは知っておくと良い
  21. Copyright © Henry, Inc. All rights reserved. • 「多くの人や状況に揉まれて形作られた知見は、多分優れている」という 前提に立つ。

    • 社会レベルで存在する現状の引力に、無駄に抗うのは得策ではない。 ◦ AIの台頭もあり、これまで以上に「世に広く普及したものを採用する」価値が上 がってきた。 • とはいえ、個人として車輪の再発明は大好き。これをやることで理解できる ものはとても多い。 ◦ そこから新しいものを生み出せることだってある。 無駄な独自路線は避ける
  22. Copyright © Henry, Inc. All rights reserved. • 知識から良い設計を生み出すには、ぼんやりとした理解では足りない。 •

    「その設計やパターンを構成する要素」をなるべく要素に分解し、それぞれ が担う役割と相互作用を理解する。 • 特にアーキテクチャっぽい話題は、複数の要素が組み合わさっていることが 多い。 ◦ 複数の問題を同時に解くエレガントなアーキテクチャであるという見方ももちろ んできるが、それらすべてが自分たちの状況にマッチすることは稀。 ◦ (一方で、中途半端に部分的に採用すると、意義を失ったり逆に複雑化すること もある。) 曖昧なまま実践しない
  23. Copyright © Henry, Inc. All rights reserved. • 設計の意図を自分たちの言葉で言語化することがチームにとって重要。 ◦

    何を大事にしているのか?何を犠牲にしているのか?それはなぜか? ◦ 「〇〇設計/アーキテクチャをやります」で曖昧すぎる。 • 正しく実践されるようにする意味でもあるが、なにより設計を進化させるた めにとても大切。 ◦ 意図がわからないと、これまでの歩みが伝わらず、設計が育たない。 意図を言語化する
  24. Copyright © Henry, Inc. All rights reserved. • 初手の実践で価値が出せないものは、やり切るのが難しい。 ◦

    逆に、小さくても初手で価値が出ると、そこに良い引力が生まれ、加速できる。 • そのためには、要素を分解して最小限の構成で始めることが有効。 ◦ 無駄な障壁を回避できる。 • 多少の妥協をしてでも、初速を稼ぐことを優先したほうがいいこともある。 ◦ 原理主義的に進めると、初速が稼げないことが多い。 いきなり価値を出すことを目指す
  25. Copyright © Henry, Inc. All rights reserved. • 新しい設計の導入直後は、一時的に生産性が落ちる谷を必ず迎える。 •

    まずは個人として責任を持ち、チームを巻き込んで価値が出せるところまで やりきる。 ◦ コードを書くだけでなく、ドキュメンテーションや社内勉強会などの手段も活用 する。 やりきる
  26. Copyright © Henry, Inc. All rights reserved. • 設計の正しさを支えていた「事業・サービス・現状」という前提は、時間と 共に簡単に変化する。

    • 前提が変われば、最適な設計も変わる。 • ビジネスやサービスの全体に興味を持ち続け、変化を最前線で捉え続けるこ とが、設計者には求められる。 前提を常にウォッチする
  27. Copyright © Henry, Inc. All rights reserved. 今回は、僕個人が普段「設計」をするときに意識していることを 共有しました。 最初にも述べた通り、設計の正解はなく、考え方にも正解はありません。

    それでも、自分の中の「考え方」の形をはっきりさせておくことは、 チームでより良いソフトウェアを作っていくためにとても大切です。 ぜひ、みなさんも自分の「設計の考え方」を意識してみてください。 おわりに