システム開発は、日々進化しています。従来の多くは、最初に全体計画を立てるウォーターフォール開発でした。最近は小さい開発を繰り返し、仕様変更もしやすいアジャイル開発が増加しています。
また、プログラミングなしにソフトウェア開発をするノンプログラミングも増えています。ノンプログラミングには、クラウド型とオンプレミス型があります。
本記事では、システム開発の基本的なポイントから最新事情まで解説します。
Contents
1. システム開発とは
1-1. システム開発の定義
システム開発とは、新規の場合は従来人手に頼っていた作業を自動化したり、リニューアルの場合は今までよりも利便性や正確性を高めるために、システムを構築することを指します。多くの場合、外部のシステム会社に依頼します。「何のために」「どんな仕様で」「どんな機能で」「いつまでに」「いくらで」といった内容を「要件定義書」に決めてから、開発が開始されます。
一つのシステムが出来上がるまでには、まず発注企業側がプロジェクトチームを決定し、RFI（情報依頼書）やRFP（提案依頼書）を作成します。それらに沿った文書を、発注を受ける候補である複数のSIerやベンダーが提出し、発注先が決定されます。
その後要件定義で、基本設計と詳細設計がSIerもしくはベンダーのシステムエンジニア（SE）が作成し、プログラマー（PG）がソースコードを書いていきます。その後テストを行い、バグがないかチェックして納品します。
2. システム開発の流れ
2-1. 依頼する上での重要なポイント
2-1-1. 目的を明確にする
お金と人員と時間を使ってシステム開発をする以上、従来にはないユーザーメリットが必要です。そのためには「このシステム開発の目的は何か」を明確化することが必要です。どんなユーザーに、今までにはないどんなメリットを創造できるのかを設定しましょう。そうすることで、開発会社も装備すべき機能を洗い出しやすくなります。
2-1-2. 最適な開発会社の選定
数多くあるシステム会社の中から、どこを選べばいいのかという判断は、プロジェクトの成否を左右する重要なポイントです。大きなポイントは、「得意分野」「価格」「体制」「類似システムの過去の実績」です。特に類似システムの実績があると、プロジェクトの成功確度が大幅にアップします。
コンペでのプレゼンの印象や見積もり書の価格比較だけでなく、開発会社のWebサイトも丹念にチェックしましょう。
2-1-3. 積極的なコミュニケーション
システム開発の目的や、類似したシステム開発事例、疑問点に関してコミュニケーションを取りましょう。またコミュニケーションを取ることで、レスポンスの早さや回答の丁寧さも把握できます。
2-2. 契約する上での重要なポイント
2-2-1. 多段階契約と一括契約
システム開発の契約においては、工程ごとに契約を結ぶ多段階契約が一般的です。一方、システム開発の全行程を一つの案件として契約を結ぶのが一括契約です。
多段階契約の場合、工程ごとの費用に見積もりを出すことができますが、何回も契約交渉する必要があります。一括契約の場合は、契約は一回で済みますが、見積もりが不正確な場合、リスクがあります。
2-2-2. 多段階契約が推奨される理由
多段階契約が推奨される大きな理由の一つが、プロジェクト開始時点で目的が明確になっていないというものです。つまり、社内でシステムの最終イメージが共有されていないことが多いのです。
そのため一括契約の場合、契約締結時点でお互いの義務を約束することが困難になります。特にシステム開発は、長期に渡ることがかなりあります。プロジェクト稼働中に、社内事情で追加事項が発生することもあります。実務面のリスクを考慮すると、多段階契約の方がリスクは少ないといえるでしょう。
2-3. 検収時の重要なポイント
一般的にシステム開発では、納品後の検収をもって開発費の支払いが終了します。検収とは受け入れテストです。納品されたシステムが、予め設定された仕様を満たしているかを確認します。その後、本稼働し、運用・保守となります。
様々なチェックを行い、納品システムに問題がないと判断した場合、発注側が捺印した検収書を開発会社に渡します。検収の大まかな流れを、以下に記します。
＜システム開発の検収の流れ＞
① システムの納品
② 受け入れテスト
③ 不具合があった場合、プログラムの修正
④ プログラムの再納品
⑤ 受け入れ再テスト
⑥ 発注会社が捺印した検収書を発行
※これ以降は契約不適合責任期間
3. 具体的なシステム開発工程
システムが完成するまでの全体の工程。要件定義段階でブレない設計をすることが、修正やバグ防止につながる
ここでは、システム開発工程を解説します。どんな職種の人がどの部分を担当するのかを把握しておくことは、とても重要です。
3-1. 要件定義
「顧客がどんなシステムを望んでいるのか」をヒアリングや資料を通じて、正確に把握します（要件分析）。顧客の現状とニーズを分析し、課題を設定した上で、課題を解決するためのシステムの全体像（ソフトウェア機能やハードウェア）を設計するのが要件定義です。
＜要件定義のポイント＞
① 顧客と打ち合わせ→要求分析
② 要件定義書作成
③ 開発見積書算出
3-2. 外部設計（基本設計）
外部設計では、文書化した要件定義書を顧客と共有し、開発するシステムの機能を決定します。ここで一番重要なのは、ユーザーの満足度を追求するスタンスです。いくら高機能のシステムを構築しても、ユーザーに使ってもらえなければ、それは無用の長物です。
ユーザー目線で、インターフェースデザインや機能の優先順位を設計することが、とても重要です。
＜外部設計のポイント＞
① システムの基本となる設計
② 操作画面、操作方法、データ出力等のインターフェイス仕様決定
③ スケジュールやコストの設計
3-3. 内部設計（詳細設計）
外部設計（基本設計）をベースに、SE（システムエンジニア）がシステム仕様書を作成します。この仕様書は、「外部設計で要求されている動作を実現するために、どのパートはどのようなソースコードで書くべきか」というプログラマーへの指示書的な側面があります。
ここでは、開発するシステムの機能実現に必要な構成力とプログラマーが気持ち良くプログラミングできる適切な指示の表現力が求められます。
＜内部設計のポイント＞
① システム内部の動作や機能を設計
② プログラム機能を単体に分割し、物理データや入出力を設計
3-4. プログラミング
SEが作成した仕様書に沿って、プログラマーがプログラミングを行います。この時、どんな動作をどの言語で表現するかは、プログラマーが判断します。
またシステム設計書で求められる動作を実現するために、どのようなソースコードを書けば良いのか、そこにプログラマーのスキルが問われます。
ちなみにクオリティの高いソースコードの特徴を、以下に記します。
＜高品質なソースコードのポイント＞
① 正確に動作する
② 素早く、効率的に動作する
③ 保守がしやすい
④ 無駄がなく、シンプルである
3-5. 単体テスト
プログラミングが完成すると、書かれたソースコードが正確に作動するかどうか、SEがテストを実施します。そし、テスト結果をレビューします。
ここで重要なのが、「テスト観点」です。テスト観点とは、システムが正しく動作するための切り口をまとめたものです。テスト観点のポイントを、以下に記します。
3-5-1. 機能要素
テスト観点の機能要素は、検証すべき機能や動作を要件定義書から抽出していきます。例えば、「各ページの画面表示機能」や「ボタン選択時の画面遷移機能」などがあります。
3-5-2. 検証方法
テスト観点の検証方法は、「納品システムをどのようにテストするか」です。具体的には、それぞれの機能に対してどのような検証方法を適用するかを決定します。
例えば、「ユーザビリティテスト」や「条件網羅テスト」、「互換性テスト」「異常値テスト」などがあります。
3-5-3. 入力条件
テスト観点の入力条件は、「どんな値が入力されるのか」です。例としては、「大文字小文字の区別」「空文字・スペース」「うるう年などのイレギュラーな年月日」などがあります。
3-5-4. 出力結果
テスト観点の出力結果は、テスト対象としての出力結果として何をみるかということです。具体的には、「音声・動画のズレの有無」「文字化け・文字切れ」「異常値入力時のエラーメッセージ」などがあります。
3-6. 総合テスト
総合テスト（システムテスト）では、全ての機能や性能が満たされているかをシステム開発会社側が検証します。またハードウェアや通信回線も含め、機能間の連携や運用・保守の実現性もチェックします。
＜総合テストのポイント＞
① 機能単位で検証する
② 機能設計書通りに動くか検証する
③ バグを出し切ることが重要
3-7. 運用テスト
運用テストは、「業務で支障なく使えるか」を確認するための最終テストです。この運用テストは、エンドユーザーが本番稼働後と同じ環境下で行います。また開発会社側が想定していない操作の結果や、UI上の不都合などもチェックします。
ポイントとしては、「余裕のあるスケジュール」「ユーザー目線」「不具合・バグの共有」などがあります。気をつけるべきは、予期せぬ不具合によるユーザー側のデータや機器の支障です。そうならないために、ネットワークやセキュリティ環境を用意する必要があります。
3-8. リリース
システムやアプリ、ソフトウェアの開発が完了すると、開発会社によってリリースされます。
3-9. 運用・保守
新しく開発されたシステムが常時正常に稼働するためには、エンジニアによる運用・保守が必要です。例えばシステムダウンが発生すると、ダウン中の利益機会の損失が生まれ、ユーザーの信頼感も失われます。
システムの運用設計においては、「監視体制」と「障害時の対応」、「役割分担と責任の所在」を決めておくことが大切です。
また定期メンテナンス・バックアップ業務としては、「セキュリティパッチ適用」「メンテナンスサーバーの再起動」「定期的なバックアップ」などがあります。
4. システム開発の上流工程
システム開発の上流工程とは、開発設計における初期段階の工程です。具体的には「要件定義」や「機能定義」、「構成管理」「計画立案」などの工程を指します。
要件定義では、クライアントが求めている「システムの目的」「実現するための機能」等をヒアリングし、要件としてまとめます。
5. システム開発のV字モデル
システム開発のV字モデルとは、システム開発の開始から完成までの流れを可視化したモデルです。V字モデルの大きな特徴は、左側に開発工程があり、右側にそれに対応するテスト工程があります。
例えば、左側の一番上には要件定義があり、それに左右対称の形で「要件定義が正しく実装されているか」を検証するシステムテストがあります。
V字モデルを活用することで、開発工程に対応したテスト内容が明確になります。また工程ごとに不具合の検出・修正を行うので、手戻りのリスクを軽減できます。
6. 4種類の開発スタイル
システム開発には、大きく4つのスタイルがあります。それぞれメリットとデメリットがあるので、ここではそれらを整理します。
6-1. ウォ―ターフォール型開発
ウォ―ターフォール型開発は、一番メジャーな開発手法です。「要件定義」から始まり、「リリース」まで時系列で作業を進めていきます。各工程が完了し承認されないと、次の工程には進みません。各工程ごとに成果物を残していく手法が、ウォーターフォール型開発です。
＜ウォ―ターフォール型開発のメリットとデメリット＞
【メリット】
① メジャーな手法のため、プロジェクトに関わる人間に一から説明する必要がない
② この手法を経験している人材が多く、プロジェクトマーネジャーを確保しやすい
③ 各工程ごとに区切り、承認後に次の工程に進むため、工程ごとの成果物が確実に残り、進捗管理しやすい
【デメリット】
① 想定外のニーズにより手戻りが発生した場合、予算超過や納期ずれにつながりやすい
6-2. アジャイル型開発
アジャイル型開発は、優先順位の高い工程からシステム開発できます。この「アジャイル」という言葉には、「素早い」「頭の回転が速い」といった意味があります。
＜アジャイル型開発のメリットとデメリット＞
【メリット】
① 顧客の優先順位の高い部分、もしくは要件が決まった順に開発に着手できる
② 構築するシステムの全体像が決定していない状態でも、開発できる
③ 短期での納品が可能
【デメリット】
④ 計画性に欠けているため、大規模の開発には向いていない
6-3. プロトタイプ型開発
“プロトタイプ”とは、そもそもデモンストレーション用に問題点洗い出しのために設計された原型という意味です。そこからプロトタイプ型開発とは、将来修正することを想定した上でスピーディにシステムを完成させる開発手法です。システムの完成形が明確に決まっていない場合、まずは動作するシステムを構築し、随時修正していくプロトタイプ型開発は便利な手法です。
＜プロトタイプ型開発のメリットとデメリット＞
【メリット】
① 完成形が決まっていなくても、早くシステムを構築できる
② システムを作りながら、随時修正を加えることができる
【デメリット】
③ そもそも最終形が決まっていないので、計画性には欠ける
④ 大規模なシステム構築には向いていない
6-4. スパイラルモデル
スパイラルモデルは、まずシステムを複数のサブシステムに分割します。そしてサブシステム毎に順次開発を進めていきます。これは、大規模なシステムの開発においてよく活用される手法です。
サブシステムに分けることで、完成ごとにお客様に見せることが可能になります。そうすることで手戻りがなくなり、システムの完成度を高めることができます。
＜スパイラルモデルのメリットとデメリット＞
【メリット】
① 修正ごとに、随時アップデートできる
② 顧客の要望を随時取り入れていきながら開発できるので、顧客の満足度が高くなる
【デメリット】
① 修正ごとに開発対応を実施するため、コストが膨れるリスクがある
7. システム開発の働き方
システム開発の働き方には、自社開発、受託開発、SESの3つのスタイルがあります。それぞれメリット、デメリットがありますので、今の自分にとってどれが最適な働き方かを判断する必要があります。
7‐1. 自社開発
GoogleやAmazon、マイクロソフトなど有名企業には、多くのITエンジニアが働いています。彼らのシステム開発の働き方は、自社開発です。以下に、自社開発のポイントを記します。
＜自社開発のポイント＞
【メリット】
① ユーザーへの価値提供を追求できる
② ユーザーの反応データを把握でき、本質的なサービス向上をしやすい
③ スケジュールが比較的調整しやすい
④ システム開発途中のトラブル対応にも融通がききやすい
【デメリット】
① 人気サービスを展開している企業が多く、入社難易度は高い
② アジャイル開発を採用しているところが多く、慣れていない人には当初戸惑いがある
③ サービスリリース＝利益とは限らない
7‐2. 受託開発
受託開発は、企業から依頼を受けてシステムを開発する働き方です。また受託開発は請負契約になり、必ず成果物を完成させる必要があります。一般的にはシステム検収後に、一括で報酬が支払われます。
＜受託開発のポイント＞
【メリット】
① 案件のボリュームが多い
② 職場が変わらない
【デメリット】
① 納期に縛られ、土日返上で働くことも
② 元受け企業が利益が上がるが、下請け企業はハードワークの割には利益が少ない
③ 給料はアップしにくい
7‐3. SES
SESとは、ITの派遣会社を通し、客先常駐で働くスタイルです。プログラマーとしてのスキルがなくてもやる気があれば採用されやすく、ITの現場で経験を積みながらスキルアップを図るチャンスがあります。
＜SESのポイント＞
【メリット】
① 入社しやすく、未経験者にも門戸は開かれている
② 入社後に研修を受けられる
【デメリット】
① 職場は自分で決められず、会社が決定する
② 未経験者は、最初はアシスタント的な仕事が多い
③ 職場が変わるので、スキルを深掘りできないことも多い
8. システム開発に関わる全職種と必要スキルと年収
システム開発には、様々な職種の人が関わります。ここでは詳しく見ていきましょう。
8-1. プログラマー（PG）
プログラマーは、システムエンジニア（SE）が作成した仕様書に沿ってコードを書きます。
求められるスキルは、バグがなく、正確に動作するわかりやすいソースコードを書くことです。またシステムエンジニアとのコミュニケーション能力も重要です。
プログラマーの平均年収は、420万円前後です。月額に換算すると、35万円前後です。
8-2. システムエンジニア（SE）
システムエンジニア（SE）は、システム開発の上流工程を担当します。要件定義や基本設計、詳細設計を担います。
求められるスキルは、顧客の課題をわかりやすく説明できる力です。また、メンバーを上手くまとめたり、スケジュール管理等のマネジメント力も必要です。
システムエンジニアの平均年収は、約500万円前後です。
8-3. プロジェクトマネージャー（PM）
プロジェクトマネージャー（PM）は、プロジェクトの目標達成を意識しながらシステム開発案件を統括します。
求められるスキルは、予算や人員などの全般を統括する力です。
プロジェクトマネージャーの平均年収は、約620万円前後です。
8-4. セールスエンジニア
営業が受注し、顧客企業と最初にコミュニケーションを取るエンジニアです。営業職と技術職の交わる領域であり、高い専門性が要求されることが多く、エンジニア出身が多いです。
求められるスキルは、顧客にわかりやすく説明する力と、ニーズをヒアリングし、システムに落とし込む力です。
セールスエンジニアの平均年収は、約520万円前後です。
9. システム開発に関するQ&A
ここでは、システム開発に関する代表的なQ&Aを取り上げたいと思います。
9-1. システム開発の見積もりについて
現在、ECシステムの開発に関わっています。こういったシステムの開発によって、もらえる報酬の相場はいくらぐらいでしょうか。システムの規模によって金額が変わることは理解できますが、どうやってその金額が決まるのかわかりません。
→システム開発の金額計算は、「完成まで何人月かかるか？」という方式になります。例えばSEが4人で5ヶ月かかるのであれば、「4人×5ヶ月」で20人月になります。SE一人あたりの単価を80万円とすると、80万×20人月＝1,600万円になります。この場合の報酬は受託料であり、機器の購入、設置費用は別になります。
9-2. システム開発の品質管理に関して
以前勤務していたゲーム会社では、リリース前のバグチェックを完璧にしていました。またターゲットである子供にもテストに参加してもらい、そのゲームのクオリティチェックをしていました。その後親の関係に地元に戻り、小さなシステム会社に転職しました。その会社では、最低限のバグチェックのみでリリースしています。自社サイトの商品紹介文では、完璧に機能するように表記しています。こういったことは、よくあるのでしょうか。
→残念ながら、このような現象はあり得ます。企業の規模に関わらず、「最低限のバグチェックのみ」「審査中に、同時並行でバグ修正版を作成する」という現象はあるのです。その結果消滅するサービスもあれば、アップデートを重ねて生き残るサービスもあります。
9-3. システム開発職（SE）と製品のソフト開発職では、どちらは忙しいのでしょうか
大手メーカーのSEという仕事には、無理のある納期に追われるイメージがあります。一方で、大手メーカーの製品のソフト開発職も同様の状況なのでしょうか。
→システム開発職のSEを業務系SE、製品のソフト開発職を制御系SEとすると、業務系SEの方が忙しいパターンが多いです。その理由は、「業務系SEは人間を相手にするから」です。制御系SEはシステム仕様の変更が少なく、動作確認も容易です。ところが業務SEは相手が人間なので、「よく理解していなかった」「勘違いしていた」「忘れていた」といった現象があり、その度に仕様変が発生するのです。
10. まとめ
システム開発に関する知識は、今後ますます重要性が増すと思われます。人生を豊かに生きるためには、IT知識は欠かせません。そのためには、まず全体像を正確に把握し、自分と関わりのある分野はどこか、またそれは他のどの分野と連携しどのような機能を果たしているのかを理解する必要があります。
ITは一旦興味を持って勉強し始めると、非常に奥深い分野です。インターネットが発達した現在では様々なジャンルのナレッジサイトが充実しているので、独学でも知識とスキルをマスターできる環境が整っています。
本サイトでも、わかりやすく理解できるコンテンツを拡充していく予定ですので、是非活用頂ければ幸いです。
