はじめまして。クオリティコンサルタントの つとう工房 です。
ソフトウェア開発における「品質」とは、いったい何を意味するのでしょうか。
PMBOKやISO等の国際的な標準に準拠し、チェックリストを整備し、ルール通りにレビューを行う。確かに、それは品質保証にとって欠かせない取り組みの一つです。しかし、「品質」の問題に関して、私が、現場で常に感じているのは、その取り組みだけでは不十分だということです。
真に求められるのは、現場の実態を理解し、プロジェクトごとの特性を見抜き、表層的な課題の奥に潜む本質を見極める力。言い換えるならば、“イメージ力”と呼ばれるものの重要さです。本稿では、気軽な読み物の体裁を保ちながら、私が、直近対応した大規模プロジェクトの事例をもとに、“イメージ力”がなぜ品質向上に不可欠なのかを掘り下げてみたいと思います。
1. 品質の確保を阻んでいたのは開発に向き合う“体質”だった
現在、私が支援中の案件は、3年にわたる大規模システム開発プロジェクトです。私が参画したタイミングでは、開始からすでに2年以上が経過していましたが、進捗管理も、プロダクトの品質管理もまったく機能していない状態でした。
ヒアリングを開始した当初、関係者からは「うまくいっていないのは外部要因のせい」「人手不足がすべての原因だ」といった声がまことしやかに囁かれていました。
しかし、私は、その言葉を鵜呑みにせず、現場で交わされる会話、提出された資料、ミーティングでの空気感から醸し出される、いわゆる“ノイズ”に注目しました。そうして、時間をかけて丁寧に観察していくうちに、次第にプロジェクトの根本的な問題が浮かび上がってきたのです。
問題の本質は、管理スキルの不足にはなく、開発部門に根付いた“組織体質”にありました。
たとえば、明らかに遅延しているのに「全体的には順調です」と報告されるケースが散見されたり、進捗会議では数値を用いた報告がほとんどなく、問題を報告する文化自体が欠如していたり、さらには、開発メンバーの多くが「自分のタスクだけやっていればよい」という姿勢で、チームとしての一体感が感じられない雰囲気が蔓延していました。
エンドユーザーからは、「遅延の原因を具体的に示してほしい」「今後の改善策を提案してほしい」といった要求が繰り返し出されていましたが、開発側からは具体的な説明もなければ、対策の提示もありませんでした。結果として、ユーザーとの信頼関係は大きく損なわれ、プロジェクトの空気は次第に重苦しくなっていくのが、傍からも感じ取れました。
PMBOK、ISO/IEC25010およびISO/IEC9126に基づく改善提案
私は、品質コンサルタントとして、本プロジェクトの中盤からこの案件に参画させていただき、PMBOK、ISO/IEC25010およびISO/IEC9126などに基づく、A4用紙100枚程度の体系的な改善提案書を作成しました。
そして、その提案書の中で、
- 進捗管理の可視化
- リスク管理の仕組みの提案
- レビュー手順の見直し
などの提案を展開しました。
しかし、その一方で、その作業を進めながら、この提案だけでは足りないと強く感じながら執筆を進めてもいました。
なぜなら、この現場の品質の根本的な問題は、プロジェクトマネージメントのテクニカルな手法不足に起因しているというよりも、「事実を正しく受け止めようとしない・伝えようとしない」という姿勢の欠如、つまり“ファクト＝事実”に寄り添うというごくごく常識的で基礎的な姿勢の欠如にあると痛感していたからです。
レトロスペクティブ文書にまとめる
これを受け、私は、テクニカルな提案書とはまた別に、振り返り文書として「レトロスペクティブ文書」をまとめることにしました。
「レトロスペクティブ文書」では、まず、この数年にわたってエンドユーザーが声を上げても、不毛地帯に向かって叫んでいるように実行に結びつかなかった、あたかも“暖簾に腕押し”のように繰り返されてきた虚しいやりとりを、ひとつひとつ議事録から拾い上げ、その実態を示しました。そして、問題の根本原因は、開発担当部門の組織体質に関わる問題であり、プロジェクトの状況をありのままに報告し、解決に向けて真摯に取り組む姿勢がなかったことに起因すると結論付けました。
そして、さらにそれを受け、「進捗を正直に報告する」「問題を隠さずに共有する」「曖昧な表現を避ける」といった、組織として根付かせるべき“行動様式”を示し、「良い報告ではなく、正しい報告が信頼を生む」「実態を変えずに見せかけだけ整えても意味がない」といった箴言も書き添えることにしました。これらの提言は、テクニカルな手法以上に、文化的な改革の重要性を訴えるものでした。
2. 「イメージ力」が導く実践的な品質支援
品質エンジニアが、品質改善を検討する上で最も重視しなければいけないのは、プロジェクトに対して杓子定規に「標準規格を適用する」という点にはありません。もちろん、標準に従うことは大変重要ですが、それ以上に必要なのは、「現場の実態を正しくイメージし、適切な手を打つこと」です。それを、私は、“イメージ力”と呼びたいです。
“イメージ力”とは、形式に表れない情報を読み取る力です。たとえば、ある週の進捗会議で「ほぼ予定通りです」と報告されたとします。その言葉の裏に、何があるか。関係者の表情や声のトーン、前週の報告との矛盾、未提出の成果物の存在、些細な変化に注意を向けることで、プロジェクト実態の息遣いを汲み取ることができます。
また、開発メンバーとの雑談の中からも、重要なヒントを得ることがあります。あるメンバーが「最近は、毎晩遅くまで残業していて…」と漏らした一言から、タスクの見積もりに無理があることを察知し、工数再計算の提案をしたこともありました。これは、数値データだけでは決して見えてこない問題です。
また、ドキュメントレビューでも、単に「記載ミスがないか」をチェックするだけではなく、「このドキュメントで次工程の作業者が正しく動けるか」という視点を持ちます。文書が整っていても、読み手の視点を想像しなければ、品質は担保できません。実際、過去にレビューで「問題なし」とされた仕様書が、実装段階で多数の不整合を生んだケースもありました。
こうした経験から、私は、「品質とは、書かれていないものを想像する力」によって左右されるものと考えます。品質エンジニアにとっての武器は、標準規格の知識だけではなく、現場と対話し、空気を読み、背景を推察する“イメージ力”なのです。
以下、ここまで詳述してきた“イメージ力”について、簡潔に要約してみます。
🧑💻現場とつながり、密に対話する姿勢を持つことの必要性
直接、現場に足を運ぶ、ないし定期的な対話やオンラインでのやり取りを通じて、現場の声や温度感をつかむことの重要性。情報の行間や空気を捉えるには、「話す量」と「聴く姿勢」が何より大切であるということ。
👀些細な変化や違和感を見逃さない観察眼を持つことの必要性
進捗報告やレビュー内容、メンバーの一言一言の裏にある「兆し」に気づくためには、日頃から注意深く観察し、「あれ？」と感じる感度を磨いておく必要があるということ。
🔍ドキュメントや発言の“先”を読み、次工程や他者の立場を想像することの必要性
成果物は、次工程の作業者にどう伝わるか？ 実際に手を動かす人の視点を想像することで、形式だけではない「本当に使える品質」を見極めることが可能になるということ。
🛠️標準の適用に捕らわれ過ぎず、柔軟に現場に合わせた対応を心掛けることの必要性
いうまでもなく標準は重要ですが、それをどう現場に馴染ませるかが、品質エンジニアの腕の見せ所。常に、現場の実態を起点に考える姿勢が、品質改善の鍵になるということ。
私が、本稿でお伝えしたい“イメージ力”は、上記のような形に要約できるかと思います。
3. 前職のQA統括部門に抱いた違和感
私の前職では「QA統括部」という部門があり、全社の品質保証活動を担っていました。部門としての体制は整っており、各プロジェクトに対して一律の品質ガイドラインを適用するスタイルでした。
しかし、私は、その部門の品質に対するアプローチに対して、長年、強い違和感を抱いていました。なぜなら、その施策の多くが“目的化”しており、本来支援すべき現場の実態と乖離していたからです。
たとえば、ある小規模な改善プロジェクトでは、ステークホルダーが限られており、関係性も非常に安定していたにもかかわらず、「PMBOKに記載されているから」という理由だけで、「ステークホルダー・エンゲージメント・アセスメント・マトリックス」の提出が求められたことがありました。担当PMは、「この作業、誰のためにやるんでしょうか…」とこぼしていたものです。（デヴィッド・グレーバー博士の“ブルシットジョブ —— クソどうでもいい仕事”が産み落とされた瞬間！）
また、プロジェクトに重大な品質リスクが発生した際にも、「定期レビューに合格しているから問題はない」と判断され、現場の悲鳴は聞き流されたこともありました。形式的なレビュー手続きが、実態を覆い隠す盾となっていたのです。
私は、QA部門こそが、最も柔軟であるべきだと考えています。プロジェクトごとに状況を見極め、何が本当に必要なのかを見出す。それは、画一的な知識ではなく、経験と洞察と対話から生まれる対応力です。つまり、ここでも“イメージ力”が問われているのです。
QA部門が、ただ規格を押し付ける存在ではなく、「現場のパートナー」として機能するようになれば、品質文化は劇的に変わるはずです。そのためには、制度やチェックリストよりも、現場に寄り添う姿勢が求められます。
まとめ
言うまでもなく、われわれは、品質エンジニアのプロとして、お客様や、そこらのソフトウェア開発ベンダーが足元にも及ばないくらい、ソフトウェア品質に関しての専門的な知見を保有していなくてはいけません。しかし、品質とは、標準規格による単なる文書管理やレビュー手続きの整備ではありません。それに加え、現場に入り込み、プロジェクトの実像を“イメージ”し、必要な対応を的確に提案できることを併せ持つことが不可欠なのです。
品質を支えるのは、標準規格ではなく“人”です。だからこそ、QAエンジニアには、机上の知識だけでなく、現場を観察し、対話し、本質を見抜く力が求められます。私は、これからも“イメージ力”を更なる武器に、プロジェクトの実態に即した品質支援を続けていきたいと思います。
そしていつか、形式に縛られず、現場の声を真に受け止められるQA部門が、業界全体に広がっていくことを願っています。品質の本質は、形式ではなく、“想像と行動”の中にあると考えるからです。
——しかし、いったんそんな風に結論付けてはみたものの、その理想郷を目指そうとする姿勢自体が、かつて紀元前の昔、世界最高の知性が独り言ちた、
“The more perfect a thing is, the harder it is to acquire.”（物事が完全であればあるほど、それを手に入れるのは困難である。）—— アリストテレス
という、現代に至るまで、人間が性懲りもなく繰り返してきた“退屈な”取り組みそのものを、また繰り返し反芻してしまっていることにハタと思い至り、その結論の凡庸さに、我ながらいささかのうんざり感を覚えつつ、この場はいったん以上で筆を擱きたいと思います。
