開発標準とは何か

　システム開発やソフトウェア開発は、開発者の経験や能力に品質や生産性が大きく影響する属人的な作業です。しかし、昨今の大規模化、複雑化した開発では、多人数の開発要員が同時に作業を進行するため、作業手順や成果物に何らかの基準を定めなければ、成果物の品質や整合性を確保することができません。

　つまり、開発標準とは、大規模化、複雑化するシステム開発において、ソフトウェア開発特有の属人的なリスクを抑制し、品質確保や生産性向上を図る取り組みであると言えます。

　それでは開発標準とは、どのような事柄を規定したものなのでしょうか？ たとえば、国内で最も知名度が高い開発プロセス標準と言えるのは、情報処理推進機構（IPA）が提唱する「共通フレーム」です。システム開発の構想段階から開発、運用、保守、廃棄に至るまでのライフサイクル全般を通じて必要な作業項目が包括的に規定されています。

　ただし、共通フレームは、“日本において、ソフトウェア開発に関係する人々（利害関係者）が「同じ言葉」で話すことができるようにする”ことを目的に策定された枠組みです。また、ウォーターフォールやアジャイルなどのさまざまな開発モデルや実装方式でも利用できるように汎用性を持たせるために、作成物の種類や書式などは規定していません。

　したがって、共通フレームだけでは、開発標準としては不完全です。そのため、IPAでは共通フレームをそのまま適用するのではなく、組織（企業）内のIT環境や業務内容、技術的な特性に合わせて作業項目の取捨選択や作業手順や方法、成果物の種類や書式等を拡張するテーラリング（修整）を推奨しています。


　この共通フレームは、「ISO/IEC 12207 ソフトウェアライフサイクルプロセス」と「ISO/IEC 15288システムサイクルプロセス」を統合し、日本独自の拡張を行っているため、国際標準に準拠した枠組みです。しかし、開発標準として用いるには、企業内のIT環境に合わせた標準化（＝レベル3）および、業務内容や技術的な特性に合わせて作業方法や成果物の定義を拡張する（＝レベル4）、テーラリングを行う必要があります。

　ただし、業務特性に適した設計手法の使い分けや、開発モデルや実装方式などの技術特性に合わせて適切な成果物の定義を行うには、さまざまな開発方法論や実装技術に精通していなければ極めて困難です。実際に、IT導入を外部委託している発注者では、レベル3およびレベル4に相当にする開発標準を定義していることは滅多にありません。

　そのため、実際のシステム開発では、ITベンダーの社内標準として策定された開発標準が用いられているのです。

ITベンダーが開発標準を策定する理由

　開発標準は、すべてのITベンダーが策定しているわけではなく、中堅クラス以上のシステムインテグレータから社内標準として策定している場合が多くなります。これには、いくつか理由があります。

　1つ目は、開発標準本来の目的である、ソフトウェア開発特有の属人的なリスクの抑止です。開発案件の規模が大きくなれば、多くの開発要員が必要になります。さらに自社の技術者だけで対応できなければパートナーに参画してもらい、開発要員を確保する必要があります。しかし、開発要員の増加は、属人的なリスクの増大につながるため、品質や生産性の確保が難しくなります。

　もう1つの要因は、元請け案件の増加です。元請け案件はITベンダーにとって、売上規模が大きく、利益を上げるチャンスがありますが、相応のリスクもあります。進捗遅延に追加要員を大量投入すれば赤字となり、納期が遅れれば発注者からの支払いが遅れるなど、元請け案件のシステム開発の失敗は、ITベンダーの会社経営にさえ影響を与えるのです。

　そのため、開発標準の導入は、元請け案件を受注する機会が多くなる中堅クラス以上のシステムインテグレータには、不可欠な取り組みであると言えます。


　上図は、一般的な開発標準の概略を例示したものですが、開発にウォーターフォールモデルに採用している場合は、まず開発工程の基準が定義されます。さらにそれぞれの開発工程の作業項目や方法、開発全体のマネジメント基準、再利用可能な標準ツールから構成されています。

　ITベンダーの開発標準は、ITベンダー内で蓄積された知見に加えて、UMLなどのモデリング言語やPMBOKなどのプロジェクトマジメントに関する知識体系など、さまざまなソフトウェア開発に関する方法論をもとに作成されており、ITベンダーの知識資産（ナレッジ）とも呼べるものです。

　さらに大手システムインテグレータでは、専任部署を設けて新しい技術に対応した開発標準の拡張や支援ツールの充実を図るなど、多くの時間と人員をかけて開発標準の維持管理が行われています。膨大な数の開発案件が、開発標準によって品質や生産性が改善されれば、会社全体で大きな成果をあげることができます。大手特有のスケールメリットを活かした取り組みです。

　そのため、大手システムインテグレータには、非常に充実した開発標準を策定している傾向があります。たとえば、ある大手ITベンダーでは、設計書からソースコードを自動生成する標準ツールを自社開発しています。ツールによる自動化は、属人性そのものの排除につながるため、品質確保や効率化に大きな効果が期待できます。

品質や生産性を確保できない開発標準とは

　ITベンダーが開発標準の導入する目的が、システム開発の失敗を回避することにあるのならば、発注者としても歓迎すべき取り組みでしょう。しかし、筆者が経験したプロジェクトでは、ITベンダーの開発標準が発注者の期待する品質や生産性の確保することができないケースを数多く目にしてきました。

品質を確保できない終了基準

　たとえば、あるITベンダーのプロジェクトマネージャより、各工程の終了基準（クライテリア）について提案がありました。終了基準は、各工程の終了時点で到達すべき目標であり、次工程の開始可否を判断したり、申し送り作業をチェックしたりするために利用します。

　プロジェクトマネジメントの鉄則として、工程をさかのぼる手戻りはできる限り減らす必要があります。そのため、特に長期間のプロジェクトでは、各工程の終了基準を中間マイルストーンとして設定して達成状態を共有することで、発注者とITベンダーの認識齟齬を防止し、工程間の手戻りを減らす効果があります。

　ITベンダーの提案は理に適っているため、発注担当者も同意して、工程完了時に終了基準を確認することを申し合わせて、プロジェクトをスタートしました。ちなみに、筆者が担当したプロジェクトでも、終了基準を採用した経験があり、確認項目は次のような内容をイメージしていました。


　たとえば、要件定義であれば、上記のように終了基準を定義することで、要件定義の実施内容や作成資料、要件定義が終了した時点の達成状況や品質基準を確認できるため、発注者との認識齟齬を防ぐことができます。一方、ITベンダーからは、次のような終了基準が提示されました。


　上記の終了基準では、それぞれの成果物が確認できず、達成状況や品質基準も示されていないため、要件定義工程の実施内容や達成状況を確認できません。ITベンダーに対して、終了基準の見直しを要請しましたが、これが当社の標準プロセスであり、この書面に発注者の押印をいただけないと、次工程が着手できないとの返答がありました。

　つまり、ITベンダーの終了基準は、発注者が承認したことを示す証跡であり、ITベンダーの社内プロセスに必要な書面でしかありませんでした。発注者は、具体的な作業内容や達成状況を確認できる終了基準でなければ押印はできないと回答し、ITベンダーの主張を受け入れませんでした。

運用されない標準プロセス

　外部委託型のシステム開発では、課題管理、ToDo管理、リスク管理など、さまざまな管理台帳を運用します。利用頻度の高い台帳は、開発標準の標準ツールとして整備されており、ITベンダーから提供されることも珍しくありません。

　レビュー管理表もそのひとつです。上流工程の成果物は、大半がドキュメントとなるため、ドキュメントレビュー時の指摘事項を記録し、対応状況を管理することで、ドキュメントの品質管理に利用します。あるプロジェクトでもITベンダーからレビュー管理表が提供され、ドキュメントのレビューで利用することになりました。

　提供されたレビュー管理表の指摘区分は、「仕様不具合」、「記述不足」、「誤字脱字」、「体裁誤り」、「記載ルール違反」、「指摘不備」、「仕様確認」、「仕様変更」など、十数種類の分類が設けられており、レビュー担当者から指摘区分の判断基準がわからないと相談がありました。

　筆者の経験では、これほど多くの分類を運用したことがなく、分類の意図が解らなかったため、ITベンダーのプロジェクトマネージャに相談したところ、あまり意味のない分類なので記入不要との回答がありました。回答通り指摘区分を記入しないままレビューを続行しましたが、全体的にドキュメント品質が低く、指摘事項が数千件を越える事態となりました。

　品質状況に危惧した発注者から、ITベンダーに改善を申し入れた結果、ベテランのプロジェクトマネージャを参画させて、品質問題の解決を取り組むことになりました。プロジェクトマネージャが最初に着手したことは、品質問題の傾向を定量的に分析し、品質問題の発生原因と品質改善に必要な作業工数を算出し、対応スケジュールを立案することでした。

　プロジェクトマネージャの問題解決手順は、品質問題を正確に把握した上で対策を立案するもので、それ自体には問題がありませんが、ここでレビュー管理表には、指摘事項が記入されていないことが問題となります。しばらくして、すべての作業を一時中断して、レビュー管理表の読み合わせを行いたいと申し入れがありました。

　発注者としては、同じ作業をやり直すようなものですから、あまり釈然としませんが、プロジェクトマネージャからは、これ以外の対応方法がないとの説明があり、結局対応することとなりました。しかし、指摘事項が膨大な件数となっていため、レビュー管理表の読み合わせに約1ヶ月の期間が費やされることになりました 。

　今回の無駄な作業は、指摘区分を記入していれば防ぐことができたはずです。しかし、混乱を招いた根本的な原因は、ITベンダーの標準台帳に実際の作業に適さない分類が定義されていたことにあります。十数種類もの分類を設けた意図は、現場でのテーラリングを想定していたのか、ITベンダーの品質メトリクスとして必要だったのか解りませんが、ITベンダーのプロジェクトマネージャが意図を理解していなかったことだけはハッキリしています。

形骸化した品質基準

　RFP（提案依頼書）を用いたITベンダーの選定では、ITベンダーに対してシステム開発時の品質管理能力の提示を求めることが珍しくありませんが、システムに不具合を生じせる原因には、さまざまな要素が関係するため、ITベンダーが自社の品質管理能力を客観的に証明することは容易ではありません。

　一昔前なら、“当社は「ISO9001 品質マネジメントシステム」の認証を取得しております”といったアピールを行うITベンダーもいましたが、最近の提案ではほとんど見かけなくなりましました。代わりに最近は、品質管理能力を示すため、自社の開発標準を提示するITベンダーを見かけます。

　あるプロジェクトのRFPにも、品質管理能力に関する説明を求める依頼事項があり、ITベンダーの提案では、自社の開発標準に定義されたテスト工程別のソースコード1Kステップ数あたりのテストケース数の提示がありました。これはテスト密度と呼ばれる指標で、一定のソースコード量に対して適正とされるテストケース数を示す値です。

　目標テストケース数を確認したところ、結合テスト、総合テストともに問題の無い値でした。なお、同ITベンダーは、これまで現行システムの保守を行ってきた実績も考慮され、正式発注が決まりました。発注後は、比較的スムーズにプロジェクトが進行しましたが、総合テストが始まった途端に品質問題が発生しました。

　総合テストは、発注側のシステム担当者も参画して、実際の業務データを利用してテストが行われましたが、正常系の操作が一通り確認できない品質であることが判明しました。緊急性の高いプロジェクト課題として、発注側体制を増員して、テストケースの見直しを行い、不具合の洗い出しと修正作業を実施しました。

　対応が早かったこともあり、リリース・スケジュールを守ることができました。リリース後、品質問題の発生原因の検証することになり、ITベンダーが作成した結合テストのテストケースを確認することになりましたが、業務データのバリエーションが十分に考慮されておらず、テストケースの質に問題があることがわかりました。

　さらに検証を進めていくと、テストケース数自体もかなり少なかったことが解りました。提案時にテスト密度の説明を受けていたので、テストケースの作成担当者に理由を確認したところ、テスト密度の評価はおろか、自社の開発標準に、テスト密度の定義があること自体を理解していませんでした。

【次ページ】攻めのITにつなげる発注者の開発標準