積層仕様定義

設計書 + サンプル + 詳細解説 + 質問 = 仕様 ⇒ 仕様書

仕様の定義に至るまでに、設計書から質問までの内容が積み重なるイメージ。

これを「積層仕様定義」と呼ぶ。

「設計書」で説明しきれない内容は「サンプル」で説明する。

「サンプル」で説明しきれない内容は「詳細説明」で説明する。

「詳細解説」で説明しきれない内容を「質問回答」で説明する。

「情報の信頼性」は質問回答が一番高く、設計書が一番低い。

「情報伝達の効率性」は設計書が一番高く、質問が一番低い。

「仕様定義の属人性」は質問回答が一番高く、設計書が一番低い。

「設計書」のアウトプットは、「定義書」。大体がスキーマ定義書である。

「サンプル」のアウトプットは、「ファイル」。大体がファイルやJSONである。

「詳細解説」のアウトプットは、「ドキュメント」。パワポのスライドの場合もある。

「質問回答」のアウトプットは、「問い」と「回答」。厚めの資料の場合もある。

仕様定義に至るまでに、どのステップでの課題解決を重視するのかを情報提供者と情報利用者で合意形成しておく。

式にするとわかりやすい。

式 : 設計書 + サンプル + 詳細解説 + 質問回答 = 仕様

例 : 60 + 15 + 5 + 20 = 100

上記を期待として、実態が以下である場合、

例 : 30 + 20 + 10 + 40 = 100

この状況になった場合は、設計書の質を疑って対応すると、建設的に動ける。

集めた情報を集約することで、「仕様書」が作れる。

仕様書の構成要素は目次, 概要, 設計書, 用語定義, 処理フロー図, 処理パターン, 処理シナリオ, 要件一覧, 詳細仕様, 参考資料。

構成要素は必須の項目もあれば、任意の項目もある。

作る対象の複雑さと、作り手の習熟度によって情報濃度と整理度合いが変わる。

隠れパラメータとして、定義者と実装者の間に “共有力” が備わっている場合、仕様書の定義を省くことが可能。この “省く” ことが “スピード” を生む場合があり、ここで生まれるスピードが “競争力” につながる場合がある。だから、”共有力” は重要。

もしくは、共有力を必要としないくらい人を動かせて、動くために必要な情報を正確に揃えられる能力があると良い。能力に制限はない。言語化力, ドメイン知識, 交渉力, 人心掌握, 政治力, ファシリテーション etc…

「定義」と「解釈」と「理解」の関係性を知っておく。

定義 ⇒ 解釈 or 理解 ⇒ 実装 ⇒ 仕様

ここでの「定義」は言葉に対する意味解釈を説明することを指す。

“「A」とは、「B」である” これを定義と呼ぶ。

定義することはとても重要。

最終的に仕様に現れる。だから、定義は重要。

良い定義は、「解釈」に迷いを生まない。

「何であって、何ではない」という様に、肯定だけでなく、否定ができる。

肯定と否定がセットで持てる場合は、定義の完全性が高い。

良い定義は、「理解」を助ける。

理解は複数の定義の “関係性” を説明できるようにするために必要。

Aの定義が変わることにより、関係するBの作用範囲が推論できる場合、それはAとBの定義の質が高い。理解の深さは推論の質で測れる。

悪い定義は解釈に迷いを生み、誤解につながる。

悪い定義は疑問を生み、影響範囲の不透明感につながる。

誤解 or 不透明さを感じたら定義を疑う。

誤解 or 不透明さを生まないためにも定義にこだわる。

SHARES