SE一年目のための仕様書の書き方

概 要

仕様書どおりに作っているはずなのに、なぜか予定と違うシステムができてしまう。手戻しが頻発して予算を超過してしまう。それらは曖昧な仕様書が原因です。本書は、新米SEがベテランにステップアップするのに必要な、わかりやすく誤解されない仕様書作成のポイントを解説します。開発メンバーに必要な情報を「正しく伝える」ための文章作法、仕様変更への対応方法など、システム品質を高める仕様書の書き方が基礎から身につきます。

著者 宮古環
価格 本体1800円(税別)
ISBN 978-4-7980-4167-4
発売日 2014/8/26
判型 A5
色数 2色
ページ数 224
CD/DVD
ダウンロード
表紙イメージ
購入 アマゾンで購入する
楽天で購入する

※リンク先によっては、販売ページが用意されていないことがあります。あらかじめご了承ください。

新しいウィンドウで開く 書籍購入のご案内

サポート

サポート情報は以下からご参照下さい。

サポート情報へのリンク

目次

第1章 仕様書は誰に向けて書くべきか

1-1 曖昧な仕様書が大量の「作り直し」を発生させる

■プロジェクトが失敗する原因の1つに仕様書がある

■曖昧な仕様書の4つのパターン

■なぜ誤解される仕様書が作られるのか

1-2 仕様書は誰に向けて書くべきか

■仕様書は、成果物のイメージを正しく伝えるために作られる

■仕様書を誰に向けて書くのかを把握しよう

■要件が決まらない時は視点を変えて情報を集めよう

■視点を変えるための前提条件と制約事項

1-3 理系エンジニアと文系クライアントはわかりあえない

■理系エンジニアのマインドセット

■対話を重視する理系エンジニアへの評価

■文系クライアントにトップダウンで「決めさせる」テクニック

■文系クライアントに伝えるべき5つの要素

Column 情報連携がまったくできない現場

Column テンプレートと人重視

第2章 開発の流れと仕様書の役割

2-1 要件定義工程

■要求定義書には、クライアントとの合意を記録して残そう

■プロジェクト計画書は、人のアサイン・管理に使おう

■スケジュールは、変更に強いフォーマットを使おう

■要件定義書では、絶対的なモノサシで要件を定義しよう

2-2 設計工程

■システム概要仕様書は、本当の主体を確認しながら作成しよう

■システム構造仕様書は、OSやミドルウェアについて記述しよう

■外部設計書は、ユーザー視点で設定しよう

■内部設計書は、開発に必要なものを記述しよう

■概要設計書は、システムの概要を設定した結果を記述しよう

■詳細設計書は、後工程に必要な詳細な設計を記述しよう

■データベース設計書は、開発メンバー内の調整をしてから記述しよう

■ネットワーク設計書は、論理ネットワーク図などを記述しよう

■試験項目一覧は、重要な項目を試験の観点から明確化しよう

2-3 実装工程

■実装時のトラブル管理にはツールを使おう

2-4 試験工程

■地味な作業が多い試験工程

2-5 保守運用工程

■保守運用工程には、スキルや経験が必要とされる

Column 合意していたものを武器にしてはいけない

第3章 コミュニケーションによって曖昧さをなくす

3-1 仕様書を読む人は誰かを確認しよう

■仕様書は、想定していない人が読むこともある

■どんな人がその仕様書に関わるかを考えよう

3-2 相手と会話しよう

■コミュニケーションの基本はキャッチボール

■ポジティブな会話でWin-Winのコミュニケーションをはかろう

■馴れ合いスキルを上手く使おう

3-3 仕様書でもコミュニケーションの流れを意識しよう

■仕様書の作り方もコミュニケーションの基本と同じ

■仕様書は楽して作ることはできない

■いきなり仕様書に手を付けると失敗するわけ

■コンピュータとのにらめっこは止めよう

■要件定義ができないわけ

■技法を知っても人の話が聞けるようになるわけではない

3-4 用語を統一しよう

■ツールを使って用語を抽出しよう

■ルールを決めて抽出した用語を整理しよう

3-5 仕様書の合意内容を確認しよう

■合意内容の確認は、明確なYESが出るまで何度も行おう

3-6 コミュニケーションのために積極的にドキュメントを作ろう

■品質の高い仕様書は、3段階のステップで作成しよう

3-7 議事録を書こう

■記事録は下準備をしておくと、時間を効率的に使える

■ミーティングの終了間際に内容を再確認しよう

■議事録は、結果をまとめてシンプルに書こう

■訓練すれば、議事録は早く書ける

3-8 レビューできますか?

■レビューによって、仕様書の精度を上げよう

■レビューに合わせてアジェンダを作っておこう

■レビューには、前向きな発言ができる人を選ぼう

■読み手の観点で仕様書をレビューしよう

■揚げ足取りにならないように意見を述べよう

3-9 疑問や不明な点を残さない

■気軽に質疑応答ができる雰囲気を作ろう

■「わからないこと」を一緒に分解しよう

■「わからないこと」はどうすれば解決するのか

Column 笑顔を増やそう

第4章 誤解されにくい文章を書く

4-1 用語の意味を理解して使いこなそう

■用語は、相手に伝わるように的確に使おう

■熟語とカタカナ言葉は、使うのを控えよう

4-2 相手に伝えようという姿勢を心がけよう

■普段から、ほかの人とコミュニケーションをとろう

■問題の解決は、すぐにはできない

4-3 悪文は直せる

■悪文を直すポイントは、主語と述語

■わかりづらい表現とその対策

4-4 文章は的を絞り、論理を積み上げよう

■文章は、流れや関連性に注意しよう

■強調したい部分は、箇条書きにしよう

■数学の集合を意識して、文を接続しよう

■文章は、的を絞りながら書こう

■論理を小さく積み上げていくには、骨組みが必要になる

4-5 文章のテーマとトピックを決めよう

■文章のテーマを絞ろう

■文章のトピックを決めよう

■文章を書こう

4-6 良い文章をお手本にしよう

■良い文章をひたすら真似しよう

■文から文章へ、文章から文書へ

■地道に文章力を磨こう

4-7 KJ法やマインドマップで情報を整理しよう

■チームワークを簡単に生み出すKJ法

■KJ法のやり方

■KJ法にも欠点がある

4-8 文章が書けない本当のわけ

■文章力を磨くには、時間がかかる

Column たまには紙を使って対話をしてみよう

Column 的を絞るイメージ

第5章 読みやすい書類にまとめる

5-1 文章を文書に仕上げよう

■文章にヘッダーや図表を加えて文書にまとめよう

■文書はヘッダー、本文、フッターの3つに分けて書こう

■フォーマットは、文章の関連性の説明が不要な場面で使おう

■設計書などではフォーマットをカスタマイズして使おう

■成果物のイメージが共有できてから仕様書を書き始めよう

5-2 設計書と設計図は違うもの

■設計書と設計図は、分けて管理・作成しよう

5-3 要件定義書は専門用語を使わずにまとめよう

■クライアントがわかる言葉で記述しよう

■要件のチェックリストを作ろう

5-4 提案書では事実と考察は分けて書こう

■提案書は相手の立場を尊重して書こう

■事実と考察は分けて書こう

■プレゼン資料は、スライドの流れを考えて作ろう

5-5 RFPでは改善する個所や不明点を明らかにしよう

■RFPは、要件の評価基準を定義してから書こう

■PFPでは、留意事項や瑕疵責任なども忘れずに書こう

■RFPの作成にKJ法を使うことを検討してみよう

5-6 計画書のスケジュールは進捗の指標になるように作成しよう

■計画書のスケジュールは、重要な節目だけ正確に書こう

■表と文章を併用しよう

■複数のスケジュールを想定しておこう

5-7 手順書は作業する人の視点で作成しよう

■手順書は、前提条件と例外を想定して書こう

■変化を許容できるフォーマットで書こう

■スクリーンショットは、Excelとフリーウェアを使おう

■手順書には、問題発生時の復旧手順も書いておこう

5-8 仕様書を読んでもらうための仕掛け

■積極的にプレゼンテーションの場を設けよう

5-9 クライアントの言質を取ろう

■スケジュールや時間を盾にクライアントの言質を取ろう

■クライアントの言質は、後に残る形で残そう

5-10 仕様書を開発者の自己保身のために使ってはならない

■価値観が違う人でも、すり合わせできる開発者になろう

第6章 仕様変更に強くなる

6-1 仕様の変更理由、変更点、バージョン管理が基本

■仕様変更があった時は、その理由を明確にしよう

■仕様書を変更せざるを得ない状況とは

6-2 仕様書の扱いに注意しよう

■内部資料であれば、仕様「書」にこだわる必要はない

■仕様書を使わない場合の注意点

■仕様書のマスターは一元管理しよう

6-3 クライアントのイメージが固まっていると変更に強い

■変更が多い仕様書とそうでないものの差

■なぜWBSが作れないのか

■変更に強い仕様書を作ろう

■仕様書の全体量が決まらない理由

■仕様書の質が決まらない理由

6-4 小さくPDCAサイクルを回そう

■PDCAサイクルとは

■PDCAサイクルに失敗する理由

■PDCAサイクルで自分の身の丈を測定をしよう

6-5 失敗は失敗した本人ほどわからない

■IT技術の加速はモラルの低い人を量産するのか

■IT業界に広がる被害妄想の蔓延

■情報共有の加速によるダメダメスパイラル

Column 意外とされない変更管理

PR

秀和システム