1-1ソフトウェア開発モデル
11月のはじめ、こむぎ堂の工房にはシュトーレンのスパイスの香りが漂い始めていました。予約の受付は12月1日からです。店長は粉を量る手を止めて言いました。「今年は予約のときに受け取り日を選べるようにしたいな。それと、焼き上がったらお客さんのスマートフォンに知らせが届くとうれしい」。ミナトはその晩から、作りたいことを全部書き出した仕様書を作り始めました。画面の一覧、入力の項目、エラーのときの文言。1か月がたつころには、仕様書は30ページを超えていました。ところが動く画面はまだ1枚もなく、そのあいだに店長の希望は3回変わっています。ミナトは相棒に打ち込みました。「書き直してばかりで、ちっとも作り始められないんだけど」
相棒は、ミナトのやり方に名前があることから教えてくれました。要件定義、設計、プログラムの製造、テストという工程を順番に一つずつ終わらせ、前の工程には戻らないことを前提に進める開発モデルをウォーターフォールモデルといいます。水が滝を上から下へ落ちるように、工程が一方向に流れるところからついた名前です。
このモデルは、作るものが最初からはっきり決まっているときに力を発揮します。工程ごとに成果物と区切りがあるので、進み具合を測りやすく、大きな開発でも人を割り振りやすいからです。弱点は、後の工程で要求の誤りが見つかったときです。テストの段階で「受け取り日は土日だけでいい」と言われたら、要件定義まで戻って作り直すことになり、戻る工程が多いほど手間がかさみます。ミナトの1か月は、まさにこの弱点に当たっていました。
要求がはっきりしないなら、先に形にして見せればよいはずです。開発の早い段階で試作品（プロトタイプ）を作って利用者に触ってもらい、その評価を反映しながら要求を固めていく開発モデルをプロトタイピングモデルといいます。紙に書いた画面の一覧より、指で押せる予約画面のほうが、店長は「ここはこうしたい」を言いやすくなります。
試作と評価を、一度ではなく何度も繰り返す考え方もあります。システムをいくつかの部分に分け、部分ごとに設計・開発・評価の流れを回しながら、らせんを描くように少しずつ大きくしていく開発モデルがスパイラルモデルです。1周ごとに「このまま進めて大丈夫か」というリスクを確かめてから次の周に入るのが特徴です。
期間の短さを第一に置くやり方もあります。開発支援のツールやプロトタイプを使い、少人数で、期間を区切って素早く作り上げる手法をRAD（Rapid Application Development）といいます。利用者が開発に加わり、試作を見ながらその場で決めていくことで、待ち時間を減らします。
ここから基本情報！分けて作る2つのモデル
システムを一度に全部作らず、何回かに分けて作るモデルには、要求をいつ決めるかで2つの型があります。最初に全体の要求を決めておき、それを機能の単位に分けて、単位ごとに開発とリリースを繰り返すのが段階的モデル（インクリメンタルモデル）です。こむぎ堂でいえば、受け取り日の指定と焼き上がり通知の両方を先に決めたうえで、受け取り日の指定を先に出し、通知は次の回に出す、という分け方になります。
これに対して、最初の時点では要求を決めきれないことを前提に、版を出すたびに利用者の反応を見て要求そのものを見直し、次の版で作り直したり広げたりしていくのが進展的モデル（エボリューショナリーモデル）です。段階的モデルが「決まった全体を分けて届ける」のに対し、進展的モデルは「届けながら全体を決めていく」と考えると区別しやすくなります。
似た製品をいくつも作る組織では、別の工夫があります。複数の製品に共通する部品や基盤をコア資産としてあらかじめ整え、それを再利用しながら、製品ごとに違う部分だけを作り足して製品群をまとめて開発する手法をソフトウェアプロダクトラインといいます。予約の仕組みをパン屋、ケーキ屋、和菓子屋向けに作り分ける会社なら、予約の受付やお知らせの部分を共通にして、品書きの画面だけを店ごとに変える、という作り方です。
基本情報の範囲ここまで
1-2アジャイルの概要
相棒の提案は短いものでした。「全部を決めてから作るのをやめて、2週間で動く部分を一つ作り、店長に見せて直してもらう。それを繰り返そう」。ミナトは30ページの仕様書を閉じ、最初の2週間で作るものを、受け取り日を選ぶ画面だけに絞りました。
短い期間で動くソフトウェアを作っては見せ、利用者の声と変化を取り込みながら開発を繰り返す手法をまとめてアジャイル（アジャイル開発）と呼びます。英語の agile は「素早い、機敏な」という意味です。計画を最後まで守り切ることより、途中で変わる要求に合わせて向きを変えられることを大事にします。
アジャイルでは、作る機能を「利用者が何のために何をしたいか」という短い文で書き出すことがよくあります。「予約するお客さんとして、受け取り日を選びたい。仕事帰りに寄れる日に取りに行けるから」のような文で、これをユーザーストーリーといいます。30ページの仕様書の代わりに、こうした文を1枚ずつ付箋に書けば、店長はどれを先に作るかを並べ替えるだけで決められます。
ここから基本情報！アジャイルの価値観と反復の単位
アジャイルという言葉が広まるきっかけになったのは、2001年に開発者たちが公表したアジャイルソフトウェア開発宣言です。宣言は4つの価値を、左の項目により価値を置くという形で並べています。プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を。右の項目にも価値はあると断ったうえで、左を重んじるという書き方です。
この4つの価値を、日々の開発で守る行動に落とし込んだのがアジャイルソフトウェアの12の原則（アジャイル宣言の背後にある原則）です。価値のある動くソフトウェアを早く継続的に届けて顧客を満足させること、開発の後半であっても要求の変更を歓迎すること、動くソフトウェアを数週間から数か月という短い間隔で届けることなどが含まれます。
短い期間で計画・設計・実装・テストをひと回りする、その1回分のまとまりをイテレーションといいます。ミナトが決めた「2週間」が、イテレーションの長さです。期間をあらかじめ固定しておき、その中で終わる分だけを作る、という区切り方をします。
作り方にも工夫があります。チームの全員が同じ時間に同じ場所に集まり、1台のコンピュータの画面を見ながら一つのコードに一緒に取り組む手法をモブプログラミングといいます。キーボードを打つ人は交代しながら、残りの全員が考えを出し合います。次の節で見るペアプログラミングを、2人からチーム全体に広げた形です。
基本情報の範囲ここまで
繰り返しの区切りごとに欠かせないのが、立ち止まって進め方を見直す時間です。区切りの終わりに、うまくいったことと困ったことをチームで話し合い、次の期間のやり方を改める活動をふりかえり（レトロスペクティブ）といいます。ふりかえりで見直すのは、作ったものの出来よりも、チームの作り方のほうです。
ここから基本情報！ふりかえりの型
ふりかえりの進め方の代表がKPTで、3つの見出しに分けて書き出します。続けたいよかったことがKeep、うまくいかなかったことや困りごとがProblem、それを踏まえて次の期間に試す具体的な行動がTryです。
最初の2週間を終えたミナトのKPTは、こうなりました。Keepは「金曜の閉店後に店長へ画面を見せたこと」。Problemは「土日の朝は店長が忙しく、質問の返事が月曜まで止まったこと」。Tryは「質問は木曜までに付箋で渡す」。Tryは、次の期間にやったかどうかを確かめられる行動として書くのがこつです。
基本情報の範囲ここまで
1-3XP（エクストリームプログラミング）
受け取り日の画面を作っている途中、ミナトは12月31日の次の日付が「12月32日」と表示されるのに気づきました。直したつもりが、今度は2月が31日まであります。相棒は「直す前に、正しい答えを先に書いておこう」と言いました。
アジャイルの手法のうち、プログラムを書く現場の習慣まで細かく決めているのがXP（エクストリームプログラミング）です。よいとされる実践を、極端（extreme）なほど徹底するという意味の名前で、短い間隔でのリリースと、技術的な実践（プラクティス）の積み重ねを重んじます。
相棒の言った「正しい答えを先に書く」が、XPの代表的な実践であるテスト駆動開発（TDD）です。プログラム本体より先に、「12月31日の次は1月1日」「2027年2月の最後の日は28日」のように、満たすべき結果を確かめるテストのコードを書きます。最初はテストが失敗します。そのテストに通る最小限のコードを書き、通ったら次のテストを足す、という順で進めます。日付の扱いを後から書き換えても、テストを流せば前に直した所が正しく動き続けているかをすぐに確かめられます。
テストに通ったコードは、動いていても読みにくいままのことがあります。外から見た動きは変えずに、プログラムの中の構造を整理し直して読みやすく直すことをリファクタリングといいます。動きを変えていないことは、先に書いたテストが保証してくれます。テスト駆動開発とリファクタリングは、組にして使うことで安心して直せるようになります。
XPには、2人1組でプログラムを書くペアプログラミングもあります。1台のコンピュータの前で、1人がコードを書き、もう1人がそれを見ながら誤りや設計の方向を確かめ、役割を交代しながら進めます。書いた後にまとめて見直すより、書いているその場で誤りに気づけるのが利点です。
ここから基本情報！XPのほかの実践
何をどの順で作るかの決め方も、XPは実践として定めています。顧客が作ってほしい機能をストーリーとして示し、開発者がそれぞれの手間を見積もり、その見積りをもとに顧客が優先順位を決めて、次のリリースやイテレーションの範囲を決める活動を計画ゲームといいます。「受け取り日の指定は4日、通知は6日」と聞いた店長が、受け取り日を先にすると決めるのが、その形です。
コードの持ち主も決め方の一つです。特定の担当者だけが自分の書いた部分を直すのではなく、チームの誰もがコードのどの部分でも直してよいとする考え方をソースコードの共同所有といいます。担当者が休んでも作業が止まらず、ペアプログラミングやテストがあることで、他人の書いた部分も安心して直せます。
作りすぎを戒める原則もあります。「いつか要るかもしれない」機能を先回りして作らず、いま必要なものだけを作る、という原則をYAGNI（You Aren't Gonna Need It：それはきっと必要にならない）といいます。ミナトが「来年はケーキの予約もするかも」と考えて作りかけた画面は、YAGNIに従えば今は作りません。必要になったときに作るほうが、使わない部品を保守し続ける手間がかかりません。
基本情報の範囲ここまで
変更をこまめに一つにまとめ、そのたびに自動でテストする習慣もXPの実践の一つで、開発と運用の連携の中で改めて取り上げます。
1-4スクラム
2週目の金曜の閉店後、店長はホワイトボードの前で腕を組んでいました。付箋には「受け取り日を選ぶ」「焼き上がりを知らせる」「予約を取り消す」が並んでいます。相棒がミナトに勧めたのは、どれを先に作るかを決めるのは店長の役目にする、ということでした。
アジャイルの中で、チームの役割と、繰り返しの区切りで行う決まった行事（イベント）を定めた枠組みがスクラムです。XPがプログラムの書き方の実践に重きを置くのに対し、スクラムは「誰が何を決め、どんな区切りで進めるか」というチームの進め方を定めています。名前はラグビーのスクラムから来ています。
スクラムで開発を担う一つのチームをスクラムチームと呼び、3つの役割の人で構成します。作るものの価値をいちばん大きくする責任を持ち、何をどの順で作るかを決めるのがプロダクトオーナーです。決めたものを実際に作り、出来上がりの品質に責任を持つのが開発者です。スクラムが決まりどおりに回るようにチームを支え、作業の妨げになっている問題を取り除くのがスクラムマスターです。こむぎ堂では、店長がプロダクトオーナー、ミナトが開発者、進め方を助言する相棒がスクラムマスターに近い役回りになりました。
スクラムの繰り返しの1回分をスプリントといいます。長さは1か月以内の決まった期間に固定し、スプリントが終わればすぐ次のスプリントが始まります。こむぎ堂のスプリントは2週間です。
作りたいことの一覧にも、スクラムでは名前があります。プロダクトに必要な機能や改善を、優先順位の高い順に並べた一覧がプロダクトバックログで、並べ方を決めるのはプロダクトオーナーです。そこからこのスプリントで仕上げる項目を選び、それを作るための作業の計画を添えたものがスプリントバックログです。ホワイトボードの付箋の列全体がプロダクトバックログで、今週の枠に移した付箋がスプリントバックログ、という見立てになります。
ここから基本情報！スプリントの中の行事
1つのスプリントは、決まった行事で区切られています。始まりに、このスプリントで何を作り、どう進めるかを話し合って決めるのがスプリントプランニングです。ここでプロダクトバックログから項目を選び、スプリントバックログを作ります。
スプリントの期間中は、毎日同じ時刻・同じ場所で、開発者が短く集まります。前の日からの進み具合と、目標に向けて困っていることを確かめ合い、その日の計画を立て直す場がデイリースクラムで、15分以内で終えることになっています。こむぎ堂では、開店前の仕込みの合間の5分がそれに当たりました。
スプリントの終わりには、出来上がったものを関係者に見せて意見をもらい、次に何を作るかを話し合うスプリントレビューを行います。金曜の閉店後に店長が画面を触ってみる時間がこれです。その後に、チームの進め方を見直すふりかえり（スクラムではスプリントレトロスペクティブ）を行って、1つのスプリントが閉じます。
基本情報の範囲ここまで
1-5DevOps
受け取り日の画面が動き始めると、別の困りごとが出てきました。直したプログラムをお店の予約サイトに載せるのは、毎回ミナトが閉店後に手作業でしていて、ファイルを1つ上げ忘れた晩には、翌朝まで予約の画面が開かなかったのです。店長は言いました。「作るのが速くなっても、届けるところで止まっていたら同じだね」
作る側（開発）と、動かし続ける側（運用）が分かれていると、開発は早く新しい機能を出したがり、運用は止まらないことを優先して変更を嫌う、という食い違いが起きがちです。開発（Development）と運用（Operations）のチームが協力し、ツールによる自動化と、互いの目標を共有する文化の両面から、新しい機能を素早く、しかも安定して届け続けようとする考え方をDevOpsといいます。
DevOpsを支える仕組みの一つ目が継続的インテグレーション（CI）です。開発者が書き換えたコードを、共有の保管場所に小さく頻繁に取り込み、取り込むたびにビルドとテストを自動で流します。何日分もの変更をまとめて合わせると、どの変更が原因で壊れたのかを探すのに手間がかかります。小さく合わせていれば、壊れた原因はいま取り込んだ変更の中にあります。
二つ目は、その先の段階を自動にする継続的デリバリー（CD）です。テストに通った変更を、本番の環境に出す一歩手前まで自動で準備し、いつでもリリースできる状態を保ちます。本番に出す最後の判断は人が行います。こむぎ堂なら、ミナトが手で上げていたファイルの準備が自動になり、店長の「出していいよ」を合図にボタン一つで出せるようになります。
ここから基本情報！自動で届ける先と、信頼性の守り方
最後の判断まで自動にしたものが継続的デプロイ（Continuous Deployment）です。テストに通った変更は、人の承認を待たずにそのまま本番の環境へ反映されます。継続的デリバリーとの違いは、本番に出す手前で人が判断するかどうかの一点です。どちらも略すと「CD」になるので、試験の文では「人の承認を挟むか」で見分けます。
運用の側をソフトウェアの技術で支える考え方もあります。システムの信頼性を数値の目標として定め、監視や障害への対応、運用の作業の自動化を、ソフトウェア開発の手法で進めるやり方、またはその役割を担う職種をSRE（Site Reliability Engineering：サイト信頼性エンジニアリング）といいます。2003年にGoogleの社内で始まったやり方です。
障害は、起きてから慌てるより、起こしてみて備えるほうが安く済みます。動いているシステムにわざと障害を起こし、一部が止まっても全体が動き続けるかを確かめて弱い所を見つける手法をカオスエンジニアリングといいます。予約サイトでいえば、通知を送る仕組みをわざと止めてみて、予約の受付まで止まらないかを確かめることに当たります。
セキュリティも、最後にまとめて点検するのでは遅くなります。開発と運用の流れの初めから、セキュリティの点検や対策を組み込んでおく考え方がDevSecOpsで、DevとOpsのあいだにSecurityのSecを入れた名前です。CIでテストを流すときに、使っている部品に既知の脆弱性がないかも自動で確かめる、といった形をとります。
基本情報の範囲ここまで
DevOpsの考え方は、機械学習にも広がっています。店長はいつか、天気と曜日からシュトーレンの売れ行きを予想するAIを使ってみたいと話しています。機械学習のモデルは、作って終わりではなく、新しいデータで学習し直し、予想が外れ始めていないかを監視し続ける必要があります。こうしたモデルの開発から運用・監視までを、DevOpsの考え方で継続的に回す取り組みをMLOpsといいます。
1-6標準化と再利用
受け取り日を選ぶカレンダーを、ミナトは一から作ろうとしていました。相棒がそれを見て尋ねます。「カレンダーの部品なら、もうよく使われているものがあるよ。それと、変数の名前、昨日と今日で付け方が違わない？」。画面のファイルを開くと、受け取り日が uketoriDate と pickup_day の2通りで書かれていました。
一人で作っていても、昨日の自分と今日の自分で書き方がそろわないことはあります。人が増えればなおさらです。開発の手順や、書類やプログラムの書き方、使う用語などの基準を、組織の中であらかじめ統一して決めておくことを標準化といいます。基準がそろっていれば、他人の書いたものも読みやすく、直しやすくなります。
プログラムの書き方についての標準がコーディング標準で、字下げの幅、1行の長さ、コメントの付け方などを決めます。その中でも、変数や関数、モジュールの名前の付け方をそろえる決まりを命名標準（命名規則）といいます。「受け取り日は pickupDate、語は英語で、単語の区切りは2語目から大文字」と決めておけば、uketoriDate と pickup_day の取り違えは起きません。
ここから基本情報！部品を作る・使う
すでにある部品を使い回すことを、ソフトウェアの再利用といいます。再利用できれば、作る手間が減るうえ、ほかの所で使われて確かめられてきた部品なので品質も上がります。ただし、部品は作るときから「別の所で使われる」ことを前提に設計しておかないと、使い回せません。
使い回しやすい部品の条件として挙げられるのがモジュールの独立性です。モジュールの中の処理が一つの目的にまとまっているほど（凝集度が強いほど）、そしてモジュールどうしのつながりが少ないほど（結合度が弱いほど）、独立性は高くなります。カレンダーの部品が日付を選ぶことだけを受け持ち、予約の保存の仕組みに依存していなければ、ケーキの予約の画面にもそのまま持っていけます。
部品より大きな単位で再利用するのが、市販や公開されているソフトウェアパッケージです。予約の受付から入金の管理までをひとまとまりにした製品を導入すれば、開発の生産性も品質も上がります。パッケージの中核の作りは変えずに、設定を変えたり機能を足したりして、利用者の要望に合わせることをカスタマイズといいます。カスタマイズを重ねすぎると、パッケージが新しい版になったときに合わせ直す手間が増えます。
部品を組み合わせる考え方は、さらに進んでいます。画面の部品を並べたり、設定を選んだりしながら、少ないプログラムの記述でアプリを作るのがローコード開発、プログラムをまったく書かずに作るのがノーコード開発です。専門の知識がなくても早く作れるのが利点で、店長が自分で在庫の表を作ることもできます。その一方で、提供されている部品でできないことは作れず、提供するサービスが終わると作ったものも動かせなくなる心配があります。また、地図や天気予報のように、複数の提供元が公開しているAPIを組み合わせて、新しいサービスを作る手法をマッシュアップといいます。一から作るより早く作れますが、品質や提供が続くかどうかは、組み合わせた先の提供元に左右されます。
基本情報の範囲ここまで
1-7リバースエンジニアリングと作り直し
焼き上がり通知を足すには、去年、知り合いの業者が作った古い予約システムとつなぐ必要がありました。ところが、手元には設計書が1枚も残っていません。ミナトは古いプログラムを開いて、どこで何をしているのかを、上から一行ずつ読み始めました。
設計書が無いなら、出来上がったものから設計を読み取るしかありません。既存のソフトウェアを解析して、その仕様や、どんな部品で組み立てられているかといった情報を取り出すことをリバースエンジニアリングといいます。設計から製品を作る普段の流れ（フォワードエンジニアリング）を、逆向きにたどる作業です。古いシステムの保守や、新しいシステムへの移し替えに使われます。
リバースエンジニアリングには、権利の面で気をつけることがあります。解析して得た情報をもとに、元のソフトウェアの権利者の許可なく、そっくりな製品を作って売れば、元の製品の知的財産権を侵害するおそれがあります。また、ソフトウェアの利用許諾契約の中で、リバースエンジニアリングそのものを禁止している場合もあります。こむぎ堂の古いシステムを解析する前に、ミナトは業者との契約書を店長に確かめてもらいました。
ここから基本情報！解析の図と、作り直しの種類
一行ずつ読むより、全体の地図があると解析は速く進みます。プログラムの中で、どの関数（サブルーチン）がどの関数を呼び出しているかの関係を、矢印でつないだ図にしたものをコールグラフといいます。古い予約システムのコールグラフを描くと、「予約を保存する」関数を3つの画面が呼んでいることが分かり、通知はそこにつなげばよいと見当がつきました。
新しい仕組みをつなぐときに確かめたいのが、互換性です。古いシステムと同じ形式のデータを読み書きでき、置き換えたり組み合わせたりしても同じように動く性質のことで、リバースエンジニアリングは、互換性のある製品を作るための情報を得る目的でも行われます。
解析した結果をもとに作り直す作業にも、範囲の違いで名前があります。既存のシステムを解析して、機能は保ったまま、構造や使っている技術を見直して新しいシステムとして作り直すことをリエンジニアリングといいます。リバースエンジニアリングで設計を取り出し、それをもとにフォワードエンジニアリングで作り直す、という2つの組み合わせです。一方、外から見た機能は変えずに、プログラムの内部の構造だけを、読みやすく保守しやすい形に整理し直すことをリストラクチャリングといいます。
基本情報の範囲ここまで
1-8モバイルアプリケーションソフトウェア開発
焼き上がり通知の話が進むと、店長はさらに言いました。「お客さんのスマートフォンに、こむぎ堂のアイコンが並んだらうれしいな」。ミナトは調べ始めて、スマートフォン向けの作り方が1通りではないことに気づきます。
スマートフォンで使う予約の仕組みは、ブラウザで開くWebページとして作るか、ストアから入れるアプリとして作るかで、作り方も、お客さんの手元に届くまでの手順も変わります。どの作り方を選ぶかで、使える端末の機能と、公開までにかかる手間が決まります。
ここから基本情報！スマートフォン向けアプリの作り方と届け方
作り方は大きく3つに分かれます。比べると、次のようになります。
| 作り方 | どう作るか | 長所と短所 |
|---|---|---|
| ネイティブアプリケーションソフトウェア（ネイティブアプリ） | iOS、Androidなど特定のOS向けに、そのOSが用意する開発の環境とAPIで作り、端末に入れて使う | 動きが速く、カメラや通知など端末の機能を十分に使える。OSごとに作り分ける手間がかかる |
| モバイルWebアプリ（モバイル用Webアプリケーションソフトウェア） | HTML・CSS・JavaScriptで作り、ブラウザで開いて使う | インストールが要らず、1つ作れば多くの端末で動く。使える端末の機能は限られる |
| ハイブリッドアプリケーションソフトウェア（ハイブリッドアプリ） | ネイティブアプリの外枠の中で、Webの技術で作った画面を動かす | 画面の多くをOSの違いを越えて使い回しながら、ストアで配れて端末の機能も使える |
Webアプリの側からネイティブアプリに近づける技術もあります。Webの技術で作ったアプリに、ホーム画面への追加、電波が無いときの動作、プッシュ通知といったアプリらしい機能を持たせたものをPWA（Progressive Web Apps：プログレッシブウェブアプリ）といいます。ストアを通さずに、こむぎ堂のアイコンをお客さんのホーム画面に置けるので、店長の希望はPWAでもかなえられます。
Webで作る場合、同じページをパソコンでもスマートフォンでも開かれます。ブラウザは、サーバに要求を送るときに、自分の種類やOSなどを知らせる情報をHTTPのヘッダに入れて送っており、この項目をUser-Agentといいます。サーバはこれを見て、端末に合った画面を返すことができます。ただし、User-Agentは書き換えることもできるので、これだけを信じて安全に関わる判断をするわけにはいきません。
アプリが端末のカメラや位置情報、通知などを使うときは、利用者に許可を求めます。これをパーミッション要求といいます。焼き上がり通知のために「通知を許可しますか」と尋ねる画面がこれです。必要な機能だけを、使う場面で、何のために使うかが分かる形で求めるのが望ましく、関係のない連絡先や位置情報まで求めると、お客さんに不審に思われます。
ネイティブアプリやハイブリッドアプリを公式のストアで公開するには、ストアを運営する事業者のアプリケーションソフトウェア審査（アプリ審査）を通る必要があります。公開の前に、事業者の定めた基準に照らして、安全性や品質、内容、個人情報の扱いなどを確かめる工程です。審査で直しを求められれば、修正して出し直すので、公開日から逆算して余裕を見ておきます。審査を通ったアプリを、ストアなどを通じて利用者の端末に入れられる状態で届ける工程がアプリケーションソフトウェア配布（アプリ配布）です。改良した版も、多くの場合は審査を通ってから配布されます。
基本情報の範囲ここまで
1-9構造化手法と形式手法
3回目のスプリントで、ミナトは予約1件の扱いを紙に書き出していました。予約を受け付ける、入金を確かめる、焼き上がりを知らせる、受け取られる。途中で取り消されることもあります。順番を整理しないまま書いたプログラムは、取り消された予約にまで焼き上がりの通知を送っていました。
大きなシステムや込み入った処理を、品質を保って作り、後から直しやすくするために、昔から使われてきたのが構造化手法です。システムが果たす機能を出発点にして、大きな機能を小さな機能へと上から下へ分け、分けた単位ごとに設計し、プログラムにしていきます。「予約を管理する」を「受け付ける」「入金を確かめる」「知らせる」に分け、それぞれをさらに分ける、という進め方です。
ここから基本情報！構造化手法で使う図
機能を上から下へ一段ずつ細かくしていく手順を段階的詳細化といいます。こうして分けた機能を、上位の機能の下に下位の機能がぶら下がる上下関係として整理することを階層構造化と呼びます。上の段だけを見れば全体が分かり、下の段に降りれば細部が分かるので、大きなシステムでも一度に考える範囲を小さくできます。
分けた結果できあがる、プログラムを構成するモジュールと、モジュールどうしの呼び出しの関係などの全体の組み立てをソフトウェア構造といいます。ソフトウェア構造を図で表す方法も、構造化手法の中で使われてきました。モジュールの階層と呼び出しの関係を木の形で描く構造化チャート、機能の階層を表す図と、機能ごとの入力・処理・出力を表す図を組にしたHIPO（Hierarchy plus Input Process Output）、データの流れと処理、データの保管場所を矢印と記号で描くDFD（Data Flow Diagram）などです。
ミナトの予約1件のように、「いまどの段階にあるか」で振る舞いが変わるものには、別の図が向いています。システムや対象がとりうる状態と、どんな出来事（イベント）をきっかけにどの状態へ移るかを、状態を表す記号と矢印で表したものを状態遷移図といいます。予約の状態遷移図を描くと、「取消済み」の状態からは「焼き上がり通知」への矢印が出ていないことが一目で分かり、通知を送る前に状態を確かめる処理が抜けていたと気づけます。
基本情報の範囲ここまで
構造化手法と並んで使われるのがオブジェクト指向です。機能を分けていく構造化手法に対して、オブジェクト指向は「予約」「お客さん」「商品」のような、データとそのデータに対する操作をひとまとまりにしたもの（オブジェクト）を単位にして、システムを組み立てます。予約というオブジェクトが自分の状態と、状態を変える操作を一緒に持つので、取り消された予約が通知を送ってよいかを、予約自身の操作の中で確かめられます。
オブジェクト指向の設計では、図の描き方をそろえたUML（Unified Modeling Language）がよく使われます。UMLにはいくつもの図があり、その一つに、利用者などシステムの外にいる者と、システムが提供する機能との関係を表すユースケース図があります。ユースケースとは、利用者がシステムを使って果たしたい一つ一つの目的のことで、「予約する」「予約を取り消す」「受け取り日を変える」などが当たります。
ここから基本情報！仕様を数学で書く
日本語で書いた仕様は、読む人によって受け取り方が変わることがあります。「受け取り日は予約日の翌日以降」の「以降」に翌日が入るかどうかは、人によって迷います。そこで、それまで自然言語で書いていた仕様を、決められた規則に従って数学的に厳密に書き、あいまいさをなくして品質を高める手法を形式手法（Formal Method）といいます。
形式手法で仕様を書くための言語が形式仕様記述言語で、VDM-SLやVDM++、Z記法などがあります。厳密に書かれた仕様は、矛盾がないかをツールで確かめられます。VDM-SLやVDM++で書いた仕様について、文法や型の誤りを調べたり、仕様をそのまま動かして結果を確かめたり、プログラムのコードを生成したりできる支援ツールがVDMToolsです。仕様を動かして試せるので、プログラムを作る前に、仕様そのもののテストができます。
基本情報の範囲ここまで
3回目のスプリントの終わり、12月1日の朝。受け取り日を選べる予約の画面だけが、先に動き始めました。焼き上がり通知はまだ次のスプリントの付箋の中です。それでも、シュトーレンの予約は前の年の倍の速さで埋まり、店長は焼き上がりの棚を見ながら言いました。「全部そろうのを待っていたら、今年の予約には間に合わなかったね」
11月にミナトが書いた30ページの仕様書は、間違っていたわけではありません。足りなかったのは、店長の希望が変わることを前提にした進め方でした。2週間ごとに動く部分を見せ、何を先に作るかを店長が決め、出来上がったものをテストに通して届ける。この章の語の多くは、その一つ一つの動きにつけられた名前です。
ただ、ミナトには気がかりが一つ残っています。スプリントのたびにプログラムを書き換え、手元には少しずつ違うファイルがいくつもたまってきました。どれが本番で動いている版なのか、ミナトはもう、すぐには答えられなくなっていました。