開発モデルと開発工程

• 日程: Day 2 / セッション 5
• 時間: [13:00-13:30]
• 形式: 座学
• ゴール: 代表的な開発モデル（ウォーターフォール、V字、アジャイル、スパイラル、RAD、インクリメンタル、プロトタイピング）の特徴を一言ずつ言える。機能要件と非機能要件の違いを、自分の開発テーマの例つきで説明できる
• 学習形式: 対話型解説

午前中、お疲れさまでした。手元には「情報モデル一覧」「状態遷移図」「機能一覧」「プレゼンテーション一覧」が揃っているはずです。

ここで一度、手を止めて考えてみてください。

いま自分が作っているこれらの成果物は、ソフトウェア開発全体の「どこ」の作業なのでしょうか？

登山に例えると、午前中のあなたは夢中で岩場を登っていました。このセッションは、尾根に出て地図を広げる時間です。山全体（開発の全工程）を眺め、自分の現在地に旗を立てます。

現在地が言えると、次の2つが変わります。

• これから作る成果物が「何のための材料か」を説明できる
• 「あとで直せばいい」ものと「いま決めるべき」ものを区別できる

このセッションでは「開発とは何か」「開発モデルにはどんな種類があるか」「開発の工程はどう並ぶか」を順に見ていきます。最後に午前の成果物を工程図の上にマッピングします。

「開発」という言葉に、どんなイメージがありますか？　プログラムを書くこと？　それは開発の一部にすぎません。

開発とは、次の2つを行う活動です。

• 有用なものを生み出すこと
• 人の営みを「システム化」すること

ポイントは「有用な」の部分です。誰にとって有用か——そう、Day 1 から繰り返している「ペルソナにとって」です。動くプログラムを書いても、ペルソナに価値が届かなければ開発は成功していません。

料理に例えると、開発は「レシピを考えて料理を作り、食べる人に出すまで」の全体です。コーディングは「加熱調理」にあたる一工程にすぎません。加熱が上手でも、食べる人の好みを外したら失敗です。

「システム化」の例を対比で見てみましょう。

• 該当する例: 紙のレシート集計を、家計簿システムの「支出登録」機能に置き換える。人の営み（家計管理）がコンピュータで再現され、集計が自動になる
• 該当しない例: レシートをスキャンして画像フォルダに溜めるだけ。データは増えるが、家計管理という営みは楽になっていない。「デジタル化」であって「システム化」ではない

• 開発の目的は「コードを書くこと」ではなく「有用なものを生み出すこと」
• 「誰にとって有用か」の答えがペルソナ。開発の話になっても Day 1 の軸は変わらない

「開発」を英語にすると develop。語源は「包み（velop）を解く（de-）」、つまり「包まれていたものを開いて現す」です。写真の「現像」も develop と言います。開発とは、ペルソナの中に包まれていた価値を、目に見える形に現像する作業——そう考えると、Day 1 でやった「暗黙知を形式知にする」話と同じ構図だと気づきませんか。

開発の進め方には「型」があります。これを開発モデルと呼びます。代表的な7つを、一言ずつで押さえましょう。

ここで少し考えてみてください。なぜ型が7つも（実際はもっと）あるのでしょうか？

答えの1つは「作るものの性質が違うから」です。仕様が固まりきった銀行の勘定系と、正解が誰にも見えない新サービスでは、適した進め方が違います。服にS/M/Lやフォーマル/カジュアルがあるのと同じで、状況に合わせて選ぶものです。

この研修自体も、実は開発モデルに沿っています。Day 1 から「PDCAを小さく沢山回す」「定義→価値の確認→再定義を繰り返す」と言われてきましたね。これはアジャイル・反復型の考え方そのものです。

家計簿システムを例に、モデルの違いを見てみます。

• ウォーターフォールなら: 全機能の要件を確定→全設計→全実装→全テスト、を一直線に進める。途中で「レシート読み取りも欲しい」と言われると手戻りが大きい
• アジャイル／インクリメンタルなら: まず「支出登録と一覧表示」だけ作って使ってもらい、次の周回で「月次レポート」を足す。要望の変化に強い
• プロトタイピングなら: 最初に画面の試作品（今日の最後に作るモックアップ！）を見せ、「入力項目はこれで足りる？」を確認してから作り込む

• 7つのモデルは暗記対象ではなく「選択肢」。特徴を一言で言えれば、比較して選べる
• 詳しい使い分け（XP、Scrum など）は Day 3 の「開発手法」で扱う。今日は名前と一言をつかめば十分

ウォーターフォールの元祖とされるのは、ウィンストン・ロイスが1970年に書いた論文です。ところが原論文を読むと、ロイスは一方通行の工程図を示した直後に「この進め方はリスクが大きく、失敗を招く」と書き、前工程への反復（フィードバック）を推奨しています。つまり「ウォーターフォールの父」は、ウォーターフォールの危うさを最初に警告した人でした。図だけが独り歩きして世界標準になってしまった——「情報は受け手によって意味が変わる」という、こうもり問題の壮大な実例かもしれません。

モデルが「進め方の型」なら、工程は「作業の種類」です。どのモデルを選んでも、次の5つの工程は必ず登場します（順番や繰り返し方が変わるだけです）。

1. 要件: 何を実現すべきかを決める（機能要件・非機能要件）
2. 仕様: 要件を満たすために、システムが外から見てどう振る舞うかを決める
3. 設計: 振る舞いを実現する内部の構造を決める
4. 実装: 設計をコードにする
5. テスト: 要件・仕様どおりに動くか検証する

要件は2種類に分かれます。ここが今日いちばん大事な区別です。

• 機能要件: システムが「何をするか」。例:「家計簿に支出を登録できる」
• 非機能要件: システムが「どの程度うまくやるか」。例:「支出登録は3秒以内に完了する」

同じ「支出登録」の話でも、「登録できる」は機能要件ですが、「3秒以内」「同時に100人使える」「パスワードで保護される」は非機能要件です。機能要件だけ満たして非機能要件を外すと、「動くけれど遅くて誰も使わないシステム」ができあがります。

では、午前の成果物を工程の上に置いてみましょう。

あなたの現在地は「要件〜仕様」のあたりです。Day 3 で設計、Day 4 で実装とテストへ進みます。4日間の研修は、開発工程をひととおり歩く旅でもあるのです。

参考に、V字モデルで見ると工程とテストは次のように対になります。

家計簿システムの「月次レポート」で5工程を通してみます。

• 要件: ペルソナは月末に使いすぎを振り返りたい（機能要件: 月次集計を表示できる／非機能要件: 5秒以内に表示）
• 仕様: 「レポート画面で年月を選ぶと、カテゴリ別合計と前月比が表示される」
• 設計: 支出モデルを月・カテゴリで集計するAPIと画面の構造を決める
• 実装: JavaScript で集計処理と画面を書く
• テスト: 月末データで5秒以内に正しい合計が出るか検証する

• 「工程」はどのモデルでも共通。モデルは工程の「並べ方・繰り返し方」の違い
• 機能要件は「何をするか」、非機能要件は「どの程度うまくやるか」。この区別が次のセッションの主役
• 午前の成果物は要件〜仕様に位置する。だからこそ「情報」由来であること（ペルソナ視点）が効いてくる

V字モデルの右半分（テスト）は、左半分（定義）と鏡写しです。つまり「要件が曖昧だと、システムテストで何を確認すべきかも曖昧になる」ということ。テストの失敗の多くは、実はテスト工程ではなく要件工程で仕込まれています。「バグは書いた瞬間ではなく、決めなかった瞬間に生まれる」と言われるゆえんです。

• 「アジャイルとインクリメンタルの違いを、家計簿システムを例に説明してください」
• 「私の開発テーマは〇〇です。ウォーターフォールとプロトタイピングのどちらが向いているか、理由つきで意見をください。私も反論します」
• 「『支出をカテゴリ別に集計できる』という要件に対して、セットで考えるべき非機能要件の候補を3つ挙げてください」

今回学んだことを一言でまとめると「開発には工程という共通の地図があり、あなたはいま要件〜仕様の地点にいる」です。

• 開発とは、ペルソナにとって有用なものを生み出し、システム化すること
• 開発モデルは7つの「進め方の型」。特徴を一言ずつ言えれば選択の土台になる
• 工程は「要件（機能・非機能）→仕様→設計→実装→テスト」。午前の成果物は要件〜仕様に対応する

地図を見ると、1つ空白が残っています。非機能要件です。「何をするか」は機能一覧に出せましたが、「どの程度うまくやるか」はまだ誰も決めていません。次のセッションでは、ペルソナの視点で非機能要件を定義し、「非機能要件一覧書」を作ります。

• 7つの開発モデルのうち3つを選び、それぞれ一言で特徴を言えますか？
• 「支出登録」を題材に、機能要件と非機能要件の例を1つずつ言えますか？
• 今日午前に作った機能一覧は、開発工程のどこに位置しますか？

• 参考リンク: IPA「共通フレーム」（ソフトウェアライフサイクルプロセスの日本語ガイド）、Winston W. Royce "Managing the Development of Large Software Systems" (1970)
• 発展課題: 自分の開発テーマにいちばん合う開発モデルを1つ選び、選んだ理由と「採用しなかったモデル」の理由を一文ずつ書いてみましょう。Day 3 の開発手法のセッションで答え合わせができます