知識ゼロからでもエッセンスを獲得できる、「発注者」に向けた空前の入門書です。

「このままじゃ納期に間に合わない! 」
「当初の予算に収まらない! 」
「完成したシステムの使い勝手が悪すぎる! 」

企業や組織のシステム開発は、少し前まで「成功率3割」だったほど、
失敗する可能性が異常に高いプロジェクトです。

その最大の原因は、

「お客様 vs 受注者」
「システムの素人 vs システムのプロ」
「この通り作ってください」vs「 はい、わかりました」

そういう対立した関係の「壁」を乗り越え、
協力してシステムを作る方法を、
誰も教えてくれなかったことにあります。

本書は、大手ベンダーでのプロジェクトマネージャー、
ITプロセスコンサルティング職を経て、
東京地方裁判所、東京高等裁判所のIT専門委員として
ITトラブルが法的紛争となった事件の和解調停や裁判の補助を担当し、
トラブルを裁判に発展させずに解決に導いた確率が9割を超え、
現在は政府CIO補佐官として政府系機関システムのアドバイザー業務に携わる、
システム開発に潜む地雷を知り尽くした「トラブル解決請負人」が、
大小70以上のトラブルプロジェクトを解決に導いた経験を総動員し、
失敗の本質と原因を網羅した7つのストーリーから成功のポイントを導き出す1冊。

本書を読み、あなたが「お客様」から「プロジェクトメンバー」になったとき、
システム開発はグッと成功に近づきます。

【本書のおもな内容】
●要件定義に欠かせない「業務フロー図」の書き方
●「プロジェクト管理能力」でベンダを見極める方法
●ベンダが一緒に仕事したくなる発注者、見捨てたくなる発注者
●プロジェクトメンバーの「モチベーション」の上げ方
●社員の意識を変えるために「経営トップ」がやるべきこと
●みんながシステム担当者に 協力してくれる「しくみ作り」
●トラブルを回避する「リスク管理プロセス」
●ダメージを最小限に抑える「セキュリティ対策」

【すぐに役立つチェックリストやツールも満載】
★システム開発プロジェクトにおける発注者の役割一覧
★プロセス別:発注者のおもな作業一覧
★要件定義で最低限確認しておくべきチェックリスト
★ベンダが作るプロジェクト計画書とプロジェクト管理計画書の記載項目例
★要件の必要性・十分性をチェックするための3ステップ
★プロジェクトのリスクを管理するプロセス
★プロジェクトのリスクを発見するチェックリスト
★「フィーリングマップ」の使い方
★「Goサイン」を出す社長の思考を予測する方法 など

本書の構成(※詳細はもくじページへ)
第1章 システム作りは業務フローから〜「本当に役に立つシステム」を作るために、まずやるべきこと
第2章 発注者に最低限必要な知識〜自社の業務を「正確に」知っているか?
第3章 失敗しないベンダ選びのポイント〜プロジェクト管理能力の見極め方
第4章 社内の協力を得るために〜みんながシステム担当者に協力するしくみ作り
第5章 リスク管理で大切なこと〜「ベンダ側のリスク」の引き出し方
第6章 ベンダとの適切な役割分担〜発注者はどこまで「ワガママ」でいられるのか?
第7章 情報漏えいを起こしてしまったら〜ダメージを最小限に抑える対応法
出版社からのコメント

「自分が使うシステムなのに、なぜか社員が協力してくれない……」
「経営者がシステムのことをわかってくれてない……」
「そもそも、システム作りなんか本業じゃないし、やる気が起きない……」
「ベンダのやる気が感じられない! 」
「実績のあるベンダだから信用して任せたのに、使えないシステムに多額の費用を払うことになった……」

そういう、システム担当者の悩みの声をたくさん聞きました。
そこで本書では、日本中のあらゆるITトラブルと解決策を知り尽くした、
著者の細川義洋氏の経験と知見を総動員し、

「なぜ、これほどまでにシステム開発は失敗しやすいのか?」
「”本当に役に立つシステム”に最短距離でたどり着ける最低限の知識は何か?」
「読むだけに終わらず、現場で”再現”するためにはどう伝えるべきか?」
「システム担当者を孤立させず、正しく評価されるためにはどうすればいいか?」
「発注者とベンダのチームに変える方法は何か?」

そうしたことを3年間議論し尽くして完成した、
発注者のための画期的な入門書です。

ホームページ、ECサイト、Webマーケティングシステム、
そしてAI、ビッグデータ、IOTなど、IT全盛時代を迎えた今、
ITシステムが、企業の経営を大きく左右する時代に突入しています。

御社の経営発展と売上拡大を加速させる1冊として、
そしてシステム担当者としてのキャリアを充実させるために、
ぜひ、本書を使い倒してください。

• システムを導入する目的を忘れないように書き留めておく
• 業務フロー図には、懸念事項や課題を漏れなく書き込む
• システムを導入して誰が喜び、誰が困るのかも書き込む
• システム化の範囲は、効果が明確に説明できる部分に限る
• システム担当者自身が、業務をどのように改善するかという「意志」を持つ
• システム担当者となったからには、自分の思いは隅において、改善の推進者になりきる

• システム担当者にはシステム化する対象業務の知識が必須
• 発注者側の責任で頓挫したプロジェクトの賠償責任は発注者にある
• システム担当者がモチベーションを上げるには、経営者の視点でシステム導入の意味や目的を考えてみるとよい

• ベンダの示すプロジェクト管理項目と管理工数が十分かを見極める
• 信頼できるベンダは、自社内のリスクも含めて、ユーザと共有する
• 要件の変更や追加を、ただ承諾するベンダにはプロジェクト管理義務違反の恐れがある
• ベンダの示すリスクを、まずは傾聴する

• システム担当者は、往々にしてエンドユーザーの協力が得られず孤立する
• エンドユーザーにヒアリングをするときには、最低限の業務知識を得ておくこと
• 難解なIT専門用語を使わない
• 相手が忙しい中、時間を割いてくれていることに感謝する
• システム担当者が他部門と調整をするときは、その上司がフォローと支援をする
• エンドユーザーの協力を得るには、システム開発の意義や目的について、経営トップからのメッセージングを繰り返す
• 経営陣は、システム開発も社員全員の本業であるという意義づけと仕組みの改革をすること

• ベンダにリスクを開示させるために発注者側は真摯に聞く姿勢を忘れない
• ベンダのリスクもプロジェクトのリスクと同じように、発注者側が知るべきことと認識する
• ベンダのリスクは発注者側から引っ張り出す
• 定量的なプロジェクト状況やスキル評価、工数の妥当性のほか、プロジェクトに合わせて設定した評価軸でベンダのリスクを評価する

• 期限までに要件を決めきれないことは日常茶飯事
• 要件定義工程完了前に、
  「今後、どうすべきか？」を改めて話し合うチェックポイント会議を開く
• ベンダへの質問に遠慮は不要。
  技術でも業務でもどんどんきくべき。
  そうすることで、ベンダ側の知識が醸成されることもある
• たとえパッケージソフトを使うときでも、どうしてもこだわりたい自社の長所は捨てずに入れ込む
• 発注者とベンダは、お互いに「自分たちのほうが損をしている」と思う程度がちょうどいい

• 機密情報を扱うシステムでは、漏洩時の影響を踏まえてトリアージを行い、重大度に合わせた対策を実行できるように準備をしておく
• 情報漏洩時の見舞金や保証金の相場は500円から5000円程度といわれる
• 運用担当者にモチベーションを維持してもらうためには、必要な待遇改善を検討すべきだし、キャリアパスも定義する必要がある
• 情報漏洩時には、そのシステム自体を捨てる覚悟も必要。たとえ良いシステムであっても、それに固執すると、企業の信用を損ねたり、再発を起こす可能性もある