「ちゃんと作らない」という判断が正しいとき、コストになるとき
― 期間・関与人数・設計の温度から考えるシステム設計
この記事では、「ちゃんと作らない」という設計判断がどんな前提のもとでは合理的で、
どんな前提を外すとコストになるのかをまとめています。
何を作るのか、既存のツールで代替できないのは何か？
そもそも「何を作るか」をどうやって定義するか。
新しくシステムやアプリを作るとき、
まず考えるのは「どう作るか」でも、「なぜ作るのか」でもなく、
既存のツールでは、どこが合っていないのか。
この点が曖昧なまま始めると、その後の設計や実装の議論は、ほぼ間違いなくズレる。
既存ツールで代替できない理由は、意外と技術的なものではない。
業務フローと合わない
運用の前提が違う
ツールやシステムに合わせて人が動く必要が出てくる
これをやるためだけに、このツールは重い・値段が高い
こんな「小さな違和感」が積み重なって、「じゃあ作ろう」ってなる。
問題なのは、既存ツールが悪いかどうかではなく、
どこが合っていないのかが言語化されていない
「とりあえず自作」という結論に飛びついてしまう
「何を作るのか」は、
「何を作らないのか」を決める問いでもある。
この段階でズレていると、
後からどれだけ設計を頑張っても、そもそも作ったものが噛み合わない。
作るシステムやアプリはどのくらい使われることを想定しているのか？
次に、作るシステムがどれくらいの期間使われる想定なのか、
その前提が設計判断にどう影響するのか。
実際の期間自体には、明確な答えが出ないことが多い。
数ヶ月の検証で終わるかもしれない
1〜2年は使うかもしれない
思っていたより長く残るかもしれない
それ自体は問題ではない。
問題になるのは、この前提を仮にも考えずに設計すること。
使われる期間の想定は、設計の精度を決めるための材料であって、正確に予測するためではない。
数ヶ月で終わる可能性が高いもの
しばらく使うが、形は変わり続けそうなもの
長期的に同じ役割・同じ使い方になりそうなもの
どれなのかによって、設計に織り込むべき将来の仮定が変わる。
何年使うシステムなのかを、当てることが重要なのではない。
今の設計でどれだけ先まで持続させるかを考えておくことが重要。
使われている間、誰がどれくらい関わるのか
利用期間と合わせて重要なのが、関わる人の前提。
使われている間、エンジニアは関わり続けるのか
作った後はほぼ放置なのか
外注に引き渡すのか
触る人は固定か、入れ替わるのか
これらの前提は、設計の濃さに直接影響する。
エンジニアが継続的に関わる前提なら、
暗黙知が多少あっても回る
多少変な作りでも修正できる
一方で、
「誰も触らない」「触れない」時間が長くなる前提なら、
設計、実装内容の分かりにくさ
境界の不明確さ
変更のしにくさ
が、そのまま運用コストになる。
よくあるのは、
エンジニアが常に関わる前提の濃さで作られたシステムを、
エンジニアがほとんど関わらない運用に乗せてしまうケース
設計の問題に見えて、
実際には人の想定が外れたことが原因で変更がしづらい状態になる。
設計の議論に入る前に、
誰が（どんな人が）
どれくらいの期間
どの頻度、どの程度の時間、関わるのか・関われるのか
この前提を一度、言葉にしておくだけで、
その後の判断がかなり楽になる。
設計が合っていないシステムは、人の時間を食い始める
設計判断のコストが、どこに、どんな形で現れるのかの話。
システムの運用コストというと、
サーバー代やクラウド利用料が真っ先に思い浮かぶ。
月にいくらかかり、どれくらい最適化できるか。
もちろんそれも大事だけど、
多くの場合、エンジニアの稼働時間の方が高くつく。
仕様を理解する時間
影響範囲を調べる時間
触っていいのか迷っている時間
誰かに聞かないと進められない時間
結局作り直す時間
会計上は見えづらく、サーバー代より高くつく。
設計が合っていないシステムは、「人の時間」を食い始める。
変更のたびに慎重になる
触れる人が限られている
新しく入った人が戦力になるまでにかなりの時間がかかる
システムが重いのではなく、
設計の濃さと、関わる人の前提がズレている ことが原因。
重要なのは、インフラコスト削減ではなく、
設計判断を間違えたとき、
そのツケがエンジニアの時間として支払われる
ということ。
だから設計の濃さを考えるとき、
「インフラはいくらかかるか」以上に、
何人が
どれくらいの期間
どんな前提で関わるのか
を置かないと、判断がずれ、システム費用以上のコストになる。
設計の濃さは「期間 × 関与人数」で決まる
感覚や好みではなく前提条件から、設計の濃さを決める軸について。
長期間 × 多人数 → 高温
短期間 × 少人数 → 低温
長期間 × 少人数 → 要注意
短期間 × 多人数 → 痛い目を見る
期間が何ヶ月で何人でやるのが適切なのかは、決まっていない。
かつ、期間はある程度予測できても、人数に関しては増減がよく起こる。なぜならどこの組織もエンジニアは常に採用していて、流動性が高いから。
人数をどう扱うか？
作るシステム・アプリのことを理解していて、触れる人の数。
その上で何人が関わるか。
入れ替わりがどれくらい起こりうるか。
暗黙知が通用する程度の人数か。
入ってからしばらくは人数としてカウントできず、むしろキャッチアップのサポートにコストがかかるので減る。
期間：
・短期：数ヶ月〜半年
・中期：1〜3年
・長期：5年〜
人数：
・少：1~2人
・中：5人前後
・多：6人以上
を前提として、どんなことが起こりうるか？
短期 × 少人数
要件は変わる前提。正解がまだわかっていないから。
作り直す確率の方が高い。
モノリスでも、ベタ書きでも、仮の構造でも、動くものを作ることを最優先している。
抽象化、汎用/共通化など、将来を見据えた設計をしても、作り直す場合に意味がなくなる。
見えていない将来のための設計だから、空を掴むようなもの。
短期 × 多人数
仕様がかわりやすいのに、人が多い。
一斉に何かをしようとすると間違いなく衝突する。
全員が全体設計に口を出すと何も動かなくなるから、触る・設計する範囲を限定して、境界を明確にする。
同時に触られる前提で、衝突しない構造を作ることを優先すると、動きやすくなる。
長期 × 少人数
長く使われるけど、関わっている人が特定の人だけ。
その人しかわかっていないから属人化している。
長く続くほど暗黙知が増えていく。特定の人に依存しているので設計も改善されず、明確に困っていないので静かに破綻していく。
対策としては、人を増やさなくても引き継げる状態を作っていくこと。未来の自分になぜそうしたかを説明できるような状態を。
他には、「その人が明日いなくなったら？」のための準備しておく。
反対に、人数が少ないからと雑に作ると、長期的に使い続けた時に、
どこをどう触るのがセーフ・NGなのかがわからなくなる。
長期 × 多人数
長くたくさんの人が関わるので、引き継ぎなども発生する。
暗黙知を増やさないためのドキュメントや、人が触る範囲の限定と境界、責任の分離が必要になる。
ただ作り始めた段階ではこうなることを想定して、対策を立てることはない。というかできない。
長期 × 少人数のパターンから人が増えて、このパターンになることが多く、そのために準備しておくポイントがある。
最初から温度を高く将来のことを考えてきれいに作っていく必要はない。
でも、温度を上げられる余地を作れるかは最初の設計で決まる。
人数が余った時に気をつけること
人が余っている = 設計温度を上げていいサインではない。
代わりにやるのは、
境界の整理
消せるかの検証
ドキュメント化（最小限）
具体的には後で切れる部分を作り始めること。
元に戻すことが簡単にできる点以外に、部分的に他の人が関われるような状態を作っていくことにもつながるから。
反対に増えた人数で設計の温度だけを上げようとしても、
議論や衝突によって、少人数の時よりも物事が進みづらくなるケースがざらに出てくる。
人数が減った時に気をつけること
人数が減ったときには逆の判断が必要になる。
境界を減らす。
将来のための抽象化も、判断の障壁になるなら減らす。
1人でも全体を理解・判断できる状態に戻す。
設計の温度は、一度上げたら終わりではなく、
人数の増減ともに調整できることが重要になる。
引き返せなくなるポイント
設計の温度とコストの関係について、
「高い＝安全、低い＝危険」という誤解。
意図的な技術負債
設計の温度を下げて作ると、技術的負債は必ず生まれる。
テストがない、構造が変、暗黙の了解がある。
要件が固まっていない段階で、
将来を見据えた設計や抽象化をしないと、決めた結果で、
誤りでも、失敗でもない。
重要なのは、
その技術的負債は「返す前提」なのか、「捨てる前提」なのかを自覚しているかどうか。
低温設計だと、後者の場合が多い。
書き直すか、消す。
どちらにしても、想定内のコスト。
問題になるのは、低温で作ったことではなく、
低温で作ったものを、
いつまで使うのか決めずに時間が経つこと。
前提のずれの調整（リプレイスについて）
時間が経って、使われ方が変わって、
「仮のものではなくなる瞬間」が来る。
その時にはリプレイスが必要。
リプレイスというと、
「最初の設計が間違っていた」
「ちゃんと作れていなかった」
という反省点に思われがち。でも実態は違う。
多くの場合は、設計の前提が変わっただけ。
想定より長く使われるようになった
関わる人が増えた
他のシステムや業務とつながった
それに合わせて、
設計の温度を上げ直す必要が出た結果。
多くの場合、温度を上げる場所は限定できる。
ただ、それは最初にどの温度で作ったかではなく、
温度を変えられる余地を残していたかによる。
撤退コストは低温設計だから高くなるわけではない
設計の温度を誤ったときに起きる最大の事故は、
性能が出ないことでも、コードが汚くなることでもなく、やめられなくなること。
技術的負債があっても、コードは書き直せるし、
最悪、全部捨てることもできる。
それなのに、撤退できていないケースは多い。
誰がどう使っているのかわからないデータ
習慣化された業務フローに組み込まれている
他のシステムが前提としている
コードや設計をきれいにしても解消できない。
撤退コストは、技術的負債の延長として発生するのではなく、
低温設計で作ったものを、いつまで使うのかを決めずに、先送りし続けた結果として生まれる。
それが続いた結果、お金と人のリソースを吸う存在が残り続けることになる。
つまり、低温設計で作ること自体は適切な場合もある。
ただ、続けるかやめるかの判断をせずに放置することが、将来のコストになる。
設計の温度を決めるための確認ポイント
最後に、ここまでの話を踏まえて
設計の温度を決めるためのポイント。
想定利用期間はどれくらいか
（当てる必要はないが、大体でも考えたかどうか）利用期間に、誰がメンテナンスする前提か
（常にエンジニアが触るのか、ほぼ触らなくなるのか、その人はどの程度の労力をさけるのか）関わる人が増える・減る可能性はどの程度あるか
（事前に準備しておく必要がどれくらいあるか）触らなくなった時、簡単に消せるか
（作ったものを前提としているシステムや人が複雑になっていないか）今の設計温度は高すぎないか
（将来への期待が過度になっていないか）
※この記事は Medium に 2026年2月15日 に公開したものを転載しています。
ご相談等はこちらから：https://yoshiakihayashida.com/consulting/
