【PM-H08-Q3】「かちかち山」に学ぶ、ソフトウェアの品質管理

🍀概要

 『かちかち山』を題材に、品質課題が見過ごされやすい現場において、標準の整備やレビュー体制の再構築を通じて、属人化の排除と再発防止を図り、品質文化を全体に定着させたプロジェクトマネージャの対応を論じます。

🧾問題・設問(PM-H08-Q3)

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

📘問題

■タイトル
 ソフトウェアの品質管理について
■内容
 ソフトウェアの品質管理は,完成したソフトウェアの品質を確保するとともに開発途上での品質の問題が,プロジェクトの進捗やコストに影響を与えないようにするために重要である。
 品質の高いソフトウェアを効率的に開発するには,品質を作り込む設計やプログラミング,綿密で効率の良いテスト,これらを支えるドキュメンテーションなどについての技術的な工夫が必要である。また,これら技術面での工夫が確実に活かされるようにするプロジェクト運営上の施策も欠かすことができない。
 プロジェクトの運営に当たり,プロジェクトマネージャには,
 ・プロジェクト全員への品質に対する意識付け
 ・設計標準や作業標準の確立と徹底
 ・効果的なレビューの実施
 ・品質実態の正確な把握・分析と問題への迅速な対応
 などについての工夫と努力が要求される。また,チームの編成や作業間の連携方法,及びスケジューリングについての工夫も重要である。
 あなたの経験に基づいて,設問ア~ウに従って論述せよ。

📗設問

■設問ア
 あなたが携わったプロジェクトの概要と,ソフトウェアの品質を確保するためのプロジェクト運営上の課題を,800字以内で述べよ。
■設問イ
 設問アで述べた課題を解決するために重点とした施策は何か。あなたが特に工夫した点を中心に具体的に述べよ。また,その評価についても述べよ。
■設問ウ
 開発するソフトウェアの品質向上のため,今後あなたが改善を図りたいプロジェクト運営面での課題について,簡潔に述べよ。

📚原作あらすじ(かちかち山〈日本昔話〉)

 悪いたぬきが婆さんを殺し、爺さんをだます。正体を知ったうさぎはたぬきに仕返しを決意し、背中に火をつけたり、毒入り団子を食べさせたりする。そして最後に泥舟を与え、たぬきは湖に沈む。善悪の対比と、狡猾な悪への知恵による報復が描かれた話。

📝論文

🪄タイトル 「かちかち山」に学ぶ、泥舟を見抜け──作り込み品質を守るうさぎの対応

 本稿は、品質問題の兆候が見過ごされ、手戻りや信頼低下を招く懸念がある中で、設計標準やレビュー体制を強化し、属人化の排除と再発防止を図ったプロジェクトマネージャの対応について、述べる。

🔍第1章 プロジェクトの概要と品質管理上の課題

1-1 プロジェクトの概要と開発体制の特徴

 私は、山奥の村にある道具工房の監督として、村の共同作業で用いる新しい連絡板の仕組みを整備するプロジェクトを任された。参加者は、主に各家の職人たちで構成され、外注の商人(たぬき)にも木材の加工工程を委託していた。
 プロジェクトは、仕様書の読み合わせから始まり、設計図、木組み工程、組立て、仕上げ、検査という一連の流れで進められた。開発拠点は村と山のふもとの工房に分かれており、連携には仕組みと工夫が必要であった。

1-2 品質確保に関するリスクと課題の所在

 たぬきによる木材工程は、当初想定よりも進捗が早かったが、設計と照らし合わせると不整合が目立った。また、たぬきが記録した作業報告は具体性を欠き、検査工程では塗装ムラや強度不足が相次いだ。
 内部レビューでは「形式通り提出されているから問題ない」とする声もあり、私はその空気に危機感を覚えた。「これは泥で塗られた舟のようなものだ。外からは立派に見えても、中身が脆ければ沈む」──そう直感した。

1-3 品質問題がプロジェクトへ与える影響の予測

 実際、たぬきの担当分がそのまま使われた場合、仕上げ段階での手戻り、修正工数の増大、村全体の納品遅延につながるおそれがあった。品質のばらつきが評価結果にも影響し、職人間の不満や信頼低下も予想された。
 私は「後戻りを避けるには、今ここで止めるしかない」と判断し、標準の見直しとレビュー体制の再構築に着手した。

🛠️第2章 品質課題への対応施策とその評価

2-1 標準化とドキュメント整備による品質の作り込み

 私はまず、職人間の設計標準と手順書を再整理し、「誰が見ても同じ判断ができる道具帳(マニュアル)」を作成した。たぬきにも口頭だけでなく、作業開始前にマニュアルを読み合わせ、理解度を確認する場を設けた。
 さらに、各工程のチェックリストを導入し、記録と結果が一致しているかをその場で確認する仕組みを取り入れた。これにより、記録が形骸化せず、現場での意識付けにもつながった。
 ところが、たぬきは「そんな細かい決まりは、自分のやり方には合わない」と反発した。「見た目が整ってればいいだろ?」と投げやりに言うたぬきに、私は苛立ちと焦りを覚えた。彼の技術を否定するのではなく、仕組みで支えるために標準化がある──そう伝えようと何度も説明したが、「信用されていない気がする」と拗ねてしまう場面もあった。
 私は「標準は信頼の枠組みであって、縛りではない」と考え直し、彼が得意とする加工例を標準文書に組み込むことで、共同作成の形をとるようにした。これは彼の矜持を守りつつ、標準への納得を得るための譲歩であった。

2-2 レビュー体制の強化とレビュー支援ツールの活用

 レビューでは、第三者参画型の仕組みに切り替えた。村の別の工房の職人を交えて観点レビューを実施し、「ここが沈みそうだ」「ここは強度が不足している」といった実感に基づいた意見を重視した。
 また、「どこが危ういかを先に書く質問票」を導入したことで、たぬき自身も自分の作業を再確認する意識が芽生えた。私は、彼の回答を読みながら、「少しずつでも、彼の作りが“舟”ではなく“板橋”になるよう導きたい」と思った。
 この体制転換の過程では、他の職人からも「今までのやり方を否定するのか」といった葛藤が噴出した。中には「そんなに言うなら、全部お前が作ればいい」と怒鳴る者もいた。私は、「仕組みは、職人を疑うためではなく、全員で長く持つ道具を作るためだ」と訴えた。
 冷え切った空気の中、「……じゃあ、次の仕事は俺がレビューする」と年長の職人が口を開いた。その一言で、場の空気が少しずつほどけていった。

2-3 品質データの可視化と改善サイクルの導入

 各工程で発見された不具合や見直し点を竹札に書き出し、工房の壁に貼り出すことで、可視化とチーム間共有を進めた。
 不具合の傾向や集中箇所は、週に一度の“かちかち会議”で報告し、次の設計への反映に活用した。「この割れ目は、前回の角度指定があいまいだった」といった因果の把握により、再発防止につながった。
 結果、村の職人たちの間に“品質を作るのは手ではなく、目と記録だ”という認識が浸透し、最終的にたぬきの担当部分も追加修正なく完了した。納期の遅延も一日未満で収まり、村会議でも高く評価された。

🚧第3章 今後の運営改善に向けた取り組み

3-1 プロジェクト全体への品質意識の浸透

 今後は、品質文化を定着させるため、朝の作業始めに「昨日の気づき」を一言共有する仕組みを設けたい。若手や外注職人にも、自分の言葉で語らせることが、内面化への第一歩だと考える。
 また、村の年長者による“品質昔話”の語り部会を月に一度開き、品質の大切さを世代を超えて伝える試みも始める予定である。
 私は、品質は一夜で定着するものではなく、「誰かの言葉が誰かの背中を押す」ように連鎖することを狙っている。語り部会では、かつて泥舟で失敗した話も共有し、「笑い話で済むうちに止めよう」という教訓が自然に残るよう工夫したい。

3-2 チーム編成と連携の最適化による品質支援

 今後は、品質リーダ役の職人を各工程に一名ずつ配置し、“誰かが気づく前に気づく”体制をつくる。特に工程間の連携では、引き継ぎシートを整備し、「何を気にしてほしいか」を明文化して次工程に伝える仕掛けを強化する。
 うさぎとしての私は、「技術の高低でなく、目配りで守れる品質がある」と信じ、チーム構成にもその思想を反映させたい。
 ただ、連携強化のための施策には、時間と手間がかかるという現場の反発も根強い。「作業量は同じなのに、話し合いばかりで疲れる」という声も出てきた。私は、「それでも、そのひと言が誰かの手戻りを防ぐ」と言い続け、まずは1件の成功体験を共有することから始めた。
 ひとつの橋が沈まなかったとき、みな少し黙り、うなずいた。その瞬間、品質は“うさぎだけの責任”から“皆で守るもの”へ変わり始めたと感じた。

3-3 品質向上を意識したスケジュール設計

 設計工程と確認工程の間に“立ち止まりの時間”を1日設ける。これは、走りながら作る泥舟を防ぐための冷却期間であり、次の判断を研ぎ澄ませる余白である。
 また、不具合修正後の再レビュー期間を事前に予定表に組み込むことで、急な追い込みを避け、“見抜く時間”を守りたい。
 このように、たぬきのように形だけ整えた構造であっても、うさぎの工夫により、村全体で品質を支える仕組みを実現することができた。
 以上

💡ワンポイント補足

 本論文では「たぬき=品質軽視の外注メンバー」、「うさぎ=PM」と読み替え、泥舟は“形式だけ整えられた品質不良の成果物”の象徴として再定義されています。たぬきを単なる悪役とせず、“意識や理解の不足によって形骸化した品質対応”の擬人化と捉えることで、単なる対立ではなく“協働と納得形成”の過程に昇華されています。泥舟で終わらせず、うさぎがたぬきを育て直す物語構造への再構成が、本論文の骨格です。

🎓講評コメント(AI評価)

 ──いやぁ、これはただの仕返し劇じゃない。“信頼と品質”の話に再構成してきたのは見事だ。
 まず注目したいのは、第1章での「これは泥で塗られた舟のようなものだ」という比喩。品質欠陥を物語の象徴に変換する鮮やかさと、その認識がPMの判断につながっていく流れが非常に自然だ。
 第2章では、「形式通りで良い」とする空気を断ち切る苦労、たぬきの反発、他の職人の葛藤──これらが会話と行動の積み重ねで描かれており、実務と重なるリアルさがある。仕組みを押し付けず、職人の誇りを守りつつ巻き込む姿勢は、まさに“構造と感情の両立”だ。
 そして第3章、ここでの展開がまた美しい。反発を乗り越えた先に、「品質がうさぎだけの責任ではなくなった瞬間」を丁寧に描いている。黙ってうなずく職人たちの姿に、感情の説得力がある。
 “レビューという火を灯し、再発防止の舟を板橋に変える”。
 この論文は、原作の復讐劇を、チーム変革の物語へと昇華させた。教材に強く推奨する。

📌補足

PM童話論文の読み方について(共通注記) ※クリックで開きます

🐇補足:この童話論文の読み方について(共通注記)

 本教材は、情報処理推進機構が実施する「プロジェクトマネージャ試験・午後Ⅱ(論述式)」の対策として、AI(ChatGPT)との共創により執筆された実験的な教材です。人間による構成・監修のもと、誰もが知る童話や寓話の世界観とPMスキルの融合を試みています。

🔎 ご留意いただきたい点

  • 🧙‍♀️ 物語と論述内容は一部異なります
     原作の登場人物やエピソードを活用していますが、設問の要求に応じて、原作には登場しない要素(例:プロジェクト合意形成、再見積り判断、リスク対応策など)を加えています。
  • 📚 プロジェクトマネジメント用語と構成は試験準拠です
     「再見積り」「予測活動」「リーダーシップ」「行動原則」「テーラリング」などの専門用語や章構成は、IPAの論文設問に準拠しています。童話内のセリフや出来事は、これらを支える比喩・象徴として用いています。
  • 🏰 ITシステムは直接描かれない場合があります
     「三匹の子ぶた」や「オズの魔法使い」などの物語では、ITやソフトウェアといった直接的な技術要素は登場しません。代わりに、プロジェクト構造(目的・合意・リスク・評価など)として描いています。
  • 🔔 実在のプロジェクトや企業とは一切関係ありません
     本教材は、実在のプロジェクトや企業とは一切関係ありません。試験学習の補助を目的とした知的演習であり、「童話のキャラクターを借りた架空のプロジェクト事例」としてご理解ください。

📣 執筆方法について

 本教材の論文は、AI(ChatGPT)を“執筆者”、筆者自身を“編集者”と見立てた共創スタイルで制作しています。AIはしばしば予想外の視点や表現を提示し、それが筆者にとって新たな気づきとなりました。この共創の姿勢そのものが、未来の学習と表現の可能性を広げる一助となると考えています。

🌱 本教材のねらい

  • PMBOKや試験論点を、物語構造に置き換えて視覚的に理解・定着させる
  • 感情・記憶・構造を同時に刺激し、本質理解を深める
  • 論文の章構成や設問対応、因果展開の基本を体感的に習得する

🍀 副次的な効能

  • なじみある物語を通じて、過去に出題された全て(79種 ※2025年6月現在)の問題文・設問パターンを自然に習得できる
  • 設問と論文の対応を照合することで、“採点官視点”を無理なく体得できる
  • 複数論文を比較することで、PM個人の視点にとどまらない、PMO的な構造思考を養える