SERVICE & TOPICS サービス・最新トピック

大規模システム開発におけるトラブル事例② ~入力情報の管理は自部署の責任で行うべし~

大規模システム開発におけるトラブル事例② ~入力情報の管理は自部署の責任で行うべし~

前回に引き続き、大規模システム開発におけるトラブル事例についてお話しします。第2回目は『プロジェクトに適合した開発基盤(インフラ)の確立』についてです。

相談者が参画している大規模システム開発のプロジェクトチームは、技術系(企画、開発、生産)だけでなく、事務系(営業、販売、サービスなど)の部署も関わっています。相談者は関係部署からの要望(構想、機能、技術)を取りまとめ、技術要件・システム設計に落とし込み、詳細設計・実装を請負先企業に準委任されていました。

しかしながら、プロジェクトチーム内の関係部署より吸い上げた構想・機能要件の量が約2,000件と多く、要件の粒度がバラバラなため、膨大な精査工数を要してしまい、本来行うべき技術要件、システム設計の作成が滞ってしまいました。

では、どこに問題があったのでしょう? 大きく2つあります。

一つ目は相談者の所属部署から関係部署に要望提起をお願いした時に、『フリーフォーマット』にしてしまったことです。プロジェクトチームには様々な領域の担当者が参画しております。組織間、個人間でモノの捉え方、価値観が異なるため、要望エビデンスに記載する内容・粒度ともに異なって当然です。今回のケースでは、相談者の所属する部署、言い換えると要望を利用して技術要件を作成する部署が関係部署をコントロール・マネージメントすべきなのです。

『フリーフォーマット』による要望エビデンスは一見すると書きたいことを自由に書けるイメージがあります。しかし、受け取る側、今回は技術要件を作成する側の立場として、要望内容の把握はもちろん、システムデザインに置き換えるのに膨大な工数がかかるのは想像に難くありません。

一方で関係部署、特に事務系部署に『エビデンスの粒度』を意識しろといっても、言われた側は恐らく理解できないでしょう。そこで、自部署、技術要件を作成する部署からガイドライン・制約条件を提示してあげることが必要なのです。

『ガイドライン・制約条件を提示する』と関係部署の要望がすべて反映できないのでは?、と思われるかもしれませんが、そうではありません。単純な方法があるのです。それは『フリーフォーマット』にしていたエビデンスに対し、『タグ付け』をしてあげるだけで十分なのです。乱暴かもしれませんが、最も簡単で関係部署も理解しやすい最善の方法なのです。タグ付けの方法は下記スライドに例として記載しておりますが、唯一ではありません。情報検索やトレーサビリティを確保できるよう、変更してもかまいません。

そしてもう一つの問題、ツールの適切な活用です。技術系職場において要求管理、構成管理、変更管理、仕様作成といった専用ツールの活用は現在では当たり前として認知されていますが、事務系や企画部署においては馴染みがないかと考えます。理由は要求・タスクの数、粒度が開発現場に比べて圧倒的に低いからです。

しかしながら、大規模システム開発では、構想・要望段階より要件の数が1000件を超えているのが実態です。これを汎用ソフト(例えばエクセルなど)で管理するというのは本末転倒です。一方で企画部署・事務系部署では上記のような専用ツールの使用経験が少ないと考えられます。利用方法を理解するだけでも相当の工数を費やすのではないでしょうか。

上記現状を鑑み、既存の汎用ツールや無償提供されているオープンソース(RedmineやSubversionなど)との連携を可能にした、簡易的な要求管理ツールが複数のツールベンダーから提供されています。これらを用いた場合、既存ツールを引き続き利用できることから、ツールの理解に要する工数も大きく低減できますし、導入費用に関しても、例えば PTC Integrity やIBM DOORSのような大規模の要求管理ツールより大きく抑えることができます。

大規模のシステム開発およびソフトウェア開発における開発基盤の構築も、プロジェクトを進捗させる上で必要な要素となります。

なお、要求管理ツールの情報につきましては、商標権等の都合上Web掲載できませんが、弊社にて関係資料を所有しております。ご興味のある方はお問い合わせフォームにて弊社までご連絡いただけると幸いです。

タグ付けの例
タグ付けの例