商品の詳細

• Amazon.co.jp ランキング: #412636 / 本
• 発売日: 2003-10-16
• 版型: 単行本
• 256 ページ

日経BP企画
実践！システムドキュメント徹底活用
システム設計書や操作マニュアルなど「SEが書くドキュメント」の作成ノウハウを解説。前半では初歩的なビジネス文書の書き方を、後半ではドキュメント作成の勘どころを整理するとともに、模範的な文書の事例を数多く紹介している。活用されるドキュメントを作成するには「なぜ書くのか」、「なぜ標準化するのか」など、「なぜ」を5回繰り返す必要があると主張する。ドキュメント作成の本質を知るうえで必読といえる。

（日経コンピュータ 2003/12/01 Copyright©2001 日経BP企画..All rights reserved.）

出版社/著者からの内容紹介
システム設計もテストも品質管理も、ドキュメント一つでムダ＆ミスを一掃！

本書ではSEが現場で書く、設計工程やプログラミング工程に含まれる「システムドキュメント」について解説しています。設計のムダとりのポイントはどこか？仕様書の項目をどうするか？テスト計画書になにを書くか？標準化とはいったいなにか？システム開発の設計・運用の効率がグンッとあがる方法をエキスパートが伝授！また若手SEが陥りがちな設計ドキュメントの悩みと解決方法、運用ドキュメントの改善への取組みをケーススタディとして実録した「システムドキュメント」を完全制覇！

内容（「BOOK」データベースより）
本書では「ドキュメント」をSEが現場で書く、設計工程やプログラミング工程に含まれる設計書・テスト計画書・操作マニュアル・各種ミーティング資料や議事録に特化している。「間接業務の圧縮(ドキュメント作成業務)」と「ドキュメントの質的改善」により、いかにシステム開発の生産性は高まるのか?本書では、SEとしての文章力の基礎と向上、システムドキュメント改善への取組み方、設計書様式の工夫による設計品質向上、テスト計画書様式の工夫によるテスト品質向上を網羅し、解説。また若手SEが陥りがちな設計ドキュメントの悩みと解決方法、運用ドキュメントの改善への取組みをケーススタディとして実録。

カスタマーレビュー

いまいち。
P58、「トヨタの5W(5回のWhy)で設計書を考えよう」と自分で言いつつ、「誰が」「いつ」「何を」「どう」という一般の5W1Hでリストアップしている。

他にも抽象論と具体論のバランスが悪いし、話の粒度が揃っていない（本書で紹介されている言葉を使えばパラレリズムが合っていない）。筆者のドキュメント作成能力に疑問を感じる。

例えばP70からP73。
(3)「転記を減らす」は2/3ページで終わり、
(4)「変更しやすく」では3ページ使い、「ドキュメントの変更のしやすさ」と「変更作業のしやすさ」に分けて、Excel の画面イメージ付でシートは分割しない方が一元管理できていいなんて書いてあったり、変更するならテーブル定義書参照ね、とテーブル定義書のサンプルがでかでかと載せている。
そもそも(4)を２項目に分けているにも関わらずそれが小見出しや箇条書きになっていないし、２項目に分ける意味も感じられない。シート分割するなってのもエンジニアなら One Fact in One Place なんて常識だし、変更時にテーブル定義書を参照すればいいって、それで十分だという保証はどう取るというのだろう。
さらに現場で使われる言葉を選ぶなら変更性でなく保守性だ。
(4)で中身のないことにページを裂くなら、(3)でセル参照やマクロを用いた自動転記を紹介しないのは何故だろう。それこそドキュメントを標準化することによる恩恵だというのに。

…と、いうようにツッコミどころ満載。

一般的なドキュメンテーションに関する本や実践性の高い Excel 本、トヨタ生産方式のホワイトカラー適用指南書を選んだ方がよい。

具体例も不足
著者に文章力・構成力があるのか疑問を感じた。
例えば、「SEのための文章力基礎講座」なる章があるが、その中に「データシミュレーションのススメ」というテストの一種の紹介を、中途半端な内容でなぜ含めたかわからなかった。
また、10ページ最後に「・・・その答えは・・・」の前後のつながりと文の表現が私には不自然に感じた。
その他、「付加価値」という表現が誰が何を基準としてのものかはっきりせず、「付加価値は『プログラム開発のみである』ことを自覚すること」とはどういうことなのだろうか。要求定義、分析、設計には、著者の「付加価値」がないのだろうか。

著者自身が、「文書力の３つのポイント」として著していることと矛盾する表現が多い。
例えば、「自動化（ニンベンのある自動化）」という表現の「（ニンベンのある自動化）」の意味はわからなかった。
「レビュー」の意味についても著者の世界での話となっている。

全般的に、著者のかなり偏った知識でもって記述されている。
特に開発工程に関しての説明・表現は不適切で、さらに著者自身の考え方が古い
（著者が著したかったであろう開発工程自体が古いという意味ではない）。

開発工程の各段階で必要となるドキュメントの理想的な記述項目やフォーマットを著したものでもないし、「模倣」する「システムドキュメント」の種類はほんの少数しかなく、「徹底活用」するには無理がある。

著者の部下向けに書かれた書物であろうか。

徹底活用という主旨とは違いますが使える本です。
個人的かも知れませんが徹底活用と言われると“外部設計書を運用マニュアルに簡単にシフトできる書き方”とか“外部設計書をそのまま結合テスト計画書に引用できる書き方”なんてものを想像して本書を購入しましたが「ドキュメントの標準化」をベースにかかれている本です。

「有効なドキュメント標準化のしくみ」を持たないシステム関連の企業や部門が標準化を考えるにはかなり具体的でわかりやすいと思います。機能分類（GUI、バッチなど）ごとに用意する設計書を変えるところなどはきっちり納得がいきました。

結構お勧めだと思います。タイトルと内容が違うと感じたので星４つです