複雑さを受け入れるか、拒むか？ - 事業成長とともに育ったモノリスを前に私が考えたこと #RSGT2026

Regional Scrum Gathering Tokyo 2026 の資料です

Transcript

1. 複雑さを受け入れるか、拒むか？ 事業成長とともに育ったモノリスを前に私が考えたこと Regional Scrum Gathering Tokyo 2026 2026/1/7 Kei Ogane
2. 自己紹介 ばやし(Kei Ogane) 株式会社Linc’well所属 オンライン診療システム提供サービスで エンジニアリングマネージャー 最近の趣味はようやく手に入れた Nintendo Switch2でNintendo Switchで も出来るゲームをすることです
3. 会社紹介
4. オンライン診療システム提供サービス システム提供
 診療

5. 患者さん向けもクリニック向けも
6. 更に複雑なところ クリニックフォアが提供している オンライン診療の 診療科の数はとても多い
7. 診療科毎の体験の磨き込み 例えば低用量ピルの患者さんと 男性AGAの患者さんだとペルソナが全然違う 医療は健康に関わる分野だから不安を抱えやすい 診療科の体験をそれぞれ磨き込まなきゃ（白目）
8. 複雑だから強い 中核の業務領域の実装が簡単であれ ば、競争優位を維持できるのは短い 間だけです。 したがって、 中核の業務領域は必然的に複雑 になります。 出典: ドメイン駆動設計をはじめよう Vlad Khononov著、増田 亨、綿引 琢磨訳
9. ありがたいことに使われている
10. ただ辛いところもあって 最初期に作られたモノリス*1が そのままスケールしている モジュラーモノリス*2化など 抜本的に複雑さを低減させる取り組みも 動いているが、短期的にも複雑さを 低減させる取り組み が必要 詳しくは 2025年 Packwerkの現在と弊社の状況 https://zenn.dev/lincwell_inc/articles/packwerk-trends-2025 *1 モノリス: すべての機能が一体化した単一のアプリケーション *2 モジュラーモノリス: 内部を明確なモジュールに分けた単一のアプリケーション
11. プロダクトには許容できる複雑さの限界がある 出典: ルールズ・オブ・プログラミング ―より良いコードを書くための21のルールChris Zimmerman (著), 久富木 隆一 (翻訳) 新しい機能を追加すると、コードが複雑 になることが多い。 そして、コードが複雑になるにつれ、 そのコードで作業するのがどんどん難 しくなり、進捗がどんどん遅くなる 。 そこでは、バグ修正だろうが機能追加だ ろうが、先に進もうとするどんな試み も、問題を解くそばから、解いた問題の 数だけ同じ数の問題を新たに発生させ る。
12. 我々はプロダクト開発でこういうゲームをやっている 許容できる複雑さの残りゲージを削りつつ プロダクトの価値を積み上げていく 残りゲージが無くなったら ゲームオーバー（追加開発ができなくなる） 複雑さ 根本から違う機能の開発 売上が30上がった！ 複雑さが40上がった！
13. とはいえ複雑さのために開発を拒否しては本末転倒 〇〇っていう新機能 出したいんですよね
 それは複雑さ 上がるんで駄目です
 このままだと サービスクローズ なんだけど...
14. 複雑さを低減しながら開発をする方法 - 継続性が読めないものは捨てやすく作る - モデルをアップデートする - 要件と設計を行き来する
15. 継続性が読めないものは捨てやすく作る 今後も使われるかの確度が低い機能は、 現行のシステムとできるだけ疎な関係にしつ つビジネス上の要望を満たす 例) - SaaSで代替 - DRY原則*1 を破りわざと冗長に作る 新規プロダクトだと継続性は見えにくいが、 既存はこれまでの実績で継続性の見立てが それなりにできる 現行機能群 新機能 *1 DRY原則: Don't repeat yourselfの略。コードの重複を防ぐ考え方
16. 捨てやすいからチャレンジがしやすい プロダクトを成長させる上で不確実なものに チャレンジするのは大事 不確実なものにトライして 上手くいかなかった際に すぐにリセットできるように捨てやすく作る もう使ってない機能で複雑さを上げない 複雑さ 上手くいかなかった機能の削除 複雑さが40下がった！
17. ずっと使われそうな機能は ただ作ればオッケー？ 己の中の疑問を呈してくる人
18. モデルをアップデートする ずっと使われるであろう機能は 捨てやすさに拘らず開発をする しかし、ただ新しい機能を追加するのではなく 新しく機能が加わることで、 全体のモデル、機能はどうアップデートされる のかを再検討 する よりコストは掛かるが、短期的なアウトプットの 速さよりも複雑さが増大しないことを重視してい る 資料シェア機能ってユーザが アクセス権を操作できるってことか。 じゃあ既存のアクセス禁止機能と 実は同じか？ アクセス 禁止機能 資料シェア 機能 権限 管理機能 再検討 例）
19. エリック・エヴァンスもそう言ってる 出典：エリック・エヴァンスのドメイン駆動設計 エリック エヴァンス (著), 和智 右桂 (翻訳), 牧野 祐子 (翻訳) 新しい要求が自然には適合しなかったり する場合には、やはりドメインモデルが 間違っているという認識が得られること がある。 (中略) より深くドメインを理解するように なった開発者は、モデルをもっとわか りやすくしたり、役立つようにしたり するための好機を見出すのだ。
20. 戦術的プログラミングと戦略的プログラミング 戦術的プログラミングの問題点は、近 視眼的であることだ。戦術的なプログ ラミングをする場合、できるだけ早く タスクを終わらせようとしている。 (中略) あなたの第一の目標は、優れたデザイ ンを生み出すことであり、それがたま たま機能することでもある 。これが戦 略的プログラミングです。 出典：John Ousterhout著『A Philosophy of Software Design, 2nd Edition』（筆者訳）
21. でも、要件を満たそうとすると 捨てづらかったり複雑なものになってしまう... 己の中の疑問を呈してくる人
22. 要件と設計を行き来する 要件まで踏み込んで設計を考えると、 設計の幅はとても広がる 捨てやすく作るためだったり、 複雑さを下げるために要件のトレードオフを PdMやステークホルダー *1と一緒に 探っていく 〇〇ができない案 ☓☓が困る案 SaaSで実現 API連携 別システム切り出し 全部盛り案 〇〇機能と 統合 *1 コンテキストによって要件のトレードオフを探っていく人は変わりそうですね
23. 要件と設計を行き来するの具体例 特定の診療科において診察の前に特定の業務 を実施したいという要望があった また制約として以下があった - 現在のシステム上で操作をできるように したい 現在のコードだと、診察のステップは診療科 共通であるため１ステップ追加されると影響 は甚大 診察のステップ共通化 されてるから 厳しい...
24. 要件と設計を行き来するの具体例 制約の背景も - システムを切り替えながらだと オペレーションの負荷増大が懸念 と至極真っ当なものだった PdMを介してステークホルダーと落とし所を探 ろうとしてもなかなかうまい落とし所が見つ からなかった 影響が大きいので システムに組み込 みたくない... 同じシステム上で 実現しないと厳し い... どっちの言い分も わかる...
25. 要件と設計を行き来するの具体例 落とし所が見つからないのは、お互いの事情 の解像度の問題かと思い、 直接ステークホルダーと会話することに 議論を重ねる上でわかってきたのが 以下であった - 実験的な施策のため最初はスモールス タート。オペレーション影響もそこまで ない - 規模が大きくなるとシステムを切り替え ながらだと難しい お互いの時間軸が ずれてたっぽい
26. 要件と設計を行き来するの具体例 - 最初はSaaSでスモールに試す - 施策がヒットしてスケールしたら 今のシステムに組み込む という落とし所を見出し、 大規模開発することなく施策の実施ができた また後日談としてSaaSで 実験的な施策の実施は問題はなかった オンライン診療 システム SaaS 新機能を組み込んだ オンライン診療システム
27. 複雑さを低減させるためには 実現したいことだけではなく - ビジネスの確度 - 要求やシステムの時間軸 を自ら直接掴みに行く ことが 大事であることを認識した 最初のユーザ数って... 施策の全体像として...
28. とはいえ簡単にはできない ステークホルダーやPdMと要件のトレードオフを探りに 行っても上手くいかないことも - 業務や背景の解像度が粗く、何も突っ込めない - 事業、ユーザへの理解が足りておらず 開発側の都合に寄り添い過ぎてしまう
29. 解像度を上げる 相手側の領域への解像度が低いと そもそも会話ができない エンジニアが、プロダクト、オペレーショ ン、事業の理解をすることが大事であること が分かったので、色々やりました
30. 事業やプロダクトの理解はどうやったか - 実際に自分で体験する - 実際のデータから把握する - 現場を見学する - スプリントレビューで事業理解を深める
31. 実際に自分で体験する 自分たちが提供しているプロダクトは一体どんな 体験を提供してるのか理解したい 自分もよくオンライン診療を使っているし、メン バーにも使うことをおすすめしてる
32. 実際のデータから把握する すべての診療科を自分で経験はできないので - 社内の詳しい人からドメイン知識を学んだり - 自分たちで詳しく調べる勉強会をやったり - ユーザの行動データを分析しながらみんなで わいわいしたり して自分が体験できないエリアの知識も キャッチアップ
33. 現場への理解 入社したら一度は現場を見に行ってる プロダクトが実際に使われているところを見る ことで以下の効果を期待している - プロダクトの使われ方を知る - 現場の空気感やオペレーションの 高度さを学ぶ - 上記を学びオペレーションサイドの人と 会話をする際のスタンスを得る
34. スプリントレビューで事業理解を深める スプリントレビューはこれまでただ機能のデモをしているだけだった そこからデモ以外に - 過去リリースした機能のインパクト - 現在追ってるKPI状況の共有 もスプリントレビューでやることにした デモの際にも機能の動作ではなく、機能の価値を説明するようにした スプリントレビューを通じて事業理解を深められる形にした
35. キャッチアップするのは大変 目の前のソースコードに向き合いつつ 事業・現場・プロダクトまで理解して 複雑さのトレードオフをバランスさせるのは 大変だけど...
36. 複雑だから強い(再掲) 中核の業務領域の実装が簡単であれ ば、競争優位を維持できるのは短い 間だけです。 したがって、 中核の業務領域は必然的に複雑 になります。 出典: ドメイン駆動設計をはじめよう Vlad Khononov著、増田 亨、綿引 琢磨訳
37. 複雑さを受け入れるか、拒むか？ 受け入れる複雑さ、拒む複雑さを判断する ための事業やドメインの理解 受け入れるけど複雑さを最低限にするため のエンジニアリング 両立するのは難しいけど 難しいことやって競争優位性を高めて いきたいですね