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

by bayashi

Slide 1

Slide 1 text

複雑さを受け入れるか、拒むか？事業成長とともに育ったモノリスを前に私が考えたこと Regional Scrum Gathering Tokyo 2026 2026/1/7 Kei Ogane

Slide 2

Slide 2 text

自己紹介ばやし(Kei Ogane) 株式会社Linc’well所属オンライン診療システム提供サービスでエンジニアリングマネージャー最近の趣味はようやく手に入れた Nintendo Switch2でNintendo Switchでも出来るゲームをすることです

Slide 3

Slide 3 text

会社紹介

Slide 4

Slide 4 text

オンライン診療システム提供サービスシステム提供  診療 

Slide 5

Slide 5 text

患者さん向けもクリニック向けも

Slide 6

Slide 6 text

更に複雑なところクリニックフォアが提供しているオンライン診療の診療科の数はとても多い

Slide 7

Slide 7 text

診療科毎の体験の磨き込み例えば低用量ピルの患者さんと男性AGAの患者さんだとペルソナが全然違う医療は健康に関わる分野だから不安を抱えやすい診療科の体験をそれぞれ磨き込まなきゃ（白目）

Slide 8

Slide 8 text

複雑だから強い中核の業務領域の実装が簡単であれば、競争優位を維持できるのは短い間だけです。したがって、中核の業務領域は必然的に複雑になります。出典: ドメイン駆動設計をはじめよう Vlad Khononov著、増田亨、綿引琢磨訳

Slide 9

Slide 9 text

ありがたいことに使われている

Slide 10

Slide 10 text

ただ辛いところもあって最初期に作られたモノリス*1がそのままスケールしているモジュラーモノリス*2化など抜本的に複雑さを低減させる取り組みも動いているが、短期的にも複雑さを低減させる取り組みが必要詳しくは 2025年 Packwerkの現在と弊社の状況 https://zenn.dev/lincwell_inc/articles/packwerk-trends-2025 *1 モノリス: すべての機能が一体化した単一のアプリケーション *2 モジュラーモノリス: 内部を明確なモジュールに分けた単一のアプリケーション

Slide 11

Slide 11 text

プロダクトには許容できる複雑さの限界がある出典: ルールズ・オブ・プログラミング ―より良いコードを書くための21のルールChris Zimmerman (著), 久富木隆一 (翻訳) 新しい機能を追加すると、コードが複雑になることが多い。そして、コードが複雑になるにつれ、そのコードで作業するのがどんどん難しくなり、進捗がどんどん遅くなる。そこでは、バグ修正だろうが機能追加だろうが、先に進もうとするどんな試みも、問題を解くそばから、解いた問題の数だけ同じ数の問題を新たに発生させる。

Slide 12

Slide 12 text

我々はプロダクト開発でこういうゲームをやっている許容できる複雑さの残りゲージを削りつつプロダクトの価値を積み上げていく残りゲージが無くなったらゲームオーバー（追加開発ができなくなる）複雑さ根本から違う機能の開発売上が30上がった！複雑さが40上がった！

Slide 13

Slide 13 text

とはいえ複雑さのために開発を拒否しては本末転倒〇〇っていう新機能出したいんですよね  それは複雑さ上がるんで駄目です  このままだとサービスクローズなんだけど...

Slide 14

Slide 14 text

複雑さを低減しながら開発をする方法 - 継続性が読めないものは捨てやすく作る - モデルをアップデートする - 要件と設計を行き来する

Slide 15

Slide 15 text

継続性が読めないものは捨てやすく作る今後も使われるかの確度が低い機能は、現行のシステムとできるだけ疎な関係にしつつビジネス上の要望を満たす例) - SaaSで代替 - DRY原則*1 を破りわざと冗長に作る新規プロダクトだと継続性は見えにくいが、既存はこれまでの実績で継続性の見立てがそれなりにできる現行機能群新機能 *1 DRY原則: Don't repeat yourselfの略。コードの重複を防ぐ考え方

Slide 16

Slide 16 text

捨てやすいからチャレンジがしやすいプロダクトを成長させる上で不確実なものにチャレンジするのは大事不確実なものにトライして上手くいかなかった際にすぐにリセットできるように捨てやすく作るもう使ってない機能で複雑さを上げない複雑さ上手くいかなかった機能の削除複雑さが40下がった！

Slide 17

Slide 17 text

ずっと使われそうな機能はただ作ればオッケー？己の中の疑問を呈してくる人

Slide 18

Slide 18 text

モデルをアップデートするずっと使われるであろう機能は捨てやすさに拘らず開発をするしかし、ただ新しい機能を追加するのではなく新しく機能が加わることで、全体のモデル、機能はどうアップデートされるのかを再検討するよりコストは掛かるが、短期的なアウトプットの速さよりも複雑さが増大しないことを重視している資料シェア機能ってユーザがアクセス権を操作できるってことか。じゃあ既存のアクセス禁止機能と実は同じか？アクセス禁止機能資料シェア機能権限管理機能再検討例）

Slide 19

Slide 19 text

エリック・エヴァンスもそう言ってる出典：エリック・エヴァンスのドメイン駆動設計エリックエヴァンス (著), 和智右桂 (翻訳), 牧野祐子 (翻訳) 新しい要求が自然には適合しなかったりする場合には、やはりドメインモデルが間違っているという認識が得られることがある。 (中略) より深くドメインを理解するようになった開発者は、モデルをもっとわかりやすくしたり、役立つようにしたりするための好機を見出すのだ。

Slide 20

Slide 20 text

戦術的プログラミングと戦略的プログラミング戦術的プログラミングの問題点は、近視眼的であることだ。戦術的なプログラミングをする場合、できるだけ早くタスクを終わらせようとしている。 (中略) あなたの第一の目標は、優れたデザインを生み出すことであり、それがたまたま機能することでもある。これが戦略的プログラミングです。出典：John Ousterhout著『A Philosophy of Software Design, 2nd Edition』（筆者訳）

Slide 21

Slide 21 text

でも、要件を満たそうとすると捨てづらかったり複雑なものになってしまう... 己の中の疑問を呈してくる人

Slide 22

Slide 22 text

要件と設計を行き来する要件まで踏み込んで設計を考えると、設計の幅はとても広がる捨てやすく作るためだったり、複雑さを下げるために要件のトレードオフを PdMやステークホルダー *1と一緒に探っていく〇〇ができない案 ☓☓が困る案 SaaSで実現 API連携別システム切り出し全部盛り案〇〇機能と統合 *1 コンテキストによって要件のトレードオフを探っていく人は変わりそうですね

Slide 23

Slide 23 text

要件と設計を行き来するの具体例特定の診療科において診察の前に特定の業務を実施したいという要望があったまた制約として以下があった - 現在のシステム上で操作をできるようにしたい現在のコードだと、診察のステップは診療科共通であるため１ステップ追加されると影響は甚大診察のステップ共通化されてるから厳しい...

Slide 24

Slide 24 text

要件と設計を行き来するの具体例制約の背景も - システムを切り替えながらだとオペレーションの負荷増大が懸念と至極真っ当なものだった PdMを介してステークホルダーと落とし所を探ろうとしてもなかなかうまい落とし所が見つからなかった影響が大きいのでシステムに組み込みたくない... 同じシステム上で実現しないと厳しい... どっちの言い分もわかる...

Slide 25

Slide 25 text

要件と設計を行き来するの具体例落とし所が見つからないのは、お互いの事情の解像度の問題かと思い、直接ステークホルダーと会話することに議論を重ねる上でわかってきたのが以下であった - 実験的な施策のため最初はスモールスタート。オペレーション影響もそこまでない - 規模が大きくなるとシステムを切り替えながらだと難しいお互いの時間軸がずれてたっぽい

Slide 26

Slide 26 text

要件と設計を行き来するの具体例 - 最初はSaaSでスモールに試す - 施策がヒットしてスケールしたら今のシステムに組み込むという落とし所を見出し、大規模開発することなく施策の実施ができたまた後日談としてSaaSで実験的な施策の実施は問題はなかったオンライン診療システム SaaS 新機能を組み込んだオンライン診療システム

Slide 27

Slide 27 text

複雑さを低減させるためには実現したいことだけではなく - ビジネスの確度 - 要求やシステムの時間軸を自ら直接掴みに行くことが大事であることを認識した最初のユーザ数って... 施策の全体像として...

Slide 28

Slide 28 text

とはいえ簡単にはできないステークホルダーやPdMと要件のトレードオフを探りに行っても上手くいかないことも - 業務や背景の解像度が粗く、何も突っ込めない - 事業、ユーザへの理解が足りておらず開発側の都合に寄り添い過ぎてしまう

Slide 29

Slide 29 text

解像度を上げる相手側の領域への解像度が低いとそもそも会話ができないエンジニアが、プロダクト、オペレーション、事業の理解をすることが大事であることが分かったので、色々やりました

Slide 30

Slide 30 text

事業やプロダクトの理解はどうやったか - 実際に自分で体験する - 実際のデータから把握する - 現場を見学する - スプリントレビューで事業理解を深める

Slide 31

Slide 31 text

実際に自分で体験する自分たちが提供しているプロダクトは一体どんな体験を提供してるのか理解したい自分もよくオンライン診療を使っているし、メンバーにも使うことをおすすめしてる

Slide 32

Slide 32 text

実際のデータから把握するすべての診療科を自分で経験はできないので - 社内の詳しい人からドメイン知識を学んだり - 自分たちで詳しく調べる勉強会をやったり - ユーザの行動データを分析しながらみんなでわいわいしたりして自分が体験できないエリアの知識もキャッチアップ

Slide 33

Slide 33 text

現場への理解入社したら一度は現場を見に行ってるプロダクトが実際に使われているところを見ることで以下の効果を期待している - プロダクトの使われ方を知る - 現場の空気感やオペレーションの高度さを学ぶ - 上記を学びオペレーションサイドの人と会話をする際のスタンスを得る

Slide 34

Slide 34 text

スプリントレビューで事業理解を深めるスプリントレビューはこれまでただ機能のデモをしているだけだったそこからデモ以外に - 過去リリースした機能のインパクト - 現在追ってるKPI状況の共有もスプリントレビューでやることにしたデモの際にも機能の動作ではなく、機能の価値を説明するようにしたスプリントレビューを通じて事業理解を深められる形にした

Slide 35

Slide 35 text

キャッチアップするのは大変目の前のソースコードに向き合いつつ事業・現場・プロダクトまで理解して複雑さのトレードオフをバランスさせるのは大変だけど...

Slide 36

Slide 36 text

複雑だから強い(再掲) 中核の業務領域の実装が簡単であれば、競争優位を維持できるのは短い間だけです。したがって、中核の業務領域は必然的に複雑になります。出典: ドメイン駆動設計をはじめよう Vlad Khononov著、増田亨、綿引琢磨訳

Slide 37

Slide 37 text

複雑さを受け入れるか、拒むか？受け入れる複雑さ、拒む複雑さを判断するための事業やドメインの理解受け入れるけど複雑さを最低限にするためのエンジニアリング両立するのは難しいけど難しいことやって競争優位性を高めていきたいですね