まえがき

第一部　成功する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業界が日本を救う

あとがき