あらすじ
システムの外注は失敗率が異常に高いプロジェクト。元ＩＢＭのプロマネで「ＩＴ紛争解決請負人」のシステム開発スペシャリストが、実際のトラブル事例や裁判例を元に、失敗の本質と原因を網羅した７つのストーリーから成功法則を導き出した１冊。今までなかった、「発注者」に向けた入門書の決定版！
...続きを読む感情タグBEST3
Posted by ブクログ
物語仕立てで読みやすい。ストーリー形式で問題定期と解決策が示される為、未経験の人にとってはとても読みやすく、勉強になる本だと感じた。
ただし、作中でも記載されていたが、あくまで参考書であって、教科書ではない。
ITは新しいことばかりなので、日々情報収集や勉強が大事だと痛感した。
Posted by ブクログ
発注者から眺めた、IT関連のプロジェクトの怖さ、難しさを言語化した問題提起の書。
情報システムの構築にあたっての最上流 要件定義の以降の工程をとらえて、しかも発注者の立場からシステム開発を論ずる書です
プロジェクト中に発生するさまざまな問題に対して、ベンダと一緒に対応したり、ベンダの作成したシステムをテストするなど、発注者にもたくさんの役割を果たす義務があります。
これを、「ユーザの協力義務」といい、その義務を果たさない発注者は、使えないシステムに膨大なお金を払った上に、損害賠償まで請求される危険すらあります。
プロジェクトの失敗とは、「納期オーバ」、「コストオーバ」、「完成したシステムに当初望んだ通りの機能が備わっていない」という３つのいずれかに当てはまるケースです。
本書の目的は、「本当に役に立つシステム」を完成させるための最低限の知識をお伝えすることです。
著者は、ソフトウエア開発会社にて、プロマネを経験し、ＩＴコンサルとなり、経産省にて政府ＣＩＯ補佐官として政府の基幹系システムに従事した経験をお持ちです。
システム開発プロジェクトは発注者が構想し、リードする時代に入ったといっています。
気になったのは、以下です。
・いきなり要件定義書を造ってはいけない。
・まずは、社内全体の業務を俯瞰して、全体最適の視点から業務の問題点や新しいシステムが実現することで改善される点、全社的なメリットなどがひと目でわかる資料を作成します。
・そのためには、まずは、業務フローを作成します。そして、その中にさまざまなことをメモ書きしていきます。
・ベンダーにどんな機能や性能をもつシステムがほしいかを決めて、ベンダに伝えることは発注者の役割になります。
・そのためには、２つの業務フローを作成します。ＡｓＩｓ：現在の業務の流れ、ＴｏＢｅ：現在の問題点を解決して実現する新しい業務の流れ
・システム化を行うのは、効果が明確に説明できるところのみを対象とします。そのために、システム化する範囲は何度も考えて決定します。
・業務フローをつくっていい点は、会社の各部門が有機的につながってこそ機能するということが、１枚の図でよくわかることです。
・次に業務フローに合わせて、社内の発注者の役割を付していきます。①エンドユーザの責任者、②プロジェクト承認者（社長など）、③プロジェクトマネージャー、④システム担当者
・そしておもな作業は、さらに工程別にブレークダウンします。①要件定義、②委託先選定、③プロジェクト計画、④設計・要件変更、⑤受け入れ試験、⑥移管・サービスイン
・システム開発成功のキモは、受託ベンダーの「リスク管理」にある
・ベンダーの能力は「プロジェクト管理計画」で評価できる
・プロジェクトを管理するためのツール、プロジェクト計画書、プロジェクト管理計画書、ＷＢＳ，リスク管理票、課題管理表、故障管理表、
・プロジェクト管理工数は、全体工数の１０％前後、プロジェクトの進捗遅れは、５日以上遅れたらアラートを上げる
・ＩＴシステムは、ビジネスの主役になりつつあり、本業と同様重要な課題になっている。
・各部からは、多忙を理由に要望の取りまとめに協力してくれないケースが多い システム担当者が孤立してしまいがち。
・ユーザからは、ベンダー自体のリスクは見えにくい。いわば盲点となっている。
・ベンダーのリスクもユーザと共有すべき リスクチェックポイント、リスク管理表
・ベンダが勝手に作業を進めても、黙認すると「合意」したとみなされる
・要件定義終了時に宿題と、方針をチェックポイント会議で確認する
・技術的な話は、最終的にベンダが責任をもつが、それを決める過程では発注者だって口出ししてかまわない
・気になることがあれば、何度でもエンジニアに質問したり設計のやり直しを依頼する
・もやもやが消えるまで質問や注文を繰り返すことで、発注者もベンダも、今のやり方の正しさに自信が持てる
・業務フロー図に、現状の問題だけでなく、自分たちのいいところ、残したい業務も書いて貼っておく
目次
はじめに 発注者は「お客様」ではなく「プロジェクトメンバー」
第１章 システム作りは業務フロー図から
第２章 発注者がこれだけは知っておくべき最低限のこと
第３章 失敗しないベンダの選び方
第４章 社内の強力を得るために
第５章 リスク管理で大切なこと
第６章 ベンダとの適切な役割分担
第７章 情報漏えいを起こしてしまったら
エピローグ
ISBN：9784478065792
出版社：ダイヤモンド社
判型：A5変
ページ数：336ページ
定価：1980円（本体）
発売日：2017年06月14日第1刷
Posted by ブクログ
日頃のベンダー管理がうまくできていないと感じていたので、業務改善の参考にしたいと読んでみた。
ストーリーは置いておいて、物語仕立てなので、それぞれの立場でどう考えており、どんなことに気を付ければ良いかが、分かりやすく学べた。
特に自社内のリスクも含めて、ユーザーと共有することについて、考えさせられた。
言っても意味がないし、聞いてもらえないだろうと諦めてしまったことを思い出した。
このように、教科書に載っていないような、他人の失敗を疑似体験できる良い本だと感じた。
Posted by ブクログ
物語形式で話が進んでいく＆1章ごとにテーマが分かれているため
非常に読みやすい。
ただ、読みやすいが故に読み終わった後にしっかり振り返らないと
ビジネス小説を読んだだけ、になってしまう。
というわけで振り返り。
1章：主人公(白瀬)が社内システムを作ることになり、
システム要件定義作成に四苦八苦する。
→業務フロー図には目的・理想・懸念を書く
自社の強みを活かすことを忘れない
2章：ベンダが途中で撤退。その途中まで開発した分の費用を請求してくることに
→要件の必要性・十分性をチェック
フィーリングマップを作る（どの部署のどの役職が笑顔or不機嫌？）
3章：規模の小さいベンダに大きなPJを任せたくないが・・・
失敗しないベンダの選び方
→リスク管理ができているか。ベンダ内部の問題も発注者に開示しているか。
発注者はベンダの問題を取り込もうとしているか。
4章：社員がシステム要件作成に協力してくれない
→社員の意識を変えるため、経営トップが人事権を使う
PJオーナーは社長。
5章：ベンダの選定はばくちのようなもの？
→ベンダが悪い、といっても得られるものはない。
ベンダのリスクも共有する。3章同様。
6章：発注者はどこまでわがままを言えるのか
→モヤモヤが消えるまで質問や注文を繰り返す。双方ともやり方の正しさに自信が持てる
7章：情報漏洩への対応
→事前対策、事後対策を立ち上げ段階から考えておく。
Posted by ブクログ
知ってるつもり、復習のつもりで読んだのだが、
全然できてない、全然足りなかった。
失敗したプロジェクト(検収とか納品はした)の分析・総括ができてなかったんだな。
発注者・ベンダ、その時々でどちらの立場でもあるわけだが、
大変に勉強・参考になりました。
これ、ITだけじゃなく様々な企画のプロジェクトへ通じると感じました。
Posted by ブクログ
面白い。システム開発のベンダーに何かを注文したとしても、発注主はただ任せるのでは駄目だというのがよく分かる。こういう世界に無知な自分にとってはとても参考になった。
Posted by ブクログ
普段システムを受注して作る側なわけなんですが、一方で発注側支援コンサルみたいなこともやっていて、お客様側の話も理解したいなと常々思ってました。
わりと最後の方ですが、発注側がベンダのキャリアパスとか考えてモチベートしていかないとみたいな話があって、まさか、お金出す側がそんなこと考えないといけないなんて、、と思いますが、私も最大限気を遣っていただいているのだなと思うと、なかなか胸熱だったりします。
しかし、ヒューマンドラマの最後のオチ、あれはないわあ。
Posted by ブクログ
小説仕立てで様々な失敗しそうなITプロジェクトの例をあげながら改善ポイントを主に発注側の視点で、時には受注側の気持ちも織り交ぜつつ解説する。ストーリーの後にサマリーが合ってまぁ分かりやすい。
ただ小説の内容があまりにチープ...今どきそんなキャラいないだろ...昭和のおっさんのファンタジー。若い20代女性社員を「お前」とか呼んだらコンプライアンス違反ですよ...
Posted by ブクログ
要件定義過程において必要なポイントをストーリー形式で解説。先回りしてのリスク管理とリスクをユーザーとベンダで共有できる仕組みが必要。ベンダ側の注意点として気をつけなければいけないのは、合意なく成果物の開発に着手すること。成果物は随時合意することが重要。ユーザーのPJ目的に照らして、本件を超えた全社的な目標を頭に入れつつ会話をすることが+αに繋がるか。
Posted by ブクログ
導入企業側からITシステム構築プロジェクトのマネジメントのトラブルになりがちなところをストーリー仕立てで紹介した本。
入門書としては悪くない。実際の判例にも触れて、どのようなトラブルが起きうるか紹介している。顧客とのやり取りに慣れてない人だと得るものが多そう。
以下、参考になった点。
業務フローには業務を行う上で懸念事項や疑問点も書き込む。業務フロー図に、現状の問題点だけじゃなくて、自分たちのいいところとか残したい業務も書いて貼っておく。
Posted by ブクログ
小説仕立てで読みやすい。Sl業界の知識が薄くてもすんなり読める。
ストーリーに陳腐な部分もあり、そこに気を取られてしまうこともあったが・・・。
各章の始まりと終わりにポイントがまとまられており、その部分で理解が深まる。
システム開発が実際どうやって進んでいくのか？というイメージも持てる。
逆にエンジニアの方が読むには物足りないのではないかと思う。
全体を読んでの感想としては、システム開発は関係者全員が我が事感を持って分け隔てなく意見を言い合って進めましょう、ということだと思う。
それを行う上で、目指すべき姿、改善しなければならない点、どうやって進めていくかという計画やアクションにおけるプロトコルを事前にしっかり決めておくことが大事なのだと感じた。
Posted by ブクログ
小難しい要件定義に関する本かと思っていたら、物語調で大変読みやすい。
システムを外注するというのは、決してシステム部門だけに降りかかってくる話ではないので、知っておいて損はないです。
分厚くみえますが物語調なのでサクッと読める。おすすめ。
Posted by ブクログ
生産管理システム構築の過程でシステム構築のポイントを整理したくて読んでみた書籍。
小説風のストーリー仕立ては、それほど面白くないが、要件定義のポイント整理やベンダとの向き合い方、リスク管理など各章のまとめページは、今後のシステム構築で迷ったときの立ち返るポイントリストとして使えるものだと感じた。
Posted by ブクログ
システムを外部のベンダーさんと一緒に開発したことは何度か経験あるけども、
外注をしておまかせすれば、思った通りに夢を叶えてくれるわけではない。
注文した側も、きちんと責任と役割を分担して進めていかないと、いけないんだよね。
これって、システムに限らず人にものを頼むときもそうだと思う。
丸投げして、あとでチガーウ！と言われても、頼んだ方の責任も大きいよね。
Posted by ブクログ
「業務フローに社員の感情を書き込め」にはハッとした。全体最適を考えるとどうしても負荷が増える部門が発生してしまうが、特に経営陣に説明するときに使えると感じた。他にも「ベンダー内のトラブルも言ってもらえるような関係性を構築する」などシステムを外注している情報システム部門担当者は一読しておくと良い。, 当然、ストーリー通りにいかないケースは多数あるが、この本を「基本」とすると良いのではないか。
Posted by ブクログ
情報システム構築を発注する側の人間が奮闘する内容でオムニバス形式のストーリ仕立てになっています。（ただしメインの登場人物は同じ）
世の中に出回っている情報で、発注側の視点に立ったときに参考になるものは意外と少ないのが現状です。
本書は、システム企画や構築を外部に発注する経験が少ない人や、経験はあるけれどなかなか上手くいかずモヤモヤを抱えている人向けに、システム導入プロジェクトを推進するにあたって重要なポイントが提示されています。
また、発注側だけでなくベンダーが果たすべき義務についても触れており、ベンダー側の人が読んでも得るものは多いと思います。
ただ、本書はあくまで要点を紹介しているだけなので、プロジェクトを回すための実務レベルの情報については、それ相応の書籍等をあたることをお勧めします。
Posted by ブクログ
業務要件定義：新しくシステムを導入して、どんな業務を実現するのかを決める作業
システム要件定義：業務要件定義書に書いたことを実現するために、システムが持つべき機能を書き出す作業
いずれも発注者が行う作業
特に業務要件定義は、発注者自身が全面的にリードしないといけない。社外ベンダには分からないことが多いため
業務要件定義書を書くより前にやらないといけないこと、社内全体の業務を俯瞰して、全体最適の視点から、業務の問題点や新しいシステムが実現することで改善される点、全社的なメリットなどがひと目でわかる資料を作成すること。
業務フロー図を作成すること。業務フロー図には、さまざまなメモ書きをしていかないと、最終的には役に立たないシステムになる
機能要件：システムができること・できないことを具体的に明らかにする作業。この不備はトラブルの原因のワースト1
まずは現状のながれ、As- Isと、その問題点を明らかにして、それを解決する業務の姿、T o-Beを書く、２つの業務フロー図並べて見ることで、業務のプロセスや組織をどう変えるのか、そしてどの業務をシステム化すべきかが初めて明らかになる
業務を行う上での懸念事項や疑問点も書く
業務フロー図の段階でシステム化する範囲を決めてしまうと、本当はシステム化すべきではない業務を範囲に入れてしまったり、逆にシステム化すべき部分が未検討になる
その他は使わない
システム化するのは、効果が明確に説明できるところだけ
システム化する範囲は、本当にそこをコンピュータでやるべきか、何度も考えて決める
会社は各部門が有機的につながってこそ機能するということが、この1枚の図でよくわかる
社員やお客様さんがどんなふうに喜ぶのか、ちゃんとイメージして作ったか
自社の最大の強みにもっとこだわる
大事なことは社長かはも言うべき
サイトを使う人全員の立場になりきって、喜びとか苛立ちとかの感情を含めて全部共有しないと、本当に役に立つサービスを作ることはできない
業務フロー図には目的を書き込んでおく
懸念と理想も出来る限り書いておく
第1章まとめ
・システムを導入する目的を忘れないように書き留めておく
・業務フロー図には、懸念事項や課題とモレなく書き込む
・システムを導入して誰が喜び、誰が困るのかも書き込む
・システム化の範囲は、効果が明確に説明できる部分に限る
・システム担当者自身が、業務をどのように改善するかという「意識」を持つ
・システム担当者となったからには、自分の思いは隅に置いて、改善の推進者になりきる
要件定義で最低限確認すべきチェックリスト
134p135p
フィーリングマップ
139p
第2章まとめ
・システム担当者にはシステム化する対象業務の知識が必要
・発注者側の責任で頓挫したプロジェクトの賠償責任は発注者にある
・システム担当者がモチベーションを上げるにば、経営者の視点でシステム導入の意味や目的を考えてみるとよい
プロジェクト管理には、全体の工数の10％程度を見込んでおくべき
176〜179p
第3章まとめ
・ベンダの示すプロジェクト管理項目と管理工数が十分かを見極める
・信頼できるベンダは、自社内リスクも含めて、ユーザーと共有する
・要件の変更や追加を、ただ承諾するベンダにはプロジェクト管理義務違反の恐れがある
・ベンダの示すリスクを、まずは傾聴する
第4章まとめ
・システム担当者は、往々にしてエンドユーザーの協力が得られず孤立する
・エンドユーザーにヒアリングするときには、最低限の業務知識を得ておくこと
・難解なIT専門用語を使わない
・相手が忙しい中、時間を割いてくれていることに感謝する
・システム担当者が他部門と調整するときには、その上司がフォローと支援をする
・エンドユーザーの協力を得るには、システム開発の意義や目的について、経営トップからのメッセージングを繰り返す
・経営陣は、システム開発も社員全員の本業であるという意識づけとしくみの改革をすること
264〜269p
第5章まとめ
・ベンダにリスクを開示させるために、発注者側は真摯に聞く姿勢を忘れない
・ベンダのリスクもプロジェクトのリスクと同じように、発注者側が知るべきことと認識する
・ベンダのリスクは発注者側から引っ張り出す
・定量的なプロジェクト状況やスキル評価、工数の妥当性のほか、プロジェクトに合わせて設定した評価軸でベンダのリスクを評価する
287p
第6章まとめ
・期限までに要件を決めきれないことは日常茶飯事
・要件定義工程完了前に、「今後、どうすべきか？」を改めて話し合う、チェックポイント会議を開く
・ベンダへの質問に遠慮は不要。
技術でも業務でもどんどん聞くべき。
そうすることで、ベンダ側の知識が醸成されることもある
・たとえパッケージソフトを使うときでも、どうしてもこだわりたい自社の長所は捨てずに入れ込む
・発注者とベンダは、お互いに「自分たちのほうが損している」と思う程度がちょうどいい
Posted by ブクログ
前著と同様にITシステムを発注するときのトラブルを物語形式で紹介している本。典型的なケースがいくつか取り上げられている。ITシステムの発注に特有なことも多いが、開発やデザインを外注するときにも該当することが多い。社内では、自分ではりかいできないようなことでも、とにかく金を払って外注すればやってくれる、のような考え方がいまだに多く、相変わらずトラブルが続発している。
Posted by ブクログ
「なぜ、システム開発は必ずモメるのか？」の著者と同じということに気づかず、タイトルのみで手に取った。
前回が訴訟ベースで深掘りが浅い部分が多かったが、本書では事例ベースの話で、よりわかりやすかった。APPENDIXの内容は、プロジェクト発足当初に皆で意識合わせしておいた方がよいものが多く、プロジェクトマネージャーを任せられた方が最初に読むにはいいボリューム感の本だと感じた。
ただ、前書と同じく、ラノベ形式でストーリーが進行するので、ベンダーとの契約内容など、もう少し詳しい部分は別の本で補完する方がよさそうである。
Posted by ブクログ
システムの発注者側としての注意すべき要点について、網羅的ではないが有用な視点が書かれている。
良い点として、小説仕立てで取っつきやすいという点と、あまり他のこの手の本では書かないようなリスク管理の考え方の話が参考になりそう。
登場人物のITコンサルの女性が現実離れしたキャラクター設定なのはアレだが(20代の設定には無理がある、あとクライアントにこんな失礼な態度取る奴は普通いない)
フィーリングマップはこの本で初めて知った手法だが、キャッチーで面白そうだと思った。実務で使ってみたい。
Posted by ブクログ
基本的なことで、頭ではわかっていることが中心。
ただ、実際は工数の関係やコミニュケーション不足で、できてないことも多い。
発注者、ベンダーで立ち位置は異なっても、プロジェクトを成功させるために、お互い意見を交換して、進めていくことが大切。
Posted by ブクログ
Appendixに価値がある。発注者の役割や要件定義のチェックリスト、プロジェクト計画書に盛り込むべき項目に、リスクを洗い出すときのチェックリスト等。
全体的に外注する場合の注意点として、主にリスク管理に重点を置かれている。特に、発注者側のベンダの内部に潜むリスクへの対応の仕方やスタンスは参考にする価値あり。
ただ、ストーリーはやや冗長でコスパは若干悪い。
Posted by ブクログ
例題部分は読み物として物足りなさはあったけど、実用書としては私に土地勘もないので手ごろに役立ちそう。しかしまあシステム関係が地獄になりがちなのはこういう原因があるからなのね。
Posted by ブクログ
本書は各章でよく起こりそうな問題をストーリ仕立てで紹介しており、解決に導くにはどうしたらよいか？を考えさせる内容になっている。とはいうものの所々に「Hint」が記載されており、理解の助けとなっている。読み物としてみればなかなか面白いが、よくある一般的な管理手法等を体系的に学びたい人には不向きである。
また合間合間にチェックリストの付録があり、自分が使用しているひな形と比べる事が出来た。
開発側としてはプロジェクトスタート時には無関心でいられ、出来上がってから文句を言われるのが一番困る。システム開発はあくまでも協調作業という事がこれを読んで広まればうれしい。
Posted by ブクログ
とあるシステムを市民開発することになり、PJメンバー間の認識ズレが気になっていたところに、参考にしようと手にとりました。読みやすくするためのストーリー展開に古さを感じましたが、押さえるべき要点が理解しやすく書かれていると思いました。
Posted by ブクログ
ストーリー仕立てで、システム導入時の注意点が学べる本。
いまだに世間ではシステム導入は博打であり、当たるも八卦、当たらぬも八卦といった風潮が見られる。
しかし実際はベンダ側にknowledgeが蓄積されつつも、肝心の導入企業側の理解が高まっておらず、いまだに下請けを扱うかのような高慢な態度でシステム導入を進める結果、失敗しているケースが多い。
本書で書かれているような、業務フローの作成方法、そもそもの業務理解、ベンダ選定やその後のリスク管理、ベンダとの連携、社内協力、情報漏洩への対処、などを理解しておけば、大きな失敗は防げるのではなかろうか。
Posted by ブクログ
本書は自分の会社や組織にシステムを導入しようとしている、システム担当者やプロジェクトマネージャーに向けて書かれています。小説のようなストーリー仕立てで、営業から新しいシステム作成の担当に抜擢された主人公と、外部のコンサルタントが協力して問題を解決していく中で何が大事なことなのかを学んでいけます。ストーリー自体は面白かったですし、著者が言いたい「システムの開発は、発注者とベンダの協業であるという」こともよく分かりました。システム企画に初めて関わる私のような立場であれば、最初の本としてはオススメだと思います。
Posted by ブクログ
システム開発に関わらず、発注者は他部署に影響するサービスを購入する場合、サービスの基礎知識・周りを巻き込む力・目的、手段を伝える力がないと優秀なコンサル、商品力があってもビジネスの成功率は低い。業者への丸投げ体質が負の遺産を作る仕組みになってるように思えた。
