システム開発における「仕様書を読む」とは？効率的な読み方を解説

背景

システム開発では仕様書と呼ばれる技術文書を活用し開発を進めていきます。しかし、長年開発に従事してきた体感として、仕様書の読み方がわからないという悩みを抱えている方が実に多いと感じています。そのため、このような悩みを抱えている方に向けて、自身の経験をお伝えしたく筆を執りました。

仕様書とは？

仕様書に関しては以下の記事で解説しておりますので、仕様書とはそもそも何なのかという方はこちらをまずご覧いただければと存じます。

仕様書を読み込むとは？どんな時に読み込むのか？

「仕様書を読む」行為は、仕様書を受け取った人物が特定の目的を遂行するために行う活動です。特定の活動とは、大きく分けて以下3つです。

1. ソフトウェア設計書/ソースコードを作成する
2. テスト仕様を作成する
3. 新たな仕様書を作成する

ユースケース1. ソフトウェア設計書/ソースコードを作成する

ソフトウェア開発部署もしくはソフトウェア開発ベンダーのエンジニアが仕様書を読み込むというシーンです。彼らは見積のために仕様書を読む必要がありますし、見積フェーズからの変更点を管理する必要があるため、仕様書を読み込みます。

ユースケース2. テスト仕様を作成する

ソフトウェア/製品のテストを行うエンジニアが仕様書を読み込むというシーンです。彼らもソフトウェア開発部署やソフトウェア開発ベンダーと同様に見積のために仕様書を読み込みます。そして、テスト仕様書（テスト手順やテスト時の期待結果が記載された文書）を作成するために仕様書を読み込みます。

ユースケース3. 新たな仕様書を作成する

仕様書を受け取って仕様書を作成するエンジニアが存在します。これは何を言っているかと言いますと、発注者が発行した仕様書を仕様担当のエンジニアが受け取り、下流工程へ渡すために具体化を行う行為です。つまり、発注者が「要求」を仕様書に記載し、発注者が「実現手段」まで具体化するために、発注者が発行した仕様書を読み込みます。ある程度大規模な開発になると、開発を委託することが多いため、委託先の中に仕様担当エンジニアが必要になってくるという構図です。このエンジニアが発注者との橋渡しを行う役割を担っています。

仕様書を効率的に読み込むには？

仕様書を読む際に意識してほしいコツがあります。それは仕様書の構造を頭に入れることです。よく、いきなり数千ページの仕様書を読み始め深い眠りに入っていく方々を横で見てきました。一方、仕様をとても理解しているエンジニアは仕様書の構造が頭に入っているため、情報へのアクセスが早く、仕事も早いです。「仕様に関してはあの人に聞け！」という状態に一日でも早くなるために、仕様書を読み込む前に以下3つの手順を行うことを推奨します。これを実施することで、仕様書の構造が頭に入り、仕様の理解度が向上します。

1.仕様書リストを探す

先ほど数千ページの仕様書と記述しましたが、仕様書1つあたり数百ページあり、かつ、仕様書数が数十個あるプロジェクトを多く経験してきました。仕様を発行する側も、どの仕様書をどのVersionで誰に展開するのかを管理する必要があるため、仕様書名をリスト化して展開してくれる場合があります。そのため、まずは仕様書リストを探しましょう。

2.仕様書リストに記載されているカテゴリに目を通す

仕様書リストが見つかった場合、仕様書リストに目を通します。すると、以下のようにカテゴライズされている場合があります。

仕様書がこのようにカテゴライズされている場合、カテゴリの名称に注目します。その名称には、仕様書発行側がわかりやすいように意図を持って名称を付与していることが多いです。その意図を何となくでもよいので想像してみましょう。例えば、「COM」というカテゴリであれば、「COMMON」＝「共通仕様」というように連想します。

3.各仕様書の概要やスコープを一通り読み、その仕様書に何が書いてあるかを把握する

各仕様書群のカテゴリを想像した後は、それぞれの仕様書を開き、概要やスコープの章を読みます。それにより、その仕様書ではどのようなことを記述しているのかを掴むことができます。この段階で最後まで仕様書を読み込む必要はありません。概要を掴んだら次の仕様書へ移ってください。一通り概要を読み終わった後、仕様書の構造が頭に入っているはずです。

エンジニア

一度では覚えられないよ！

一度で全部覚えることは難しいと思いますので、上記3つの手順を複数回行うか、この仕様書にはこういうことが書いてあるというメモを残しておくことを推奨します。これが「仕様書の歩き方」として資産になるはずです。

まとめ

システム開発で行われる「仕様書の読み込み」について解説してみました。少しでも参考になれば幸いです。