「要求を仕様化する技術・表現する技術」がオススメ。「要求とは」「仕様とは」からはじめて、仕様戦争までの経緯、回避するための具体的施策までが分かる。用いた仕様書」はなかなか興味深い。著者は「要求」と「仕様」の関係をロジックツリーに見立てる。...└─仕様n(スペックn-1,n-2,n-3...)まぁ、こんなにキレイにならないだろうが、「このスペック(群)で"やりたいこと"は実現していると言えるのだろうか?」という視線が、どのフェーズでも配れるという点は素晴らしいと思う(実際に目配りするかどうかは別として)。本書のポイントは、「仕様書に要求"も"書け」に尽きる。仕様書に「スペック」だけ書くなと。「要するに何がしたいのか=要求」も併記しろとしつこく主張する。?なぜなら、要求は「その仕様になった理由」を表すから(←超重要)。要求とセットで仕様を検討することで、仕様モレは防げる。いう視線がつきまとうから。ホントのところ、実装フェーズになったらそれどころじゃないって、確定仕様をコードに落とすのに精一杯で、見る箇所も極めて狭い範囲に限られている。それでも仕様書を見る度に要求が目に入れば、「この仕様だけで要求は実現できる?」という問い直しをすることになる。言われたとおりに書いたはいいが、やりたいことは結局できませんでした、という悲しいよくあることは、これで、無くなる。仕様の衝突を事前に察知→顧客レベルで回避する。仕様の衝突の根本は、要求の衝突だからだ。その場合、どちらか、あるいは両方の「要求」が曖昧性を含んでいる。要求を仕様に分解するのではなく、要求をロジカルに分解する。これにより、仕様化する前に要求同士で矛盾を起こしていることが「見える」ようになる。どっちを仕様を優先するかは、どの要求を優先するか、の議論になる。A担当の「要求A」とB担当の「要求B」で決める話。ひどい場合は、A担当が先月言った「A要求」と、昨日言った「A'要求」との衝突。Aさんに判断してもらえるよう「要求の見える化」をしよう。道理が引っ込む無理な要求の狭間で苦しむことは、やめよう、仕様バグの温床だ。一つのドキュメントに「要求」と「仕様」が混ざると分かりにくい、といった弊害が出てくる。仕様書を開くと要求が見えるため、オーバースペックになる恐れがある。著者に言わせると、これを回避するための「Excel仕様書」だそうな。「要求」の階層と「仕様」の階層を分けて記述するところがミソ。オートフィルタを使えば階層ごとの表示/非表示をコントロールすれば問題解決。■「要求の見える化」の実践と効果その実践。仕様書は作らなかったが、要求を念頭においた仕様管理は確かに効果があった。チームメンバーにこう周知したのだ→「顧客へのレポートの先頭、仕様書の各セクションの冒頭、ソースヘッダコメント、さらにメモ/メール/ホワイトボードに至るまで、関係する"要求"を必ず書け」ってね。要求は「○○をするために...」という表現形式でロジックツリーで分解せよとレクチャー。その結果、変わったのは、ペーパーではなく、質問のやり方。「とどのつまり、何がしたいのでしょうか?」が、かなり早い段階で(したがって比較的なごやかな空気の下)、お互いに口にするようになった。これまで、部分的に五月雨で放り出される「仕様」をキャッチして、ジグソーパズルのピースを当てはめるように組み上げていたものが、最初に「やりたいこと」を念頭におきながら作業を進めるようになった。モレは絶滅したとは言わないが、行き違いは格段に減った。仕様がぶつかりそうなとき、その仕様が支えている要求どうしを並列して見せることにより、顧客に優先順位付けをしてもらえるようになった。└─動力(超電磁)...このやり方だと間違いなく★で取りモレが出るだろう。)...このやり方だと、それぞれのノードからさらに要求が定義され、要求のブレークダウンによりスペックが決まってくる(当然、エヴァ単体を作るだけでは意味がなく、チルドレン、セントラルドグマ、マギ、第3新東京市そのものを準備・運用・メンテナンスする必要が出てくることが分かる)。人類補完計画は想定外の運用であることも見えてくる(顧客は誰かにもよるが...)本書のやり方をそのまま適用できるかは分からないが、考え方は非常に使える。経験を積んだ方なら「そんなのアタリマエじゃねーか」ということばかりあるし、あるいは身につまされるエピソードが多々あるかもしれない。著者の主張・方法を知るにつれ、「わたしならこうする!」というアイディアが必ず浮かぶ。読んで分かった気になってオシマイという無駄本と違い、本書を読むと何らかの具体的アクションができるはず、しかも自分の中から湧いてくる、そういうスゴ本。»コメントご無沙汰です私も(汎用機COBOLの世界でも)プログラム設計書の冒頭、各セクション仕様の冒頭に、どんな要求に基づき何を実現したいのかを書かせるようにしています。ソース内にも出来る限り日本語のコメント文を書かせますね。作るときもそうですが、これが一番役に立つのは仕様変更時とトラブル対応時。このセクションにこの修正は入れるべきでない、ココにはこんなロジックが入っているハズがないという、あるべき論でソースを追えるので、デバック時にも有効なんですよね。結局は早く高品質のシステム完成と...はナカナカですが、本当に有効です。鉛のZEPさんお久しぶりです本来ならば、「何を作るか」以前に「それで何をやりたいか」という質問をするべきなんでしょうね。00:07おまけです仕様書の書き方はプロジェクトにより様々でしょうが、会社やプロジェクトの姿勢、とりわけマネージャー、プロジェクトリーダーの姿勢が提案型、自分たちが作って使ってもらうんだという形であれば、自ずと仕様書=要求書となって行きますね。同じ会社で似たようなシステムを開発していても、やる気の無いPJがユーザー部門の言われるがままに部下任せでダラダラやっていると最後必ず「そもそも論」で揉めることになってしまいます。マネージャーとかリーダーって影響力デカイと改めて感じる今日この頃であります。明日、2年越しの開発がSを迎えますが、いやぁ~今回も大変勉強になりました。さんあー、確かにそのとおりっマネージャーがプロジェクト全体の「色」というか「空気」といった雰囲気に与える影響は、はかりしれないものがありますね。「燃えさかるプロジェクトの火消し屋」として幾度か死線に投下されたことがありまが、似たような状況でもPMによって消防士だったりクラッシャーになったり、ヤル気満々だったり敗戦処理員だったり。サービスリリース、おめでとうございます。あっても、そこまでこぎつけるのに大変な努力を強いられたかと忖度いたします。仕様が書けていますか?」に感銘し本書に沿って要求仕様書を作成しようと試みています。答えが見つからないときは、問題を変えてみよう。(哲学はなぜ間違うのか)本は読まなくても書評を書くことはできる。