目次
まえがき
第一部 成功するSEの考え方，仕事の進め方
第1章 SEの仕事は「人」が9割
- 業務システム開発とは／業務システム開発という仕事とは／業務システム開発に関与する人々／
- SEとはどのような職種なのか／SEの定義／SEの役割の範囲／環境を作り上げる／SEの仕事はほとんどが「人」／
- 上がダメなら自分でやる／コミュニケーションが足りない／「使う人々」と「作る人々」のコミュニケーション／
- 「わからないほうが悪い」？／「知っていること」と「知らないこと」／コミュニケーションを成功させる条件／
- 立場が違えば見方も異なる／コミュニケーションの改善がすべて
第2章 失敗の原因はコミュニケーション不足
- 顧客の不満はなぜ発生するのか／不満の根拠／ほとんどが「小さな」問題／マイナス方向の「ハロー効果」／
- 原因はコミュニケーション不足／細かいところほど大事／細部までこだわった仕様を作る
第3章 マネジメントが成否の鍵
- マネジメントがすべてを左右する／業務システム開発で最も大切なこと／「作るもの」と「提供するもの」／
- 相反する要求の間で／「作る活動」と「作る活動の制御」／プロジェクトマネジャーの本当の納品物／
- プロジェクトそのものを成功させる／問われる経営者の責任／組織として「あるべき姿」／
- 上位マネジャーの役割が鍵／チームメンバーに対する考え方／マグレガーのX理論，Y理論／技術的な知識の重要性
第4章 コミュニケーション重視の会議術【準備編】
- 「会議」の定義／公式なコミュニケーションの場／従来型の会議の問題点／コミュニケーション重視の会議術／
- 事前の情報収集／収集した情報の管理／素早く情報を表示できればOK／基本的な姿勢としての「リハーサル」／
- 機材について／会議の円滑な運営に必要な機材／記録のために必要な機材
第5章 コミュニケーション重視の会議術【実践編】
- 笑顔の会議／ある失敗会議の例／リラックスできる会議／「何が原因だったか」を明らかにする／
- 繰り返される「ぶち壊し」会議／数十億円がパーになる／具体的な会議の進行／声に出して読み上げる／
- 決定事項として確定する／リズム感のある会議／会議術・議事録術の基本理念／会議でよくある問題／
- 問題が発生しないようなルールを決めておく／難しいからこそ事前の準備が大切／正しく理解してもらうための努力／
- コミュニケーション技術の向上が重要／計画技法，情報収集技法が最重要
第6章 プロジェクト初期段階の仕事術
- 最初が肝心／初顔合わせでの「質問」と「お願い」／自分自身で直接確認する／業務に関する説明を受ける／
- サンプル画面イメージの作成／提示の目的／考えを固める際の材料／開発側としての考えを固める／
- 「作れる」と思えないものは作れない／できるだけ早い段階で提示する／プロジェクト初期段階で確認できること／
- 具体的な行動によるコミュニケーション／開発側の考えについて顧客側の理解を得る／スケジュールの調整／契約前に確認しておくべきこと
第7章 成果物作成の仕事術
- SEとプログラマーのコミュニケーション／「素人にはわからない」？／作成するのは必要最小限／
- 具体的なドキュメント作成方法／明確にできることを明確にしていく／直接対話によるコミュニケーションが不可欠／
- 承認済みの自然言語表現とプログラム／プログラマーと顧客のコミュニケーション
第8章 顧客業務分析の仕事術
- 業務システム開発の最重要工程／「売り上げを送る」が意味すること／仕様変更になった場合／
- 設計書はコミュニケーションから生まれる／スタートダッシュで顧客業務を徹底理解／顧客業務の現場を見る／
- 顧客業務の理解について顧客の承認を得る／承認された顧客業務理解に基づいた要求定義／
- 「仕様を膨らまさないために」？／要求は夢も含めてすべてを話してもらう／他者の判断に頼るのは危険／
- 前提条件は必ず自分で確認する／スケジューリング等プロジェクトの最適化／要員配置を行う時期
第9章 設計・実装・テストの仕事術
- 最小限のドキュメントによる設計とリリースレベルの実装／設計の承認と実装の承認／
- 時間をかけるべきときに時間をかける／承認を得た後の作業の進め方／単なるテストでは不十分／最重要パスに焦点をあてる
第10章 プロジェクト運営の仕事術
- 開発に直接関わる人々を確認する／顧客側のユーザーを確認する／「現場主義」は「事実主義」／
- 終了までの流れをイメージする／完成したシステムをイメージする／「顧客業務の徹底理解」が不可欠／
- 問題が発生した場合／実現・管理するのは「環境」／コミュニケーションの成功を継続する責任／
- 急遽開催されることになった会議／マネジメントがうまく機能していない／いい加減な上流工程がもたらすもの／
- バグが発生する原因／SEが果たすべきマネジメント機能
第11章 業務システム開発は「伝言ゲーム」
- 現場を確認して自分で判断する／他者の判断はあてにならない／「知ること」の難しさを知る／
- 業務システム開発は「伝言ゲーム」／改善が改悪になる／なぜ同じ失敗を繰り返すのか／
- ルールは変えることができる／組織の文化が影響する
第二部 成功するSEのプロジェクト計画・運営術
第12章 名ばかりプロジェクトマネジメント
- 名ばかりプロジェクトマネジャー／「ざっくり」な「計画」で始めるのが仕事の日本のIT業界／
- 日本のIT業界のマネジメントは残念ながら最低レベル／自覚を迫られているIT業界／
- ガイドラインでかえってダメになった？／怒られないことが最優先？／日本のIT企業がNew3Kとなる要因／
- 「怒られなければいい」の先にあるもの／安易な兼務は事実軽視のあらわれ／最悪の上位マネジャーとは
第13章 誤解がプロジェクトを破綻させる
- 案外シンプルな誤解／作るべきものを明確にする／「計画」という単語のスコープ／
- 二種類の「計画」をごちゃまぜにしない／管理者層・経営者層の意識不足が失敗を招く／
- 顧客より素人の担当SE／元請けSEと孫請けSE／現場を知らない上位マネジャー／筆者が使う方法
第14章 上流工程はすべて計画活動
- 上流工程は計画活動そのもの／(1)プロジェクト目標（ゴール）の決定／(2)初期段階の計画作成／
- (3)現場見学，ヒアリング，業務分析とそのレビュー／(4)要求定義／(5)システム全体像の決定と計画作成
第15章 本当の計画，名ばかりの計画
- 失敗プロジェクトはなぜ多いのか／パーセンテージ見積りの罠／ボトムアップによる見積り／名ばかりの計画／
- できるはずのないことで怒られている／納期短縮も可能になる／作るもの自体が見えにくい／プロジェクトの「見える化」
第16章 ネットワーク図による計画作成術（アナログ式）
一 実現することを階層構造に整理する
- WBS作成／ルールは二つだけ／どの程度まで行うのか
二 ワーク・パッケージの特定とWBS辞書の作成
- いちばん下の要素／プロジェクト終了時のイメージ／○○システム一式？
三 アクティビティ・リストの作成
- 「行動」を洗い出す／客観的に行う／ビビッてはならない／伝えられないのなら，信頼して任せる／実現可能性が重要
四 プロジェクト・ネットワーク図の作成
- 実行順序を特定する／まずは普通にやる
五 アクティビティの実現に必要なものを検討する（資源見積り）
- 実現のための絶対エネルギー／コストに直接影響する事柄ばかり／人的資源が重要／CMMIの衝撃／必ずトラブルになる会社／目の前のプロジェクトよりも『日経コンピュータ』？
六 アクティビティ実行に必要な期間を割り出す
- なるべく具体的に考える／可能な限り話し合う
七 アクティビティ実行に必要なコストを算出する
- 大変な作業になる場合もある／PMBOK第3版の表現変更／理想とは程遠い現実
八 計画作業の現状を把握する
- プロジェクト全体の期間を特定／ほぼ100％結果は同じ
九 プロジェクトの最適化を検討する（重要）
十 コミュニケーションを検討する（最重要）
- 二通りの計画／コミュニケーションを検討する／トラブルで儲けようとする人たち
十一バー・チャート，コスト・ベースラインを作成する
- ここからは機械的作業／文句を言っている場合ではない
第17章 ネットワーク図による計画作成術（デジタル式）
- 一 実現することを階層構造に整理する
- 二 ワーク・パッケージの特定とＷＢＳ辞書の作成
- 三 アクティビティ・リストの作成
- 四 プロジェクト・ネットワーク図の作成
- 五 アクティビティの実現に必要なものを検討する（資源見積り）
- 六 アクティビティ実行に必要な期間を割り出す
- 七 アクティビティ実行に必要なコストを算出する
- 八 計画作業の現状を把握する
- 九 プロジェクトの最適化を検討する（重要）
- 十 コミュニケーションを検討する（最重要）
- 十一バー・チャート，コスト・ベースラインを作成する
第18章 ネットワーク図による計画の最適化
- 失敗を前提としている組織／失敗するとわかっていて引き受けたりしない
一 ネットワーク図を見極める
- 独立並行パス／集中パス／プロジェクトマネジメントパス／シリアルパス／コンヴァースパス（逆パス）
二 クリティカルパスを徹底的に増やす
- クリティカルパスとは？／どんどんつぶしていく／クラッシングとファスト・トラッキング／限界ぎりぎりを実現する
第19章 IT業界が日本を救う
- すべてが改善されていく／言い訳にならない言い訳／無策で失敗するのは必然／PMBOKで中心となっている方法／
- 失敗すべくして失敗している／「普通の」やり方では間に合わない／本当の計画活動とは／
- 失敗プロジェクトの根源はいつも同じ／感情ベースのマネジメントが主流／元請け・下請け構造の限界／IT業界が日本を救う