開発技術

基本の仕組み

「利用者が空き枠を選び予約を完了できる」は機能要件、「繁忙時も3秒以内に一覧を表示する」は条件を定めた非機能要件の例です。

要件定義で必要なことを合意し、設計で実現方法を決め、実装とテストで確認します。受入テストでは依頼者の目的を満たすかを評価します。

実装が仕様書どおりでも、仕様が利用者の必要とずれていれば目的は達成できません。各要件に確認方法を対応させておきます。

要件から保守まで

開発は、企画→要件定義→設計→実装→テスト→移行→運用・保守の順に進みます。機能要件は「何ができるか」という処理の内容、非機能要件は性能・可用性・信頼性・セキュリティ・保守性など「どの程度の品質で動くか」の条件です。

要件定義の段階で受入れの条件（何を満たせば完成とするか）を決め、利用者側の承認を得ておきます。要件→設計→テストの対応を後からたどれるようにしておくことを追跡可能性（トレーサビリティ）といい、要件の漏れや過剰な機能を見つけやすくなります。

基本の仕組み

送料計算を一つのモジュールへまとめれば、送料ルールの変更時に画面ごとに修正する手間を減らせます。呼出し側は必要な入力と結果だけを扱います。

凝集度は一つのモジュール内の仕事のまとまり、結合度はモジュール間の依存の強さです。責任が明確で、内部実装への依存が少ない構造を目指します。

単にファイルを細かく分けても、互いの内部状態を直接書き換えるなら依存は強いままです。境界と公開するインタフェースを考えます。

結合度と凝集度の段階

モジュールの独立性は、結合度が低いほど、凝集度（モジュール強度）が高いほど高いと評価します。外部に見せるインタフェースを明確にして内部の実装を隠す（情報隠蔽）と、内部を変更しても利用側を直さずに済みます。

結合度は、モジュール間で何を受け渡すかで段階が分かれます。必要なデータ項目だけを引数で渡すデータ結合が最も弱く望ましい結合で、他のモジュールの内部を直接参照・変更する内容結合が最も強い結合です。

凝集度は、高い順に機能的強度、情報的強度、連絡的強度、手順的強度、時間的強度、論理的強度、暗合的強度です。一つの機能だけを実行するモジュールが最も望ましく、「初期化処理をまとめただけ」のように実行時期が同じだけのもの（時間的強度）や、無関係な処理の寄せ集め（暗合的強度）は低い評価です。

基本の仕組み

18歳以上を受け付ける処理なら、17・18・19を試すと境界の前後を確認できます。19だけでは「18より大きい」と実装された誤りを見逃すかもしれません。

同値分割は同じ扱いになる入力をグループ化し、境界値分析はその境目を重視します。ホワイトボックステストでは、分岐や経路など内部構造を基に確認します。

テストに通っても誤りが一切ないと証明できるわけではありません。正しい入力だけでなく、異常値や欠落、操作順の違いも仕様に沿って考えます。

テストの段階と結合テストの進め方

単体テストはモジュール内部の処理、結合テストはモジュール間のインタフェース、システムテストは性能や負荷を含めた要件全体、受入テスト（運用テスト）は発注者や利用者が業務で使えるかを確かめます。修正後に、変更していない部分へ悪影響が出ていないかを確かめるのが回帰テスト（リグレッションテスト）です。

結合テストを上位のモジュールから進めるトップダウンテストでは、まだできていない下位モジュールの代わりにスタブを使います。下位から進めるボトムアップテストでは、呼出し元となる上位モジュールの代わりにドライバを使います。

ブラックボックステストと網羅の基準

ブラックボックステストは内部構造を見ずに仕様から入力を選びます。「18歳以上を受け付ける」なら、18以上が有効同値クラス、17以下が無効同値クラスで、同値分割ではそれぞれから代表値を一つずつ選びます。境界値分析（限界値分析）では、境目の17と18を必ず含めます。

ホワイトボックステストは、内部の命令や分岐をどこまで実行したか（網羅、カバレージ）を基準にします。「AかつBなら処理Xを行う」という判定一つなら、命令網羅はAとBがともに真の1ケースで満たせますが、判定条件網羅（分岐網羅）には判定が偽になるケースも必要です。

条件網羅は、AとBがそれぞれ真と偽をとればよいので、（A真・B偽）と（A偽・B真）の2ケースでも満たせます。ただし、この2ケースでは判定がどちらも偽になるため、処理Xが一度も実行されず、判定条件網羅も命令網羅も満たしません。条件の真偽のすべての組合せを試す複数条件網羅が最も強い基準です。

基本の仕組み

作成者が予約の取消し処理を順に説明し、参加者が「取消し後の在庫は戻るか」と質問すると、実装前に仕様漏れを見つけられます。

ウォークスルーは作成者の説明を基に確認する方法、インスペクションは役割や手順を定めて系統的に欠陥を探す方法です。目的と進め方を区別します。

作成者の能力を評価する場にすると、問題を隠したり議論が脱線したりします。成果物の具体的な不整合と修正判断に焦点を当てます。

レビューの種類

ウォークスルーは作成者が主催し、成果物を順に説明しながら参加者と検討します。インスペクションは、作成者ではないモデレーター（進行役）が主導し、事前に資料を読んだ参加者が決められた役割と手順で欠陥を指摘し、結果を記録して修正まで確認します。

ほかに、参加者が持ち回りで進行役を務めるラウンドロビン、同じ立場の開発者同士で見るピアレビュー、作成者自身が見直す机上チェックなどがあります。レビューは実行しない静的な検証、テストはプログラムを動かす動的な検証です。レビューの場では欠陥の指摘に集中し、直し方の議論や修正作業は分けて行います。

基本の仕組み

予約画面の試作品を利用者に触ってもらい、短い周期で改善するのが反復的な進め方です。動く成果を使って認識のずれを小さくします。

ウォーターフォールは工程を段階的に進め、アジャイルは短い反復で価値ある成果を届けながら変化へ対応します。どちらも品質管理や関係者との合意は必要です。

アジャイルは計画も文書も不要という意味ではありません。優先順位、完了条件、振り返りがなければ、ただ作り直しを続ける状態になります。

開発モデルの使い分け

ウォーターフォールモデルは工程を順に確定させ、原則として前の工程へ戻らない前提で進めます。プロトタイピングモデルは試作品を利用者に見せて要求の認識を合わせ、スパイラルモデルはリスクを評価しながら設計・開発を繰り返します。

システムを機能ごとに分け、段階的に作って順次リリースするのが段階的モデル（インクリメンタルモデル）、全体を作ってから要求の変化に合わせて改良を重ねるのが進展的モデル（エボリューショナリモデル）です。DevOpsは開発チームと運用チームが連携し、自動化されたビルド・テスト・リリースで迅速に改善を続ける考え方です。

スクラムの役割とイベント

スクラムでは、プロダクトオーナーがプロダクトの価値を最大化する責任を持ち、プロダクトバックログの項目や順序を明確にします。例えば予約機能と通知機能のどちらを先に届けるかを、利用者の価値から整理します。開発者へ実装手順を一方的に命令する役割とは区別します。

デイリースクラムは、開発者がスプリントゴールへの進み具合を確認し、直近の作業計画を調整する15分のイベントです。管理者へ一人ずつ成果を報告するだけの会議ではありません。障害を見つけたら、必要な詳しい議論を別途行うこともできます。

バーンダウンチャートは、横軸に時間、縦軸に残作業量を置いて進捗を見る方法です。完了した量の累計を描くグラフと混ぜないようにします。線が下がらない場合は未完了の作業や見積りの変化を確認しますが、グラフだけで価値や品質を保証することはできません。

スクラムマスターは、スクラムの理論と実践をチームや組織が理解できるよう支援し、チームの有効性に責任を持ちます。スプリントは1か月以内の固定期間で、その中にスプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブが含まれます。

XPの代表的なプラクティス

XP（エクストリームプログラミング）では、テスト駆動開発（先にテストを書き、それを通すようにコードを書く）、ペアプログラミング（二人一組で一つのコードを書く）、リファクタリング（外部から見た動作を変えずに内部構造を改善する）、継続的インテグレーション（頻繁に統合し、ビルドとテストを自動で実行する）などを実践します。

今必要でない機能は作らないというYAGNI（You Aren't Gonna Need It）の考え方や、特定の担当者に限らず誰でもコードを修正できるソースコードの共同所有もXPの特徴です。リファクタリングは機能追加や不具合修正とは目的が違う点に注意します。

基本の仕組み

図形に面積を求める操作を定め、円と長方形で計算方法を実装すれば、利用側は同じ操作で面積を求められます。実際の図形の種類によって処理が変わるのが多相性です。

クラスは属性と操作を定義し、オブジェクトはその具体的な実体です。カプセル化は内部状態へのアクセスを管理し、継承は既存の定義を引き継ぎます。継承先で操作の実装を置き換えるのがオーバーライドです。

同じ名前でも引数が違うオーバーロードと、継承した操作を再定義するオーバーライドは別です。継承すれば常に良い設計になるわけではなく、親として扱ったときに約束した振る舞いを守れるかを確かめます。

オブジェクト指向の基本

クラス間の関係では、汎化と特化（is-a関係）と、集約（part-of関係）を区別します。「円は図形の一種」のように共通の性質を上位のスーパークラスにまとめるのが汎化、その逆に下位のサブクラスへ具体化するのが特化です。「エンジンは自動車の一部」のような全体と部分の関係が集約です。

委譲は、あるオブジェクトが受け取った処理の要求を、別のオブジェクトに任せて実行させる仕組みです。継承を使わずに機能を再利用する方法として使われます。