開発プロセス・手法｜ウォーターフォール・XP・DevOps・リバースエンジニアリング【ITパスポート】

ソフトウェアの作り方は、最初に要求がどこまで決まっているかで選び分けます。

開発モデル ── 順に進めるか、確かめながら繰り返すか
構造化手法とオブジェクト指向
XP とアジャイルの技法
DevOps・MLOps とリバースエンジニアリング
開発プロセスの枠組み ── 共通フレームと CMMI
まとめ
この節で解ける公開問題

開発モデル ── 順に進めるか、確かめながら繰り返すか

ウォーターフォールモデルは、要件定義・設計・プログラミング・テストを上流の工程から順に進めるモデルです。前の工程の成果物（要件定義書や設計書）を固めてから次の工程に入り、最後の工程が終わったところで、できあがったシステムを引き渡します。計画が立てやすい反面、あとの工程で作るものが変わると前の工程までさかのぼることになり、手戻りが大きくなります。何を作るかが最初に固まっていて、途中で大きく変わらない仕事には、ウォーターフォールモデルが向いています。たとえば、記載する項目が法令で決まっている届出書類を作るシステムのように、作るものが開発の前から決まっている場合です。

主なソフトウェア開発モデルの4つ。ウォーターフォールモデル＝要件定義→設計→プログラミング→テストと階段状に、上流から順に1回で進める。プロトタイピングモデル＝本番の前に試作品を作り、利用者が触って要求を確かめる。スパイラルモデル＝渦巻きのように、部分ごとに繰り返し、少しずつ広げる。RAD＝少人数とツールで短期間に作る。

順に1回で進めるのがウォーターフォール。ほかの3つは、作って確かめることを繰り返します。

要求が最初には固まらないときは、作って確かめることを繰り返すモデルを使います。

作って確かめることを繰り返すモデル

プロトタイピングモデル　… 本番のシステムを作り込む前に、画面や操作の見本となる試作品（プロトタイプ）を作り、利用者に触ってもらって「これで合っているか」を確かめる。例：予約サイトの画面だけ動く見本を店のスタッフに使ってもらい、「電話番号の欄が要る」といった声を本番の設計に生かす

スパイラルモデル　… システムをいくつかの部分に分け、部分ごとに設計・開発・テストの1周を回して、渦巻きのように少しずつ範囲を広げていく。1周ごとに利用者の評価とリスクの見直しを入れる

RAD（Rapid Application Development）　… 少人数のチームが開発ツールと試作品を使い、利用者と確かめながら、決めた短い期間で作り上げる

アジャイル　… 機能を小さく分け、優先度の高いものから短い期間で開発とリリースを繰り返す。考え方とスクラムの進め方はアジャイルなふるまいの回で扱っている

プロトタイピングとスパイラルは、どちらも途中で利用者に見てもらいます。見分けるのは何のために作るかです。プロトタイピングは、要求を確かめるための見本づくりが中心で、確かめたあとに本番のシステムを作ります。スパイラルは、本番のシステムを部分ごとに作り足していく進め方です（各周の中で試作を使うこともあります）。

ある会社が、前例のない大規模なシステムを作ることになりました。最初から全体を作り切るのは危険が大きいので、 部分ごとに作っては利用者に評価してもらい、そのたびにリスクを見直しながら、少しずつ範囲を広げていくことにしました。最も合う開発モデルはどれですか。

構造化手法とオブジェクト指向

システムをどんな単位に分けて設計するかにも、代表的な考え方が2つあります。

構造化手法は、システムの機能を、大きなものから小さなものへ段階的に分けていき、処理の流れに沿って組み立てる手法です。 オブジェクト指向は、データとそれを扱う処理（手続き）をひとまとめにしたオブジェクトを単位に、システムを組み立てる手法です。オブジェクトの中身は外から隠し（カプセル化）、決まった窓口を通してやりとりするので、部品として再利用しやすくなります。構造化手法は機能を分けていき、オブジェクト指向はデータと処理をまとめた部品を組み合わせます。

構造化手法とオブジェクト指向。左＝構造化手法：受注処理を、注文を受ける・在庫を確かめる・出荷を指示する、の3つに分ける木の図。機能を大きなものから小さなものへ分ける。右＝オブジェクト指向：注文と商品の2つのオブジェクトが、それぞれデータと処理をひとまとめに持ち、互いにやりとりする。データと処理をひとまとめにした部品で組み立てる。

構造化手法は機能を分け、オブジェクト指向はデータと処理をまとめます。

UML（Unified Modeling Language）は、オブジェクト指向の設計などで使う、図の書き方を統一した表記法です。クラス図、アクティビティ図、ユースケース図など、目的ごとの図が決められています（アクティビティ図は情報システム戦略の回で扱っています）。

ユースケースは、利用者がシステムを使って何をするかを、利用者の目から見た使い方の単位でまとめたものです。ユースケース図では、人の形で描く利用者（アクター）と、楕円で描く使い方（「商品を注文する」など）を線で結びます。

XP とアジャイルの技法

XP（エクストリームプログラミング）は、アジャイル開発の手法の1つです。プログラマが毎日の開発で実践する技法（プラクティス）を、テスト駆動開発・ペアプログラミング・継続的インテグレーションなどの形でひとまとめにしています。 XP は1つの技法の名前ではなく、技法を束ねた手法の名前です。

同じアジャイルの手法でも、チームの役割と期間の区切り方を決めているのがスクラムです。スクラムチーム（プロダクトオーナー・開発者・スクラムマスター）、スプリント、プロダクトバックログ、ふりかえり（レトロスペクティブ）は、アジャイルなふるまいの回で扱っています。

XPのおもな技法の3つ。テスト駆動開発＝テストを先に書く→合格するコードを書く→整理する、の輪を回す。ペアプログラミング＝1つの画面に2人が向かい、書く人と確かめる人に分かれる。継続的インテグレーション＝複数のコードをこまめに統合して自動でテストする。

テストを先に書く、2人で1台、こまめに統合する。どれも品質を保ったまま速く変えるための技法です。

アジャイル開発で使う技法

ユーザーストーリー　… 実現したいことを「だれのために・何をしたいか・なぜか」の形で短く書いたもの。例：会員として、過去の注文を見たい。同じ商品をすぐ買い直したいから

テスト駆動開発　… コードより先にテストを用意し、まだ通らないことを確かめてから、通るだけのコードを書き、最後に整理する。例：送料を計算する部品なら、先に「3,000円以上の注文は送料0円」を確かめるテストを書く

ペアプログラミング　… 2人で1つの画面を共有して組む。キーボードを持って書く人（ドライバー）と、横で誤りに目を配り次の手を考える人（ナビゲーター）に分かれ、役割はこまめに交代する

リファクタリング　… 利用者から見た動きはそのままにして、プログラムの中の書き方や組み立てを読みやすく整える

継続的インテグレーション（CI）　… 各自が変更したコードを数時間ごとやコミットのたびにまとめ、ビルドとテストを自動で行う

スプリントバックログ　… スクラムで、今回のスプリントで作る項目をプロダクトバックログから選び、そのための作業に分けて書き出した一覧

リファクタリングかどうかは、利用者から見て何かが変わるかで見分けます。表示される金額が変わる、押せるボタンが増える、といった変化があれば、それはリファクタリングではありません。リファクタリングは、外から見た動きを変えずに中身だけを整えます。同じ計算を何か所にも書き写して読みにくくなったプログラムを、結果を変えずに1か所にまとめる、といった作業です。

稼働中の会員サイトのプログラムに、次の4つの変更を行います。リファクタリングにあたるのはどれですか。

DevOps・MLOps とリバースエンジニアリング

開発チームと運用チームが別々の部署に分かれていると、開発が仕上げたものを運用に渡すところで、待ちや行き違いが起きやすくなります。 DevOps は、開発（Development）と運用（Operations）が1つのチームのように目標を共有して協力し、テストや本番への反映を仕組みで自動にして、改良を小刻みに、途切れなく届け続ける取組です。たとえばネット通販の会社で、開発者が直したコードは自動でテストされ、問題が無ければその日のうちに本番に反映される。運用の担当は、本番での使われ方や障害の情報をすぐ開発に返し、次の改良につなげる、という形です。 DevOps の決め手は「開発側と運用側の連携」と「自動化」の2つです。

DevOps。開発と運用を無限大の形の輪でつなぐ。開発で作る→自動でテスト・本番へ移行→運用で動かして利用者の反応を見る→また開発へ、と回り続け、新しい機能を素早く、くり返し届ける。

開発と運用が1つの輪になって、作って届けることを途切れなく繰り返します。

MLOps は、同じ考え方を機械学習のモデルに当てはめたものです。モデルを作る側と運用する側が連携し、新しいデータで学習し直したモデルを素早く本番に入れ、本番での精度を見張り続けます。

リバースエンジニアリングは、できあがったソフトウェアを手がかりに、さかのぼってその設計や仕様を割り出す手法です。仕様から設計、設計からプログラムへと進むふつうの開発を、逆向きにたどります。たとえば、20年前に作られた在庫管理システムに手を入れることになったが、資料も当時の担当者も残っていない。そこでプログラムを読み解いて、どんな条件で発注をかけているかを書き出す、といった場面で使います。

ふつうの開発とリバースエンジニアリングの向きの違い。上の段＝ふつうの開発：仕様書→設計書→プログラムと右へ進む。下の段＝リバースエンジニアリング：プログラムを解析して、設計書→仕様書へと左へ逆向きにたどる。

リバースエンジニアリングは、できあがったプログラムから仕様や設計を取り出します。

開発プロセスの枠組み ── 共通フレームと CMMI

共通フレームは、ソフトウェア開発とその取引を適正にするために、そのもとになる作業項目を一つ一つ定義して標準化したもので、 SLCP（Software Life Cycle Process）とも呼ばれます。IPA が「共通フレーム2013」として発行しています。発注する側と開発する側が「要件定義」「設計」などの言葉を同じ意味で使い、どの作業をだれがするかを取り決めるための共通の物差しです。

CMMI（Capability Maturity Model Integration：能力成熟度モデル統合）は、開発と保守のプロセスを評価して改善するために、システム開発組織のプロセスがどこまで成熟しているかをモデルにしたものです。成熟度を5段階のレベルで定義し、成り行きまかせで結果が予測しにくいレベル1（初期）から、プロセスを継続的に改善し続けるレベル5（最適化）までで、組織の開発力を測ります。共通フレームは作業と言葉をそろえる物差し、CMMI は組織の開発プロセスの成熟度を測る物差しです。