はじめに

はじめまして！26新卒の小寺です。 先日、システム開発の基礎についてハンズオンを交えて学ぶ研修を受けました。 本記事では、研修を通して学んだことを共有し、少しでもシステム開発について理解を深めていただければと思います！

情報システムとは？　〜開発工程を建築にたとえてみる〜

情報システムとは、私の言葉でまとめると 「人・物・金・情報」のデータを、入力→処理→出力して、実世界にフィードバックする仕組みです！
情報システム開発は、一般的に次の工程で進みます。

計画　→　要求分析　→　設計　→　プログラム開発　→　テスト　→（運用・保守）

これだけだとイメージが湧きにくいので、「家を建てること」に例えてみます。

工程 建築で言うと 情報システム開発で言うと
計画 街並みや家族構成に合わせて建築計画を立てる 企業を取り巻く環境・方針に基づき開発プロジェクトの全体計画を立てる
要求分析 外観・間取りなどユーザーの要望をまとめる 「要求」をどう新システムに反映するか検討し「要件」にまとめる
設計 建築設計図（建築図・構造図・設備図）を作る 要件をどう実現するか、外部設計・内部設計で決める
プログラム開発 設計図に基づき工事に着手する プログラム仕様書に基づきプログラムを作成する
テスト 引渡し前に作業過程と結果を検証する 機能・性能を満たしているか検証する
運用 電気・ガス・水道などを使い快適に過ごす 稼動開始時と同等のサービスを提供し続け、安定稼動を図る
保守 経年劣化の修理や台風・地震への補強をする 潜在的な不具合の修正や、問題が顕在化する前の予防を行う

余談ですが、 「要求」と「要件」ってなんとなく同じ意味に聞こえませんか？私は最初混同していました。 研修では「要求＝ユーザー側からの要望」「要件＝要求をシステム的に解決する方法」と定義していて、 ここをしっかり区別して議論できるようになると、開発チームやクライアントとのコミュニケーションがグッとスムーズになると感じました！

情報システム開発は「与えられた条件（機能・性能・期限・費用）で目標を実現する、具体的な方法や手順を作る作業」とも言えます。 この条件の解釈が開発側とユーザー側でズレると、完成後の評価が食い違ってしまうので、できるだけ数値化した尺度で合意しておくことが大切だそうです。

ソフトウェアの品質ってどう決まるの？

「品質が良い／悪い」って感覚的に語られがちですが、実はJIS（日本産業規格）で定義されています。
JIS X 25010:2013 では、ソフトウェア品質を次の8つの特性に分類しています。

  • 機能適合性（必要な機能を過不足なく提供できているか）
  • 性能効率性（限られた資源でどれだけ効率よく動くか）
  • 互換性（他の製品やシステムと情報をやり取りできるか）
  • 使用性（ユーザーが迷わず使えるか）
  • 信頼性（決まった条件下で安定して動作し続けられるか）
  • セキュリティ（権限に応じたデータアクセスを守れているか）
  • 保守性（修正のしやすさ）
  • 移植性（別の環境に移しやすいか）

「バグがない」だけが品質ではなく、使いやすさや移しやすさまで含めて品質、というのが新鮮でした。

情報システム開発の課題と、文書化の大切さ

研修では、開発現場でよく起きる課題として次の4つが挙げられていました。

  • 人材不足／育成が追いつかない
  • 情報過多（メール、資料、書籍…何が公式な情報かわからなくなる）
  • 文書の散在（どれが最新版かわからない）
  • 進捗が不明（作業内容が見える化されていない）

これらの課題は、文書化を徹底することである程度防げるそうです。
標準の文書形式を用意すれば経験の浅いメンバーでも一定水準の成果物が作れますし、版管理を徹底すれば最新版もひと目でわかります。地味に思えて、実はかなり効果的な対策だなと感じました。

代表的な開発手法を4つ紹介

情報システムの開発工程を標準的な手順としてモデル化したものが「開発手法」です。代表的な4つを紹介します。

  1. ウォーターフォール型開発
    要求分析→設計→プログラム開発→テストの順に、後戻りせず進める最も伝統的なモデル。各工程の成果物が次工程の出発点になるため、全体をしっかり把握し、工程ごとの作業をしっかり定義して進める必要があります。上流工程が曖昧なまま進めて下流で不具合が出ると、大きな手戻りになってしまうのが弱点です。
  2. プロトタイピング型開発
    プロトタイピング型開発とは、試作品（プロトタイプ）を早い段階で作り、設計や機能の妥当性を検証する手法です。大きく二つのタイプがあります。
    1. 使い捨て型：要求分析の一部としてユーザー確認を取り、プロトタイプ自体は使わずに捨てる
    2. 進化型：作ったプロトタイプに機能を足していき、そのまま本稼働のプログラムにする
  3. アジャイル型開発
    優先順位の高いものから計画・実行・移行を繰り返しながら進める手法。不確定要素が多く綿密な計画が立てづらい場合や、成果を小出しにする意義がある場合（例：モバイルアプリの新サービス）に向いています。変化が激しく予測が難しいプロダクト開発において、変更に柔軟に対応できる手法として採用が増えているそうです。
  4. 反復型開発（イテラティブ型）
    最初に基本部分を決め、サイクルごとに目標設定→評価を繰り返しながら完成品に近づけていく手法。進化型プロトタイピングを反復型で進めるケースもあります。

「結局どれを使えばいいの？」と思ったのですが、正解は一つではなく、システム化する対象の特性（不確定要素の多さ、規模、納期など）に応じて選ぶものだそうです。適材適所、大事ですね。

データの正規化（要求分析の一部）

要求分析でデータ・ストアにデータ項目を追加するときは、データの持ち方を整理する「正規化」を行います。目的はデータの独立性を保ち、更新・追加・削除をしても矛盾が起きないようにすることです。

正規化は次の3ステップで進めます。

  1. 第1正規化：繰り返しグループを分離し、キーを決めて、元のグループのキーと連結する
  2. 第2正規化：連結キーを構成する部分キーに従属する項目を分離し、元のグループのキーはそのまま残す
  3. 第3正規化：非キー項目に従属する項目を分離し、分離したグループのキーを決め、元のグループのキーは残す

たとえば「受注伝票」のような非正規形のデータを分解していくと、最終的に「受注」「明細」「商品」「得意先」というテーブルに分かれていきます。それぞれの工程で必ず「元のグループのキーを残す」ことで、分離後もテーブル同士のつながりが保たれる、という考え方がポイントでした。

設計工程 〜外部設計と内部設計〜

「設計」は2つの工程からできています。

  • 外部設計：要求分析の結果を受けて、ユーザーから見える部分を設計します。新業務フローの作成、ウィンドウなどのユーザーインターフェース設計、データベース設計が含まれます。
  • 内部設計：外部設計の結果を受けて、開発者から見た設計を行います。システム機能を「源泉（入力）」「変換（処理）」「吸収（出力）」に分類・分割しながらプログラム単位、さらにモジュール単位まで落とし込み、プログラム仕様書を作成します。

外部から見える部分と、開発者しか意識しない内部の作りを分けて考える、という視点がわかりやすかったです。

プログラム開発とテストの流れ

プログラムは長期間にわたり複数人が保守する重要な資産なので、開発には次の準備が必要です。

  • プログラミング標準化ガイドの用意
  • 再利用可能なソフトウェア部品の準備（著作権/使用権の確認は必須）
  • 開発用ハードウェア／ソフトウェアの確保

テストは工程が進むごとに範囲が広がっていきます。

  • 単体テスト：プログラム仕様書通りに動くか、処理ロジックに着目して検証（ホワイトボックステストが中心）
  • 結合テスト：単体テスト済みのプログラム同士のインターフェースを検証
  • システムテスト：情報システムが要求品質を満たしているか、本稼動に近い環境で検証
  • 運用テスト：本稼動時の運用が可能か、ユーザーへの引渡しが可能かを検証

単体テストでは処理ロジックに着目する「ホワイトボックステスト」、
結合テスト以降では入力に対する出力結果だけに着目する「ブラックボックステスト」が使われる、という使い分けも研修で初めて知ることができました。

移行作業とサービスイン基準

本稼動への移行は限られた時間で行うことが多いため、事前準備と当日作業を分けて計画します。

  • 業務の移行：新業務処理の解説書・操作手順書の用意、必要に応じたユーザー研修
  • 運用の移行：運用手順書の用意と、それに沿った運用テスト
  • 現行システムへの復帰手順：移行失敗時に備えた切り戻し手順
  • システム／データの移行：ハードウェア・ソフトウェア・ネットワークの整備、データ変換

そして、本稼動を開始してよいかを判断する基準が「サービスイン基準」です。

  • ユーザーと合意した機能要件
  • 品質要件を満たしていること
  • ユーザー／運用部門の受け入れ体制ができていること
  • 移行作業が完了していること

これらを事前に数値化しておき、基準を満たしていれば承認、満たしていない場合は判定者や会議体が最終的な可否を判断する、という進め方でした。「なんとなく OK」という曖昧な判断で本稼動へ進めないための重要な仕組みだと感じました。

プロジェクト管理の基本

最後に、開発を支えるプロジェクト管理についても触れておきます。
PMBOK（Project Management Body of Knowledge／米国PMIの登録商標）では、プロジェクトを「独自のプロダクト、サービス、所産を創造するために実施される有期的な業務」と定義しています。定常業務と違い、開始と終了が決まっていて、終了時に付加価値のあるものを生み出す点が特徴です。

プロジェクト管理の目的は、品質（Quality）・コスト（Cost）・納期（Delivery）＝QCD を、計画（P）・実施（D）・評価（C）・改善（A）のサイクルで管理することです。
具体的には、こんな管理が行われます。

  • 品質管理：工程完了時の公式レビュー、随時行う非公式レビュー、各テスト工程での品質検証
  • スケジュール管理：マスター・スケジュールを作成し、遅れがどこに波及するかを見極める
  • 進捗・コスト管理：マスター・スケジュールを細分化したWBS（Work Breakdown Structure）を作成し、担当者・開始/終了予定日・工数を管理する

プロジェクトコストにおいて人件費の比率は高いため、作業の平準化が重要です。計画的なリソース管理が不可欠だと学びました。

さいごに

私なりに研修の内容を噛み砕いて要点をまとめられたと思います！
情報システム開発は「計画→要求分析→設計→プログラム開発→テスト」という工程の流れだけでなく、品質の考え方やプロジェクト管理まで含めて理解して初めて全体像がつかめるのだと実感しました。
これからは、この知識をベースに実際の開発業務やシステム設計に活かしていけるようになりたいです。
このブログが少しでも同じように学び始めた方の役に立てば嬉しいです！