SE一年目のための仕様書の書き方 システム品質を高める文章術

宮古環(著者)

• 販売会社／発売会社: 秀和システム
• 発売年月日: 2014/08/27
• JAN: 9784798041674

商品レビュー

2018/12/30

日本語の分かりやすさ、関係者とのコミュニケーションの重要性がわかります。
著者の経験から、日本のIT業界に毒付いているのが面白いです。

2014/11/04

ものすごく教科書的な本だった。図書館で借りて読むだけじゃダメな本かもしれない。特に、自分みたいに特別仕様書を書く必要性に迫られていない人は。
前からよく聞くけど、SEというものはコミュニケーション能力が必要なんだろうなと思った。そういうこともあって自分は、SEにはむいてないのだろうと思う(ずっとプログラマでいい)。
あとがきの話がひどかった。なれる！SEですらこんなにひどくないだろと思うような事例が。小説化してほしいところ。
ところで、保守運用における、システム障害訓練ってどういうことなんだろう。アクセス負荷とかかな？

2014/10/25

仕様書の不備の例。
・全体像が示されていない。
・技術的に実現不可能な仕様を要求している。
・要求仕様間の関連性が記述されていない。
・具体的にどのように実現するのかが明記されていない。
・複数の解釈ができる仕様を要求されている。
・元の仕様がマッチしていないにもかかわらず、その過程が不明瞭のまま。
曖昧な仕様書の４つのパターン。
①観点が曖昧、もしくは資料ごとに統一性のない仕様書
②内容が薄く、要求仕様書に近い仕様書
③上流工程のインプットの記述の粒度をただ細かくした仕様書
④重要な情報が欠落している仕様書
逆に、仕様書自体はしっかりできていても、開発を行うメンバー側に問題があり、説明や作業指示に膨大な時間を浪費し、結果として想定していた工数を大幅に超えてしまうケースもある。
失敗の原因は、現場の人間関係を崩さないことを重視している点にある。
意味のある仕様書の条件。
①関係者に成果物のイメージが正確に伝わる
②合意すべき点が明確に定義されており、曖昧でない
③重要な点が強調されている
④スケジュール上、押さえるべき点を押さえてある
⑤後から見直した際に、過去に行われたこうてを追うための記録が書かれている
魔法の言葉
・つまり、こういうことでしょうか？（意見を代弁）
・だから、こうなのですか？（考察を代行）
・しかし、こういった場合は考えていますか？月例外の確認）
要件のチェックリスト
①項目名（項目の名前）
②推奨要件（クライアントが要望した内容）
③実現方法（要件をどうやって実現するか）
④成否（要件を満たしているか）
⑤説明（補足情報）
⑥参照（参照先の資料）
ウォーターフォール型でも、結果を待って計画を変更した方がよい事態が想定される場合は、計画の分岐点を想定し、複数型のスケジュールとすべき。