【開発生産性カンファレンス 2025】開発の手戻りを防ぐ！要求管理から考える開発生産性

品質改善の「鍵」は超上流にあり

株式会社ベリサーブは2001年に設立され、主にソフトウェアのテスティングサービスを提供しています。システム開発の品質向上に寄与するサービス・ソリューションを数多く取り扱っている会社です。

最近は「ベリサーブ＝テストの会社」というイメージをお持ちの方が多いのですが、私たちの事業領域はテスティングサービスだけではありません。品質向上に関わる全領域を事業領域として再定義しており、今日ご紹介する「ConTrack」も新しい事業の一環として取り組んでいます。

売上については、ここ5年間堅調に推移しています。特徴的なのは、売上の約半分が自動車関連の領域であることです。製品の品質や信頼性が極めて重要な領域でも、我々の技術力が認められていると認識しています。

会社紹介は以上にして、本題に入ります。まずは、なぜ上流工程が大事なのかということについて認識を合わせたいと思います。

まず、IPAが2023年に実施したアンケート結果をご紹介します。ユーザー企業、ベンダー企業、個人という3つのセグメントで、システム開発においてどこに課題があるかを質問したものです。

結果を見ると、どのセグメントでも「要件定義/管理」が上位に来ています。ユーザー企業では2位で47％、ベンダー企業でも2位で53％、個人では3位で49％となっており、多くの方が要件定義に課題をお持ちだということが分かります。



要件定義、つまり要求定義は最も上流の工程です。要求の定義誤りや定義漏れといった不具合は、基本設計や詳細設計、結合テストや単体テストといった下流工程では見つけることが困難です。

発覚するのは、良くてシステムテストや受け入れテスト、最悪の場合はカットオーバー後やプロダクトリリース後になります。後工程になればなるほど手戻りコストは大きくなり、要求定義工程で埋め込んだ欠陥は非常に大きなインパクトを持ちます。納期遅延や契約不履行といった大きなトラブルにつながる可能性もあります。

要求定義工程で誤りを犯しやすいのには理由があります。この工程では複数の部門や複数の組織・企業が関わることが多く、それぞれ異なるバックグラウンドや前提条件を持った中でコミュニケーションを取る必要があります。

そのため、ミスコミュニケーションが発生しやすく、他の工程よりも不具合や欠陥を埋め込む確率が高くなります。情報システム開発、自動車の制御ECU開発、産業機械、量産品開発など、いずれのシステム開発でも複数の部門・企業が関わるため、ミスコミュニケーションのリスクは大きいのです。

では、これだけリスクが大きい要求定義が、きちんと管理されているのでしょうか。IPAのアンケート結果を見ると、「仕様書で定義して要求管理している」「Excelで管理している」など、レガシーな方法で管理されているケースが多数を占めています。

「ツールを使っている」という回答もありますが、詳しく見ると要求管理専用ツールではなく、タスク管理ツールで代用しているケースが多いのが実情です。これだけリスクが大きいにもかかわらず、専用ツールを使った適切な管理があまり行われていないことが分かります。



このように、要求定義工程で埋め込んだ欠陥を見つけるのは後工程になりがちで、修正コストが非常に大きくなります。修正コストが大きい上に、ミスコミュニケーションにより欠陥を埋め込みやすい。それにもかかわらず、適切な管理が行いきれていないという状況にあります。

さまざまな技術や手法が提唱されていて、MBSEやテストファースト、アジャイルなどもこういった問題を解決するための手法といわれていますが、今日はその数多くある取り組みの中から、この要求管理にフォーカスして話します。

要求管理の手法とConTrack

では、この要求管理がどのように要求定義の工程に寄与していくのかから、話します。

要求管理の意義は、主に「一貫性の確保」「網羅性の確認」「変更時の影響分析」の3つがあります。

一貫性の確保は、要求仕様で定義されたものが設計・ソースコードに正しく落とし込まれることを保証します。要求通りに設計を起こしていかないと、要求の実装誤りになってしまいます。要求管理を実施していくと、要求とそれに対応する設計の成果物を簡単に見比べられるようになり、ステークホルダー間で合意形成を図りながら開発を進めることができます。

網羅性ついても確認する必要があります。ですが、管理ツールを使わずに開発していると、大体どのプロジェクトでも2〜3％の要求で実装漏れが発生しており、規模が大きくなればなるほど影響が大きくなっていることが分かります。

変更時の影響分析では、要求変更や設計変更が発生した際に、その影響を抜け漏れなく対応していかないとデグレードにつながる可能性があります。要求管理により関連する項目同士がつながっているので、どこに影響が出るのかを抜け漏れなく対応し、デグレードなく開発を進めることができます。

この3つの意義を実現するためのツールとして、弊社で扱っているConTrackという製品があります。ConTrackは、要求管理、構成管理、変更管理を含めて、システム開発におけるドキュメント管理の仕組みをひととおり持っているツールです。



特徴的なのが文書解析エンジンです。文書ファイルやスプレッドシートで作られたドキュメントを、皆さんがお持ちの資産を大きく変更することなく、そのままConTrackに取り入れることができます。その際に章、節、項目といった形で分解し、項目の粒度でどの要求がどの設計で実現されているのかを線で結んで可視化していくツールです。

ConTrackがドキュメントの目次代わりになります。大規模なプロジェクトでは、文書ファイルが100ページを超えたり、スプレッドシートのシートが非常に多くあったりして、目的の項目を探すのに時間がかかります。ConTrackではツリーを展開していく感覚で項目を選び、ダイレクトにそのファイルの該当箇所に飛んでいくことができます。

実際の事例では、ConTrackを使うことでデザインレビューの工数を半減させました。これは、デザインレビュー時間の半分がドキュメント探しだったことを意味します。スキルを持った方の時間をより製品やシステムの価値向上のための活動に充てることができるようになったのです。



ConTrackの文書解析エンジンは、強力な差分チェック機能を持っています。ドキュメント更新時に、どの項目が変わったのか、どのように変化したのかを自動的に抽出できます。

その変化点分析結果を起点に、インパクト分析画面では他の工程への影響範囲まで表示します。従来はベテランの方が頭の中で影響分析していましたが、ConTrackを使えばどなたでも一定のレベルで影響分析ができます。文字の差分だけでなく、絵の差分も色枠で表示し、Word、Excel、PowerPoint、PDFといったさまざまなフォーマットで作成されたドキュメントの差分を簡単に確認できます。



また、プロジェクトの状況に合わせて最適なトレース作成方法を選べます。ID/タグが埋め込まれているドキュメントであれば、ConTrackに取り込むことで自動的にトレースを貼ります。IDタグが管理されていないプロジェクトでは、画面上でドラッグアンドドロップしながら線を引いたり、項目をダブルクリックやスペースキーで関連付けたりできます。

実際のドキュメントの状況に合わせて最適な方法を選ぶことで、トレース作成のための工数増分を抑えられるのです。

トレーサビリティ管理ツール「ConTrack」利用事例

ここまで要求管理の課題やConTrackの機能を話しました。ここからは実際の事例を2つご紹介します。

事例1：インフラ系企業の基幹システム更改プロジェクト

一つ目はインフラ系企業での基幹システム更改プロジェクトです。エンドユーザーが要求仕様を作成し、SIerが基本設計工程から後を担当するという形態でした。

かなり大規模なシステムで、要求仕様も非常にボリューミーでした。エンドユーザー側でも要求が基本設計で網羅されているかレビューをしているものの、数が多過ぎてチェックしきれない状況でした。

ConTrack導入前は、2〜3％程度の要求実装漏れが発生していました。また、プロジェクト進行中の要求変更・設計変更で影響範囲の抜け漏れが発生し、修正漏れによるデグレードが多発していました。

これらは要求に関連する問題なので、発覚するのはカットオーバー直前です。そのため工期遅延の原因となり、数カ月から年単位の遅延もあり得る危険な状態だったと伺っています。



第2フェーズ以降でConTrackを使用し、要求仕様と基本設計をつなげながら開発を進めました。基本設計の工程進行中に、基本設計書が1個できるたびに要求の実装漏れを確認し、漏れが見つかった時点で即座に基本設計書を修正するという取り組みを行いました。

2〜3％の実装漏れは依然として発生しましたが、ツールで早期に発見できたため、開発工程終盤での発覚による時間のロスを防げました。またデグレードについても、PMの方から「かなり減った」という感想を頂いています。これによって、第2フェーズ以降は工期遅延をかなり抑えることができました。

事例2：自動車制御システム（ECU）開発プロジェクト

二つ目は自動車の制御システム（ECU）開発の事例です。完成車メーカーから要求仕様がPDFで部品メーカーに提示され、部品メーカーが設計を行うという役割分担でした。

要求仕様は第1版で完全にフィックスするわけではなく、開発中に第1版、第2版、第3版と更新されます。変更箇所は赤字や取り消し線で表現されますが、これを人が行うため抜け漏れが発生していました。

自動車メーカーからすると、赤字表示は「おまけ」という位置付けで、漏れがあっても部品メーカーの責任とされる厳しい状況でした。部品メーカー側でも差分チェックを行いますが、100ページほどもある仕様書を1行ずつ確認するため、やはり人的ミスが発生していました。



そこで部品メーカー側でConTrackを導入し、文字の差分チェックや絵の差分チェック機能を活用しました。従来は人数をかけて一生懸命変更箇所を探していましたが、ConTrackなら数分で差分チェック結果が返ってきます。

従来のやり方に比べて圧倒的にコスト削減とミス防止につなげることができました。しかも精度が非常に高いという効果も確認できました。



2つの事例に共通しているのは、要求の出し手と受け手がそれぞれ異なる組織・企業であることです。両者の間にミスコミュニケーションがもともと発生していました。

特に大規模・複雑なシステム、自動車のように人の命に関わる高い信頼性・安全性が求められるシステムでは、単なるミスコミュニケーションでも影響が非常に大きくなります。

ConTrackが両者の架け橋となることで、ミスコミュニケーションに起因する問題を埋めて、問題の撲滅・抑止につなげられたのではないかと考えています。非常に効果が出た2つのプロジェクトをご紹介しました。

"DocOps"による要求管理のさらなる進化

最後に、DocOpsによる要求管理のさらなる進化と題し、DocOpsとは何なのかというところから話します。

DocOpsという言葉は、まだ一般的な用語ではありません。弊社が新しく提唱している、開発の生産性向上に寄与するための新しいコンセプトです。



DevOpsは、基本的にはモデリングされたりコーディングされたりして、システムが動ける状態になった後の活動に対して、自動化・機械化・AIによる自動化を図ることで、開発のスピードや品質を圧倒的に向上させる取り組みを指します。

ただ、上流工程で要求が誤っていたり、要求の実装漏れがあったりといったエラーがあっても、DevOpsでは全ての問題を解決するのは難しいです。人間の判断が必要だったり、もともとドキュメントがさまざまなフォーマットで作られていたりしたら、DevOpsの仕組みに乗せることが簡単にできなくなるからです。

このドキュメント管理の分野にもDevOpsの考え方を拡張できれば、より高い生産性で、しかも安全で品質の高いシステムを作っていくことができるのではないかと考えています。

DocOps基盤の最終形態をイメージしたものでは、真ん中にConTrackがあります。ConTrackで管理する対象は、DocOpsの文脈では要求仕様や基本設計書といった、例えばWordやExcelで作られることが多いドキュメントが対象になります。



これらのドキュメントは、SubversionやGitのような構成管理ツールで管理されることもありますが、一般的にはファイルサーバー、SharePoint、Boxといったファイル共有基盤でフォルダー分けして管理される領域に入っていることが多いです。

さまざまな場所に散らばっているドキュメントを、ConTrackでバーチャルに一元管理していきます。その際にWordやExcelといったファイルを項目レベルで分解してConTrackに登録し、データ化を図ります。

これをAPIで外の仕組みやプログラム、AIなどに渡していくことによって、設計に関するいろいろな活動のDX化が進んでいくと考えています。

具体的にどんなイメージがあるのか、3つご紹介します。

1. ドキュメント更新後のタスク自動切り出し

設計担当者が作ったドキュメントを構成管理リポジトリに登録・更新すると、JenkinsやプログラムがConTrackに差分分析や影響範囲分析を指示します。影響範囲の分析結果については、RedmineやJira Softwareのような課題管理システムにチケットを切り出していきます。

従来であれば人がやっていた活動を、システムが自動的に回すことで、より設計のブラッシュアップに皆さんの工数を割けられるようになります。

2. トレース作業の効率化

上流工程と下流工程の間に何らかの法則があれば、それを外部のプログラムでロジックを組んで、自動的に線を引くことでトレースするところまで自動化できます。

3. 定期的なトレース状況の監視

従来はタスクやソースコードの粒度でメトリクスを取得するわけですが、ConTrackではドキュメントを項目レベルに分解するため、より細かい粒度でのメトリクス測定が可能になります。



実際にDocOpsを実現した事例を話します。組み込みシステムで、インターフェース仕様書のデザインレビューにかなり時間がかかっていました。インターフェースする箇所の総数は数万箇所あり、仕様が変わるたびに目視でデザインレビューしていましたが、毎回1人月以上かかっていました。しかもサンプルチェックしかできず、全箇所チェックできないので抜け漏れが発生していました。

これを、ConTrackと整合性チェックツール（スクラッチ開発）を取り入れることで解決しました。インターフェース仕様を整合性チェックツールにかけると、レコードごとに分解され、そのレコード情報を整合性チェックツールに渡すと、今まで人がやっていたデザインレビューをロジックで全部回すことができます。

これによって、今まで影響範囲にしかできなかったチェックが全箇所対応できるようになり、1回当たり1人月以上かかっていたものが30分以内で完了するようになりました。圧倒的な工数削減と生産性向上を実現し、システムによる処理のため品質向上にもつながりました。

このようなプロジェクトにDocOpsを導入することにより、開発のスピードアップと品質の大幅な改善を実現させるために、ベリサーブはこれからもConTrackを進化させ続けると共に、プロジェクトへの導入や運用を全力でサポートしていきたいと思います。

アーカイブ動画も公開しております。こちらも併せてご覧ください。

※ご視聴には登録が必要です