清水吉男のレビュー一覧
-
-
Posted by ブクログ
「入門+実践」要求を仕様化する技術・表現する技術
改訂第2版
仕様が書けていますか？
著：清水 吉男
出版社：技術評論社
良書、どろくさいシステム開発のなぜを考える書です。難易度が高いです。
本書の目的は、コンピュータシステムの構築の要求を適切に表現することで仕様を引き出す方法を語ってくれています。
本書を読めば、仕様変更率を５％以下に抑えることができ、仕様関係のバグも激減し、当初の納期通りにシステムができあがる、という、なんというありがたい書なのである。
要求の仕様化技術は、ソフトウエアエンジニアリングの技術の中の一部にすぎない
仕様化技術を生かすために、設計技術、見積技術、スケジューリング、進捗管理も重要である
さらに、要件開発は、２１世紀に入って、さらに高度な要求仕様の書き方や、要件の抽出、分析方法の研究もすすんでいる。
が結論です。
本書の構成は３部構成です。
①要求仕様にまつわる問題とはどんなものがあるのか
②問題に対して、どう要求仕様をかけばいいのか
③要件管理をどうするのか、なにを、計測すればいいのか
ソフトウエア開発とは、大勢の人間がかかわっているのでコミュニケーションの問題、個々のエンジニアが、みえない要求、仕様を、プログラム言語でコードにするので、対応する個々の人間のスキルや理解度に左右される、やっかいなものです。
あたまの痛い内容がたくさんでてきます。
・解釈の違いは伝言ゲームの中で発生する
・ウォータフォールの最大の欠点は、問題を発見するタイミングが遅くなることである
・テスト期間が短くなるのは、設計や実装に時間をとられているので、テストする時間が短くなるからである
・派生開発（追加開発）での潜在バグは、前任者が作りこんだバグがたまたま発見されたもの、なぜ作り込まれたのかは永遠にわからない
・設計や実装ベースであきらかになった、要求仕様や設計のミスは、要求仕様書に追記されることはない
・保守性という品質要求は、機能とはまったくことなるため、設計段階で、品質要求を行い、あらかじめ、組み込んで置かなければすり抜けてしまう
・要求仕様を丸投げした段階で、分割発注をおこなっても、まともなコードはかけない
・要求されない仕様は、実装されない
・仕様レビューは、１回しか見積工数として見られていないし、多くの指摘事項をもらうことを前提とはしていない
・仕様変更の流れ
①変更依頼の内容の不備をチェック
②内容の軽重や変更の範囲を検討
③範囲が広い場合は、関係者を集めて対応方法を検討
④現行仕様と矛盾しないか、他の機能仕様に影響がないかを検討
⑤手分けして、手戻り作業を行い
⑥修正作業と確認作業を行い
⑦対応完了の報告を行う
・要求仕様の粒度を小さくすると、「とてもそこまで書いている時間がありません」
⇒でも、仕様化されていないまま、設計はできない
⇒手戻りをするくらいであれば、粒度を小さくするほうが効果がたかく、おつりがくる
・顧客との関係を高める
仕様書のサンプルを用意して、成果物を例示して、なぜ必要なのか意味を説明する
・お互い「わかった」が一致していないケース、勘違いしています。
・文章が書けない人に他人の文章を理解させることは容易ではない
・理解するという行為は、時として、作成するよりも、難しい
・仕様モレよりも、要求モレを防ぐほうが難しい
・要求がきちんと文書化されることはほとんどありません
・仕様が分かりにくければ、理由と、説明をセットにしておく
・システムを適切なカテゴリに分割する、要求を分割して範囲を小さくする
・仕様書は、エクセルで書く
・派生開発（追加開発）の難しさ
①一般的に開発期間が短い
②自分で書いたコードではない、人の書いたコードを解析する必要がある
③要求仕様の文書がない、あっても不足している
④ほしい設計書がない
・言われたことを、メモしているだけではだめ
メモや議事録を、ドキュメント体系の中にうまく反映するための仕組みが必要
・仕様化されない要求は実現されない
目次
第2版の発行について
はじめに
第1部 要求仕様にまつわる問題
第1章 要求仕様にまつわる問題
1.1 どこで問題が発生しているか？
1.2 要求仕様のトラブルの実態
1.3 曖昧な仕様で作業に入っている
1.4 顧客からの仕様変更が頻発して……
1.5 要求した機能を満たしていない
1.6 納期の遅れとなって表面化する
1.7 品質要求に応えられないSE
1.8 派生開発での仕様トラブルはもっと複雑
1.9 設計書が省かれてしまう原因になっている
第2章 なぜ仕様のトラブルが起きるのか
2.1 問題が明らかにされたか？
2.2 仕様化の作業を放棄した
2.3 ドメインの知識がない
2.4 バグの経験だけでは役に立たない
2.5 レビューできた仕様書か
2.6 FIXした・しないでもめる理由
2.7 途中で仕様変更が混乱する理由
2.8 望みはある
第3章 要求仕様は不要か？
3.1 テスト仕様で代われるか？
3.2 仕様化しないほうが儲かる？
3.3 “不完全な要求仕様”の誤解
3.4 “コードなら書ける”の仕組み
3.5 GUI構築ツールで仕様を引き出せるか？
第4章 仕様化の効果
4.1 要求仕様書がすべての始まり
4.2 一気に解消する混乱
4.3 設計や実装のイメージができる
4.4 不用意な「試作」が減る
4.5 設計や実装時に仕様の確認ができる
4.6 レビューで感じる仕様化の効果
4.7 トータル工数が短くなる
4.8 設計に入る前に機能の難易が見える
4.9 顧客との良好な関係を築ける
4.10 ITゼネコンとの訣別
4.11 要件管理に取り組める
第5章 要件開発の重要性
5.1 文書にする理由
5.2 “わかる”の問題に対応する
5.3 なぜ“要求”仕様書というのか？
5.4 要求仕様書は誰が書くのか
5.5 顧客からの要求仕様書を洗練する
5.6 仕様モレと仕様間の衝突を早期に発見する
5.7 要件開発をスケジュール管理のなかで行う
5.8 要件開発と要件管理は車の両輪
5.9 要求工学における世界の動き
第2部 要求仕様を書く
第6章 “要求”を書く
6.1 要求の役割
6.2 要求の表現
6.3 要求には「理由」がある
6.4 必要なら「説明」を付ける
6.5 要求のカテゴリ化
6.6 要求のモレを防ぐことが重要
6.7 品質要求を確認する
6.8 品質要求の表現
第7章 要求の階層化テクニック
7.1 要求を階層化して範囲を狭める
7.2 「MECE」の活用
7.3 階層化しても「要求」に変わりはない
7.4 依頼者と分割の基準を共有する
7.5 階層は2層ぐらいで止める
第8章 要求を仕様化する
8.1 仕様とは
8.2 “Specify”の意味
8.3 仕様で衝突する
8.4 いつ仕様化すべきか？
8.5 検証可能性について
8.6 固有の番号を付ける
8.7 要求の階層のなかで仕様を捉える
8.8 さらに範囲を狭めるためのグループ化
8.9 シナリオ機能と単純機能の違い
8.10 仕様と要求の混在の問題
8.11 仕様から要求を立てる
8.12 “ペースト作文”の弊害
8.13 「否定表現」などの曖昧な表現を避ける
8.14 “FIX”から“賞味期限”へ
8.15 品質要求の仕様化
8.16 確定しない仕様の表現
8.17 設計情報の扱い
第9章 Excelによる仕様化の勧め
9.1 「Excel」のほうが細かな使い方ができる
9.2 要求書と要求仕様書を一体化
9.3 要求TM（トレーサビリティ・マトリクス）への展開
9.4 自在に「列」を設計する
9.5 WBSとの違い
9.6 Excelで書くときの注意
第10章 派生開発における要求仕様書
10.1 “部分理解”の世界である
10.2 要求仕様書の体系を持ち込む
10.3 旧状態を表現する
10.4 何が変更されるかを表現する
10.5 「差分」を書く
10.6 変更の種類
10.7 変更の要求
10.8 追加の要求
10.9 移植の要求
10.10 削除の要求
10.11 派生開発の品質要求
第11章 画面仕様書のあり方
11.1 画面仕様書の問題点
11.2 画面操作全体に対する要求はあるか？
11.3 個別の画面設計の指針としての仕様
11.4 画面遷移と画面仕様を連携させる
11.5 機能仕様との連携
第12章 ヒアリング時の注意
12.1 ヒアリングの目的
12.2 “システムの目的”を確認する
12.3 今回の要件定義の手順について同意を得る
12.4 仮説見積りに基づいた仕様作成期間
12.5 契約時には、仕様の項目数の見積りを付ける
12.6 要求仕様書の「体系」を示す
12.7 事前にヒアリングの範囲を知らせる
12.8 こちらの要求仕様のフォーマットに慣れてもらう
12.9 言われたことをメモしただけではダメ
12.10 品質要求をヒアリングする
12.11 未決項目を含んだ状態でのベースライン設定
12.12 顧客を仕様化作業に巻き込む
第3部 要件管理と計測
第13章 仕様化を支える要件管理
13.1 なぜ、仕様が変更されるのか？
13.2 関係者へのオリエンテーリング
13.3 要求仕様書をレビューする
13.4 ベースライン設定と合意
13.5 以後の仕様変更をコントロールする
13.6 未確定だった仕様が決まる
13.7 いつ仕様変更を実施するか
13.8 仕様変更を期間限定で募集する方法もある
第14章 仕様化の出来栄えを測る
14.1 何を計測するか
14.2 レビューでの指摘件数とバグ件数の関係
14.3 データは組み合わせると声を発する
14.4 バグから学ぶ要件開発の方法
第15章 仕様化技術の応用
15.1 リスク管理へ応用
15.2 課題への対応が見えずにうろうろする
15.3 作り替えても前と変わっていない
15.4 業務指示もその場で具体化しよう
15.5 会社の方針がそのまま降りてくる
おわりに
参考文献
ISBN：9784774142579
出版社：技術評論社
判型：A5
ページ数：384ページ -
-
-
-
-
Posted by ブクログ
改善や改修に特化した開発プロセス方法が記載されている。ソフトウェアの話として書かれているが、機械や電気系の人にも役立つと思う。特に、組み込み系をやられている方は、殆どの場合、既存製品のモディファイが開発となると思われるので、参考として手にとってはいかがだろうか？
XDDPと呼ばれる筆者が考えた方法論が書かれている。背景まで丁寧に書かれているので、手っ取り早くノウハウを得たい人にはやや冗長に映るだろう。基本的に本手法の肝は、要求からの漏れチェックのための視覚化と要求からの変更内容を導く思考過程の可視化だと思った。よって、その場限りのコード改修と異なり、レビューがしやすくなる上、設計者の従来機種への理解が深まるというメリットが有るように思う。
本手法が新規設計が少ない組み込み業界の開発プロセス標準の一つとなり、多くの設計者が報われるようになることを望みたい。 -
-
Posted by ブクログ
清水さんの本を読んだのは、これで3冊目です。
冗長とか読みにくいとかいう感想は一緒です。でも、まずは、それを書いておかないとね。
そのように、本としては、いまいちな本書がこんなに読まれているのは、そこに卓越したオリジナリティと実用性があるからだと思います。
★★★
本書では、清水さんのUSDM（Universal Specification Describing Manner）について書かれています。
改訂版なので16ページ増えています。
USDMは、要求仕様書の書き方です。仕様書というからには、
「仕様書」は「Specification」の日本語ですが、どのような状態かわからないままこの言葉を使っていると思います。英和辞書を引いても「仕様」「詳細」「明細」といった意味が書かれているだけでほとんど役に立ちません。「USDM」では「Specification」を、関係者がその内容について“特定できた（Specify）状態"、すなわち同じもの（こと）をイメージしている状態と定義します。
が満たされている必要があると筆者は主張します。
そのために、
・ 要求には特定しやすいように番号を振る
・ 仕様にも同様に番号を振る
・ 要求と理由と説明と仕様は区別して書く
・ 複数の要求はカテゴリにまとめる
・ 要求自体の階層化は2段までとする
といった具体的なテクニックが書かれ、さらにチェックマーク欄などを加えた具体的フォーマットが示されています。
★★★
USDMの価値は、要求に対して理由を紐づけることで要求の依頼者の真意とのズレを無くし、さらに仕様を要求と離れないように、しっかりと関連付けて明確にしていることにあると思います。
そして、それをExcelという追加修正しやすいツールで記載しているところが実用性を上げています。
★★★
本書を読む前に、Twitterで@mkoszkさんが
USDMで用いている要求は一般に使われている要求とは違う。USDMにおける要求は、「範囲」を表すようにしている。それは、状態や条件の場合分けがあり、連続する振る舞いを表現するため、一般に要求と思われているものよりも文章が長くなり、複数の動詞が含まれることになる。#USDM
posted at 01:22:35
という理解でよいのかしら？ #USDM
posted at 01:22:50
USDM本が改訂される理由は、「仕様は要求に含まれる”動詞”およびその”目的語”にある」ということを全面に押し出すためと書かれている。 #USDM
posted at 01:32:09
この理解がまだ不十分なのだが、今のところの理解を書いておこう。複数の動詞が含まれる要求を分解して、一つ一つの動詞にするだけではなく、その動詞が書かれた背景や情景、シーンや状態を見極め、書かれていない”動詞”を抽出するというものだ。 #USDM
posted at 01:34:52
この考え方はHAYST法におけるFV表の”目的機能"を導き出す方法と似ている気がしている。USDMで抽出された"動詞"とFV表に書かれた”目的機能"は、表現された結果は違うものだけれども、その過程が似ている気がしている。 #USDM
posted at 01:38:46
FV表の目的機能は、システム機能では無い。どちらかというと要求に近いと思われる。そのため、USDMと似ている気がしているだけで、やっぱり違うのかもしれない。
posted at 01:48:51
書かれていたので、今回、FV表との違いを意識して読みました。
その結果分かったことは、
@mkoszk 半分位読んだのですが、USDMの要求仕様とFV表の目的機能とは重なるところは多いのですが違うものでした。目的機能の方は「欲しいかどうか」は重視しません。
posted at 12:31:43
@mkoszk 半分しか読んでいないのでUSDMの方は確信はないのですが、FV表の方は基本機能を考えてから目的機能に戻ります。そうすることで今回の商品にはあるいは過剰品質かもしれないけど再利用や保守で必要となる機能を見つめます。
posted at 12:54:33
「理由」と「目的」は似ているけど違うものです。そこがUSDMとFV表との本質的な違い。理由は「何故？」と掘り下げる思考で、目的は「本来はどうなの？」と登っていくもの。開発用には掘り下げる方が良いし、テストでは視野が広がるので本質に目を向けるのが良いだろう。
posted at 18:18:26
です。
FV表のFは智美塾合宿の結果Fg（ゴールを意識した機能）ということが分かってきたのですが、「機能」から「目的」を問う方向なのです。
つまり、FV表の「目的機能」は、「その機能は何のためにあるの？」「その機能が果たすべき目的は何なの？」「そもそも、どうして作ろうと考えたの？」という解決空間を拡げる上部へ展開していく方向です。
一方で、USDMの「理由」は、「その要求がでてきた理由や背景はなんだっけ？」「何故、依頼者はこんな要求を出してきたんだっけ？」というように要求の依頼者の真意と要求仕様書を記述する開発者やレビューアとの認識のズレをふせぐための「要求の掘り下げ」です。
これは、どちらが良いという話ではなく、要求を仕様化していくためには、それはさまざまな選択肢の中から仕様を確定していく行為ですから、清水さんの「理由｣の方向で分析するのがよいのです。
そして、できた機能に対してテストする時には、書かれた要求や仕様が間違っていることもあるわけですから、「目的」展開を行ってゴールの認識を共有して（Fをレビューして）テスト設計に持っていくのがよいわけです。
ということで、長文になりましたが、お勧めです（たぶん、初版の方をお読みの方が多いと思いますが）。 -
Posted by ブクログ
ソフトウェアエンジニアリングの教科書には「新規開発をどう上手くやるか」について書いてありますが、私たちが日々格闘している「派生開発」については「保守」としてひとくくりにされ、十分な記述がありません。
もちろん、新規開発のノウハウが役立つ部分もあるのですが、筆者の清水吉男は「派生開発の現場では、時間に追われバグを見つけ次第直すという間違ったプロセス」にメスを入れています。
つまり、派生開発においては、
o 変更要求仕様書
o トレーサビリティ・マップ
o 変更設計書
を作るプロセスを提案しています。これらは、実践的で非常に役立つノウハウと思います。口語調で話が整理されていないためちょっと読みにくい点がちょっと残念です。 -
Posted by ブクログ
ネタバレ世界中で，システム設計の現場では、「新規開発」より、「派生開発」としての動いているシステムの変更や機能追加が多い。
その点に着目した著者の経験が凝縮されている。
派生開発の場合に何が課題になるかの仕立てをうまくしている。
仕様をどうやって明確にしていくかについての知見が豊富にある。
仕立て(tailoring)をしているだけでなく，清水吉男さんのよいところは，現場にあわせた着付け(fitting)もできることだ。
決めたことを，決めた通りにやるだけなら，能力のある技術者はいらないかもしれない。
どういう制約条件のもとで決めたことか，条件が変わったらどうするかを考える能力があるかどうかが課題だろう。
数少ない日本の相談業務（コンサルティング）を頼みたくなる方だ。
一度，清水さんの話をお聞きになられた方なら感じられたと思う。
相手を引きつける力
相手に頼む力
相手の話を聴く力
がある。
自分の経験を大事にする技術者としての感性を持ったまま，
経営的な課題に取り組もうとする姿勢がある。
著者の書かれたことを勉強するだけでなく，
著者そのものを勉強することをお勧めしたい。 -
Posted by ブクログ
ネタバレ何を作るとよいかということをここでは「要求」という漢字2文字で表現しています。仕事によっては「制約」という場合もあります。
これらの制約を仕様として記述するのが不十分だと，
何を，どういう条件で試験すればいいかが分からないため，
結果として，何度も作り直しをしないといけないこともあります。
システム設計の基本的なところを，清水吉男さんの経験に基づいて、うまく整理しているところがよいでしょう。
参考文献も，海外でも流通している基本文献をあげているので，
国際的な展開に役立てることもできるでしょう。
2011年の11月には，上海で開催された世界ソフトウェア品質会議でも関連発表があったので，参考にするとよいでしょう。
また，2011年6月の派生開発カンファレンス2011での
藤倉 俊幸さんの
ユースケースとUSDMにセミフォーマル手法を適用した要求検証
が，本書の内容を発展させるよい鍵だと思いました。 -
Posted by ブクログ
・良書。久しぶりに自分でも試してみようと思ったソフトウェア開発プロセスの本。
・個人の思い込みや勘違いを防止する為に、レビュー（他者の視点＝組織力）を重視する所は、ワインバーグのエゴレス方式に近い。 ≪参考≫ジェラルド・M.ワインバーグ(著)「プログラミングの心理学―または、ハイテクノロジーの人間学」
・設計に時間を掛ける事で、事前にバグを防ぎ、その結果、プログラム修正の時間は減らせるという考えは、デマルコの思想に近い。 ≪参考≫トム・デマルコ (著)「デッドライン―ソフト開発を成功に導く101の法則 」
・XDDPの成果物は下記の通り。レビュー時に他者の気付きがされ易いように工夫されている。
変更要求仕様 …（What ） どのような振る舞いを変更するか？
トレーサビリティ・マトリクス …（Where） どのモジュールを変更するか？
変更設計書 …（How ） 変更方法について記述する
-
-
-
Posted by ブクログ
ネタバレ最近、新規プロジェクトが少なくなってきたと聞く。
そうであれば、今後は、既存システムの改修案件が増えてくるであろうということで、読んでみた本。
よくあることだが、ソースを書いた人と保守する人は別の人。
だから保守する人はどこを直せばよいのか、わからないことがある。
そんな時、「部分理解」な人でも、できる限り手戻りなく修正するプロセスを確立しておけよってことがこの本の趣旨。
ごもっともです。
主軸は、レビューの大切さ。そしてレビュアーに気づいてもらうように（アンカー効果が働かないように）、変更内容の事前準備をすること。
その方法として、手順は５つ。
・変更内容とその理由を記載した、変更要求仕様書を作成すること。
・縦軸に変更内容、横軸に画面一覧（ソースファイル一覧）としたトレーサビリティマトリックスを作成すること。これで、修正漏れを少しでも防ぐ。だって同じようなソースが至る所にあること多いもん。
・どのように変更するかを記載した、変更設計書を「プログラム言語」ではなく「文章」で作成すること。before/afterを文章で書く。
・レビューを実施して、勘違い・考慮漏れなどを無くすこと。
・ここでようやくソースコード修正。これ直してよ。ちょろです。直しますね。は、ご法度。
まあ、C言語っぽい言葉がやたらと出てきて、SVNとか差分管理ツールとかないんかいとか思わせる言い回し、オブジェクト指向を前提としていないよねとか、オフショア開発ではなく1人プロジェクトを主体としていることが前提となっているように読めたから、使えるところだけ使おう。 -
-
-
-