5-1統合の順序
木曜の夕方、こむぎ堂の作業台に、焼き上がり通知の部品が一通りそろいました。オーブン横に置く大きなボタン、知らせを送るサーバのプログラム、お客さんのスマートフォンに出る画面。部品ごとのテストは、前の章ですべて通っています。ミナトがメロンパンの天板を出したところでボタンを1回押すと、手元のスマートフォンが2回震えました。画面には「メロンパン 焼き上がりました」が、同じ時刻で2通並んでいます。店長は「1回しか押してないよね」と、ボタンをのぞき込みました。本番で動かし始めるのは2週間後の月曜です。それまでに、全体をつないだ状態で確かめ、店で使える形にして受け取らなければなりません。
相棒の最初の返事は、ミナトの予想と違うものでした。「ボタンもプログラムも、それぞれの仕様どおりに動いていると思います。食い違っているのは、つなぎ目のほうです」。調べてみると、ボタンは信号が届かなかったときに備えて、1秒以内に返事が来なければ同じ信号をもう一度送る作りでした。一方、知らせを受け付けるプログラムは、届いた信号を1つずつ別の焼き上がりとして扱います。どちらの部品も単体テストには合格していて、つないだときにだけ2通目が生まれていたのです。
単体テストを終えたモジュール（プログラムを分けた一つ一つの単位）を組み合わせ、モジュールどうしのやり取り（インタフェース）が正しく働くかを確かめるテストを統合テスト（結合テスト）といいます。ITパスポートのシラバスには統合テストの名前で載っていますが、現場や参考書では結合テストと呼ぶことも多く、どちらも同じテストを指します。2通届いた件のように、モジュールのあいだの約束の食い違いは、モジュールを1つずつ試す単体テストでは見つかりません。統合テストは、こうした食い違いを探すためにあります。
つなぐ相手が、まだそろっていないこともあります。受付のプログラムができていても、ボタンの機械が届くのが来週なら、信号を送ってくれる相手がいません。そこで、テストしたいモジュールを呼び出し、決めた値を渡して、返ってきた結果を受け取る仮のプログラムを用意します。これをドライバ（テストドライバ）といいます。ミナトは、ボタンの代わりに「メロンパン焼き上がり」の信号を1秒おきに2回送るドライバを書き、受付のプログラムが2通目をどう扱うかを、ボタンなしで何度でも再現できるようにしました。
ここから基本情報！モジュールをつなぐ順番
モジュールが3つ以上あると、どれからつなぐかを決めなければなりません。焼き上がり通知のプログラムは、上から順に、信号を受け付けて全体を取りしきる「受付」、誰に知らせるかを決める「宛先選び」、スマートフォンへ送る「送信」の3段に分かれています。上のモジュールが下のモジュールを呼び出す関係です。この組み合わせの順番を統合する順序と呼び、統合の計画を立てるときに初めに決めます。
上位のモジュールから下へ向かって順につないでいく方式がトップダウンテストです。受付から始めると、受付が呼び出す宛先選びや送信が、まだできていないことがあります。そこで、呼び出されたら決まった値を返すだけの、仮の下位モジュールを置きます。これをスタブといいます。宛先選びのスタブなら、誰が登録していても「ミナトのスマートフォン1台」を返す、といった作りです。全体の流れを早いうちに確かめられる代わりに、スタブを用意する手間がかかります。
反対に、下位のモジュールから上へ向かってつなぐ方式がボトムアップテストです。送信と宛先選びを先につなぎ、まだ無い受付の代わりにドライバを置いて呼び出します。実際に送る処理を担ういちばん下の層から確かめられる一方、全体の流れが通しで見えるのは最後になります。
基本情報の範囲ここまで
2通届く件は、受付のプログラムに「同じボタンから1秒以内に届いた同じ信号は1つとみなす」処理を足して直すことになりました。直した受付にドライバから信号を2回送ると、スマートフォンは1回だけ震えました。
ここから基本情報！統合の途中でモジュールが変わったら
統合の途中でモジュールに手を入れると、すでにつないで確かめた部分が正しく動かなくなっていないかが気になります。モジュールが変わったときに、つないだ後のテストをどの範囲で、どの順にやり直すかを、統合の計画の中で前もって決めておく方針を再帰戦略（回帰戦略）といいます。シラバスにもこの書き方で、統合する順序と並んで載っています。受付を直したなら、受付そのものと、受付から呼び出される宛先選び・送信とのつなぎ目のテストはやり直す、といった決め方です。
基本情報の範囲ここまで
5-2統合テストの計画と報告
金曜の朝、開発会社の担当者から1枚の表が届きました。「つなぐモジュール」「試す操作」「期待する結果」「結果」の列が並び、結果の欄はまだ空です。ミナトは「2通届くのはもう直したんだから、試さなくていいよね」と言いかけて、表のいちばん上の行に目を止めました。そこには「ボタンを1回押す → 通知は1通」と、直したばかりの不具合がそのまま書いてありました。
テストは、思いついた順に試すものではありません。何を、どの順に、どんな結果なら合格とするかを先に決め（計画）、そのとおりに試し（実施）、目標と実際の結果を比べて合否を判断する（評価）、という流れを持っています。評価で目標に届いていなければ、直してもう一度試します。
目標を先に書いておかないと、出てきた結果がよいのか悪いのかを判断できません。「通知が届いた」と書くだけでは足りず、「押してから1分以内に、登録した人全員に1通ずつ届く」と書いてあって初めて、届くまでに3分かかった結果を不合格と言えます。開発会社の表の「期待する結果」の列は、そのための欄です。
ここから基本情報！統合テストの計画書・手順・報告書
開発会社の表のもとになっているのがテスト計画です。テストの目的、対象の範囲、方法、日程、担当者、合格の基準を前もってまとめたもので、ソフトウェアどうしをつなぐ統合テストでも、ボタンや人の作業まで含めた全体のテストでも作ります。
計画の中の一つ一つのテストを、どの順番で、どんな操作をして実行するかを具体的に書いたものがテスト手順です。「受付のプログラムを起動する → ドライバからメロンパンの信号を1秒おきに2回送る → 送信の記録を見て1通だけかを確かめる」のように、別の人が読んでも同じ操作ができる細かさで書きます。
テストを終えたら、実施した内容、結果、見つかった不具合とその対応をソフトウェア統合テスト報告書にまとめます。統合テストを結合テストと呼んでいたころの名前でソフトウェア結合テスト報告書と呼ぶこともあり、中身は同じです。こむぎ堂の件は、不具合の欄に「原因：ボタンの再送と受付の扱いの食い違い。対応：受付で1秒以内の同じ信号を1つにまとめる」と残りました。報告書は、次の工程へ進んでよいかを判断する材料になり、後で似た不具合が出たときに原因をたどる手がかりにもなります。
基本情報の範囲ここまで
5-3検証テストの種類
土曜の朝7時50分、開店前の店で、開発会社が用意した試験用の登録600件を入れて通知を試しました。メロンパンの天板を出してボタンを押すと、ミナトのスマートフォンに知らせが届いたのは5分後でした。平日に試したときは、すぐに届いていたのです。押した時刻と届いた時刻を並べると、登録が多いほど遅れていました。
部品のつなぎ目を確かめたら、次は、組み上がった全体が最初に決めた要件どおりになっているかを確かめます。システム全体を対象に、要件定義で決めた機能や性能を満たしているかを確かめるテストをシステムテストと呼びます。いまのシラバスには用語例として載っていませんが、広く使われている呼び名です。
土曜の遅れを見つけたのは、性能を確かめるテストでした。応答時間や一定時間に処理できる件数などが、要件を満たしているかを確かめるテストを性能テストといいます。中でも、大量のデータやアクセスを与えて、負荷が高い状態でも正しく動くかを確かめるテストを負荷テストといいます。平日の試しでは登録が少なく、負荷がかからなかったので、遅れは表に出ませんでした。
原因は単純な割り算で説明できました。送信のプログラムは、1秒に2通ずつ送る設定になっていたのです。登録が600件なら、600 ÷ 2 ＝ 300秒、つまり5分かかります。「押してから1分以内（60秒以内）」を600件で守るには、1秒に600 ÷ 60 ＝ 10通は送れなければなりません。
| 登録件数 | 1秒に2通のとき | 1秒に10通のとき |
|---|---|---|
| 100件（平日の試し） | 50秒 | 10秒 |
| 300件 | 150秒（2分30秒） | 30秒 |
| 600件（土曜の試し） | 300秒（5分） | 60秒 |
100件なら1秒に2通でも50秒で届き、要件を満たしてしまいます。少ない件数で試しているかぎり、この遅れは見つかりません。負荷テストで件数を増やして初めて、要件を守れない設定だと分かったわけです。
開発会社が送信の設定を1秒に10通へ直すと、600件は60秒で届きました。ただ、直したのは送信のモジュールだけでも、ほかの所に影響が出ていないとは限りません。プログラムを変えたとき、その影響で、それまで正しく動いていた所に新しい不具合が出ていないかを確かめるテストを回帰テスト（リグレッションテスト）といいます。ミナトは、木曜に直した「1回押して1通」のテストも含めて、前に通ったテストを全部もう一度流しました。回帰テストは、動き始めた後にプログラムを直すときにも使います。
ここから基本情報！検証テストで行うテストの種類
要件どおりかを確かめるテストは、何を確かめるかで分けられます。この分け方をテストの種類と呼びます。性能テスト・負荷テスト・回帰テストのほかに、次の6つを表にまとめました。このうちストレステストは基本情報のシラバスの用語例にはありませんが、負荷テストと並べてよく使われる語です。残りの5つはシラバスに挙がっています。
| テスト | 確かめること | 焼き上がり通知での例 |
|---|---|---|
| 機能テスト | 要求された機能が、仕様どおりに正しく動くか | 売り切れのボタンを押すと「売り切れました」が届くか |
| 非機能要件テスト | 性能・信頼性・使いやすさなど、機能以外の要件を満たしているか | 朝7時台は送らないか、1分以内に届くか |
| ストレステスト | 想定を超える負荷をかけ、限界での動きや、限界を超えたときの振る舞いを見る | 登録を想定の3倍の1,800件にして、どこで遅れが大きくなるか、知らせが消えずに後から届くか |
| セキュリティテスト | 不正なアクセスや攻撃に耐えられるか | ほかのお客さんの登録内容を、自分の画面から見られないか |
| ファジング（fuzzing） | 予想していない値や形式の崩れたデータを大量に自動で入れ、異常な終了や脆弱性を探す | パンの名前の欄に、極端に長い文字列や記号だけの文字列を次々に入れる |
| 探索的テスト | 細かい手順を決めず、担当者が知識と経験をもとに操作を探りながら不具合を探す | ボタンの長押し、2種類のパンの続けての押し方などを、その場で思いついて試す |
非機能要件テストは大きなくくりで、性能テストや負荷テスト、セキュリティテストも、確かめる中身からいえばこの中に入ります。負荷テストとストレステストの違いは、かける負荷の大きさです。負荷テストは想定した最大の負荷で正しく動くかを、ストレステストは想定を超えたときにどう振る舞うかを見ます。
基本情報の範囲ここまで
テストの記録は、作った人たちが確かめて終わりではありません。業務や仕組みが、決められた基準や計画どおりに行われているかを、独立した立場から調べて評価することを監査といいます。シラバスでは、検証テストの仕事の一つに「監査の支援」が挙がっています。監査を受けることになったとき、テスト計画や結果の記録をそろえて見せられるようにしておくことが、作る側に求められます。
ここから基本情報！監査人が処理結果を比べる方法
監査人がシステムの処理の正しさを確かめる方法の一つに、並行シミュレーションがあります。監査人が自分で用意した検証用のプログラムに、本物のシステムと同じデータを処理させ、2つの結果を比べる技法です。焼き上がり通知なら、1日分の登録と焼き上がりの記録から、誰に何通送るべきかを別のプログラムで計算し、実際に送られた記録と比べる形になります。もとはシステム監査の技法で、この単元のシラバスには用語例として載っていない語です。
基本情報の範囲ここまで
5-4システム統合とシステム検証テスト
日曜の午後、店はお休みです。ミナトは開発会社の担当者と一緒に、オーブン横にボタンを取り付け、店のWi-Fiにつなぎました。ここまでのテストは、ボタンの代わりにドライバを使い、サーバも開発会社の机の上にありました。本物のボタンを、本物の店員が押すのは、この日が初めてです。
ソフトウェアどうしがつながったら、次はハードウェアと、人の手作業まで含めてつなぎます。焼き上がり通知は、ボタンの機械（ハードウェア）、受付から送信までのプログラム（ソフトウェア）、焼き上がったら店員がボタンを押すという作業（手作業）の3つがそろって、初めて仕組みとして動きます。第2章で振り分けた3つが、ここで一つになります。
ここから基本情報！システム全体をつなぐ工程のタスク
ハードウェア、ソフトウェア、手作業、必要ならほかのシステムまでを組み合わせ、システム全体として要件を満たすことを確かめる工程をシステム統合といいます。シラバスでは、この工程の仕事（タスク）がいくつかに分けて書かれています。
最初の仕事は、統合する順序、体制、日程、テストの方針を決めて文書にするシステム統合計画の作成です。次に、計画に従ってつないだシステムを実際に試すシステム統合テストの実施を行います。日曜の試しでは、粉の付いた手袋のまま押すと、ボタンが反応しないことがありました。小さなボタンを、手のひらで押せる大きなものに替えることになりました。
試した結果が、システムの要件や設計の内容を満たしているかを判定するのがシステム統合の評価です。ボタンを替えた後、「1回押して1通」「600件でも1分以内」の両方を満たしていると判定されました。
基本情報の範囲ここまで
統合の結果は、作った開発会社だけで確かめて終わりにはしません。システム統合の結果を、発注した側と作った側が一緒に確かめ、評価して合意する場をシステム統合の共同レビュー（共同レビュー）といいます。こむぎ堂では店長が加わり、手袋のまま押すと反応しない件と、大きなボタンに替える対応を、開発会社の担当者と一緒に読み合わせて了承しました。使う側がこの場にいれば、作る側が気づかない店の事情を、早いうちに持ち込めます。
ここから基本情報！システム要件に照らす検証
統合したシステムが、システム要件定義で決めたシステム要件どおりに実現されているかを確かめるテストをシステム検証テストといいます。中身は、機能テストや性能テスト、負荷テスト、セキュリティテスト、回帰テスト、探索的テストなど、何を確かめるかで分けたテストの組み合わせです。同じ工程は、以前はシステム適格性確認テストと呼ばれていました（英語の system qualification testing の訳です）。ソフトウェアだけを対象に、ソフトウェア要件に照らして行うものはソフトウェア検証テストと呼び、こちらも考え方は同じです。
基本情報の範囲ここまで
5-5導入
月曜の昼、開発会社の担当者が段取り表を持ってきました。いま動いているのは開発会社のサーバで、中に入っているのは試験用の登録だけです。これを、こむぎ堂が契約したサーバへ移し、本物のお客さんの登録を受け付けられるようにします。店長は表を見て言いました。「入れる日に何か起きたら、誰に電話すればいいの」
開発やテストに使ってきた環境とは別に、実際の業務で利用者が使う環境を本番環境といいます。2つを分けるのは、本番環境でテストをすると、本物のお客さんのスマートフォンにテストの知らせが届いてしまうからです。反対に、テスト用の環境で何が起きても、お客さんには影響しません。
本番環境で動かし始めてよいかどうかは、前もって決めた基準に照らして判断します。品質や運用の準備が整っているかを確かめ、本番で使い始めるかを決める関門を稼働判定（移行判定）といいます。こむぎ堂では、受入れの確認がすべて終わった後の金曜に、店長が最終の判断をすることにしました。シラバスに用語例として載っている語ではありませんが、システムを入れ替える現場で広く使われます。
ここから基本情報！導入の計画と実施
本番環境にシステムを入れる前に、手順、日程、必要な機器や人、古い仕組みからの切り替え方を決めておく活動をインストール計画の作成といいます。シラバスでは、導入の計画で決めることとして、次のような語が挙がっています。
導入する前に満たしておくべき条件が導入要件です。サーバの契約が済んでいること、店のWi-Fiが通知に要る通信を通すこと、お客さんの登録を受け付ける準備ができていることなどがこれにあたります。導入してよいかを判断するための基準は導入可否判断基準（ソフトウェア導入可否判断基準）と呼びます。「テストで見つかった不具合がすべて解決している」「報告書を双方が確認している」のように、判断の前に文書で決めておきます。稼働判定は、この基準に照らして行う場です。
計画ができたら、それに従って導入します。プログラムを入れ、設定を整え、データを用意して、使える状態にするまでの一連の作業が導入作業です。その作業を、どの順序で、どう進めるかを具体的に書いたものが導入手順で、こむぎ堂の段取り表は「サーバにプログラムを入れる → 設定を写す → ボタンの接続先を本番に切り替える → 店長がボタンを1回押して確かめる」の順でした。誰がどの作業を受け持つかを決めた担当の分け方が導入体制です。店長の問いへの答えも、ここに書かれます。
導入体制には、使う側の組織も入ります。システムを実際の業務のために使う部門が利用部門で、こむぎ堂なら厨房と売場の店員がそれにあたります。システムが毎日止まらずに動いているかを見守り、稼働を管理する部門がシステム運用部門です。小さな店では、ミナトが一人でこの役を兼ねることになりました。
開発会社は、本番の前に、本番と同じ構成のサーバを仮想環境に作り、導入手順を一度通して練習しました。仮想環境は、1台の物理的なコンピュータの上に、ソフトウェアで何台ものコンピュータが動いているかのような実行環境を作ったものです。本物の機械を用意しなくても、同じ構成を何度でも作り直して試せます。
基本情報の範囲ここまで
5-6受入れと納品
導入の翌日、開発会社の担当者が言いました。「ここからは、こむぎ堂さんが確かめる番です」。渡されたのは、開発会社のテストとは別の、店が自分で試すための表でした。店長は首をひねります。「作った人がもうテストしたのに、なんでうちがもう一度やるの」
店長の問いへの答えは、誰が何を確かめるかの違いにあります。開発会社のテストは、作る側が、設計したとおりに動くかを確かめるものでした。システムを頼んだ側（発注者）が、自分たちの要求どおりに動くかを、自分たちの立場で確かめる最後のテストを受入れテストといいます。作る側は、受入れテストの準備や進め方を手伝います。
受入れテストでは、何ができていれば受け入れるのかを、前もって決めておきます。システムを受け入れるかどうかの合否を判定するための基準を受入れ基準といいます。こむぎ堂の基準は、要件定義の章で決めた「焼き上がりと売り切れを知らせる」「朝7時台は送らない」に、テストで分かった「1回押して1通」「600件でも1分以内」を足したものになりました。受入れテストで問題がなければ、システムは正式に引き渡されます。
ここから基本情報！受け取るまでの段取り
受入れの進め方を定めたものが受入れ手順、受入れの確認と判定を行うために発注者の側で整える担当の分け方が受入れ体制です。こむぎ堂の受入れ体制は、操作をミナト、お客さん役を朝の店員、合否の判定を店長が受け持つ形でした。
契約で決めた成果物（プログラム、設定、説明書など）を、取り決めた期日までに発注者へ引き渡すことを納品といいます。納品されたものを発注者が検査し、契約や仕様のとおりであることを確かめて正式に受け取ることを検収といい、合格と判断するよりどころを検収基準と呼びます。受入れテストの結果は、検収の判断材料の中心になります。
基本情報の範囲ここまで
5-7教育訓練と利用者用文書
受入れテストの途中、朝だけ手伝いに来る店員が、ボタンの前で手を止めました。「焼き上がったら押す、のはいいけど、天板がまだ半分しか出ていないときは押していいの」。ミナトは答えに詰まりました。押し間違えたときの取り消し方も、まだ誰にも伝えていません。
仕組みが正しく動いても、使う人が使い方を知らなければ、知らせは正しく届きません。システムを入れるときには、使う人や運用する人に使い方を教える教育訓練を行い、作る側はその準備を手伝います。
そのときの中心になるのが、システムの使い方を、実際に使う人に向けてまとめた利用者マニュアル（システム利用マニュアル）です。ミナトは、「天板をすべて出してから、1種類につき1回押す」「押し間違えたら、5分以内に取り消しボタンを押す」と、店員の問いへの答えを書き込みました。答えが書いてあれば、ミナトがいない朝でも、店員が自分で判断できます。
ここから基本情報！教育訓練の仕組みと資料
利用者や運用者に、操作の方法や業務の知識を身につけてもらうための仕組みを教育訓練システムといいます。代表例が、ネットワークを通じて教材を届け、学ぶ人が時間や場所を選ばずに学べるe-Learning（イーラーニング）です。そのうち、Webブラウザで教材を開いて学ぶ形のものをWeb Based Training（WBT）と呼びます。朝の店員は、出勤前にスマートフォンで2分の動画を見て、ボタンの押し方を覚えました。
教育で使う動画、手順の紙、練習問題などをまとめて教育訓練資料といいます。こむぎ堂の動画も、教育訓練資料の一つです。
基本情報の範囲ここまで
ここから基本情報！利用者用文書類の種類
使う人に向けた説明の文書をまとめて、利用者用文書類と呼びます。画面やボタンの操作のしかたを順に説明した操作マニュアルは、その代表です。
シラバスには、利用者用文書類としてシステム利用文書とソフトウェア利用文書が並んでいます。対象がシステム全体か、その中のソフトウェア1本かで分けて考えると区別しやすくなります。前者は、ボタン・サーバ・お客さんの画面がどうつながり、店の一日のどこで誰が何をするかといった、システム全体の使い方を説明します。後者は、店長が通知の文面を変える管理画面のように、個々のソフトウェアの使い方を説明します。
文書の形も紙だけではありません。質問に順に答えると設定が終わる画面のウィザード、例題に沿って操作を一通り体験する学習書（チュートリアル）、画面を使いながらその場で開けるオンラインヘルプも、シラバスに利用者用文書類として挙がっています。
使い方とは別に、運用のきまりを定めた文書が運用規程です。運用の手順、担当、守るべきルールや禁止事項を書きます。こむぎ堂では「通知の文面を変えられるのは店長だけ」「知らせが届かないときは、その日のうちにミナトへ連絡する」と決めました。
文書は、作ったら終わりではありません。ボタンを大きなものに替えたので、操作マニュアルの写真も替える必要があります。仕組みの変更に合わせて利用者向けの文書を最新にする作業を利用者用文書類の更新といい、シラバスでは統合や検証テストの仕事の中にも、くり返し挙がっています。
基本情報の範囲ここまで
5-8妥当性確認テスト
本番の前の1週間、焼き上がり通知を常連さん20人だけに試してもらいました。仕組みは表のとおりに動き、知らせは1分以内に1通ずつ届きます。ところが水曜の夕方、常連さんの一人がカウンタで言いました。「知らせが来てから急いで来たのに、メロンパン、もう無かったよ」
仕様のとおりに動いていても、店長が最初に言った「焼きたてを食べてほしい」には届いていませんでした。システムが、実際に使われる環境で、本来の目的や用途を果たしているかを確かめるテストを妥当性確認テストといいます。ITパスポートのシラバスでは、発注した側が作る側の支援を受けながら、意図した運用環境でシステムを使い、意図した用途を達成しているかを確かめることとして説明されています。
ここから基本情報！妥当性確認テストの計画と技法
妥当性確認テストも、計画を立ててから行います。シラバスに挙がっている計画の項目は4つです。何のために確かめるのかを示す妥当性確認テストの目的、どんな結果なら目的を果たしたといえるかを示す成功基準（期待される結果）、どんな方法で確かめるかを示す妥当性確認テストの技法、それぞれのテストを行うために要る場所・機器・人などの条件を示す妥当性確認テストの環境条件です。
こむぎ堂の計画に当てはめると、目的は「通知を受けたお客さんが、焼きたてのパンを買えること」、成功基準は「通知から30分以内に来店したお客さんが、目当てのパンを買える」です。環境条件は「本番環境で、常連さん20人の実際のスマートフォンを使い、ふだんの営業時間に行う」になります。
技法の一つが使用性テスト（ユーザビリティテスト）です。実際の利用者に使ってもらい、操作のしやすさや分かりやすさを確かめます。常連さん3人に登録画面を使ってもらうと、1人がパンの選び方で迷いました。品質特性の「使用性」は、JIS X 25010 の2025年の改正で「インタラクション容易性」という名前に変わっています。シラバスの用語例は、改正前の「使用性」のままです。
もう一つの技法が、正式に受け入れる前に、利用者が実際にソフトウェアを一定の期間使ってみるソフトウェアの試行利用です。常連さん20人による1週間の試しが、これにあたります。
基本情報の範囲ここまで
メロンパンが無かった理由は、知らせの速さではありませんでした。ボタンを押していたのはオーブンから天板を出したときで、パンが冷めて棚に並ぶのはその20分後です。そのあいだに来たお客さんがトレーを持って待ち、並んだ分をすぐに買っていきました。話し合いの末、ボタンを押すのは「オーブンから出したとき」ではなく「棚に並べたとき」に変え、通知を受けた人の分を10分だけ取り置くことにしました。
店長は、店員の一日の仕事の流れを、文章で書き直しました。「焼き上がったら天板を冷まし台へ置く。棚に並べたらボタンを押す。通知の分は札を立てて10分取り置く」。業務の流れをこのように文章の形で書いた文書を業務記述書といいます。もとは、内部統制の評価でよく使われる3点セット（業務記述書・フローチャート・リスクコントロールマトリクス）の一つとして知られる語で、この単元のシラバスには用語例として載っていません。業務の手順を書いておけば、仕組みと人の作業がどこでつながるかを、誰でも同じように確かめられます。
ここから基本情報！見つかった問題の記録と始末
妥当性確認テストで見つかった問題は、記録して、解決するまで追いかけます。問題を分析して突き止めた、その問題を引き起こしたおおもとの原因を不具合の根本原因といいます。こむぎ堂の件では、通知の遅さではなく、「ボタンを押す時点が、お客さんが買える時点とずれていた」ことが根本原因でした。
根本原因を取り除き、同じ問題が再び起きないようにする対応が是正処置です。押す時点を棚に並べたときに変え、それを業務記述書と利用者マニュアルに書き込んだのが、こむぎ堂の是正処置です。これに対して、見つかった欠陥そのものを直す作業を欠陥修正といいます。試しの1週間には、パンの名前に「・」が入ると通知の文面が途中で切れる欠陥も見つかり、開発会社が直しました。
見つかった問題や気づきをもとに、仕組みや手順をよりよくする作業が改善作業です。登録画面で迷った常連さんの声から、パンを写真で選べるように画面を直しました。そして、この一連の経験から得た気づきを、次の計画で使えるように文書に残すことを学んだ教訓の記録といいます。ミナトは「知らせのきっかけは、お客さんが買えるようになった時点に合わせる」と書き残しました。
基本情報の範囲ここまで
本番の前の金曜、店長は受入れの表の最後の行に丸を付け、「月曜から動かそう」と言いました。月曜の朝8時、ミナトがメロンパンを棚に並べてボタンを押すと、カウンタのスマートフォンが1回だけ震えました。8時半、最初に知らせを受けた常連さんが、取り置きの札の立ったメロンパンを2つ買っていきました。
木曜の夕方に2通届いた知らせは、つなぎ目の食い違いでした。土曜の5分の遅れは、少ない件数では見えない性能の問題でした。そして水曜の「もう無かったよ」は、仕様のとおりに動いていても目的に届いていない、という問題でした。3つとも、部品を1つずつ試すだけでは見つからず、つなぎ、負荷をかけ、店で実際に使ってもらって、初めて表に出たものです。
月曜の閉店後、店長はスマートフォンの登録画面を眺めながら言いました。「予約してくれたお客さんにも、取り置きができたら知らせたいね」。動き始めたばかりの仕組みに、もう次の注文が来ています。