体系的な要件管理が求められる背景には
システムの現場にいれば、誰しも一度は「ドキュメントではなくソースコードを見てくれ」と言われた経験があるかもしれない。実際、要件定義や設計といった上流フェーズのドキュメントと、実装されたプログラムやシステムとの整合性が必ずしも取れていないケースは珍しくない。こうした食い違いに、ある意味、エンジニアが人力で対応してきたのだ。
ところが近年、こうした食い違いを許容できない開発プロジェクトが増えている。そこで必要になるのは、体系的な要件管理である。すなわち、要件定義から、設計、開発、テスト、さらには運用に至るすべてのフェーズで作成されたドキュメントやコードが一貫性のある状態で管理され、かつその対応をトレースできることが求められているのだ。
状況は組み込み系システムでもエンタープライズ系システムでも同様だが、背景は若干異なる。まずは、車載システムに代表される組み込み系で、体系的な要件管理が必要になってきた背景を説明しよう。
日本のメーカーでは従来、現場でのすり合わせによる品質重視の開発手法が、開発文書などの管理よりも重視されてきた。重要なのは開発ドキュメントではなく、実際に出来上がったもの、という思想だ。そこには、日本メーカー特有の事情もある。メーカーにおいて当初、組み込み系システムの開発を担っていたのは、独学でプログラミング言語を身に付けたハードウェアや設計回路のエンジニアである。
彼らは、性能を重視する一方で、ソースコードの可読性に対する意識は十分でなく、コーディングしたエンジニア本人にしかメンテナンスできないシステムも少なくなかった。つまり、システムのブラックボックス化が進んでいたのだ。それでも日本製品の品質は高く、大きな問題はあまり起こらなかったのだが、ここにきて大きく事情が変わった。リコール問題などを受けて、2011年、消費者が直接利用する製品としては初めてとなる乗用車を対象とした機能安全規格（ISO26262）が発行され、開発プロセス全体で安全を保証する管理が問われるようになったのだ。
一方、エンタープライズ系では、ここ20年の間に、システムが大規模化・複雑化・高機能化し、1社での開発が難しくなった。その結果、海外も含めた複数のベンダーが開発に従事するようになり、またオープンソースソフトウェアの利用も増えた。
社内であれば、曖昧な表現でも要件や設計の意図は伝わるが、社外や海外のベンダーに対しては難しい。曖昧さを排除すれば、管理するべきドキュメントの量も膨大となる。オープンソースソフトウェアもまた安易に利用するとブラックボックス化する。中身を用途に応じてドキュメント化しなくてはならない。いずれも、要件管理を難しくする要因だ。
現在、エンタープライズ系システムのトラブルが社会に及ぼす影響度は年々増大する一方だ。トラブル防止には保守性向上が必須となるため、体系的な要件管理に対する要求も今後、増すだろう。
日本独自のALMツールの開発がスタートした経緯
体系的な要件管理が求められているなかで、現在急速に普及しつつあるのがALM（Application Lifecycle Management）ツールだ。ALMツールは、システムの要件定義、設計、実装、テスト、運用というフェーズ間の連携を強化することで、ソフトウェア開発の生産性や品質、影響分析やリスク分析の精度などを向上させる。
ALMツールは、以前から厳密な要件管理が求められてきた欧米で発達してきた。そのため体系的な要件管理が求められた多くの日本企業は当初、欧米発のツールを利用したが、利用が進むにつれて、日本の開発スタイルに合わない点が目立ってきた。
ALMツールの開発に携わってきたSCSK ビジネスソリューション事業部門 AMO第二事業本部 新ビジネス推進室 第二課長 山本 敏博（右）、同課 横田 浩行（左）。
欧米の大規模システム開発は、「要件定義→基本設計→詳細設計→実装→テスト」というウオーターフォールモデルに沿って上流から下流へと進められることがほとんどだ。一方、日本では、上流工程で要件や設計はある程度固めるものの、下流工程で仕様を変更しながら開発することが多く、開発が終わってからそこでの知見を上流工程にフィードバックすることも珍しくない。
また、開発標準が重視される欧米発のALMツールは、「要件定義や設計にツールの標準フォームや標準プロセスを使用する」ことを前提としている。一方、日本の開発現場では、技術者が現場ごとに使いやすいフォームを自作していた。つまり、要件定義や設計のドキュメントがWord、Excel、PowerPointなど多様なツールで作成されてきたのだ。
開発スタイルを無理に変更しようとすれば、現場の反発を招きかねない。また、既存のドキュメントをALMツール独自の標準フォームで作り直すのは膨大な手間だ。こうした状況から、日本の開発現場に合ったALMツールに対する要望が、開発を外部から支援するITベンダーにも寄せられるようになる。そこで開発された日本発のALMツールが、SCSKの「ConTrack（コントラック）」だ。
日本発のALMツールに求められるもの
ConTrackの開発にあたっては、より使いやすいツールを求める開発現場のさまざまな課題が吸い上げられた。
日本では、要件定義や設計のドキュメントは、ALMツールではなく、Word、Excel、PowerPointなどによる作成が一般的となっている。ConTrackは、Wordファイルではアウトラインや章番号などを、またExcelファイルではシートごとのフォーマットを自動認識することで、登録したファイルの見出し情報をツールの画面上で確認可能だ。いずれのファイルも、ツールへのドラッグ＆ドロップで容易に登録可能である。
要件定義、設計、開発、テストの各フェーズで作成されるドキュメントやコード間の関連付けは、画面上で線を結ぶことによって可能になっている。欧米のALMツールでは直観的な関連付けが難しかったという現場の要望を受けて、あえてWebアプリではなくクライアントアプリを採用することで、GUIの自由度を高くしたのだ。
ALMツールの機能はトレーサビリティ管理が中心となるが、変更管理・構成管理と連携させたいという現場のニーズも高かった。そのためConTrackでは、変更管理にプロジェクト管理ソフトウェアであるRedmineを、構成管理にはバージョン管理システムであるSubversionを採用し、ツール間での連携を図っている。いずれのアプリケーションも、日本発のALMツールの要望が高かった車載機器の業界で普及していたため採用された。
トレーサビリティ情報の登録方法には、①画面上でのドラッグ＆ドロップ、②トレーサビリティマトリクスの作成、③トレーサビリティIDを挿入して自動登録、④CSVにエクスポートしてExcelで修正し再度インポートの4通りがある。
また、要件や設計の仕様変更によるリスクを把握したいとのニーズに対しては、10段階でリスクの大きさを表示できるようにしている。ASIL（Automotive Safety Integrity Level）やリスクマネジメントに対応するため、画面上で4段階や3段階に定義し直すことも可能だ。
特に運用フェーズでは、新機能の追加開発やシステム改修などにより仕様変更が発生する。仕様変更が既存システムのどの部分に影響を与えるかを見極める「影響分析」で漏れがあれば、手戻りが発生する。人手による分析ではどうしても漏れが発生し、全件テストが必要になるため、膨大な工数がかかる。
ConTrackを使った体系的な要件管理で正確な影響分析が可能になれば、ピンポイントでテストを実施でき、工数を大幅に削減できる。また、影響分析の結果、全件テストが必要だとわかれば、現場の納得感が得られるだろう。
直観的で使いやすいConTrackの操作画面イメージ。一目でシステム全体の影響範囲が把握できる。
ConTrackでは、サーバー上にあるファイルがクライアントPCと同期する。サーバーにアクセスが集中するとファイル変更などの操作に手間取るためだ。同期方式であれば、容量が大きいWord、Excel、PowerPointなどのファイルも軽快に扱える。
ALMツールのユーザー企業には、現在、自動車メーカーや金融機関とそのシステム子会社が多い。また、薬事法改正の影響で医療ロボットもトレーサビリティ管理の対象になった医療機器業界、システムの耐用年数が長い電力業界や鉄道業界などでも、ALMツールに注目する企業が増えている。
特に、金融自由化で銀行と証券会社の系列化が進む大手金融機関、経営環境が厳しい地方銀行では、今後、システム統合が増えていくだろう。規模が大きく、システムトラブルが信頼毀損につながる金融システムでは、要件管理だけでなく、影響分析やリスク分析などにおけるALMツールのニーズは高い。
ConTrackは現在Ver2.2が提供されている。今後もユーザー企業の課題やニーズなどをヒアリングし、さらなるツールのバージョンアップに役立てるそうだ。システムの要件定義や設計のドキュメント管理だけでなく、ドキュメントとソースコードの関係性管理やトレーサビリティ、さらには仕様変更における影響分析やリスク分析の精度向上にもつながるConTrackのようなALMツールの導入を検討する企業は、今後さらに増えていくのではないだろうか。
