ソフトウエアの品質向上に関する様々な仕組みや工夫は、先人から受け継いだ技術蓄積があります。そしてその技術蓄積を支える考え方も一緒に蓄積されています。
本稿では、日本のソフトウエア品質技術の発展と世界とのつながりの一端を紹介しながら、日本に根付いているソフトウエア品質向上のやり方を、より一層、理解するためのヒントを提供したいと考えています。本稿は、特に若いソフトウエア技術者を意識していますが、もちろんベテランの方々にも、考え方の整理に役立てていただけるのでは、と思っています。
今日、さまざまな知識情報が我々の周りを取り巻いています。海を越えて多くの知識情報が我々の手元に届きます。このとき、海外からの情報発信に振り回されることなく、これまで発展させ蓄積してきた日本のやり方に、もっと自信を持って取り組んでほしいと思っています。ただ、注意願いたいのは、筆者の狙いは、一方的に日本のやり方の優位性を説くことではありません。むしろ、この地球上でおたがいに影響し合って、相互に発展してきた事実に目を向け、世界の全体像の中で、日本のやり方というものを理解することをお勧めするものです。

ＳＱｉＰ（Software Quality Profession）活動は、その前身であるＳＰＣ研究委員会（ソフトウエア生産管理研究委員会。以下、ＳＰＣと呼ぶ。）の活動を含めれば、３０年以上の歴史があります。この活動の狙いが「ソフトウエア工学とＴＱＭの結婚」と称されているように、ＳＰＣでは、日本がハードウエア製造業の品質向上で成功を収めた原動力であるＴＱＭの考え方と方法論を、ソフトウエア品質向上にも役立てるべく、活動を展開しました（参考文献１）。最近、若いソフトウエア技術者と話をすると、皆さんＳＰＣもＴＱＭも知っているのに、ＳＰＣ活動の狙いが、上述の「結婚」であることを、意外にも知らないことに気がつきました。このため、あえてここで言及しました。
ＴＱＭに基づく品質管理は、日本製品の優秀性とともに世界の関係者の注目を浴びました。ＳＰＣ活動に参加した多くの日本の企業が、ＴＱＭの考え方をもとにソフトウエア品質向上活動を実践して成果を上げました。ＮＥＣが全社的に展開したＳＷＱＣ活動における仕組みや工夫もその一例と言えるでしょう（参考文献２）。

良く知られているように、ＩＳＯ９０００ファミリーのマネジメント手法は、日本のＴＱＭで培われたＰＤＣＡサイクルに基づいています。これは、日本の先人の努力によって国際標準に組み込まれたものです。ただ、国際標準の制定にかかわった専門家や、ハードウエア製造業に従事し日本の改善（Kaizen）を勉強した人達を除けば、海外ではＩＳＯ９０００ファミリーは知っていても、ＰＤＣＡのことはあまり知られていません。また、ＩＳＯ９０００ファミリーの考え方の基礎となっているプロセスアプローチも、「品質は工程で作り込む」というＴＱＭにおける考え方によるものです（参考文献１）。
一方、あまり語られていない話では、ハンフリー氏が提唱したソフトウエア成熟度モデルの中にも、日本のＴＱＭの考え方が盛り込まれています。ハンフリー氏は、日本企業のソフトウエア品質の取り組みを調査するために、日本の主要なコンピュータメーカや、通信メーカを調べました。彼は、ソフトウエア成熟度モデルに関する彼の最初の著書において、日本がデミング博士やジュラン博士から統計的品質管理を学んだことに言及し、さらに、日本が現場の第一線において発展させた欠陥の未然防止活動（defect prevention）の重要性と、その実践が成功裏に展開されていることに言及しています。そして、誤りの原因分析（error cause analysis）と欠陥の未然防止（defect prevention）を、彼のソフトウエア成熟度モデルのレベル５の実践に必要なものと位置づけました（参考文献３）。

国際標準の記述や、ソフトウエア成熟度モデルの記述は、その性格上、付随する歴史的背景や、他の関連知識との関係は簡略化される傾向にあります。また、この傾向は、国際標準やソフトウエア成熟度モデルの教育場面や、アセスメントの実施場面においても同じであり、歴史的背景や他の知識情報との関係が明示的に意識されるわけではありません。また、欧米のソフトウエア品質の専門家全員が、必ずしも日本のＴＱＭに精通しているわけではありません。このため、ＩＳＯ９０００ファミリーやソフトウエア成熟度モデルとＴＱＭの関係は、十分、理解が促進されているとは言い難いのが現状です。
しかも、ＩＳＯ９０００ファミリーやソフトウエア成熟度モデルは、そのもう一つの側面、すなわち、プロセスの実践を客観的に実証するという欧米的な考え方の側面が強調されて理解されたため、その背後にあるＰＤＣＡやプロセスアプローチなどの考え方は、本質的にＴＱＭと共通であるにもかかわらず、ＴＱＭとは異なった考え方に基づく国際標準やソフトウエア成熟度モデルであると理解されているのが現状と思われます。次章では、この「理解の壁」を取り崩し、より本質を理解するためのヒントを述べます。

前章で述べた知識情報の「理解の壁」を取り崩すためには、その知識情報が誕生した時代背景や、他の知識情報との関連を知ることです。このためには、その知識情報を取り巻く客観的な事実を明らかにし、他の知識情報との関連性を明らかにしていく努力が欠かせません。時間的な分析だけではなく、地理的、文化的背景を含めた総合的な分析が必要です。
分析のための情報源は、その知識情報に直接携わった関係者による「原典」に、できるだけ当たると良いと思います。「原典」には、第三者によってフィルター（取捨選択）されずに残っている貴重な情報があるからです。
ソフトウエア品質の知識情報の例をご紹介しましょう。２００７年に発行された「ソフトウエア品質体系ガイド－ＳＱｕＢＯＫ Ｇｕｉｄｅ－」です。このガイドは、５階層の構造でまとめられています。第４層と第５層は、独立した個別の知識情報に対応していますが、上位の第１から第３層までは、該当する下位の知識情報に関する背景説明や、他の知識情報との関係が述べられています。特に、海外のやり方との対比説明によって、日本の取り組みの特徴や発展経緯が理解できるようになっています。
前述のＴＱＭとソフトウエア成熟度モデルは、知識体系上は、別の知識項目として分類、整理されています。しかしガイドブックの限られた紙面の中で、両者の時代的背景や関連性についても述べられています。
ＳＱｕＢＯＫ Ｇｕｉｄｅを百科事典的に、ある特定の知識を知るために利用することもあるでしょう。しかし、その知識を必要とした背景や、複数の知識相互の関係を合わせて通読し、全体像を理解することをお勧めします。言い換えれば知識情報を噛み砕いて理解し、現在、各自が抱えるソフトウエア品質の課題に照らし合わせて、知識情報を十分に読み解いてほしいと思います。

当たり前のことかもしれませんが、日本のやり方を理解するには、海外のやり方を見て自分たちのやり方と対比してみると良いし、現在の問題を理解するには、歴史を振り返ってみると良いと思っています。地理や文化も含めた、いわばソフトウエア品質に関する「歴史学のすすめ」を提案いたします。

やみくもに誤りだけを検出、指摘するだけでは、いくら時間があっても足りない場合が多いでしょう。まず、どのような欠陥を検出、指摘することがレビューの効率化につながるのかがプロジェクトやレビューアの間で合意できているかに気づく必要があります。合意できている場合にはそれに沿って欠陥を検出するスキルが必要になります。同時に、知識不足等により十分な欠陥検出ができないときには、自身ができる範囲内ではどのような欠陥が検出できるかを想像できる必要があります。また、レビューの実施コストが得られる品質向上に見合うものであるかどうかを意識できると更に望ましいでしょう。

他の人ではなかなか指摘できない深刻で検出の価値が高い欠陥を見つけたとしても、その伝え方が適切でなければ修正されなかったり軋轢を生んでしまったりする場合があります。相手の事情を配慮し、上手に伝えるスキルも重要です。上述1のスキルにも関連しますが、プロジェクトメンバにとって最も有益な指摘から順番に伝える配慮も必要になります。プロジェクトにとって致命的なものは何で、そうでないものは何かを認識できていることが前提となります。組織の文化にもよりますが、これみよがしに徹底的に細かい指摘を並べ連ね、ドキュメントをつるし上げることは「そんなことをやる時間があったら・・」という他のメンバの思いを強くしてしまう可能性が高いでしょう。 このスキルは経験が少ない人に限定されるスキルのようにも思えますが、実は中堅やベテランにも異なった形で求められるスキルです。新人や新しく加わったメンバに対して、威嚇や圧力を与える目的で欠陥を指摘している場面に出会ったことはないでしょうか？新人、新メンバが何か直接的に言いづらい間違いや気にくわない態度を取っているときに、新人や新メンバが担当している部分を必要以上に細かくチェックして、たくさんの欠陥を指摘することで間違いや態度を変えさせようとすることは効果もそれほど望めませんし、時間の面からみても効率的ではありません。

自身が発見した欠陥を端的に説明できるスキルは、特に会議形式のレビューの効率を高めます。きちんとまとめられていないときに限って、自身でも説明不足、物足りないと感じ，長々と冗長な発言をしてしまうことが多い傾向にあります。説明が複雑になる欠陥では、検出時にどのように説明すれば明確になるかを考えるスキルが必要になります。 「他の人が指摘をしているから、なんとなく自分も発言しておかないと」とか「自分も気づいていたことを知らせたい」と思ったとしても、その発言によって会議のスムーズな進行を妨げたり、検討にプラスにならないと考えたりすれば、黙っておくスキルも必要です。黙っておくスキルは中堅以上に特に求められるスキルといえます。

レビューにおいて普遍的なスキルを挙げました。プロジェクトレビュー、ドキュメントレビュー、コードレビュー等、実施形態やレビュー対象によっても求められるスキルはかわります。また、開発するソフトウェアや組織によっても変わりますのでただ１つの正解はないことを認識し、ご自身の状況（コンテキスト）に応じて、どのようなスキルが求められているかを考えなければなりません。本稿がそのようなご検討のヒントとなっていれば幸いです。

2011年2月にソフトウェアテストシンポジウム 新潟で「派生開発でUSDM（Universal Specification Description Manner）とDRBFM（Design Review based on Failure Mode）をミックスして一気通貫で品質確保する」という事例発表をさせていただきました。発表後、資料を見た何人かの方から、進めるに当たっての課題や現場にどのように導入したらよいかなどのご質問をいただきました。このような機会をいただきましたので、この場をお借りして詳しく説明します。

メンバーの持ってきた本を元にして「USDM」を導入し、お客様から紹介された資料をきっかけに「DRBFM」を導入することとしました。どちらも、レビューを重視する点が共通している手法です。

導入にあたっては、私自身の”つかんだ”という感覚と、お客様やメンバーへの定着度合いをみながら順をおって進めました。

（表 2. 課題と施策の対応）

4.1	USDMの導入 施策の第一段階として、USDM（Universal Specification Description Manner）とトレーサビリティ・マトリクス（TM）を取り入れました。 USDMは株式会社システムクリエイツの清水吉男氏が考案された、要求を仕様化するための表記方法です。 USDMには次のような特徴があります。 1つの表に全ての要求・仕様を記述する 要求を2～3段の階層構造で定義する 各要求に対して、その要求が必要な理由を併記する 最下位の要求に対して仕様（その要求を実現するためのシステムの振る舞い)を記述する 要求・仕様にはユニークなIDを付与する このような記法によって変更要件の意味を理解して、変更しなければならない仕様を漏れなく見つけ出して一覧化します。 トレーサビリティ・マトリクス（TM）は、USDMに付随するもので、USDMによって明確にした変更仕様が、どのモジュール（またはソースコード）に影響するかを改造規模で示すものです。これによって、ある要求を満たすには、どこを変更する必要があるのかが俯瞰でき、どのくらいの変更なのかを定量的に把握できます。 USDMとTMをセットにしたドキュメントが「変更要求仕様書」です。（図1） （図 1 変更要求仕様書） 表の左側部分はUSDM記法で記載した仕様です。これは「何を変更するのか」という“What”の視点で記入します。 右側部分は「トレーサビリティ・マトリクス（TM）」です。モジュール単位の列を作成して、仕様に対して変更が必要なモジュールとの交点に改造規模を記入します。TMは「どこを変更するのか」という“Where”の視点で記入します。 表が完成したら、要求が正しく理解できているか、仕様に抜け、漏れがないかを確認するためにメンバー全員で集合形式でレビューを行います。同時に、自担当部分の変更が他メンバーのモジュールに与える影響などの検討も行います。 図には簡単に記入方法を記載しましたが、詳しくは次の書籍をご覧いただくとよいかと思います。 「要求を仕様化する技術・表現する技術 - 入門＋実践 仕様が書けていますか?」 清水 吉男（著） Software People Vol.8 「特集：コンサルタントが教える戦慄の仕事術 失敗しない派生開発」 Software People編集部（編集）
4.2	DRBFMの導入 USDMがメンバーに完全に定着した段階で、「DRBFM（Design Review Based on Failure Mode）」を導入しました。 DRBFMはトヨタのGD3（ジー・ディー・キューブ：Good Discussion, Good Design Review, Good Design）の一翼をなすもので、吉村達彦氏の造語です。「未然防止」の手法で「まだ起きていない問題の発生を予測し、それが起きないように未然に防止すること」を目的に考案されました。 変更点・変化点と機能に着目 レビューによって心配点の発掘・探索 叡智を集め対策を作り込む という考え方の下に、次のような表を使って、レビューを行います。 （図 2 DRBFM記入表） ※「トヨタ式未然防止手法GD3 いかに問題を未然に防ぐか」吉村達彦著 （日科技連）を参考に作成 DRBFMは次のように行います。 設計者が水色のセル（「部品名／変更点」～「心配点を除くためにどんな設計をしたか」）を記入する。 関係者を集めて、黄色のセルの｢他に心配はないか」｢他に考えるべき要因はないか」を議論する。 心配点が見つかったら、それを除くための対応を議論し、「推奨する対応」に記入する。 「心配点を除くためにどんな設計をしたか」の妥当性を議論する。新たな心配点が見つかった場合は表に追記し、対応を議論して、「推奨する対応」に記入する。 最終的に心配点が見つからなくなったら終了とする。 後に対応が完了したら、黄緑のセル（「対応の結果実施した活動」）を記入する。 私たちは、導入当初の何度かは、図2の表をそのまま使ってやってみましたが、記入やレビューに時間がかかる割に効果が現れませんでした。 メンバーに変更要求仕様書とその背景となる考え方がすでに浸透していたため、変更要求仕様書を完成させた段階で、DRBFM表の項目のような想定される問題はすべて考慮済みとなっていたのだと思います。 ”思いもよらない”問題の発生を防ぐには、あまり形式ばらずに、「なんとなく怪しい感じがする」とか「ここは、あとあと何かが起きそうだ」など、理屈では説明できないけれど、経験上なんとなく焦げ臭いところを吸い上げて記録しておき、全員レビューのたびに気づきを誘発する、そんなものが必要なのではないかと思いました。「変更要求仕様書」が論理的な思考をあつかう「左脳」だとすると、予想や直感などをあつかう「右脳」に相当するものです。 そのような発想で出来上がったのが「心配点シート」です。
4.3	心配点シート 心配点シートはDRBFMを使ってみてやりにくかった点をスリム化して、変更要求仕様書とセットで使えるようにしたものです。基本的な考え方は、DRBFMと同じです。 次のような工夫を施しました。 変更要求仕様書と一体化できるように、要求事項と対になるようにした 詳細化しないように、わざと最上位要求という大くくりの単位で作成するようにした 気づきを誘発させるためにDRBFMの表よりもゆるいフォーマットとした 各工程のレビューフェーズでつねに記入できるような欄をあらかじめ設けた 試行錯誤の結果、最終的には、次のようなフォーマットに落ち着きました。 （図 3 心配点シート） 心配点シートは次のように使います。 変更要求仕様書と 同じファイルに納める 心配点シートは変更要求仕様書と対を成すものなので、変更要求仕様書と同一のファイルに別シートとして納めます。（図4参照） シートの単位は、変更要求仕様書の最上位要求単位として、シート名も最上位要求のIDを記入します。 （図 4 心配点シート） シートの上段 上段左側に、変更要求仕様書の大要求の「要求事項」を、左側には「理由」を、変更要求仕様書どおりに記入します。 シートの下段：左側 左側に「変更するにあたっての懸案・心配点」をなるべく短く記入します。レビューで気づきを誘発するのが目的なので、詳細に書く必要はありません。今はまだ発生していないけれど、将来発生しそうな問題、なんとなくぼんやりした不安点などを、論理的かどうかは気にせず1行につき1つ記載します。 シートの下段：右側 右側には各工程のレビュー名を記載します。おそらく一般なウォーターフォール開発では、基本設計、機能設計、詳細設計、単体テスト…など細かなフェーズに分かれると思います。それらのフェーズをあらかじめすべて記入しておきます。（図3では工程を簡略化しています） 変更要求仕様書を 作成しながら記入する 変更要求仕様書を作成している最中はいろんなことを気にしているはずです。多くは仕様化することで解消されるでしょうが、それでも変更要求仕様書作成段階では払拭できない心配点は少なからず残るはずです。そうした心配点を漏れなく記入しておきます。 変更要求仕様書レビュー時に レビューする 変更要求仕様書のレビューのたびに、レビューメンバー全員で、心配点が顕在化するかどうかを考えます。特に思いつかなければ「対処の必要なし」と記載して済ませます。何か気づきがあれば、「その心配を取り除くためにどんな対処をしたか（するか）」を記入します（図3の赤字の部分）。検討している最中に新たな心配点が浮かんだら追記して、さらに検討を行います。

変更要求仕様書と心配点シートを導入することで次のような効果が得られました。

• 時間をかけて全員でレビューすることで、いままでよりも詳細な仕様化ができ、仕様化漏れがなくなった。
• 理由を記載することで、要求の真の目的を理解でき正確な仕様化ができるようになった。
• ユニークなIDを成果物に記入するようにしたので、どの開発でどのような変更が発生したのかを追跡することができるようになった。
• TMによって、変更に対する各モジュールへの影響が横断的にわかるようになり、レビュー段階で変更箇所の漏れに気づくことができるようになった。
• 変更が一覧化されて1つの表に集約されているため、影響範囲がひとめでわかり、変更量と複雑さがイメージでつかめるようになった。
• メンバー全員がレビューに参加することによって、自分の担当モジュールだけでなく、他のメンバーの担当モジュールへの影響も意識するようになった。
• 心配点シートで些細な心配でも吸い上げるので、メンバー全員が「プロジェクト全体」に対して、責任感と参加意識が強くなった。さらに、バグの発生は、メンバー全員の敗北という意識が芽生えた
• 成果物レビュー時に心配点シートのレビューを行うことで、緊張の時間と弛緩の時間を作り出し、レビューにメリハリが出るようになった。
• ベテランになればなるほど、経験に裏付けられた心配点が記入される傾向があり、なぜそのような心配点が出るのかが若手に伝わるチャンスとなった。

変更要求仕様書と心配点シートを導入することで、課題としていた4つは解消されました。大げさな話ではなく、本当に変更仕様に関する問題は発生しなくなりました。
少なくとも、ソフトウェアという不可視なものを扱う場合、「そこに変更のすべてがあり、常に最新の状態に保たれていて、その変更をメンバー全員が知っている」という安心感は、品質の向上にも役に立つものと思います。

導入と進め方のポイントを経験をふまえて記載します。

a. 必要性と表記方法のスタディ

変更要求仕様書と心配点シートを完成させるには、メンバー全員の協力が必要となります。そのためには、なぜ変更要求仕様書と心配点シートが必要なのか、どのようなルールで記入するのかを理解しておかなければなりません。事前に集まって勉強会を開きましょう。

b. 記入ルールの明確化

変更要求仕様書の要求事項、理由、仕様はプロジェクトリーダーが記入、TMは各モジュール担当が記入、心配点シートは全員が記入する事としました。なぜなら、USDMは、「何を変更するのか」の観点で記載するため、細かな実装を知らなくても書けるからです。これが書けないようではお客様との仕様調整は難しいということになります。TMは実装を知っているモジュール担当者が記入します。TMを記入する際には、必ず仕様を参照するので、自然とクロスレビューになります。

c. お客様をまきこむ

いきなりお客様に「変更要求仕様書を導入します」と言っても、なかなかOKが出ないかもしれません。私たちは、導入当初はお客様と実施するデザインレビューの際に改造仕様書のサブ資料のようなかたちで提出していました。開発のたびにだんだん露出度を上げていき、最終的には、改造仕様書を作成する前段階の仕様書として認知されるようになり、お客様もまじえてレビューを行うことができるようになりました。

d. 事前配布・事前レビュー

変更要求仕様書と心配点シートは事前配布・事前レビューを徹底します。配布時にレビュー記録表を添付して、レビューアはレビュー結果と追加の心配点を記入して、集合レビューの前に作成者に戻します。
これには2つの効果があります。１つは、仕様書がレビューに値する完成度になっているかの確認です。あまりにも要求を取り違えているとレビューに時間がかかるばかりで先に進みません。逆に、「て・に・を・は」などの些細な間違いは、レビュー時に気になって指摘し始めると、意外と時間がかかってしまうものです。そのような些細なものは、集合前の段階で指摘してレビュー前に取り去ってしまいます。
2つめは、事前に目を通すことで、無意識下に働きかける効果です。技術者は意外と仕事の時間以外でも、なにがしか担当モジュールについて考えているものです。変更仕様を脳内で熟成する時間を確保することで、心配点シートに載るような、ひらめきや気づきに期待します。

e. 仕様変更の度に全員レビュー

要件の追加や変更が入った場合や仕様変更が発生した場合には、必ず変更要求仕様書を改版して、常に最新の状態をキープします。仕様が変更になれば、影響範囲や心配点も変わるはずなので、どの工程であったとしても、再度全員でレビューを行います。時間はかかりますが、より安全で確実な変更を行うための投資と考えます。

f. 各工程の成果物のレビュー毎にその機能が取り込まれているか照らし合わせる

変更要求仕様書と心配点シートは、次工程のインプットであるとともに、実際は、すべての工程のインプット文書となります。変更要求仕様書に書かれた変更点は、改造仕様書にも反映されますし、テストも行われるはずです。ですので、各工程の成果物をレビューするときには、変更仕様が確実に反映されているか、他に心配点はないかを確認します。

g. 以前の変更要求仕様書と心配点シートを参照する

新たな変更要求仕様書を作成するときは、今まで作成した変更要求仕様書を見直して、類似の変更をしたことがないか、顕在化しなかった心配点が今回は顕在化する可能性はないかを考えながら作成します。変更要求仕様書はメンバーの叡智の固まりなので、何らかの気づきにつながるはずです。

h. 理由や粒度にこだわり過ぎない

変更要求仕様書導入当初は、要求の理由を書くのが難しく感じるはずです。要件書に理由が書かれていることは少ないですし、今まで要求に対する理由を考えたことがあまりないからです。仕様の粒度にも悩むと思います。細かくすると膨大な数になる可能性もありますし、荒くすると要求事項と同じになる気がします。でも、大丈夫です。要求事項によって荒い粒度になったり細かい粒度になったりするのは、複雑さや難易度などが自然と反映されているからです。レビューしてくれる人を信じて、理由や粒度にはあまりこだわらずに記載します。

i. レビューは緊張と弛緩を交互に

成果物のレビューは常に緊張感が伴います。そうした緊張感の合間に、頭をほぐす意味も含めて心配点シートのレビューを行います。変更要求仕様書の記載で想定される問題の検出はされているはずなので、心配点シートでは問題が発見されなくて当たりと思って、やや発散系になってもよしとしてやるのが良いと思います。リラックスした場の方が気づきが生まれる可能性が高まります。

変更要求仕様書と心配点シートを使った開発のイメージを図にしてみました。（図5）

（図 5 変更要求仕様書と心配点シートを中心とした開発のイメージ）

変更要求仕様書は、プロジェクトの羅針盤のようなものだと考えています。
ウォーターフォール開発のサイクルでは、それぞれの工程の成果物は、前工程の成果を受け継ぎながら進んでいきます。進むにあたって、変更要求仕様書という羅針盤を常に確認し、「その成果物には変更が反映されているのか」を必ずチェックし、心配点シートで「心配していたことが顕在化していないか、さらに心配すべきことはないか」を検討しつづけます。
航海に例えるなら、今までの航路とこれから進もうとする航路が正しいのかを羅針盤で確認し、行く手に危険が待ち受けていないかを推測する作業を怠らないということです。
変更要求仕様書と心配点シートを中心に据えて開発サイクルを回すことで、いつ難破してもおかしくない派生開発という困難を、正しいゴールに向かって安全にかつ穏やかに進めることができます。
プロジェクト管理システムやツールはたくさんありますが、品質を確保する最後の砦は、コミュニケーション、チームワーク、経験、助け合いなど、「人」が主役だと思います。

変更要求仕様書と心配点シートを導入してからの約3年の間に14ファイルができました。つまり、14回の派生開発を繰り返したことになります。
変更が入るたびに何度も書き直され、全員でレビューしたファイルは知識が凝縮されたプロジェクトの宝でありチームの誇りです。

プロダクトライン開発とは、ひとことでいうと、共通部と可変部をわけて開発することにほかなりません。しかも世代ごとに、可変部の内部で共通部を見つけて分離し、共通部分を増やしてゆくことが重要です。

もちろん、プロダクトライン開発に変えてゆく間も、既存製品群のリリースは続けなければなりません。既存製品群をリリースしながら、段階的にプロダクトライン開発に移行してゆくイメージは図１のようになります。

図 1：世代ごとに可変部の内部で共通部を見つけて分離する

図1では現在のソースコードを灰色、共通部を水色、可変部をピンク色で表現しています。開発を継続している製品が4機種あったとすると、一度にプロダクトライン化することは難しく、まず１つの機種を選択して、それを共通部と可変部に分けます。それを第１世代とします。

第２世代では、共通部を増やすとともに、同じ共通部を使って２機種を開発します。２機種の共通部は同じソースコードなので、ここからソースコード削減効果が生まれます。

さらに第３世代では、共通部をさらに増やすとともに、その共通部を使って４機種すべてを開発します。４機種の共通部は同じソースコードなので、さらにソースコード削減効果が生まれます。

このように、第１世代で、共通部と可変部を分けている段階では、まだソースコード削減効果が出ません。効果が出るのは同じ共通部から複数の機種を作り出せるようになった第２世代以降です。

製品群を生み出すのに必要なソースコードの量が少なくなれば、それだけで品質向上がねらえます。

プロダクトライン開発では可変性分析をおこない、何かに依存している部分を局所化して設計を改善していきます。たとえば製品ごとに異なるOSを使った、複数の製品からなる製品群を作っているようなところでは、OSに依存している部分を局所化する設計に改めます。図１にOSに依存している部分を局所化したクラス構造を示します。

図 2：OS依存を局所化する

図２では、OSユーザークラスは、OSインターフェースクラスを使っています。OSインターフェースクラスを実装しているのが、Linux実装クラス、ITRON実装クラス、Windows実装クラスです。

Linux実装クラスだけが linux.h をインクルードしていて、ITRON実装クラスだけがitron.h をインクルードしていることに注目してください。このようにすることで、OSインターフェースクラスを使った OSユーザークラスはどのOSにも依存しないで実装できます。

OS間の違いによる動作の違いを局所化することで、それ以外への影響を少なくできます。これによってOS非依存部分の品質を高めることができます。

OSユーザークラスとOSインターフェースクラスの部分が全ての製品での共通部となります。

このように何かに依存している部分を派生した実装クラスに局所化し、その抽象インターフェースを使ってユーザープログラムを実装することで、ユーザークラスの品質を高く維持することができます。

プロダクトライン開発では品質が向上するチャンスが２回あります。（図３参照）

図 3：繰り返し検証による品質の向上

１つめは、フレームワークを作ってリリースするときです。フレームワークチームはリリースするときに仮仕様のアプリケーションと組み合わせてきちんとフレームワークが動作するかを設計者がテストします。

２つめは、フレームワークとアプリケーションを組み合わせて製品開発をするときです。アプリケーションチームはフレームワークを使って製品全体の動きを設計者がテストします。

不具合も局所化される可能性があります。共通部分が他の機種でも使われていて他の機種では不具合が発生していないならば、共通部分よりもその機種用の可変部に不具合がある可能性が高いと言えるでしょう。

コード行数が数百万行におよび巨大なプロジェクトの場合、プロダクトライン化を一度に進めることはできません。そのドメインにとって資産となる一番大切な部分から、順番に共通部と可変部に分ける取り組みを始め、世代ごとに少しずつその範囲を広げてゆきます。

取り組んでいるパッケージの範囲から、品質が向上していく様子をメトリックスに取り、改善を見える化をしてゆきます。第１世代では不具合が局所化されるだけかもしれませんが、共通部が複数の機種に使われる第２世代から繰り返し検証による品質の向上が見込めます。

機種ごとに担当者が違っているものを、できるだけ同じ担当者で出せるように変えていくのが、プロダクトライン開発です。（図４参照）

図 4：各機種と各機能が、どの担当者とどのソースからできているのか

機種と機能の関係を図で表したものです。第１世代の機種が４機種あって、第２世代の機種が２機種あります。それぞれにいろいろな機能がはいっています。

プロダクトラインがうまくいっている状態とは、図４の上部のように、どの機種も同じ担当者が作っている状態です。このようになっている部分を世代を重ねるごとに増やしていくのがよい戦略です。

図４では、担当者で分けてみましたが、実際は同じ担当者でも別のソースコードを書いているかもしれないので、正確にはソースコードで分けて考える必要があります。まずこのようなマトリックスを作って、現状の機種と機能がどの担当者のどのソースから作られているのかをまず把握します。

ひとりの担当者が多くの機種を受けもつことで、ソースコードの再利用を意識した作りに変えることができ、コードクローンを少なくし、その機能用のソースコードの品質を向上させる効果があります。

共通部と可変部に分けて開発するのがプロダクトライン開発ですが、これは必ずしも組織を２つに分けることではありません。組織作りにはいろいろな方法があると思いますが、図５のように担当者を決めて機能を担当させる方法がお薦めです。

図 5：機能を担当する体制づくり

図５は機能ごとに担当者を割り振る方法です。ある特定の機能Ａに注目すると、その機能の開発に責任をもっているリーダーＡは、その機能の共通部と可変部の両方を担当しています。第２世代では、自分で作った共通部を使って、２つの機種の可変部を開発し、それぞれ組み合わせて製品をリリースします。

リーダーは共通部を作ると共に可変部を作り、さらに同じ共通部を使って複数の派生機種を開発することをミッションとします。自分で実装しやすくすると同時に他人にも使ってもらいやすいインターフェースを作るわけです。このようにリーダーは作る側と使う側の両方を担当するということとなります。

さらに派生機種を増やしていく段階で、次世代リーダーＢさんを育成します。そのときはまず可変部を作ってもらいながらプロダクトラインの基本を伝授します。

マスターした次世代リーダーＢは、やがて機能ＢのリーダーＢとなります。

モデル駆動開発を活用することで、プロダクトライン開発を加速することができます。製品をモデル駆動開発する場合、テストもモデル駆動開発します。設計したものは開発者が自分でテストします。図６をご覧ください。

図 6：製品とテストの両方をモデル駆動開発する

設計者は、製品用のモデル図面と、テストスイート用のモデル図面を同時に設計します。クラス図上に、製品用のクラスと、テスト用のクラスを描きます。状態マシン図なら、製品用の状態マシンを表した図のほかに、その状態マシンをテストするためのテストクラス側の状態マシンの図も描きます。

それらの図からそれぞれコード生成させ、PC上でテストします。

うまく動くかどうか確認しうまく動いたら、今度は両方のモデルから、それぞれ実機用のソースコードを生成させ、ターゲット上でテストをします。

製品コードをリファクタリングした後も、それにあわせてテスト用コードもリファクタリングしてテストが通る状態を維持します。これにより品質が落ちていくのを防ぎます。テスト周期、リリース周期は１日以内とし、常に２つを同時にリリースします。

このとき（テストコード行数／ソースコード行数）のメトリックスをモジュールごとに計測して見える化することをお薦めします。

さらに、いったん作り上げたプロダクトラインプラットフォームが崩れないように監視していくプロセスも取り入れます。依存性構造マトリックスを作成し、認められない循環参照、逆向き参照、飛び越し参照などを追加してプラットフォームが崩れ出さないかも監視します。自動化し深夜プロセスに組み込みます。

このように、プロダクトライン開発では、製品群開発を効率的に進められるように、世代を重ねてよい設計に変え、よいプロセスに変えつづけていくことが大切です。それにより、これまで述べたようにソフトウェア品質を高めることができます。

製品ファミリに搭載されるソフトウェアの開発は、過去に開発したものをベースに新製品を開発する、すなわち派生開発が通常です。特に製品の種類が多く、同時期に多くの異なった製品をリリースするような製品ファミリでは、各製品の開発が並行して実施されることも少なくありません。これを、ソフトウェアの構成管理の視点で表現すると、下図のようになります。

図 1：従来の派生開発における構成管理

この場合、次のような問題が起こります。

• 複数の製品に同じ機能を追加する場合、各バージョンに対して作業が必要
• ある製品で障害が発生した場合、そのベースになっている全製品に対して修正が必要

つまり、複数のバージョンに対して同一の作業をしなければならなくなり、「ムダ」が発生します。特に、バージョンが上がるにつれてソフトウェアの構造（アーキテクチャ）が無秩序に変わっているほど、ムダは大きくなります。派生の数が増えるにつれてメンテナンス対象も増加し、対応漏れ等による品質低下のリスクも増大します。 このような問題を回避するために、ソフトウェアの再利用を前提とした製品開発を実施しているケースも多くあります。これは、製品間で共通となる資産をソフトウェア部品として開発し、再利用するというものです。その考え方自体は良いのですが、実情は下図のようになっています。

図 2：従来の再利用開発における構成管理

つまり、ソフトウェアは部品として資産化されているものの、バージョン間での互換性はなく、ある製品を構築する際には特定のバージョンが必要になります。この場合も、基本的に先の例と同様の問題が発生します（単に派生の数が少ないだけと言えます）。

前述の問題を解決するための方法として、ソフトウェア・プロダクトライン（Software Product Line : SPL）があります。SPLでは、製品ファミリに属する各製品で再利用される資産を開発するドメイン・エンジニアリング（domain engineering）と、開発された資産を利用して個々の製品を開発するアプリケーション・エンジニアリング（application engineering）という、2層型の開発を行います。ドメイン・エンジニアリングで開発される資産は、コア資産（core asset）と呼ばれます。また、アプリケーション・エンジニアリング実施時に発生したコア資産の改善要求は、ドメイン・エンジニアリングへフィードバックされ、これを受けてコア資産の更新が行われます。

図 3：SPL開発の概観

SPLの基本的な枠組みは上記のとおりですが、この時点で従来型の再利用と同じではないか、単に専門用語を並べただけと感じる方も多いでしょう。実際、従来型の再利用と全く異なるわけではなく、多くの点で似通った部分があります。それに加えてSPLでは、従来型の再利用では解決できなかった問題を解決するために、様々な要素が加えられています。 本稿では、SPLの象徴とも言える2つの要素「スコーピング」と「可変性管理」を中心に、SPLが従来の派生開発／再利用開発とどう違うのか、そして前述の問題をどのように解決するのかについて説明します。

製品ファミリの開発は、追加／変更／修正の連続です。その寿命を終えて開発終了となるまで、延々と続いていきます。このような状況の中で、開発した資産を長期に渡って再利用できるようにするには、「将来の変化を予測して、その変化に対応しやすいように設計する」必要があります。この変化にどこまで対応するかの範囲を決めることをスコーピング（scoping）と言い、その範囲をスコープ（scope）と言います。
SPLの適用において、スコープを適切に定めることは重要です。一般的に、スコープが狭いと、その資産を利用して開発できる製品数が少なくなり、再利用機会が減ってしまいます。一方、製品数が少ないということは製品間の違いも多くないため、より製品に適した使いやすい資産が揃えられます。逆にスコープが広いと、製品ファミリに含まれる製品が増えるため、同一資産の再利用機会は増えます。しかし、製品間の差異も多様になり、資産が抽象的なものになってくるため、再利用が難しくなる傾向があります。コア資産の再利用による効果、すなわち製品ファミリの開発がどれだけ最適化できるかは、このコア資産の再利用のしやすさと機会によって決まってきます。よって、このバランスが最適となるようにスコープを定義することが、SPL開発の成否を大きく左右します。

図 4：コア資産の再利用の効果

スコープに含まれる製品の間には、共通なものと異なるものがあります。下図を見て下さい。ここで、3つの円がそれぞれ製品A／B／Cの資産だとします。この時、全ての製品で共通となる部分を共通部（common part）、それ以外を可変部（variable part）と呼びます。可変部の内、特定の製品でしか使わない資産は、製品固有部（product-specific part）と呼ぶこともあります。SPL開発では、この共通部と可変部を管理することで、製品ファミリの開発の最適化を図ります。これを、可変性管理（variability management）、または共通性・可変性管理（commonality-variability management）と言います。

図 5：共通部と可変部

可変部には「なぜその違いが発生するのか」の理由があります。これを可変性（variability）と呼びます。裏を返せば、製品ファミリに可変性があるということは、その違いを生み出すことができることを示しています。そして、可変性には変化の種類が存在します。代表的なものはオプション（optional）と代替（alternative）です。前者は製品に搭載する／しないを選択できるもので、後者は幾つかの選択肢の1つを選ぶものです。簡単な例として、ディジタル腕時計ファミリを考えます。このファミリには、以下の4つの製品が含まれるものとします。

• 12時間表示ディジタル腕時計
• 24時間表示ディジタル腕時計
• アラーム機能付き12時間表示ディジタル腕時計
• アラーム機能付き24時間表示ディジタル腕時計

この時、このディジタル腕時計ファミリには、時間表示機能（12時間と24時間の代替）とアラーム機能（オプション）の2つの可変性が存在します。このようにして特定された可変性を管理していく際には可変性モデルを利用するのが一般的です。可変性モデルの内、最もよく知られているものはフィーチャモデル（feature model）でしょう。これは、製品ファミリを特徴づける要素（フィーチャ）をツリー上に表現したものです。ディジタル腕時計ファミリの例では、以下のようにモデル化できます。

図 6：ディジタル腕時計ファミリのフィーチャモデル

したがって、各製品を効率良く開発するためには、コア資産は以下の要件を満たす必要があります。

• 時間表示機能を（製品に載せる前に）12時間／24時間に切り替えられること
• アラーム機能の搭載／非搭載が切り替えられること

可変性を分析・管理することによって、開発すべきソフトウェアにどのような柔軟性が求められるのか、それを実現するためにどんな技術を利用するべきかが明確になります。これは、「保守性」という品質特性に関して、その要件を明確にすることと捉えることができます。

製品を開発する場合、可変性モデルに記述されている可変性をどのように扱うかを決定します。前述のディジタル腕時計の例だと、アラーム機能 を搭載するのか／しないのか、時間表示は12時間／24時間のどちらにするのかを決定します。この決定内容に従って、コア資産の可変点 （variation point）をコンフィグレーションしていきます。可変点とは、コア資産中の可変性を実現している場所のことです。例えば、アーキテクチャ上でアラーム機 能を実現するコンポーネントが定義されていて、この搭載／非搭載が切り替わるとしたら、このコンポーネント自体が可変点になります。このようにして、コア 資産が現在開発中の製品に適した形に変換されます。この一連の過程を導出（derivation）と言います。

図 7：可変性の決定による製品の導出

コア資産から製品用の資産が導出されるということは、コア資産には共通部だけでなく、可変部も含まれるということがわかります。製品固有部でない可変部は幾つかの製品間で共有されるため、コア資産に含めることができます。 もちろん、新製品開発時にはコア資産に含まれない新機能や、製品固有部の開発なども含まれます。前者は通常ドメイン・エンジニアリングで、後者はアプリケーション・エンジニアリングで開発を行います。

ここで、本稿の冒頭で述べた保守の問題について振り返ってみます。SPL開発では、この問題を本当に解決できるのでしょうか。答えはYESです。 SPLにおけるコア資産は、共通部だけでなく可変部も含みます。そして、管理されている可変性に対して、各開発成果物（要求仕様、内部設計、コード、テスト仕様、etc.）が正しく製品を導出できるように開発されます。このため、コア資産の最新バージョンは、その時点でスコープに含まれている製品を全てカバーできる状態になっているのです。従来の開発と比較してこれを図示すると、以下のようになります。つまり、コア資産のバージョンが上がっても互換性が維持されるように、開発を行っているのです。この結果、コア資産の最新バージョンを保守するだけで、全ての製品の保守を行うことができます。

図 8：SPL開発と従来型の開発の比較

従来型の開発とSPLを比べてみるとわかるとおり、従来型では各バージョンが「特定の製品」に対応しているのに対し、SPLでは「製品群」に対応しています。言い換えると、前者は個別最適な開発を、後者は全体最適な開発を行っていると言えるでしょう。この、「全体最適の視点で製品群全体を開発していく」という姿勢こそが、SPLの根幹を成す考え方なのです。

SPLは単純な開発技術ではなく、ビジネス戦略や開発プロセス・組織構成の最適化等も含んだ包括的なパラダイムであるため、非常に大きな工学体系になっています。このため、そのポイントを上手く掴んで、実開発に役立てることが重要です。本稿では、SPLというパラダイムの一部を、スコーピングと可変性管理を中心に要点だけを説明してきましたが、多くの方の改善の一助となれば幸いです。

品質の最も古典的な定義はクロスビー（P. Crosby）の定義として有名な「要求に対する適合」であろう。これは要求が常に正しいという前提に成り立っているが、ソフトウェア要求を正確に定義するのは難しいことは今でも解決されておらず、問題の残る定義である。しかし、これは長い間ソフトウェアの世界でも中心的な考え方として最近まで良く使われた定義である。
現在、ソフトウェア品質の定義はユーザ視点に立つべきというのが一般的であり、ユーザにとっての「価値」や「満足度」と言われることが多い。そこで、ソフトウェアを意識したソフトウェア品質定義の変遷をみてみる。

（１）	品質は誰かにとっての価値である。 これはワインバーグ（G.M.Weinberg）の定義である。 ここで「誰か」とは、実際にソフトウェアを使うユーザや管理者であったり、ソフトウェアを開発する開発者自身であったりする。 ワインバーグは自身の著書「ワインバーグのシステム思考法」の中で、ソフトウェア工学の専門家として、クロスビーの定義の要求の正確さに依存しない、ソフトウェア品質の定義を一般化しなければならないと述べている。 ソフトウェアの要求の曖昧さに悩まされながらソフトウェアの開発に携わってきた者にとって納得の出来る定義であろう。
（２）	品質は、ユーザにとっての満足度（ＣＳ）である。 これは近代的品質管理における品質の定義として、一般に受け入れられている考え方である。 「満足度（ＣＳ：Customer Satisfaction）」は日本の品質管理の成功に刺激されて米国が作ったマルコム．ボルドリッチ国家品質賞のスローガン「顧客満足度（ＣＳ）」が逆輸入されたもので,日本企業の経営指針として多く採用されている。 顧客満足度について、英国ソフトウェア企業ＰＲＡＸＩＳ社のマーチン．トーマスは「ＣＳは我々のゴールである。しかし、カスタマー（顧客）の視点は毎月でも変わりうる。」と述べ、顧客満足度というのはやさしいが、日々変化する「各々の顧客の満足とは何か」を知りフォローするのは容易なことではないし、これを実現し続けるのは至難の技であると解説している。
（３）	システムが本稼働するとき、どこまで真のビジネス（ユーザ）ニーズに合っているかということ これはジェームス．マーチン（Martin.J.）の定義であり、自身の著書「ラピッド．アプリケーション.ディペロップメント」の中で述べている。 開発期間が長くなると計画時点でユーザニーズを正確に把握していたとしても、完成時にはニーズ自体が変化しているということが往々にして発生すという現実に対応したものである。 結局、最終的にユーザが使用する時点で、そのニーズをどれだけ満足しているかが、良い品質かどうかの鍵である。ただし、前にも述べたとおり、ユーザとは誰であるかが課題である。

ソフトウェアの開発は図―１に示した様に①ユーザの要求が有り、②これをソフトウェアの仕様に落とし、③そのソフトウェア仕様に従ってコードを書く、という手順で行われる。
ソフトウェア品質を捉える際は、ソフトウェア品質を、狭義の品質と広義の品質の両面から考える必要がある。狭義には①ユーザの要求がソフトウェア仕様に正しく反映されているかという品質、すなわち「要求と仕様の適合度」があり、さらに②ソフトウェア仕様の定義に従ったコードが生成されているかという品質、すなわち「仕様とコードの適合度」の品質がある。これらは一般に①を設計品質、②をプログラム品質と呼ぶことが多い。
広義の品質とは最終成果物（プログラム）がユーザの使用する時点で要求をどれだけ満たしているか、という品質すなわち「ユーザ要求への適合度」である。これは前述したジェームス．マーチンの品質定義に通じるところがある。
ソフトウェア品質を大きく一つとして捉えるのではなく、上述のように分けて考えることで品質改善やＳＰＩなどの改善活動に活かしやすくなる。

ソフトウェアに要求される重要なことがら（使命など）を整理してみると品質を議論する際の要点が浮き上がってくる。 ソフトウェア品質はあらゆる角度からもれなくソフトウェアを観察することでその要素が見つけられる。それをSQuBOKから引用してみる。

• 「時間」についての概念
• 「コスト」の概念
• 「必要な機能」が実現されていること
• 「使いやすい」こと
• 「想定した時間内」に機能を実行できること
• 「実行時に故障しない」こと
• 「導入や学習」が容易
• 「導入後の維持／拡張」が容易なこと

（１）	Roger S Pressman ；ソフトウェアの品質特性を測定することは可能 機能および性能に関する明示的な要求事項、明文化された開発標準および職業的に開発が行われた 全てのソフトウェアに期待される暗黙の特性に対する適合 適合品質（quality of conformance） ：当該品目の設計仕様に対する準拠度合い 』 Pressmanの定義は比較的新しいものであり、筆者は他の定義に比べてかなり実用的であると考えている。SQuBOKが詳しく解説しているのでその一部を引用する。 『Pressmanの定義は、他の品質に関する議論を踏まえたうえで、全体的に共通する以下の二つの観点から品質を論じているといえよう。 設計品質（quality of design） ：設計者が当該品目に対して指定する特性 適合品質（quality of conformance） ：当該品目の設計仕様に対する準拠度合い 』
（２）	Joseph　M．Juran　；二つの視点 プロダクトの特性（Feature）が顧客のニーズに応えることで満足を提供する 不備：deficiencies（障害や誤り）から免れる
（３）	Robert L Glass　；品質は製品によって変わり全てに共通の品質定義はない 各製品が備えるべき一式の品質特性のことであり、プロジェクトの種類に応じて異なった優先度が付くべきもの
（４）	ＩＳＯ，ＩＥＣなど国際規格の定義　；品質に関する規格は数多く存在するが、ここでは皆さんがよく目にする二つの規格を取り上げた。 ISO９０００の定義 本来備わっている特性の集まりが要求事項を満たす程度（要求事項とは明示的事項、暗黙的事項、義務として要求されているニーズのこと） ISO/IEC２５０００ 指定された特定の条件で利用する場合の、明示的または暗示的なニーズを満たすソフトウェア製品の能力

以上、ソフトウェア品質の定義について私の経験とSQuBOKからの引用で述べてみた。品質はステークホルダや切り口、さらには時代や対象によって多様であることをご理解頂ければ幸甚である。
品質は定義したら測定しなければ意味が無い。そのためには先ず品質モデル（一般的には階層構造のモデル）を理解し、目的にあったメトリックスを定義し、それを測定しなければならない。測定結果は品質改善に活用（寄与）されてこそ品質定義の意味が生きてくると考える。

前号で清水吉男氏よりXDDPの理論が紹介されました。今月号では、(株)デンソーにおけるXDDPの導入事例を紹介します。
XDDPの導入を開始して、今年で４年目となります。効果検証の試行プロジェクトから始まり、希望者へのコンサルティング、そして、リーダー育成と一つのコンセプトに従って展開をしてきました。４年という時間はかかっていますが、正しく導入したプロジェクトでは、品質、生産性について確実に成果が出ています。そして、何より大きな変化は、何人かの技術者については、開発への取り組みが確実に“前向きになった”という現実です。
開発で多忙の中、社外発表や論文作成に技術者が自発的に取り組み始めました。今年は、XDDP関連だけで社外発表は3件、論文作成は2件を予定しています。また、コンサルティイングに使用する成果物の内容や送られてくるメールの送信時間を見ると、自発的に努力を始めた技術者の姿を容易に想像できます。

まだ、“変化の兆し”というレベルですが、こうした技術者が組織に16％ 出て来れば（後述）、現場は甦り、技術者が本来の仕事を取り戻せると考えています。タイトルは、敢えて“こうして現場は甦る”としました。彼らへの信頼と確信とを込めて、これまでの取り組みを紹介したいと思います。

開発現場での新規開発と派生開発の割合を調べてみると、ほとんどが派生開発であることがわかります。しかし、実際のすべての枠組み（仕組み、プロセス、成果物 等）は、新規開発向けに作られたものです。確かに、清水吉男氏の本を除いて、ソフトウェアエンジニアリングの書籍は、すべて新規開発を対象に書かれています。CMMIのレベル3で必要となる標準プロセスを考えてみても、派生開発用の標準プロセスが存在している組織は少ないのではないでしょうか？
現実的に考えれば、新規開発よりも派生開発を中心に考えていく必要があります。新規開発と派生開発では、要求や制約条件が全く異なりますので、派生開発に新規開発のプロセスを適用するには無理があります。
新規開発では、要求仕様書や各設計書を完成させて開発を進めます。しかし、派生開発で必要なのは差分情報です。新規開発のプロセスを使って、この差分情報を要求仕様書や各設計書に埋め込み、各ドキュメントを完成させながら派生開発を行えば、時間が足りなくなってしまいます。その結果、途中のプロセスを飛ばして、ソースコードの変更に取りかかるようなことが起こるのです。

これまでは、新規開発用のプロセスが中心だったかもしれません。しかし、派生開発向けの開発プロセスであるXDDPが提案された以上、XDDPをベースに派生開発のあり方をもう一度議論すべき時に来ています。

我々は、XDDPの導入を決め、試行プロジェクトにおいて、ある程度の手応えを得ました。実際に現場に導入してみて、XDDPについて感じたのは以下の３点です。

（１）	プロセスが極めて合理的である XDDPは、派生開発を、変更と追加というタイプの異なる2つのプロセスに分け、それぞれの要求を実現する最適なプロセスと成果物を提供しています（図：XDDPによる派生開発）。特に、変更のプロセスでは、変更仕様とその影響範囲の抽出を表記法を工夫したり、レビューをうまく活用することで、設計者の思い込みや勘違いを最小限に抑えます。XDDPは、要求を実現するという観点から、必要なプロセスを層別し、整理した極めて合理的なプロセスと言っていいと思います。
（２）	これまでの現場の問題に的確に対応している 多くの組織では、テストでのバグや後戻りが頻発しています。XDDPは、これらの問題の根本原因を解消するプロセスと成果物で構成されています。それはXDDPを導入したプロジェクトの品質と生産性から判断できます。我々の試行プロジェクトでは、従来の開発と比べて、テスト工程での不具合発生率65％減、生産性1.3倍という結果を得ました（図：XDDP導入による効果）。
（３）	トヨタ生産方式の考え方にマッチしている トヨタ系のメーカーとして感じるのは、大野耐一氏が考案したトヨタ生産方式（以降、TPS：Toyota Production System）の考え方によくマッチしているということです。これは、いくつかのプロジェクトで実際に取り組んでみて気づきました。TPSは、ムダの徹底排除とプロセスの合理性を追求した生産方式ですが、その点では、XDDPも同じ思想で作り上げられた開発プロセスと言えます。 また、TPSでは、常にプロセスを変化させること（継続的改善）が求められます。“時代の変化を見据え、お客様の要求にあわせてプロセスを変えていく”、この発想により、TPSは製造現場を“強靱な生産システム”へと変貌させます。 これは、XDDPでも同様です。派生開発では、毎回、要求や納期、担当者が変わるので、前回のプロセスをそのまま使うわけにはいきません。さらに、派生開発では開発期間が短いので、要求を実現する的確なプロセスが必要です。XDDPでは、PFD（Process Flow Diagram）を使ってプロセスを設計し、こうした変化に対応します。

XDDPについては、その技術もプロセスも理解しました。また、試行プロジェクトにより、現場への効果も確信できました。あとは、“開発現場の技術者にどう納得して取り組んでもらうか”が大きな課題でした。
その時、参考にしたのが、エレベット.M.ロジャーズの「イノベータ理論」です。イノベータ理論では、「普及率16%を超えた時点でイノベーションは急速に普及する」（普及率16％の論理）としています（図：普及率16%の論理）。そこで、XDDPを一つのイノベーションと捉え、ロジャーズの採用者分布曲線に従った展開を今回のプロセス改善のコンセプトとしました（図：ロジャーズの採用者分布曲線）。つまり、全体の底上げを狙うのではなく、イノベータから始め、アーリーアダプタを育て、そして、アーリーマジョリティへとXDDPを順次展開していく戦略をとったのです。
全体の底上げによる展開も考えましたが、推進側のリソースが限られているため、現場全体へは十分な対応はできません。しかし、普及率16％の論理に基づき、最初は、2.5％のイノベータを対象にし、次にアーリーアダプタに切り替えていけば、推進側のリソースが十分ではなくても、XDDPを使いこなせる技術者を育てることは可能です。そして、そうした技術者が先行して育てば、彼らと一緒に展開活動を推進していくことができるのです。現場の技術者を指導者に育て、彼らと共に現場に“教え合う文化”を醸成する。まさに、これは、少人数のスタッフで大組織のプロセス改善に立ち向かう我々にふさわしい方法でした。
そこで、まず、全体の16%の普及率を目指し、次のようなステップで進めました。

Step1：関心のある人から導入（イノベータ）
Step2：リーダーを育成（アーリーアダプタ）
Step3：草の根活動へ展開（マジョリティ）

改善戦略は立案できましたが、問題はこれをどう実践するかです。技術者に対して何をどう考え、具体的にどう行動していくのか、推進側が取り組む姿勢を変えなければ、現場の技術者は本気で取り組んでくれません。
これまでXDDPの現場展開を進めてきて感じるのは、技術的なハードルよりも、むしろ人の意識に問題があるということです。これまでのプロセス改善活動やCMMIやISOの取り組みで、技術者に改善への拒否反応やトラウマを植え付けてしまっている可能性があります。今回、XDDPの導入前に、現場の技術者にプロセス改善について聞いてみると、以下のような話が聞けました。

• CMMIのレベル2をクリアしたが現場はよくならない
• 決められたドキュメントは作るが何に使うかわからない
• どうせまた、しばらくしたら違う方法を進めるのだろう
• 推進側は現場のことを理解していない

これらは、今回のXDDPの展開についてのものではないですが、現場の技術者の推進側に対する不信感をよく表しています。CMMIやISO自身は決して悪くないのですが、推進側が現場への導入を誤り、正しく誘導できていない可能性がありました。こうなると、むしろ今回の取り組みは推進側への信頼を取り戻すことを前提に、我々推進側と技術者の考え方や習慣を変えることが成功への近道だと感じました。そして、“技術者の習慣を変え組織文化を変革する”をスローガンに、“個人の習慣”と“組織文化”に挑む活動を始めました。

XDDPの展開を進めるのに当たり、２つの方針を掲げました。

１．PCA ( Person Centered Approach ) による個別性、独自性の尊重
２．コミュニケーションを主体にした信頼関係の確立

プロセス改善の対象である個人の習慣や考え方を変えるためには、個別に対応していくしかありません。ソフトウェアの開発では、プロジェクト毎に要求や制約条件が異なります。また、技術者についても、性格、技術、キャリア等、当然違っています。こうした状況下で、現場に対して十把一絡げに施策を打っても、問題は決して解決しません。
PCA は、カール・ロジャーズが提唱した、一人ひとりの人間の個別性、独自性を尊重し、あらゆるコミュニティとの積極的な対人関係を深めようとする考え方です。XDDPの展開では、PCAに基づいて、開発状況や技術者の個性を尊重したコンサルティングと技術支援 を活動の中心にしました。
そして、そのアプローチの中で重視したのが、コミュニケーションによる現場技術者との信頼関係の確立です。“共感”はするが“同情”はしない。“理解しようとする”のではなく“受け入れる”。技術者が直面している状況を察し、伴走者の気持ちで支援を諦めずに続ける。これらは、我々が目指す目標と現場を分析した結果から、自ずと導かれる方針でした。

取り組みの中で、一番苦労したのは、Step1からStep2への移行です。Step1では、組織の中でXDDPに個別に取り組んでいる人や、興味のある人が対象でしたので大きな問題はありませんでした。しかし、Step2では、リーダー候補を選定し、XDDPを指導できる人材に育てる必要があります。
そのためには、XDDPを十分理解していないリーダー候補者に、XDDPに実際に取り組んでもらわなければいけません。XDDPに振り向いてもらわないといけないわけです。このような点から、このフェーズの活動は、“営業”と考えることができます。つまり、この活動は、XDDPという商品を顧客である技術者に買って頂く営業活動であるということです。
営業の技術は、営業活動で成果を上げている中堅企業や書籍から学び、そこで得たエッセンス（以下）を実際のXDDPの展開活動に活用してきました。

（１）	「訪問時間」よりも「訪問回数」 これまで、何度となく技術者の席まで行き、話をしてきました。その時に注意したのが、“話す時間”より“行く回数”を重視する「訪問時間より訪問回数」という発想です。1時間まとめて話をするよりも、15分を4回に分けて話をする方が効果的だということです。 技術者は、日々“忙しい”と感じていますので、長く時間を取られることを嫌います。そこで、何度も技術者の元に足を運びながら、彼らの話に耳を傾け、状況にあわせてXDDPの話を少しずつしていきます。席にいないときは、来たことを名刺に書いてキーボードの上に置いておきました。これも1回の訪問でした。 何度も席まで行って話をするうちに、少しずつ耳を傾けてくれるようになります。そうして、取りかかれる内容を一緒に考えながら、自ら一歩踏み出す瞬間を待ちます。かたくなな態度をとり続ける技術者もいましたが、そういう技術者は、“縁がなかった”と諦めました。
（２）	「言い訳」はチャンス いざ、取り組みの話題になると必ず出てくるのは、出来ない理由（言い訳）です。「取り組む時間がありません」「全部は無理です」「プロジェクトはまだ途中なので・・・」「取り組むテーマがありません」等、いろいろ聞いてきました。こうした人は、言い訳して、結局何も変えません。そして、皮肉なことに彼の言い訳は当たります。そこに気づかなければ、変わることはできないのです。ですから、出来ない理由に全く意味はありません。それに、この先、できる条件が完全に整うことなど決してないのです。 しかし、こうした言い訳の対応策が工夫できれば、彼らは取り組まない理由を失います。技術者によって異なりますが、一通り話を聞いて状況を共有できたら、“出来ない理由”を“出来る理由”にかえるアイデアを一緒に考えます。こうして外堀を辛抱強く埋めていきます。 ただ、言い訳も2種類あります。“前向きな”言い訳と“後ろ向きの”言い訳です。“前向きな”言い訳には、本当に何とかしたくても何ともできない技術者の気持ちが表れています。ここを感じ取り、共感し、受容する姿勢が推進側には必要であると感じています。
（３）	技術的な説明は妥協しない XDDPを十分理解していない状態では、XDDPの技術そのものに対する誤解が生じています。そこで、技術的な質問が出た時には、的確かつ丁寧に答える必要があります。「なぜ、うまくいくのか？」、「今までと、どこが違うのか？」「どんな技術が新たに必要か？」「習得にどのくらいかかるのか？」等、質問はさまざまですが、すべての質問に納得できるよう答えて、技術者の不安や疑問を解消してきたつもりです。この回答には、推進側とXDDPへの信頼がかかっていますので、誠意ある姿勢が求められました。 技術者は、「やりたくないから取り組まない」のではなく、「知らないから取り組まない」という場合がほとんどです。技術を理解してもらうまで粘り強く説明すると、能力の高い素直な技術者は興味を持ってくれました。まだ、頭の中のどこかに“なんとかしたい”“やってみたい”“うまくやりたい”という気持ちが残っていた証拠だと思います。 こうして、現場の技術者を徐々に“せざるを得ない状況”に追い込み、彼らの気持ちの変化を待ちました。そして、取り組むきっかけをつかんだ技術者は一歩踏み出してきますので、そのタイミングで技術支援を開始しました。気持ちが傾いたその瞬間、そのタイミングで彼らが必要としているものを必要なだけ提供したのです。 世間では、“Time is money（時は金なり）”といいますが、開発現場の改善では、“Timing is money（タイミングこそ金なり）”の発想が重要でした。このタイミングを把握でき、こうした機会を意図的に作り出せる人が、組織には専任者として必要だと思います。

「普及率16％の論理」では、16%を超えると組織全体に影響すると言われていますが、実は確信があったわけではありません。むしろ16%を目標に、あらゆる手段を考え実施してきたというのが本音のところです。おそらく、周りの誰も信じてはいなかったと思います。
しかし、確実に技術者たちは変わり始めました。「はじめに」では、“変化の兆し”として、論文や社外発表への取り組みを紹介しましたが、今では、次のような技術者も目にするようになりました。

• 身近な話題でテーマを作り、要求仕様書の書き方の“けいこ”を始めた中堅技術者
• 「私も課題を持って発表できるような仕事がしたい」と相談に来るリーダー
• “アーキテクチャ再構築”に自主的に取り組み、コンサルティングを希望する若手技術者
• “なんとかしたい”とオフショアでのXDDPの活用を相談に来る上司と部下
• XDDPの勉強会を自ら企画し、課内で部下と一緒に勉強を始めた管理職

まだ、このような技術者は全体の16％には至ってはいませんが、こうした光景を見ていると個人の習慣から組織文化が徐々に変化している手応えを感じます。組織の中でも、技術者の変化を話題に上げ、嬉しそうに話をする管理者もいます。「もしかすると16%を超えたら展開が加速して組織が変わるかもしれない・・・」展開前に想定したロジャーズの仮説が、今、現場への大きな期待へと変わり始めました。

現在の取り組みについては、紙面の都合でこれ以上説明はできませんが、現場では、今、Step2からStep3への活動を引き続き展開しています。これまでの経験から言えるのは、プロジェクトの状況や現場環境、技術者の個性を把握し、彼らの能動をいかに引き出すか、つまり、技術者1人1人の“自律”と“工夫”が活動の成否の鍵を握るとういうことです。
自分の意志で一歩踏み出した技術者たちは、XDDPの技術を着実に習得し、品質、生産性を改善することで自分の時間を確保します。そして、“次の時代への準備”を始めます。アーキテクチャの再構築や分析手法の習得、それに見積もりや進捗管理、スケジューリング等、やっとエンジニアリングや管理技術に取り組むことができるのです。
私がXDDPの技術支援を積極的に進める狙いは、まさにここにあります。それは、疲弊した開発の中でうつ病に倒れ、多くの人に助けて頂きながら執念で手に入れてきたXDDPへの確信であり、この技術こそがソフトウェア技術者を救い、再生する一歩だと信じるからです。
混乱を制した先には、誇りと笑顔を取り戻した技術者が、ソフトウェア開発を心から楽しみ、組織の“希望”となることを願ってやみません。ソフトウェア開発に希望を失った技術者も、本来の能力を発揮し、自分らしく胸を張って生きていける可能性がここにあります。時代の頂に何人の技術者を導くことができるか、XDDP によりプロセス改善に新たな展開が始まりました。

派生開発というのは、ある製品やシステム（のソースコード）をベースにして、新しい機能を追加したり、操作性などを改良して製品やシステムを作り上げて行く開発方法で、その過程で新しい製品やシステムの体系が生み出されることがあります。

派生開発のプロジェクトの特徴として、一人プロジェクトになるような小さな変更案件から数十人で対応するような大きな変更案件まであることです。開発期間が１ヶ月という短期間のものから１年以上のケースもあり、変更行数が５００行程度のものから１０万行に達するようなものまであります。
また、多くの場合、ソースコード上で該当すると思われる箇所を見つけ次第に変更しています。もともと変更要件の実現方法も複数あり、いずれの変更方法でもテストでは「正しい」と評価される可能性があります。でも担当者が気づくのは通常はその中の「１つ」です。しかも必ずしも適切な変更箇所が選ばれているとは限りません。

また、プロジェクト終了時の反省会では、相変わらず「全体を理解できていなかったから・・・」という声が出てきます。そしてそれで皆さんが納得しているのです。
でも

• 「全体」とはどの範囲ですか？
• 「理解」とはどの状態を言うのですか？

要するに「全体」を理解して作業ができる状況にないにもかかわらず、「全体」を理解すれば問題が解決すると考えているのです。そしてこの立場に立つ限り、全体を理解できない状況に備えることができません。それよりも最初から「部分理解」の制約の中で作業が強いられるということを前提にすることで、担当者の思い込みや勘違いに気づく方法を取り入れる工夫ができるのです。
また、派生開発では下表のように新しい機能の追加に伴って問題が発生しているケースが少なくありません。これも派生開発の特徴です。

もともとソフトウェアエンジニアリングの世界には、「保守」あるいは「保守開発」というプロセスがあります。（JIS X 0160：ソフトウェアライフサイクルプロセス）

「保守開発」で想定しているのは、主にバグなどの「是正保守」や稼働後の環境の変化に対応するための「適応保守」であり、そのようなケースでは今でも「保守」のプロセスで対応しても支障はないと思います。
ビジネス分野においては、このようなケースが多いと思われますが、それでも最近は、新しい機能の追加なども伴うことが多く、変更要件が複雑になっていると思われます。

これに対して、組み込みシステムの世界では「是正保守」よりも、機能追加や性能の改良などを行って新しい製品として市場に出すというケースが多く、そこには「保守開発」という概念はありません。たとえば「携帯電話」が今日の｢ケータイ｣端末に変化（進化）する過程は「保守」では説明がつきません。パッケージソフトや流通などの制御システムでも、ビジネスの競争に勝つという要求に応えるために頻繁に機能の追加が行われています。
こうした中で、2008年にJIS X 0160が改訂され「緊急保守」と「改良保守」が追加されました。「改良保守」は主に機能追加など新しい要求への対応を想定しています。ただし、「是正保守」と「改良保守」では求められている「要求」が根本的に異なるという、新しい問題が生じます。

「XDDP」は派生開発に特化した開発アプローチで、派生開発の特徴である「短納期」や「部分理解」の中での作業に対応しています。短納期の要求に対しては無駄のない合理的なプロセスで対応する必要があります。また「部分理解」に対してはいきなりソースコードを変更するのではなく、適切な成果物を生成して他の人のレビューを受ける機会を作ることが重要です。
「部分理解」に対応した開発アプローチによって手戻り作業が大幅に減り、結果として「短納期」を支援することにもなります。XDDPによって「Q」と「C」「D」を同時に手に入れることに繋がるのです。
また派生開発では、変更行数が少ないときは「一人プロジェクト」になるのはやむを得ませんが、「部分理解」の下で生じる思い込みや勘違いを防ぐ方法を講じる必要があります。XDDPの開発アプローチはこの問題にも対応できます。

「XDDP」は、下図のように「USDM」と「PFD」の２つの主要な技術に支えられています。

「PFD」 ( Process Flow Diagram ) は、今回の派生開発の要求（納期やコストも含む）を達成するために合理的な成果物とプロセスの連鎖を設計する技術であり、これによって手戻りが起きにくい開発アプローチを設計します。また途中での変化に対しても、開発アプローチの「別案」を考え出すための重要なツールなのです。
ただし、設計された開発アプローチの合理性を判断するには、そこに現れる成果物の構成などの定義とプロセスにおける作業の定義が必要になります。
一方「USDM」 ( Universal Specification Describing Manner ) の方は、今回の要求（追加／変更）を適切に表現し、そこから必要な仕様を引き出す方法を提供します。USDMは要求と仕様を階層関係の中で捉えますが、これはもともとモレが生じにくい構成です。そして要求に含まれる「動詞」をしっかりと表現することで、要求に含まれる「仕様」を引き出すテクニックを提供しています。
このようなUSDMの表記法によって、実際にベースライン設定後の仕様変更率が「１％」にまで押さえることもできています。

XDDPの主な特徴を以下に列記します。

• 変更と機能追加をそれぞれ別々のプロセスで対応し、これらを並行させます
• そのため、変更要求仕様書と追加機能要求仕様書の２種類の要求仕様書を用意します
• 変更と追加の要求仕様書は「USDM」の表記法を用います
• 変更プロセスでは変更要求仕様書、TM ( Traceability Matrix ) 、変更設計書の「３点セット」の成果物を作ります
• 変更要求仕様や変更設計書はすべて「before/after」で記述します
• これによって、追加も含めてXDDPで生成する成果物はすべて「差分」になります
• 機能追加は追加機能要求仕様を作成すると同時に、それをベースのソースコードに受け入れるための変更要求仕様を対応させます
• ソースコードの変更は、すべての変更箇所と変更方法を明らかにしたあとで一斉に取り掛かります
• 機能仕様書や設計書などの公式文書は、テスト終了後に「差分」の情報によって更新します

もっとも重要なことは、「変更」と「追加」を異なるプロセスで対応することです。「追加」は通常の要求仕様書が必要で、その後の設計プロセスや実装プロセスも新規開発のアプローチが使えます。そこに現れないのはシステム全体の「アーキテクチャを設計する」プロセスぐらいです。
一方「変更」は、簡単なケースでは変更要件から該当箇所の当たりをつけてソースコード上で見つけて変更する、というプロセスも必ずしも否定できません。税率の変更などはこのような対応でも問題は生じないでしょう。
もちろん、変更要件の内容によっては、もっと緻密なプロセスが必要になります。たとえば現状のソースコードを解析して不足している設計書の記述を補いながら、関係箇所の相互関係の理解を進めたり、メモリーの競合やCPUの負荷の状況を検証したりしながら、最適な変更箇所を特定するといった方法も必要です。しかも、こうして見つけた「変更箇所」も担当者の思い込みや勘違いの可能性があり、レビューの機会を設けながら作業を進める必要があります。 XDDPでは、このように「追加」と「変更」の要求が異なることを考慮し、変更プロセスにおいて「変更要求仕様書」「TM（Traceability Matrix）」「変更設計書」の３種類の成果物（３点セット）の作成を勧めています。これらは「What」「Where」「How」の３つの視点から変更箇所の情報を表現しています。
「変更要求仕様書」は、変更要求に対して変更箇所を「変更仕様」として記述しますが、すべて「before / after」で表現することを求めています。「追加する」や「削除する」は、それ自身が「before / after」を内包している用語です。そこでXDDPでは「変更」も「現状の仕様」に対して「新しい仕様」を対峙して記述することで「変更」の意図を表現します。この副次効果として影響箇所の気づきを誘導し、変更の難易度や変更行数の見積もりも容易になります。

　「３点セット」のポイントは、生成するタイミングが異なることです。従来は、変更要件ごとに
①該当箇所（変更箇所）を見つけて
②変更方法を考え
③その場でソースコードを変更する
という一連の作業が行われますが、XDDPでは①で変更要求仕様（とTM）を作成し、すべての変更要件に対して①の作業が終わった後にレビューを行い、担当者の思い込みや勘違いを除去してから②の作業に入って変更設計書を作成します。そしてすべての変更仕様に対して変更設計書を作成し必要なレビューを終えてから、変更設計書に沿ってソースコードを一気に変更します。
このように「３点セット」の成果物を作るタイミングが工夫されていることで、担当者自身でも思い込みや勘違いを除去できるのと同時に、それぞれの段階で関係者によるレビューを可能にしているのです。そして最後になって一気にソースコードの変更に取り掛かります。この一気呵成のソースコードの変更はXDDPの特徴の一つです。
こうすることで、複数の変更要件で変更箇所が重なるケースにも対応しやすくなり、従来のように何度もソースコードを変更し直す必要もなくなります。また別の変更要件の探索中に、既に対応した変更要件の対応方法で漏れていた箇所などに気づくこともあります。その場合でもまだソースコードを変更していませんので、より適切な情報に基づいて変更要求仕様を訂正できるのです。

XDDPの開発アプローチは適切な成果物を生成しながら作業を進めるため、途中で思い込みや勘違いに気づき易く、総じてバグは減ります。特に、複数人数で対応するケースでは、従来では各担当者が分担するソースコードを結合してテストに入ったところで、お互いの食い違いが元でバグが噴き出します。XDDPでは「３点セット」の成果物によって互いに変更箇所やその意図を確認する方法を提供してことで、テストで発見されるバグは大幅に減るのです。

また「一気にソースコードを変更する」というのもXDDPの特徴です。一般に上位のプロセスは要件の内容が生産性に影響を与えますが、実装プロセスは事前の準備さえ整えておけば個人の生産性データがそのまま適用できます。要件の内容に左右されることはありません。
XDDPでは変更設計書によって、すべての変更要件について具体的な変更方法まで記述していますので、ソースコードの実装工程は予定通りに進行します。ソースコードの同じ箇所を何度も変更することもありません。

従来の方法ではソースコードの変更に着手するのが早く、１時間あたりのコード生産性が「５行前後」というケースも少なくありません。その結果、２００００行の変更（追加も含む）に４０００時間（５人で４ヶ月）必要になります。
これに対してXDDPではコード生産性は一般に８０行～１００行に達します。

この結果、従来方法ではソースコードの変更作業を終えるのに合計５０００時間超の工数が必要になります。またその後テストに回されたところで２００件を超えるバグ（10件／KLOC）が発生します。さらに変更箇所の記録がないためにバグの対応に１０００時間超の手戻り工数（平均５時間／１件）が費やされます。
これに対して、XDDPでは「３点セット」の成果物を作りながら作業を進めますので、ソースコードの変更作業はわずか２５０時間、日程にして約１週間で終わってしまいます。つまり、３７５０時間（４０００時間-２５０時間）を投入して「３点セット」の成果物を作ってレビューすれば、わずか１週間余りでソースコードを変更できるということです。
実際には変更依頼から変更設計書に展開するのに「３７５０時間」を必要とせず、２割?３割ぐらいは余ります。この「２割」というのは従来方法では

• 変更作業を進める中で変更要件を依頼者に確認しなおしたり
• 何度もソースコードの同じ箇所を読み返したり
• 既に変更した箇所を読み返してその意図を思い出したり、さらに変更し直したり

している工数です。
XDDPの開発アプローチには「３点セット」があることでレビューなどによって思い込みや勘違いが相当数除去されますので、テストで発見されるバグも１／５～１／１０に減ります。上のケースでは３０件程度に減ると予想されます。さらに変更箇所の記録が残っていますので、バグの平均対応時間も半分に減り、手戻り工数は８０～１００時間程度で済むはずです。
こうして、従来方法で６０００時間を要していた工数が、XDDPでは３１００時間程度で対応できるということになります。実際にこれを裏付けるデータが多数上がっています。

「なぜなぜ問答は修得が難しいので、簡単に習得できる原因分析法を」と品質保証部長等から言われ、「分析後に関係者から感謝される原因分析」、「これが真の原因だと関係者が悟り改善意欲がわく原因分析」を目指して開発したのがプロセスネットワーク分析法（PNA）です。
組織のすべての業務は（経営者の業務も、管理者の業務も、技術者の業務も）インプットをアウトプットに変換するプロセスとみることができ、組織の成果を出すためにはそれらの業務は相互関係をもっていてネットワーク状になっている。これはJIS Z 9900に記載されていたプロセスネットワーク（JIS　Z　9900　4.7　組織におけるプロセスのネットワーク、及び4.8　品質システムとプロセスのネットワークとの関係）概念です。図にプロセス図および説明を示します。

図1　プロセス図および説明
（拡大図）

価値を付加する仕事をするために、組織に存在している業務【プロセス】が分析の対象範囲です。製品実現プロセス（JIS Q 9004　７．製品実現　JIS Q 9005　9　製品・サービス実現）関係だけではなく、マネジメントプロセスも、管理者や経営者の責務に関係するプロセス（JIS Q 9004　５．経営者・管理者の責任、及び、６．資源の運用管理、JIS Q 9005　７　経営者の責任　８　経営資源の運用管理）も必要に応じて分析の対象になります。

PNA法では概略、(1)分析課題の定義、(2)プロセスネットワーク（プロセスフロー以外に、プロセスマネジメントプロセス、プロセス能力調達プロセス）の調査、及び(3)プロセスネットワークの分析、(4)改善項目のまとめの順で分析を行います。実際にＰＮＡを行ってみるとプロセスフローを調査し、分析しただけで原因が判明することもあります。開発業務の場合のプロセスフローと特定のプロセスの能力支援プロセス群を図に示します。

図2　プロセスフロー
（拡大図）

図3　支援プロセス群
（拡大図）

開発技術およびマネジメントについての体系的な知識の収集と知識資産の構築が分析を行うためには重要です。そのためには組織としてプロセス能力・資産の構築と、資源の運用管理（JIS　Q 9004　５項、６項、JIS Q 9005　７項、８項）が重要な項目です。

PNAは、世の中に成果を出すための目的達成行動を対象とした原因分析技術です。しかし退職やノイローゼなどの衝動的な行為に基づく問題の分析には適用できません。この分野は心理的カウンセリングを用いた「なぜなぜ問答」の適用領域です。

適確な原因分析技術を修得していると、改善が進み技術力・マネジメント力が向上し、次のプロジェクトから未然防止ができるようになります。
原因分析の方法のひとつが「なぜなぜ問答」ですが、「なぜ」を単純に5回繰り返しても分析は成功しません。分析結果が縦の棒状になるようでは原因を見逃している可能性があり、多くの場合失敗です。分析結果はツリー状になることがしばしばあります。

「なぜなぜ問答」は管理者や品質保証スタッフが分析するのではなく、当事者が自問自答し、その後管理者や品質保証スタッフがレビューし、分析方法を指導することが勘所です。管理者や品質保証スタッフが分析すると過去の経験から誘導しやすく、誘導すれば再発しやすくなります。
当事者が原因分析する際には次の事項について注意する必要があります：

• 現物をみて分析する
• 複合文は単文にわけ、単文ごとに分析する
• 事実か推論か参考意見かを区別する
• 検証不可能な回答（形容詞・形容動詞）は詳細を具体的にする
  例：忙しい、時間がない、人がいないなど
• どのように行ったかを分析する（Whyではなく、What、How、Whenが先）
• 論旨を確認し検証するために図解（系統図が推奨）する

原因分析を管理者や品質保証スタッフが分析する場合には：

• 質問ではなく聞き出し相手に思い出させ・気付かせる（精神分析相談型カウンセリングの技術）
• 相手の思考を妨げない（討論や説得ではない・次々と言わない・間を置く・回答を待つ）
• 相手の思考を活発にするためにあいづちを打つ
• 相手が真実を言っているか相手を観察しながら行う

レビューする際にも、同様な事項を確認しながら行います。

• 分析の論旨を図解する、あるいは図解資料を基にレビューする。A4用紙程度の「なぜなぜ問答」テンプレートに記載されているようでは原因のもれの可能性があります。
• 図に記載された原因で、形容詞･形容動詞などあいまいな回答はすべて吟味します。
  例：忙しい　何を行っていて余裕がないか、担当している業務を列挙する。
• 図に記載された原因が事実か推論か吟味します。
  例：標準が無い　標準があるが；無視した、理解できなかった（教育に原因がある）、必要性がわからなかった（指導に原因がある）、標準を守らなくても誰にも指導されない（マネジメントに原因がある）などの可能性があります。
• 分析論旨に飛躍がないか吟味します。
  例：例外条件がもれた　設計時に気がつかなかったか、仕様書に記載があったか無かったのかを分析しているか。
• 分析もれ／不足を吟味します。
  例：最終検査でもれたと分析し原因分析は終了した。要求仕様書に記載されていない事項であり、要件開発工程も分析するべきだった。作りこみ工程の分析がもれた。またプロジェクト品質マネジメント計画も立案されていない（マネジメントプロセスの分析がもれた）。
• 分析の誤りがないかどうか検証します。
  分析の誤りで多いのが、実際には実行できないことを実行していないから問題が発生したと断定するケースです。次のプロジェクトなどで実行できるかどうかを検証する必要があります。
  例：検査でバグが発見され、レビューもれと指摘され、チェックリストの不備が原因だと報告された。次回のプロジェクトでそのチェックリストを正確に適用できるかどうか検証したところ、開発期間と対象物の量、チェックリストの量からすると実行できないことがわかった。設計課題、最終成果物の質に与える影響（FTA,FMEA、その結果から規定したプロジェクト品質マネジメント計画）、担当技術者の能力、その工程での品質保証記録から「ぎりぎりの意思決定」を行い、レビュー範囲を規定することがもれていた。
  例：検査もれと指摘された。しかし、テスト技術の観点からすると完璧な検証は膨大な期間と工数がかかり実行不可能である。検証しようとすると費用も大幅に増え、今回のプロジェクトの開発期間からすると納期を延ばす以外にない。開発期間と費用がかわるとこの商品の市場性はなく、商品開発は停止に追い込まれる。納期と費用との関係でどこまで品質保証するかはプロジェクト責任者決定事項であり、プロジェクト立ち上げ時のプロジェクト憲章にて前提条件および制約条件として明記すべきであった（プロジェクト憲章発行もれ・・・プロジェクト責任者の責任放棄）、またどのように品質保証するかはプロジェクト計画策定時にプロジェクト品質マネジメント計画を策定し、明記しプロジェクト責任者出席のレビューで決定するべきであった（プロジェクト品質マネジメント計画策定および審議もれ）。これらのことからすると、品質保証部門関係者およびプロジェクト責任者に対するプロジェクトマネジメント教育が欠落している可能性が高い。
• プロジェクト関係者がその要因が解消されたら、同じことは起きないと確信を持てるか。分析者や管理者が「真の原因がわかった」と納得することではありません。

それぞれが原因分析の結果を保存し、後日見直すと原因分析力の向上のきっかけになります。
分析結果を集めてみると「知らなかった型」「守らなかった型」「できなかった型」「意図的に省略した型（弁解型を含む）」「ヒューマンエラー型」などの類型があることがわかります。類型別に分析方法を訓練することを推奨します。
原因が判明したら、関連の専門領域を調べ知識体系や同様な要因類型（一般化）を調査し（一を聞いて十を知る）、系統図に追加することも原因分析では重要です。
「なぜなぜ問答」による分析は広い範囲に適用できますが、分析も、分析結果のレビューも難しい技術です。より簡単に修得できる技術として、ISO-9000に基づく原因分析技術「プロセスネットワーク分析」法があり、11月号に掲載する予定です。「なぜなぜ問答」だけではなく、「プロセスネットワーク分析」法の適用もお勧めします。

私の会社は、主なサービスとして障害者の方の地域生活を支援する事務所に対して、業務全般を支援するシステムをインターネットブラウザから利用する形で提供しています。
いわゆるSaaS（Software as a service）にあたるかと思います。派遣や請負開発もしていますが、現在は全てをSaaSへシフトしていく途上という感じです。
ここでは、お客様からの意見等を通じてどういった品質特性がどういった評価を得ているか、ということをお話してみたいと思います。

簡単に、障害者の方の地域生活支援について説明しますと、介護保険に類似した仕組みです。地域で障害者の方が暮らしていくサービスを提供している事業所に対して、国がサービスの対価を給付するといったものです。私の会社で提供しているソフトは、国に対する請求の計算と介護のコーディネート管理を主な機能としています。
このサービスを、自分たちでシステム化して提供するにあたっての状況、環境は以下のようでした。

• 私自身が、障害者の地域生活支援について非常に詳しい。
  （ヘルパー、コーディネーター、事業所立ち上げ等の実経験がある）
• 会社の信用が大してない。（起業まもなくで資本金1千万では大きな開発案件はこない）
• 会社のマンパワーがない。（メンバー5名）
• 社内メンバーにネットワークセキュリティのエキスパートがいる。
• 障害者福祉サービスは全国共通の仕組みなので、対象地域が日本全国。
• 障害者福祉サービスは仕組みや関連する法律が頻繁に変わるので、それに合わせてすばやくきめ細かいメンテナンスが必要。
• システムのお客様にあたるサービス提供者は、小さな事業所が多い。また非営利目的で事業をしている場合も多いので、多額の経費は出せないケースがほとんど。

こういった状況を解決するのにSaaSが持っているといわれるいくつかの特徴は、非常に費用対効果が高いであろうと考えました。

特徴1：	Webブラウザを利用してシステムを提供するため、インストールを必要とせず、またお客様と同じ画面、現象を提供側である会社でも見ることができる。
特徴2：	プログラムがサーバー側にある。
特徴3：	プログラムを購入してもらうのではなく、利用料をいただく形でシステムを提供する。
効果1：	初期導入が容易で早くなる。
効果2：	プログラム変更、バクの修正等もサーバー側で修正するだけで完了する。 お客様の事業所に直接訪問する必要が減るので遠距離でも提供しやすくなる。
効果3：	お客様のコスト削減。また必要な機能、運用規模に応じてシステムの提供を増減しやすい。

実際に、SaaSの仕組みでシステムを提供してみると、管理の容易さや遠隔地のお客様の増加等提供する立場としては、当初予想した通りに近い効果を得ている実感がありました。しかし、お客様の側から見てはたしてよいイメージがあるのか、あるいはそうだとすればどの部分がよいと感じているのだろうかとの疑問がわきました。ただなんとなくヒアリングしても漠然とした評判を聞いたような形になってしまうともったいないので、いいタイミングで私が参加していた社外コミュニティの集まりでISOの品質特性の話が出ていたのを、「これが面白い」と思い、かみくだいた形の質問を用意しそれを利用してシステムの評価をして見ました。
ご存知のように、ISO/IEC9126-1:2001では、ソフトウェア品質を示す特性とそれをさらにブレイクダウンした品質副特性を定めています。ヒアリングは、事業所の業務上のスタイルみたいなものがありますので、偏らないよう30社ほどにお願いしました。
顧客にとっての重要度、顧客評価はヒアリングの結果を、SaaS貢献度は提供側の社内評価で、3段階評価にしてみました。

（拡大図）

• 業務知識が、ある程度評価に結びついていると思われるもの
  機能性の副特性である合目的性、標準適合性や信頼性、保守性で比較的高い評価をいただいていることがわかりました。これについては、システムの特性より、私や担当エンジニアが、実際の業務経験や業務知識を持っているのに起因するものではないかと考えています。また、ヒアリングは、提供システムについての評価をお願いしたのですが、システムの性能ではなく例えばPCの操作やお客様の業務上のアドバイスに対しての評価が高いために満足度が高いという事例が思ったよりも多かったと思います。
• システム提供側の力点と顧客満足度にずれがあると思われるもの
  ある程度予想はしていましたが、例えば機能性の副特性である正確性などは、不具合が出ないのは当たり前で、数の問題でなく、不具合箇所が業務上どれだけ重大かという問題でそれも回復が早いと不具合が出ないより全体の満足度がむしろよくなる場合さえあります。
  移植性の副特性である設置性、共存性や保守性の副特性である試験性などお客様に見えにくい特性は、評価の高低以前に評価の対象にもなってないように思われます。機能性の副特性であるセキュリティにあたる所などは、かなり力を入れて高レベルなものを提供しているのですが、ある程度の評価はあるものの高の評価はほとんど無く、逆にどこからでも見られるようにしてくれといったセキュリティとは矛盾する要求があったことも少なからずあります。
• SaaSの貢献度が高いと感じられたもの
  品質特性から見てもSaaSがよいと思っていた保守性、信頼性などでは、副特性の試験性など例外もありますが、全般的には比較的顧客の評価が高く、また、顧客の評価は低いですが移植性に関しては、システム提供側としてのコスト低減、効率性を実感しており、この方式を採用した効果はかなりあると考えています。

質問も品質特性にうまく該当するものを作成できたかは自信ないです。しかし、ざっくりとした調査ではありますが、漠然とした実感と実際にお客様が思っていることのずれを認識するにはとても役立ったと感じました。精度、粒度はともかく実際に計測することの大切さを実感した次第です。

もともと自分なりに、システムはこういうものを提供すれば、と思っていたのを簡単にまとめると、お客様が

• 使うとよさそうと思う
• 使ってみようと思う
• 使ってよかったと思う
• ずっと使ってみてよかったと思う

の四つです。
経営というのはある意味、この四つをどれだけコストを掛けず質を落とさず叶えるかにかかっている気がしています。
今回の試みは、すでに利用しているお客様にお願いしたものなので主に、「使ってみて」「ずっと使ってみて」の部分についての評価と思いますが、実際にシステムやサービスが製品として成り立つには、「使うとよさそう」「使ってみよう」の部分もとても重要です。これはコストの問題と、あと品質特性でいえば使用性、機能性、信頼性、効率性などを可視化して、サービス利用を始める前に伝えることができるかがとても大切な要素となります。機会があればここの部分についても何らかの形で、想定ユーザーの意識を知る試みができればと考えています。

「わが社のA関連製品の売上が最近思わしくありません」「どんな製品ですか」「例えば、○○、○○などです」「いや製品の種類や名前でなく、顧客にどのような“価値”を提供しているかお聞きしたのです」「価値？」「ええ、それらの製品を通して顧客に提供している価値です」「そんな風に考えたことはありません。私たちは製品を提供していると思っていました」「製品そのものではなく、製品を通して価値を提供しているのではないのですか。売上減は、提供できている価値が、顧客が期待している価値に合致しないからではないのですか」

振り返れば、日本は戦後の復興がなった1960年ごろから四半世紀にわたり“品質立国”として高度経済成長を謳歌しました。それは心を込めて顧客価値提供に徹した経営の成果でもありました。1980年代初めにはジャパン・アズ・ナンバーワンなどとおだてられていい気にもなりました。そしてバブル経済に見舞われ、その後に味わってきた成熟経済社会の運営の難しさにまだ戸惑っています。打開のための有効な処方箋はあるのでしょうか。
品質立国日本が実現したのは、工業製品の大衆化による経済高度成長期が“品質の時代”だったからです。品質が競争優位要因であって、賢くも日本が“品質優等生”だったからです。品質が良いとよく売れます。品質が良いとスリムな効率的な管理が可能になります。その結果生産性が上がりコストが下がります。品質立国はこうして実現したのです。

バブル経済後の苦しみは、日本が成熟経済社会に移行し、それまでと異なる経営スタイルが求められているにもかかわらず、十分に対応できていないという国の経済構造、産業構造に原因があると言ってよいでしょう。
どのような時代にあっても、経営の目的が製品・サービスを通して顧客に価値を提供し、その対価から得られる利益を源泉として、この価値提供の再生産サイクルを回すことにあるという基本は変わりありません。品質とは、製品・サービスを通して顧客に提供される価値に対する顧客の評価を意味するなら、どのような環境にあっても“品質中心”すなわち“顧客価値提供中心”の経営が正統であることに変わりはないのです。

「経営において品質が重要だということは重々承知しています」「それで何をしてきましたか」「品質中心をスローガンに掲げ、コストより品質、納期より品質に重点を置いて経営管理を進めてきました」「どんな品質を求めてきたのですか」「えっ、ですから品質第一です」「どのような品質特性を重視してきましか」「……」「お客様はその製品のどこを評価して買って下さるのですか。評価して下さる特性は変化していませんか」
この会社は、品質を真摯に追求してきたと言っています。しかし、追求すべき品質についての自分たちの仮説を見直すことなく追求してきたのです。いま私たちには、成熟経済社会という“新・品質の時代”にあります。新たな品質の時代に、新たな品質概念の確立とその方法論の構築をめざすべきではないのでしょうか。経営の目的である顧客価値の追求、その達成方法の確立に血道を上げるべきではないのでしょうか。成熟した経済社会における品質管理は、原則は以前と同じでも、目標とする品質の範囲とレベル、企画・開発プロセスにおけるポイント、技術の活用、パートナーとの関係などにおいて、高度成長期とは異なるはずです。

「どのような品質の製品を提供すべきか分かったとして、その事業で成功し続けるためにどのような能力が必要だと思いますか」「能力？」「そうです、能力です。顧客の視点で価値のある、競争力のある強い製品を提供するためにあなたの会社はどのような点が優れていなければなりませんか」「競争力？」「ええ、顧客価値提供において他社に比べて優れていなければ事業としては成功できません」「わが社には、いいところもありますが、弱みも……」「もちろんです。何もかも強いなんてことはあり得ません。しかし、その事業分野で強くなくてはならない側面については、他社より優れていなければなりません」「競争優位要因ということですね」「ようやく分かっていただけましたか」
どのような事業分野にも、その分野の特徴、すなわち製品に対するニーズの特徴、顧客の特徴、製品実現に関わる技術の特徴、業界の特徴などに応じて、事業で成功するために必要な組織の能力像というものがあります。ある事業ドメインで成功する方法は多種多様ですが、ある勝ちパターンを現実のものとするためには何かが優れていなければなりません。それが競争優位要因です。

どのような時代でも、顧客価値中心という意味での品質中心経営が成功への道であることに変わりありません。しかし、目標とする品質は高度成長期と同じではありません。その目標品質を達成する方法の重点もまた従前と同じではありません。成熟経済社会に移行して、再び“品質の時代”を迎えました。しかし品質の意味は高度成長期に比べ広く深くなっています。現代は“新・品質の時代”なのです。現代の組織には“品質2.0経営”が求められているのです。経営の原点が組織的顧客価値提供活動にあるとの認識に立ち、品質中心、ひと中心、システム志向、自己変革などの行動原理に基づく品質マネジメントを推進して行くことが、いまとるべき道なのです。

日本製品の強みは高品質にあり、それは企画、設計、製造、品質保証、市場サポートに携わる人々の品質意識、技術力そしてプロセスの質の高さによるものです。ハード量産前に工場の技術者により主に生産性に対するチェックを通して設計に磨きがかかります。さらに品質保証部門による統合的なユーザー視点の製品テストとその結果に基づく「生産開始の合否判定権限」が製品の高品質に寄与しています。設計者も製造部門や品質保証部門のハードルがあるからレベルが上がり、三者のモチベーションも高いわけです。
しかし、近年競争の激化に伴う機能と複雑さは増加の一方であり、それを実現するために組み込みソフトウェアの規模も肥大化の一途です。また、生産開始日程や製品品質を決める比重がしだいにハードからソフトへと移ってきています。テスト前の上流工程でのソフトウェア品質は見えにくいため、 ソフトウェアの重要度が増すにつれ品質の維持が難しくなってきています（測定できないものはコントロールできません）。加えて、ハードと違ってソフトウェア設計品質には工場からの磨きはかかりませんので、品質保証部門も最後の総合テスト（システムテスト）のみでは品質に自信を持つことができません。最終の総合テストの段階で予想以上のバグが発見される場合の多くは、それ以前の工程での品質の造り込みが不足していたことを意味しますので、結局出荷後の潜在バグは多いわけです（ブラックボックステストのバグ摘出率は５０％未満といわれています）。

品質保証部門はハード主体の製品では総合テストを主たる任務とすることで済んでいましたが、ソースコードを含めた設計品質で製品品質の大勢が決まってしまうソフトウェアでは、それだけでは品質保証はできません。「工程検査」をしっかりやるべきです。すなわち、ソフトウェア開発工程の「要件分析・定義」「外部（主に機能）設計」「内部設計（アーキテクチャ設計とインターフェース設計を主とした詳細設計）」「コーディング」の各段階で、ドキュメントレビューやコードレビューが充分に実施されているかを確認しなければなりません。もちろん、スキルがあればレビュー（検証）に直接参加すべきですが（特に要件定義書や外部仕様書においては）、重要なのは各工程の成果物であるドキュメントの完成度が設計内でチェックされているかを確認することです。ソースコードについては、静的解析ツールを使用しながら可読性を含めたコード品質のチェックも済んでいることを確認します。そして、クラスのメソッドあるいは関数ごとに単体テストが基準を満たすように（例えば正常系はC1パスカバレッジ100%）実施され、関連モジュールとの結合テストが充分に済んでいるかを確認します。
そして、これらの「検証の充足度をいかに可視化するか（ものさし作り）という可視化技術」と「充足度を判定する基準作り」が品質保証部門に求められているわけです。このような途中のチェック能力と、いざとなればブレーキを踏むことができる権限が品質保証部門には必要です。さもないと先に進みたい一心の企画／設計部門はアクセルを踏みっぱなしとなり、途中までは早いですが、最後の総合テストで大ブレーキがかかり、製品プロジェクトという車は結局ゴールに予定時間内につけないことになるか、それでも無理に突っ走れば事故（市場問題）を起こすことになるでしょう。このようなことが起きないように、各製品プロジェクトに参加している品質保証部門の担当者は、設計成果物の品質確認（レビューやテスト）が計画通り実施されていることを適宜チェックしていくわけです。

現在は、多くの設計開発を資本関係のない外部の、しかも海外の開発会社へ請負型契約で委託しなければ競争に勝てない時代です。請負先には成果物責任がありますが、調達側が受け入れテストで品質の低さに気がついても「時すでに遅し」です。このような事態を避けるには調達側は内部仕様書、ソースコード、テストセット（単体テスト、結合テストに必要なテストコード、スタブ、テストケースなどのすべて）の品質を、早期に確認する必要があります。具体的には内部での開発と同様な成果物の品質保証計画を請負先に要求し、適宜調達側の設計部門が成果物品質を再確認することが大切です。この品質保証計画は当然調達契約書に含むようにします。工程検査では、この品質保証計画書の内容確認とともに、計画通りに請負側と調達側が成果物の確認を実施しているかチェックします。
品質保証部門が請負側のバグ出し屋になってしまうと、人をどんどん増すことになり結局品質も充分に上がりません。ハード部品の調達と同様な仕組みがソフトウェアの調達にも必要です。そして成果物の質と量で対価を支払らうべきです。

製品の品質問題を起こしてユーザーに迷惑をかけることは、その製品に関わった個人、チーム、組織のすべてにおいてプロ意識を欠いた恥ずかしいことである、という認識がまず必要です。次にその失敗を繰り返さないように、類似問題の再発防止／未然防止につながる予防措置を組織レベルまで共有することです。そして品質保証部門は、そのような仕組みが正しく機能しているかを確認する必要があります。プロセス改善は重要ですが、製品品質の維持には、特にソフトウェア開発に携わる設計者一人一人の「品質と生産性への意識」と「技術力」のレベルがある水準以上であることが前提です。逆も真、すなわち製品の高品質を目指すことが個人から組織レベルでの技術力、品質意識そしてプロセスの質を押し上げることになるのです。

私の所属する部署は、部品サプライヤー（以下B社）としてお客様の完成車メーカ（以下A社）へ納めるエンジン制御ユニットのソフトウエア（以下SW）を開発しています。 SWの品質を保つため、B社内でのValidation後、A社内でも、完成車としてValidationを行います。 また、B社内では、Projectへの開発中のプロセス履行監査（以下監査）を行っています。

ある時、そのA社のSW品質監査室の方から「B社さん、A社へ開示できないノウハウを含め詳細な内容に立ち入った監査をB社で完結することにより、不具合の防止をして下さい。ついては、B社さんの監査の仕組みのアセスメントをします」と言われました。

そこで私どもB社の監査のアセスメントをA社さんに行っていただきました。その際頂いたご指摘を基に、現在仕組みの強化中です。本編では今までB社の構築してきた監査の仕組みと、現在の強化の取り組みについてご紹介します。

A社のアセスメント結果は、「監査の仕組みがあり、必要なことの大部分はカバーされている。 しかしプロジェクト全体としての『やりきり感』が見えず、そのやりきりの監査が出来ていないので、やりきりを監査する仕組みを構築して欲しい」とのことでした。 やりきり確認の監査の方法はB社へ一任されました。

B社の監査の方法はインタビュー形式で、作業成果物の確認を行っています。そのため、 今までのインタビュー形式では例えば、「コードレビューを行っていますか？」に対し、プロジェクトリーダー（以下PL）は数件のレビュー結果（エビデンス）を示して、「はい」と答えればよいことになっていました。つまり、レビューを行った事実の一部を見せればよく、プロジェクトが設計工程でやるべき全てのレビューとテストをやりきっているか確認できていませんでした。

上記の『プロジェクトのやりきりの監査』構築のために、当初は監査担当者が直接エビデンスの確認を行うつもりでした。 しかし、エビデンスが入っているフォルダーを監査担当者が見ても、現在のプロジェクトの進捗に対し、全てエビデンスが格納されているのか判断できませんでした。

そこで、先ずプロジェクト自身で『やりきり』を『見える化』し、その姿を確認出来るようにしました。これによって、（１）今までは、担当者のレビューなどの工程スキップにPLが気付かなかった、または気付いても放置していたことによる不具合の流出への歯止めになると期待しています。また、（２）エビデンスチェックをインタビューの前に行っておくことにより、忙しいPL達とのインタビューの時間を短く出来ました。【図1】『やりきり』に関しては後述します。

上記をまとめますと下記のような方法になります。
『「プロジェクトの開発者が工程を遵守していること」を
「PLが確認（検図）していること」を
「監査部が監査する」』

また、監査部門として、開発プロジェクトへお願いした新たな品質目標は、以下の2点です。
（１）『工程不遵守による不具合ゼロ！』
（２）『工程未定義による不具合ゼロ！』

図1　完成度見える化表を使用した、やりきり度を確認する監査の仕組み
（拡大図）

以下で、『やりきり』と『見える化』の具体例を示します。

『やりきり』とは

行動としてまずは、例えば、全て（10件）の顧客要件に対して、それぞれ（10件）テスト結果があるということです。設計工程の例で言えば『要件分析－設計－コーディング－単体テスト－結合テスト』の工程があり、それぞれの工程にレビューがあり、テストにはテスト報告書があります。これらの全てのレビューとテストが行われていること。 これが『やりきり』の第1ステップです。当たり前に『愚直』に行うことですね。

『見える化』とは

各顧客要件に対して設計工程での作業成果物（エビデンス）が全てあることを確認したことを『見える化』します。【図2】の例では、3件の顧客要件に対し、PLは各設計工程でのレビューとテストの作業成果物を検図した後に●をつけます。

『見える化』のポイントは、ステータスの良し悪しが一目でわかることです。【図2】の例では、顧客仕様No.0002の『結合テストRM（レビュー議事録）』の欄が空白（検図されていないand/orエビデンスがない）になっているのが一目でわかります。

図2　工程やりきりの見える化表の例
（拡大図）

監査部署では、PLへ空白の理由を確認後、不適合項目として監査報告します。PLは報告に対して原因に対する是正処置をとります。

上記『見える化』例で考慮すべきことは5S（整理、整頓、清潔、清掃、躾）の精神だと思います。いつもきれい（全て●）になっていないと、空白があっても気にしなくなってしまうからです。

これはきりの無い質問です。しかしまずはRM（レビュー議事録）を見て、「(1)レビューアは間違いを指摘できるレベルの経験者である。*1　(2)添付されているレビューチェックリスト（ノウハウとしての観点集）を全て確認（✓ฺ）している。　(3)レビュー時間がレビュー対象の量に対して妥当である。*2　(4)全ての指摘事項に対し対策が打たれている。」
上記4点でレビューの『やりきり』を確認します（上記4点が検図の観点であり、レビューの『良品条件』です）。

• *1『指摘できるレベルの経験者』の判断は現状、検図者であるPLに任せています。 勿論「対象領域での経験年数3年以上」など、定義できなくは無いですが、運用レベルに達していません。
• *2 レビューの時間も検図者であるPLの経験値で判断しています。

対策中で、まだまだ改善の余地があります。大きなポイントは以下の2点です。

• 当事者のリーダー自身がどれだけ真剣に確認しているか
  プロジェクトの当事者ではない監査担当は、所詮エビデンスチェックで重箱の隅を突っつくことしか出来ません。どれだけ、当事者のリーダー自身が真剣に確認しているかが最終品質に影響することに変わりはありません。 この活動のキックオフに際し、「監査の仕組みつくりは、開発者のプロセスへの理解と意識の向上とを並行して行う」と宣言して活動しています。
• 監査担当者のスキル確保
  エビデンスへのアクセスを確保し、いざとなったら監査担当者もエビデンスの中身の良し悪しを確認出来る技術レベルの確保が必要です。運用後の監査担当者の人選と教育計画も必要です。

『やりきり』という言葉は、無限∞なイメージがあります。きっと決まったゴールは無く、自分で限界を決めてしまってはいけないという心があるのかもしれません。また『やりきり』とは、行動（努力）を示す一方、『やりきった』ことの判断は結果でするものかもしれません。今回の対策例に対し、これで十分『やりきっている』のかという問いは、『工程不遵守による不具合ゼロ！』を維持できていますかという問いに代わるのかもしれません。ですから逆説的ですが、手段としての『見える化』だけをやり過ぎることにより工数ばかり掛かって結果の出ない『見せる化』にならないよう注意が必要だと感じています。

SQiPは、ソフトウェア品質管理技術・施策の調査・研究・教育を通じて、実践的・実証的な
ソフトウェア品質方法論を確立・普及することにより、ソフトウェア品質の継続的な向上を目指します。