システム開発ライフサイクル（SDLC）へようこそ！
皆さん、こんにちは！情報マネジメントを学ぶ上で最も重要な章の一つへようこそ。企業が「新しい会計ソフトが必要だ」と考え始めてから、実際に毎日それを使うようになるまで、一体どのようなプロセスを経ているのか、不思議に思ったことはありませんか？ここでは、その仕組みを学びます。
システム開発ライフサイクル（SDLC：Systems Development Life Cycle）は、組織が高品質なシステムを構築するために従う、段階的な「ロードマップ」や「レシピ」のようなものです。家を建てることを想像してみてください。設計図もなしに、初日からいきなりレンガを積み始めることはありませんよね？まずは建築家に相談し、予算を確認し、図面を作成するはずです。SDLCは、ITシステム開発においてまさにそれと同じ役割を果たすのです！
SDLCとは？
SDLCは、情報システムを計画、作成、テスト、導入するために組織が使用する構造化されたプロセスです。公認会計士（CPA）を目指す皆さんにとって、このプロセスを理解することは非常に重要です。なぜなら、皆さんはプロジェクトに投資する価値があるかを判断する立場になったり、ITチームに対してシステムに必要な機能を伝える「エンドユーザー」の役割を担ったりすることが多いからです。
最初は難しく感じるかもしれませんが、大丈夫です！ 5つの明確なステップに分けて見ていきましょう。流れを覚えるための簡単な覚え方は、頭文字をとったP-A-D-I-Mです：
1. Planning（計画と実現可能性調査）
2. Analysis（分析）
3. Design（設計）
4. Implementation（導入・実装）
5. Maintenance（保守）
第1段階：システム計画と実現可能性調査（Planning）
これは「そもそも、やるべきか？」を決める段階です。多額の費用を投じる前に、そのプロジェクトが本当に理にかなっているかを確認する必要があります。
この段階で最も重要なのが実現可能性調査（Feasibility Study）です。プロジェクトが現実的かどうかを判断するために、TELOSというフレームワークを使います：
T - Technical（技術的）：それを構築するための技術やスキルはあるか？
E - Economic（経済的）：費用に対して利益が見込めるか？（CPAを目指す皆さんの腕の見せ所ですね！）
L - Legal（法的）：データのプライバシー法（香港のPDPOなど）を遵守しているか？
O - Operational（運用的）：スタッフは実際にそれを使うか、あるいは変化に抵抗するか？
S - Schedule（日程的）：期限内に完成させられるか？
クイックレビュー： プロジェクトが技術的には可能でも、コストが法外にかかるようであれば、経済的な実現可能性のテストで不合格となり、この段階で中止すべきです。
第2段階：システム分析（Analysis）
次に進むことが決まったら、「システムには具体的に何が必要なのか？」を考えます。
この段階でプロジェクトチームは、ステークホルダー（システムを利用する人たち）に話を聞き、要件（Requirements）を収集します。
例： 新しい給与計算システムを設計する場合、「分析」段階では人事チームに「どのようなレポートが必要か？MPF（強制積立年金）の計算は自動化すべきか？残業代の扱いはどうするか？」といったことを確認します。
避けるべきよくあるミス： この段階を飛ばしたり、急いだりすることです。今必要なものを定義しておかないと、結局ビジネスの役に立たないシステムが出来上がってしまいます。後から次々と要求が増えていくことは「要件クリープ（Requirement Creep）」と呼ばれ、プロジェクト失敗の原因となります！
第3段階：システム設計（Design）
分析段階で「システムが何をするか」を確認しました。設計段階では、それを「どう実現するか」を決めます。
ここでは「設計図」を作成します。内容は2つあります：
1. 論理設計（Logical Design）： 概念的な流れ。データがA地点からB地点へどう移動するか？
2. 物理設計（Physical Design）： 実際のハードウェア、ソフトウェア、データベースの仕様。どのサーバーを使うか？ユーザーインターフェース（画面）はどう見えるか？
例え話： 「分析」が「5人乗れて、速い車が欲しい」と言うことなら、「設計」はエンジン図面を描いたり、シートの革を選んだりすることです。
第4段階：システム導入（Implementation）
ここからは「実行」の段階です！プログラミングを行い、ハードウェアを購入し、実際にオフィスへシステムを導入します。
試験で非常に重要なのがシステム変換（System Conversion）（旧システムから新システムへの移行）です。これには4つの方法があります：
1. 直接移行（Direct Changeover）： 日曜日に旧システムを止め、月曜日に新システムを稼働させる。
リスク： 高い！新システムがクラッシュした場合、戻る場所がありません。
2. 並行稼働（Parallel Running）： 旧システムと新システムを一定期間、同時に運用する。
リスク： 低いですが、非常にコストがかかり、スタッフの作業量も2倍になります。
3. パイロット運用（Pilot Running）： まず一部の支店や部署だけで新システムを試す。
利点： 不具合が起きても、会社のごく小さな部分だけで済みます。
4. 段階的移行（Phased Conversion）： モジュールごとに導入する（例：まずは請求モジュール、次に在庫モジュール、といった順序）。
重要なポイント： 導入にはテストとユーザー教育も含まれます。従業員がログイン方法すら分からなければ、どんなに優れたシステムも無意味です！
第5段階：システム保守（Maintenance）
システムが稼働開始！ですが、仕事は終わりではありません。この段階は、システムが最終的に置き換えられるまで続く、最も長い期間です。
保守には以下の種類があります：
- 是正保守（Corrective）： テストで見つからなかったバグの修正。
- 適応保守（Adaptive）： 税法の変更など、外部環境の変化に伴うシステムの更新。
- 予防保守・機能改善（Perfective）： 壊れていなくても、システムをより速く、より良くするための改善。
豆知識： システムのライフサイクル全体にかかるコストの大部分は、構築段階ではなく、この保守段階で発生するんですよ！
クイックレビュー表
段階： 計画（Planning）
主な活動： 実現可能性調査（TELOS）
段階： 分析（Analysis）
主な活動： ユーザー要件の収集
段階： 設計（Design）
主な活動： 設計図の作成（論理設計・物理設計）
段階： 導入（Implementation）
主な活動： コーディング、テスト、システム変換（直接、並行など）
段階： 保守（Maintenance）
主な活動： バグ修正と法改正等への対応
成功のためのヒント
SDLCに関する試験問題を見たら、常に「今、プロセスのどこにいるのか？」を自分に問いかけてください。
- 予算という言葉があれば、計画（Planning）を考える。
- スタッフへのインタビューという言葉があれば、分析（Analysis）を考える。
- 初日にシステムが失敗するリスクといった記述があれば、導入（Implementation/変換）を考える。
これらの段階を練習し続ければ、すぐにこの分野をマスターできます！あなたなら大丈夫！