「開発メンバーは毎日忙しく働いているのに、新機能のリリースが進まない」
このような状態に陥っている企業は少なくありません。エンジニアの能力や努力が不足しているとは限らず、実際には、障害対応や問い合わせ、データ修正、軽微な改修といった保守業務に開発リソースが吸収されている可能性があります。
ところが、保守対応は細かな作業に分散しやすく、通常のタスクとして処理されるため、どの程度のリソースを消費しているのか把握できていない企業もあります。その結果、「とにかく採用を増やそう」「開発会社を追加しよう」と対策したものの、状況がほとんど変わらないこともあります。
新規開発を止めている原因を判断するには、まず保守に使われている時間と、その影響を可視化することが必要です。
本記事では、開発・保守体制を見直す際に確認したい5つの指標を紹介します。
忙しいのに開発が進まない理由
開発部門の業務は、新機能の開発だけではありません。既存システムを安定稼働させるため、日々さまざまな対応が発生します。
- 利用部門からの問い合わせ
- 障害や不具合の調査
- データ修正や設定変更
- 法改正や外部サービス変更への対応
- 小規模な機能改修
- 定例作業や監視
- 古い仕様の調査
一つひとつは数十分から数時間で終わる作業でも、複数のシステムで毎日発生すると、大きな負担になります。さらに、予定していなかった対応が割り込むと、開発者は作業を中断し、状況を把握してから保守対応に切り替えなければなりません。対応後に元の開発へ戻る際にも、設計やコードの文脈を思い出す時間が必要です。
つまり、実際に保守作業へ使った時間だけでなく、作業の切り替えによる損失も発生します。これが「全員忙しいのに成果が増えない」状態を生みます。
指標1：保守工数比率
最初に確認したいのが、開発チームの総稼働時間に占める保守業務の割合です。
保守工数比率は、次のように算出できます。
保守業務に使った時間 ÷ 開発チームの総稼働時間 × 100
ここでいう保守業務には、障害対応だけでなく、問い合わせ、定例作業、調査、軽微な修正なども含めます。チケット管理されていない口頭依頼やチャットでの質問も、可能な範囲で記録することが重要です。
数値の高さだけで良し悪しを判断することはできません。安定稼働が特に重要なシステムでは、保守の比率が高くなることもあります。大切なのは、組織が想定している配分と実態が一致しているかどうかです。
新規開発を優先しているつもりなのに、実際には半分以上の時間が既存システムの維持に使われているなら、体制設計を見直す必要があります。
指標2：予定外作業の割り込み率
次に確認したいのが、計画外の作業がどれだけ発生しているかです。
スプリントや月次計画を立てても、緊急対応が何度も入れば、予定した開発は完了しません。計画時に登録されていなかったタスク数や工数を記録し、全体に占める割合を確認します。
割り込みが多い場合は、単に人員が足りないのではなく、次のような問題が隠れている可能性があります。
- 問い合わせ窓口が整理されていない
- 障害の再発防止ができていない
- システムの監視やテストが不足している
- 特定の担当者に質問が集中している
- 軽微な依頼の優先順位を判断するルールがない
割り込み率を把握すると、「増員が必要なのか」「受付方法や運用ルールを変えるべきなのか」を切り分けやすくなります。
指標3：開発バックログの滞留日数
新規開発や改善要望が、着手されないままどの程度残っているかも重要な指標です。
バックログの件数だけを見ると、優先度の低い要望が多いだけかもしれません。そこで、登録から着手までの日数や、優先度が高いにもかかわらず未着手になっている期間を確認します。
特に注意したいのは、顧客体験の改善、売上に関係する機能、業務効率化など、事業上の効果が期待できる開発が保守対応によって後回しになっているケースです。
技術部門では問題なくシステムを維持できているように見えても、事業部門から見ると、改善速度が落ちて競争力を失っている可能性があります。バックログの滞留日数は、保守負荷が事業へ与える影響を説明する材料になります。
指標4：同じ原因による再対応件数
似た問い合わせや障害に何度も対応している場合、保守業務が改善につながっていない可能性があります。
たとえば、毎月同じデータ修正が発生しているのに、原因となる入力処理は改修されていない。担当者が毎回手作業で対応している。この状態では、保守工数が継続的に発生します。
再対応件数を確認する際は、チケットの文言が完全に一致しているかではなく、原因や対応方法が同じかという観点で分類します。件数が多いものから、自動化、仕様変更、運用ルールの変更を検討します。
保守チームに改善時間が確保されていないと、目の前の依頼を処理するだけになりがちです。再発防止に使う時間を別枠で確保することも必要です。
指標5：特定担当者への依存率
最後に確認したいのが、保守タスクが特定の担当者へ偏っていないかです。
システムごとに、対応できる人の数、問い合わせ先、レビュー担当者を整理します。担当者が一人しかいない領域や、その人の承認がなければ作業が進まない領域は、休職・退職・異動によって停止するリスクがあります。
また、詳しい担当者へ相談が集中すると、その人は新規開発へ参加できなくなります。組織全体では十分な人数がいるように見えても、重要な知識が一人に偏っていることで、実質的なボトルネックが生まれます。
依存度を下げるには、単にマニュアルを作るだけでは不十分です。別の担当者が実際の保守作業を経験し、レビューを受けながら判断基準を学べる体制が必要です。
数値を取った後に判断すること
5つの指標を確認したら、保守業務を次のように分類します。
- 社内に残すべき重要な判断業務
- 手順を整備すれば他の担当者へ移せる業務
- 自動化できる定型業務
- 外部チームへ継続的に任せられる業務
- 廃止・統合を検討すべき業務
すべての保守を外部へ移す必要はありません。事業上の優先順位や顧客への影響を判断する役割は、社内に残した方がよい場合があります。一方、定型的な調査、テスト、軽微な改修、ドキュメント更新などは、外部チームと分担しやすい領域です。
重要なのは、忙しいから人数を増やすのではなく、どの業務に、どのような人材が必要なのかを整理することです。
外部開発チームを「保守の受け皿」にしない
外部チームを活用する際に注意したいのは、負担の大きい作業をそのまま丸投げしないことです。手順や優先順位が曖昧な状態では、委託先からの確認が増え、社内担当者の負担がかえって大きくなることがあります。
ラボ型開発などの継続的な外部チームを活用する場合は、小さな保守・改修から始め、実務を通じてシステムと業務知識を蓄積してもらう方法が現実的です。日本側の責任者が優先順位や品質基準を示し、外部チームが調査・実装・テストを担うことで、徐々に対応範囲を広げられます。
保守を安定して任せられるチームができれば、社内エンジニアは新規サービスや重要な改善へ時間を使いやすくなります。
まとめ
新規開発が進まないとき、すぐに採用や増員へ進むのではなく、まず保守業務によるリソースの圧迫を確認することが重要です。
確認したい指標は次の5つです。
- 保守工数比率
- 予定外作業の割り込み率
- 開発バックログの滞留日数
- 同じ原因による再対応件数
- 特定担当者への依存率
数値を可視化すると、採用、自動化、業務整理、外部チーム活用のどれを優先すべきか判断しやすくなります。