社内向けソフトウェアの案件が一日で崩れることはまずありません。少しずつずれていきます。納期が数週間延び、範囲が数機能ふくらみ、業務担当者が別件で忙しくなり、ある日から誰も話題にしなくなる。以下の六つの原因は会社を問わず繰り返し現れ、いずれも早く気づけば防げます。
1. 最終決定者がいない
最大の原因です。部署ごとに業務の理解が違うとき、開発側が代わりに選ぶことはできません。結果として待つことになり、悪くすると両方の方式を作り、運用時に利用者へ選ばせることになります。
防ぎ方：業務上の決定者をひとり指名します。ある部署が納得しなくても「この方式で行く」と言える権限を持つ人です。その名前を案件文書に書き、「経営会議」を既定値にしないこと。
2. 範囲を成果ではなく機能名で書いている
「画面50本」という一覧は明確に見えて、測れません。検収の場では、業務が回るかどうかではなく、画面が完成しているかどうかの議論になります。
防ぎ方：範囲は業務の文章で書きます。たとえば「経理が支払申請を起票でき、二段階の承認を経て、仕入先別の債務一覧を出力できる」。検収は、その文章どおりを実データで動かすことです。
3. 実際の利用者が終盤にしか登場しない
入力を担当する人が検収で初めてシステムを見るなら、大きくて遅い指摘がほぼ確実に出ます。必須項目の不足、操作手数の多さ、よくある状況に対応できないなど。
防ぎ方：粗い画面ができた時点から、短い周期で実際の利用者に触ってもらいます。早い指摘は、正しいが遅い指摘よりはるかに安上がりです。
4. 例外業務を最後に回す
例外はどの会社にもあります。与信限度を超える承認が許される特定顧客、一部返品、案件コード発行前に締結した契約など。これらは実データでの試験になって初めて表に出ることが多く、ひとつが構造の変更を招くこともあります。
防ぎ方：分析段階で直接尋ねます。「先月、手順どおりに処理できなかった案件はありましたか」。そして頻度の高い例外から先に作ります。
5. 旧データを小さな作業とみなす
データ移行を最終週に置く計画をよく見ます。実際には旧データは想定より汚れており、突合には何往復も必要です。数字が合わない間は、正しく動くシステムでも使えません。表示される数字を誰も信用しないからです。
防ぎ方：構造が固まった時点で移行の試行を始め、繰り返し実行し、稼働前に一致の基準を明文化します。
6. 引き渡し後の持ち主がいない
案件が終わり、導入チームが去り、社内には日々の質問に答えたり小さな変更を決めたりする責任者がいない。システムは現実からずれていき、利用者は静かに表計算へ戻ります。
防ぎ方：着手前にシステムの持ち主を決め、全期間を通して参加してもらい、小さな変更のための年度予算を確保します。
早期の警告サイン
ずれ始めた案件は、順調な案件より静かなものです。質問が減ったことは吉報ではありません。
気にすべき三つの兆候です。
- 進捗会議の話題が、業務の中身から納期の調整に移る。
- 序盤はほとんどなかった変更要望が、終盤になって増え続ける。
- 業務担当者が二回続けて打合せを欠席する。
リスクを下げる簡単な方法
数週間で実業務に載る大きさまで、案件を分割することです。実業務へ出すたびに検証になります。使われているか、数字は合うか、手数は減ったか。すでに本番で動いている小さな塊の集まりは、全体が失敗しにくくなります。価値が早い段階で届いているからです。
