開発プロセス・手法

要点と定義

ソフトウェア開発手法は、作る対象や変更の頻度、品質上の要求に合わせて、作業を進めやすくするための考え方です。この節で押さえるのは、既存ソフトウェアから設計情報を読み取るリバースエンジニアリング、内部構造を改善するリファクタリング、XPの実践、スクラムのイベントです。

リバースエンジニアリングは、既存のプログラムやデータベース定義などを解析し、仕様や構成、設計情報を明らかにする作業です。たとえば、稼働中のデータベースの定義情報から、表や関係を整理した設計図を再構成することが該当します。既存のものから抽象度の高い情報を読み解く方向がポイントです。 ソフトウェアのソースコードや動作を調べて、仕様や構造を明らかにする場合も同じ考え方です。

リファクタリングは、外部から見た機能や振る舞いを保ったまま、内部構造を整理・改善することです。処理を読みやすく分けたり、重複を減らしたりして、保守しやすくします。利用者に見える結果を変える機能追加とは区別します。

XP（エクストリームプログラミング）は、アジャイル開発手法の一つです。代表的な実践には、ペアプログラミング、テスト駆動開発、継続的インテグレーション、リファクタリングがあります。ペアプログラミングでは二人が組み、実装と確認の役割を交替しながら作業します。知識を共有し、誤りを早く見つけやすくする狙いがあります。

テスト駆動開発では、まず期待する動作を確かめるテストを作り、そのテストを通す実装を行い、必要に応じて内部を改善します。継続的インテグレーションでは、変更したコードを頻繁に結合し、その都度ビルドやテストを行います。結合を後回しにせず、小さな不整合を早く検出する考え方です。XPではコードの結合とテストを繰り返します。

スクラムは、スプリントと呼ぶ一定期間の作業単位を用いるアジャイル手法です。デイリースクラムでは、開発チームが日々の進捗、次の作業、障害などを共有し、作業を調整します。スプリントプランニングは期間中の目標や作業を計画し、スプリントレビューは成果を確認してフィードバックを得る場です。レトロスペクティブは進め方を振り返り、改善点を決めます。イベント名は、何を共有・確認・改善するかで見分けます。

適用条件と例

既存システムの仕様書が不足していて、保守や移行のために構造を把握したいときは、コード、設定、データベース定義などを解析して設計情報を得ます。これはリバースエンジニアリングです。解析結果をもとに新しいシステム全体を作り直す工程まで含むとは限りません。また、解析で得た情報を使って開発・販売する場合は、権利者の権利や利用許諾契約に関する確認が必要です。契約で解析が制限される場合もあるため、許可や法的扱いを一律に断定できません。

リファクタリングの例として、同じ計算を複数箇所に書いていた処理を共通関数にまとめる場合を考えます。入力と出力、画面や外部機能の振る舞いが変わらないことをテストで確かめながら整理します。もし計算結果や利用者の操作手順が変われば、単なる内部改善ではなく機能変更も含んでいます。

小さな変更を頻繁に統合するチームでは、継続的インテグレーションが役立ちます。各変更後にテストを実行すれば、どの変更で問題が生じたかを絞り込みやすくなります。テストを後からまとめて作る進め方では、期待する動作の確認が遅れ、統合時に不具合が重なることがあります。XPの実践として問われる場合は、テストを先に用意することや、コード結合とテストを繰り返すことを手掛かりにします。

ペアプログラミングは、二人が同じ作業を見ながら、実装とレビューを進める場面に適します。一方が入力し、もう一方が設計や誤りを確認し、役割を交替します。一人で順番に作業するだけでは、この実践の特徴である同時の協働や相互確認がありません。

スクラムのイベントを選ぶときは、日々の状況共有ならデイリースクラム、スプリントの作業計画ならプランニング、完成した成果の確認ならレビュー、進め方の改善ならレトロスペクティブと整理します。例として、毎朝、担当者が昨日の作業と今日の予定、進行を妨げる問題を共有する場面はデイリースクラムです。イベント名の語感ではなく、目的と実施タイミングを対応させます。