■ 1. 問題の概要
- 個人としては合理的な判断が組織として見た場合に非合理な判断となり事業を圧迫する
- よくある相談内容:
- 開発に時間がかかりすぎる
- サーバーコストが高いのではないか
- 新機能追加のたびに想定以上の工数がかかり見通しが立たない
- 月間数百/数千ユーザー程度のサービスに対して規模に明らかに過剰な状態となっていることが多い:
- 複雑な運用が必要な大規模向けの構成
- 最新技術が多数導入され全体の見通しが悪い
- ほとんど負荷がないのにキャッシュ層が導入されている
- データベースは大きめのサーバーで複数拠点での冗長構成
- エンジニアの能力不足ではなく個人として合理的に行動した結果意図してこのような状態にしている可能性がある
- 個人の問題ではなく構造的な問題
■ 2. 原因1: 転職市場が生む「キャリア最適化」のインセンティブ
- 転職市場での評価:
- 3年間安定したシステムを堅実に運用しパフォーマンスを最適化した経験より1年で最新技術を使った新しいシステム構築をリードした経験の方が年収が上がりやすい
- 「事業に必要かどうか」より「履歴書に書けるかどうか」が優先される構造
- 評価されるのは「ポータブルなスキル」:
- 最新技術の導入経験
- 有名な技術スタックでのシステム構築実績
- 業界標準とされる開発手法の経験
- 評価されにくいもの:
- 自社サービス固有の知見
- チーム独自のノウハウ
- 結果として生まれる構造:
- 月間利用者数が少ないサービスでも大規模構成
- 小規模チームで複雑なシステム分割
- シンプルな構成で十分な規模で最先端技術を導入
■ 3. 原因2: 成功企業の事例を真似する罠
- 技術カンファレンスやブログで目にするのはメルカリ/freee/エムスリーのような成功企業の事例
- 「最新技術で組織をスケールさせた」「マイクロサービス化で開発速度を向上させた」という事例は極めて特殊な前提条件の上に成り立っている
- 彼らにとっての「複雑なシステム」は組織のスケールに対する解決策であって技術的な理想形ではない
- 「成功企業のやり方=正解」という空気が規模に合わない設計を正当化してしまう
■ 4. 原因3: "絶対に落とさない"に対してのコスト
- 「システムが止まったら困るから念のため」という思考が過剰な構成を生む:
- 複数拠点での冗長構成を初期から導入
- サーバーは「大きめ」で確保
- 全システムを最高レベルの安定性で設計
- 将来の負荷に備えて先行投資
- 月間数千ユーザーのサービスに月間数百万ユーザーに対応できる構成
- 「念のため」という言葉で正当化されるが経営的には大きな機会損失
- 余剰コストで本来は新機能開発や顧客獲得に投資できたはず
■ 5. 対策1: 「キャリア最適化」のインセンティブに対して
- 「シンプルに保つこと」を評価項目に追加:
- 新技術導入だけでなく技術的負債の削減も評価
- 「コスト削減に成功した」を実績として認める文化
- 長期的な運用/改善を正当に評価
- 技術選定の意思決定プロセスを明文化:
- 「なぜこの技術を選ぶのか」を意思決定プロセスに組み込みドキュメント化
- 事業的な必要性を説明できることを前提とする
- 外部の目を入れる:
- 技術顧問やアドバイザーによる定期的なレビュー
- 「今の規模に本当に必要か」を客観的に判断
■ 6. 対策2: 成功企業の事例を真似する罠に対して
- 小さく始めて段階的に拡張する原則とする:
- 初期フェーズはシンプルな構成でスタート(1つのアプリケーション/基本的なデータベース構成/最低限の監視/目標レベル99.5〜99.9%)
- 成長に応じた3段階の拡張ステップを想定:
- ステップ1: まず最適化(クエリ最適化/インデックス追加/キャッシュ導入/N+1問題の解消)
- ステップ2: サーバー性能アップ(CPU/メモリの増強/スケールアウト)
- ステップ3: システム分割(マイクロサービス化/専門チームの配置)
- 多くの場合ステップ1〜2のみで十分対応できる
- 「今の規模」に最適化する文化を作る:
- 「最初から完璧」ではなく「必要になったら拡張」を原則とする
- 各段階のコスト対効果を明確にし拡張のタイミングを事前に合意
- 「早すぎる最適化」を避ける文化を醸成
- 成功企業の規模と自社の規模の違いを認識
■ 7. 対策3: "絶対に落とさない"に対してのコストに対して
- 「どれだけ止まっていいか」を経営判断として決める:
- 「止めない」ではなく「どこまで止まっていいかを最初に決めること」が重要
- 99.9%稼働率ということは月43分程度は止まる可能性があるということ
- 止まってはいけないということはリスクを取りづらくなるコストが存在する
- システム内で優先順位をつける:
- ユーザーが見る画面やクライアントが常に使っている機能については落ちづらくしておく
- 社内で使用する管理画面などは落ちても問題ないとする
- ユーザーやクライアントに直接影響する機能と社内でしか使わない管理機能を同じレベルで守る必要はない
■ 8. 結論
- エンジニアが個人として合理的に動いた結果事業が後退してしまうのは構造的なインセンティブの帰結
- 「うちのエンジニアは大丈夫」と慢心せずに対策していくことを推奨
- 最高なのは個人の合理性と組織の合理性を一致させること
- それを思わせるのが経営者の役割
- エンジニアと経営者が同じ方向を向いて判断できる組織は強い組織