第1章　発注する前にこれだけは知っておこう

• 1-1　システムって何？　どうやって作るの？
• 1-2　システム開発の流れ　
• 1-3　開発形態
• 1-4　予算を立てよう
• 1-5　開発会社はどうやって探すのか
• 1-6　開発会社はどうやって決めるのか
• 1-7　見積りがきた　どうやって判断するのか
• 1-8　見積額に対する意識
• 1-9　契約書について
• 1-10　契約書について(発注後)
• 1-11　そもそもSE，プログラマってどんな人なのか

第2章　社内体制を整える

• 2-1　社内体制を整えよう
• 2-2　窓口担当者はどこまで開発知識が必要か
• 2-3　窓口担当の適任者ってどんな人なのか
• 2-4　協力体制は十分か
• 2-5　権限は与えられたか
• 2-6　仕様ってどこまで決めるものなのか
• 2-7　システムの性格を知っておこう
• 2-8　いつ，何をすればいいのか
• 2-9　元SEの発注担当者が犯しやすい間違い
• 2-10　業務フローの書き方
• 2-11　業務フロー作成手順サンプル

第3章　開発会社を見極める

• 3-1　本当にこの会社に頼んで大丈夫なのか
• 3-2　開発会社には得意，不得意がある
• 3-3　技術力だけで十分か
• 3-4　開発会社に求めるもの
• 3-5　開発会社って全て自分の会社で開発するのか
• 3-6　システムコンサルタントを使いこなす
• 3-7　システムコンサルタントを見分ける・実例・費用
• 3-8　SEと徹底的に話そう
• 3-9　SEを見極めよう
• 3-10　不安を持ったら
• 3-11　こんなことを言うSEは信用できない
• 3-12　こんなことを言うSEは信用できる
• 3-13　若いSEと年配のSEどっちが信用できるのか
• コラム　技術者の適正

第4章　イニシアティブをとろう(発注者主導で進めよう)

• 4-1　開発を依頼するときにどこまで資料を作るか
• 4-2　いつ，どの段階で契約すればいいのか
• 4-3　契約内容で気をつけることとは
• 4-4　たくさんの事例を話そう
• 4-5　SE，開発会社にどういう態度で臨めばいいのか
• 4-6　どうSEと接すればいいのか
• 4-7　どこまでイニシアティブを取ればいいのか
• 4-8　スケジュールの管理はどうやるのか
• 4-9　ユーザーインターフェース
• 4-10　中間報告を求めよう
• 4-11　定例ミーティングは必要か
• 4-12　社内に途中経過を知らせて意見を吸い上げよう
• 4-13　突然の仕様変更
• コラム　何気なく使い分けている言葉

第5章　目前の本番稼動に向けて

• 5-1　本番に向けてのテスト
• 5-2　テスト仕様書について
• 5-3　テスト中に重大欠陥が出たら−その対応，姿勢
• 5-4　ドキュメントを確認しよう
• 5-5　社内教育はどうするか
• 5-6　バックアップ体制の確立
• 5-7　検証修了書を出す
• 5-8　本番立会い
• 5-9　本番開始後のトラブル(責任分岐点)
• コラム　新しいソフトを使う

第6章　本番稼動開始後の発注担当者の仕事

• 6-1　システムをまとめよう(弱点・改善要求点)
• 6-2　システムをまとめよう(費用対効果)
• 6-3　システムの寿命−2次開発は必要か
• 6-4　データの流れを掴む
• 6-5　システムの今後を考える
• コラム　再インストールは最後の手段

第7章　ケーススタディ

• 7-1　開発直前に開発プロジェクトが中止になった！
• 7-2　複数社から見積りを取ったらかなりの差が…＜その1＞
• 7-3　複数社から見積りを取ったらかなりの差が…＜その2＞
• 7-4　分割検収，分割請求にして欲しいと言われた
• 7-5　SEに業務スキルを求めない開発
• 7-6　ビジネスショーで名刺をバラまこう
• 7-7　SEを品定めする質問例
• 7-8　データの外部流出を防ぐ
• 7-9　部分的に開発を依頼する
• 7-10　操作性を考える
• 7-11　社内ソフトを管理する
• 7-12　支社・営業所を管理
• 7-13　仕入先，販売先など取引先との提携