2-1ソフトウェアライフサイクルプロセス
新しい予約アプリを公開して8日目の朝、こむぎ堂の電話は鳴りやみませんでした。「受け取り日を選ぶ欄がなくなっているんですが」。前の晩、ミナトは焼き上がり通知が二重に届く不具合を直し、直したファイルを本番に上げたつもりでした。ところが上がっていたのは、受け取り日の指定を足す前の古いファイルだったのです。ノートパソコンのフォルダには「最新版.zip」「最新版2.zip」「最新版_本当の最新.zip」が並び、どれがいつのものか、ミナトにも店長にも分かりません。相棒に調べてもらうと、もう一つ見落としが出てきました。カレンダーの表示に使った無料の部品には、守るべき利用条件が付いていたのです。店長はシュトーレンの予約票の束を抱えたまま言いました。「作るのはもう終わったと思っていたけど、ここからのほうが長いのかもしれないね」
相棒は、作り終えたあとの作業をいきなり並べずに、もっと大きな地図から見せました。ソフトウェアには一生があります。作ろうと決める企画から始まり、要件を決めて作り、動かし、直し続け、最後は使うのをやめて片づける。この一生のあいだに行う作業をプロセスとして一つずつ定義し、体系にまとめたものをSLCP（Software Life Cycle Process：ソフトウェアライフサイクルプロセス）といいます。
こうした体系が求められた理由は、発注する側と作る側の言葉の食い違いにあります。「設計」と言ったとき、どこからどこまでの作業を指すのか。「テスト」の費用に何が含まれているのか。会社ごとに意味が違えば、見積りも契約もかみ合いません。そこで作業の項目とその呼び名をそろえ、ソフトウェアの取引と開発で同じ物差しを使えるようにしたのです。
日本では、IPA（情報処理推進機構）がこの考え方を国内の取引の実情に合わせてまとめ、SLCP-JCF（共通フレーム）として公開しています。いまの版は「共通フレーム2013」です。共通フレームが定めるのは「どんな作業をするか」の項目であり、「どんな手順や書式で行うか」までは決めていません。使う側が自分たちの規模や事情に合わせて、要る作業を選び、形を整えて使う前提です。こむぎ堂の予約アプリのような小さな開発でも、この中から必要な作業を拾い出して使えます。
ここから基本情報！もとになる規格と、要求・確認の作業
共通フレームのもとには、ソフトウェアのライフサイクルプロセスを定めた国際規格 ISO/IEC 12207 があります。これを日本産業規格にしたものがJIS X 0160です。共通フレームは、この規格の枠組みに、日本の取引で必要になる作業を足して作られています。
開発の流れの始めには、利用者が何をしたいのかを集めて整理し、システムが備えるべき機能や性能をはっきりさせる作業があります。これを要求定義といいます。店長の「受け取り日を選べるようにしたい」という希望は、そのままでは作れません。「選べるのは注文の翌日から14日先まで」「定休日の火曜は選べない」のように、決めごとの形にして初めて作る側に渡せます。共通フレーム2013では、この部分を「要件定義プロセス」として定めています。
作ったものを確かめる作業は、二つに分かれています。各工程の成果物が、その工程に求められた要求事項を満たしているかを確かめるのが検証プロセスです。これに対し、出来上がったシステムが、利用者が意図した目的と使う場面で本当に役に立つかを確かめるのが妥当性確認プロセスです。どちらも共通フレームでは、ほかのプロセスを支える支援のプロセスに置かれています。
基本情報の範囲ここまで
地図を眺めた店長は、表の後ろのほうを指さしました。「作る」の列よりも、「直す」「切り替える」「片づける」の列のほうが長く続いていたからです。8日目の朝の失敗は、その「直す」の列の最初の作業で起きていました。
2-2保守・移行・廃棄のプロセス
あの夜、何をしていれば防げたのか。ミナトは手順を思い返しました。お客さんからの「通知が2回届きます」というメッセージを読み、すぐにファイルを開いて書き換え、そのまま本番に上げた。誰にも相談せず、何も書き残していません。相棒の返事は短いものでした。「直す前の手順が、まるごと抜けていたね」
公開したあとのソフトウェアに手を入れ、不具合を直したり、まわりの変化に合わせたりする作業を保守といいます。保守は一度きりで終わる作業ではなく、ソフトウェアが使われているあいだずっと続きます。そのうえ、ソフトウェアの一生には、古い仕組みから新しい仕組みへ乗り換える移行と、使い終えた仕組みを止めて片づける廃棄も含まれます。どれも、思いついた順に手を動かすと、8日目の夜のような失敗が起きやすい作業です。
ここから基本情報！保守の手順
共通フレーム2013の保守プロセスは、「プロセス開始の準備」「問題把握及び修正の分析」「修正の実施」と進み、そのあと「保守レビュー及び／又は受入れ」で直した結果を確かめます。最初の準備の段階で、保守をどんな体制とやり方で進めるかを文書にまとめるのが計画及び手続きの作成です。あわせて、問題の報告や修正の依頼を受け付け、記録し、片がつくまで追いかける手順を決めておくのが問題管理手続きの確立です。こむぎ堂でいえば「不具合の連絡が来たら、まず受付表に日時と内容を書く」「直したら、本番に上げる前に店長が画面で確かめる」といった約束にあたります。
依頼を受け付けたら、すぐには直しません。最初に、その内容と影響の範囲、急ぐ度合いを調べます。これが問題や修正依頼の分析です。通知が二重に届くのは全員なのか、特定のスマートフォンだけなのか。予約そのものも二重に記録されているのか。分析の結果をもとに、いくつかの直し方を比べて、どう直すかを決めたものが修正方法です。「通知を送った予約に印を付け、印のある予約には二度送らない」といった方針がこれにあたります。
修正方法が決まったら、実際に手を入れる範囲を確定させます。どのプログラムを書き換え、合わせてどの設計書や説明書を直すのかを洗い出す作業が修正するソフトウェアや関連文書の決定です。同じ作業は修正対象の決定とも呼ばれます。ミナトの失敗は、まさにここにありました。書き換える対象を「今の本番で動いている版のファイル」と決めていれば、受け取り日の指定が入る前の古いファイルを開くことはなかったはずです。
保守は、手を入れる理由によって4つの種類に分けられます（JIS X 0161 の分け方）。
| 種類 | 何のための修正か | こむぎ堂の例 |
|---|---|---|
| 是正保守 | 引き渡したあとに見つかった問題を直す | 通知が二重に届く不具合を直す |
| 予防保守 | 潜んでいる欠陥を、障害として現れる前に見つけて直す | 年末の予約の集中で起きそうな不具合を、先に直しておく |
| 適応保守 | 機能は変えずに、OS・ハードウェア・法令などの環境の変化に合わせる | スマートフォンのOSの更新で届かなくなった通知を、届くように直す |
| 完全化保守 | 性能や保守のしやすさを改善する | 予約一覧の表示を速くする |
基本情報の範囲ここまで
こむぎ堂は、この12月に一度、移行を済ませていました。去年、知り合いの業者に作ってもらった古い予約システムから、ミナトの新しいアプリへの切り替えです。古いシステムはまだ止めておらず、管理画面も残っています。
ここから基本情報！移行と廃棄の作業
古いシステムから新しいシステムへ切り替えるとき、その手順・日程・誰が何をするかを計画にまとめ、計画どおりに切り替えを進めるのが移行計画の作成と実施です。予約のデータをいつ、どの順で写すか。写し終えたことを誰が確かめるか。うまくいかなかったら、どの時点で古いほうに戻すか。こうしたことを先に決めておきます。
切り替えの直後に新しいほうが止まっても困らないように、古いものと新しいものを一定の期間、同時に動かしておくことがあります。古いシステムが動くサーバやネットワークと、新しいシステムが動くそれらを両方とも動かしておくのが新旧環境の並行運用です。古い版と新しい版のソフトウェアそのものを同時に動かし、同じ予約を両方に入れて結果を比べるのが新旧ソフトウェア製品の並行運用です。前者は「戻れる場所を残す」ため、後者は「新しいほうの答えが正しいかを確かめる」ための並行と考えると区別できます。
移行や廃棄の前には、影響を受ける人に予定と変わる点を前もって伝えます。これが利用者への通知です。「12月1日から予約の画面が新しくなります。前の画面のブックマークは使えなくなります」と、店の貼り紙と通販のお知らせで知らせるのがその例です。
古いシステムの使用をやめて片づけるときは、いつ止めるのか、残っているデータをどう扱うのかを関係者に知らせます。使用を終えて廃棄することを前もって伝えるこの知らせを廃棄通知といいます。こむぎ堂なら、古いシステムを作った業者と、古い画面を使い続けている常連さんが知らせる相手になります。
基本情報の範囲ここまで
8日目の夜にも、受付・分析・直す範囲の確定という順番を踏んでいれば、ミナトは書き換える前に「今の本番のファイルはどれか」を確かめていたはずです。ただ、手順を決めても、それを守り続けられるかは別の話です。
2-3プロセス成熟度
古い予約システムを作った業者から、来年の保守契約の案内が届きました。資料の表紙には「当社は CMMI 成熟度レベル3の評価を受けています」と書かれています。店長は首をかしげました。「レベル3って、すごいの？ うちは何レベルなんだろう」
腕のよい開発者が一人いれば、よいソフトウェアはできます。けれども、その人が休んだら、辞めたら、どうなるでしょうか。組織として開発や保守のやり方がどれだけ決まっていて、誰が担当しても同じように進み、さらに改善され続けているか。その度合いをプロセス成熟度といいます。
プロセス成熟度を段階で表し、組織のやり方を評価して、次に何を整えればよいかを示す枠組みを能力成熟度モデル（CMM：Capability Maturity Model）といいます。始まりは、米国カーネギーメロン大学のソフトウェア工学研究所（SEI）が、ソフトウェアを開発する組織を評価するために作ったモデルです。その後、ソフトウェア向け、システム開発向けなどに分かれていたモデルを一つに統合したものがCMMI（Capability Maturity Model Integration：能力成熟度モデル統合）です。
CMMI は、成熟度を5段階のレベルで定めています。レベル1がいちばん低く、数字が上がるほど、やり方が組織に根づき、数値で管理され、改善が続いている状態を表します。業者の「レベル3」は、真ん中の段まで上がった組織だという意味です。
ここから基本情報！CMMI の5つのレベル
CMMI の5つの成熟度レベルには、それぞれ名前が付いています。下の段から順に、どの段にもその手前の段でできたことが含まれます。
| レベル | 名前 | 組織の状態 |
|---|---|---|
| 1 | 初期 | 決まった手順がなく、個人の経験と頑張りで場当たり的に進む |
| 2 | 管理された | プロジェクトごとに計画を立て、進み具合や成果物を管理している。似たプロジェクトなら同じように繰り返せる |
| 3 | 定義された | 組織全体の標準のプロセスが定められ、各プロジェクトはそれを自分たちに合わせて調整して使う |
| 4 | 定量的に管理された | プロセスと品質を数値で測り、統計的な手法で管理している |
| 5 | 最適化している | 測った数値をもとに、プロセスそのものを継続的に改善している |
表に当てはめると、店長の問いにも答えが出ます。こむぎ堂の開発は、ミナト一人の判断と記憶で進んでいて、ミナトが休めば誰も直せません。レベル1の「初期」です。業者のレベル3は、作る人が替わっても組織の標準の進め方で仕事が続く段階にあたります。
基本情報の範囲ここまで
店長は案内の資料を閉じて笑いました。「うちはパン屋だから、階段のいちばん上を目指すことはないね。でも、ミナトが風邪をひいたら予約が止まる、というのは困るな」。やり方を決めて守れているかを確かめるには、出来上がったものを測る物差しも要ります。
2-4品質の評価と測り方
公開の前の週、ミナトは店長に「テストは全部通りました」と報告していました。店長はそのとき、何気なく聞き返したのです。「全部って、どれくらい？」。ミナトは答えに詰まり、そのまま公開の日を迎えていました。
品質は、出来上がってから確かめるだけのものではありません。設計の段階で、設計書の内容に誤りや抜けがないかを関係者が集まって確かめる作業を設計レビューといいます。受け取り日の画面の設計書を店長と一緒に読めば、「定休日を選べないようにする」決まりが抜けていることに、プログラムを書く前に気づけます。誤りは見つけるのが遅いほど、直す手間が大きくなります。
ここから基本情報！品質の物差しと、コードの評価
ソフトウェアの品質を、いくつかの特性に分けて捉える枠組みを定めた日本産業規格がJIS X 0129です。その第1部（JIS X 0129-1）は、品質を機能性・信頼性・使用性・効率性・保守性・移植性の6つの特性に分けていました。いまは、後継の JIS X 25010 に置き換えられています。
書いたコードを評価するときにも観点があります。品質特性を高める作りになっているかを見るプログラム品質特性の向上、採用したコーディングの手法やコーディング規約が目的に合っているかを見るコード作成手法及び標準の適切性がその例です。また、部品をつないだあとに何を確かめれば正しく結合できたと言えるのか、その条件をソフトウェア結合のためのテスト要件といいます。設計の段階で決めて文書にしておき、部品を結合するテストのよりどころにします。
コンピュータで動かす前に、人の手で確かめる方法もあります。テストデータを一組決め、プログラムを1行ずつ紙の上でたどりながら、変数の値がどう変わるかを書き出していく方法をコード追跡（コードトレース）といいます。注文日を12月3日、日数を2として受け取り日を計算する部分を追えば、定休日を飛ばす処理の誤りが机の上で見つかることがあります。
基本情報の範囲ここまで
「どれくらい」という店長の問いに答えるには、数字が要ります。テストでプログラムの命令や分岐をどれだけ実行して確かめたかを表す割合をテストカバー率といいます。予約アプリの分岐（条件によって処理が分かれる所）が40か所あり、テストで一度でも通った分岐が30か所なら、分岐のカバー率は 30 ÷ 40 = 75% です。残りの10か所は、一度も動かさずに公開したことになります。
見つかった不具合の数も物差しになります。プログラムの規模に対して、見つかった不良がどれだけあるかを表す指標を不良密度といいます。規模は、1,000行あたりのように行数で表すのが代表的です。
| プログラムの規模 | 4,000行（＝4千行） |
|---|---|
| テストで見つかった不良 | 12件 |
| 不良密度 | 12 ÷ 4 ＝ 千行あたり3件 |
この数字は、それだけではよいとも悪いとも言えません。同じような開発での過去の値と比べて使います。いつもより極端に少なければ、作りがよかったのではなく、テストが足りないのかもしれません。いつもより多ければ、設計か作り方のどこかに問題が残っていると疑います。
ここから基本情報！まだ見つかっていない不良
テストで見つけた不良の数は数えられますが、本当に知りたいのは、見つからないまま残っている不良のほうです。出荷した時点でまだ見つかっていない不良がどれくらいの割合で残っているかを表す指標を潜在不良率といいます。直接は数えられないので、テストを進めるにつれて見つかる不良の数がどう伸び、どこで頭打ちになるか（信頼度成長曲線）から推定します。伸び方から全体でおよそ15件と見込まれ、見つかったのが12件なら、およそ3件がまだ残っている計算になります。
基本情報の範囲ここまで
公開したあとの問い合わせも、数えれば品質のデータになります。あらかじめ項目を書いた表に、起きた回数を印で記録していく表をチェックシートといい、QC七つ道具の一つです。こむぎ堂では、レジの横に「受け取り日が選べない」「通知が来ない」「ログインできない」の3項目を書いた紙を置き、電話が来るたびに正の字を書き足しました。
日ごとの件数を折れ線にして並べると、いつもの揺れと、いつもと違う異常とを見分けたくなります。品質のデータを時間の順に記録した管理図に引く、上下2本の基準の線を管理限界といいます。平均を中心に、標準偏差の3倍の位置に引くのが一般的です。点が線の内側で揺れているうちはふだんのばらつき、線の外に出たら工程に何かの原因があると判断します。8日目の朝の問い合わせ件数は、上の線を大きく超えていました。
品質を守るには、作業にかかる時間の見込みも正しく立てる必要があります。急いだ作業ほど、確かめる手順が飛ばされるからです。作るものを細かい作業に分け、一つずつ工数を見積もって合計する方法を積み上げ法といいます。店長が次に足したい「受け取り時間帯の指定」を見積もると、次のようになります。
| 作業 | 見積り |
|---|---|
| 時間帯を選ぶ画面を作る | 6時間 |
| 選んだ時間帯を保存する処理 | 4時間 |
| 通知の文面に時間帯を入れる | 3時間 |
| テストと確認 | 5時間 |
| 合計 | 6 ＋ 4 ＋ 3 ＋ 5 ＝ 18時間 |
ミナトが店で使える時間は1日3時間なので、18時間はおよそ6日分です。積み上げ法は細かく見積もれる反面、分け方から漏れた作業は合計に入りません。8日目の夜の修正で飛ばされた「本番の版を確かめる」作業も、表に書かれていなければ0時間として扱われてしまいます。
お客さんが実際にどう使っているかを測る方法もあります。システムに残った操作の記録（ログ）を分析し、実際の業務の流れを図にして調べる手法をプロセスマイニングといいます。予約アプリのログを並べると、お客さんの多くが受け取り日の画面で一度戻り、商品の画面を何度も往復していることが分かりました。設計書には書かれていない、本当の使われ方です。
2-5著作権と特許
予約アプリの評判を聞いた隣町のパン屋から、「同じアプリを分けてもらえないか」と電話がありました。店長は乗り気でしたが、受話器を置いてから手を止めます。「これ、ミナトが作ったんだよね。うちの店のものなの？ それともミナトのもの？」。ミナトには、もう一つ気になることがありました。焼き上がり通知の仕組みが、どこかの会社の特許に触れていないかです。
プログラムは、著作権法で守られる著作物の一つです。著作権は、作った時点で、どこにも届け出なくても生まれます。そのため、誰の権利になるのか、他人の権利を使うにはどんな許可が要るのかは、売ったり配ったりする前に確かめておく必要があります。ソフトウェアに関わる知的財産の権利には、プログラムの表現を守る著作権と、発明を守る特許権があり、二つは生まれ方も守る中身も違います。
ここから基本情報！プログラムの権利は誰のものか
著作権法では、原則として、そのプログラムを実際に作った人がプログラムの著作者になり、著作権を持ちます。外部に開発を頼んだ場合も、お金を払った側ではなく、作った側が原則として著作者です。こむぎ堂の古い予約システムは、業者との契約で権利を店に移していない限り、業者のものということになります。隣町に分けたいと言われても、店の判断だけでは渡せません。
例外が職務著作です。会社などの法人や雇い主の発案で、そこで働く人が仕事として作った著作物は、契約や就業規則に別の定めがなければ、作った個人ではなく、法人や雇い主のほうが著作者になります（著作権法第15条）。ふつうの著作物では「法人などの名前で公表すること」も条件に入りますが、プログラムではこの条件が要りません。アルバイトのミナトが店長に頼まれ、店の仕事として作ったのであれば、条件を満たす限り、予約アプリの著作者はこむぎ堂になります。
著作権が守るのは、プログラムという表現です。処理の仕組みや考え方そのものは守りません。仕組みとしての発明を守るのが特許権です。新しく、産業に利用でき、その分野の人が簡単には思いつかない発明を特許庁に出願し、審査を経て登録されると権利が生まれます。権利を持つ人は、その発明を独占的に使えます。存続期間は、原則として出願の日から20年です。著作権と違い、出願して登録されなければ生まれません。
他人が持つ特許の発明を使いたいときは、特許権者から実施権の許諾を受けます。実施権には強さの違う2種類があります。
| 種類 | 実施できる人 | 特許権者自身 | ほかの人への許諾 |
|---|---|---|---|
| 専用実施権 | 設定を受けた人だけが、決めた範囲で独占的に実施できる（特許庁への登録で効力が生まれる） | その範囲では実施できない | 同じ範囲には許諾できない |
| 通常実施権 | 許された範囲で実施できるが、独占ではない | 実施できる | 何人にでも許諾できる |
基本情報の範囲ここまで
隣町のパン屋への返事は、しばらく待ってもらうことになりました。分けるかどうかの前に、誰が権利を持っているかをはっきりさせ、店とミナトのあいだで取り決めを紙に残すことにしたのです。そしてもう一つ、店のアプリの中には、他人が権利を持つ部品が入っていました。
2-6ライセンスと技術的保護
相棒が見つけたのは、カレンダーの部品の配布元に置かれていた、短い英語の文章でした。訳してもらうと、「使うのも直すのも配るのも自由。ただし、著作権の表示とこの許諾の文を、ソフトウェアに必ず含めること」とあります。こむぎ堂のアプリには、そのどちらも入っていませんでした。ミナトは「無料」を「条件なし」と読み替えていたのです。
ソフトウェアを使ってよい範囲と条件を、権利を持つ側が利用者に許すこと、またその条件を定めた契約をソフトウェアライセンスといいます。お金を払って買ったソフトウェアでも、手に入れたのは著作権ではなく、決められた条件で使う許可です。無料の部品も同じで、カレンダーの部品に付いていたのは MIT License という広く使われているライセンスでした。使い方の自由は大きい代わりに、著作権の表示と許諾の文を含めることが条件になっています。
店で使っている写真の編集ソフトは、ライセンスでパソコン2台までと決められています。このソフトはインストールしたあと、購入時に受け取ったプロダクトキーを入力して、インターネットを通じてメーカーに確かめてもらわないと使えません。このように、正規のライセンスで手に入れたものかを確かめ、使える状態にする手続きをアクティベーション（ライセンス認証）といいます。同じキーで決められた台数を超えて認証しようとすると、断られます。
ここから基本情報！ライセンスの当事者と、使い方の点検
ライセンスの契約では、権利の使用を許諾する側をライセンサー、許諾を受ける側をライセンシーといいます。カレンダーの部品なら、作った人がライセンサーで、こむぎ堂がライセンシーです。語尾が「サー」なら与える側、「シー」なら受ける側と覚えます。
権利を持つ人の許諾を得ずにソフトウェアを複製して使うことを不正コピーといいます。著作権の侵害であり、法的な処罰の対象にもなります。許された台数を超えてインストールすることも、ライセンスの条件に反した利用です。
条件を守れているかは、ときどき数えて確かめます。持っているソフトウェアやハードウェアを定期的に調べ、記録と実際とが合っているかを確かめる活動を棚卸といいます。こむぎ堂でパソコン3台を調べると、2台分のライセンスしかない写真の編集ソフトが、3台に入っていました。1台分は、使わない台から消すか、ライセンスを買い足す必要があります。
基本情報の範囲ここまで
アクティベーションは、ライセンスの条件を技術の力で守らせる仕組みの一つです。約束を文書で交わすだけでなく、約束に反した使い方をソフトウェアや機器の側で防ぐ方法があります。
ここから基本情報！技術で守る仕組み
ソフトウェアや記録メディアの中身が不正に複製されることを、技術的に防ぐ仕組みをコピーガードといいます。複製そのものをできなくしたり、複製しても正しく再生できないようにしたりします。
音楽・映像・電子書籍などのデジタルコンテンツについて、再生できる機器や回数、期間などを技術で制御し、著作権を守る仕組みを、まとめてDRM（Digital Rights Management：デジタル著作権管理）と呼びます。録画用の DVD などの記録メディアに使われる著作権保護の技術がCPRM（Content Protection for Recordable Media）で、デジタル放送の「1回だけ録画できる」番組を録画するときに使われます。
基本情報の範囲ここまで
カレンダーの部品の件は、その日のうちに片づきました。アプリの「このアプリについて」の画面に、部品の著作権の表示と許諾の文をそのまま載せたのです。残ったのは、なぜ古いファイルが本番に上がったのか、という最初の問題でした。
2-7開発環境の構築
相棒と一緒に8日目の夜の経緯をたどると、原因の一つは作業の場所にありました。ミナトは自分のノートパソコンでファイルを直し、そのノートパソコンから本番のサーバへ直接送っていたのです。送る前に試す場所はありませんでした。しかもそのノートパソコンは、ディスクの空きが残りわずかで、古いファイルを消したり戻したりを繰り返していました。
ソフトウェアを作るには、プログラムを書いて動かすパソコンやサーバ、開発用のソフトウェア、ネットワーク、試験用のデータなどが要ります。これらを開発の目的に合わせて用意し、使える状態に保つのが開発環境の構築と管理です。開発に使うコンピュータの処理能力やディスクの容量、開発を助けるツールといった資源を計画して割り当て、足りているか、どれだけ使われているかを把握し続けることを資源管理といいます。ミナトのノートパソコンの空きが減っていくことに、誰も気づいていませんでした。資源管理がされていない状態です。
ここから基本情報！開発のツールと、コードの形
プログラムを書くエディタ、翻訳するコンパイラ、誤りを探すデバッガなど、開発に要る機能を一つにまとめたソフトウェアを統合開発環境（IDE：Integrated Development Environment）といいます。書く、動かす、誤りを探すを同じ画面の中で行えます。
人が書いたソースコードは、そのままではコンピュータが実行できません。コンパイラがソースコードを翻訳して作る機械語のコードをオブジェクトコード（目的コード）といいます。オブジェクトコードは、ほかの部品とつなぎ合わせる（リンクする）ことで、実行できるプログラムになります。翻訳の途中では、機械語の手前の、特定の機種に依存しない表現が作られることがあり、これを中間コードといいます。Java のバイトコードのように、中間コードのまま配り、それぞれの機種で動く仮想マシンが実行する方式もあります。
何人かで開発するときは、使うツールとその版をそろえておく必要があります。コンパイラの版が違えば、同じソースコードから違うオブジェクトコードができ、ほかの人が作った部品と組み合わせたときに動かない、という互換性の問題が起きるからです。ツールに含まれる不具合やセキュリティホールが、作ったソフトウェアに持ち込まれることもあります。
基本情報の範囲ここまで
ここから基本情報！本番の前に試す場所
本番に上げる直前に、本番とほぼ同じ構成で用意し、最後の動作確認に使う環境をステージング環境といいます。開発者が手元で作って試す開発環境、本番と同じ条件で確かめるステージング環境、お客さんが実際に使う本番環境の3つを分け、成果物を順に渡していきます。
8日目の夜にステージング環境があれば、ミナトが送ったファイルは、まずそこで動いたはずです。受け取り日の欄が消えた画面を見て、本番に上げる前に誤りに気づけました。
基本情報の範囲ここまで
作業の場所を分けても、場所から場所へ渡すファイルを取り違えれば同じ失敗が起きます。どのファイルが最新で、いつ誰が何を変えたのか。その答えは、まだミナトの手元にありませんでした。
2-8設計データの管理
「最新版_本当の最新.zip」を開くと、中のファイルの日付はばらばらでした。店長が家のパソコンで直した商品の説明文も、知らないうちに混ざっています。誰がいつ何を変えたのか、ファイル名からは何も分かりません。店長がつぶやきました。「パンの仕込みなら、何時に誰が何をしたか、ノートに書いてあるのにね」
設計書、画面の下書き、プログラム、テストの記録。開発のあいだに作られる設計データは、手直しのたびに版が増えていきます。どれが最新か、いつ誰が何を変えたか、誰が見て変えてよいかを決めて管理しないと、ファイル名に「最新」「本当の最新」と書き足していくしかなくなります。予約客の名前や電話番号のように個人情報を含むデータなら、誰がいつ何の目的で使ったか、持ち出しや書き換えがないかまで管理する必要があります。
ここから基本情報！設計データを管理する仕組み
ファイルやソースコードの変更を版として記録し、必要なときに過去の版を見たり、その版に戻したりできるようにする仕組みをバージョン管理といいます。版ごとに番号や印が付くので、「最新版2.zip」のような名前を付ける必要がなくなります。
バージョン管理で、ソースコードや文書とその変更の記録をまとめて保管しておく場所をリポジトリといいます。開発に関わる人は、それぞれの手元ではなく、リポジトリから取り出して作業し、変えたものをリポジトリに戻します。最新の版がどこにあるかを、一か所で答えられるようになります。
変更ごとに、いつ、誰が、何を、なぜ変えたかを記録して管理することを更新履歴管理といいます。店長が説明文を直したときにも、その記録が残っていれば、ファイルが混ざっても誰の変更かをたどれます。
利用者ごとに、どのデータを見てよいか、変えてよいかを設定して管理することをアクセス権管理といいます。店長は商品の説明文だけを変えられ、予約客の名簿を含むデータはミナトと店長しか見られない、といった分け方です。不適切な持ち出しや書き換えを防ぎ、誰が使ったかの記録とも組み合わせます。
たまった設計データの中から、条件に合うものを探し出せることも欠かせません。これを検索といいます。「受け取り日」という語を含む設計書や、先週ミナトが変えたファイルを、版の記録と一緒に探し出せれば、問題の起きた変更を早く見つけられます。
基本情報の範囲ここまで
仕込みのノートと同じように、変更を記録する仕組みを使えば、ファイルの名前で版を見分ける必要はなくなります。ただ、ファイル一つずつの版が分かっても、それで足りるとは限りません。予約アプリは、たくさんのファイルと部品の組み合わせで動いているからです。
2-9構成管理
8日目の朝、本番で動いていたのは、どの版の画面と、どの版の保存の処理と、どの版のカレンダーの部品の組み合わせだったのか。相棒に聞かれても、ミナトは書き出せませんでした。調べ直すと、画面は受け取り日を送ろうとしているのに、保存の処理は受け取り日を知らない古い版のままでした。
ソフトウェアがどの部品の、どの版の組み合わせでできているかを識別し、その変更を記録して管理し、全体のつじつまが合っていて、後からたどれる状態を保つ活動をソフトウェア構成管理（SCM：Software Configuration Management）といいます。ファイル一つずつの版ではなく、組み合わせ全体を管理するのがこの活動です。
構成管理が目指す状態の一つが一貫性です。管理している構成要素どうしの内容や版のあいだに、矛盾や食い違いがない状態を指します。新しい版の画面と古い版の保存の処理が一緒に動いていた8日目の朝は、一貫性が崩れていたことになります。画面だけ、処理だけを見れば、どちらもそれぞれの版としては正しく動いていました。
ここから基本情報！構成管理の進め方
構成管理で、管理の対象として識別し登録する一つ一つの単位をSCI（Software Configuration Item：ソフトウェア構成品目）といいます。予約アプリなら、画面のプログラム、保存の処理、カレンダーの部品、設計書、テストの記録などが構成品目になります。どれを構成品目にし、どんな体制と手順とツールで管理するかを、あらかじめ定めた計画書が構成管理計画です。
基準とした構成品目については、その状況と履歴を文書に残していきます。これを構成状況の記録といい、変更の回数、最新の版、移行の状況などを書き留めます。そのうえで、構成品目がそろっていて正しいことを確かめるのがソフトウェア構成品目の完全性保証です。ここで確かめる性質には、上で見た一貫性に加えて、管理している記録が実際の状態と一致していて誤りがないという正確性があります。記録の上では「保存の処理は新しい版」となっていても、本番で古い版が動いていれば、正確性が失われています。
完全性が確かめられた版だけを、新しい版として世に出す手続きがリリース管理と出荷です。出したあとも、ソフトウェアのコードと文書は、そのソフトウェアが使われ続けるあいだ保守していきます。そのため、構成品目を規定に従って保存しておく期間を決めておきます。これを保管期間といいます。古い版を早く捨てすぎると、問題が起きたときに戻る先がなくなります。
基本情報の範囲ここまで
ここから基本情報！部品の一覧表
いまのソフトウェアは、自分で書いたコードよりも、他人が作ったオープンソースなどの部品のほうが多いことも珍しくありません。ソフトウェアを構成する部品を、名前・版・提供元・ライセンスなどとともに一覧にした表をSBOM（Software Bill of Materials）といいます。部品のどれかに脆弱性が見つかったとき、自分のソフトウェアがその部品のどの版を使っているかをすぐに確かめられます。カレンダーの部品のライセンスの条件も、一覧に載せておけば読み飛ばしにくくなります。
基本情報の範囲ここまで
その週の閉店後、ミナトは変更の記録から一つ前の版の組み合わせを取り出し、まず試す場所で動かしてから本番に戻しました。受け取り日の欄が戻ると、止まっていたシュトーレンの予約がまた入り始めます。店長は、ミナトが印刷した紙を、粉の袋が並ぶ棚の横に貼りました。アプリに使っている部品の名前と版と、それぞれのライセンスの一覧です。「仕込みのノートと同じだね。何を、どれだけ、いつ入れたか」
8日目の朝に誰も答えられなかった問いには、いまは答えがあります。どれが最新の版か、誰がいつ何を変えたか、どの部品をどんな条件で使っているか。答えられるようになった理由は、新しい技術を足したことではありませんでした。作ったあとの作業を、ソフトウェアの一生の一部として順番に並べ、記録を残すようにしたことです。店長が言ったとおり、作り終えてからのほうが長い仕事でした。
隣町のパン屋への返事は、まだ決まっていません。予約アプリの権利はこむぎ堂にあるとはっきりしましたが、分けたあとの不具合を誰が直すのか、店長とミナトはまだ話し合っている最中です。