0人中、0人の方がこのレビューが役に立ったと投票しています。
投稿者：匿名 - この投稿者のレビュー一覧を見る
著者の本はどれもとても分かり易いです。この方面で経験豊富な著者だから書ける本だと思います。
失敗した経験のある人であればヒントになるかと
2017/07/05 08:34
1人中、1人の方がこのレビューが役に立ったと投票しています。
投稿者：uu4k - この投稿者のレビュー一覧を見る
ユーザとベンダーとの間で生じる問題について、いくつかの短編ストーリーに沿って解決方法を学ぶといった内容になっています。
ベンダーを利用した１つのシステム開発の頭から終わりまでを描くものではなく、短編ごとで別個の案件の内容をぶつ切りに描いているもののため、ベンダーを利用したシステム開発を行った経験のない人がいきなりこの本を読んでも浸透しづらいです。
ただ、一方で実際にベンダーを利用したシステム開発で問題を経験した人であれば、いろいろとヒントとなるものを得られるよい本だと思います。
予断ですが、ストーリーは少々微妙だったので評価のほうに反映してます。
投稿元：
レビューを見る
購入。
タイトルのとおり、自社業務を外注する際にシステム担当者が注意すべき点をストーリー仕立てでまとめている。
技術的なことには触れていない。個々の案件ごとに異なる部分だからそれでよいと思うが、最低限の参考書リストがあると更に便利な本になると感じた。
システム担当者になったときに自社内の過去のやり方をそのまま行うことが正しいとは限らない。そんなときにこの本で自社以外のやり方を学ぶのは有効だと思う。
投稿元：
レビューを見る
本書は各章でよく起こりそうな問題をストーリ仕立てで紹介しており、解決に導くにはどうしたらよいか？を考えさせる内容になっている。とはいうものの所々に「Hint」が記載されており、理解の助けとなっている。読み物としてみればなかなか面白いが、よくある一般的な管理手法等を体系的に学びたい人には不向きである。
また合間合間にチェックリストの付録があり、自分が使用しているひな形と比べる事が出来た。
開発側としてはプロジェクトスタート時には無関心でいられ、出来上がってから文句を言われるのが一番困る。システム開発はあくまでも協調作業という事がこれを読んで広まればうれしい。
投稿元：
レビューを見る
普段システムを受注して作る側なわけなんですが、一方で発注側支援コンサルみたいなこともやっていて、お客様側の話も理解したいなと常々思ってました。
わりと最後の方ですが、発注側がベンダのキャリアパスとか考えてモチベートしていかないとみたいな話があって、まさか、お金出す側がそんなこと考えないといけないなんて、、と思いますが、私も最大限気を遣っていただいているのだなと思うと、なかなか胸熱だったりします。
しかし、ヒューマンドラマの最後のオチ、あれはないわあ。
投稿元：
レビューを見る
例題部分は読み物として物足りなさはあったけど、実用書としては私に土地勘もないので手ごろに役立ちそう。しかしまあシステム関係が地獄になりがちなのはこういう原因があるからなのね。
投稿元：
レビューを見る
システム開発に関わらず、発注者は他部署に影響するサービスを購入する場合、サービスの基礎知識・周りを巻き込む力・目的、手段を伝える力がないと優秀なコンサル、商品力があってもビジネスの成功率は低い。業者への丸投げ体質が負の遺産を作る仕組みになってるように思えた。
投稿元：
レビューを見る
Appendixに価値がある。発注者の役割や要件定義のチェックリスト、プロジェクト計画書に盛り込むべき項目に、リスクを洗い出すときのチェックリスト等。
全体的に外注する場合の注意点として、主にリスク管理に重点を置かれている。特に、発注者側のベンダの内部に潜むリスクへの対応の仕方やスタンスは参考にする価値あり。
ただ、ストーリーはやや冗長でコスパは若干悪い。
投稿元：
レビューを見る
知ってるつもり、復習のつもりで読んだのだが、
全然できてない、全然足りなかった。
失敗したプロジェクト(検収とか納品はした)の分析・総括ができてなかったんだな。
発注者・ベンダ、その時々でどちらの立場でもあるわけだが、
大変に勉強・参考になりました。
これ、ITだけじゃなく様々な企画のプロジェクトへ通じると感じました。
投稿元：
レビューを見る
面白い。システム開発のベンダーに何かを注文したとしても、発注主はただ任せるのでは駄目だというのがよく分かる。こういう世界に無知な自分にとってはとても参考になった。
投稿元：
レビューを見る
基本的なことで、頭ではわかっていることが中心。
ただ、実際は工数の関係やコミニュケーション不足で、できてないことも多い。
発注者、ベンダーで立ち位置は異なっても、プロジェクトを成功させるために、お互い意見を交換して、進めていくことが大切。
投稿元：
レビューを見る
システムの発注者側としての注意すべき要点について、網羅的ではないが有用な視点が書かれている。
良い点として、小説仕立てで取っつきやすいという点と、あまり他のこの手の本では書かないようなリスク管理の考え方の話が参考になりそう。
登場人物のITコンサルの女性が現実離れしたキャラクター設定なのはアレだが(20代の設定には無理がある、あとクライアントにこんな失礼な態度取る奴は普通いない)
フィーリングマップはこの本で初めて知った手法だが、キャッチーで面白そうだと思った。実務で使ってみたい。
投稿元：
レビューを見る
「なぜ、システム開発は必ずモメるのか？」の著者と同じということに気づかず、タイトルのみで手に取った。
前回が訴訟ベースで深掘りが浅い部分が多かったが、本書では事例ベースの話で、よりわかりやすかった。APPENDIXの内容は、プロジェクト発足当初に皆で意識合わせしておいた方がよいものが多く、プロジェクトマネージャーを任せられた方が最初に読むにはいいボリューム感の本だと感じた。
ただ、前書と同じく、ラノベ形式でストーリーが進行するので、ベンダーとの契約内容など、もう少し詳しい部分は別の本で補完する方がよさそうである。
投稿元：
レビューを見る
前著と同様にITシステムを発注するときのトラブルを物語形式で紹介している本。典型的なケースがいくつか取り上げられている。ITシステムの発注に特有なことも多いが、開発やデザインを外注するときにも該当することが多い。社内では、自分ではりかいできないようなことでも、とにかく金を払って外注すればやってくれる、のような考え方がいまだに多く、相変わらずトラブルが続発している。
投稿元：
レビューを見る
物語形式で話が進んでいく＆1章ごとにテーマが分かれているため
非常に読みやすい。
ただ、読みやすいが故に読み終わった後にしっかり振り返らないと
ビジネス小説を読んだだけ、になってしまう。
というわけで振り返り。
1章：主人公(白瀬)が社内システムを作ることになり、
システム要件定義作成に四苦八苦する。
→業務フロー図には目的・理想・懸念を書く
自社の強みを活かすことを忘れない
2章：ベンダが途中で撤退。その途中まで開発した分の費用を請求してくることに
→要件の必要性・十分性をチェック
フィーリングマップを作る（どの部署のどの役職が笑顔or不機嫌？）
3章：規模の小さいベンダに大きなPJを任せたくないが・・・
失敗しないベンダの選び方
→リスク管理ができているか。ベンダ内部の問題も発注者に開示しているか。
発注者はベンダの問題を取り込もうとしているか。
4章：社員がシステム要件作成に協力してくれない
→社員の意識を変えるため、経営トップが人事権を使う
PJオーナーは社長。
5章：ベンダの選定はばくちのようなもの？
→ベンダが悪い、といっても得られるものはない。
ベンダのリスクも共有する。3章同様。
6章：発注者はどこまでわがままを言えるのか
→モヤモヤが消えるまで質問や注文を繰り返す。双方ともやり方の正しさに自信が持てる
7章：情報漏洩への対応
→事前対策、事後対策を立ち上げ段階から考えておく。
