目次

はじめに

発注者は「お客様」ではなく「プロジェクトメンバー」

PART１

第１章　システム作りは業務フロー図から　「本当に役に立つシステム」を作るために、まずやるべきこと

第１章で学べること
　・システム担当者が最初にやるべきこと
　・要件定義の出発点「業務フロー図」に書くべきこと
　・システム化する範囲の定め方
　・発注者側のシステム担当者が持つべき「心構え」

第１章の読み方
　「どんなシステムを作るか」を決めるのは誰か？
　要件定義は２つの「業務フロー図」を作るところから
　業務フロー図を書く人がつい、やってしまいがちな「ワナ」
　システム化する範囲を間違えないたった１つの「判断基準」
　そのシステムで本当に会社が幸せになりますか？
　新システムを使う人と企業の「喜び」を表現する
　業務フロー図を書く人に必要な「メンタリティ」がある
　新しい技術に振り回されて「本当の強み」を軽視していないか？

ＡＰＰＥＮＤＩＸ
　・業務フロー図には「目的」を書き込んでおくと良い
　・「懸念と理想」もできる限り書いておく
　・システム開発プロジェクトにおける発注者の役割
　・プロセス別：発注者のおもな作業

第１章まとめ

PART２

第２章　発注者がこれだけは知っておくべき最低限のこと　自社の業務を「正確に」知っているか？

第２章で学べること
　・システム担当者が最低限持っておくべき知識
　・要件定義工程でシステム担当者が行なうべきこと
　・システム作りに興味のない担当者に意欲を持たせる方法

第２章の読み方
　「本当の責任者」をハッキリさせないとベンダは「やる気」をなくす
　一緒に仕事したくなる発注者見捨てたくなる発注者
　不自然な出来事の裏にはヘタな「シナリオライター」がいる？
　ベンダに協力せずに失敗したときの損害は発注者が保障する
　要件定義に必要な発注者とベンダの「協力関係」とは？
　システム担当者の「知識不足」が会社に大打撃を与える
　メンバーのモチベーションを上げる「フィーリングマップ」

ＡＰＰＥＮＤＩＸ
　・要件定義で最低限確認しておくべきチェックリスト
　・要件の必要性・十分性をチェックするための３ステップ
　・フィーリングマップの使い方
　・同心円状のフィーリングマップ活用法
　・要件の必要性・十分性をチェックする方法
　・「Goサイン」を出す社長の思考を予測する

第２章まとめ

PART３

第３章　失敗しないベンダの選び方　プロジェクト管理能力の見極め方

第３章で学べること
　・本当にプロジェクト管理ができるベンダを見極めるポイント
　・発注者が知っておくべきIT導入プロジェクト管理項目
　・ベンダの管理能力を知るうえで知っておきたいポイント
　・追加費用や納期延長の依頼があったとき、発注者がとるべき態度

第３章の読み方
　システム開発には「不測の事態」と「リスケジュール」がつきもの
　プロジェクトを適切に「管理」するために絶対に外せないポイント
　要件の変更に追加費用や納期延長を求めてくるベンダは○か×か？
　そのベンダは「言いにくいこと」を伝えてくれますか？
　トラブルを乗り越えるための発注者の「聞く力」

ＡＰＰＥＮＤＩＸ
　ベンダが作るプロジェクト計画書とプロジェクト管理計画書の記載項目例

第３章まとめ

PART４

第４章　社内の協力を得るために　みんながシステム担当者に協力するしくみ作り

第４章で学べること
　・システム担当者とは、社内でどんな存在なのか
　・エンドユーザーにヒアリングするときに気をつけるべきこと
　・社内一丸となってシステム作りに取り組むために必要なこと

第４章の読み方
　「社員が協力してくれない」はシステム開発最大の危機
　システム担当者が「孤立」する理由
　壊れかけたプロジェクトはどう立て直せばいいのか？
　エンドユーザー社員がシステム開発に協力する風土としくみ
　社員の意識を変えるために「経営トップ」がやるべきこと

第４章まとめ

PART５

第５章　リスク管理で大切なこと　「ベンダ側のリスク」の引き出し方

第５章で学べること
　・ベンダ側が自社のリスクを開示しない理由
　・ベンダが抱えているリスクへの対応法
　・ベンダ側のリスクを検知する評価軸

第５章の読み方
　システム開発はアタリ／ハズレで勝負が決まる「バクチ」か？
　エンジニアが突然「抜けてしまう」ことがある理由
　ベンダはなぜ、自社内のリスクを隠したがるのか？
　「そっちが悪い」と言ったところで得られることは何もない
　アメリカにあって日本にない一番大切な「考え方」
　発注者側からリスクを「引っ張り出す」メリット
　ベンダのリスクを検知するための「プロセス」

ＡＰＰＥＮＤＩＸ
　・プロジェクトのリスクを管理するプロセス
　・要件定義に関するリスクチェックポイントの例
　・リスク管理表の記載項目例
　・プロジェクトのリスクを発見するチェックリスト例

第５章まとめ

PART６

第６章　ベンダとの適切な役割分担　発注者はどこまで「ワガママ」でいられるのか？

第６章で学べること
　・期限までに要件をまとめきれないときの対処法
　・ベンダに対してどこまで質問して良いのか？
　・パッケージソフトと自社の長所のバランスの取り方
　・ベンダとの役割分担において心がけること

第６章の読み方
　ベンダが勝手に作業を進めても黙認すると「合意」したとみなされる
　要件定義終了時に「宿題」と「方針」を確認する「チェックポイント会議」
　「システムの専門家」相手に発注者はどこまで質問するべきか？
　発注者の質問がベンダを「育てる」ことになる？
　パッケージソフトを自社に適した形で導入するために
　「７：３で自分たちが損してる」とお互いが思うくらいがいい

第６章まとめ

PART７

第７章　情報漏えいを起こしてしまったら　ダメージを最小限に抑える対応法

第７章で学べること
　・情報漏えいに備えてやっておくべきこと
　・情報漏えい時の賠償額の相場
　・情報を扱う運用担当者に必要なケア
　・情報漏えいを起こしてしまったときに捨てるべきもの

第７章の読み方
　漏えいしてからでは何もできない立ち上げ段階の「準備」がカギ
　情報漏えいが起きた場合の補償額・見舞金の相場とは？
　機密性と漏えい時の影響度を基準にした「情報のトリアージ」
　セキュリティ対策の立案時に考慮すべき運用担当者の「気持ち」
　被害を最小限にとどめるために行なうべきこと
　企業を存続させるために何を捨てて、何を残すか？

第７章まとめ

エピローグ

著者

細川義洋（ほそかわ・よしひろ）
政府CIO補佐官。ITプロセスコンサルタント。
元・東京地方裁判所民事調停委員・IT専門委員、東京高等裁判所IT専門委員。
立教大学経済学部経済学科卒業後、NECソフト株式会社（現NECソリューションイノベータ株式会社）にて金融機関の勘定系システム開発など多くのITプロジェクトに携わる。その後、日本アイ・ビー・エム株式会社にて、システム開発・運用の品質向上を中心に、多くのITベンダと発注者企業に対するプロセス改善とプロジェクトマネジメントのコンサルティング業務を担当。独立後は、プロセス改善やIT紛争の防止に向けたコンサルティングを行なう一方、ITトラブルが法的紛争となった事件の和解調停や裁判の補助を担当する。これまで関わったプロジェクトは70以上。調停委員時代、トラブルを裁判に発展させず解決に導いた確率は９割を超える。システム開発に潜む地雷を知り尽くした「トラブル解決請負人」。2016年より政府CIO補佐官に抜擢され、政府系機関システムのアドバイザー業務に携わる。
著書に『なぜ、システム開発は必ずモメるのか？ 49のトラブルから学ぶプロジェクト管理術』『「IT専門調停委員」が教える モメないプロジェクト管理77の鉄則』（ともに日本実業出版社）、『プロジェクトの失敗はだれのせい？』『成功するシステム開発は裁判に学べ！』（ともに技術評論社）などがある。