2-1システム設計
「焼き上がりと売り切れを知らせる。朝7時台は送らない」。先週、開発会社の担当者と読み合わせた要件定義書の最後には、そう書いてあります。月曜の朝、ミナトはその紙をオーブンの横に貼ろうとして、手を止めました。メロンパンが焼き上がったことを、いったい誰が、どうやってシステムに伝えるのでしょう。オーブンに温度のセンサを付ける案、店員がタブレットに焼き上がり表を打ち込む案、大きなボタンを1つ置く案が出ていますが、かかるお金も手間もまるで違います。店長は粉の付いた手でボタンを押すまねをして、「押すだけなら、焼きながらでもできるよ」と言いました。相棒の返事は短いものでした。「では、押すのは人、知らせを送るのはサーバ、と分けて書いておきましょう」
要件定義書に書かれているのは「何を実現するか」です。設計は、それを「どういう仕組みで実現するか」に置き換える作業です。こむぎ堂の場合、最初に決めることになったのは、要件のそれぞれを誰が受け持つかでした。焼き上がりの合図はボタンという機械が、知らせを送る処理はプログラムが、ボタンを押す判断は店員が受け持ちます。
このように、システム要件をハードウェア・ソフトウェア・人の作業などに振り分け、システム全体の構成を決める工程をシステム方式設計（システムアーキテクチャ設計）と呼びます。開発の工程と作業の名前をそろえるための枠組みである共通フレームで使われる工程名です。振り分けを決めると、どんな機器とどんなプログラムが、どうつながって動くのかという全体の形が見えてきます。システムを形づくる要素とその関係、そして設計の基本方針をひとまとめにしたものをアーキテクチャ（architecture）といいます。もとは建物の「建築様式」を指す言葉で、柱や部屋の配置を先に決めるように、システムの骨組みを先に決めます。
ここから基本情報！振り分けの担い手と構成品目
基本情報のシラバスは、システム設計で要件を振り分ける先として、ハードウェア、ソフトウェア、サービス、手作業の4つを挙げています。手作業は、システムに処理させずに人が受け持つ作業のことです。焼き上がりを目で確かめてボタンを押すのは手作業で、センサに置き換えればハードウェアの受け持ちに変わります。どちらにするかは、業務の効率、作業の負担、かかる費用を比べて決めます。サービスは、外の事業者から借りて使う機能を指します。こむぎ堂は通知のサーバを店に置かず、クラウドから借りることにしました。どこまでを借りるかによって、IaaS（機器やネットワークまで）、PaaS（プログラムを動かす実行環境まで）、SaaS（アプリケーションそのもの）と呼び分けます。
振り分けを決めると、利用者がどこまでを受け持つのかもはっきりします。これをシラバスは利用者作業範囲という語で挙げています。こむぎ堂なら、店員の作業はボタンを押すところまで、お客さんの作業は好きなパンを登録するところまでで、通知の文を書いて送るのはシステムの受け持ちです。範囲をあいまいにしておくと、「売り切れの知らせは誰が出すのか」が宙に浮きます。
システムを組み立てる要素のうち、ハードウェアで実現する部分をハードウェア要素、ソフトウェアで実現する部分をソフトウェア要素と呼びます。こむぎ堂では、ボタン本体と、ボタンの信号をインターネットへ送る小さな通信機器がハードウェア要素です。登録を受け付けるプログラムや、知らせを送るプログラムがソフトウェア要素です。シラバスはソフトウェア構成を決める項目に、ソフトウェアシステム要素という語も並べています。ソフトウェアで実現するシステム要素を指す語で、ソフトウェア構成を決める段階では、その一つ一つについて自分たちで作るか、パッケージソフトウェアやミドルウェアを使うかを決めていきます。
設計や構成の管理で、ひとまとまりとして扱い、版を付けて管理する単位を構成品目と呼びます。そのうちハードウェアのまとまりがハードウェア構成品目です。こむぎ堂なら「焼き上がりボタン一式（ボタン・通信機器・電源）」を1つの品目にしておけば、故障したときに何をそろえて取り替えればよいかが決まります。
基本情報の範囲ここまで
担い手が決まったら、次は利用者から見える部分を決めます。お客さんが開く登録の画面、届く知らせの文面、店員が押すボタンの使い方など、システムの外側から見た姿を決める設計を外部設計といいます。基本設計と呼ぶこともあります。外部設計の内容は利用者にも読めるので、店長も読んで確かめられます。
システムに要る機能を洗い出し、機能ごとに処理の中身を具体的に決めていくのが機能設計です。焼き上がり通知の機能は「パンを登録する」「焼き上がりを知らせる」「売り切れを知らせる」「登録をやめる」の4つになりました。要件定義書の「朝7時台は送らない」も、ここで中身を決めなければなりません。7時台に押されたら知らせを捨てるのか、8時になってからまとめて送るのか。店長は少し考えて、「8時にまとめて」と決めました。
2-2処理方式とデータベース方式
開発会社の担当者がホワイトボードに箱を描きます。「処理をどこで動かすかを決めましょう。レジ横のパソコン1台で全部やる手もあります」。ミナトは聞き返しました。「そのパソコンの電源が落ちたら、通知も止まりますよね」
処理を1か所に集めるか、何か所かに分けるかは、システムの性格を大きく左右します。複数の利用者からの処理を1台のコンピュータに集めて実行する方式を集中処理といいます。データも機器も1か所にあるので管理しやすく、守る場所も1つで済みます。その代わり、その1台が止まると全体が止まります。
これに対し、処理を複数のコンピュータに分担させ、ネットワークでつないで全体の仕事を進める方式が分散処理です。1台が止まっても、ほかの機器が受け持つ処理は続けられますし、処理が増えたら機器を足せます。そのぶん、どこで何が動いているかを把握し、データの食い違いを防ぐ手間が増えます。
分散処理の代表的な形がクライアントサーバシステムです。サービスを求める側（クライアント）と、求めに応じて処理をする側（サーバ）に役割を分けます。焼き上がり通知では、ボタンとお客さんのスマートフォンがクライアント、登録を覚えておいて知らせを送る仕組みがサーバです。クライアントの側にWebブラウザを使う形をWebシステムといいます。お客さんは専用のアプリを入れなくても、ブラウザで登録の画面を開けば使えます。画面を直したいときも、サーバの側を直せば全員の画面が新しくなります。
Webシステムの中身も、役割で2つに分けて呼びます。利用者が直接目にして操作する、画面の表示や入力を受け持つ部分がフロントエンドです。パンの一覧を並べ、登録のボタンを押させるところがこれに当たります。利用者からは見えない、サーバの側でデータを処理し、データベースとやり取りする部分がバックエンドです。登録を保存し、ボタンが押されたら宛先を探して送るところがこちらです。
ここから基本情報！サービスに分けて組む
バックエンドを1つの大きなプログラムにせず、「登録」「宛先探し」「送信」のような小さなサービスに分け、それぞれを独立して作り、入れ替えられるようにする設計をマイクロサービスアーキテクチャ（マイクロサービス）といいます。送信のサービスだけを直しても、ほかのサービスを止めずに入れ替えられます。その代わり、サービスの数だけ、つなぎ目の取り決めと動作の見張りが要ります。
サーバの用意や管理をクラウド事業者に任せ、開発者は「ボタンが押されたら動く処理」のような機能の単位でプログラムを置くだけにする形をサーバレスアーキテクチャと呼びます。サーバが無いわけではなく、利用者の側でサーバを意識しなくて済むという意味です。焼き上がり通知のように、1日に数十回しか動かない処理なら、動いた分だけ料金を払う形にできます。
部品どうし、システムどうしが、どんな形式のデータを、どんな順でやり取りするかを定めたものがインタフェース仕様です。サービスに分けて組むときは、これが決まっていないと組み合わせられません。サービスとして切り出した機能について、何をするのか、どう呼び出せばよいのかを書き表したものをサービス記述といいます。たとえば送信のサービスなら「パンの名前と宛先の一覧を受け取り、送った件数を返す」と書いておきます。処理方式を決めるときには、ボタンが押されてから知らせが届くまでに、どの処理がどの順で動くかという手順も明らかにしておきます。押す、受け取る、時間帯を確かめる、宛先を探す、送る、送った記録を残す、の順です。
基本情報の範囲ここまで
処理の置き場所と並んで決めるのが、データをどう持つかです。業務で扱うデータの構造と、データどうしの関係を表したものをデータモデル（data model）と呼びます。焼き上がり通知で扱うのは「お客さん」「パン」「登録」の3つです。1人のお客さんが何種類ものパンを登録でき、1種類のパンを何人ものお客さんが登録できます。この関係を図にしたものがE-R図です。
お客さんとパンと登録のように、形のそろったデータは、表の形でデータを持つ関係データベース（RDB）に向いています。一方、送った知らせの記録は件数がどんどん増え、文面や付け足す情報も知らせごとに違います。こうしたデータには、表の形と決まった列（スキーマ）を前提にせず、キーと値の組や文書の形で柔軟に格納するNoSQLデータベース（NoSQL）が使われることがあります。大量のデータを多くの機器に分けて持つのも得意です。どちらを使うかは、データの形と量で決めます。
2-3ソフトウェア設計
翌週、担当者は設計書を2冊持ってきました。薄い1冊を店長に渡し、「こちらはお店の方に確かめていただく分です」と言います。厚いもう1冊を開くと、ミナトの知らない表と矢印が並んでいました。「こちらは、プログラムを書く人のための分です」
薄い1冊は外部設計の設計書で、利用者から見た姿が書かれています。厚い1冊に書かれているのは、その姿をシステムの内側でどう実現するかです。外部設計で決めた画面や機能を実現するために、プログラムの内部の構造、部品の分け方、処理の手順やデータの持ち方を決める設計を内部設計または詳細設計と呼びます。視点が利用者から開発者へ移ります。
共通フレームでは、ソフトウェアの設計を2段に分けています。前の段でソフトウェア全体の構造を決め、後の段で、分けた部品の一つ一つについて、中の処理の手順やデータの構造までを具体的に決めます。この後の段がソフトウェア詳細設計です。その結果をまとめた文書がソフトウェア詳細設計書（詳細設計書）で、プログラムを書く人が、これを読めば迷わず書き始められるところまで書き込みます。担当者の厚い1冊がこれでした。
ここから基本情報！設計の前の段と、その先
ソフトウェア設計の前の段、つまりソフトウェアを部品（ソフトウェアコンポーネント）に分け、部品ごとの役割と、部品どうしのつなぎ方を決める工程をソフトウェア方式設計といいます。システム方式設計がシステム全体を担い手に振り分けたのに対し、こちらはソフトウェアの中を分けます。
詳細設計の結果を受けて、一つ一つのプログラムの内部の処理の流れや判定の条件を決める作業は、古くからプログラム設計と呼ばれてきました。コーディングの直前に当たる作業です。「7時台なら8時まで待つ」を、時刻をどう比べ、待っている知らせをどこに置いておくかまで決めます。
データベースについても同じように詳しく決めます。表の項目と型、検索を速くするための索引、データの置き場所など、データベースを実際に作るのに要る仕様を定めるのがデータベース詳細設計です。「登録」の表にはお客さんの番号とパンの番号を持たせ、パンの番号で引く索引を付けておけば、ボタンが押されたときに宛先をすぐ探せます。
基本情報の範囲ここまで
詳細設計書に処理の流れを書くとき、どんなに複雑な処理も、上から順に進む「順次」、条件で分かれる「選択」、同じことをくり返す「繰返し」の3つの組み合わせで表せます。この3つの基本構造の組み合わせで処理を組み立て、大きな処理を小さなまとまりへ段階的に分けて整理することを構造化といいます。焼き上がりの知らせなら、登録したお客さんを1人ずつ取り出すのが繰返し、今が7時台かを確かめるのが選択、文面を作って送るのが順次です。こう書けば、どこで何をしているかが読む人に分かり、後から直すときにも迷いません。
2-4コンポーネントとユニット
厚い設計書の最初のページには、通知サーバが4つの箱に分けて描かれていました。「受け付け」「時間帯の確認」「宛先探し」「送信」。箱の中には、さらに小さな箱が入っています。ミナトは箱の数を数えて、「入れ子の箱みたいですね」とつぶやきました。
大きなプログラムを一度に作ることはしません。役割ごとの部品に分け、部品をさらに小さく分けて、一人が書いて確かめられる大きさにしてから作ります。分け方がよければ、作った部品をほかのシステムでも使い回せます。たとえば「送信」の部品は、焼き上がり通知だけでなく、予約の確認の知らせにもそのまま使えるかもしれません。
ここから基本情報！コンポーネントに分ける
一定の機能を持つまとまりとして切り出した、ソフトウェアの部品をソフトウェアコンポーネントと呼びます。設計書の4つの箱が、それぞれ1つのコンポーネントです。ソフトウェア方式設計で、ソフトウェアをこうした部品の単位に分けていく作業がソフトウェアコンポーネント分割です。
分けるときに迷うのは、どこまでを1つの部品にするかです。小さすぎれば部品どうしのやり取りばかりが増え、大きすぎれば1つ直すたびに広い範囲を確かめ直すことになります。部品として独立して働けるか、ほかでも使い回せるかを考えて決める、部品の大きさや範囲の区切りをソフトウェアコンポーネントの単位と呼びます。「時間帯の確認」を「宛先探し」の中に入れず独立させたのは、営業時間が変わったときにそこだけ直せるようにするためでした。
分けた部品ごとに、受け持つ機能の仕様を具体的に決める作業がソフトウェアコンポーネント機能仕様決定です。「時間帯の確認」なら、「今の時刻を受け取り、7時台なら8時0分まで待つ指示を、それ以外ならすぐ送る指示を返す」と決めます。部品どうしが、どんなデータや制御をどう受け渡すかを決めるのがソフトウェアコンポーネント間インタフェース設計で、ソフトウェア方式設計の作業です。ソフトウェア詳細設計の段になると、そのつなぎ目について、データの形式や呼び出しの手順まで詳しく定めます。これをソフトウェアコンポーネントインタフェース詳細設計と呼びます。
基本情報の範囲ここまで
部品の中の小さな箱は、プログラムを書く人が一つずつ受け持ち、書いたらすぐに動かして確かめる単位です。この単位まで分けておくと、どこを誰が書くか、どこから確かめるかが決めやすくなります。
ここから基本情報！ユニットに分ける
ソフトウェアを分けていったときの、プログラミングとテストの対象になるいちばん小さな単位をソフトウェアユニットと呼びます。シラバスでは、ソフトウェア要素をソフトウェアユニット（プログラム）まで分けることが、ソフトウェア設計の仕事として書かれています。「送信」の部品なら、「文面を作る」「送る」「送った記録を残す」の3つが、それぞれ1つのユニットです。
ソフトウェア要素を、実装しやすいソフトウェアユニットに分ける作業がソフトウェアユニット分割で、単にユニット分割ともいいます。分けたユニットごとに、実現する機能の仕様を決めるのがソフトウェアユニット機能仕様決定です。「文面を作る」なら、パンの名前と残りの個数を受け取り、「メロンパンが焼き上がりました（残り12個）」という文を返す、と決めます。
基本情報の範囲ここまで
入れ子の箱は、外側から順に、何を受け持つかを決めていった跡です。ミナトが数えた箱の数だけ、つなぎ目もあります。
2-5インタフェース設計
試作の登録画面を常連さんに見てもらうと、最初の一言は「どこを押せばいいの」でした。パンの写真は並んでいるのに、登録のボタンが画面の下に隠れていたのです。店長も、毎朝の焼く量を決めるのに、登録の数を紙で見たいと言い出しました。
システムと何かが出会う所には、必ず取り決めが要ります。システムと利用者のあいだ、システムとほかのシステムのあいだ、部品どうしのあいだで、データや情報をどんな形で、どんな方法でやり取りするかを定める設計をインタフェース設計といいます。常連さんが迷ったのは、利用者とのあいだの取り決めが足りなかったからです。
利用者とのやり取りのうち、画面について決めるのが画面設計です。画面に何を表示し、どこに置き、どの順で操作してもらうかを決めます。登録画面は、パンの一覧から選んで、いちばん目立つ所にある「登録する」を押す、の2手で終わるように直しました。
ここから基本情報！入出力を詳しく決める
利用者がシステムを操作し、情報をやり取りするための接点をユーザーインタフェース（UI）と呼びます。画面の表示だけでなく、オーブン横のボタンも、届く知らせの音も、この接点に含まれます。
システムに何を入力し、何を出力するかについて、項目や形式、入出力の方法を決める設計を入出力設計といいます。登録画面ならパンの選択とメールアドレスが入力、届く知らせの文面が出力です。入出力設計で決めた内容をもとに、画面や帳票の項目の配置、文字数、入力の制限までを具体的に詰めるのが入出力詳細設計です。シラバスはインタフェース設計を、操作性、応答性、視認性を考えて、入出力装置を通して扱うデータの物理的な設計を行う作業と説明しており、入出力詳細設計はその用語例に挙がっています。
詳しく詰める中で、画面の並び方と、画面から画面への移り方を決める画面構成も決めます。入力された値が決められた範囲に入っているかを確かめるリミットチェックもここで設計します。登録できるパンの数を1〜10種類と決めておけば、11種類目を選んだ時点で知らせを出せます。
基本情報の範囲ここまで
画面と並ぶもう一つの出力が、紙や表の形で出すものです。業務で出力する報告書や一覧表などの項目と配置を決める作業を帳票設計といいます。店長のために、毎朝6時に「今日の登録数一覧」をパンごとに1行ずつ出すことにしました。登録数の多い順に並べ、昨日より増えたパンには印を付けます。焼く量を決める人が、一目で読み取れる並べ方にするのが帳票設計の仕事です。
ここから基本情報！伝票とコード
システムに入力するもとになる紙もあります。店頭で常連さんが「登録をお願い」と言ったとき、店員が書き込む受付票です。取引や処理を記録する用紙の項目と配置を決める作業を伝票設計といいます。受付票の項目を、登録画面の入力の順と同じ並びにしておけば、後で打ち込むときに目が行き来しません。
受付票には、お客さんを区別する番号も書きます。登録された順に0001、0002と番号を割り振るだけで、番号そのものには分類などの意味を持たせない付け方を連番コードといいます。桁数が少なくて済み、割り振りも簡単です。その代わり、番号を見ても常連か新しいお客さんかは分かりませんし、途中に番号を差し込むこともできません。
紙に出す側では、罫線や見出しのような決まった部分をあらかじめ用意しておき、そこにデータを重ねて印刷するフォームオーバーレイという方法があります。毎朝の一覧も、枠は決まっていて中身の数字だけが変わるので、この方法に向いています。
基本情報の範囲ここまで
画面ごと、帳票ごとに決め方がばらばらだと、利用者は画面が変わるたびに使い方を覚え直すことになります。プログラムの中のつなぎ目でも、事情は同じです。
ここから基本情報！そろえるための取り決め
インタフェースを設計する前に、統一性や使いやすさを保つための決まりを定めておきます。これをインタフェース設計基準と呼びます。「決定のボタンはいつも画面の右下」「日付は年/月/日の順」「エラーの知らせは赤だけに頼らず文で書く」のような決まりです。設計者が何人いても、画面の作りがそろいます。
プログラムの中では、分けたユニットどうしの呼び出し方と、データの受け渡し方を取り決めます。これがソフトウェアユニット間インタフェースです。「文面を作る」ユニットが文を返し、「送る」ユニットがそれを受け取るとき、文字数の上限や、パンの名前が空だったときの扱いまで決めておかないと、つないだときに食い違います。
基本情報の範囲ここまで
常連さんにもう一度見てもらうと、今度は迷わずに登録が済みました。押す場所が1か所に決まっていれば、人は迷いません。
2-6テストの設計
設計書をめくっていた店長が、ふと顔を上げました。「押してから1分以内に届く、って書いてあるけど、本当に届いたかどうかは、どうやって確かめるの」。相棒の答えは「確かめ方も、作る前に決めておきましょう」でした。
テストは、作り終わってから考えるものではありません。設計で「こう動くはずだ」と決めたときに、「それをどう確かめれば合格と言えるか」も一緒に決めておきます。後回しにすると、確かめようのない書き方の設計が残ったり、テストの日になって合格の線をめぐって話がまとまらなくなったりします。「1分以内」なら、何回押して、何台のスマートフォンで、何秒以内に届けば合格とするかまで、設計の段階で決められます。
ここから基本情報！テストで確かめることを決める
開発するソフトウェアについて、テストで確かめるべき内容と満たすべき条件をまとめたものをテスト要求事項といいます。シラバスは、システム設計の段階でシステム統合テストの範囲や手順の方針を検討する項目に、この語を挙げています。焼き上がり通知なら、「押してから1分以内に届く」「7時台に押したら8時に届く」「売り切れの知らせは、登録した人にだけ届く」がテスト要求事項になります。
ソフトウェアの部品をつなぎ合わせたときに、設計書の要件をすべて満たしているかを確かめるテストが、ソフトウェア統合テストです。そのテストで、何を、どんな手順で、どんなデータを使って確かめるかを具体的に定めた文書をソフトウェア統合テスト仕様（仕様書）と呼びます。「時間帯の確認」と「送信」をつないで、7時59分と8時0分に押した場合を試す、のように書きます。
確かめるべき項目をあらかじめ一覧にしておき、一つずつ印を付けていく表がチェックリスト（checklist）です。テストやレビューで確かめ漏れを防ぐために使います。項目が具体的であるほど、誰がやっても同じ結果になります。
基本情報の範囲ここまで
「1分以内」は、確かめ方が決まって初めて、守れたかどうかが言える約束になりました。店長は、合格の線が書かれた行を指でたどって、うなずきました。
2-7品質特性と利用時の品質
「結局、よいシステムって何で決まるの。速ければいいの」。店長の問いに、ミナトはすぐには答えられませんでした。速くても、届いた知らせが間違っていたら困ります。正しくても、登録が面倒ならお客さんは使いません。
「よい」には、いくつもの向きがあります。ソフトウェアの品質を、評価できるいくつかの観点に分けたものを品質特性といいます。観点が決まっていれば、要件定義や設計の段階で「どの観点で、どこまでを目指すか」という目標を立てられ、出来上がったものを同じ物差しで評価できます。
ITパスポートのシラバスは、品質特性の例として機能性や効率性などを挙げています。機能性は、利用者が必要とする機能を、仕様どおり正しく備えている度合いです。焼き上がりのときに、登録した人へ、正しいパンの知らせが届くかどうかがこれに当たります。効率性は、求められる働きを、どれだけ少ない時間や資源で果たせるかの度合いです。押してから届くまでの時間や、サーバの処理にかかる負荷が効率性の話です。どちらの名前も、ソフトウェアの品質特性を定めた古い規格（JIS X 0129-1）の分け方から来ていて、後で見る今の規格では別の名前に置き換わっています。
品質という言葉は、製品とは別の所でも使われます。組織が品質を管理する仕組み、つまり品質マネジメントシステムについて定めた国際規格のまとまりがISO9000（ISO 9000）です。中心にあるのは、満たすべき要求事項を定めた ISO 9001 で、日本では JIS Q 9001 として出ています。用語を定めた ISO 9000 は JIS Q 9000 です。開発会社が ISO 9001 の認証を受けていれば、作り方を管理する仕組みが整っていることの目安になります。
ここから基本情報！利用時の品質の5つの特性
ソフトウェアとシステムの品質の分け方を定めた日本産業規格がJIS X 25010です。2013年版は、品質を2つのモデルに分けていました。使った結果としての品質を表す利用時の品質モデル（5特性）と、製品そのものの性質を表す製品品質モデル（8特性）です。基本情報のシラバスの用語例は、この2013年版の名前で並んでいます。
この規格は2025年12月に改正されました。利用時の品質モデルは新しい JIS X 25019 へ移り、「便益性」「リスク回避性」「受容性」の3特性を柱にする形に組み直されています。2013年版にあった利用状況網羅性は、新しいモデルでは品質特性から外れました。試験の勉強ではシラバスの名前で覚え、今の規格では形が変わったことを知っておけば足ります。
2013年版の利用時の品質は、利用者がシステムを使ったときに得られる結果を、5つの向きから見ます。焼き上がり通知に当てはめると、次のようになります。
有効性は、利用者が目指した目標を、どれだけ正確に、漏れなく達成できたかの度合いです。知らせを見たお客さんが、目当てのパンを実際に買えたかどうかです。同じ「効率性」という名前が、利用時の品質では、目標を達成するために利用者が使った時間や手間の少なさを指します。登録までに何回画面に触れたかは、こちらの効率性で測ります。
満足性は、使ったことで利用者のニーズが満たされた度合いで、また使いたいと思えたか、信頼できると感じたかを含みます。リスク回避性は、経済状況、人の生活や健康、環境に対して起こりうるリスクを和らげる度合いです。売り切れたのに「焼き上がりました」と届けば、お客さんは無駄足を踏みます。そうした損を避けられるかを見ます。
利用状況網羅性は、初めに想定した使われ方に加えて、想定を超えた状況でも、有効性・効率性・リスク回避性・満足性を保って使える度合いです。字を大きくして画面を見ているお客さんや、旅行先で知らせを受け取ったお客さんでも、困らずに使えるかどうかです。
基本情報の範囲ここまで
店長の「速ければいいの」に、ミナトはようやく答えられます。速さは、品質の向きのうちの一つにすぎません。ただ、使った結果の品質は、お客さんが使ってみるまで測れません。作る前に目標として書き込めるのは、製品そのものの性質のほうです。
2-8製品品質
担当者が設計書の最後のページを開きました。表の左に品質の観点が並び、右の欄はまだ空いています。「ここに、それぞれの目標を書き込んでいきます」。ミナトは性能の欄に、要件定義書から「押してから1分以内に届く」を写しました。
使った結果の品質を確かなものにするには、製品そのものが備えるべき性質を、観点ごとの目標として作る前に決めておきます。担当者の表で、性能の欄の次に並んでいたのは互換性です。互換性は、同じ環境や資源をほかの製品と分け合いながら、互いに悪い影響を与えずに動き、ほかの製品と情報をやり取りできる度合いを指します。焼き上がり通知が、お客さんのスマートフォンに入っているほかのアプリの動きを邪魔しないこと、店のレジの仕組みから売り切れの情報を受け取って使えることが、互換性の目標になります。
ここから基本情報！互換性の中身
互換性は2つの副特性に分かれます。同じ環境でほかの製品と共存できる共存性と、ほかの製品と情報を交換し、交換した情報を互いに使える相互運用性です。相互運用性は英語のままインターオペラビリティ（interoperability）とも呼ばれます。レジから受け取った「メロンパン 残り0個」という情報を、通知の仕組みが売り切れの知らせに使えれば、相互運用性があるといえます。名前の似た「トレーサビリティ」（追跡可能性）とは別の概念です。
基本情報の範囲ここまで
表には使用性（ユーザビリティ）の欄もあります。利用者が目的を果たすために、その製品を理解し、覚え、操作しやすい度合いを指します。登録画面で常連さんが迷ったのは、使用性の問題でした。なお、品質特性を定めた規格（JIS X 25010）は2025年に改正され、使用性は「インタラクション容易性（対話性）」という名前に置き換わりました。シラバスは改正前の名前を使っているので、両方の名前を知っておくと迷いません。
ここから基本情報！操作のしやすさ
使用性の中には、操作や制御のしやすさを表す副特性があります。古い規格（JIS X 0129-1）ではこれを運用性と呼び、JIS X 25010 では運用操作性と呼んでいます。粉の付いた手でも押し間違えない大きなボタンは、運用性を高める工夫です。基本情報のシラバスでは、運用性という語はプログラムを分けるときの基準の一つとしても挙がっています。こちらは、運用のしやすさを考えてプログラムの分け方を決める、という意味です。
基本情報の範囲ここまで
お客さんの情報を預かる以上、セキュリティの欄も空けておけません。製品品質の特性としてのセキュリティは、人やほかの製品が、認められた権限の種類と水準に応じた範囲でだけデータを扱えるように、情報とデータを守る度合いを指します。誰がどのパンを登録しているかは、お客さんの好みという個人の情報です。ほかのお客さんや、店の外の人に見えてはいけません。
ここから基本情報！製品品質の8つの特性
JIS X 25010 の2013年版は、製品品質を8つの特性に分けています。基本情報のシラバスの用語例も、この8つです。焼き上がり通知の目標に当てはめると、次の表になります。
| 特性 | 何の度合いか | 焼き上がり通知の目標 |
|---|---|---|
| 機能適合性 | 利用者の明示されたニーズと暗黙のニーズを満たす機能を備えている | 登録した人に、正しいパンの知らせが届く |
| 性能効率性 | 決められた時間や処理量の中で、資源を無駄なく使って機能を果たす | 押してから1分以内に届く |
| 互換性 | ほかの製品と共存し、情報をやり取りできる | レジの売り切れの情報を使える |
| 使用性 | 理解し、覚え、操作しやすい | 2手で登録できる |
| 信頼性 | 決められた条件で、決められた期間、機能を果たし続ける | 土曜の朝の混む時間にも止まらない |
| セキュリティ | 権限に応じた範囲でだけデータを扱わせる | 登録の中身がほかの人に見えない |
| 保守性 | 意図した保守者が、効果的かつ効率的に修正できる | 営業時間が変わっても1か所直せば済む |
| 移植性 | 別の環境へ移しやすい | 借りるクラウドを替えても動かせる |
表の8つは、さらに副特性に分かれます。機能適合性は機能完全性・機能正確性・機能適切性に、性能効率性は時間効率性・資源効率性・容量満足性に分かれます。移植性は、別の環境に合わせられる適応性、入れたり外したりしやすい設置性、ほかの製品と置き換えやすい置換性からなります。
保守性の副特性からは、2つを取り上げます。1つは再利用性で、ある資産を複数のシステムで使ったり、ほかの資産を作るのに使ったりできる度合いです。「送信」の部品を予約の確認の知らせにも使えれば、再利用性が高いといえます。もう1つは変更性で、求められた修正を加えやすい度合いです。古い規格（JIS X 0129-1）で保守性の副特性として使われていた名前で、JIS X 25010 の修正性（欠陥を入れず、品質を下げずに修正できる度合い）は、変更容易性（changeability。旧い規格の変更性に当たる）と安定性を合わせたものと説明されています。運用性と同じく、再利用性もシラバスではプログラムを分けるときの基準として挙がっています。
2025年の改正では、製品品質の特性は9つになりました。使用性はインタラクション容易性（対話性）に、移植性は柔軟性に置き換わり、新しく安全性が加わっています。表の名前は、シラバスに合わせて改正前のものにしてあります。
基本情報の範囲ここまで
夕方、設計書の最後の表は、すべての欄が埋まりました。オーブン横のボタンは店員が押す。知らせを送るのはクラウドの通知サーバ。お客さんはブラウザの画面で、2手で登録する。そして、押してから1分以内に届く。店長は表を指でなぞって、「これなら、焼きたてを待っている人に間に合うね」と言いました。
月曜の朝の問い、「焼き上がりを誰が、どうやってシステムに伝えるのか」には、設計書が答えを出しました。要件をボタン・サーバ・人に振り分け、処理を置く場所とデータの持ち方を決め、通知サーバを部品と単位に分け、つなぎ目と画面を決め、確かめ方と品質の目標まで書き込んだからです。どの決定も、要件定義書のどの行から来たのかをたどれます。
ただ、担当者が帰りぎわに見せてくれた試作のプログラムを見て、ミナトは首をかしげました。メロンパン、食パン、クロワッサンの知らせを送る処理が、ほとんど同じ形で3回書かれていたのです。新しいパンを1つ増やしたら、どこを何か所直せばよいのでしょう。焼きたてを届けるための仕組みが、パンが増えるたびに直しにくくなっていくのでは困ります。