「全員のために作るシステム」が、誰も満足しないシステムになる前に読む話。
全体最適を目指すが、全てを救うのは無理という現実
2026年 / カテゴリ:現場SEあるある / 読了目安:5分
現場SEをやっていると、必ずぶつかる壁がある。それが「全体最適と個別対応の線引き」だ。システムを作る側としては、できるだけ多くの人が使いやすいものを届けたい。でも現実は、現場の数だけ「うちだけ特殊」な事情が存在している。
あるあるすぎる「例外対応の要求」
プロジェクトが走り出してしばらく経つと、必ずと言っていいほど出てくるのがこの言葉だ。
「この処理、うちの部署だけ少し違うんですけど、対応できますか?」
一件目は微笑ましい。二件目も頑張れる。でも五件目、十件目になると、設計の根本が揺らぎ始める。気づけば「全体最適」を謳っていたシステムが、個別対応の継ぎ接ぎだらけになっている。
例外を積み重ねた結果、標準フローが誰も使わない「名ばかりの標準」になる。保守コストは跳ね上がり、次の改修で誰も全体像を把握できなくなる。
「全員を救おうとする」ことの罠
真面目なSEほど、全部の要望に応えようとしてしまう。それ自体は悪くない。だが、全員を救おうとするシステムは、構造的に「誰も満足させないシステム」になりやすい。
理由はシンプルで、例外が増えれば増えるほど、本来の標準ルートが細く・複雑になっていくからだ。全員分の抜け道を用意しようとすると、どのルートも中途半端になる。
「全員対応」を目指した結果、テストパターンが爆発し、リリースが遅れ、バグが増え、誰の要望も中途半端にしか満たせなかった……という経験、心当たりありませんか。
線引きはどこに引くべきか
では、どこで線を引けばいいのか。現場感覚として使っている判断基準を整理するとこうなる。
| ケース | 対応方針 | 判断 |
|---|---|---|
| 全社員の50%以上が使う処理 | システムに組み込む | 標準化 |
| 特定部署・特定ロールだけの処理 | 権限・設定で吸収できないか検討 | 要検討 |
| 利用頻度が月1回以下の例外処理 | 手運用+マニュアル化を推奨 | 手運用 |
| 将来的に廃止予定の業務フロー | 原則対応しない | 対象外 |
ポイントは「頻度」と「影響範囲」の2軸で考えることだ。頻度が低く影響範囲が狭い処理を、わざわざシステムに組み込む必要はない。「手運用でお願いします」も、立派な設計判断だ。
「手運用を選ぶ」は逃げではない
経験の浅いころは、「手運用にする=設計の敗北」と感じていた。でも、今はそう思っていない。適切な範囲で手運用を選択することは、むしろシステムの品質を守る行為だ。
システムが扱うべき範囲を絞り込むことで、標準ルートの品質・安定性・保守性が上がる。80%を高品質で救う設計は、100%を中途半端に救う設計より、結果として多くの人を幸せにする。
線引きを伝えることもSEの仕事
技術的な判断だけでなく、「なぜここに線を引いたか」をステークホルダーに説明できることが重要だ。「できない」ではなく「ここはシステムではなく運用で対応する方が、長期的にあなたたちにとっても有利です」という説明ができるかどうか。
全体最適を守るための線引きは、交渉であり、設計であり、コミュニケーションだ。全員を救えないことを正直に伝え、それでも最大多数が恩恵を受けられる落としどころを一緒に探す。それが現場SEの腕の見せ所だと、今はそう思っている。
この記事のまとめ
- 全員を救おうとするシステムは、誰も満足させないシステムになりやすい
- 「頻度」と「影響範囲」を基準に、システム対応と手運用を切り分ける
- 「手運用を選ぶ」は設計の敗北ではなく、品質を守る積極的な判断
- なぜ線を引いたかを説明できることも、現場SEの大切なスキル
#システム設計
#SEあるある
#全体最適
#ITエンジニア
#プロジェクト管理

