はじめに
情シスに配属されたばかりの方や、他部署からDX推進部門へ異動してプロジェクトに関わることになった皆さん。 「システム開発って、一体何から始めればいいの？」と戸惑っていませんか？
「システム開発＝黒い画面に向かって、ひたすらカタカタとプログラムを書き始める」 そんなイメージを持っている方も多いかもしれません。
しかし、実際の情シスやDXの現場では、「急にプログラムを書き始める」ということは実はとても少ないのです。（事業部の担当者が、自分の業務効率化のためにちょっとしたVBAやノーコードツールを触るのとはワケが違います）
この記事では、事業会社でシステムを構築・運用していくための「正攻法のシステム開発の流れ」と、知っておきたい「現場のリアル」をステップバイステップで解説します。
システム開発の基本フロー
一般的なシステム開発（ウォーターフォール型）は、以下のようなステップで進んでいきます。
- 要件定義（何を作るか決める）
- 基本設計（画面など外側を決める）
- 詳細設計（内部の処理を決める）
- DBオブジェクト準備（データの箱を用意する）
- コーディング（実際にプログラムを書く）
- 単体テスト（機能ごとに動くか確認する）
- 結合テスト（繋げて動くか確認する）
- ユーザ受け入れテスト（UAT）（現場に使ってもらう）
- リリース（本番運用開始！）
重要なのは、「前の工程がしっかり完了していないと、次の工程には進めない」という点です。それぞれの工程で一体何をしているのか、現場のリアルな実態を交えながら詳しく見ていきましょう。
要件定義：ここが全て！システム開発の「最重要フェーズ」
システム開発において、1番重要なのがこの「要件定義」です。ここでみっちり議論を重ねておかないと、後工程で全て破綻して最初からやり直し…という大惨事を招きます。
要件定義では、大きく分けて「機能要件」と「非機能要件」の2つを決めます。
- 機能要件： そのシステムで「何ができるか」（例：バーコードを読み取って在庫を減らす、月次レポートをPDFで出力するなど）
- 非機能要件： 性能や使い勝手などの「裏側の条件」
初心者の方には「非機能要件」がイメージしづらいと思うので、実例を挙げます。 例えば、「そのシステムは、同時に何人が使うのか？」という視点です。 「部署内の3人が順番に使うシステム」なのか、「工場の全従業員500人が、始業時間の8時ぴったりに一斉にアクセスするシステム」なのかで、必要なサーバーのスペックやネットワークの設計は全く変わってきます。ここを見落とすと、「リリースした途端にシステムがフリーズして現場がストップする」という恐ろしい事態になります。
【超重要】「現場の要望」をそのまま鵜呑みにしてはいけない！
要件定義において、情シス・DX担当者が陥りがちな最大の罠があります。それは、「現場のユーザーの要望を、言われた通りそのままシステム化してしまうこと」です。
現場から「今のExcel管理表と全く同じ画面のシステムを作ってよ」と言われることは多々あります。しかし、それをそのままシステム化するのは危険です。 なぜなら、そのExcel表自体が「昔からなんとなく継ぎ足しで使われている、非効率な業務フローの産物」である可能性が高いからです。
私たちの仕事は、言われたものを作ることではありません。 「なぜその機能が必要なのか？」「本来の目的は何か？」を深掘りし、時には業務フローそのものの見直し（BPR）を提案することが、情シスやDX推進の本当の価値なのです。
設計（基本設計・詳細設計）と「ドキュメント」の意義
要件が固まったら、次はいよいよ「設計」に入ります。
- 基本設計： ユーザーから見える部分の設計です。画面のレイアウト、クリックした時の画面遷移、帳票の出力イメージなどを決めます。
- 詳細設計： 開発者向けの設計です。プログラムの内部でどういう計算をするか、データをどう処理するかなど、専門的なドキュメントを作成します。
なぜ面倒な「設計書」を残す必要があるのか？
「動くシステムができれば、設計書なんていらなくない？」と思うかもしれません。しかし、これには明確な理由があります。
メーカーで導入したシステムは、5年、10年と長く稼働し続けます。 数年後、システムを改修したいとなった時、当時の開発者（あなた）が別の部署へ異動していたり、退職している可能性は十分にあります。設計書（ドキュメント）がないシステムは、中身がブラックボックス化し、誰も手出しができない「負の遺産」になってしまうのです。
後任者や保守を引き継ぐ外部ベンダーのためにも、「未来への引き継ぎ資料」としてドキュメントを残すことは、プロとして必須の仕事です。
DB（データベース）オブジェクト準備
システムの設計図ができたら、データを入れるための「箱（データベース）」を準備します。 データモデル設計に応じて、必要なテーブルや項目（カラム）を作成していきます。場合によっては、データベースサーバーそのもののセットアップ（OSのインストールやネットワーク設定など）から情シスが手を動かすこともあります。
コーディング（プログラミング）
ここまできて、ようやく皆さんがイメージする「プログラミング」の登場です！ 詳細設計書に従って、ゴリゴリとコードを書いていきます。
実は、これまでの「要件定義」と「設計」の工程をしっかりやっていれば、コーディングは何も迷うことなく、ただ手を動かすだけの作業になる（のが理想）です。「コードを書きながら考える」状態になっているとしたら、それは設計が甘い証拠だと言えます。
テスト（単体テスト・結合テスト）
プログラムが書き上がったら、徹底的にテストを行います。
- 単体テスト： ボタンを押したら正しい計算結果が出るかなど、一つ一つの機能が正常に動くかを確認します。
- 結合テスト： 画面から画面へのデータ引き継ぎや、他の既存システムとの連携が問題なく行えるかを確認します。
ここでのリアルな鉄則は「手順と証跡（エビデンス）を必ず残すこと」です。 画面のスクリーンショットやテストデータのログを残しておくことで、万が一リリース後にバグが発覚した際に「テスト時は正常だったか、それともテスト漏れだったのか」を切り分ける重要な命綱になります。
ユーザ受け入れテスト（UAT）
情シス側でのテストが終わったら、次は「実際に使う現場のユーザー」に触ってもらいます。これをUAT（User Acceptance Test）と呼びます。
現場のユーザーは、普段の業務で忙しい中テストに協力してくれます。「とりあえず触ってみてください」と丸投げするのではなく、情シス側から「今回はこの業務フローを想定して、このような手順（シナリオ）で入力してみてください」というテスト手順書を提示してあげるのが、スムーズに進めるための優しさでありコツです。
リリース
すべてのテストをクリアしたら、いよいよ「リリース（本番公開）」です！
使用するサーバーやツールによって具体的な作業は異なりますが、ざっくり言うと「決められた場所に完成したプログラムを配置し、ユーザーにシステムの入り口（URLなど）を案内すること」です。
しかし、リリースして終わりではありません。「今日から使えます」という案内だけでなく、「旧システムからの切り替えタイミング」「万が一トラブルが起きた時の連絡先や運用ルール」までしっかり周知徹底して、初めてシステム開発の1つのサイクルが完了します。
まとめ
いかがでしたでしょうか。システム開発は、コードを書いている時間よりも、その前後の「準備・確認・調整」の時間が圧倒的に長いということがお分かりいただけたかと思います。
特に、情シスやDX部門としてプロジェクトに関わる方は、「現場の御用聞きにならず、本質的な要件を定義すること」をぜひ意識してみてください。
最初は覚える工程が多くて大変かもしれませんが、自分が関わったシステムが現場で動き出し、業務が劇的に楽になる瞬間は、何度経験しても最高の達成感があります。一つ一つのプロセスを大切にして、より良いシステム作りを目指していきましょう！
コメント