1．はじめに

ハードウェアとソフトウェアで構成されるコンピュータ・システムの納品物では，不具合発生製品数も不具合発生件数も，開発プロジェクトあたりで，ソフトウェアの不具合がハードウェアを上回っている[1]．さらに，コンピュータ・システムの開発費に占めるソフトウェア開発費は全体の5割を超えている[1]．このことは，ソフトウェア開発のQCD（Quality（品質），Cost（価格），Delivery（納期））管理が重要であることを示している．

ソフトウェア開発の管理を成功させるために，たとえば，PM（Project Manager）の育成や，品質管理部や生産技術部などの組織の整備や，開発プロセスの導入などの多様な取組みが，多くの企業で実施されている．従来から，ウォーターフォール型をはじめとして，スパイラル型やアジャイルなどの複数の開発プロセスが提案されてきた．近年では，国際標準の動向や顧客の要望などを踏まえて，企業での開発プロセスの導入が進んでいる．たとえば，IEC 61508の機能安全規格では，自動車や鉄道などさまざまな製品開発において，派生規格であるISC 26262やIEC 62278などで定められた開発プロセスに準じて開発をすることが求められる．

多くの開発プロセスは，要求定義や設計や実装など，複数の作業単位で構成される．本稿では，この作業単位を工程と呼ぶ．各工程では，開発者は，前工程から開発文書を受け取り，自工程に求める開発作業を行い，その成果を開発文書として作成する．さらに，その開発文書を次工程に送り，順次開発を進める．

各工程での成果物を評価するとき，プログラムは，コード行数やモデルの複雑度など，複数のメトリクスで品質が測定されることによって，品質が一定の水準で管理されている．他方，開発文書は品質のメトリクスが定義されておらず，品質が十分管理されているとはいえない．

そこで，我々は2011年にシステム開発文書品質研究会（ASDoQ：Association of System Documentation Quality）を設立し，開発文書の利用者の立場で，システム開発文書の品質の検討を開始した．ASDoQは，システム開発文書の品質の定義・測定・普及の活動を行う任意団体であり，2015年にシステム開発文書品質特性モデルの第1版をリリースした[2]．2016年8月現在，個人会員88名，法人会員17社で活動している．

本稿では，システム開発文書の品質のモデル化と，モデルの活用について報告する．第2章で開発プロセスと開発文書の関係を，第3章でシステム開発文書の品質のモデルを述べる．第4章で文書品質モデルの適用事例を，第5章で判明した課題を述べる．第6章で今後の展望を述べ，第7章にて結論とする．

2．開発プロセスと開発文書

2.1　開発プロセス

ソフトウェア工学の研究では，複数の開発プロセスが提案されている．ウォーターフォール型の開発プロセスでは，ソフトウェア開発を，要求定義や設計などの工程に分類し，各工程を順に進める．このプロセスでは，発注や進捗の管理を工程単位に明確に行うことができるので，プロセス通りに開発した認証を得る場合に利用されている．ウォーターフォール型は，改良されたり，ほかの型に組み込まれたりして使用される．現在広く使用されているV字モデルは，ウォーターフォール型の実装工程で折り返した表記をして，設計工程とテスト工程の対応関係を明示したモデルである．

ソフトウェアの企画，開発，運用，破棄に至るライフサイクル管理の進め方は，ソフトウェア・ライフサイクル・プロセスとして，ISO/IEC 12207（JIS X 0160）に標準化されている．我が国では，IPA（情報処理推進機構）がこの標準を元にして，共通フレームを定めている[3]．IPAはさらに，V字モデルに分類されるESPR（Embedded System development Process Reference）を規定し普及に努めている[4]．本章では，ESPRを例に，システム開発プロセスと開発文書の関係を論じる．

2.2　 ESPRにおける工程の入出力

ESPRは，図1に示す複数の工程（ESPRではアクティビティと呼ばれる）で構成される．まず，システムの要求定義を行い，システムをハードウェアとソフトウェアに分離したアーキテクチャを定める．次に，ソフトウェアとハードウェアの開発を，それぞれのプロセスに従い行う．

V字モデルに分類されるESPRでは，実装工程から右側にテスト工程が位置している．これらは，実装工程から右上に順に進める段階では，要求定義やアーキテクチャ設計などに対応するテストを，同一水平位置のテスト工程でそれぞれ行うことを示している．

ESPRでは，各工程の入力と出力が，それぞれ文書であることを明示している．図2は，ソフトウェア要求定義工程の入出力の例である．左側にこの工程に対する入力が，中央にこの工程で行うことが，右側にこの工程からの出力が書かれている．すなわち，ソフトウェア要求定義工程では，製品企画書やシステム要求仕様書などの文書を入力し，ソフトウェア機能要求の明確化などを行い，ソフトウェア要求仕様書と内部確認レポートを出力する．同様に，ESPRでは，各工程において，何らかの文書を入力し工程の作業をした後に文書を出力することを求めている．すなわち文書を工程間で引き渡すことで開発を進めるように，プロセスが定義されている．

2.3　本稿で扱うシステム開発文書

開発プロセスで定義されている，要求仕様書や設計書などの工程の成果物である文書のほかに，実際の開発では，レビュー記録や議事録なども作成する．

本稿では，これらの開発プロセスで定義された文書に加えて，開発業務の遂行上で生成するすべての文書を「システム開発文書」と呼ぶ．たとえば，開発会議の議事録や，開発業務の目的で送受する電子メールなども開発の遂行上で生成するので，システム開発文書として取り扱う．その上で，それら文書の品質を議論する．

3．文書品質のモデル化

我々は，「システム開発文書の品質はシステム開発に携わる読み手が決定する」と考え，文書の読み手が文書を読む過程に従って，システム開発文書の品質をモデル化する．

3.1　認識・理解・行為

事実と意見をできるだけ正確にかつ読み手の労力が少なくなるように伝えることを主目的とする文章を，阿部は情報伝達型の文章と呼んでいる[5]．システム開発文書は，情報伝達型の文章の一種であるので，読み手は，少ない労力で正確に理解することを開発文書に求める．

我々は，情報伝達型の文章に求められる「少ない労力で読み取る」性質を，読み手の「認識」が容易に行えることと位置づけた．そして，できるだけ正確に伝えることを，読み手の「理解」が容易に正確に行えることとした．加えて，開発文書の読み手は，理解した内容に基づいて開発という「行為」をすると考えた．すなわち，我々は，開発文書の読み手が，「認識」「理解」「行為」の順で開発文書を使用するとした（図3）．

一例として半導体工場の搬送機の制御システム開発にかかわる開発文書を想定する．搬送機は，さまざまな厚さや大きさのウエハーを搭載し，処理装置の間を走行する．搬送機の制御システムを設計する設計者は，走行経路や，許容される加減速の最大値や，過積載時の異常伝達方法などの要求を知り得なければ，システムを設計できない．そのために，設計者は，設計に必要な要求が，認識しやすく，理解しやすく，さらに設計という行為に必要な情報が漏れなく，要求仕様書に記述されていることを求める．

3.2　システム開発文書の品質のモデル化

我々は，システム開発文書の読み手が，「認識」「理解」「行為」の3段階を順に踏み開発文書を使用するので，それぞれに対応づけた開発文書の品質があると考えた．

「認識」の段階では，文書内容を理解する前処理が行われる．この段階では，文書は文法に従い，表記上の工夫がなされていることなどが求められる．そこで，我々は，認識のための品質特性として「規範適合性」と「可読性」を割り当てた．次に「理解」の段階では，書かれている内容を理解しやすく，矛盾がないことなどが求められる．したがって，理解の品質特性として「理解容易性」と「論理性」を割り当てた．最後に行為の段階では，開発に必要な情報が正確であり，漏れなく完全に記載されていることなどが求められる．そこで，行為の品質特性として「完全性」を割り当てた．以上の5項目を「システム開発文書品質特性」とした．

5項目の特性は，さらに細分化可能である．我々は，細分化した特性を，「品質副特性」と呼ぶこととした．さらに，品質副特性を測定する「測定項目」を設けた．

システム開発文書品質特性と，品質副特性と，測定項目の全体を，「システム開発文書品質モデル」と呼ぶ．以降，本稿では，システム開発文書品質特性を品質特性と呼び，システム開発文書品質モデルは文書品質モデルと略称する場合がある．

我々は，品質特性を5種類，品質副特性を14種類定義した．さらに品質副特性は，複数の測定項目で測定されると考え，測定項目の例として53例を提示した．表1に測定項目例を一部掲載する．

3.2.1　規範適合性

規範適合性とは，記述が文法や規則に則しているという品質特性である．この品質特性は，「文法適合」「記法適合」「基準適合」の3品質副特性からなる．

「文法適合」は，たとえば自然言語で書かれている場合には，日本語や英語などの文法に適合していることである．開発文書は，多くの場合，話し言葉（口語）ではなく，書き言葉（文語）で記述することが望まれる．

「記法適合」は，たとえば図や表を用いる場合に，定められた記法で記述することである．モデリング言語であるUML（Unified Modeling Language）はISOで標準化されているので，図をUMLに準拠して記述するならば，それを宣言して記法に従う必要がある．

「基準適合」とは，業界や組織などで特別に定めた基準に従うことである．たとえば企業は，企業内で用いる文書体系や，報告書や帳票などで用いるフォーマットやテンプレートなどを，多様な基準で用意している．これらの基準に従うことも，規範適合性に位置づける．

3.2.2　可読性

可読性とは，記述が読みやすいという品質特性である．この品質特性は，「簡潔」「統一」「表記工夫」の3品質副特性からなる．可読性は，文字の認識と構文解釈のしやすさの範囲とし，内容の範囲を含まない．

品質副特性の「簡潔」は，短文を用いるなど，回りくどくなく記述することである．たとえば長文になると，修飾語が多くなったり，主語と述語の間が離れたりして，可読性が低下する場合がある．

「統一」は，表記・表現方法および表現上の視点を統一することである．たとえば，同じ対象を指す単語の表記が異なると，独立した複数の対象が存在すると誤解されるおそれがある．

「表記工夫」は，文書に表記上の工夫をすることである．たとえば，複数の項目が定義されているとき，箇条書きすることで，可読性を高めるなどの工夫により，読みやすくなる．

3.2.3　理解容易性

理解容易性とは，文書内容の理解をしやすいことという品質特性である．この品質特性は，「非曖昧」「関係」の2品質副特性に細分化する．

「非曖昧」とは，一意に解釈できること，あるいは動作または状態を具体的に特定する記述をすることである．たとえば，「AはすべてBでない」という記述は，Aの全部分がBという性質を持たないという解釈と，Aの一部分はBという性質を持つという解釈が可能である．このように，複数通りの解釈が可能である状態を，曖昧と呼ぶ．さらに，意味の解釈を具体的に特定できない状態も，本稿では曖昧と呼ぶ．たとえば「処理する」という述語に対して，目的格が省略され処理対象が不明である場合がこれに該当する．我々は，前後関係や対象の知識などを用いて，曖昧さを解決している場合が多い．しかし，内容の理解を容易にするためには，非曖昧であることが必要である．

「関係」とは，各情報の関係を明確に記述することである．たとえば，議事録に明記した顧客の要望は，要求仕様書において実現すべき要求項目として定義し，設計書においてその要求項目の実現方法を設計する．これらの相互関係を明確にすることにより，読者の理解を容易にする．

3.2.4　論理性

論理性とは，論理的に整合が取れていることをいう品質特性である．この品質特性は，「無矛盾」「一貫」「構造」の3品質副特性からなる．

「無矛盾」とは，論理的な衝突がない記述をすることである．システム開発文書が対象とするシステムは，定義されたとおりに動作する．もし，要求とテストが矛盾していれば，開発成果を保証できない．システム開発文書の記述は論理的に整合している必要がある．

「一貫」とは，論理展開が合理的で一貫していることである．たとえば，設計を行う場合，リアルタイム性という制約を掲げた場合に，それを逸脱する設計が行われてはならない．

「構造」とは，内容の整理が合理的・体系的であることである．たとえば，階層化して記述する場合は，内容を適切に分割，整理すべきである．設計書としてその点に留意すれば，システムのモジュールの独立性が高まり設計の質が向上する．

3.2.5　完全性

完全性とは，開発に必要十分な情報が記載されているという品質特性である．この品質特性は，「合目的」「正確」「妥当」の3品質副特性からなる．

「合目的」とは，目的に合致した内容を記述することである．工程作業に必要な情報が網羅されているかが評価される．たとえば，要求仕様書には，要求定義工程で定める機能要求や非機能要求の内容を記述する．要求仕様書を入力する設計工程では，書かれた要求に従い設計を行う．要求が網羅して記述されていない場合は，その要求に対応する設計を行うことができないので，この品質が低いと判断する．なお，ESPRは，各開発文書に記述すべき情報を開発文書の目次として例示しているので「合目的」の指針となる[4]．

「正確」とは，記述内容が正しいことである．たとえば，設計書に処理アルゴリズムを記述するときに，繰り返し条件などを正確に記述しなければならない．

「妥当」とは，記述内容が妥当であることである．たとえば，ハードウェアの性能限界を超える精度での制御を求める要求は，妥当な要求とはいえない．

4．文書品質モデルの適用事例

本章では，開発現場において，文書品質モデルを適用した事例を示す．いずれも適用は，研究会とは独立に，各社で工夫をして行った．

4.1　文書品質可視化への適用例（A社）

4.1.1　開発文書の課題と文書品質の可視化

A社では，上流工程の成果物である要求仕様書や設計書の品質向上により，後工程での発生不具合の低減やレビューの効率化による製品開発のQCD向上を目的として，開発文書の改善に取り組んできた．そこでは，改善の効果を測るために，開発文書の品質を効率的に測定し可視化するしくみが求められていた．

開発文書の品質を効率よく測定するために，自然言語処理を活用した診断ツールを開発した．このツールは，曖昧表現を検出できるが，内容に踏み込んだチェックができない．したがって，ツールで測定できない部分は，人手によるレビューを行っていたが，その場合の明確なチェックルールはなく属人的であった．

共通のチェックルールを構築するために，抽出した問題点を分類して，測定項目を定義していた．しかし，測定項目が問題点の種類を網羅しているか，項目の分類が十分であるかなどの検証が困難であった．さらに，レビューのたびに測定途中で測定項目を見直すこともあり，測定を複数回くり返す必要があった．

そこで，測定項目を独自で定義する困難さを解決する方法として，文書品質モデルを活用して測定項目とその分類を定める取組みを行った．

4.1.2　文書品質モデルの適用

対象とする文書は，6ページからなるソフトウェア要求仕様書であり，A社の2名の診断者が文書を読んで明らかになった問題点を洗い出した．2名のうち1名は，レビュー工程で品質管理に携わる技術者であり，もう1名は，開発文書の品質に取り組む研究者である．これら2名が，対象とするソフトウェア開発チームに属さず，第三者の立場で，各々でレビューした．レビューでは，製品に対する暗黙知を持たない設計者やテスト技術者でも利用できる要求仕様書の在り方を想定して行った．なお，内製ツールでの測定も実施した．

表2に，2名の診断者による重複を排除した指摘件数と，ツールによる指摘件数を示す．人手により142件，曖昧表現を検出するツールにより53件の指摘があった．なお，人手による曖昧表現の検出は合計18件であった．曖昧表現の検出が，ツールの方が人手よりも多い理由は，ツールでは登録された曖昧な単語とその係り受けから形式的に検出しているためである．人間が文脈を理解しながら読むと曖昧ではない個所まで，ツールでは過剰に検出している．

実際の製品開発は，製品に対する暗黙知を有する技術者が，要求定義者とともに行う．そこで，曖昧な記述や条件が省略されている記述がある要求仕様書でも，知識で補いながら，あるいは要求定義者に確認しながら，開発が進められている．このように，従来の開発体制では表面化しなかった文書品質上の課題を，文書品質モデルの適用で明らかにすることができる．ここでは，副特性の人手による指摘件数で多かった，「記法適合」(29件)と「合目的」(24件)について，以下に分析する．

対象とした要求仕様書は，表を用いた書式で記述されていた．「記法適合」では，規定の書式で書かれていないという指摘が多数を占めていた．この理由は，執筆者が規定書式の記述に不慣れなので，規定書式とは異なる従来から使用していた書式を用いたためと考えられる．

「合目的」では，文言の意図が不明確であるなど，要求仕様書として記述すべき項目が欠落していることの指摘が多数を占めていた．この要求仕様書は，製品に対する暗黙知があれば読み取れるが，暗黙知がない開発者には理解できないことが明らかになった．

4.1.3　文書品質モデルを適用したことによる利点

従来は開発文書に対する品質管理の測定項目がなく，気がついた問題点をKJ法などで分類し，測定項目を構築しながら測定していた．そのために，測定項目を構築する作業や見直しの手間があった．さらに，測定項目が統一されていないので，複数の文書品質を比較することができなかった．そして，アドホックに測定項目を作成しているので，品質の網羅性について疑問が持たれていた．

これらに対して，文書品質モデルを活用することで，(1)測定項目の構築・見直しの手間が不要になった，(2)診断結果を示す枠組みとして文書品質モデルを使うことができた，(3)文書品質の分析を網羅的に行うことができた，という利点を得た．すなわち，レビューにおける生産性の向上を達成するとともに，従来にはない網羅的な分析で見つかった指摘を書き直すことで，要求仕様書の品質が従来よりも向上することが期待できる．なお，今回の事例では，要求仕様書のレビューのみを対象としたので，最終製品の品質との関係を確認しなかった．

4.1.4　文書品質モデルの適用による課題

今回の品質モデルを適用したレビュー試行で2種類の課題が確認された．第1に，測定値が必ずしも実際の開発現場で修正や改善が必要な欠陥とは一致しないことである．

表2のレビュー指摘分類の内訳では，ツールによる過剰な「理解容易性」に対する検出を除くと，「規範適合性」「論理性」「完全性」の順で指摘が多い．しかし，本診断結果をA社の開発にかかわる技術者に提示したところ，1番目に多い「規範適合性」にかかわる指摘は，A社の開発チームにとっては開発への影響が少ないので，実際の開発で文書の修正を指示する優先度は低いという意見をいただいた．しかし，「規範適合性」の指摘を正すことで開発の効率や品質が高まるので，優先度は低いが問題点として指摘してほしいという意見も出された．このことは，総合評価をする際には，品質モデルのすべての特性を一律の重みで扱うのではなく，対応の優先順位や開発への影響を考慮した重みづけをする必要があることを示唆する．

第2に，レビュー結果を特性にあてはめる際に，分類に迷う指摘が複数存在した．たとえば，文の係り受けにかかわる指摘では，完全に合致する測定項目が用意されておらず，「理解容易性」と「可読性」のどちらにも分類可能と考えられる場合があった．このことは，特性の分類基準の明確化や，レビュー担当者の教育などの必要性を示唆する．

上述の結果から，文書品質モデルは，その運用面での課題はあるものの，開発文書の品質の測定と可視化に活用できることが確認できた．特に，副特性ごとに測定項目例が示されているので，部署や担当製品の違いを超えて，測定項目をそろえることができ，文書品質測定の導入コストが低くなるｓｓｓと考えられる．

4.2　レビューへの適用例（B社）

4.2.1　レビューの指摘と文書品質モデルとの関係

要求定義工程や設計工程におけるレビューの目的は，要求定義や設計の品質を向上することである．上流工程での品質向上により，製品開発のQCDを向上させることが可能となる．このレビューを効率的に行うために，手戻りの大きい重要度の高い欠陥を優先的に検出するレビュー手法が研究されている[6],[7]．レビューは，工程で作る開発文書に対して行われるので，その欠陥を，文書品質モデルに対応づけることにより，レビュー時に特に注目すべき文書品質特性を明らかにする．

あるFA（Factory Automation）装置開発プロジェクトの要求定義レビューで，製品のハードウェアとソフトウェアの双方に精通したレビュー担当技術者が，従来からB社で用いてきたチェック項目を用いて手戻りの大きい欠陥を優先的に検出したところ182件が指摘され，重要度に従って致命的，重度，中度，軽度の4水準に分類された．

今回，レビュー工程に文書品質モデルがどのように利用できるかを検討するために，従来手法で抽出した欠陥が，文書品質モデルでどの文書品質特性に分類されるかを分析評価した．新たな欠陥検出をしていないので，今回の試行で最終製品の品質が向上したわけではない．なお，従来手法では欠陥の重要度を表現できるので，同様に文書品質モデルを拡張した．すなわち，品質特性と副特性に続いて，文書品質モデルの表の右列に，欠陥の重要度を記載できるようにした．

従来から行ってきたレビュー手法で検出した182件の欠陥の文書品質モデルへの分類は，レビュー担当者2名が個別に行い，その後に合議で分類を決定した．表3は，182件の指摘の，文書品質モデルへの分類結果である．

本事例では，「完全性」と「論理性」と「理解容易性」の一部の副特性に，欠陥が分類された．このうち，「完全性」の指摘数が過半数を占めた．他方，「可読性」と「規範適合性」への分類は指摘されなかった．これは，開発現場のレビュー担当技術者が，後ほどのデバッグによる手戻り工数が大きいと考える欠陥が「完全性」と「論理性」に偏在し，「可読性」と「規範適合性」を原因とする欠陥では少ないと見なしていることによる．すなわち，前者を検出する項目を充実させ後者を省略することで，レビュー工数を削減しつつ製品品質を確保しようとしているためである．

4.2.2　レビューにおける文書品質モデル活用

従来の開発現場で行われている欠陥検出が，「完全性」と「論理性」に偏っているので，文書品質モデルを用いて今までと同様の欠陥検出をするためには「完全性」と「論理性」を重視すればよい．さらに，文書品質モデルを欠陥の重要度を表現できるように拡張することで，従来から行ってきたレビューの水準を維持したレビューを行い得る．

B社では，現在は，製品開発の経験が長い技術者が，開発のすべての工程を担当しているので，文書品質モデルの「可読性」と「規範適合性」に関しては，たとえ欠陥があったとしても，大幅な手戻りにつながるミスを犯さずに製品品質が維持できることが経験上分かっている．そこで，これらの特性を軽視している．しかし，これらの特性は，文書の読みやすさを高め，誤読を防止し，開発の生産性を高めるために寄与するので，これらの特性に対する欠陥が放置されるべきではない．たとえば，新入社員の開発チームへの加入や，一部の工程をアウトソーシングする際などには，「理解容易性」と「可読性」および「規範適合性」の特性が重要になってくる．今回の分析で，必要に応じてこれらの特性に対するレビューを行うべきであることが判明した．その場合は，ツールを活用してレビューを行い，レビューに割く工数を増やさないことを検討する．

5．文書品質モデルの課題分析

本章では，現場での試用を通じて明らかになった課題と対応案を列挙する．

5.1　測定項目の課題

5.1.1　測定項目の整備不足

文書品質モデルは，測定項目を例示しているのみであり，品質を測定することを目的としては十分に整備されていない．さらに，品質の測定値の求め方に対して，モデルは言及していない．

A社の事例では，公開している文書品質モデルの測定項目例を用いて，品質が低い記述の検出を行い，検出数を用いて，その品質の測定値としていた．しかし，例示されている測定項目で充足しているとは言いきれないので，まず，測定項目の整備が必要である．

測定項目を充実させる1つの方法は，今までに行われてきたレビュー記録の分析結果を活用することである．従来から，レビューでは開発文書を精査し，欠陥を検出してきた．そこで，それらの欠陥を分析することで，具体的な測定項目を新たに追加する．これにより，開発現場の経験を活用した測定項目の整備が進むので，現場に即した測定項目を充実できる．

5.1.2　測定項目の分類迷い

A社の事例では，レビュー結果の品質特性への分類に迷いが生じていた．B社の事例でも，2名の担当者が異なる分類をした後に，合議をしていた．測定項目は，いずれかの品質副特性に割り当てられる．しかし，適用事例では，その割り当てに迷いが生じた．

このことは，開発現場で運用する際には，測定者が分類に迷わないように，事前の教育が必要であることを示唆している．そのためには，測定項目ごとに複数の文例を用意して，測定者が，より具体的に測定項目を理解するように支援することが考えられる．これにより，分類の迷いを低減することが期待できる．

しかし，なおも分類の迷いが解消されない場合は，品質特性，品質副特性，測定項目のすべてにわたり，見直しを検討する必要があり，今後の課題となる．

5.2　測定の課題

5.2.1　測定基準

同一の文書を複数人が測定する場合，判断基準の相違や，同一の判断基準においてもケアレスミスなどを原因として，欠陥件数に差が生じる可能性がある．他方，機械による測定でも，ツールにより判断基準が異なるならば，欠陥件数に差が生じる．さらに，人手による測定と機械による測定を同時に行う場合，A社の事例のように両者の値の性質が異なるので同様に取り扱うことができない．

人手による課題を解決するためには，まず，測定基準を合わせるために，測定者の事前教育が必要である．あるいは，複数の測定者が個別に測定し，その後に話し合いで測定結果を合意する方法も有効である．機械による測定では，ツールの種類とバージョンが異なることで生じる判定基準の違いを，管理する必要がある．そして，人手と機械による測定が混在する場合は，事前に値の扱い方法を決めておく必要がある．

しかし，いずれにおいても，測定値のゆらぎを根本的に解決するには至らないので，さらなる検討が必要である．

5.2.2　測定漏れ

B社の事例では，従来から行っていたレビューでは，「可読性」と「規範適合性」の欠陥が検出されなかった．その理由は，限られた時間内に効果が高いレビューを行うために，文書の内容に重点を置いたためである．開発現場では，このように「可読性」や「規範適合性」を軽視するレビューが行われることが多い．しかし，この状態が放置されると，可読性が低い文書が放置され，生産性や品質に悪影響を及ぼすことが考えられる．

「可読性」や「規範適合性」の測定項目は，「完全性」よりは機械による測定が可能な項目が多いと考えられる．そこで，機械による測定の導入を進めることで，品質測定を効率的に行いながら，品質の向上を目指すことが必要である．

6．文書品質モデルの今後

本章では，文書品質モデルの適用を通じて明らかになった課題を踏まえつつ，文書品質の測定方法の改善と，レビュー合否判断と人材育成での活用の可能性を論じる．

6.1　文書品質の測定方法の改善

6.1.1　機械による測定

自然言語処理の技術を応用することで，一部の測定項目で，欠陥個所の計数が可能である．

たとえば，「文法適合」の欠陥として，不適切な助詞の使い方や，誤字・脱字などの測定項目において，ある程度の機械による検出が可能である．「表記工夫」の欠陥としては，読点の使い方や過剰なカタカナ表記などの測定項目で，ある程度の検出が可能である．「非曖昧性」では，「約」や「かもしれない」などあらかじめ定義された，曖昧な語句の検出が可能である．

このように，意味解析を必要としない副特性では，いくつかの測定項目において，欠陥の検出が機械により可能である．そこで，ツールごとに，文書品質モデルのどの項目をどの基準で検出するかを整理する．これにより，複数種類のツールを効率的に使い分けることが可能となる．ただし，過剰な検出が行われることが想定されるので，検出結果を人手によりスクリーニングする必要もあり得る．

6.1.2　人手による測定

人手による測定では，どの開発文書の，どの品質特性を測定するかを，測定者の能力により定める必要がある．たとえば，設計書の文書品質として，完全性の項目を測定するためには，測定者は，設計書に書かれるべき技術項目に対する知識が必要である．

他方，同じ設計書であっても，規範適合性の項目を測定する場合は，測定者は，モデリング言語であるUML文法や社内の文書基準などに精通していれば良く，人材育成部門の担当者でも可能である．

このように，測定する品質特性の項目に応じて，測定者を決めて測定を行うことで，多様な能力の測定者が分担でき，作業負荷の分散が可能となる．なお，測定者による揺れを防止するためには，事前の教育と，複数名による測定が必要である．

6.2　文書品質モデルのさらなる活用

6.2.1　レビュー合否判断の透明性を高める

レビューでは，工程で作成した開発文書を精査して合否を判断する．たとえば要求定義工程では，要求仕様書を精査して，次工程に進むか否かを判断する．しかし，判断基準が不明確で，レビューをすり抜けた不具合が後工程に流出する事例が観察されている．文書品質モデルを用いることで，レビュー合否の判断基準を明確にできる可能性がある．以下にその一案を示す．

B社の事例から，手戻りの大きい欠陥は，文書品質モデルの「完全性」と「論理性」と「理解容易性」に分類される．そこで，これら3種の特性における指摘事項に関しては，改訂が必須か任意か，再レビューが必要か否かなどを，レビュー会議で項目ごとに定めることを必須とする．他方，「可読性」と「規範適合性」の特性における指摘は，大きな手戻りになる可能性が少ないので，開発者に対応を一任する．

6.2.2　注目すべき品質特性を際立たせる

今回の事例から，ソフトウェアの品質に直接影響を与える問題点と，文書の読み手の読みやすさに影響を与える問題点が，開発文書の利用環境により異なることが分かった．さらに，たとえばソフトウェアの品質に直接影響を与えると思われる「完全性」に対する指摘であっても，その影響度は，指摘内容に応じて，大きい場合も小さい場合もあり得ることが分かった．

すなわち，文書品質モデル上で，品質上の指摘件数の多少により，総合的な品質を論じることはできない．

そこでまず，文書品質モデルの特性に応じて，ソフトウェアの品質に対する影響度を割り振る．その値は，一般的には，「完全性」「論理性」の順で，小さくなる．その上で，B社の事例にあった欠陥の重要度という概念を文書品質モデルに取り入れる．これにより，検出件数が少なくても影響が大きい問題点を見落とすことなく対処が可能になる．一方，軽微な問題点であっても，きわめて多くの問題点がある場合は，作業効率の低下などの影響を勘案して，対策を検討することができる．

重みづけの分布は，開発プロジェクトの特性や，文書の読み手の経験や技術レベル，言語の精通度合などによって異なることが考えられる．

6.2.3　人材を効果的に育成する

技術者が作成した開発文書の文書品質を，品質副特性ごとに評価すれば，技術者の弱みと強みが副特性の単位で明らかになるので，効果的な人材育成が可能となる．

最初に，技術者が作成した設計書の文書品質を，レビュー担当者や人材育成担当者などが測定する．次に，人材育成担当者や上司などが，指摘された項目を精査する．そうすることで，人材育成担当者や上司は，技術者が弱点とする副特性を直接に高める教材を技術者に与えることができ，効果的な人材育成が可能となる．

たとえば1文の長さが100文字を超える長文が多数書かれていたので品質副特性の「簡潔」が不可とされている場合は，基礎的なライティング訓練を行えばよい．あるいは，複数の機能要求の設計が欠落したので「合目的」に関する指摘が目立つ場合は，技術者と面談して欠落理由をさらに探る必要がある．技術者の弱点を明らかにした上で，たとえば上位の要求を詳細化する手順や，抜けや漏れを防ぐための分析手法の習得などの教育を，個別に実施する．

以上のように，技術者が実際に作成した開発文書の文書品質を明示することにより，不足する能力を特定でき，その能力の効果的な育成が可能となる．

7．おわりに

開発プロセスを導入した企業の開発現場では，プロセスが定める開発文書を日常的に作成している．本稿では，これらの開発文書の文書品質モデルを解説し，適用事例を紹介した．

本モデルは，プロジェクト管理の改善や人材育成の促進などに，適用可能である．しかし，文書品質の測定や値の解釈などの点で，多くの課題を残している．それらの課題の存在を了解した上で，今後，開発現場での試用を進め，そこから出てくる意見をフィードバックし，開発現場で使用可能な測定方法を提案するとともに，モデルの改訂を継続して行う．

謝辞　ASDoQの会員の皆様，特に文書品質モデルに関して議論をしていただいた皆様に深謝いたします．本稿は，ASDoQの成果物です．