開発技術 重点教科書

システムは、思いついたその日からいきなりプログラムを書き始めるわけではありません。家を建てるときに「どんな家にしたいか」を相談し、間取り図を描いてから柱を立てるのと同じように、システム開発にも決まった手順、つまりプロセスがあります。この章では、その最初の入り口である「何を作るか」「どう作るか」を決める段階を見ていきます。

開発プロセスの全体像

システム開発は、大きく分けると要件定義（何を作るか決める）→設計（どう作るか決める）→プログラミング（実際に作る）→テスト（正しくできたか確認する）→導入・受入れ（お客様に渡す）→保守（使い続けられるようにする）という順番で進みます。この一連の流れを覚えておくと、あとから出てくる個々の用語が「どの段階の話なのか」を整理しやすくなります。たとえば「単体テスト」と聞いたら、それはプログラミングの段階に近い話だな、というふうにイメージできるようになるのがゴールです。

システム要件定義・ソフトウェア要件定義

開発の一番最初に行うのが、これから作るシステムやソフトウェアに何を求めるのかをはっきりさせるシステム要件定義・ソフトウェア要件定義です。ここで決める要求は、大きく2種類に分けられます。ひとつは「見積書を自動計算できるようにしてほしい」「顧客情報を検索できるようにしてほしい」といった、システムが持つべき具体的な働きを示す機能要件です。もうひとつは、機能そのものではなく「1秒以内に画面が表示されること」「24時間365日止まらないこと」「不正アクセスされないこと」といった、性能や品質に関する要求である非機能要件です。機能要件は「何をしてくれるか」、非機能要件は「どれくらいちゃんとやってくれるか」と覚えると区別しやすいでしょう。

非機能要件を考えるときの物差しになるのが品質特性という考え方です。代表的なものとして、必要な機能がきちんと揃っているかを示す機能性、少ない資源で効率よく動くかを示す効率性、利用者にとって使いやすいかを示す使用性、故障しにくく安定して動き続けるかを示す信頼性などがあります。「速さ」「使いやすさ」「壊れにくさ」といった、目に見えにくい価値をきちんと言葉にして評価する枠組みだとイメージしてください。

また、要件定義の内容が本当に正しいかどうかは、担当者ひとりの判断に任せきりにはしません。関係者が集まって内容を確認し合う共同レビューを行うことで、思い込みや見落としを早い段階で防ぐことができます。開発の初期段階で誤りに気づけば気づくほど、あとの手戻りが少なくて済むため、共同レビューは非常に重要な工程です。

設計（機能設計・詳細設計）

要件定義で「何を作るか」が固まったら、次は「どう作るか」を具体的に決めていく設計の段階に進みます。設計はひとつの作業ではなく、段階的に細かくしていくのが特徴です。まず、利用者から見てシステムがどう振る舞うか、画面の項目や入力・出力の内容といった、外から見える部分を決めるのが機能設計です。これは開発者だけでなく利用者側の視点も交えて決めるため、外部から見た設計という意味で「外部設計」と呼ばれることもあります。

機能設計で全体の骨組みが決まったら、次はその中身、つまりプログラムの内部構造やデータの持ち方、処理の手順といった、開発者側の視点で詳しく詰めていく詳細設計を行います。こちらは内部の作り込みを決める設計という意味で「内部設計」と呼ばれることもあります。機能設計が「利用者から見える窓の形を決める」段階だとすれば、詳細設計は「その窓を実際にどう組み立てるか、骨組みや金具まで決める」段階だとイメージすると違いがつかみやすいはずです。設計の精度が低いと、あとのプログラミング工程で手戻りが発生しやすくなるため、この段階でどれだけ丁寧に検討できるかが、開発全体の効率を大きく左右します。

設計が固まったら、いよいよ実際にプログラムを組み立てていく段階に入ります。ただし「プログラムを書いたら終わり」ではありません。書いたものが本当に正しく動くかを確かめる作業とセットになって、はじめて次の工程に進めます。この章では、プログラムを作る作業と、それを確かめる作業の両方を見ていきます。

プログラミングという工程

設計書の内容に従って、実際にプログラミング言語を使ってプログラムを書いていく作業をコーディングと呼びます。ただし、人間が書くものである以上、最初から完璧に動くことはまずありません。プログラムの中の誤り、つまりバグを見つけて直す作業をデバッグと呼び、コーディングとデバッグは常にセットで行われます。

また、自分ひとりの目だけでプログラムを確認するのではなく、他の担当者にソースコードを読んでもらい、誤りや改善点がないかを指摘してもらうコードレビューも欠かせません。第三者の視点が入ることで、自分では気づきにくい書き方のクセや潜在的な不具合を早期に発見できます。

単体テストとホワイトボックステスト

個々のプログラムを書き終えたら、そのプログラム単体が正しく動作するかどうかを確認する単体テストを行います。これはプログラミングの工程に含まれる、いわば「自分の書いたパーツの動作確認」です。

単体テストでよく使われる考え方がホワイトボックステストです。「ホワイト（白）＝中身が見える」という名前が示すとおり、プログラムの内部構造、つまり条件分岐やループといった処理の流れそのものに着目し、想定されるすべての経路が正しく通るかを確認していく方法です。テストを行う際には、あらかじめどんな入力データを使うかを決めておくテストデータの作成と、その結果がどうだったかを分析することが実務上の重要な活用例になります。ただの思いつきでデータを入力するのではなく、「境界となる値」や「特殊なケース」を意識してテストデータを設計することが、質の高いテストにつながります。

統合・テスト（結合テストからシステムテストまで）

単体テストが済んだプログラムは、次に他のプログラムと組み合わせて動かす段階に進みます。複数のプログラムをつなぎ合わせ、プログラム同士の連携がうまくいくかを確認するのが統合テストです。個々の部品は正しく動いていても、部品同士をつなげた途端に不具合が出る、ということは珍しくありません。統合テストは、まさにその「つなぎ目」の確認を行う工程です。

統合テストの段階からは、単体テストのように内部構造を見るのではなく、システムの中身を気にせず「仕様書どおりの入力に対して、仕様書どおりの出力が返ってくるか」だけを確認するブラックボックステストという考え方が中心になります。「ブラック（黒)＝中身が見えない箱」として扱い、利用者と同じ目線で外から動作を確認するイメージです。

テストにはさらにいくつかの種類があります。想定どおりの処理速度で動くかを確認する性能テスト、大量のアクセスやデータが集中したときにシステムが耐えられるかを確認する負荷テスト、そしてプログラムを修正した際に、その修正が原因で今まで正常に動いていた別の部分まで壊れていないかを確認する回帰テスト（リグレッションテスト）は、いずれも実務で頻繁に登場する重要なテストです。特に回帰テストは、「一部を直したつもりが、別の場所で新しい不具合を生んでしまう」というシステム開発でよくある失敗を防ぐための工程だと理解しておきましょう。たとえばネットショップのカート機能を修正したときに、関係ないはずの会員登録画面までエラーになってしまう、というようなことは意外と起こりがちです。回帰テストは、そうした「意図しない副作用」をあらかじめ検出するための保険のようなものだとイメージしてください。

なお、テストには「計画を立てて実施し、その結果を評価する」というサイクルがあり、あらかじめ決めた目標に対してどれだけの実績が出せたかを評価することも欠かせません。テストは行っただけで終わりにせず、その結果を次の改善につなげてこそ意味を持ちます。また、テストは「バグが一つも存在しないこと」を証明するための活動ではない、という点も覚えておきたいポイントです。どれだけ丁寧にテストを重ねても、すべての不具合を洗い出せる保証はありません。テストはあくまで「品質を一定の水準まで高め、リスクを減らすための活動」であるという位置づけを理解しておくと、試験問題の考え方にも合わせやすくなります。

プログラムが完成し、テストで一定の品質が確認できたら、いよいよそのシステムを実際に使ってもらう段階に入ります。ただし、作って終わりではありません。使ってもらってからも、システムは生き物のように変化に対応し続ける必要があります。この章では、完成したシステムを届ける工程と、その後の付き合い方、そして開発にかかる労力をどう見積もるかを見ていきます。

導入・受入れ

システムを発注した側、つまり取得者（委託側）は、実際にシステムを作った供給者（受託側）の支援を受けながら、本番に近い環境でシステムを実際に動かしてみて、狙いどおりの成果が得られるかを確認します。この確認作業を受入れテストと呼びます。受入れテストは開発者側ではなく、あくまで発注した側が主体となって行う点がポイントです。「使う立場になって、本当に困らないか」を確認するのが受入れテストの本質だからです。

これと似た言葉に妥当性確認テストがあります。これは「作られたものが、そもそも利用者が本当に必要としていたものと合致しているか」を確認するテストです。仕様書どおりに正しく作られているかを確認するテストと、利用者の本当のニーズに合っているかを確認するテストは、似ているようで視点が異なることを意識しておくとよいでしょう。

受入れテストで問題がないと判断されれば、システムは正式に納品されます。あわせて、実際にシステムを操作する人向けに使い方をまとめた利用者マニュアルを用意し、運用者や利用者、その他の関係者に対する教育訓練も行われます。さらに、これまで使っていた古いシステムから新しいシステムへ切り替える移行の作業も、この段階の重要な仕事のひとつです。移行のタイミングを誤ると、業務が一時的に止まってしまうこともあるため、慎重な計画が求められます。

保守

システムは、納品して終わりの「完成品」ではありません。稼働を始めたあとも、法律の改正や組織の方針変更、新しい技術の登場などに合わせて、修正や変更、改善を続けていく必要があります。この、稼働後のシステムを安定して使い続けられるように手を加え続ける活動を保守と呼びます。企業を取り巻くITの環境や経営戦略は常に変化していくものなので、保守は開発が終わったあとも長く続く、地味だけれど非常に重要な工程です。

ソフトウェアの見積り

システム開発を始める前には、「どれくらいの作業量になりそうか」「どれくらいの期間がかかりそうか」を事前に予測しておく必要があります。これをソフトウェアの見積りと呼び、開発の規模や開発環境などをもとに、必要な開発工数（どれだけの人手と時間がかかるか）や開発期間を算出します。

見積りの代表的な手法のひとつがファンクションポイント（FP）法です。これは、画面の数や出力される帳票の数、扱うデータの種類といった、利用者から見てわかりやすい機能の数や複雑さをもとに規模を数値化し、そこから開発量を見積もる方法です。プログラムの行数のような技術的な指標ではなく、利用者にも理解しやすい機能ベースで見積もれる点が特徴です。

このほか、過去に自社で手がけた似たようなシステムの実績データと比較しながら、おおよその規模を予測する類推見積法、そして複数の作業項目の規模を絶対的な数値ではなく、互いの相対的な大小関係で見積もる相対見積もあります。いずれも「未来のことを完璧に言い当てる」ためのものではなく、限られた情報の中でできるだけ現実的な予測を立てるための工夫だと理解しておきましょう。

ここまで見てきた「要件定義→設計→プログラミング→テスト→保守」という流れは、あくまで基本形です。実際の現場では、この流れをどんな考え方で進めていくかによって、いくつかの型が使い分けられています。この章では、開発の進め方そのものに関する代表的な手法・モデル・フレームワークを整理していきます。

代表的なソフトウェア開発手法

プログラムの作り方そのものにも、いくつかの考え方があります。処理の流れを機能ごとに小さな部品に分割し、それらを組み合わせてプログラム全体を組み立てていく構造化手法は、古くから使われてきた基本的な考え方です。これに対して、データとそれを操作する処理をひとまとまりの「モノ（オブジェクト）」として扱い、それらの組み合わせでシステムを組み立てていくオブジェクト指向という考え方も広く使われています。

オブジェクト指向の設計でよく使われるのが、利用者がシステムをどう使うかという場面を洗い出すユースケースという考え方や、システムの構造や振る舞いを図で表現するための標準的な表記ルールであるUMLです。

また近年特に注目されているのが、開発チーム（Development）と運用チーム（Operations）が連携し、開発から運用までを一体的かつスピーディに進めていくDevOpsという考え方です。従来は「作る人」と「動かす人」が分かれ、互いの都合がぶつかりがちでしたが、DevOpsでは両者が同じ目標に向かって協力し合うことで、変更をより早く、より安全に世の中へ届けられるようになります。同じような発想を機械学習（Machine Learning）の分野に応用し、AIモデルの開発から運用までを効率的に回していくMLOpsもあわせて覚えておきましょう。AIモデルは一度作って終わりではなく、新しいデータに合わせて学習し直し、運用しながら精度を保ち続ける必要があるため、DevOpsの考え方がAI分野にも広がってきているのです。

主なソフトウェア開発モデル

開発の工程をどんな順序・形で進めるかという「型」にもいくつかの種類があります。最も古典的なのが、要件定義から保守まで、決められた工程を上流から下流へ順番に、後戻りしない前提で進めていくウォーターフォールモデルです。水が上から下へ流れ落ちる様子になぞらえて名づけられており、大規模なシステムで計画的に進めたい場合に向いています。

これに対して、設計・開発・評価というサイクルを、少しずつ規模を広げながら何度も繰り返していくスパイラルモデル、実際に動く試作品（プロトタイプ）を早い段階で作って利用者に見てもらい、フィードバックを得ながら完成度を高めていくプロトタイピングモデルがあります。特にプロトタイピングモデルは、「文章だけでは伝わりにくいイメージのズレ」を早期に解消できる点が強みです。

さらに、開発ツールや部品をあらかじめ用意しておき、短期間で一気にシステムを開発するRAD（Rapid Application Development）、そして完成済みのソフトウェアを解析し、その仕組みや設計内容を逆にたどって明らかにするリバースエンジニアリングもあわせて押さえておきましょう。リバースエンジニアリングは、仕様書が残っていない古いシステムの内容を調べ直す場面などで使われます。

アジャイル開発とスクラム

ウォーターフォールのように最初から計画をきっちり固めるのではなく、短い期間で「作る→確認する→直す」を繰り返しながら、変化に柔軟に対応していく軽量な開発の進め方をアジャイルと呼びます。仕様が途中で変わりやすい現代のシステム開発では、この考え方がますます重視されるようになっています。

アジャイル開発では、利用者が「誰が」「何をしたいか」「なぜそれが必要か」という形で要求を短い文章にまとめるユーザーストーリーを出発点にすることがよくあります。代表的な手法のひとつであるXP（エクストリームプログラミング）では、あらかじめテストを書いてからプログラムを実装するテスト駆動開発、2人1組で1台のパソコンに向かい、片方がコードを書きもう片方が確認しながら進めるペアプログラミング、外から見た動作は変えずにプログラムの内部構造だけを整理して読みやすく保つリファクタリング、そして一定の作業サイクルの終わりに「うまくいったこと・改善したいこと」を振り返るふりかえり（レトロスペクティブ）といった実践方法が用いられます。また、変更を加えるたびに自動的にテストや統合を行い、常に動く状態を保とうとする継続的インテグレーション（CI）もアジャイル開発と相性のよい仕組みです。

アジャイル開発の代表的なフレームワークがスクラムです。スクラムでは、開発するものの価値に責任を持つプロダクトオーナー、実際に開発作業を行う開発者、チームがスクラムのルールどおりに進められるよう支援するスクラムマスターの3つの役割からなるスクラムチームを組みます。開発はスプリントと呼ばれる短い期間（1〜4週間程度）を繰り返す形で進められ、実現したい機能や要求を一覧にしたプロダクトバックログの中から、そのスプリントで取り組む項目を選び出したスプリントバックログをもとに作業を進めていきます。

開発プロセスに関するフレームワーク

最後に、組織として開発の進め方を標準化するための枠組みも押さえておきましょう。ソフトウェア開発とその取引をより適正なものにするために、要件定義から保守までの作業項目をひとつひとつ定義し、標準化したものが共通フレーム（SLCP）です。発注する側と受注する側で、作業の範囲や責任の分担について認識のズレが起きないようにする、いわば「共通のものさし」の役割を果たします。

また、開発や保守のプロセスそのものがどれだけ組織的に成熟しているかを評価し、改善につなげるためのモデルがCMMI（能力成熟度モデル統合）です。CMMIでは、組織のプロセスの成熟度を5段階のレベルで定義しており、行き当たりばったりの状態から、標準化され、さらに継続的に改善されていく状態へと、段階的にレベルアップしていく考え方を示しています。自分たちの組織が今どの段階にいて、次に何を目指すべきかを客観的に把握するための物差しとして活用されます。