【書籍】情シスの定石～失敗事例から学ぶシステム企画・開発・保守・運用のポイント～(技術評論社)│Gloria, Limited

すべての情シス・関係者へ

好評発売中！

すべての情シス・関係者へ

好評発売中！

これは情シスのバイブルだ

情シス(現場)

いまいち、情シス業務のやるべきことが分からない。
業務への不安を払拭したい･･･

理想のシステムを作り、周りから頼られる情シスになりたい･･･

情シス(部長)

経営者

システム投資の判断をするために、
どのような点を確認すればよいのだろう･･･

情報システム部門の担当者が

「絶対に」押さえるべきノウハウを体系化！

情シス(現場)

いまいち、情シス業務のやるべきことが分からない。
業務への不安を払拭したい･･･

理想のシステムを作り、周りから頼られる情シスになりたい･･･

情シス(部長)

経営者

システム投資の判断をするために、
どのような点を確認すればよいのだろう･･･

情報システム部門の担当者が

「絶対に」押さえるべき

ノウハウを体系化！

全体感を理解

全体感が分かっていないと、この先何をすべきかが見えてきません。また、個別最適な対応に終始してしまいます。
本書では「鳥瞰図」を提示するとともに、それぞれの位置付けを明確にすることで、情シスの全体感が理解できるようにしました。

やるべき事が分かる

情シスの活動はシステム開発だけではありません。
本書は「システムライフサイクル」を軸として整理することで、情シスの活動をカバーし、やるべき事を解説します。

現場で使える

実際の現場においては、それぞれ抱えるシステムも違えば、体制や状況も異なります。教科書的なことのみでは現場での利用は難しいでしょう。
本書は、筆者の経験やノウハウに基づく定石を提示するとともに、できるかぎり具体例を紹介します。そうすることで、読者自身の状況においてイメージアップしやすいようにしました。

『全体鳥瞰図』を元に
全てを語ります

現役「情シス」

全体感がよく分からない方
自身の対応方法が正しいのか分からない方
もっと良い方法がないのか知りたい方

異動で「情シス」へ

突然情シスに配属され、右も左も分からない方

転職で「情シス」へ

システム開発ベンダから事業会社の情シスに転職し、その活動の違いが分からない方

部下・新人育成にお悩みの方

情シスの部下・新人に、何をどのように伝えて育成していけばよいかお悩みの方

業務部門の方

情シスと相対しているが、情シスが何をしているのかイメージが湧かない方
自身がどういった役割を果たせばよいのか分からない方

経営者

システム投資の判断のため、どのような点を確認すればよいかを理解しておきたい方
自社の情シスを強化したく、情シスに推薦できる書籍を探している方

開発ベンダ勤務の方

情シスと開発ベンダの役割の違いを整理したい方
お客様(事業会社)がどういった観点を気にするのかを把握したい方

就活生

事業会社の情シスがどういった活動をしているのか理解したい方
システム開発ベンダとの違いを理解したい方

1. 本書の構成を知る (1章を読む)

2. 全体をさっと読み、内容をつかむ

3. 担当業務部分を熟読して活用する

石黒直樹

株式会社グロリア
代表取締役

1981年生まれ。京都府出身。

大学卒業後、日本を代表するシステムインテグレータ（SIer）である株式会社野村総合研究所に入社。主に、徹底した品質が必要とされる金融系システムを担当。大規模プロジェクト、開発、保守、運用など、情報システムに関する様々な経験を有する。

15年勤務の末、独立して現職。現在は主に中小企業、個人事業主様のビジネス発展を、ITを軸にしてご支援中。企業理念は「−あなたと共に、未来を創る−」。

情報処理安全確保支援士（#019126）、情報処理技術者試験（ITストラテジスト試験、プロジェクトマネージャ試験合格）

解夏

現役「情シス」

新卒でシステム開発会社に入社。アプリケーションの設計・開発に従事。その後、大規模な開発プロジェクトのリーダやマネジメントを経験。

現在は、事業会社のシステム企画部門に所属し、システムグランドデザイン検討、システム企画、導入時のプロジェクトマネジメント等を行っている。

＜保有資格＞
・Project Management Professional（PMP）
・情報処理技術者試験（プロジェクトマネージャ試験、データベーススペシャリスト試験合格）
など

第１章情シスが抱える課題と本書の役割

1.1 情報システム部の現状

【COLUMN】開発ベンダのSEと事業会社の社内SEの違い

1.2 課題に対する本書の役割

1.2.1 本書から得られること

1.2.2 対象読者

1.2.3 課題解決のための本書の「コンセプト」

1.3 本書の構成

1.3.1 全体構成

1.3.2 各章の構成

1.3.3 要因について

1.3.4 登場人物について

第２章企画

2.1 「企画」とは

2.1.1 鳥瞰図における位置付けと内容

【COLUMN】企画こそ、高いITレベルが必要

2.2 サービス企画

2.2.1 サービス企画の活動内容

【COLUMN】サービス企画が不要そうなケースでもサービス企画は必要？

2.2.2 サービス企画作成のポイント

【COLUMN】非機能要求とは？

【COLUMN】要求と要件の違い

2.2.3 特に重要な社外要因・社内要因

2.2.4 【失敗事例】経営戦略と方向が異なり、企画がなかなかOK出ず

2.3 システム企画

2.3.1 システム企画の活動内容

2.3.2 システム企画作成のポイント

【COLUMN】システムグランドデザインとは？

【COLUMN】システム全体像を守っていくには？

【COLUMN】モチベーションをどうやって上げる？

2.3.3 特に重要な社外要因・社内要因

2.3.4 【失敗事例】IT資産を有効活用できず、運用コストが倍以上に！

【COLUMN】システム企画に対する評価を忘れずに

2.4 RFP

2.4.1 RFP作成の活動内容

【COLUMN】RFIって？

2.4.2 RFP作成のポイント

2.4.3 特に重要な社外要因・社内要因

【COLUMN】オフショア開発の特徴とは？

2.4.4 【失敗事例】RFPのレビュー先部署の選定が十分でなく、重要な要求漏れから大問題に発展！

2.5 提案書評価・契約

2.5.1 提案書評価・契約の活動内容

【COLUMN】準委任契約の「準」って？

【COLUMN】開発ベンダが準委任契約でしか受けてくれない

2.5.2 提案書評価・契約のポイント

【COLUMN】システム構築した後の運用はどうするの？

2.5.3 特に重要な社外要因・社内要因

2.5.4 【失敗事例】開発ベンダにプログラムを再利用、販売されてしまった！

【COLUMN】基本契約と個別契約

2.6 サービス評価

2.6.1 サービス評価の活動内容

【COLUMN】SLA（Service Level Agreement）とは

2.6.2 サービス評価のポイント

2.6.3 特に重要な社外要因・社内要因

2.6.4 【失敗事例】既存システム置き換えでサービス利用を選択したが、作業量が多く業務が成り立たない！

2.7 この章のまとめ

【COLUMN】本書の「フェーズ」「ステップ」「要因」整理の苦労話

第３章システム開発

3.1 「システム開発」とは

3.1.1 鳥瞰図における位置付けと内容

【COLUMN】請負契約において、開発ベンダへの直接指示は違法

【COLUMN】アジャイル開発って？

【COLUMN】工程の名称は会社毎に違うので要注意

3.2 プロジェクト計画

3.2.1 プロジェクト計画書活動内容

3.2.2 プロジェクト計画書作成のポイント

【COLUMN】バグ０件はおかしい？

【COLUMN】新システムのネーミングには要注意

3.2.3 特に重要な社外要因・社内要因

3.2.4 【失敗事例】リリースタイミングを細分化しすぎた結果、コスト増、品質も低下！

3.3 要件定義

3.3.1 要件定義の活動内容

3.3.2 要件定義作成時・レビュー時のポイント

3.3.3 特に重要な社外要因・社内要因

3.3.4 【失敗事例】「現行と同様」では、現行を知らない開発ベンダが要件を設計に落とし込めない！

3.3.5 【失敗事例】非機能要件が具体的に定義されていない！総合テストで開発ベンダと揉める事態に

【COLUMN】非機能要件は定義が難しい

3.4 設計（基本設計・詳細設計）

3.4.1 設計（基本設計・詳細設計）の活動内容

3.4.2 設計（基本設計・詳細設計）のレビューポイント

【COLUMN】なぜ標準化が必要なのか

3.4.3 特に重要な社外要因・社内要因

3.4.4 【失敗事例】項目の整合性が取れておらず、統一性のない設計に！

3.5 開発・ベンダテスト

3.5.1 開発・ベンダテストの活動内容

3.5.2 開発・ベンダテストのレビューポイント

3.5.3 特に重要な社外要因・社内要因

3.5.4 【失敗事例】コード規約に準拠せず構築してしまい、保守で大混乱！

3.5.5 【失敗事例】単体テストで検出すべきバグが結合テストで大量に！スケジュールは大幅に遅延

【COLUMN】いきなりテストケース！はダメ

3.6 ユーザ受け入れテスト

3.6.1 ユーザ受け入れテストの活動内容

3.6.2 ユーザ受け入れテストのポイント

3.6.3 特に重要な社外要因・社内要因

【COLUMN】ユーザ受け入れテストでバグが出そうなところ

3.6.4 【失敗事例】重要機能の確認を後回しにした結果、バグ改修が稼働に間に合わず！

3.7 業務トレーニング

3.7.1 業務トレーニングの活動内容

3.7.2 業務トレーニングのポイント

3.7.3 特に重要な社外要因・社内要因

3.7.4 【失敗事例】説明する順番や内容に不備があり、社内説明会が炎上！

3.8 移行リハーサル・移行本番

3.8.1 移行リハーサル・移行本番の活動内容

3.8.2 移行リハーサル・移行本番のポイント

3.8.3 特に重要な社外要因・社内要因

3.8.4 【失敗事例】コンティンジェンシープランが未設定！障害復旧に時間がかかり業務影響が発生

【COLUMN】関連システムとの調整や各種管理は発注者側の責務！

3.9 この章のまとめ

第４章サービス導入

4.1 「サービス導入」とは

4.1.1 鳥瞰図における位置付けと内容

4.2 プロジェクト計画

【COLUMN】プロジェクト計画書の肝

4.3 サービス導入設計

4.3.1 サービス導入設計の活動内容

【COLUMN】FIT&GAPの「深さ」はどこまで実施すべきか

【COLUMN】データ移行は"超"大変

4.3.2 サービス導入設計作成のポイント

【COLUMN】データ移行は"超"大変

4.3.3 特に重要な社外要因・社内要因

【COLUMN】野村HD vs 日本IBMの判決

【COLUMN】レベルの高い担当者ばかりではない。自分の身を守るべし

4.3.4 【失敗事例】バックアップレベルが社内ルールに達しておらず、追加システム開発が発生！

【COLUMN】サービスは本当にさまざま

4.4 サービス設定・確認

4.4.1 サービス設定・確認の活動内容

4.4.2 サービス設定のポイント

【COLUMN】「意図」は本当に大切

【COLUMN】サービスは「共用のシステム」であることに留意しよう

4.4.3 特に重要な社外要因・社内要因

4.4.4 【失敗事例】計算方法が異なるため、算出結果が以前と変わってしまった！

【COLUMN】関連システムがある場合の確認は大変

4.5 業務トレーニング

4.5.1 業務トレーニングの活動内容

4.5.2 業務トレーニングのポイント

4.5.3 特に重要な社外要因・社内要因

4.5.4 【失敗事例】大人数で業務トレーニングを開始したところ、サービスにアクセスできず！

4.6 移行リハーサル・移行本番

4.6.1 移行リハーサル・移行本番の活動内容

4.6.2 移行リハーサル・移行本番のポイント

【COLUMN】旧システムの契約終了にはご注意を

4.6.3 特に重要な社外要因・社内要因

4.6.4 【失敗事例】データクリーニング範囲に漏れが！テストデータが残ったまま業務開始

【COLUMN】本番環境をテスト前に戻すのは本当に難しい

4.6.5 【失敗事例】データ移行が終わらない！しばらくの間業務が煩雑に

4.7 この章のまとめ

第５章保守

5.1 「保守」とは

5.1.1 鳥瞰図における位置付けと内容

5.2 保守の全体設計

5.2.1 保守の全体設計の活動内容

5.2.2 保守の全体設計のポイント

5.2.3 特に重要な社外要因・社内要因

5.2.4 【失敗事例】保守で更新すべきドキュメントが明確化されていない！

5.3 保守契約の締結

5.3.1 保守契約の締結の活動内容

5.3.2 保守契約の締結のポイント

【COLUMN】スコープが曖昧な契約書は情報が足りていない

【COLUMN】保守契約を削りすぎると･･････

5.3.3 特に重要な社外要因・社内要因

5.3.4 【失敗事例】保守契約における営業日の定義が曖昧で障害対応をしてもらえず！

5.4 優先順位付け・案件実施

5.4.1 優先順位付け・案件実施の活動内容

5.4.2 優先順位付け・案件実施のポイント

5.4.3 特に重要な社外要因・社内要因

5.4.4 【失敗事例】実施案件の管理不足から並行開発に失敗！障害多発となる事態に

5.4.5 【失敗事例】ガラパゴス化した独自の保守開発により後任にしわ寄せが！

【COLUMN】開発ベンダ側の業務負荷についても考えましょう

5.5 評価・改善

5.5.1 評価・改善の活動内容

5.5.2 評価・改善のポイント

5.5.3 特に重要な社外要因・社内要因

5.5.4 【失敗事例】人材不足により保守品質が悪化！障害が多発してしまった

5.6 この章のまとめ

第６章運用

6.1 「運用」とは

6.1.1 鳥瞰図における位置付けと内容

【COLUMN】情シス（運用）の守備範囲

6.2 運用計画

6.2.1 運用計画の活動内容

【COLUMN】障害訓練をしよう

6.2.2 運用計画作成のポイント

【COLUMN】「運用でカバー」という魔法の言葉

6.2.3 特に重要な社外要因・社内要因

【COLUMN】事業が窮すると･･････

6.2.4 【失敗事例】運用受け入れの説明ができておらず、揉めに揉めて残業の日々！

【COLUMN】DevOps（デブオプス）という考え方

6.3 イベント管理

6.3.1 イベント管理の代表的な管理対象

【COLUMN】サービスデスクを構築して効率化を図ろう

【COLUMN】特異日って何？

【COLUMN】担当者が分かれていて管理内容が重複している場合はどう扱うべきか

6.3.2 イベント管理のポイント

6.3.3 特に重要な社外要因・社内要因

【COLUMN】緊急時の対応費用

【COLUMN】手段に縛られない

6.3.4 【失敗事例】接続先システムのサービス停止を把握しておらず、システムエラーが多発！

6.4 システム管理

6.4.1 システム管理の代表的な管理対象

6.4.2 システム管理のポイント

6.4.3 特に重要な社外要因・社内要因

【COLUMN】日本中から機材を集める

6.4.4 【失敗事例】ハードウェアの延長保守を把握しておらず、コスト不足に

【COLUMN】保守期限は業務部門の感覚とは合わないことも多い

6.5 障害対応

6.5.1 障害対応の活動内容

6.5.2 障害対応のポイント

6.5.3 特に重要な社外要因・社内要因

6.5.4 【失敗事例】安易に再実行した結果、データ不整合による二次障害が発生！

【COLUMN】「対応の効率化」と「丁寧な対応」のジレンマ

6.6 評価・改善

6.6.1 評価・改善の活動内容

6.6.2 評価・改善のポイント

6.6.3 特に重要な社外要因・社内要因

6.6.4 【失敗事例】評価に使えないファクトばかり！ファクト収集のための改修が発生

【COLUMN】運用は減点方式で見られやすい？

6.7 この章のまとめ

第７章廃止

7.1 「廃止」とは

【COLUMN】廃止に関する情報は少ない？

7.1.1 鳥瞰図における位置付けと内容

【COLUMN】廃止は全体を見直す大きなチャンス

7.2 プロジェクト計画

【COLUMN】廃止対応のスコープ

7.3 廃止設計

7.3.1 廃止設計の活動内容

7.3.2 廃止設計作成のポイント

【COLUMN】開発ベンダによる影響調査方法と結果の妥当性は確認しよう

【COLUMN】プロジェクトスコープをどこで線引きするか

【COLUMN】ネットワークの廃止も難しい

7.3.3 特に重要な社外要因・社内要因

7.3.4 【失敗事例】いつの間にかデータ利用が開始されており、システム廃止とともにトラブル発生！

7.4 廃止実施

7.4.1 廃止実施の活動内容

7.4.2 廃止実施のポイント

【COLUMN】メンテナンス資料への反映は保守・運用担当がしっかりと意識しよう

7.4.3 特に重要な社外要因・社内要因

7.4.4 【失敗事例】外部サービスへの依頼が上手くいかず、無関係の他社に影響発生！

7.5 この章のまとめ

第８章マネジメント

8.1 「マネジメント」とは

8.1.1 鳥瞰図における位置付けと内容

【COLUMN】PDCAサイクルのCheck（評価）は本当に大事！

8.2 マネジメントの基本

8.2.1 マネジメントの基本とは

【COLUMN】世界標準のPMBOKガイドの動向を確認しよう

【COLUMN】PMPと情報処理技術者試験（プロジェクトマネージャ試験）の違い

8.3 各工程の「計画時」に検討すべきこと [Plan]

8.3.1 検討すべきことは何か

8.3.2 各工程の「計画時」に注意すべきポイント

8.3.3 特に重要な社外要因・社内要因

8.3.4 【失敗事例】クローズしたと思った課題が再燃！

【COLUMN】クローズした課題は「地雷」になり得る

8.4 各工程の「実行時」に確認すべきこと [Do]

8.4.1 確認すべきことは何か

8.4.2 各工程の「実行時」に注意すべきポイント

【COLUMN】開発ベンダには甘すぎず、厳しすぎず

8.4.3 特に重要な社外要因・社内要因

8.4.4 【失敗事例】開発ベンダをツメすぎた！最低限の対応しかされず品質の悪いシステムに

【COLUMN】怒りをマネジメントしよう（アンガーマネジメント）

8.5 各工程の「評価時」に確認すべきこと [Check]

8.5.1 評価すべきことは何か

8.5.2 各工程の「評価時」に注意すべきポイント

8.5.3 特に重要な社外要因・社内要因

8.5.4 【失敗事例】前工程の良くない部分が改善されず、次の工程に持ち越された！

【COLUMN】上手くいかなかった物事は「なぜなぜ分析」をしよう！

8.6 各工程の「改善時」に検討すべきこと [Action]

8.6.1 改善すべきことは何か

8.6.2 各工程の「改善時」に注意すべきポイント

8.6.3 特に重要な社外要因・社内要因

8.6.4 【失敗事例】他案件での改善が共有されず、保守案件で同じミスが発生！

【COLUMN】30時って何？

8.7 この章のまとめ

Appendix 役に立つフレームワーク

さあ, 次のレベルへ

定価 2,948円(税込)

各販売サイトで
発売中

電子版もあります

その他、全国の書店・オンラインにて販売

※実売価格は各販売サイトでご確認ください

すべての情シス・関係者へ

すべての情シス・関係者へ

関連情報

関連情報

これは情シスのバイブルだ

情報システム部門の担当者が

「絶対に」押さえるべきノウハウを体系化！

情報システム部門の担当者が

「絶対に」押さえるべき

ノウハウを体系化！

全体感を理解

やるべき事が分かる

現場で使える

『全体鳥瞰図』を元に
全てを語ります

現役「情シス」

異動で「情シス」へ

転職で「情シス」へ

部下・新人育成にお悩みの方

業務部門の方

経営者

開発ベンダ勤務の方

就活生

1. 本書の構成を知る (1章を読む)

2. 全体をさっと読み、内容をつかむ

3. 担当業務部分を熟読して活用する

さあ, 次のレベルへ

すべての情シス・関係者へ

すべての情シス・関係者へ

関連情報

関連情報

これは 情シスの バイブル だ

情報システム部門の担当者が

「絶対に」押さえるべきノウハウを体系化！

情報システム部門の担当者が

「絶対に」押さえるべき

ノウハウを体系化！

全体感を理解

やるべき事が分かる

現場で使える

『全体鳥瞰図』 を元に全てを語ります

現役「情シス」

異動で「情シス」へ

転職で「情シス」へ

部下・新人育成にお悩みの方

業務部門の方

経営者

開発ベンダ勤務の方

就活生

1. 本書の構成を知る (1章を読む)

2. 全体をさっと読み、内容をつかむ

3. 担当業務部分を熟読して活用する

さあ, 次のレベルへ

これは情シスのバイブルだ

『全体鳥瞰図』を元に
全てを語ります