システムエンジニア、プログラマーを目指している、または就職、転職した方へ、システム開発とはどのような業務、内容で、どのような工程があるのか、最初に覚えるべき概要と工程を紹介します。
システム開発を良く知らない方、各工程の内容、成果物を良く知らない方向けの内容です。
システム開発の概要
システムとは、複数の要素をつなげたり、まとめたりして一定の機能を満たすものです。
全てコンピューターに任せて完結するものではなく、組織や人、モノなどを組み合わせて業務を改善、最適化します。
一般にシステム開発というと、パソコン (サーバーやネットワーク含む) やプログラミング言語を駆使してパソコンやタブレット等で動くアプリケーションを開発するイメージがあると思いますが、実際には、会社や組織 (役職者などのえらい人も) を巻き込んで業務を改善していくことになります。
システムの種類としては、店舗などで使用する「販売管理システム」から、会社内で使用する「人事給与システム」、「ネットショップ (EC サイト)」、「動画配信システム」など様々で、同じシステムでも会社により管理する項目や業務内容も異なるため数えきれないほどのシステムが存在します。
システム開発の流れ
システム開発の大まかな流れを説明します。
初めのうちは関わらない部分も多いので、なんとなく覚えておけば良いと思います。
ここでは比較的大きなシステム開発で使用される手法 (ウォーターフォールモデル) を想定していますが、場所によっては異なる手法を使用しているところもあります。
※ 手法については、別の機会に作成する予定です。
法律等で決まっているものではないので、記載する内容は明確に定義されているものではありません。
これから関わっていく場所、システムで大きく異なる場合もありますので、参考程度と思ってください。
要求定義
システム化を依頼する企業側が、システム化したい業務などを定義します。
依頼側がどのような業務を改善・効率化したいかを認識するための工程で、開発側が関わることはあまりありません。
要件定義と間違えやすいですが、「要求定義は依頼側」、「要件定義は開発側」が実施します。
成果物
RFP (Request for Proposal ： 提案依頼書) や、RFI (Request for Information ： 情報提供依頼書) といった資料が作成されることがありますが、初級エンジニアやプログラマーが見る機会はほとんどありません。
要件定義
依頼側からの要望をもとに、開発側が実現可能な内容を提案し、最終的にシステム化の範囲、内容を要件としてまとめます。
また、セキュリティ面や性能面などの要件も明確化します。
この工程では、依頼側の要望を正しく認識、整理して実現可能な方法を提案する必要があるため、開発側に高度な知識と理解力、コミュニケーション力が必要となります。
特に依頼側の業務を正しく理解していかないと、依頼側の要望を間違えて理解し、正しい要件をまとめることができません。
成果物
成果物としては、要件定義書という書類が作成されます。
依頼側に要望が満たされているか確認するため、開発側の専門用語ではなく、専門的な知識がなくても理解できる記載が必要です。
基本設計
要件定義で作成した資料をもとに、作成するシステムの全体を設計します。
システムの全体像となるため、どのような構成でシステムを作成し、依頼側がどのように関わるか、最終的な完成形を想定して設計する必要があります。
ここまでの工程で開発側の作成する内容がほぼ確定するため、以降の工程では依頼側と開発側で時間をかけた打合せが減少します。
依頼側、開発側の双方で認識のずれが無いよう、できる限り明確な資料の作成が要求されます。
成果物
成果物は、「業務フロー、画面レイアウト、帳票レイアウト」などの依頼側業務に直接かかわる資料のほかに、「システム (ハードウェア、ソフトウェア、ネットワーク等) 構成図、テーブル定義 (データベース)、バッチ処理設計」などの主に開発側で作成するシステムの構成資料、外部システムと連携する場合は「外部システム関連図、外部 IF (インターフェイス) 設計書」など外部システムと連携するための資料を作成します。
詳細設計
基本設計で作成した資料をもとに、機器の設定方法やプログラム作成用の細かな内容を設計します。
主に開発側のみで実施され、かつ専門的な内容が多いため依頼側が関与することはあまりありません。
ただ、依頼側でも情報システム部門などの担当者であれば理解することは可能なので、随時成果物を確認することもあります。
成果物
成果物は、「画面設計書、帳票設計書、クラス図、モジュール図、シーケンス図」など、実際に実装するために必要な資料で、詳細設計を見れば製造可能となるくらいの資料となります。
※ 画面設計書、帳票設計書には「文字や日付の入力チェック」や「データベース登録・取得項目」など、細かい処理も記述します。
製造、開発
詳細設計書をもとに実際にプログラムの作成や機器を設定します。
詳細設計書の記述通りに作成するため、業務面での知識はあまり必要なく、プログラミングの知識があれば作業可能です。
ただし、詳細設計から担当する場合も多く、プログラム初心者がいきなり担当することはあまりありません。
成果物
成果物は「プログラム」となります。
作成単位は各画面や帳票、モジュール単位 (大体は設計書の単位) になります。
また、担当者はプログラムの記述だけではなく、細かい動作確認までが作業範囲となります。
単体テスト
開発で作成した成果物が想定通りに動作するかを検証します。
ここでは、「単体テスト仕様書の作成」と「単体テスト実施」の工程に分かれますが、開発者以外が担当することが望ましいです。
開発者が担当する場合が多いですが、開発者側の思い込みでテストしてしまうことが多く、想定外の動作検証ができていない場合も多いです。
ポイント
また、開発者はプログラミングのミス (不具合、バグともいいます) を出してはいけないものと思い込んでいる人が多く、不具合の記録を残さずに修正してしまうことが多いため、最終的に発見した不具合が著しく少ないという結果が出てしまう場合があります。
ミスが多すぎるのもあまり印象は良くないですが、不具合件数が少ない場合、正しくテストされていない (テスト不足) という誤解が発生します。
通常は、「不具合発見 (記録) → 開発者修正 → 再テスト」の手順で再開されます。
テストの範囲は開発プログラムごと (各画面や帳票、モジュール単位) となり、詳細設計書の記述をもとに作成します。
成果物
成果物は、「単体テスト仕様書、単体テスト結果報告書」など。
結合テスト
単体テストで検証したプログラムをまとめて動作を検証します。
単体テストと同じく「結合テスト仕様書の作成」と「結合テスト実施」の工程に分かれ、結合テスト仕様書は基本設計書の記述をもとに作成され、最終的にシステム全体が正しく動作するかを検証します。
成果物
成果物は、「結合テスト仕様書、結合テスト結果報告書」など。
システムテスト (総合テスト)
システム全体が要件定義で定義した要件を満たしているかを検証します。
ほとんどの場合は実稼働を想定して実施され、セキュリティ面や性能面も検証されます。
依頼側の業務を想定するため、テスト結果を依頼者側に確認していただく場合がほとんどです。
※ 依頼側に参加していただく場合もあります。
テスト運用、本稼働
システムテスト後の工程としては、テスト運用、操作マニュアル作成、運用マニュアル作成、業務マニュアル作成、担当者指導 (教育) 等がありますが、本稼働前の作業としてまとめます。
内容としては依頼側がシステム化した業務を本稼働するまでの準備期間であり、主に依頼側で進めることになります。
システム化前の業務と並行して、システム化した業務をテスト運用したり、要求定義で依頼した業務の改善、効率化が満たされているかを評価します。
マニュアルについては、「操作マニュアル、運用マニュアルは開発側」、「業務マニュアルは依頼側」で作成することが多く、担当者指導は、依頼側で実施する際に開発側がサポートとして呼ばれることが多いです。
システム運用、システム保守
システム運用とは、本稼働開始から稼働状況の監視・管理や、定期的なシステムバックアップ等、運用マニュアルに従って作業します。
また、システム保守とは、システムトラブルや改善依頼があった場合にトラブルの解消やプログラム等を改善します。
まとめ
システム開発とは、組織や人、モノなどを組み合わせて業務を改善、最適化するものです。
依頼側の思った通りにシステム化できることが望ましいですが、「ボタンひとつで全ての業務が完結！」などということはなかなかできず、依頼側の予算、スケジュール等も無限ではないため、依頼側と開発側でどこまで実現可能か検討することが大事です。
依頼側は簡単にできそうだと思っていても実現することが難しかったり、逆に依頼側が難しいと思ったことが簡単にシステム化できてしまう場合もあります。
できる限りコミュニケーションを取り、win – win の状態でシステム開発することを目指しましょう。