開発手法と品質管理について

現在NTTではIOWN（Innovative Optical and Wireless Network）に関する研究開発に取り組んでおります。IOWNとは、光を中心とした革新的技術を活用する高速大容量のネットワーク・情報処理基盤です。IOWNは2030年代に本格的な展開を目指して開発中ですが、このようなライフラインに関わるサービスは、様々な方に安心感を持って利用して頂けるように品質を担保する必要があります。
NICはIOWNの中でネットワークに関わる開発に多く携わっており、通信インフラの要となるような先進技術を世の中に出していくポジションを担っております。そこで本稿では、一般的な開発手法や品質管理に関する概要と、NICにおいてどのような品質管理を実施しているかということについて簡単に説明します。

ウォーターフォールはトップダウン型の開発アプローチとして、高級言語によるソフトウェア開発（特にC言語誕生以降）が主流になった1960～1970年代から現在に至るまで様々な分野で利用されています。近年は開発環境の変化もあり、アジャイルによる開発手法が大きく注目されていますが、まだ通信インフラのような大規模開発ではウォーターフォールを採用する企業が多いのではないでしょうか。
ウォーターフォールというのは下図のように上から下へ開発の各工程が流れていくモデルになります。ただし、どの工程にどのようなプロセスが入るのかは厳密に決められているわけではないので、開発現場によって定義が異なることがあります。図は一つの例として掲載しています。

ウォーターフォールの利点は、いわゆる上流にあたる要件定義や設計の工程において、開発する対象を早期に明確化し開発状況を評価することができるという点にあります。特にプロジェクトのマネージメント面や品質管理の面からこの「開発状況の評価がしやすい」という部分は非常に重要です。評価がしやすいということは、お客様や開発責任者に対して開発状況を説明しやすいことに繋がりますので、インフラのようにコストや期間がかかる比較的大規模な開発に適しています。
一方、ウォーターフォールの欠点としてはよく言われているように柔軟性に乏しい、すなわち下流工程で問題があった際の手戻りが大きいということです。隣接する工程内で問題を収束できればよいのですが、要件の変更に至るケースでは関連するほぼ全ての工程が見直しになり膨大なコストや期間がかかってしまうことがあります。

ウォーターフォールの工程は大きく、要件定義から設計までの「上流工程」と、製造から試験までの「下流工程」に分けることができます。

商用のサービスを開発する場合には、まずお客様が実現したい「サービス仕様」を固める必要があります。要件定義はこのサービス仕様のうち「システムで作る必要がある要件・機能を定義する工程」になります。

外部設計とも言われますが、要件定義に従って各機能が持つ外部のふるまいを設計する工程です。外部システムとのインターフェースや画面等のユーザーインターフェースを含む各機能の処理フローの設計が中心になります。

内部設計とも言われますが、基本設計に引き続いて各機能の内部のふるまいを設計する工程です。大規模開発では、この工程を各機能単位の内部設計と、それを更に詳細化した各モジュール/関数単位の内部設計の二つの工程に分割することもあります。

定められた言語による設計内容のコーディング作業になります。

試験工程のうち、各モジュール/関数単位の試験です。基本的にはホワイトボックス試験と呼ばれており、製造コードの走行網羅性（全てのコードがきちんと動くか）を確認する工程で、近年ではツールを用いて実施することがほとんどです。

試験工程のうち、各機能のふるまいを試験する工程です。各機能の呼び出し関係や受け渡しされるデータの網羅性を確認する試験で、機能外部からの試験が中心なので厳密にはブラックボックスに近い試験です。開発対象システム以外からの外部入力は模擬的に実施します。

全ての内部機能と全ての外部システムが接続された状態で、開発システム全体のふるまいを試験する工程です。基本的にブラックボックス試験となります。また大規模開発ではこの工程もいくつかに分割するケースがあります。

定義が難しいのが受入試験です。受入試験は要件定義の確認をする工程として紹介されていることがあります。しかし一般的な開発では、総合試験までの工程で全ての試験を完了することが多く、「受入」は開発側ではなくユーザー側の開発結果の確認工程（＝欠陥があってはならない工程）という見方もありますので、ここでは開発工程から外してあります。

ウォーターフォールでは設計から製造までが「欠陥の盛込」工程であり、試験が「欠陥の抽出」工程となります。設計では設計書品質、製造では製造品質を定量的に測定します。ウォーターフォールにおける品質測定の基本的な考え方は「人が作成したものには一定程度の欠陥がある（はず）」ということです。したがって、開発規模に応じた一定の密度で欠陥を発見できているかを評価します。欠陥があまりにも発見できない、もしくは逆に多すぎる場合にはどちらにしても「品質に問題がある」と捉えて原因を追究するアクションを行う必要があります。以下に設計と試験工程での品質管理の内容を記載します。

設計工程では設計書を作成することになりますので、設計書の品質を管理します。設計書の作成後にレビューを行い、ページ数（＝規模）、レビューコメント数、修正数（＝欠陥）等をパラメーターとしてコメント密度や修正密度を測定します。設計書自体のレビューや品質測定は、後工程ではなく同じ工程の中で実施します。ドキュメントにおける記載ミス等の欠陥の盛込みを同じ工程で解消することで下流工程への影響を抑制する必要があるからです（「設計書確認工程」が別途明示的にあるべきですが、通常同一行程に内包されます）。したがって、試験工程は「実際に製造してからでないとわからない欠陥」の発見工程となることが理想的です。

製造品質は試験工程ごとにコード行数（=規模）、試験数、バグ数（＝欠陥）等をパラメーターとして試験密度やバグ密度を測定することで品質管理を行います。欠陥を盛り込んだのが上流のどの工程にあたるのかを明確にする必要があります。欠陥の盛込みには製造工程での実装ミスや設計工程の設計ミスといった原因がありますが、前工程になればなるほど、手戻りによる影響範囲が大きくなり修正コストが高くなってしまいます。これは先にお話ししたウォーターフォールの欠点の一つです。
欠陥の盛込みとその抽出の対応関係は一般に下図のようなV字モデルを利用して説明されることが多いと思います。上流工程で欠陥を盛り込んだ内容を下流工程で確認する際の対応関係になります。

ただし、実際には以下の図のように隣接する上流工程の一部をまとめて試験することが多いのではないかと思います。これは各工程の定義にも左右されますが、製造工程も欠陥の盛込み工程の一部であることや、同じ設計工程であっても定義する内容により必要となる試験環境が異なること等が理由です。

NICの開発では開発手法としてウォーターフォールを採用するケースが多いです。各開発において先に挙げたような品質管理をきちんと実施し一定の品質を担保するとともに、インフラ系の開発については、長い年月で培った通信インフラ開発に関する試験項目・試験内容の工夫や品質評価のノウハウを活用して開発を進めています。
それに加えて、様々なシステム障害事例の水平展開により類似事例の再発防止に努めることや、試験目標や試験項目の精査、開発諸元の達成状況の明確化により利用時の不要なトラブルを防止すること等、品質管理に関わる様々な取り組みにより、研究開発の段階から安全性の高い開発を実施しております。

昨今ウォーターフォール以外の開発手法としてアジャイル開発が登場していますが、品質に関する考え方が大きく異なります。ウォーターフォールではこれまで説明してきた通り、明確な仕様を元に外部の人間にも分かりやすい定量的な品質評価が可能なため、通信インフラのような大規模開発に多く利用されてきました。一方アジャイルでは、主に開発プロセスの確からしさや要求された仕様の実現の程度によって品質評価を行うため、要求の不確定度が高く、スピードを求められる開発分野に対応する開発手法であると言えます。
今後は通信インフラの世界でもアジャイルによるスピード感のある開発と市場投入が求められるケースが増えてくると想定されます。そのためアジャイル開発に対応する新たな品質測定手法を検討することが必要になってきます。

NTTグループでは、多くのグループ会社が国内外で生活に密着するサービスを提供しています。開発品質の問題を起因としてサービスに支障が出ることのないように、今後も通信インフラの研究開発における品質管理を継続実施し、お客様にIOWNを含む各種サービスを将来にわたって安心してご利用頂けるように努めて参ります。