出版社内容情報
.NET やJavaをはじめとする昨今の開発技術は、数十年前に比べて大きく進化している。モノ作りのやり方が変われば、設計手法やプロマネ手法（いわゆる『SI技術（システムインテグレーション技術）』）もそれに合わせた見直しが必要になる。にもかかわらず、日本のSI業界では未だ旧石器時代的なSI手法を確たる根拠もなしに続けているケースが少なからず見られる。これではいつまでたっても非効率的なExcel 設計書とExcelテストから脱却できるはずがない。
近代的な開発技術の進化を理解し、SI技術を進化させ（＝近代化し）、エンドユーザー企業に対してそのメリットを提案していくのは、IT部門やSI関連会社、SIerの責務である。
本書は、日本のSI業界における多重請負構造を前提条件とした上で、近代的な業務システム開発に必要となる基礎知識やノウハウ（SI技術）を幅広く提供する。これにより、多重請負構造の上流の立場にあるIT部門やSIerのプロパーが、システム開発を正しい方向に導き、開発現場を近代化できるようになることを目指すものである。
第1章 開発プロセスとV字型モデル
1.1 V字型モデルと開発プロセスの関係
1.1.1 開発プロセスとは何か
1.1.2 計画型プロセスと適応型プロセス
A. ウォータフォール型
B. スパイラル型
C. アジャイル型
1.1.3 V字型モデルの抱える基本的な問題点
1.2 SoR型システム開発とSoE型システム開発
1.2.1 アプリケーション特性に応じたシステム開発の分類
1.2.2 実際のシステム開発市場の状況
1.3 まとめ
第2章 フェーズとロールモデル
2.1 業務アプリケーション開発の2つのストリームと5つのロール
2.1.1 業務アプリケーション開発の2つのストリーム
2.1.2 業務アプリケーション開発の5つのロール
A. 業務SE
B. アーキテクト（アプリケーションアーキテクト）
C. デベロッパー
D. テスター
E. プロジェクトマネージャー
2.1.3 チーム編成に関する注意点
A. アーキテクトとデベロッパーの違い
B. プログラマーとデベロッパーの違い
C. デベロッパーとテスターの違い
D. ロール間の職能的上下関係
E. ロールの兼務
F. 専門性を意識したアサイン
2.2 WBSの基本骨格構造
2.2.1 WBSの基本骨格構造の組み立て方
A. 最も基本的なマッピング
B. システムテストの前倒し実施
C. 不足作業の補完
D. 各タスクでの成果物の定義
2.3 まとめ
第3章 各タスクの実施の要点
3.1 要件定義
3.1.1 要件定義とは
3.1.2 主なアウトプット
A. 機能要件定義書（システム化対象業務一覧）
B. 非機能要件定義書（品質要求一覧）
C. システム概要図
3.1.3 主な課題と注意点
A. 精度の高い機能要件定義の実施方法
B. 要件の変更管理
C. システム中心設計とユーザー中心設計
3.1.4 要件定義のまとめ
3.2 外部設計
3.2.1 外部設計とは
3.2.2 外部設計のゴール
A. お客様価値の追求
B. システム構造の安定性（保守性）の確保
3.2.3 スタック構造の明確化と設計・実装連続性の確保
3.2.4 主なアウトプット
A. 共通業務設計書：論理データモデル
B. 共通業務設計書：共通業務ルール
C. 個別業務設計書：画面仕様書
D. 個別業務設計書：機能仕様書
3.2.5 主な課題と注意点
A. 手戻り軽減のための作業手順
B. 画面コンセプト（ユースケース）の明確化
C. 軽量な画面設計プロセス
D. デベロッパーとの「意図共有」の進め方
E. データ辞書の必要性
F. 論理データモデリングのポイント
G. デザイン会社との協業とUI デザインの標準化
H. ユーザビリティテストの必要性
I. 実装可能性と実装効率
J. 一般画面と重要画面の分類
3.2.6 外部設計のまとめ
3.3 方式設計
3.3.1 方式設計とは
A. 方式設計作業の進め方
B. アーキテクチャとフレームワーク
C. （参考）様々なアーキテクチャについて
3.3.2 アプリケーションアーキテクチャキューブ
A. レイヤ化原則（積層構造原則）
B. 3つの積層軸とアプリケーションアーキテクチャキューブ
C. アーキテクチャキューブによる設計問題の解釈
3.3.3 方式設計のポイント
A. 利用するコンポーネント種別の決定
B. 典型的な処理パターンの設計方法の決定
C. ソリューション・プロジェクトの構成方法の決定
D. 物理配置指針の決定
E. 共通基盤機能の開発
3.3.4 主なアウトプット
A. アプリケーションアーキテクチャ解説書の作成
B. 共通基盤機能（追加・拡張フレームワーク）の開発
C. 開発ガイドライン（内部設計・実装ガイドライン）の作成
D. サンプルアプリケーションの開発
3.3.5 主な課題と注意点
A. アーキテクトロールの泥臭さ
B. 必要十分にシンプルなアーキテクチャ
C. 業務SEチームとの連携
D. 上級デベロッパーとの協業
3.3.6 方式設計のまとめ
3.4 内部設計
3.4.1 内部設計とは
A. 基本的な内部設計の考え方
B. 内部設計の担当者
C. 実際のアプリ開発における内部設計の進め方の工夫
3.4.2 主なアウトプット
A. モジュール構成図（クラス図）
B. シーケンス図
C. 処理パターン分類表
D. フローチャート
E. インタフェース仕様（メソッドシグネチャ）
3.4.3 内部設計書の作成
A. 内部設計書の特性
B. 内部設計書の作成目的の明確化の必要性
C. 正しく実装されないリスクの低減
D. 複雑な重要画面を開発する際の設計意図の記録
3.4.4 作業の進め方と主なアウトプット
A. 基本的な作業の進め方
B. UI/BC/DACへのモジュール分解
C. BC/DAC部の内部設計
D. UI部の内部設計
3.4.5 内部設計のまとめ
3.5 実装・単体機能テスト
3.5.1 実装・単体機能テストとは
3.5.2 ソースコード管理（チームでの資産管理）
A. ソースコード管理システムの基本的な動作特性
B. ソースコードの陳腐化とビルドブレイクの発生問題
C. 日中日次ビルド（Daily Build）
D. 継続的インテグレーションとゲートチェックイン
E. 集中管理型ソースコード管理システムと分散管理型ソースコード管理システム
F. ブランチ戦略
3.5.3 自動ビルドとカナリアサーバー（開発状況と品質の可視化）
A. カナリアサーバーによる定性分析
B. 自動ビルドサーバーにおける定量分析
3.5.4 デバッグと単体機能テスト（効率的なバグ出し）
A. デベロッパーとテスターの役割分担
B. モジュール別テストによるBC/DACの単体機能テスト
C. UIデバッグの効率化のための単体機能テスト
D. 単体機能テストの記述に関するルール
3.5.5 主な課題と注意点
A. クラウド環境とクラウドサービスの活用
B. ペアプログラミングやコードレビューの重要性
C. テストケースドキュメントの執筆
3.5.6 実装・単体機能テストのまとめ
3.6 結合機能テスト
3.6.1 結合機能テストとは
A. 本書における結合機能テストの定義
B. 単体機能テストと結合機能テストの基本的な違い
C. 結合機能テストに必要な3つの基本的なツール
3.6.2 単体機能テストと結合機能テストの違い
A. デベロッパー／テスター間でのテストケースの重複問題
B. 単体機能テストと結合機能テストの違い
3.6.3 テストケースの設計技法
A. 網羅性と効率性
B. 網羅性を高めるための主な技法
C. 効率性を高めるための主な技法
3.6.4 具体的なテストケースの設計例
A. 単体機能テストのテストケースの設計例
B. 結合機能テストのテストケースの設計例
3.6.5 打鍵テスト支援ツールの活用
A. 打鍵テスト支援ツールとは
B. 打鍵テスト支援ツール導入の必要性
3.6.6 UIに対する自動テストツールの活用
A. アプリ特性によるUI テスト自動化の向き不向き
B. リグレッションテスト（回帰テスト）と互換性テストの違い
C. 互換性テストのためのテストケース選定
D. UIテスト自動化ツール選定のポイント
E. UI自動化テストスクリプト開発のコツ
3.6.7 テスト戦略とテスト計画（濃淡付けと優先順位付け）
A. 濃淡付けと優先順位付けの必要性
B. 代表的な濃淡付けの手法
C. 代表的な優先順位付けの手法
D. テスト戦略とテスト計画
3.6.8 適切なバグ管理とNo Repro問題の防止
A. デベロッパーチームとテストチームの役割分担の明確化
B. バグ票に記載すべき内容の明確化
C. ラボ環境の活用
3.6.9 品質評価データの蓄積と分析のポイント
A. 品質評価データの蓄積の重要性
B. 品質評価データの分析のポイント
C. 工程終了判定の考え方
3.6.10 その他の課題と注意点
A. テストツールに関する全社標準化のポイント
B. クラウド環境とクラウドサービスの活用
C. 非互換問題を起こしにくい業務アプリを作るためのポイント
D. SI における協力会社からの納品物の再定義
3.6.11 結合機能テストのまとめ
3.7 システムテスト
3.7.1 システムテストとは
3.7.2 代表的なシステムテスト
3.7.3 非機能要件と評価方法の定義
3.7.4 一部のシステムテストの先行実施
A. パフォーマンステスト（性能テスト）
B. セキュリティテスト
C. ユーザビリティテスト
3.7.5 一部のシステムテストにおけるテストチームの役割
A. セキュリティテスト
B. ユーザビリティテスト
3.7.6 システムテストのまとめ
3.8 （参考） インフラ・運用管理設計
3.8.1 運用環境第一主義（Production First Mindset）
A. ユーザーフィードバックの重要性
B. ユーザーフィードバック収集の難しさ
C. 運用環境第一主義（Production First Mindset）とは
D. 運用環境第一主義（Production First Mindset）の実現手法
E. 実際の開発現場とのギャップ解消の必要性
3.8.2 インフラ設計のポイント
A. PaaS技術の活用の必要性
B. イミュータブルインフラストラクチャー
C. IaC（Infrastructure as Code）
3.8.3 運用管理設計のポイント
A. 開発系エンジニアが知っておくべき代表的な運用管理タスク
B. 運用管理タスクの役割分担
C. クラウドを活用する際の各運用管理タスクの要点
3.8.4 （参考） インフラ・運用管理設計のまとめ
第4章 システム開発現場の近代化に向けて
4.1 SIerとエンプラ系システム開発現場の課題
4.1.1 技術革新の恩恵を享受できない開発現場
4.1.2 多重請負構造の問題
4.2 SoR型システム開発における更なる開発生産性の改善
4.2.1 SoR型システム開発の本質的な難しさ
4.2.2 組織的に取り組むべきポイント
A. 中堅層のプロマネや業務SEの再教育
B. アーキテクトの育成
4.2.3 プロジェクトの中での取り組み
A. 初級エンジニアの設計・実装スキルの底上げ
B. 成果物の品質確保プロセスの作り込み（開発プロセスのテーラリング）
4.3 先進的ビジネスのためのSoE型システム開発への取り組み
4.3.1 SoE領域におけるビジネス創出の難しさ
4.3.2 SoE領域において重要な3つの取り組み
A. 最新テクノロジの要点の理解
B. ビジネスニーズの深掘り
C. プロトタイプによる概念検証
4.4 現場エンジニアに求められる心構え
4.4.1 生産性（スキル）の重要性
4.4.2 座学とOJT のバランス
4.4.3 専門性を意識したスキルアップ
4.5 マネジメント層に求められる役割
4.5.1 組織的な技術力の維持・向上
A. 過度なアウトソースの抑制
B. 自律的な組織作り
4.5.2 新しいビジネスアイディアの具現化
A. 実プロジェクトにおける開発プロセスのテーラリング
B. 大きなTry & Errorを必要とする先進的なシステム開発の分離
C. プロジェクトノウハウ共有の必要性
D. バーベル戦略による投資判断
4.6 会社としてのビジョンとロードマップ策定の必要性
4.7 現場エンジニアとマネジメントの二人三脚の必要性
4.8 まとめ
赤間 信幸［アカマノブユキ］
著・文・その他
目次
第１章 開発プロセスとＶ字型モデル（Ｖ字型モデルと開発プロセスの関係；ＳｏＲ型システム開発とＳｏＥ型システム開発 ほか）
第２章 フェーズとロールモデル（業務アプリケーション開発の２つのストリームと５つのロール；ＷＢＳの基本骨格構造 ほか）
第３章 各タスクの実施の要点（要件定義；外部設計 ほか）
第４章 システム開発現場の近代化に向けて（ＳＩｅｒとエンプラ系システム開発現場の課題；ＳｏＲ型システム開発における更なる開発生産性の改善 ほか）
著者等紹介
赤間信幸［アカマノブユキ］
１９７３年生まれ、東京大学大学院理学系研究科化学専攻の修士課程卒。１９９８年、ＮＴＴデータに就職後、業務分析・設計やＪ２ＥＥシステム設計を経験。その後、マイクロソフトコンサルティング本部へ。．ＮＥＴアプリケーション開発に関するアーキテクチャコンサルティングを主に担当。大学時代の長期に渡る塾講師経験を活かし、コンサルティングサービス統括本部内の．ＮＥＴアプリケーション開発技術の標準化や、開発チーム教育支援用マテリアルの作成なども兼務している（本データはこの書籍が刊行された当時に掲載されていたものです）
※書籍に掲載されている著者及び編者、訳者、監修者、イラストレーターなどの紹介情報です。
感想・レビュー
※以下の感想・レビューは、株式会社ブックウォーカーの提供する「読書メーター」によるものです。
gushwell
HANA
だんだん
ninn.atsu
ASPanda
