システム開発ライフサイクルという言葉は、調べると「企画・設計・開発・テスト・運用」といった工程の一覧が出てきます。意味としてはそれで合っているのですが、発注する側が本当に知りたいのは別のことだと思います。このシステムは何年使うのか、次に大きなお金が出るのはいつか、そのとき誰が判断するのか。
先に数字をひとつ挙げておきます。税務上、ソフトウェアの耐用年数は原則5年です。つまり会計上は5年で価値がゼロになる資産で、更改を考え始める議論はこの5年を起点にすることが多いです。5年で必ず作り替えるという話ではありませんが、社内で説明するときの共通の目安になります。
この記事では、システム開発ライフサイクルを企画から廃止までの5段階で区切り、各段階で発注側が何を決めるのか、お金がいつどれだけ出るのかを整理します。工程の中身そのものより、時間軸とお金の話に寄せています。
この記事のポイント
- ライフサイクルは企画・開発・運用・更改・廃止の5段階で見る
- 税務上の耐用年数は原則5年で、更改の議論はここが起点になる
- 期間の大半は運用で、費用も長期では運用側が積み上がる
- 更改と廃止にもお金がかかるので、初期費用だけで判断しない
目次
システム開発ライフサイクルの5つの段階
まず区切り方です。工程を細かく分ける流派はいろいろありますが、発注側の意思決定という観点だと5つで足ります。
企画：作るかどうかを決める段階
最初の段階は、そもそも作るのかを決めるところです。ここで決まるのは目的と予算枠で、判断するのはたいてい経営です。情シスが動くのはその後です。
見落とされやすいのですが、この段階の正しい結論には「作らない」も入ります。既製のパッケージやSaaSで足りるなら、開発しないほうが一生分の費用は軽くなります。企画の段階で作ることが前提になっていると、後戻りできなくなります。
作らないほうがいいかを見分ける目安は3つです。やりたいことが業界で一般的な業務か（一般的なら既製品がある）、自社独自のやり方が競争力になっているか（なっていないなら合わせたほうが安い）、そして5年後も同じ業務が続く見込みがあるか。3つとも「いいえ」に近いなら、開発より導入を先に検討したほうが一生分の費用は軽くなります。
開発：要件定義から検収まで
次が開発です。要件定義、設計、製造、テスト、検収と進みます。工程の区切りと現場で使われる略語についてはシステム開発の工程と流れ・略称と工程表の見方で詳しく扱っているので、ここでは深入りしません。
ライフサイクルという視点で押さえておきたいのは、この段階に発注側が承認する場所が3つあるということです。要件定義書、設計書、そして検収。この3つはいずれも後戻りの費用が跳ね上がる境目なので、日程に余裕を入れておきます。
期間の感覚としては、小規模なら数か月、中規模で半年から1年程度が目安になります。ただ一生の長さで見ると、この開発期間はかなり短い部分です。
運用：動かし続ける段階
稼働してからが運用です。5段階のうち、時間をいちばん使うのがここです。5年使うシステムなら、開発が半年で運用が4年半という比率になります。
この段階で発注側に残る作業は、監視や障害対応を委託していても消えません。アカウントの発行と権限の承認、マスタの正しさの担保、業務ルールが変わったときの判断は自社側に残ります。どこまでを委託してどこから自社かの線引きはシステム開発の運用保守の委託範囲と自社に残る役割にまとめてあります。
時間の比率を数字にすると分かりやすくなります。開発6か月、運用4年6か月というシステムなら、一生のうち開発期間は1割で、残り9割が運用です。ところが社内の関心は開発期間に集中しがちで、稼働してからの4年半について事前に議論されることはあまりありません。
ここで大事なのは、運用が長いということは、運用の費用が長期の合計に効くということです。初期費用の比較だけで発注先を決めると、この部分を織り込み損ねます。
更改：作り替えを判断する段階
使い続けているうちに、業務のほうが変わります。追加開発で足していくうちに構造が複雑になり、直すたびに費用が上がってくる。そのあたりで更改の話が出ます。
判断が遅れるほど選択肢は減ります。作った会社の担当者が異動していて中身が分かる人がいない、使っている技術が古くて対応できる会社が限られる、といった状態になると、実質的に選べる相手が1社になります。更改そのものの進め方は基幹システムのリプレイスの進め方と発注側の判断基準を見てください。
私の感覚では、更改は「壊れたから」ではなく「業務が変わったから」やるほうが結果的に安く済みます。壊れてからだと、期限が先に決まってしまうので交渉の余地がありません。
廃止：止めてデータを残す段階
意外と語られないのが最後の段階です。システムを止めるときにも作業とお金が発生します。
やることは主に4つです。法令や社内規程で保存が必要なデータを取り出して残す、参照だけできる状態をいつまで維持するかを決める、停止の作業と関係先への周知、そしてライセンスやクラウド契約の解約です。契約が年単位だと、止めた月からすぐ費用が消えるわけではありません。
5段階を1枚にまとめておきます。
| 段階 | 主に決める人 | 発注側の作業 | お金の出方 |
|---|---|---|---|
| 企画 | 経営 | 目的と予算枠を決める、作らない判断も含める | 調査や相談の費用のみ |
| 開発 | 情シスと業務部門 | 要件定義書・設計書・検収の3か所を承認する | 初期費用がまとまって出る |
| 運用 | 情シス | 権限の承認、マスタ管理、業務変更の判断 | 月額または年額が続く |
| 更改 | 経営 | 続けるか作り替えるかを判断する | 再び初期費用が出る |
| 廃止 | 情シスと管理部門 | データの退避、停止の周知、契約の解約 | 退避と維持の費用が出る |
システム開発ライフサイクルで費用が出るタイミング
ここからがお金の話です。段階ごとに出方が違うので、年単位で並べたほうが判断しやすくなります。
システムは何年使うのか
「何年使うのか」に一番はっきり答えてくれるのは、実は税務の基準です。国税庁のタックスアンサーでは、ソフトウェアの耐用年数について「複写して販売するための原本または研究開発用のものについては、3年」「その他のものについては、5年」とされています（根拠は耐令別表第三、第六）。
自社で使うために作ったシステムは、この「その他のもの」として扱われるのが一般的です。ただしページに自社利用を名指しした記載はないので、実際の会計処理は税理士に確認してください。詳しい区分は国税庁のソフトウエアの取得価額と耐用年数で確認できます。
ここから逆算すると、5年で償却が終わるので、6年目以降は帳簿上の価値がない資産を使い続けることになります。だから更改の議論は5年を起点に始めるのが自然です。念のため書いておくと、5年経ったら作り替えるべきという話ではありません。業務に合っていて安定しているなら、8年でも10年でも使います。あくまで社内で話を始めるときの共通の目安です。
もう1つ、5年という区切りが効く場面があります。補助金や社内の設備投資計画は、償却期間に合わせて組まれることが多いためです。更改を6年目に置くと、前のシステムの償却が終わっているので、会計上は新しい投資として説明しやすくなります。逆に3年で作り替えると、まだ残っている資産を捨てることになるので、社内の説明が一段難しくなります。
初期費用と月額のどちらが重いか
費用の話をするとき、たいてい初期費用だけが比較されます。ところが一生分で見ると、比率が変わります。
年間の保守運用費は、初期費用の1割から1割半くらいという目安がよく使われます。あくまで一般的な目安なので、実際の判断は個別の見積もりで確認してください。この目安で計算すると、初期費用1,000万円なら年100万〜150万円で、5年で500万〜750万円です。初期費用の半分から4分の3が、運用でもう一度出ていく計算になります。
この構造が分かっていると、見積もりの比べ方が変わります。初期費用が200万円安いA社と、年間の保守費が60万円安いB社なら、5年ではB社のほうが安く済みます。逆に3年で作り替える前提ならA社です。何年使うつもりかを決めてから比べる、という順番になります。
更改の費用は前回と同じにならない
更改の予算を組むとき、前回の金額を根拠にするとまず足りません。理由は3つあります。
- データ移行の作業が乗る。前回は移行元がなかったが、今回は数年分のデータがある
- 並行稼働の期間が必要になる。新旧を同時に動かす分の費用と現場の負荷が出る
- 業務のほうが変わっている。同じものを作り直すのではなく、今の業務に合わせる分が増える
つまり2回目のほうが条件は重くなります。前回1,000万円だったから今回も1,000万円という見立てで稟議を出すと、途中で追加の相談が必要になります。
廃止にもお金がかかる
最後の段階も予算に入れておきます。金額はシステムの性質で大きく変わりますが、抜けやすい項目は決まっています。
廃止のときに費用が出る項目
- 保存義務のあるデータの抽出と、読める形式での保管
- 参照専用の環境を残す場合の、その期間の維持費
- 停止の作業と、関係先やユーザーへの周知
- ライセンスやクラウド契約の解約手続きと、残りの契約期間
とくに契約の残期間は見落としがちです。年契約の途中で止めても、残りの月数分は払うことになるケースがあります。更改の日程を決めるときは、契約の更新月を確認してから逆算すると無駄が出ません。
ここまでを踏まえて自社の予算を組むなら、見積もりの前提や対象外の範囲がそろっているかを先に点検しておくと、年単位の比較が成り立ちます。システム開発見積もりチェックシート（危険サインを見抜く60項目）で、抜けやすい項目を確認できます。
- Q. SDLCとシステム開発ライフサイクルは同じものですか？
- A. ほぼ同じ意味で使われます。SDLCはSoftware Development Life Cycleの略で、日本語ではシステム開発ライフサイクルやソフトウェア開発ライフサイクルと訳されます。ただしSDLCという言葉は開発工程の管理手法を指す文脈で使われることが多く、運用より後の更改や廃止まで含めて語られることは少ないです。
- Q. ライフサイクルの段階は4つと書かれている記事もあります。何が正しいですか？
- A. どれも間違いではありません。分け方は目的によって変わり、開発工程を細かく見る場合は6段階や7段階になります。この記事で5つにしているのは、発注側が判断を下す場所で区切ったためです。自社で使う場合は、決裁が必要になる区切りに合わせて分けるのが実務的です。
- Q. 何年で更改するのが普通ですか？
- A. 税務上の耐用年数が原則5年なので5年が起点になりますが、実際には業務との合致と保守の継続性で決まります。業務が変わっていなくて安定して動いているなら、それより長く使う会社も珍しくありません。逆に業務の変更が続いているなら、5年より早く限界が来ます。
- Q. クラウドで作ると、ライフサイクルの考え方は変わりますか？
- A. 段階の分け方は変わりませんが、お金の出方が変わります。初期費用が下がって月額が長く続く形になるため、一生分の合計で比べる必要がより強くなります。また使っているサービス側の仕様変更やサポート終了が更改のきっかけになることがあり、更改の時期を自社だけで決めにくくなります。
