はじめに

第1章 チームの構築とスケジュールの立案

1 ソフトウェア開発を成功に導く道程 12

■ 現代が求める情報処理技術者とは 12
■ ソフトウェア開発の現場で見られる「あんな失敗」と「こんな原因」 14
■ ソフトウェア開発を成功に導くためには 15
コラム●統計データで見る情報サービス業 16

2 ソフトウェア開発のプロジェクトとは何か 18

■ プロジェクトを5W2Hから考える 18
■「プロジェクト計画書」作成に当たって 19
■ リーダーシップを発揮する 21
■ 適切なプロセスモデルを選ぶ 21
■ プロジェクトを通して注意すること 24
コラム●プロジェクトはスタートが肝心 25

3 効率的でコミュニケーションのよいチームを作り、運営する 26

■ プロジェクトチームの編成に際して 26
■ コミュニケーションを強化する 28
■ 会議を効果的に利用する 32
■ ソフトウェア開発規模の大小による責任の違い 34
コラム●「性格」を考えてチームのメンバーを選ぶ 35

4 顧客との間やサブプロジェクトチームとの間で協調体制を構築し、維持する 36

■ 顧客側と開発側との考え方のギャップ 36
■ 顧客にも自分の役割を認識してもらう 37
■ 見直し体制の構築と窓口の一本化 39
■ 他のサブプロジェクトチームも“お客様” 39
コラム●運用チームへ易しいシステムを引き渡す 40
■ プロジェクトを兼任する時に気をつけること 41
コラム●顧客どうしの力関係を把握する 42

5 現実的で妥当なスケジュールを立案し、守る 43

■ プロジェクトにはリスクが多い 43
コラム●合理性をもったリスク基準を作る 44
■ 見積り技法を理解する 45
■ チームのスケジュールを作成する 47
■ クリティカルパスに注目する 49
コラム●PERTを作り上げるポイント 50
■ 時間見積りの精度を高める 52
コラム●「楽観的スケジュール」には要注意 53
■ 自分の役割に責任をもち、最後までやり遂げる 54
コラム●プロジェクト崩壊という危機的状況からの脱出 56

第2章 要求定義から設計へ

1 要求定義工程の進め方 60

■ 要求定義の位置づけと作業内容 60
■ 要求定義に関連する3つの問題 61
■ プロジェクトの目的と利用者の明確化 62
■ なぜ現状分析が必要か 63
■ DFDとER図で新しい業務システムを検討する 65
■ 要求仕様を具体化するプロトタイピング 67
■ システム化要件の明確化 68
コラム●開発過程とプロトタイピング 68
■ 効果の推定 70
コラム●オブジェクト指向分析と設計 72

2 要求定義工程を効果的に進めるポイント 74

■ 終了基準を明確にする 74
■ 業務改善への提案活動 74
■ 要求定義の課題を管理して遅延を防止 77
コラム●Webアプリケーションの開発　その1：開発のポイント 79
コラム●Webアプリケーションの開発　その2：情報技術の選択 80

3 外部設計工程の進め方 82

■ 設計工程の位置づけ 82
■ 外部設計の作業と手順 82
■ システム方式の選択 82
■ サブシステムに分割 84
■ 新しい業務システムの設計 85
■ わかりやすいユーザインターフェース設計を行うには 85
■ コード設計は追加・変更を考慮する 88
■ 他システムと連携するインターフェース設計 89
■ セキュリティ設計 90
コラム●Webアプリケーションの開発　その3：セキュリティ 91
■ データベース設計はデータ蓄積・活用の要 92
■ 通信ネットワーク設計はネットワーク技術者と共同で 94
■ 運用・障害設計 95

4 内部設計工程の進め方 96

■ 内部設計の作業と手順 96
■ モジュール化のガイドライン 97
■ データベースの物理設計 101
■ パフォーマンス／キャパシティの分析 102

5 設計工程を効果的に進めるポイント 104

■ エラーが入り込むのを防ぐ 104
コラム●ウォークスルーとインスペクション 106
■ 設計標準の作成と遵守が品質を向上させる 108
■ 変更しやすく、保守しやすい設計とは 108
■ プログラミングに入ることを急がない 109
■ 設計工程は業務設計だけではない 110
■ 仕様の合意で顧客満足を確保 110
■ 仕様の変更要求を管理 112
■ 変更管理の対応ポイント 114
コラム●仕様変更の提案が吉と出たケース 115

6 開発・テスト工程につなぐ 116

■ 局面の終わりで計画の見直し 116
■ 開発・テスト計画の作成 117

第3章 プログラミング工程

1 プログラミング工程とは 120

■ プログラミング工程における理想と現実 120
■ 想像力が求められる 120
■ コミュニケーションの重要性 121

2 準備段階〜標準化と共有化〜 122

■ 標準を策定してバラツキを抑える 122
■ 知識共有環境の整備 126
■ リポジトリを整備する 127
■ 統合開発環境の活用で効率化を図る 131
コラム●統合開発環境の種類 132
■ 開発環境と本番環境の差異に注意 136

3 プログラム詳細設計では内部仕様書を詳細化する 138

■ 詳細設計の技術的側面 139
■ 詳細設計の管理的側面 139

4 コーディングのポイントは何か 141

■ コーディングの技術的側面 141
■ コーディングの管理的側面 144

5 単体テストでモジュール内部の不具合を一掃する 147

■ 単体テストの技術的側面 147
■ 単体テストの管理的側面 148

6 実運用を見据えて準備する 150

■ 文書作成 150
■ 導入支援ツール 151
■ 運用支援ツール 152
コラム●システム開発と徹夜の蜜月 154

第4章 テストから稼動まで

1 ソフトウェアの品質とテストの意味づけ 158

■ テストは簡単にはできない 158
コラム●テストには全体の半分近くの工数が必要となる 159
■ テストは誰が実施するのか 159
■ ソフトウェアの品質とは 160
■ 品質の作りこみとテスト工程 161
■ 完璧なテストはむずかしい 162
■ 大きな障害を起こす欠陥をなくす 163

2 テストの計画と設計 166

■ テストを計画・設計する 166
■ テストシナリオとテストデータ 167
■ システムのバグや障害の影響を理解する 168
コラム●なぜ合格者を不合格にしてしまうのか 170
コラム●設計書では「なぜそうなっているのか」が大切 171
■ ホワイトボックステストとブラックボックステスト 171
■ 開発環境とテスト環境 173
■ テストに必要な時間を確保する 174
■ リグレッションテストの計画 175
■ システムのインターフェースをテストするコツ 175
コラム●コンピュータ・バリデーション 177

3 テストの実施 178

■ テスト実施の前に 178
■ ボトムアップテストとトップダウンテスト 178
■ さまざまなテスト支援ツールの活用 178
コラム●作ったところと「使うところ」 180
■ リスクを意識しよう 181
■ テストで発見されたバグの修正 182
コラム●問題管理の要点 184
■ テストで見つかったバグの水平展開 185
■ 再現しない問題への対処 185
■ 複数バージョンの管理 187
■ 本稼動でしか起こらないトラブルの未然防止 188
■ テスト工程の効率を高めるために 189

4 運用テストから稼動まで 191

■ 運用テストはシステムの使用者が主体となる 191
■ 運用テストでは業務のテストを行う 191
コラム●システムと業務は一体 193
コラム●βテスト 194
■ 本稼動に向けて 194
■ テスト設計・実施上の留意点 195

5 システムの移行 198

■ 移行は難しい 198
■ 移行計画を作成する 199
■ 移行データを絞り込む 200
■ 移行のプログラムと移行のテスト 200

6 いざ本稼動へ 202

■ テストの経験を運用に活かす 202
■ 本稼動後は顧客側企業の所有物 203
■ 設計の仮説を確認する 204
■ ユーザが気づかないところを確認しておく 205
■ 保守の時にドキュメントの質が問われる 206
■ 次のプロジェクトのために 206
コラム●チェンジ・マネジメント 208
コラム●情報システムは導入してからが大切 209

第5章 ソフトウェア開発　最近の話題から

1 発展するソフトウェアエンジニアリング 212

■ 4つの観点 212
■ 新しいソフトウェア開発技術 212
■ 新しい情報技術 213
■ 新しい開発管理技術 213
■ 開発スキル 214
■ 詳細を学びたい方のために 215

2 オブジェクト指向技術の最近の動向 216

■ オブジェクト指向技術の展開 216
■ Java開発環境 217
■ 現在の主要な技術 217

3 XP（エクストリームプログラミング） 220

■ XP（eXtreme Programming） 220
■ リファクタリング（Re-factoring） 225

4 Webサービス〜ソフトウェア再利用の新しい潮流〜 226

■ インターネット上で実行された状態のまま利用する 226
■ CORBAやDCOMと何が違うのか 227
■ Webサービスを支える3つの基本アーキテクチャ 227
■ eビジネス時代のソフトウェア開発 228
コラム●Web環境に対応したVisual Studio .NET 229

5 セキュリティ技術 231

■ 従来からのセキュリティ対策 232
■ インターネットセキュリティ対策 234
コラム●P2Pとグリッドコンピューティング 239

6 ソフトウェアパッケージを使ったソフトウェア開発 241

■ ソフトウェアパッケージ活用の効果 241
■ ソフトウェアパッケージの選択 242
■ 導入手順 244
■ 導入上の留意点 245

7 CMMからCMMIへ〜ソフトウェア開発プロセスの改善に向けて〜 248

■ 問題のある組織に共通していること 248
■ 世界的なCMMの広がり 249
■ 日本におけるCMMへの取組み 249
■ CMMからCMMIへ 250
コラム●SPIとSPA 252
コラム●ISO/IEC 15504とは何か 253
■ CMMとISO9000sの違い 253
■ 組織と個人、それぞれが継続して取り組むSPI 254
コラム●SWEBOK 255

8 ソフトウェア構成管理 258

■ ソフトウェア構成管理（SCM）とは 258
■ ソフトウェア構成管理の機能 259
■ 標準化とソフトウェア構成管理 260
■ 開発プロジェクトでの実践 261

9 クリーンルーム手法〜欠陥ゼロのソフトウェア開発〜 264

■ テストなしにソフトウェアを完成させる 264
■ チーム体制 264
■ クリーンルーム手法の4つの特徴 265
■ インクリメンタル開発プロセス 265
■ ボックス構造分析 265
■ 関数等価性検証 267
■ 統計的品質管理 267
■ クリーンルーム手法に学ぶこと 268

10 クリティカルチェーン〜TOCのプロジェクト管理手法 269

■「部分最適化」vs「全体最適化」 269
■ PERTの問題点とは何か 270
■ スケジュール立案の考え方、進め方 271
■ 進捗管理のポイント 273
コラム●TOCの原点「TOCの生産管理手法」とは？ 274

11 情報処理技術者スキル標準とITスキル標準 276

■ 情報処理技術者スキル標準の目的 276
■ 情報処理技術者スキル標準の概要 278
■ ITスキル・スタンダードについて 278

12 情報処理技術者試験とITコーディネータ 280

■ 情報処理技術者試験の沿革 280
■ スキルに応じた試験区分 280
■ 試験結果について 282
■ ITコーディネータと情報処理技術者 282
■ ITコーディネータへのキャリアパス 282

第6章 SEへの期待

1 ソフトウェア開発の顧客とは? 286

■ SEにとっての顧客とは？ 286
■ 顧客側の期待することは一致するとは限らない 287
■ 顧客自身が担う重要な役割 289
■ 顧客の作業を盛り込んだスケジュールの作成 290
コラム●経営者や管理者がソフトウェア開発に対して消極的なケースとその対応策 291

2 顧客が満足するソフトウェアとは? 293

■ 顧客にとってよいソフトウェアとは? 293
■ ソフトウェアの品質と顧客満足 293
コラム●ソフトウェアに対する要求の変化 295

3 ソフトウェア開発段階における顧客満足 296

■ 納期と機能・・どちらを優先するか 296
■ 納期が守れない時の対処方法 297
■ 要求定義の進め方 299
コラム●顧客にとって当たり前の要件とは？ 300

4 ソフトウェア利用における顧客満足 301

■ 利用者のスキルに応じた機能と操作性 301
コラム●画面の前から発想する 303
■ 操作研修（トレーニング）の進め方 304
■ 使いやすいマニュアルの作成 305
コラム●「それは何ですか?」 308

5 ソフトウェア運用保守における顧客満足 309

■ 運用管理しやすいソフトウェア 309
コラム●システムのアウトソーシングについて 310
■ ソフトウェアの保守とは 310
■ 修正のための保守 311
■ 改訂のための保守 312
■ システム障害に対応するために 312
■ 不慮の事故や災害からの復旧（ディザスタリカバリ） 313
コラム●保守地獄で泣かないために 314

6 社内の利害関係者がSEに期待すること 315

■ プロジェクトチームにおける役割を果たす 315
■ 納期やコストを守る 316
■ ソフトウェア開発のリスクに対処する 317
■ 開発の後工程を意識する 319

7 ソフトウェア開発で自分の役割を果たす 321

■ プログラマ、SEなど自分のチームの開発能力を把握する 321
■ チームの結束力を高める 322
■ チームメンバーの能力にあった目標を設定する、ジョブを割り振る 322
■ 進捗管理と情報の共有化を行う 323
■ 無駄を減らし、生産性を高める 323
コラム●「個」を活かす「コーチング」とは 324
コラム●あなたは次のことを継続していますか？ 324

8 顧客とうまくつきあうために 325

■ 顧客のことをよく知る 325
■ 顧客との円滑なコミュニケーション 325
■ 顧客との信頼関係構築 326
■ ソフトウェア開発における顧客の特質を理解し、対処する 327
コラム●SEが身につけたいスキル 328
コラム●プロのSEは真のユーザニーズを掘り起こす 329

付録　さらに勉強したいSEのみなさんのための推薦書 331
あとがき 339
索引 340
執筆者略歴 348

※執筆者（敬称略）
　編集　浜崎正和／中村実
　執筆　陸井浩三／野末泰弘／正田耕一／中村実／安藤秀樹／坂田岳史／杉村麻記子／中村一世／浜崎正和