標準とレビューに基づくプロジェクト品質の安定化と向上

美味しい水をお探しですか？
定額制だからお水は使い放題！全て“月額料金”にコミコミ！
利用料金は業界最安値！

要約
はじめに
1. 昨今のＩＴプロジェクトの特徴
2. リスク管理と危険予知
システム開発標準
1. 標準の目的と意義
2. 各種標準の概要
チェックリストによるレビュー
プロジェクト品質の安定化と向上
取り組み成果
今後の課題
おわりに
参考文献

要約

不確実性の時代ITプロジェクトは多くの危険にさらされている。危険は、品質・コスト・納期だけでなく、スコープやコミュニケーション、組織管理や調達管理などプロジェクトのあらゆる分野に潜んでいる。これらの危険を早い段階で予知し、予め対策を考えておくのがリスク管理である。しかし、危険予知を属人的能力に頼っていると、予知に漏れが生じるという大きな危険がある。予知できない危険は、管理しようが無いからである。そこで標準をプロジェクト活動の基軸とし、チェックリストを使用したレビューにより、危険予知を組織的かつ効果的に行い、プロジェクト品質の安定化と向上を図った。その結果、計画期間内でのシステム実用化率は６０％から８０％程度に向上し、全てのプロジェクトで投資対効果(ROI)は１００％を超えた。

はじめに

昨今のＩＴプロジェクトの特徴

ＩＴプロジェクトが失敗する要因として常に上位に位置づけられているのが要件定義に関わるものである。あいまいな要件定義や要件の漏れ、要件変更の多発などにより、後工程で手戻り等が発生し、品質・コスト・納期が悪化する。手戻りだけではなく、要件定義のプロセスと成果物に埋め込まれた不適合や欠陥は、次工程の設計に引き継がれる。その設計に埋め込まれた不適合や欠陥は、コードに引き継がれる。こうして工程を経て埋め込まれた不適合や欠陥のあるコードをどれだけ綿密に試験（検証）をしても、品質を確保することはできない。不適合や欠陥のある設計書に対して、どれだけ綿密に試験（検証）をしても同様に品質を確保することはできない。

つまり、９０点の要件定義に対して９０点の設計をし、９０点のコードを生成し、そのコードを１００％試験（検証）しても、９０％ｘ９０％ｘ９０％≒７０％の品質しか確保できない。また、要件変更を適切にコントロールできないと、スコープが当初の計画から逸脱し、これも品質・コスト・納期を悪化させることになる。さらには、コミュニケーションが錯綜する、組織管理が混乱する、調達管理で問題が発生するなど多くの要因が、プロジェクト品質を不安定にし、品質・コスト・納期を悪化させることになる。このような事態を引き起こさないためにリスク管理が必要とされているが、ここにもリスクが適切に管理されないという問題がある。

このようにＩＴプロジェクトには要件定義に起因して、様々な分野に渡り多くの危険が潜んでいる。それでは、要件定義を１００％完全にすればよいのかと言えば、事態はそれほど単純ではない。企業はグローバル競争の真っただ中にあり、日夜走りながら新たな開発技術やプロセスを模索しており、昨今のＩＴプロジェクトは、新しいビジネスモデルや業務プロセスの変更を伴うものが多い。加えて、ＩＴそのものが日進月歩であり、不安定である。まさに、不確実性の時代であり、ＩＴプロジェクトの要件を１００％完全に定義することは、事実上不可能である。つまり、要件定義段階で完全に危険要因を除去することはできないのが実情である。

リスク管理と危険予知

要件定義が不完全（潜在的な危険をかかえた状態）でも次へ進まなければならないＩＴプロジェクトにおいては、リスク管理が必須となる。リスクとは、もし－将来に発生した場合、プロジェクトに影響を及ぼす危険要因である。リスク管理は、この危険要因を洗い出すことから始まる。ところが、実際にリスク管理をしようとした場合、この最初におこなう危険要因の洗い出しでつまずくことが多い。なかなか、危険要因が思いつかないのである。将来の危険を予知するのは、多くの場合、個人が持つ失敗経験に依存することとなる。経験の無い失敗を、将来に発生するかもしれないとして予知するのは、普通は困難である。こうした属人的な洗い出しで漏れた危険要因は、管理対象からはずれ、実際に発生した時には不測の事態を引き起こし、プロジェクトを危機に陥れることになる。

すなわち、事故の発生となる。この事故を未然に防止するための取り組みとして、産業界ではグループで事故を想定し、ディスカッションすることで危険要因に対する感度を高める“危険予知（訓練）”が行われている。危険予知では、危険を防止するためにとるべき行動や作業手順を標語や作業標準に反映するなどして組織的に学習し、属人化させないような工夫もしている。ＩＴプロジェクトにおけるリスク管理を効果的に実践するには、このような組織的危険予知（訓練）を行うことで、できるだけ多くの危険要因を要件定義段階から洗い出すことがポイントとなる。

システム開発標準

標準の目的と意義

ＩＴプロジェクトのプロセスや成果物に潜む危険を的確に予知するには、それらを属人化させないことが重要となる。プロセスや成果物が属人的に行われる組織では、危険の発生確率のバラツキが大きく、成功しても再現性が無い。プロセスを標準化することで、プロセスの抜けや漏れ、実施内容に対するバラツキが抑制される。成果物の記載内容や記載項目、様式を標準化することで、成果物のバラツキが抑制される。成果物のバラツキが抑制されれば、それを入力とする次工程のプロセスや成果物のバラツキも抑制される。プロジェクト全体でプロセスと成果物を標準に従って実施することでバラツキを抑制できれば、危険予知を効果的かつ効率的に行うことができる。何故なら、プロセスと成果物のバラツキを抑えることができれば、危険が潜伏している範囲を限定し、発生確率や影響度も特定しやすくなるからである。その結果、プロジェクト品質の安定化が図られる。

「ばらつきに関する知識」
測定可能なものには必ず標準的な分散と特殊原因による固有の問題があると理解することである。品質向上は、特殊原因を排除し、標準的な分散を制御することに他ならない。（W・エドワーズ・デミング博士　深遠なる知識より）

標準の様式に対して、堅苦しい、思考が拘束されるなどネガティブな意見もあるが、JIS規格の製図総則には次のように書かれており、標準の様式は決して「見栄え」を良くするためではない。また、規格に従うことで自由なアイデアの発想が制約を受けるわけでもない。

JIS Z8310：2010製図総則
図面の目的は，図面使用者に要求事項を，確実に伝達することにある。さらに，その図面に示す情報の保存・検索・利用を確実に行うことができるように，図面を管理した状態にしておかなければならない。

各種標準の概要

(1)ITマネジメント標準
計画策定、開発・運用保守、評価・改善といったＩＴマンジメントのＰＤＣＡサイクル全体を通じてのプロセスと成果物を規定したもの。大局的な観点からプロジェクト品質の安定化と向上を図る。

(2)システム開発標準
システム開発の要求分析～運用試験まで各工程で必要となる標準プロセスと成果物を規定したもの。標準プロセスは、各工程で実施すべき作業項目を明記すると共に、ＷＢＳのテンプレートである。同様に成果物についても、各成果物に記載すべき項目を明記するとともに、記入様式をテンプレート化する。また、各工程で実施するレビュー・プロセスとレビュー対象成果物、レビューチェックリスト及びレビュー報告書などの標準。

(3)見積もり標準
ファンクションポイント法による見積もり手順と各種基準値を規定したもの。見積もりのバラツキを抑えることは、コスト・納期面での属人的リスクを低減し、プロジェクト品質の安定化を図る上で非常に重要である。基準値は、外部要素毎のＦＰ数やＦＰ係数（時間／ＦＰ）、言語生産性など。さらに、見積もりの観点から要求仕様書の記載内容を標準化。これにより、見積もりの調整パラメータを絞り込むことができ、見積もりのバラツキを抑制することができる。

(4)調達標準
ソフトウェア開発を外部委託する場合の見積もり、契約／発注、検収までのプロセスと必要な帳票類、成果物（発注仕様書、見積書）およびそれらのレビューチェック項目を規定したもの。発注仕様書は、納入物、納入場所、納期など基本事項に加え、著作権や瑕疵担保期間などの妥当性をチェックする。見積書は、見積もりが標準に適合しているか、調整パラメータが妥当かなどをチェックする。これらのチェックが全てパスし証跡が確認できなければ、注文は承認されない。これにより調達管理面からプロジェクト品質の安定化を図るだけでなく、商取引におけるコンプライアンスに対する危険防止にも役立てる。

チェックリストによるレビュー

リスク管理におけるレビューの目的

プロジェクト品質を安定化するためには、プロセスと成果物に対する標準を規定し遵守するだけではなく、各工程でレビューを実施し状況をモニタリングすることが重要である。実施したプロセスが妥当であったかや成果物の誤字脱字や矛盾・不整合などはもちろん、次工程以降（将来）に発生しそうな危険がどれだけあるかという観点で予知できるかがポイントなる。この観点を属人的な経験だけに頼ることは、危険予知の範囲や深度にバラツキが生じるという危険がある。これを防止するには、標準に従ってプロセスや成果物が実施されたかどうかを、標準化されたチェックリストを使用してレビューすることである。

リスク管理を意識したレビュー実施要領

各工程レビューで使用するチェックリストは、各工程のプロセスや成果物の標準で規定している項目に対応したものであり、このチェックリストを使用することで、誰もが原理原則である標準を遵守しているかどうかを効率的かつ効果的に確認できる。例えば、成果物間において追跡性や一貫性が確保されているか、記載項目が標準に規定された内容を満足しているかというようなチェック項目がある。その他にも、これまでの失敗経験や戦訓などから得たチェック項目も標準化して、これらのチェック項目に沿った形でレビューを進めている。チェックの結果、標準に適合していなければ、危険の可能性が高い。従って、成果物の承認を上程する場合、チェック済のリストとレビュー報告書の添付が無ければ、内容の如何を問わず差し戻すことを徹底すべきである。標準は、ここまで愚直に徹底してこそ、はじめて危険予知に対する有効性が確保できる。

チェックリストによるレビューの効果

このように標準化したチェックリストをベースとしてレビューを進めることで、参加者が客観的にレビューを進められるという利点もある。属人的なレビューでは、指摘内容が属人的になりがちであり、そこに是非の議論が生じることがある。そのような議論は、重要ではあるが生産性やコミュニケーション面で問題となる危険が潜んでいる。しかし、標準に対して適合しているかというチェックリスト方式であれば、指摘そのものに対する是非の議論の余地は無く、また、指摘対象は個人ではなく、あくまで成果物である。そのためレビューの生産性も高く、個人攻撃にならずに和の精神を持ってレビューを進められる。これは、「罪を憎んで、人を憎まず。」という精神の具現化でもある。このように、(個人の立場や論点を明確にして議論を戦わせるという欧米風なレビューではなく)チェックリストなどを介在させたレビュースタイルが日本人には向いていると思われるし、また、議論を避けるあまりレビューをしても誤字脱字の類しか指摘事項が出てこないという危険も回避できる。

プロジェクト品質の安定化と向上

プロジェクト品質の安定化

品質・コスト・納期を守るだけでなく、スコープ、コミュニケーション、組織管理や調達管理などプロジェクトのあらゆる分野において良好な状態でプロジェクトを完遂し、計画どおり目標を達成できるかどうかがプロジェクト品質である。このプロジェクト品質にバラツキを生じるノイズが様々な危険要因である。

品質工学によれば、品質を確保するには、まず、このバラツキを少なくし品質レベルを安定化させなければならない。そして、次の段階で品質レベルを上げるように改善するのである。プロジェクト品質が不安定（属人的でバラツキが大）な状況では、成功しても失敗しても、それは偶然の結果でしかない。達成できた品質を組織的に再現することも、失敗から学び組織的な再発防止を図ることも困難である。これでは、いつまでたってもプロジェクト品質を着実に向上させることができない。標準を規定し、標準を遵守しているかどうかをチェックリストによってレビューすることで、バラツキを少なくし危険予知を組織的に行うことができる。その結果、プロジェクト品質の安定化を図ることができる。

プロジェクト品質の向上

標準に従って失敗した場合、原因は標準の不備にある。従って、対策は標準の不備を原因究明し改訂（改善）すればよい。そして改訂した標準に合わせてチェックリストも改訂し、レビューで確認することで同じ類の失敗を確実に防止することができる。さらに、既存の標準を改善するだけでなく、新たに標準を定めていくことでプロセスや組織能力をより高次へとレベルアップし最適化を図っていく。このように標準とレビューを基軸として改善のＰＤＣＡサイクルを回すことで、プロジェクト品質を安定化し向上するために必要な組織能力を確実にスパイラルアップしていけるのである。このスパイラルアップを、日本古来の芸道では「守破離」という言葉で端的に表現している。これは、CMMI（能力成熟度モデル統合）で言うところのレベル３～５にあたる。

・守・・・師匠の教えを守ってしっかり基本を身に付ける段階→標準の遵守。
・破・・・基本を少しずつ破って独自の工夫を加える段階→標準の改善。
・離・・・師匠から離れて独自の流派を確立する段階→新しい標準の制定。

・CMMIレベル３・・・定義された。
・CMMIレベル４・・・管理された。
・CMMIレベル５・・・最適化している。

「定義されていないものは管理できない。管理されていないものは測定できない。測定されていないものは改善できない」（W・エドワーズ・デミング博士）

新しい知識体系の標準への取り込み

（１）従来の標準とレビューの限界
従来の標準は主要なタスクと成果物を定義しており、各タスクの具体的な進め方までは標準化されていない。例えば、要求分析工程では主要なタスクとして、改善ニーズの明確化や現行業務把握というタスクがあり、それぞれ成果物としてニーズ表や現行物理／論理モデル図（データフローダイヤグラム）などが定義されている。しかし、これらのタスクを具体的にどのような作業手順で進め、どのように成果物を記述すればよいかまでは標準化されていない。そのため深いレベルでの作業の進め方や成果物の品質が属人的でありバラツキがある。例えば、改善ニーズの明確化では、ユーザからヒアリングした内容を所定の様式に記述するだけの人もいれば、現場を見に行って自分の目で確認までする人、さらには現場での改善活動に参加してユーザと共に改善点を検討する人まで掘り下げの深さはにバラツキがある。成果物がどこまで掘り下げられており、真の改善ニーズを把握できているかは、有識者によるレビューに依存する。しかし、標準化されていない内容の深いレベルに対しては、チェックシートも万能ではなく「現状の問題を把握し、改善ニーズを明確化したか」という程度のチェック項目となっている。現状の問題を漏れなく把握しきって、真に改善ニーズが明確になっているかどうかは、レビューアの属人的な経験に頼るところが大きい。

（２）標準の高度化
そこで、新たな知識体系を標準に取り込み属人的な品質のバラツキを改善しようと試みる。メジャーな知識体系としては、ＰＭＢＯＫ（プロジェクトマネジメント知識体系），ＢＡＢＯＫ（ビジネスアナリシス知識体系）、ＲＥＢＯＫ（要求工学知識体系）がある。

(a)ＰＭＢＯＫ(A Guide to the Project Management Body of Knowledge)
プロジェクトの統合管理としてＰＭＢＯＫで管理することを明記し、プロジェクト管理状況チェックリストで適時、プロジェクトの遂行状況を確認できるようにする。チェックリストはＷｅｂ上で公開されているものを活用し、各管理エリアに４～５のチェック項目がある。例えば、リスク管理の中で「開始時に【リスク一覧】が洗い出されて対策を考えているか」などのチェック項目があり、キックオフ会議でリスクを洗い出し【リスク一覧】を作成する。

(b)ＢＡＢＯＫ(Business Analysis Body of Knowledge)
システム開発で最も重要な点は問題（業務ニーズ）を正しく把握するということにある。このスタートが間違っていると、解として得られるシステムがどれだけ素晴らしいものであっても意味がない。あるいは業務ニーズと乖離した無駄な機能を多く作りこむ結果となる。そのため【ニーズ表】は非常に重要な最初のアウトプットであり、後工程での成果物に付加価値を与える重要なインプットになる。裏返してみれば、昨今の業務ニーズ自体が不確実なＩＴプロジェクトでは、最も潜在的リスクの高い工程である。従来の標準では、ユーザからヒアリングした結果を単に記載するのみの内容が多い。そして、典型的な間違った記述は「問題：伝票が紙のままである。改善ニーズ：電子化する。」のようなものである。これは真の問題を記述しておらず、現状を記述したに過ぎない。真の問題は、紙ゆえにどんな不都合なことが現場で起きているかである。これを掘り下げるには、利害関係者の把握から始めなければならない。また、問題を掘り下げた結果、改善ニーズは電子化だけに留まらず業務ルールや組織などにも及ぶ。これらを総合的に踏まえた上で、電子化を推進しなければ真に業務上の問題を解決することはできない。このように改善ニーズを明確化するためには何をすればよいかが、ＢＡＢＯＫには書かれている。

(c)ＲＥＢＯＫ(Requirements Engineering Body Of Knowledge)
要求仕様分析工程では、システムが具備すべき要求仕様を分析し明確化する。ここからは、従来の標準でもそれなりに具体的なタスクと成果物が定義されている。ＲＥＢＯＫを補助文書として使用することで、より詳細なインプット／プロセス／アウトプットを参照することができ具体的に作業を進める上での助けとなる。

取り組み成果

これらの取り組みにより“標準に書いてあったよね！”というミスや失敗はほぼ無くなり、標準に帰結するような手戻りは発生しなくなる。これは、標準とレビューの相乗効果によるところが大きい。これまでは、標準に書かれていることが実施されていなくても、レビューで発見できないことがあった。その結果、後工程でミスや失敗が発生したときの原因究明で、標準に書かれていることを適切に実施していれば防止できたようなこともあった。そのような状況を回避するために、これまでは標準に従って作業し成果物が作成されているかどうかを細かく点検する必要があった。また、点検者がチェック漏れをしていないかどうかを承認者が同じように二重で点検する必要があった。その結果、点検者も全ての標準が頭に入っているわけではない為、必ずいくつかの点検漏れが発生するリスクが常に存在し、承認者の負荷が高かった。取り組みの結果、この点についても改善が図られ承認者の負荷が軽減される。承認者は、標準に従って作業し成果物が作られているかどうかを、成果物そのものではなくレビューチェックリストのチェック結果と証跡を確認すればよい。それで標準的な品質は担保することができるので、さらに標準化が難しい個別の内容について重大なリスクが内在しないかどうかを確認する時間的余裕を持てるようになる。後はチェックリストが形骸化しないように、適時、成果物とチェックリストをサンプリングして確認すればよい。

プロジェクトを遂行する中で、いくつかの標準やチェックリストを改定する。これは、作業者が自主的に失敗から学んだことやリスクと感じられる点を防止するために実施すべきである。このことから標準とレビューによるプロジェクト品質の安定化と向上が現場中心に図られると考えている。結果的に各人のスキルアップにつながり人材育成が図られる。さらに、新しい知識体系を取り込むことで、従来の標準ではカバーできていなかった深いレベルの品質向上も期待できる。例えば、ニーズ表の記述がこれまでよりも現場の実情に則して掘り下げられているものになるとか、業務分析を行う上でステークホルダーやニーズの優先順位を意識するようになる。あるいは、プロジェクトを推進する上で品質・コスト・納期だけでなく、コミュニケーション管理やリスク管理も意識するようになるなどである。

これらの総合的な成果として、計画期間内でのシステム実用化率が６０％から８０％程度に向上し、全てのプロジェクトで投資対効果(ROI)は１００％を超えるようになる。いわゆる“作っても、使われないシステム”や大幅な予算・コストの超過が皆無となる。

今後の課題

従来の標準は、ウォータフォール型の開発方法論をベースとしたものであるが、近年、アジャイル型開発や反復型開発への移行が多方面で提言されている。これは、業務ニーズ等の不確実性に伴う変化への対応が、ウォータフォール型開発では対処が困難というのが主たる理由となっている。振り返って、実際のプロジェクトを見てみると計画期間内にシステムが実用化できない案件が増えつつある。原因は、運用試験工程の遅延である。遅延の理由は、業務ニーズとシステムの整合性を確認するのに時間がかかっていることと、業務ニーズの取りこぼしによる機能追加である。結局、一番最初の【改善ニーズの明確化】に問題がある。この問題は、業務ニーズの不確実性故にどれだけ厳密にビジネスアナリシスを実施したとしても１００％完全に明確化することは不可能であり、それを前提とするウォータフォール型開発では限界があり、解くことができない。

そこで、業務ニーズが明確化できた部分からシステムを開発し早期に実用化することで、次の業務ニーズを顕在化させシステムを進化させるという多段階開発を適用する。これは、トヨタ生産方式の「改善は巧遅より拙速」（頭の中で考えすぎて遅くなるより多少は稚拙でも速く改善を実施し、隠れた問題を顕在化させ次々と改善を継続的に行うほうがよい。）という考え方を参考にできる。ちなみにアジャイル開発は、トヨタ生産方式をベースとしたアジャイル生産方式（又はリーン生産方式）をソフトウェア開発に応用したものであると言われている。いくつかの適用事例を通じて成功・失敗を整理して、標準に取り込んでいく必要がある。ここでは、優先順位づけや反復計画、反復を前提とした変更管理やアーキテクチャ設計、リファクタリング等の標準化がいっそう重要になる。そして、アジャイルに行動しながらも雑駁にならず、プロジェクト品質の安定化を図るには、標準（基本）が無意識にできるくらいしっかりと身についている必要がある。アジャイルとは、標準無視や手抜きで無節操に素早くやる小手先の技ではなく、標準を基本とした上で臨機応変にプロセスを素早く反復する大技である。

おわりに

不確実性の時代、プロジェクトや組織に潜む危険を予知して素早く判断を下し、組織を率いるようなリーダーシップが求められている。欧米では、このリーダーシップは、個人に依存したイメージが強く、いわゆるヒーローである。しかし、日本的な組織では、このようなヒーローを求めるのではなく、組織に属する一人ひとりがリーダーシップを発揮して、危険を回避していくのが良いと思われる。その為にはプロセスや成果物の実行及び危険予知などを属人化せず、組織としてプロセスや成果物のあり方、原理原則を標準として規定し、その標準への遵守や適合性をチェックリストによって皆でレビューし、すり合わせながらプロジェクトを進めていくのが良いのではないかと考える。「必要なものを、必要なだけ、必要な時に」という考えの基、標準を遵守しながらも、その標準を常に現場で改善する「すり合わせ型」組織を作り上げ、世界最大の自動車メーカとなったトヨタを手本に、プロジェクト品質の安定化と向上を図ることができる。

参考文献

[１] 富士通（株）、システム開発標準SDEM90
[２] DOD－STD－2168、DOD－STD－2167A The software development audit
[３] IEEE/EIA12207 Software life cycle processes
[４] カーネギーメロン大学、日本語版CMMI1.3、2012年5月
[５] 日科技連、ソフトウェアの総合的品質管理、1999年6月発行
[６] IIBA日本支部、BABOK2.0日本語版、2009年12月発行
[７] PMI日本支部、 PMBOKRガイド第3版、2005年2月発行
[８] 情報サービス産業協会、要求工学知識体系(REBOK) 第１版、2011年7月発行

話の分かる優秀なコンサルタントをお探しですか？

PR広告！一流コンサルタントに3.85万（税込み）〜WEB相談できる！【コンパスシェア】

DXに強いシステム開発会社をお探しですか？

PR広告！システム開発業者を完全無料でご紹介します！【EMEAO!】

PR広告！おいしい水を水道水から【Locca】

【PR広告】会社や上司へ連絡不要！【退職代行ガーディアン】

■１２０社１０００人以上が受講！！

１．研修・オンライン講座　　　　　　
　　経験と勘だけのレビューから脱却する！レビューを体系的に学び、成果につなげる！　　　　　　　　　　
　　『【リスク指向】超ドキュメントレビュー実践法』
　　※実務ですぐに使えるチェックリストを使用した演習付き！
　　
　　危険予知能力を高め、リスクを見つける！
　　『100の失敗事例に学ぶ！企業システム戦略の危険予知訓練』
　　※すぐに実践で役立つ100の失敗事例による危険予知訓練の演習付き！

■便利な道具箱

■自動でしゃべるパワーポイント（VBAマクロ）
　ノート欄のテキストを音声合成エンジンが読み上げ、画面も自動で切り替わるVBAマクロ！
音声を録音するよりとっても楽です。失敗して録音をやり直す手間もなく、部分的な変更も楽々です。

■簡易日程計算（Excel/VBA)
　製品構成展開されたツリーデータを使用して、製品を期日までに組立完成させるために必要な日程を計算するExcel/VBA！

■簡易原価積上げ計算（Excel/VBA)
　製品構成展開されたツリーデータを使用して、製品を構成する部材の原価を積上げ、製品原価を計算するExcel/VBA！