【PM-H21-Q2】「やまたのおろち」に学ぶ、品質目標達成のための施策と活動

🍀概要

　『やまたのおろち』を題材に、曖昧な表現や文化的な解釈差を乗り越えながら、設計工程における品質目標を確実に達成するための施策と活動を論じます。

🧾問題・設問（PM-H21-Q2）

📘問題

　出典：情報処理推進機構 プロジェクトマネージャ試験 平成21年 午後2 問2

■タイトル
　設計工程における品質目標達成のための施策と活動について
■内容
　プロジェクトマネージャ(PM)には，プロジェクトの立上げ時に，信頼性，操作性などに関するシステムの品質目標が与えられる。PMは，品質目標を達成するために，品質を作り込む施策と品質を確認する活動を計画する。
　PMは，設計工程では，計画した品質を作り込む施策が確実に実施されるように管理するとともに，品質目標の達成に影響を及ぼすような問題点を，品質を確認する活動によって早期に察知し，必要に応じて品質を作り込む施策を改善していくことが重要である。
　例えば，サービスが中断すると多額の損失が発生するようなシステムでは，サービス中断時間の許容値などの品質目標が与えられる。設計工程で品質を作り込む施策として，過去の類似システムや障害事例を参考にして，設計手順や考慮すべきポイントなどを含む設計標準を定める。品質を確認する活動として，プロジェクトメンバ以外の専門家も加えた設計レビューなどを計画する。品質を確認する活動の結果，サービス中断時間が許容値を超えるケースがあるという問題点を察知した場合，その原因を特定し，設計手順の不備や考慮すべきポイントの漏れがあったときには，設計標準を見直すなどの改善措置をとる。それに従って設計を修正し，品質目標の達成に努める。
　あなたの経験と考えに基づいて，設問ア～ウに従って論述せよ。

📗設問

■設問ア
　あなたが携わったシステム開発プロジェクトの特徴，システムの主要な品質目標と品質目標が与えられた背景について，800字以内で述べよ。
■設問イ
　設問アで述べたプロジェクトにおいて計画した，設計工程で品質を作り込む施策と品質を確認する活動はどのようなものであったか。活動の結果として察知した問題点とともに，800字以上1,600字以内で具体的に述べよ。
■設問ウ
　設問イで述べた問題点に対し，特定した原因と品質を作り込む施策の改善内容について，改善の成果及び残された課題とともに，600字以上1,200字以内で具体的に述べよ。

📚原作あらすじ（やまたのおろち〈日本神話〉）

　『やまたのおろち』は、毎年娘を生贄に差し出す村を救うため、須佐之男命が八岐大蛇を退治する神話。大蛇が「酒に目がない」という弱点を利用し、八つの酒樽を使って酔わせた後、剣で討ち果たす。その腹からは「草薙剣」が現れ、後に神器となる。勇気と知略、そして弱点の活用によって危機を打破した物語である。

📝論文

🪄タイトル　「やまたのおろち」に学ぶ、品質目標達成のための施策と活動

　本稿は、設計工程における品質目標達成のための施策と活動について、述べる。

🔍第1章　プロジェクトの特徴と品質目標の背景

1-1　プロジェクトの概要と開発対象システムの特徴

　私が携わったのは、神社組合の神託受付管理を支援するための仕組みを刷新するプロジェクトであった。神社組合は国中の祈願を受け付ける複数の神社を統括しており、その中でも大蛇退治に挑む戦士たちの願いを受理する神託処理は特に重要である。従来の仕組みは紙による手渡しと口伝によって管理されていたため、記録ミスや神託の伝達遅延が頻発し、深刻な事故につながる懸念があった。
　このため、戦士の到着・祈願・出陣・帰還に至る一連の流れを、受付から記録、通知、報告に至るまで一元管理し、祈願の信ぴょう性と処理速度を確保することが本プロジェクトの目的であった。

1-2　主要な品質目標とその内容

　本プロジェクトでは、特に信頼性と即時性が求められた。なぜならば、神託の誤伝達が大蛇討伐の失敗に直結するからである。定量的な品質目標としては、受付から伝達完了までの時間を3分以内、誤記録率を0.1%未満に抑えることが求められた。

1-3　品質目標が与えられた背景と制約条件

　過去には、大蛇退治に出陣した戦士に誤った日時を伝えてしまい、準備不足のまま遭遇し殉職するという事故が発生していた。神託の伝達には絶対の正確性が求められ、神職者と技術者の間で信頼を築きながら構築を進める必要があった。また、祭事との兼ね合いで開発期間は半年以内、費用も限られていたため、品質目標の達成と納期・コストの両立がPMに強く求められた。

🛠️第2章　設計工程における施策と活動の実施状況

2-1　品質を作り込む施策の計画と実施

　私はまず、過去の誤伝達事例を洗い出し、誤解が生じた要因を設計観点に落とし込んだ。たとえば、日時の記録欄に曖昧さがあったことから、表現形式を統一し、年月日時分秒までを明記する構造とした。また、複数の関係者が参照する場面に備え、神託記録は神職者と戦士の双方が閲覧できるよう設計した。これは、相互確認による誤りの発見を狙ったものである。
　さらに、神託の種類ごとに処理フローが異なることから、分岐の誤処理を防ぐためにワークフロー定義を標準化した。これらの設計方針をまとめ、設計標準書としてチームに共有した。加えて、設計メンバの理解度に差があることを懸念し、設計標準の読み合わせ会を複数回実施した。ある若手設計者から「“儀式”の概念が分かりづらい」という指摘があり、私はそれに応じて具体的な儀式手順とシステム上の処理の対応表を追加した。こうした現場からのフィードバックを即時に反映することは、設計の定着を加速させた。
　なお、大蛇退治の神託に関しては、「八つの酒樽の香りに誘われる」との古い言い伝えがあり、神託文中に酒に関する表現が含まれることも多かった。そのため、「酒」「酔」「醸」などの語を含む神託表現に対して、必ず注釈をつける仕様を設計に組み込んだ。これは、戦士側が文面の背景を理解し、戦術を練る上で極めて有効であると判断したためである。

2-2　品質を確認する活動の計画と実施

　品質を確認するため、設計レビューは神職者と第三者の巫女を交えた三者レビューとし、使用場面を想定したシナリオレビューを取り入れた。これにより、通常の設計レビューでは見逃されがちな実運用上の気づきを得ることができた。
　また、チェックリストには過去の失敗事例から得られた観点を盛り込み、「口頭表現の曖昧さ」「手書きメモとの整合性確認」など、実際の神託現場ならではの項目を追加した。巫女の一人から「儀式中の緊張状態では、細かい誤りに気づきにくい」との意見があり、私はレビューにおいても心理的な負荷を再現する演出を加えることを検討した。儀式を模した仮想環境でのレビューは、現場の緊張感を再現する臨場感あるテストとなり、多くの問題点の発見に寄与した。
　さらに、「八つの酒樽の香りが届くか否か」で神の機嫌が左右されるという伝承も踏まえ、神託発出の際に用いられる語句と匂い表現の適切性を確認するレビュー項目を新設した。レビューの場では、「この香りは好戦的すぎるのでは」といった意見もあり、文面の細部にわたる吟味が行われた。

2-3　品質確認活動から察知した問題点

　レビューにより、ある祈願文面が戦士にとって誤解を招く表現であることが判明した。たとえば、「五日の暁」という表現が、神職者にとっては「五日早朝」だが、戦士は「四日深夜」と誤解した。これは設計標準で表現の明確化が不十分だったことが原因であり、同様の表現ゆれが他にも複数確認された。戦士からは「命を預ける場面での誤解は致命的だ」との声があり、私はこの訴えを重く受け止め、直ちに対応方針の見直しを決断した。

🚧第3章　問題点への対応と施策の改善

3-1　問題点の原因分析と特定内容

　この問題は、「曖昧表現の放置」と「文化的解釈差異の軽視」が原因だったと分析した。なぜならば、神職者にとって常識である表現が、他者にとっても通じるとは限らないからである。過去の設計標準書には、表記ルールの明示がなく、神職者間の属人的知見に依存していた。

3-2　品質を作り込む施策の改善内容と再設計

　私はまず、表現例とその意味の対応表を策定し、設計標準書に明記した。これにより、新たに参加したメンバも誤解なく設計できるようになった。さらに、システム側での表現制約を強化し、事前定義された表現から選択する方式に改めた。これは、自由記述の柔軟性を削る代わりに、確実性を高める判断であった。神職者からは「表現の幅が狭まり神の意を損なうのでは」との反発もあったが、私は「意を正しく伝えることが最も神の意志に適う」と説得し、最終的に納得を得た。さらに、神託を伝える際には自動で補足文が添えられる仕組みも導入し、表現の単調さに対する懸念を軽減した。

3-3　改善の成果と残された課題

　改善後の設計に基づき開発した仕組みにおいて、神託誤伝達件数は前年比でゼロ件となり、処理時間も平均2分15秒に短縮された。定量的には誤記録率0.05%、定性的にも神職者・戦士双方からの信頼が高まり、「これで迷いなく戦える」との声も聞かれた。
　ただし、表現の柔軟性を削ったことによる創造的表現の減少は、長期的には神職者文化の一部を損なう可能性がある。このため、今後は「神の意図を補う表現欄」などを試験導入し、柔軟性と正確性の両立を図る方針である。また、新たな文化的解釈や風習の変化にも柔軟に対応できるよう、表現例は定期的に見直す体制とし、神職者・技術者・現場使用者の三者協議を年2回開催する計画を立てた。現場の声を継続的に吸い上げることで、仕組みの進化を促し続ける所存である。
　以上

💡ワンポイント補足

　「面白さ＝ファンタジー」ではなく、「語りの必然性＝読者の納得感」。酒の伝承をデータ仕様やレビュー観点に昇華させた工夫は、笑いではなく論理で魅せる模範的な手法。構造化された面白さがPM論文として最も評価されやすい。

🎓講評コメント（AI評価）

　いいですね。こういうのを待っていたんです。“伝承”を単なる小道具にせず、レビュー基準や設計方針に落とし込んだ手際が見事。しかも反発・合意・補足設計という三段構成で、技術者と神職の“信頼構築の道筋”がきちんと描けている。遊び心と実務的厳密さの両立──これは上級PMの論文です。文句なし。