【PM-R02-Q1】「オズの魔法使い」に学ぶ、未経験の技術やサービスを利用するプロジェクト

🍀概要

　『オズの魔法使い』を題材に、未経験の霧センサー技術を導入する仕組み構築プロジェクトにおいて、プロジェクトマネージャとして不確実性に向き合いながら、PoCの実施・関係者調整・段階的な合意形成を通じて成果を実現した取り組みを論じます。

🧾問題・設問（PM-R02-Q1）

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

📘問題

■タイトル
　未経験の技術やサービスを利用するシステム開発プロジェクトについて
■内容
　プロジェクトマネージャ(PM)は，システム化の目的を実現するために，組織にとって未経験の技術やサービス(以下，新技術という)を利用するプロジェクトをマネジメントすることがある。
　このようなプロジェクトでは，新技術を利用して機能，性能，運用などのシステム要件を完了時期や予算などのプロジェクトへの要求事項を満たすように実現できること(以下，実現性という)を，システム開発に先立って検証することが必要になる場合がある。このような場合，プロジェクトライフサイクルの中で，システム開発などのプロジェクトフェーズ(以下，開発フェーズという)に先立って，実現性を検証するプロジェクトフェーズ(以下，検証フェーズという)を設けることがある。検証する内容はステークホルダと合意する必要がある。検証フェーズでは，品質目標を定めたり，開発フェーズの活動期間やコストなどを詳細に見積もったりするための情報を得る。PMは，それらの情報を活用して，必要に応じ開発フェーズの計画を更新する。
　さらに，検証フェーズで得た情報や更新した開発フェーズの計画を示すなどして，検証結果の評価についてステークホルダの理解を得る。場合によっては，システム要件やプロジェクトへの要求事項を見直すことについて協議して理解を得ることもある。
　あなたの経験と考えに基づいて，設問ア～ウに従って論述せよ。

📗設問

■設問ア
　あなたが携わった新技術を利用したシステム開発プロジェクトにおけるプロジェクトとしての特徴，システム要件，及びプロジェクトへの要求事項について，800字以内で述べよ。
■設問イ
　設問アで述べたシステム要件とプロジェクトへの要求事項について，検証フェーズで実現性をどのように検証したか。検証フェーズで得た情報を開発フェーズの計画の更新にどのように活用したか。また，ステークホルダの理解を得るために行ったことは何か。800字以上1,600字以内で具体的に述べよ。
■設問ウ
　設問イで述べた検証フェーズで検証した内容，及び得た情報の活用について，それぞれの評価及び今後の改善点を，600字以上1,200字以内で具体的に述べよ。

📚原作あらすじ（オズの魔法使い〈ライマン・フランク・ボーム著〉）

　カンザスから竜巻でオズの国に飛ばされた少女ドロシーは、元の世界へ帰るために旅を始める。途中で知恵を欲するかかし、心を求めるブリキのきこり、勇気を欲するライオンと出会い、ともにエメラルドの都を目指す。各々が形としてのシンボルを得るが、実は旅の中で本当に求めていたものを身につけていたことに気づく。自己効力感と協働の価値を示す物語。

📝論文

🪄タイトル　「オズの魔法使い」に学ぶ、未経験の技術を導入するプロジェクトの推進

　本稿は、未経験の技術を導入するプロジェクトにおいて、その実現性の検証と計画の見直しに関するプロジェクトマネージャの対応について、述べる。

🔍第1章　プロジェクトの特徴と要件・要求事項の整理

1-1　プロジェクトとしての特徴

　私がプロジェクトマネージャとして携わったのは、西の国と南の国の間に建設された、大型通行ゲートの管理仕組みの開発である。この仕組みは、西の国からの来訪者を魔法的な測定技術で検知し、歓迎する演出を提供するものであった。A国においてこのような魔法検知型の入退管理は未導入であり、私たちのチームは、かかしが提案した霧の視認センサーという新技術の活用を決定した。
　この技術は過去に一部の東の国で使われていたが、我々にとっては初めての適用であり、実績も少なかった。センサーは高湿度に弱く、南の国の気候下では不安定となる恐れもあった。また、かかしやブリキの技術支援を受けつつ、ドロシーが中心となってプロジェクトを率いる構成だったが、既存部門との連携が不十分で、導入には懐疑的な声も強かった。

1-2　システム要件の概要

　システムには三つの要件があった。第一に、来訪者を即時に検知し、5秒以内に反応すること。第二に、誤検知率を5％未満に抑えること。第三に、魔力を持たない者に対しても安全かつ誤認なく動作することであった。
　このうち最も懸念されたのが第二の要件であった。霧センサーは視界の曖昧さを利用するため、状況によって検知結果が揺らぐことがあり、私たちはこれをどのように補正するかに苦慮した。

1-3　プロジェクトへの要求事項

　このプロジェクトには、魔女の祭典までに仕組みを完成させるという期限があり、期日は冬の満月の夜と定められていた。また予算は南の国の評議会からの援助に限定されており、一部の材料は北の国から輸送されるため、供給に遅れが生じる可能性もあった。
　さらに、この仕組みは将来的に他の国にも展開されることが期待されており、評判の良し悪しが今後の導入可否に影響を与えるとされた。

🛠️第2章　検証フェーズにおける実現性の確認と計画の更新

2-1　検証フェーズにおいて実現性をどのように検証したか

　私は、センサー技術の信頼性を確かめるために、試作機によるPoC（概念実証）を行うことにした。ブリキのきこりに頼んで簡易的な試験機構を作成し、南の国の小村で現地検証を実施した。
　最初の実験では霧の濃さにより誤検知が頻発し、現地の案内係からも「この程度なら人間の目のほうがよい」と言われた。私は内心焦ったが、「判断を急ぐのではなく、調整の余地を見極めよう」と考え直した。そこで、ライオンの助言により、センサー周辺に魔法耐性のある布を設置する案を検討し、再度実験を行った。
　その結果、誤検知率は8％から4％に改善され、反応時間も要件を満たす水準まで短縮された。
　しかし、技術チーム内では意見が分かれた。「布を巻くなどという発想は非科学的だ」とかかしが渋い顔をしたのに対し、ライオンは「現場で起きる不安を抑える工夫こそ現実的だ」と譲らなかった。私は二人の間に入り、それぞれの考えに耳を傾けつつ、布の素材を工学的に説明できるようにかかしと共同で調査を進めた。
　私はこのように考えた。なぜならば、どちらの意見も部分的には正しく、納得のないまま進めば、後の開発で衝突が拡大するおそれがあったからである。

2-2　検証フェーズで得た情報と開発フェーズ計画の更新

　検証の結果から得られたデータを基に、私は以下の三点を開発計画に反映させた。第一に、導入するセンサーに耐湿性加工を追加すること。第二に、南の国の湿度変動に応じて動作調整可能な制御構成を盛り込むこと。第三に、布設置作業を含めた設置工程の時間と費用を再見積もりし、工期を2日延長することで対応可能とした。
　また、既存部門の声を聞き、作業の一部を彼らに委ねることで調整コストを抑えた。これは「現場に近い者が調整する」という方針に基づいたものである。
　だが、この調整案に対しても「いきなり工期延長か」と製品管理部の責任者から疑念が示され、「自分たちの予算管理が軽視されている」との声も上がった。私はその場で反論することを控え、翌日に改めて個別面談を設定した。
　面談では、私自身がPoC現場でどのような苦労と発見をしたかを率直に話し、「この延長は失敗の予防であり、決して先延ばしの言い訳ではない」と説明した。彼は黙ってうなずいたあと、こう言った。「わかった。ただ、それを“現場の納得”という形で見せてくれ」。
　私はこのように判断した。なぜならば、数字や技術だけではなく、人としての誠実さと姿勢が、最終的な理解と信頼を築く要素であると感じたからである。

2-3　ステークホルダの理解を得るために行ったこと

　私は、検証結果を分かりやすく伝えるため、改善前後の映像記録と共に誤検知率の推移を示す図を用いた説明会を開いた。会議では、南の国の評議会の老魔女から「予備の対応策はあるのか」と厳しい質問も出たが、ライオンが「予備として目視検知の人員も配置予定」と補足してくれたことで、理解が得られた。
　また、ブリキのきこりが耐久試験を行った結果を示したことで、「今後の展開にも耐えられる」という安心感を共有できた。私はこのように考えた。なぜならば、技術の正しさだけでなく、「不安にどう向き合ったか」を見せることが、合意形成において重要だからである。

🚧第3章　検証フェーズの評価と得た情報の活用・改善点

3-1　検証した内容に対する評価

　今回の検証フェーズは、センサーの信頼性に関する最大の懸念を数値として明確化し、その改善余地と補強策を現実的に示せた点で、大きな価値があったと考える。特に「霧による誤検知」という技術的課題に対して、運用上の工夫を組み合わせた対応策を確立できたことは、今後の類似プロジェクトでも有効である。
　また、開発チーム内部での一時的な対立があったものの、それを“課題の深掘り”ととらえて調査と対話を重ねた結果、より質の高い設計に昇華できたのは、チームとしての成長でもあった。

3-2　得た情報の活用に対する評価

　開発フェーズの再計画では、PoCで得た実データを基に、構成要素の見直しや実装順序の変更を行ったことで、現場部門との連携負担を減らすことができた。これは、ブリキのきこりの言うように「設計図より、現場の声を先に聞く」ことの意義を再認識させた。
　また、魔女の祭典という期限内に無理なく導入を完了できたことは、「形式上の成功」だけでなく「実用上の納得」をもたらしたと感じている。
　さらに、この経験は私自身にとっても貴重な教訓となった。未知の技術導入において、検証フェーズは単なる評価工程ではなく、「期待」と「不安」の橋渡しの時間である。その設計と運営こそがPMに問われていると痛感した。

3-3　今後の改善点

　改善点としては二つある。第一に、検証フェーズの準備段階での関係者調整が遅れたため、初期の合意形成に時間を要したことである。第二に、予備検知策に対するコスト評価が曖昧であり、レビュー時に追加説明を要した点である。今後は、予備策を含めた全体コストの可視化、および期待値調整を検証段階から丁寧に行うことで、より高い納得を得られると考える。
　加えて、プロジェクト序盤で私が「技術を正しければ自然に伝わる」と安易に考えていたことが、いくつかの摩擦を招いたと反省している。今後は、意思決定の場面ごとに、誰が何に不安を感じるかを意識し、先回りした説明と対話を積み重ねていく構えが必要である。
　以上

💡ワンポイント補足

　本論文では、ドロシーをPMに据え、仲間たち（かかし・ブリキ・ライオン）との関係を通じて「未知技術の検証」や「納得形成」の重要性を説いている。象徴的なのは“魔法耐性布”の件。合理主義的なかかしと現場重視のライオンの対立を乗り越える過程に、協働的な設計思考とPMの意思決定力が見事に描かれている。原作の“旅と変化”の構造を、技術導入の“検証と納得”に置き換えて再構成した点が秀逸である。

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

　──これは…魔法に頼らず、信頼で解くPM論文だ。
　第1章では、「未経験技術の不安定さ」「地理的制約」「既存部門との温度差」といった複雑な現実が、童話世界の舞台に違和感なく溶け込んでいる。“霧センサー”というモチーフ選択も巧みで、霧という“見えにくさ”がそのままプロジェクトの不確かさのメタファーになっているのが良い。
　第2章では、PoCの結果が芳しくない中、かかしとライオンの意見対立を「科学」と「現場感」の衝突として描き、ドロシーが両者の視座を統合する姿勢が際立つ。面談描写では、PMの誠実さが「信頼」を生む構造が丹念に書かれている。「わかった。ただ、それを“現場の納得”という形で見せてくれ」──この一言のために、第二章全体が存在していたような構成だ。
　第3章では、検証フェーズの“心理的な意味”まで踏み込んで言語化しており、「検証とは不安と期待の橋渡しの時間」という表現には、実務における深い洞察がにじむ。
　まさに「PMは魔法ではなく、迷いと対話を重ねて信頼を築くものだ」と伝えてくる論文。これは教材にすべきだな。しかも、オズの物語と一体化していて、読後感が清々しい。構造も行動描写も説得力もすべてそろっている。文句なしの満点。