ソフトウェア開発の工程と手法

家を建てるのと同じ。ソフトウェア開発には順番がある

ソフトウェア開発と聞くと、すごく専門的で難しそうに感じるかもしれません。でも動画は、家を建てるのと同じように、明確な順番があると言います。いきなり大工さんが木材に釘を打ち始めることはありません。まずどんな家にするか話し合って、設計図を書きます。ソフトウェアも全く同じで、大きく分けると次の4つの工程になります。

• 要件定義：作るものの仕様と範囲を決める。
• 外部設計：ユーザーから見える部分を決める。
• 内部設計：システム内部の動作・機能・物理データを決める。
• プログラミング：設計をもとにプログラムを書く。

動画の後半では、実際の作り方の手法（スクラッチ開発・パッケージ開発・マッシュアップ・ローコード開発）が出てきます。なお、この動画ではプログラミングより後の工程（テストなど）には触れていません。

工程① 要件定義：どんなものを、どこまで作るか

最初の工程は要件定義です。動画の説明では、新たに構築するソフトウェアの仕様と範囲を決める工程で、つまり「どんなものを作るか、どこまで作るか」を決めます。具体的には次のことを決めます。

• そのソフトウェアで実現したい業務や業務フロー
• 必要な機能や性能（「こういう画面があって、こういう計算ができる」といった目に見える機能など）
• 要求される信頼性や保守性（目に見えない部分）

（補足：動画の「信頼性」「保守性」のように、画面や計算といった機能そのものではなく、システムの品質や運用に関する要求を非機能要件といいます。IPA（情報処理推進機構）の「非機能要求グレード」は、システム基盤の非機能要求を可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つの大項目に分類しています。また、IPAの資料はJIS X 25010に基づく製品品質モデルの品質特性として、機能適合性・性能効率性・互換性・使用性・信頼性・セキュリティ・保守性・移植性の8つを挙げており、信頼性と保守性はその中の2つです。この8特性は2013年版（ISO/IEC 25010:2011対応）の整理と考えられますが、資料に年版の明記はなく、JIS原文は確認できていません。国際規格 ISO/IEC 25010 は2023年に改訂されており、JIS側の新しい版では特性の構成が変わっている可能性があります。）

（補足：動画にない設例です。信頼性の要件を「稼働率99.9%以上」と決めると、1年（8,760時間）で止まってよい時間は8,760×（1−0.999）＝約8.8時間です。「99.99%」なら約53分。目標が一桁上がると必要な備えも大きく変わるので、あとから変えるのは大変です。）

工程② 外部設計：ユーザーから見える側の設計

要件が決まったら、2番目の外部設計です。動画では、ユーザーから見えるインターフェース部分の仕様を決める工程とされます。まず、システムやプラットフォームの方針を設計する方式設計を行います。「どんな構成にするか」という方針です。

次に、システムをモジュール単位で分割し、使用するデータベースの設計を行います。ここで聞き手が、もっともな疑問を挟みます。

そのうえで機能設計を行います。皆さんがイメージしやすい、画面レイアウトや操作方法、帳票などのインターフェース部分の仕様を決める作業です。聞き手の言葉を借りれば、画面のボタンの位置や、印刷する書類のフォーマットなど、ユーザーが直接触れる部分の設計です。

作業（動画の整理）	決める中身	動画の例
方式設計	システムやプラットフォームの方針	どんな構成にするか
モジュール分割・データベース設計	ユーザーの業務に合わせた切り分け	経理用・営業用のモジュール
機能設計	画面レイアウト・操作方法・帳票	ボタンの位置、書類の書式

（補足：区切り方が動画と違う資料もあります。たとえば民間の解説では、外部設計は画面・操作方法・帳票などユーザーから見える仕様とし、機能の分割やデータベースの物理設計は内部設計に置くものがあります。外部設計を基本設計、内部設計を詳細設計と呼ぶ場合もあります。IPAの「機能要件の合意形成ガイド」は、外部設計工程が終わるまでに発注者と開発者が機能要件を合意することを目的にしています。どこまでを外部設計とするかは資料により異なります。）

工程③ 内部設計：見えない裏側の設計

外側が決まったら、次は見えない内側です。動画では、第3の工程である内部設計は、システム内部の動作や機能、物理データなどを決定する工程です。具体的には、システム内部の機能をモジュールごとに分割し、各モジュールの機能を明確化する機能設計を行います。ここで聞き手が気づきます。

内部設計では、さらに物理設計も行います。ユーザーには見えないシステム内部で使う、ファイルやデータのやり取りに関する部分の設計です。聞き手が「データをどのサーバーのどこに保存するか、のような物理的な処理ですね」とイメージを言い、講師が「そうです」と答えています。ここまでで、「どうやって作るか」という詳細な設計図が完成します。

動画の整理	外部設計	内部設計
視点	ユーザーから見える	見えない
機能設計	画面・操作方法・帳票	モジュールごとの機能
ほか	方式設計・分割・データベース	物理設計
レストラン	メニュー表のデザイン	厨房の調理手順

工程④ プログラミングと、順番を守る意味

最後の第4の工程がプログラミングです。動画では、内部設計で設計した内容をもとに、プログラムをモジュールに分割し、そのうえでプログラムを書いて、ソフトウェアを作っていきます。ここでやっとコードを書きます。聞き手は、ここまでをこうまとめて、講師から「完璧なまとめです」と言われます。

• 要件定義で、目的と範囲を決める
• 外部設計で、ユーザーから見える部分を決める
• 内部設計で、見えない裏側の動作を決める
• 最後にプログラミングで、コードを書く

動画にない設例として、架空の「受注管理システム」に4つの工程を当てはめてみます。

工程	動画の説明	設例（受注管理）
要件定義	仕様と範囲、信頼性など	受注から出荷までの流れ、止まってよい時間
外部設計	ユーザーから見える部分	受注入力画面、納品書の書式
内部設計	見えない動作・機能・物理データ	受注を登録する裏の処理、データの保存方法
プログラミング	プログラムを書く	設計どおりにコードを書く

作り方の違い①：スクラッチ開発とパッケージ開発

ここで聞き手が、新しい疑問を出します。「この4つの工程を踏んで、毎回全てのプログラムを0から手打ちで書いていたら、今のビジネスのスピードについていけない気がします。何か違うやり方はないんですか？」。講師は、開発のアプローチには根本的な違いがあり、大きく分けると手法が違う、と答えます。

まず1つ目がスクラッチ開発です。ソフトウェアやシステムを、既存のプログラムやシステムなどを使わずに、0から開発する手法です。スクラッチカードのスクラッチと語源は似ているが、ここでのスクラッチは「最初から」という意味だと動画は説明します。全部自分たちで作る、いわば究極のオーダーメイドです。料理にたとえると、小麦粉をこねて酵母を発酵させて、0からパンを焼くようなものです。自社のビジネスに完全にフィットした独自のシステムを作れますが、時間もコストもかかります。

それに対して、既存のプログラムやシステムなどを用いる手法がパッケージ開発です。市販のパンのミックスを使うイメージです。すでに世の中にある会計ソフトや人事管理システムなどのパッケージを導入して、自社の業務に当てはめて使います。0から作るより圧倒的に早く、コストも抑えられるといいます。

動画の説明	スクラッチ開発	パッケージ開発
元になるもの	0から作る（既存のものは使わない）	既存のプログラムやシステム
自社への合い方	完全にフィットした独自のシステム	自社の業務に当てはめて使う
時間・コスト	かかる	早く、抑えられる
動画のたとえ	小麦粉から焼くパン	市販のパンのミックス

作り方の違い②：マッシュアップ

聞き手は続けて、「最近のWebサービスは、いろいろなサービスが連携して動いているのを見かけますが、あれはどういう仕組みですか」と尋ねます。講師は、それは別のアプローチでマッシュアップという手法を使っていることが多い、と答えます。

動画の例は、地図を提供するWebサービスのGoogleマップと、地域情報や天気情報を提供する別のWebサービスの組み合わせです。2つを合体させると、地図の上に地域情報や天気を表示したウェブサイトが作れます。

これを自分たちで、地図システムや気象のシステムからスクラッチ開発しようとしたら、とんでもない時間とお金がかかります。聞き手が「人工衛星まで飛ばさないといけなくなりますからね」と冗談を言うほどです。でもマッシュアップなら、すでに存在して公開されている優秀なサービスを掛け合わせるだけで、全く新しい価値を生み出せる、と動画は言います。

（補足：IPAのセキュリティ資料（2007年公開のアーカイブ）も、音楽DJの手法になぞらえて、Webアプリケーションを組み合わせて開発することを「マッシュアップ」と呼ぶようになった、と説明しています。）

作り方の違い③：ローコード開発

ここまでのパッケージ開発やマッシュアップは、だんだん便利になっていますが、聞き手は「つなぎ合わせたり設定したりするには、結局プログラミングの専門知識がないと作れないんじゃないですか」と疑問を出します。講師は「そうとも限らない時代になってきている」と答え、ローコード開発を紹介します。コードがロー、つまり少ない、という意味です。

動画の例はkintoneです。プログラミングをほとんど使わず、画面上で部品を組み合わせるようにして、アプリやシステムを作れる開発手法だと説明されます。テキストボックスやカレンダーなどの部品をマウスで配置していくだけで、システムができあがります。

（補足：動画は「専門知識がなくても」と説明しますが、一般には、コードをほとんど書かずに作るものをローコード、一行も書かずに作るものをノーコードと呼び分けることがあります。SAPの解説では、両者の違いは必要なコーディング知識の量で、ローコードは基本的なコーディングスキルが必要、ノーコードは不要とされています。kintoneはサイボウズの公式サイトで「ノーコード・ローコードツール」と紹介されています（2026年10月25日確認）。呼び分けは資料によって揺れます。）

試験に向けて確認しておきたいこと

まとめ：頭の中に見取り図を

動画は、要件定義、外部設計、内部設計、プログラミングという、家を建てるような伝統的で確実な4つの工程を、システム開発の土台だと位置づけます。そのうえで、実際の作り方には、ゼロから作るスクラッチ開発、既存のものを利用するパッケージ開発、公開サービスを掛け合わせるマッシュアップ、専門知識がいらないローコード開発という選択肢がある、と整理しました。

動画の最後は、こんな問いかけで終わります。もし今、自分のビジネスの課題を解決する新しいシステムを作るとしたら、自社のコアバリューを極めるために、時間とコストをかけてでもゼロから徹底的にこだわるスクラッチ開発を選ぶか。それとも、スピードとコストを重視してローコード開発やマッシュアップを選ぶか。動画は「正解は1つではない」と言います。ご自身の状況に当てはめて考えてみてください。