##システムを「外注」するときに読む本
システムつくる側の話（ベンダ）ではなく、システムをお願いする側（ユーザ）の話です。
システムをつくるプロジェクトの成功率は30%で残りの70%が失敗に終わるという。
ストーリー形式になっていて、ユーザー側が落ちやすい穴について書いてあります。
主人公がホモって設定が読んでいてキモいなと思いました。政府ICO補佐官のおっさんがつくってる思うとゾッとします。ゴーストライターであってほしい。
そんな素敵なストーリーの中身を要約すると、
お互いが相手の気持ちになって、コミュニケーションをとれば失敗は回避できる
ということが書いてあります（笑）
つまり、
お互いが相手の気持ちになって、コミュニケーションをとれば戦争は回避できる
というのと同じです。それができれば、2020年度の5兆3133億円という防衛費も不要だったのかもしれません。
話がそれましたが、ベンダは仕事する前にユーザーにこの本をプレゼントすれば喜ばれると思いますよ！
1980円＋税でプロジェクトの失敗が回避できればとても安いものです。
駅前で聖書を配ってくるおじさんと同じように思われるかもしれませんが。。。。
##要件定義のポイント
・システムを導入する目的を忘れないように書きとめておく
・業務フロー図には、懸念事項や課題を漏れなく書き込む
・システムを導入して誰が喜び、誰が困るのかを書き込む
・システム化の範囲は、業務をどのように改善するかという「意志」をもつ
・システム担当者となったからには、自分の思いは脇において、改善の推進者になるきる
##発注者が最低限知っておくべきこと
・システム担当者にはシステム化する対象事業の知識が必要
・発注者側の責任で頓挫したプロジェクトの損害賠償責任は発注者にある
・システム担当者がモチベーションを上げるには、経営者の視点でシステム導入の意味や目的を考えてみると良い
##ベンダ選びのポイント
・ベンダの示すプロジェクト管理項目と管理工数が十分化を見極める
・信頼できるベンダは、自社内のリスクも含めて、ユーザーと共有する
・要件の変更や追加をただ承諾するベンダにはプロジェクト管理義務違反の恐れがある
・ベンダの示すリスクをまずは傾聴する
##社内の協力を得るためのポイント
・システム担当者は、往々にしてエンドユーザーの協力が得られずに孤立する
・エンドユーザーにヒアリングをするときには、最低限の業務知識を得ておくこと
・難解なIT専門用語を使わない
・相手が忙しい中、時間を割いてくれていることに感謝する
・システム担当者が他部門と調整するときは、その上司がフォローと支援をする
・エンドユーザーの協力を得るには、システム開発の意義や目的について、経営トップからのメッセージングを繰り返す
・経営陣は、システム開発も社員全員の本業であるという意識付けと仕組みの改革をすること
##プロジェクトのリスクを的確に把握するポイント
・ベンダにリスクを開示させるために、発注者側は真摯に聞く姿勢を忘れない
・ベンダのリスクもプロジェクトのリスクと同じように、発注者側が知るべきことと認識する
・ベンダのリスクは発注者側から引っ張り出す
・定量的なプロジェクト状況やスキル評価、工数の妥当性のほか、プロジェクトに合わせて設定した評価軸でベンダのリスクを評価する
##ベンダとコミュニケーションのキモ
・期限までに要件を決めきれないことは日常茶飯事
・要件定義工程完了前に「今後どうすべきか？」を改めて話し合い、チェックポイント会議を開く
・ベンダの質問に遠慮は不要、技術でも業務でもどんどん聞くべき。そうすることで、ベンダ側の知識が醸成されることもある。
・たとえパッケージソフトを使うときでも、どうしてもこだわりたい自社の長所は捨てずに入れ込む
・発注者とベンダは、お互いに「自分たちがのほうが損している」と思う程度がちょうどいい
##セキュリティ被害を最小限に抑えるポイント
・機密情報を扱うシステムでは、漏洩時の影響を踏まえてトリアージを行い、重大度に合わせた対策を実行できるように準備しておく
・情報漏えい時の見舞金や補償金の相場は500円から5000円程度といわれる
・運用担当者にモチベーションを維持してもらうためには、必要な待遇改善を検討すべきだし、キャリアパスも定義する必要がある
・情報漏えい時には、そのシステム自体を捨てる覚悟も必要で、たとえ良いシステムであっても、それに固執すると、企業の信用を損ねたり、再発を起こす可能性もある
ざっ、とこんな感じです。
そもそも、ユーザーはベンダからみればバカで無知ばっかりなんだから、PMが手の中で転がしてあげないとダメですよ。
お互いが相手の気持ちになって、コミュニケーションをとれる平和な世界がきますように・・・