- Amazon.co.jp ・本 (279ページ)
- / ISBN・EAN: 9784798021751
作品紹介・あらすじ
明確な共通指標を定める「コミュニケーション力」、正確でわかりやすい表現のための「文章力」、複雑な作業をドキュメントにまとめる「文書力」、変更に柔軟に対応するための「メンテナンス力」…ITエンジニアが持つべき4つのスキルでダメダメ「仕様書」を改善。
感想・レビュー・書評
-
着眼点、視点は面白い。
愚痴としての読み物なのかテキストなのか焦点が絞れていないのは残念。
上から視線なのも少し気になる。
著者も自分で気付いている様で、あとがきで言い訳しているようだが。詳細をみるコメント0件をすべて表示 -
まるで国語の勉強本。
解りやすい仕様書を書きたいのに、文章(文書)指摘とは。
読む本の系統を間違えた感。
とはいえ、確かにこの本の例のような「ダメな」書き方されてる仕様書をよく見ることも事実かと。 -
内容が抽象的で希薄。
具体例がなく、ネット上で調べることが出来る程度の内容しか無い。
本の煽り文句を用いれば、あなたはまだそんな書籍を出版しているんですか?と煽り返したくなる内容。 -
あなたはまだそんな「仕様書」を書いているんですか?
●2009年4月から施行される会計基準の1つである工事進行基準では、成果物の仕様を決め、進捗率に合わせて費用計上することが決められている
●○○の条件ならできる、という部分否定で返さなければ何も始まらない
●アジャイル開発では、通常より高品質で、何度も作り直し、要望に応えるようと努力しなければならない
●暗い雰囲気や先行きが見えない雰囲気になった場合、意味のある発言やポジティブな発言をし、発言をしていない人を会話に巻き込むことでWin-Winのコミュニケーションを心がける
●情報の収集、整理、評価を繰り返し、まとめとして清書し仕様書を作る
●ミーティングでは目的、質問の一覧と合意事項一覧を作成して下準備をする
●ゼークトの組織論
・有能な怠け者は前線指揮官、有能な働き者は参謀、無能な怠け者は総司令官に向いている。無能な働き者。これは処刑するしかない
●受動態や自動詞を用いて主語を明示しないと文章は曖昧になる
●成果物のイメージが固まり、不明瞭な点について、その理由が明確になった上で、仕様書を書き始めるのがよい
●仕様書のメンテナンスでは、変更理由を示し、変更点を箇条書きにして共有し、バージョン管理をする
●Plan, Doで身の丈以上のことをやっても構わない。CheckとActionで失敗を誤魔化さずに認め、直すように動くことでプロとしての姿に近づくことができる -
要件定義が全然上手くいかなかった反省をする為に読みました。経験は非常に大事ですが、経験をする為に自ら準備をすることが重要であると知らされた気がします(今更ですが・・・)。読み終わった後、本に貼られた付箋の数がとんでもないことになっていました。
-
仕様書の書き方 というよりも、
仕様書を書くにあたっての心構えのようなことが多く書かれている