こんにちは。みなさんは仕様に関して次の困りごとに遭遇したことはありますか？
- なぜこの仕様か？変更しても問題ないのか？
- どこまでが確定仕様、どこからが暫定仕様なのか？
- 知見者の記憶や根拠になる情報を探さないといけない
今回、新製品のプロト開発～製品化着手の際に、USDM（Universal Specification Describing Manner）を導入した取り組みについて簡単にご紹介します。
USDMとは
USDM（Universal Specification Describing Manner）は「要求」と「仕様」を階層的に整理し、その関係性を明確にする仕様記述手法です。
従来の仕様書では「何をするか（仕様）」だけが記載されがちですが、USDMでは以下の3つの要素を分けて記述します。
| 要素 | 説明 | 例 |
|---|---|---|
| 要求 | なぜそうするのか（目的・背景） | 「工事写真の分類作業を効率化したい」 |
| 理由 | その要求が必要な根拠 | 「手作業での分類に1日あたり2時間かかっている」 |
| 仕様 | 具体的に何をするか | 「黒板のOCR結果から工種を自動判定する」 |
要求から仕様へとブレークダウンしていくことで、「なぜこの仕様なのか」が明確になります。また、要求に対して複数の仕様がぶら下がる形になるため、仕様の抜け漏れにも気づきやすくなります。
取り組み
具体的な活用方法は書籍になるレベルですので、書籍や他の解説記事をご覧いただければと思います。 私は以下の記事や本で活用方法を勉強していただくのをお勧めします。
参考までに、簡単に作成してみたものをご紹介します。実際のものはお見せすることができないので、工事写真の黒板をOCRして自動分類するという仮テーマで作成してみました。
感想
良かった点
- 明文化された資料を共有することで開発メンバー全員で共通認識を持って開発を進められる
- 開発メンバー内で、背景を理解した上で仕様提案や議論ができる
- 枝葉になる仕様は暫定仕様で進め、関係者に一番先に見せたい仕様やユースケースを動く形で提案できる
気になった点
- USDMの形式に慣れないと少々書きにくい
- 表の中に図を入れたり、更新のしやすさからExcelが使われることが多い（いずれはMarkdownで管理したい）
まとめ
USDMを導入することで、仕様の「なぜ」を明文化し、開発チーム全体で共有できるようになりました。 仕様書の課題に悩んでいる方は、USDMの導入を検討してみてはいかがでしょうか。 私たちもさらに使いこなしていきたいと思います！
おわりに
KENTEMでは、様々な拠点でエンジニアを大募集しています！ 建設×ITにご興味頂いた方は、是非下記のリンクからご応募ください。 recruit.kentem.jp career.kentem.jp
