あなたはまだそんな「仕様書」を書いているんですか?

著者 :
  • 秀和システム
2.84
  • (1)
  • (4)
  • (7)
  • (5)
  • (2)
本棚登録 : 66
感想 : 7
本ページはアフィリエイトプログラムによる収益を得ています
  • Amazon.co.jp ・本 (279ページ)
  • / ISBN・EAN: 9784798021751

作品紹介・あらすじ

明確な共通指標を定める「コミュニケーション力」、正確でわかりやすい表現のための「文章力」、複雑な作業をドキュメントにまとめる「文書力」、変更に柔軟に対応するための「メンテナンス力」…ITエンジニアが持つべき4つのスキルでダメダメ「仕様書」を改善。

感想・レビュー・書評

並び替え
表示形式
表示件数
絞り込み
  • 着眼点、視点は面白い。
    愚痴としての読み物なのかテキストなのか焦点が絞れていないのは残念。
    上から視線なのも少し気になる。
    著者も自分で気付いている様で、あとがきで言い訳しているようだが。

  • まるで国語の勉強本。
    解りやすい仕様書を書きたいのに、文章(文書)指摘とは。
    読む本の系統を間違えた感。

    とはいえ、確かにこの本の例のような「ダメな」書き方されてる仕様書をよく見ることも事実かと。

  • 内容が抽象的で希薄。
    具体例がなく、ネット上で調べることが出来る程度の内容しか無い。
    本の煽り文句を用いれば、あなたはまだそんな書籍を出版しているんですか?と煽り返したくなる内容。

  • 「仕様書」の書き方にフォーカスしたというよりは、
    コミュニケーションの仕方や、国語や文法の基本、心構えなどを説いた
    ビジネス本としての価値のある書籍です。

    もちろんプログラマやSEをターゲットにかかれているとは思いますが、この本のインプットだけで即自分のものとなりレベルアップできる書籍でもありません。

    まさにこの本に書いてあるとおり、実際にやれるようになるには、
    地道な訓練が必要で、そのための考え方、方法論、知識の体系集といったところ。

    自身がプログラマやSEではないので、
    知らない言葉、専門用語、考え方がでてきて勉強になりました。
    日々の日報や議事録作成でも使えそうなことが盛りだくさんです。

    ただ、揚げ足とりするわけではないですが、
    著書内で、仕様書では使うな!としている、
    ・専門用語
    ・重複の意味の言葉
    ・あれこれそれどれ
    これらが、
    直後の文内に出現したり
    (「継続的に持続する」等「こそあど」言葉がでてくる)
    う~む、、、、と感じる点もアリ。

    また、内容から著者は、よほど悩める職場で働いてきたことがうかがえます。
    周りが能力や意欲の低い者ばかりでその不満を業界全体の問題としてとらえ警鐘を鳴らしています。

    「…な人間が多い」というのは
    自己の体験談を背景にしているとしか思えない内容ですが、
    私も職種は違えど似たような経験があるので、共感できました。

    無能な同僚や部下にものすごくイライラしていたであろうことが、文面からひしひしと伝わってくる内容です。(本当にしつこいくらいに)
    8割2割のパレートでいえば2割に該当する方でしょう、だからこそこのような本を出版できたのでしょうが。

    恐らくプログラマ、SEの方の場合、本のタイトルから期待する内容とは
    ズレていると思います。

  • あなたはまだそんな「仕様書」を書いているんですか?
    ●2009年4月から施行される会計基準の1つである工事進行基準では、成果物の仕様を決め、進捗率に合わせて費用計上することが決められている
    ●○○の条件ならできる、という部分否定で返さなければ何も始まらない
    ●アジャイル開発では、通常より高品質で、何度も作り直し、要望に応えるようと努力しなければならない
    ●暗い雰囲気や先行きが見えない雰囲気になった場合、意味のある発言やポジティブな発言をし、発言をしていない人を会話に巻き込むことでWin-Winのコミュニケーションを心がける
    ●情報の収集、整理、評価を繰り返し、まとめとして清書し仕様書を作る
    ●ミーティングでは目的、質問の一覧と合意事項一覧を作成して下準備をする
    ●ゼークトの組織論
    ・有能な怠け者は前線指揮官、有能な働き者は参謀、無能な怠け者は総司令官に向いている。無能な働き者。これは処刑するしかない
    ●受動態や自動詞を用いて主語を明示しないと文章は曖昧になる
    ●成果物のイメージが固まり、不明瞭な点について、その理由が明確になった上で、仕様書を書き始めるのがよい
    ●仕様書のメンテナンスでは、変更理由を示し、変更点を箇条書きにして共有し、バージョン管理をする
    ●Plan, Doで身の丈以上のことをやっても構わない。CheckとActionで失敗を誤魔化さずに認め、直すように動くことでプロとしての姿に近づくことができる

  • 要件定義が全然上手くいかなかった反省をする為に読みました。経験は非常に大事ですが、経験をする為に自ら準備をすることが重要であると知らされた気がします(今更ですが・・・)。読み終わった後、本に貼られた付箋の数がとんでもないことになっていました。

  • 仕様書の書き方 というよりも、
    仕様書を書くにあたっての心構えのようなことが多く書かれている

全7件中 1 - 7件を表示

宮古環の作品

  • 話題の本に出会えて、蔵書管理を手軽にできる!ブクログのアプリ AppStoreからダウンロード GooglePlayで手に入れよう
ツイートする
×