アーカイブ動画

品質をマネジメントする「QMO」がプロジェクトで必要不可欠な理由

バルテス株式会社
テスト・アライアンス事業部 事業部長　石原 一宏氏

最初に登壇した石原一宏氏は、ソフトウェアテスト業界で30年以上活躍してきたエキスパートで、品質テスト業務においても数多くのプロジェクトに携わってきたキャリアの持ち主だ。著書も多数あり、現在ではセミナー講師も多数務める業界の第一人者である。

石原氏はこれまでの豊富な経験から、手戻りを減らすためには、品質からアプローチすることが重要であり、実現に向けてはQMOの存在が大きいと強調する。まずは、QMOが求められている理由を次のように話した。

「プロジェクトマネジメントでは一般にQCD（品質、コスト、納期）の管理の重要性が説かれるが、私の経験では、コストを削ると手戻りとして返ってくることが多い。一方納期も、不測の事態が発生すると簡単に破られてしまう。対して優秀なPMを見ていると、品質ベースでプロジェクトを進めていることが多いと感じています」（石原氏）

PMOの役割や現状についても言及した。PMBOKに代表されるプロジェクトマネジメントの体系は造船や建築といった成果物が目に見える形でわかるいわゆる重厚長大なものづくりのプロジェクトをベースとして作られているため、成果物が目に見えにくいソフトウェア開発案件ではクオリティ領域に関する管理手法が、ハードウェアに比べて弱い側面が存在する。

その結果、上流の各工程で途中成果物がオンスケジュールで確認されていても、結合テストやシステムテストなどプロジェクトの末期で、一気にバグが生じるなどのケースが生じることが多いという。

そこでこのような背景、そしてテスト専門会社としての経験則から大型ソフトウェア開発プロジェクトにおいては、PMやPMOのマネジメント業務に加えて、ソフトウェア品質管理の観点で支えることが重要と考える。

具体的にはPMBOKの管理エリアのうち「品質管理」「統合管理」「リスク管理」領域をソフトウェア品質の観点から担う「QMO（Quality Management Office）」の存在が必要となる。プロジェクトにおける具体的な業務、QMOに求められる資質について次のように語った。

「プロジェクトやプロセスのどこに瑕疵があるのか、嗅ぎ分ける嗅覚がQMOには求められると感じています。山登りで例えればどこが難所なのか。他のうまくいかなかったプロジェクトから情報収集をするなどして見つけ出し、解決策をトレーニングしておく。いい意味で怖がりな方、慎重な方が向いていると思います」（石原氏）

大規模なソフトウェア開発プロジェクトでは、従来のようなPMOの手法で取り組み、上流工程で基本設計や成果物の管理などを行ったとしても、品質管理のスコープが弱いため、結果として下流のテスト工程で不具合が発生することが多くなってしまう。

「リリース3日前に準正常系や異常系の「仕様抜け」が見つかるケースなどを何度も見てきました」（石原氏）

下流のテスト工程で不具合が発生しがちだ。とりわけテストフェーズが先に進んだ状態、後手になればなるほど、手戻りの修正コストは嵩み、場合によっては要件定義のフェーズからやり直す必要が生じるケースもあるという。

「品質ストーリー」を作成。上流工程で不具合の削減・下流工程で刈り取り

コストを減らす戦略においては、これまで年間3,000件以上✕20年間以上という膨大なプロジェクトに携わった経験則から得た対応策が紹介された。

「不具合はできるだけ上流工程でつぶしたい」と石原氏は語り、上流工程から「品質ストーリー」を仮説検証することが重要だと強調。品質ストーリーについて、詳しく解説を行った。

品質ストーリーとは、上流工程での品質の作り込み、下流工程での不具合の刈り取りをどのように計画し、実行していくかの戦略作りを意味する。「プロジェクトの背景・リスク」を分析、可視化するなどの具体的な取り組みが語られた。

品質管理の基本は予防であり、できるだけ上流工程で開発努力を重ねることで、バグを少なくする。バグを下流のテスト工程の早い段階で見つけることも重要だが、「下流工程はあくまでバグを見つけるだけ。いくらテストだけがんばっても品質は上がりません。本質的に品質を上げるのは上流工程、すなわち設計工程と実装工程です」と、石原氏は語る。

上流工程で発生したバグは以下スライドのように、フェーズが進むにつれて、いわゆるエントロピー増大の法則として増え続ける傾向がある。そのため、改めて上流工程でバグを作り込まないようにすることが重要だ。石原氏は「下流工程で叩くのは最小限にしたい」と繰り返した。

石原氏は改めて、品質ストーリーの作り方を、具体的に順を追って説明。まずは「背景・リスクの分析と可視化」である。特に、品質面でのリスクを書き出していくことがポイントであり、品質リスト一覧などを作ることを勧めた。

続いては、「うまくいった仮説に基づいた計画」である。背景・リスク対策の一覧に対して、それぞれ対策を講じていく。その上でテスト計画を作成する。ISOの規格をベースとした一般的なテストプロセスも紹介、次のように勘所を話した。

「線表にリスクポイントを組み込んでいくこと、プロジェクト内容によりテーラリングすることなど、特にQMOにおいては赤枠部分が重要です」（石原氏）

優秀なPMは、まず最初に下流工程のテストの発想を踏まえた上で、つまりリスクポイントを抑えた上で、上流工程の仕様書を揃えていく人が多いと石原氏は指摘する。そのような意識で上流工程で必要なコストをかけることが、結果として下流工程での不具合発生、つまり手戻り率を下げ、プロジェクト全体のコスト削減に有効であると語った。

策定したテスト計画はそのまま続けるのではなく、1週間に一度といった頻度で定期的に検証することで、改善をフィードバックする。そのループをまわすことが重要だと述べた。

事例1：ホストからERPへ刷新するプロジェクトが頓挫、要件定義が再スタート

バルテス株式会社
エンタープライズ品質サービス第１事業部 東日本ソリューション部
QXソリューションサービスグループ 副部長　倉澤 直樹氏

続いては、SIerでパッケージ開発プロジェクトの開発から導入、保守業務まで、一貫して経験してきた倉澤直樹氏が登壇。エンタープライズ領域でのERP導入、マイグレーションといったプロジェクトのPMや、品質の向上やコンサルティングを担当している。

倉澤氏は石原氏が紹介した「品質ストーリー」が、プロジェクトでどのように作成されているのか。具体的に2つのプロジェクトを紹介した。

1つ目は、ホストコンピュータからERPへ刷新するプロジェクトである。結合テスト段階で頓挫したため、バルテスに声がかかり、要件定義から再スタートすることになった。倉澤氏は石原氏が説明したように、まずはプロジェクトの背景を分析し、次のようなリスクを抽出していった。

◆プロジェクトの背景から抽出されたリスク

• メンバー経験が浅いことで、属人的で甘い設計書の書き方となっていたのではないか
• 結合テスト段階で単体レベルの不具合が多く、摘出できていなかったのではないか
• 品質内容を適宜確認できておらず、テストの進捗しか見れていなかったのではないか

続いてはプロジェクトの内容、それぞれの側面から再度、リスクを分析、抽出していった。

◆プロジェクトの内容から抽出されたリスク

• 性能面：利用者が多く、性能問題が発生する
• データ移行：並行稼働しないため、移行データの品質によりリリースが延期となる
• 現新比較：現行と新のシステムが異なるため完全な比較ができず、正解が分からない

そしてこれらのリスクに対して、それぞれ対策を検討していった。例えば、「利用者が多く、性能問題が発生する」とのリスクでは、「単体テストから特定機能に対して、性能テストを計画する」とした。

さらに倉澤氏は、これらリスクならびに対策をExcelのように一覧表にすると共に、分類や発生確率、影響度、リスク監視頻度なども同じく細かく分析して記入。テスト計画の材料とした。そして次のステップ「上手くいく仮説」の計画へと進んだ。テスト計画におけるポイントを、倉澤氏は次のように述べた。

「ポイントは3つあります。1つ目はリスク一覧から優先度付けを行うこと。2つ目は、基本的な考えとして前倒しすること。3つ目はすべて対策するとコストに影響するため、部分的にでも行うことです」（倉澤氏）

倉澤氏はこのような勘所、3つのポイントを抑えた上で策定したテスト計画のロードマップも紹介した。赤く塗られた領域のテストで抑えるべきテストを実施する箇所である。

続いては3つ目のフェーズ「計画した仮説の検証・改善」だ。大きくは2点あったと倉澤氏は語る。1つ目はリスク状況である。

リスクは変動することもあるので状況を監視し、その結果を踏まえた上で改善を計画すること。もう1つは定期的に品質分析を行うことで、弱点を洗い出し、被害を最小限に留めることだ。

「1週間に一度の頻度でこまめに分析することが重要だと思います。その際に前工程で抽出すべき欠陥が多い場合には、さらなる注意が必要です。結果として同プロジェクトは大きな問題なく、リリースすることができました」（倉澤氏）

事例2：大規模オフショア開発プロジェクトにおける品質・生産性の担保

2つ目は、オフショア開発のプロジェクトにおいて品質・生産性が懸念されたプロジェクトだ。こちらのプロジェクトも、まずはプロジェクトの背景を分析し、次のようなリスクを抽出していった。

◆プロジェクトの背景から抽出されたリスク

• 設計書の記載方法が属人的なため、記入漏れが発生するのではないか
• 単体テストが網羅されていない、不十分なのではないか
• 単体テストの実施方法が個人に依存しているのではないか

続いても先と同様、プロジェクトの内容、それぞれの側面から再度、リスクを分析、抽出していった。

◆プロジェクトの内容から抽出されたリスク

• 要件定義：システムの全体が見えず、業務フローとの整合性がとれない
• 外部I/F設計：外部システムとの関連箇所が多く、内部システムとの整合性がとれない
• 性能：10年でトランザクションが1億件となる可能性がある

これらのリスクに対して先と同様、対策を検討し洗い出していった。設計の属人化リスクでは、セルフ、有識者、第三者がそれぞれレビューするプロセスを構築。性能面でのリスクにおいては、要件定義段階での性能PoCと単体テストでの性能計画などである。

現状はリスク検証ならびに品質分析を行いながら、プロジェクトが進んでいる段階とのこと。倉澤氏は次のように話し、セッションをまとめた。

「ステークホルダーが多いプロジェクトでは、品質分析を行うために不具合情報を記載してほしいと伝えていても、対応してもらえないケースもあり、必ずしもうまく進むわけではありません。一方で、リスクの抽出やテスト計画、改善を実行することで、プロジェクトは良い方向に進むと考えています」（倉澤氏）

なお倉澤氏の発言に対して、石原氏が次のように補足している。

「危険箇所を可視化し全ステークホルダーにつまびらかにすることがポイントです。それでも動いてくれない人には改めて打診し、そのままの状態で放置しているとどのようなリスクがあるのか、考えてもらうことが大事だと思っています」（石原氏）

【Q＆A】参加者からの質問に登壇者が回答

視聴者からの質問に答えるQ＆Aセッションも設けられた。一部を紹介する。

Q．テスト計画例にあった「単体／結合テストガイドライン」の具体的な内容は？

倉澤：テストの設計や実行、不具合の起票方法など、各人がそれぞれの感覚で行うと、プロジェクトが大きくなった際に一定の品質が保てないので、ガイドライン化し、メンバーに教育した上で実行してもらいます。QMOは実行状況を監視し、フォローや指導を行います。

石原：従来のプロジェクトマネジメントの考えだと、詳細設計やレビューもできているのに、実装単体テストがうまくいかないこともある。すると、プログラマーがサボっているのではないかという考えになりがちです。

しかし、そのような考えは間違っていて、単体テストを設計するインプットや、詳細設計の粒度が悪かったからです。もちろん人によってテストがバラバラなのも問題ですが、準備やリスクポイントも含めてガイドラインとして統一し、しっかり考えていくことが重要です。

Q．品質分析や可視化の実施、判断基準の具体的な設定ポイントは？

石原：1つ目は、リスクの優先度と合わせて影響度分析を簡単にした、リスクが生じる確率と、リスクが生じたときのインパクトをそれぞれ3段階で出し、その確率とインパクトの数値の和（もしくは積）を優先度とし、優先度の高いところから着手していきます。アメリカの国防総省なども行っている有効な方法です。

もう1つは作業に従事している人のテーラリングです。作業に即していない人を外してフィットする人材をアサインするのがベストですが、難しい場合が多いため、今のリソースでどうすべきか。その際に、リスクとなり得る人材を可視化しておくことは有効ですし、応援も要請しやすいです。

倉澤：品質基準を設けてクリアしているかどうかで判断する場合、IPAなどの指標を元に判断していると思われます。しかしその指標で用いられているデータが、そもそも目の前のプロジェクトと一致しているかどうか不明です。そのためプロジェクトの中身のデータを、しっかりと見る必要があります。 

一方で、データだけでは判断できないとも考えています。作業に携わる人たちの個性があるからです。そこで私の場合は、開発に携わる人たちとコミュニケーションを取り、それぞれ仮説を立てることで、判断の指標としています。泥くさい取り組みではありますが。

石原：倉澤さんの意見に賛成です。私も毎週開発メンバーを回り、情報がないかどうかを確認しています。すると実際、数字、データの裏にある事情などが見えてきて、それが品質につながったりします。例えば、作業にマッチしない人が、事情を抱えているようなことも見えてくるケースがあります。それも踏まえてテーラリングする取り組みにもつながります。

Q．不具合を最小限に抑えるために上流工程でやるべきことは？

石原：今今持っている情報がすべてではない、と考えることが重要だと思います。今の情報が完璧だと思って開発を進めるのは危険だし、不足しているということです。

2つ目はリスクのインパクトです。不具合というのは数ではなく、質です。例えば、多少の文字化けは許容範囲ですが、誤情報や他のユーザーに登録できるなど、セキュリティに関する不具合はインパクトが大きい。特にセキュリティとアベイラビリティ（可用性）は背反となり、トレードオフの関係になるので注意が必要です。

もう1つは、例えば大規模な業務システムを開発したとします。経理部の人たちは楽になったけれども、業務系の方たちは入力作業が加わったことで、手間となってしまった。よくあるケースです。

このような不具合が生じないよう、ステークホルダーの間でトレードオフ、真逆のベクトルが生じそうな場合は、トップがどのような方針、意思決定するかを、明確に打ち出しておくことを意識しています。

Q．リスクの優先度はどのような基準で決めているか？

倉澤：プロジェクトの内容をベースに、影響度のかけ合わせで考えています。これが正しいというのはないと思いますが、何らかの指標を決める必要はあるからです。

石原：リスクインパクトの大きさで優先度を決めていきます。例えば、来るべきデータが来ていない。そもそも業務が通常に動かないといったリスクは、優先度を高く設定します。また、業務フローにリスクカテゴリ一覧を設け、見える化して考えることも多いです。

「ISO/IEC25010 SQuaRE」などを参考に、使い勝手、セキュリティ、信頼性、保守性と、互換性いった仕様書とは関係のないカテゴリを、例えば正常・異常系を横軸として、これら機能面を縦軸した図などにして可視化します。

その上で過去に実際に発生したリスクや、同業他社の動向なども考慮しながら、ステークホルダー全員でリスクの優先度を決めていくといいと思います、可視化しているので議論もしやすいです。

Q．品質分析では具体的にどのようなことを実行したか

倉澤：不具合が生じた際、現場メンバーで原因やカテゴリを不具合管理ツールに記載し、その情報を元に分析します。ただよくあるのが、「ケアレスミスでした。以後、気をつけます」と、起票されるケースです。

これだけは品質改善に向けての意味がありませんから、現場メンバーにコミュニケーションを取り、ケアレスミスではなく例えば標準化されていなかったからなのではないかと、泥くさい啓蒙活動を続けていました。

石原：すべてのミスはケアレスミスだと言えることもできますが、それは解像度が低い状態とも言えます。これまではケアレスミスだと捉えていたものから、啓蒙活動などを通じて詳細設計を定義するなど、解像度を高めていく。ケアレスミスのように個人の問題にするのではなく、組織としてレビューの仕方やドキュメントの改善などミスをしにくい仕組み作りはできないか、という見方に変えていくことが重要です。そうすることで組織として、個人としてより成熟度が上がり、不具合の減少に繋がっていくと考えています。

バルテス株式会社
https://www.valtes.co.jp

バルテス株式会社の採用情報
https://recruit.valtes.co.jp