【からふるわーくす】PM編小説09話「データの迷宮、繋がらない片思い」

本編

① 状況提示

「ふんふんふふーん♪」

うららかな陽射しの差し込むからふるわーくすオフィス。
営業担当の任野が鼻歌まじりに軽やかなキーボード音を響かせる。
実質上のリーダーであるWebディレクターの小田は、垂れ目をさらに下げるように意識しながら優しげな声で咎めた。

「任野ちゃん、仕事中に鼻歌は止めようね？」

任野がビクッと体を震わせ、はっ！と気づいた表情を浮かべる。

「ごめんなさい！　ごめんなさい！　ついうっかり！」

オーバーなアクションで平謝りしてくる。
まあ……いつものことか。
この子は良くも悪くも素直だから。
呆れ半分の眼差しを任野に向ける。

「で、何か嬉しいことでもあったの？」

ガバッと任野が顔を近づけてきた。

「そうなんですよ！　小田さん！　聞いてください！」

「聞いてあげるから、その前に少し離れてくれると嬉しいな」

たじろぐ小田を前に、自分が何をやっていたのか気づいたらしい。
えへへと笑いながらそそくさと離れた。

「以前Webサイトを作らせていただいた『陽だまりベーカリー』様から、新しいご相談をいただいたんです」

「あら！」

小田の声が弾んだ。
これは本当に会社として嬉しくなる報せだ。

「以前に制作したWebサイトで、明日から販売を始める季節限定の『さくらあんパン』の予約受付をできるようにしたいそうなんです」

「ふんふん」

「お客様が名前と個数を入力して『予約する』ボタンを押したら、お店のメールアドレスに通知が飛ぶような仕組みをご希望されています！」

技術畑とは言えない小田でもわかるくらいにはよくあるシステム。
しかし技術畑とは言えない小田にはどう作ればいいかわからない。

「言葉ちゃん」

コーダーの言葉の机に向かい、状況を説明する。
言葉はいつもと変わらず訥々と返した。

「技術的には簡単です」

任野が満面の笑顔を浮かべる。

「おー！」

「フォームのHTMLを組むフロントエンドの作業。送信されたデータを処理してメールを配信するバックエンドのプログラム、そして今回は重複予約を防ぐための、予約データを蓄積するデータベース（MySQL）の構築が必要になります」

安堵した小田の顔から笑みがこぼれる。

「頼もしいね。明日のスタートって話だけど、今すぐいける？」

「お任せください！　明日の朝にはきっと美味しいパンの予約が殺到してます！」

任野はガッツポーズを作る。
お前じゃない。
小田がジト目を寄越しかけたところで、言葉は無邪気な任野を見上げながらぽつりと答えた。

「お任せください。今日の夕方までには美味しいパンの予約システムを完成させます」

言葉がスコスコとキーボードを叩き始める。
任野もクライアントにOKの連絡を入れる。

――電話が鳴った。小田が対応する。

「はい、からふるわーくすです……ええっ！？」

受話器を置いた小田の額には黒い影がささっていた。
言葉に向き直る。

「うまうまマッサージさんのサイトが落ちちゃったんですって。これからかき入れ時の時間だから急いで復旧してほしいと言ってるんだけど……」

状況を説明する。

「確答はできません。ただ、御説明の感じでは夜までに対応できると思います」

「でも、陽だまりベーカリーさんの依頼も……任野ちゃん、返事さしあげちゃったんだよね？」

任野がバツの悪そうな顔をする。

「ええ、『お任せください！』って……」

任野は営業として当然のことをしたまで。
責められるはずもない。
ただひたすら、運とタイミングが悪かっただけだ。

言葉はちらっと任野を見やると、モニターに視線を向けキーボードを叩き始めた。

「とにかく対処します」

――間断なく鳴り続けていたキーボードを叩く音が止まった。

「完成しました」

陽だまりベーカリーに依頼された予約システムは無事組み上がった。
もちろん、うまうまマッサージのトラブルも対処した上で。

ただし時計の針は22時を回っていた。
小田が壁時計を見つめる。

「本当なら、ここでクライアントさんのところにメールが届くかテストしたいところなんだけど……」

残業につきあっていた任野も、同じく壁時計に目をやる。

「この時間じゃ、先方に御迷惑ですねえ」

「しかたない、私のメアドでテストしよう」

言葉が小田のメールアドレスを通知先に設定した。
小田がさくらあんパンを1つ予約。
その結果、DBには正常に予約情報が保存され、小田のスマホにも予約通知メールが届いた。

言葉が淡々と告げる。

「システムは正常に動いています」

「ふう……」

小田も任野も安堵の顔を浮かべた。

言葉が通知先を陽だまりベーカリーのメアドに変更する。
これで明日の公開準備は完了だ。

「言葉ちゃんも任野ちゃんもありがとう！　お疲れ様！」

② 繋がらない片思い

翌朝、午前10時を回ったところ。
言葉は昨日の残業の埋め合わせに11時からの出勤。
小田と任野は2人してノートパソコンでSNSを覗き込んでいる。

【さくらあんパン予約してきた！】

【やっぱり外せないよね！】

小田がスマホを取り出した。

「うん、外せない。だから私も予約入れちゃお」

任野がわざとらしくジト目を寄越す。

「小田さん、勤務時間中です」

昨日怒られた意趣返しらしい。
とはいえ、表情からも口調からもからかっているのは丸わかり。
小田も空気を読んで、わざとらしくふくれ面をしてみせる。

「うるさいわね。仕事よ、仕事……ほら！」

予約確認メールが映し出されたスマホを任野の眼前に突きつけた。

「予約システム、ちゃんと動いてますね～」

からかっていたことすら忘れたらしく、朗らかに笑う。

――任野のスマートフォンが鳴った。

画面に映る発信者は「陽だまりベーカリー」。

「おはようございます！　盛況のようで何より――えっ！　ええっ！　えええええ！」

任野の顔がみるみる青ざめていく。

「……直ちに確認いたします。判明次第、お電話さしあげます」

ひきつった半泣き顔を小田に向ける。

「小田さん……店舗に予約通知メールが一通も届いていないそうです」

「ええ！　でも私だって予約入れたばかりよ！」

「店長さんも最初はSNSの反響見てにまにましてたんですって。でも予約メールは一通も届かない。そこで試しに自分で予約入れてみたら、お店の方にはメールが届かなかったって」

小田の胃がきりきり痛み出す。
しかし眼前のトラブルは、その痛みすら忘れるほどに深刻だった。

「店長さんは？　怒ってる？」

「いえ、不安半分戸惑い半分な話しぶりでした」

こういうときこそ冷静になるんだ。
小田は自らに言い聞かせ、状況を整理する。

パンの予約はできた。
予約客の元に確認メールは届いた。
しかし店舗には届いていないという。

……待って？　予約は本当にできてるの？

もしかしたらデータベース異常で登録されていないこともありうる。
予約ができたようでできていない。
そうなったら最悪の事態。
クライアントに大損害を与えてしまう。
しかし、それを調べられる言葉はまだ出社していない。

ならば今やるべきことは一つだ。
毅然とした顔を任野に向ける。

「店長さんにSNSとサイトで【問題が発生しているため受付を一時停止しています】と告知してもらって」

何が起きているかわからない。
だったらまずは、これ以上被害が拡大するのを防がなくてはならない。
言葉ちゃんが出社して原因が判明すれば、その後はいくらでも手の打ちようがあるはず。

いや、きっと手を打てる。
小田は祈るような気持ちを引っ込め、任野ににっこり笑ってみせた。

「言葉ちゃん来るまで15分くらいかな。コーヒーでも飲みながら待ちましょうか」

③ データは生きていた

「…………」

出社して状況を聞いた言葉が言葉を失う。

いつも無表情で無口の言葉だが、今回ばかりは明らかに言葉を失っていた。
ただ、その感情はトラブルそのものよりも、自分のいない間にそんな事態が展開していようとは思わなかったから。
その証左として、言葉はすぐさまキーボードを叩き始めた。

「データベースを照合します」

小田と任野がごくりと唾を飲む。

「……あります。予約のデータはちゃんと入ってます」

「ほっ」

2人して胸を撫で下ろす。
お客が予約したはずなのに入っていないという最悪の事態は避けられた。
データさえ残っているなら予約そのものは復元できる。
メールが届かなくとも、データベースから予約情報を確認してお店に渡せる。
これで当座の問題は解決した。

しかし、確認メールが来ないという問題は解決していない。
なぜメールだけが届かないのか。
昨夜はちゃんとQAを行ったし、メールが届いたのも確認している。

キーボードを叩く言葉の指が止まった。
重そうに腕を上げ、モニターを指さす。

「原因……わかりました……」

その先には本番用の送信先設定。
そして、記入されている店舗の管理メールアドレス。

ただし、そのメアドは一文字抜けていた。

つまり、テスト後に本番用アドレスへ変更する際の入力ミス。
そのためフォームからデータベースまでは正常に動作していたが、その後の店舗への通知が失敗していたのだった。

「申しわ、け……ござい……ません……」

いつもと同じ淡々とした物言いながら、途切れ途切れ。
バツの悪い思いをしているのははっきり伝わってくる。

小田が静かに口角を上げた。

「言葉ちゃんだけのせいじゃないわ、お互い様よ」

言葉に特別気を使っているわけじゃない。
文字通りの意味。

本日朝、システム始動前に本番テストをしていればこんなことにはならなかった。
昨晩の仮テストで満足せず、未確認事項として残しておかなければならなかった。
その点において、小田もまたプロジェクトマネージャーとしてミスをしでかしたのだった。

しかし今は悔やんでいる場合でも、身内同士で謝っている場合でもない。
最も優先すべきは、クライアントをトラブルから救うことだ。

「さ、やるべきことをやっちゃいましょ」

真っ先に謝るべき相手も、迷惑をかけたクライアント。
でもその前に全てを片付けよう。
後のことは、終わってから考えることにしよう。

小田が対応を整理する。
まず言葉に指示。

「データベースの予約情報をクライアントに渡せるよう加工して」

ついで任野に指示。

「クライアントに、原因が判明したこと。予約情報をこれから送ること。予約システム再開の前に再テストしたいことを伝えて。『後で謝罪にうかがいます』とも」

いくら原因がメアドの入力間違いと判明したからといって、そこを直せばすむというものではない。
他にもトラブルが潜んでいるかもしれない。
今度こそ、きっちりテストしなくてはならない。

テストが無事に成功したのを確認して、予約受付を再開。
SNSの好評も手伝って、夕方前には予定数を完売することができた。

閉店後、小田と任野が陽だまりベーカリーを訪れる。
開口一番、深々と、低く低く頭を下げた。

「この度は本当に御迷惑おかけしました」

幸いなことに、店主は笑って許してくれた。

さくらあんパンが完売だったこと。
売れ行きが想像以上の速さで実害が生じなかったこと。
もともと店主が温厚で優しい人だったこと。
取り巻く環境の全てがラッキーな方向に転び、2人の帰り際には、

「よかったらどうぞ」

さくらあんパンを土産に持たせてくれた。

④ 小さな失敗を仕組みに変える

翌日のからふるわーくすオフィス。
昨日一昨日と出張に出かけていた絵森のお土産「たぬきまんじゅう」をつまみつつ、反省会を兼ねたティータイム。
事の顛末を聞いた絵森が、切なげに吐息を漏らす。

「お客様の想いは途中までは届いていましたのね。でも、店長様のところへ辿り着く最後の道だけが途切れていた……片思いですわ」

お饅頭をくわえた3人が一斉に絵森へジト目を寄越す。

（少しは空気読め！）

そのとおりなんだけど！
こっちはそれどころじゃなかったのに！
絵森は時々我を忘れてロマンチックな乙女モードに入るのが困りものだ。

言葉が口を開く。

「改めて申し訳ございませんでした。次回からは宛先変更後の受信確認を必須にします」

小田がくわえていたお饅頭を離す。

「言葉ちゃん、それだけじゃダメなの」

口の中を洗い流すようにコーヒーを口に含み、言葉を続ける。

「今回の本当のミスは、テストが終わってない事項を確認済としてしまったこと。いかなる理由であれ、どんな結果であれ、仮は仮。そこを見誤ると今度は別のことで同じミスをやらかしちゃう」

残りのお饅頭をぱくりと口に放り込み、ごくんと飲み干す。

「その点は、みんな肝に銘じないとね！」

「はい！」

3人揃っての返事。
その後を、うっとり目を瞑った絵森が繋いだ。

「かりそめの婚約はいつ破棄されるかわかりませんわ。どんな策を弄してでも今度こそ王子様との幸せなウェディングロードを歩まないとですわね」

3人が乾いた目で絵森を見つめる。

（確かに例えとしては合ってるけれど……）

3人の頭に疑問が浮かぶ。

（絵森ちゃんは出張してた間、いったい何の漫画を読んでたのだろう……）

業務メモ

※作者の独学用です。参考程度にご覧ください。

漫画

テキスト

テキストで読みたい方はこちら

テーマ

仮テストと本番確認――「未確認」を確認済みにしない

実務ポイント

• 仮テストは本番確認ではない
  本番と異なる環境や設定でテストした場合、「何を確認できて、何が未確認なのか」を明確にする。代替環境で正常に動いたからといって、本番環境まで確認済みとは限らない。
• テスト後に変更した箇所は再確認する
  メールアドレスやURL、接続先、環境変数など、テスト後に変更した箇所は新たな確認対象となる。本番用の設定へ変更したら、その状態で必要な動作確認を行う。
• トラブル発生時は、まず影響拡大を防ぐ
  原因が分からない段階でも、影響が広がる可能性がある場合は一時停止などの措置を検討する。その後、影響範囲を確認し、原因特定・復旧を進める。
• PMは「未確認事項」を管理する
  短納期や突発対応によって予定どおりの確認ができない場合もある。重要なのは、未確認事項を曖昧なまま「完了」にしないこと。確認できなかった項目を明示し、公開前に解消する。

一言

仮は仮。テスト後に変えたところは、まだ「確認済み」ではない。

模擬問題にチャレンジ！

※作者の独学用です。参考程度にご覧ください。

テーマ

制約によって予定した確認を実施できない場合の、未確認事項の管理と本番移行

問題文

プロジェクトでは、短い納期、突発的な障害対応、関係者の不在などによって、
当初予定していた確認を予定どおり実施できないことがある。

このような場合、代替手段によって一部の動作を確認できたとしても、
本番環境や本番設定では確認できていない事項が残ることがある。
また、そのような未確認事項が残ったまま本番へ移行した場合には、
問題が発生した際の影響を考慮しながら対応する必要がある。

あなたがPMとして携わったプロジェクトにおいて、
予定していた確認を予定どおり実施できず、未確認事項が生じた事例について、
設問ア～ウに従って論述せよ。

設問ア

あなたが携わったプロジェクトの概要、あなたの立場、主要な関係者及び制約を述べよ。
また、どのような事情によって予定していた確認を実施できなくなったか、
代わりに何を確認したか、その時点で何が未確認であったかを具体的に述べよ。

800字以内

設問イ

設問アで述べた未確認事項について、
あなたはPMとしてどのように認識し、本番移行までにどのように管理・確認すべきであると考えたか。

また、本番移行後に問題が発生した際、
あなたはプロジェクトへの影響をどのように判断し、関係者とどのように対応したか。
原因の調査、復旧及び再開に至るまでに行った対応と、
その順序を選んだ理由を具体的に述べよ。

800字以上1,600字以内

設問ウ

設問イで述べた対応の結果をどのように評価したか。
また、予定どおり確認できなかった事項や、確認後に変更された事項を
誤って「確認済み」と扱わないために、その後どのような改善を行ったか。
改善の理由とともに具体的に述べよ。

600字以上1,200字以内

回答例

回答例を見る

想定プロジェクト

私はWeb制作会社のPMとして、地域のベーカリーのWebサイトに、
季節限定商品の予約機能を追加するプロジェクトを担当した。

予約者が氏名と個数を入力すると、予約情報をデータベースへ保存するとともに、
店舗へ通知メールを送信する仕組みである。
主要な関係者は、顧客であるベーカリーの店主、当社の営業担当者、
実務担当者及びPMである私であった。

顧客からの依頼は販売開始前日にあり、
翌朝から予約受付を開始するという短納期であった。

設問ア 回答例

私はWeb制作会社のPMとして、既存顧客であるベーカリーのWebサイトに、
季節限定商品の予約機能を追加するプロジェクトを担当した。
利用者が氏名と予約個数をフォームへ入力すると、
予約情報をデータベースへ保存し、店舗のメールアドレスへ通知する仕組みである。
主要な関係者は、ベーカリーの店主、当社の営業担当者、実務担当者及びPMである私であった。

顧客からの依頼は販売開始前日にあり、翌朝から予約受付を開始する必要があった。
このため開発期間が短かった上、作業中に別顧客のWebサイトで障害が発生し、
実務担当者がその復旧にも対応した。
その結果、予約機能が完成したのは22時を過ぎていた。

本来は店舗のメールアドレスを通知先として、
店舗側で受信できるところまで確認する予定であった。
しかし深夜に顧客へ確認を依頼することを避け、
私のメールアドレスを仮の通知先としてテストした。
フォーム送信、データベースへの保存及び私へのメール到着は正常であった。
その後、通知先を店舗の本番用メールアドレスへ変更した。

したがって、この時点で確認できていたのは仮の通知先を使用した場合の動作であり、
本番用アドレスへ変更した後に店舗で通知を受信できるかどうかは未確認であった。

設問イ 回答例

私はPMとして、本来であれば仮の通知先でのテスト結果と、
本番用の通知先での確認を区別して管理すべきであった。
仮の通知先で正常に動作していても、その後に通知先を変更している以上、
変更した部分は新たな確認対象となるからである。
そのため、本番用アドレスへの変更を未確認事項として明示し、
翌朝の予約受付開始前に店舗側で通知メールを受信できることを確認してから、
本番移行を完了とすべきであった。

しかし実際には、仮の通知先でフォーム、データベース及びメール送信が正常に動作したことで安心し、
本番用アドレスへの変更後も一連のテストが完了したものとして扱ってしまった。
その結果、翌朝に予約受付を開始した後、
店舗から予約通知メールが一通も届いていないとの連絡を受けた。

この時点では、通知だけの問題なのか、
予約情報そのものが正常に保存されていないのか判断できなかった。
私は、原因が判明するまで予約を受け付け続けると影響が拡大する可能性があると判断した。
そこで、原因究明より先に影響拡大を防止することを優先し、
店主に予約受付を一時停止して、Webサイト及びSNSで利用者へその旨を告知してもらった。

その間に、私は実務担当者とともに影響範囲と原因の調査を進めた。
まず、予約データがデータベースへ正常に保存されているか、
利用者側の処理が正常に完了しているか、
店舗への通知処理のどこで問題が生じているかを順に確認した。
その結果、予約データは保存されており、
問題は店舗への通知部分に限定されていることが分かった。

さらに設定を確認したところ、
本番用の通知先へ変更した際の入力誤りが原因であることを特定した。
そこで設定を修正するとともに、
既に受け付けた予約情報を顧客へ共有し、業務への影響を回復させた。

ただし、原因を修正したことだけをもって復旧完了とはしなかった。
本番用の設定で再度一連の動作を確認し、
店舗側でも通知を正常に受信できることを確認した。
その結果を店主へ報告した上で、予約受付を再開した。

この対応では、問題発生時に原因究明を最初の目的とするのではなく、
まず影響拡大を防止し、その状態を確保した上で、
影響範囲の確認、原因特定、復旧、本番確認、再開の順に進めることを重視した。
原因が不明な段階でも、被害が広がる可能性に対して実施できる対応はあると判断したためである。

設問ウ 回答例

対応の結果、データベースには受付開始後の予約情報が全て残っていたため、
保存済みの予約を店舗へ共有することができた。
また、本番用メールアドレスを修正して店舗での受信確認を行った後に受付を再開し、
予定していた商品の予約販売を継続できた。
利用者に予約をやり直してもらう必要もなかった。

一方、私は結果だけを見て対応が成功したとは評価しなかった。
今回の直接的な原因はメールアドレスの入力ミスであったが、
それだけを再発防止の対象にすると、
URLや接続先など別の設定変更で同様の問題を起こす可能性があると考えたからである。

私は、本質的な問題は、本番と異なる条件で行ったテストの結果を、
その後に設定を変更した本番状態にまで適用し、
未確認事項を確認済みとして扱ったことにあると評価した。

そこで、予定した確認を実施できなかった場合は、
その項目を未確認事項として明示し、完了扱いにしないこととした。
また、テスト後にメールアドレス、URL、接続先、環境変数などを変更した場合には、
変更箇所を新たな確認対象として扱い、
変更後の状態で必要な動作確認を行うこととした。

特に短納期や突発対応によって当日中に確認できない場合には、
「仮の条件では確認済み」「本番条件では未確認」という状態を区別して残し、
本番公開前に未確認事項を解消する運用とした。

この改善によって、テストを実施したという事実だけで完了と判断するのではなく、
何を、どの条件で確認したのかをPMが把握できるようにした。
私は今回の経験から、確認できなかったこと自体を問題とするのではなく、
未確認であることを見失わず、確認できるまで管理することが重要であると評価した。