細川義洋のレビュー一覧

システムを「外注」するときに読む本

物語仕立てで読みやすい。ストーリー形式で問題定期と解決策が示される為、未経験の人にとってはとても読みやすく、勉強になる本だと感じた。

ただし、作中でも記載されていたが、あくまで参考書であって、教科書ではない。

ITは新しいことばかりなので、日々情報収集や勉強が大事だと痛感した。

システムを「外注」するときに読む本

発注者から眺めた、IT関連のプロジェクトの怖さ、難しさを言語化した問題提起の書。

情報システムの構築にあたっての最上流　要件定義の以降の工程をとらえて、しかも発注者の立場からシステム開発を論ずる書です

プロジェクト中に発生するさまざまな問題に対して、ベンダと一緒に対応したり、ベンダの作成したシステムをテストするなど、発注者にもたくさんの役割を果たす義務があります。
これを、「ユーザの協力義務」といい、その義務を果たさない発注者は、使えないシステムに膨大なお金を払った上に、損害賠償まで請求される危険すらあります。
プロジェクトの失敗とは、「納期オーバ」、「コストオーバ」、「完成したシステムに当初望んだ通りの機能が備わっていない」という３つのいずれかに当てはまるケースです。

本書の目的は、「本当に役に立つシステム」を完成させるための最低限の知識をお伝えすることです。
著者は、ソフトウエア開発会社にて、プロマネを経験し、ＩＴコンサルとなり、経産省にて政府ＣＩＯ補佐官として政府の基幹系システムに従事した経験をお持ちです。

システム開発プロジェクトは発注者が構想し、リードする時代に入ったといっています。

気になったのは、以下です。

・いきなり要件定義書を造ってはいけない。
・まずは、社内全体の業務を俯瞰して、全体最適の視点から業務の問題点や新しいシステムが実現することで改善される点、全社的なメリットなどがひと目でわかる資料を作成します。
・そのためには、まずは、業務フローを作成します。そして、その中にさまざまなことをメモ書きしていきます。
・ベンダーにどんな機能や性能をもつシステムがほしいかを決めて、ベンダに伝えることは発注者の役割になります。
・そのためには、２つの業務フローを作成します。ＡｓＩｓ：現在の業務の流れ、ＴｏＢｅ：現在の問題点を解決して実現する新しい業務の流れ
・システム化を行うのは、効果が明確に説明できるところのみを対象とします。そのために、システム化する範囲は何度も考えて決定します。
・業務フローをつくっていい点は、会社の各部門が有機的につながってこそ機能するということが、１枚の図でよくわかることです。
・次に業務フローに合わせて、社内の発注者の役割を付していきます。①エンドユーザの責任者、②プロジェクト承認者（社長など）、③プロジェクトマネージャー、④システム担当者
・そしておもな作業は、さらに工程別にブレークダウンします。①要件定義、②委託先選定、③プロジェクト計画、④設計・要件変更、⑤受け入れ試験、⑥移管・サービスイン

・システム開発成功のキモは、受託ベンダーの「リスク管理」にある
・ベンダーの能力は「プロジェクト管理計画」で評価できる
・プロジェクトを管理するためのツール、プロジェクト計画書、プロジェクト管理計画書、ＷＢＳ，リスク管理票、課題管理表、故障管理表、
・プロジェクト管理工数は、全体工数の１０％前後、プロジェクトの進捗遅れは、５日以上遅れたらアラートを上げる

・ＩＴシステムは、ビジネスの主役になりつつあり、本業と同様重要な課題になっている。
・各部からは、多忙を理由に要望の取りまとめに協力してくれないケースが多い　システム担当者が孤立してしまいがち。

・ユーザからは、ベンダー自体のリスクは見えにくい。いわば盲点となっている。
・ベンダーのリスクもユーザと共有すべき　リスクチェックポイント、リスク管理表

・ベンダが勝手に作業を進めても、黙認すると「合意」したとみなされる
・要件定義終了時に宿題と、方針をチェックポイント会議で確認する
・技術的な話は、最終的にベンダが責任をもつが、それを決める過程では発注者だって口出ししてかまわない
・気になることがあれば、何度でもエンジニアに質問したり設計のやり直しを依頼する
・もやもやが消えるまで質問や注文を繰り返すことで、発注者もベンダも、今のやり方の正しさに自信が持てる

・業務フロー図に、現状の問題だけでなく、自分たちのいいところ、残したい業務も書いて貼っておく

目次

はじめに　発注者は「お客様」ではなく「プロジェクトメンバー」
第１章　システム作りは業務フロー図から
第２章　発注者がこれだけは知っておくべき最低限のこと
第３章　失敗しないベンダの選び方
第４章　社内の強力を得るために
第５章　リスク管理で大切なこと
第６章　ベンダとの適切な役割分担
第７章　情報漏えいを起こしてしまったら
エピローグ

ISBN：9784478065792
出版社：ダイヤモンド社
判型：A5変
ページ数：336ページ
定価：1980円（本体）
発売日：2017年06月14日第1刷

システムを「外注」するときに読む本

日頃のベンダー管理がうまくできていないと感じていたので、業務改善の参考にしたいと読んでみた。
ストーリーは置いておいて、物語仕立てなので、それぞれの立場でどう考えており、どんなことに気を付ければ良いかが、分かりやすく学べた。
特に自社内のリスクも含めて、ユーザーと共有することについて、考えさせられた。
言っても意味がないし、聞いてもらえないだろうと諦めてしまったことを思い出した。
このように、教科書に載っていないような、他人の失敗を疑似体験できる良い本だと感じた。

システムを「外注」するときに読む本

めっちゃ面白い。プロマネの仕事やりたくなる。業務ベースで起こりうる問題をストーリー仕立てで提示していて読みやすい。
71/100

システムを「外注」するときに読む本

物語形式で話が進んでいく＆1章ごとにテーマが分かれているため
非常に読みやすい。
ただ、読みやすいが故に読み終わった後にしっかり振り返らないと
ビジネス小説を読んだだけ、になってしまう。

というわけで振り返り。
1章：主人公(白瀬)が社内システムを作ることになり、
システム要件定義作成に四苦八苦する。
→業務フロー図には目的・理想・懸念を書く
　自社の強みを活かすことを忘れない

2章：ベンダが途中で撤退。その途中まで開発した分の費用を請求してくることに
→要件の必要性・十分性をチェック
　フィーリングマップを作る（どの部署のどの役職が笑顔or不機嫌？）
3章：規模の小さいベンダに大きなPJを任せたくないが・・・
　　失敗しないベンダの選び方
　→リスク管理ができているか。ベンダ内部の問題も発注者に開示しているか。
　　発注者はベンダの問題を取り込もうとしているか。
4章：社員がシステム要件作成に協力してくれない
　→社員の意識を変えるため、経営トップが人事権を使う
　　PJオーナーは社長。
5章：ベンダの選定はばくちのようなもの？
　　→ベンダが悪い、といっても得られるものはない。
　　　ベンダのリスクも共有する。3章同様。
6章：発注者はどこまでわがままを言えるのか
　　→モヤモヤが消えるまで質問や注文を繰り返す。双方ともやり方の正しさに自信が持てる
7章：情報漏洩への対応
　→事前対策、事後対策を立ち上げ段階から考えておく。

システムを「外注」するときに読む本

知ってるつもり、復習のつもりで読んだのだが、
全然できてない、全然足りなかった。

失敗したプロジェクト(検収とか納品はした)の分析・総括ができてなかったんだな。

発注者・ベンダ、その時々でどちらの立場でもあるわけだが、
大変に勉強・参考になりました。

これ、ITだけじゃなく様々な企画のプロジェクトへ通じると感じました。

システムを「外注」するときに読む本

面白い。システム開発のベンダーに何かを注文したとしても、発注主はただ任せるのでは駄目だというのがよく分かる。こういう世界に無知な自分にとってはとても参考になった。

システムを「外注」するときに読む本

普段システムを受注して作る側なわけなんですが、一方で発注側支援コンサルみたいなこともやっていて、お客様側の話も理解したいなと常々思ってました。
わりと最後の方ですが、発注側がベンダのキャリアパスとか考えてモチベートしていかないとみたいな話があって、まさか、お金出す側がそんなこと考えないといけないなんて、、と思いますが、私も最大限気を遣っていただいているのだなと思うと、なかなか胸熱だったりします。
しかし、ヒューマンドラマの最後のオチ、あれはないわあ。

なぜ、システム開発は必ずモメるのか？

20160417
受注を受けてから納品するまでの流れとプロジェクトマネージャに要求されるスキルを理解するのに適した本だった。
参考資料も目を通す。

なぜ、システム開発は必ずモメるのか？

素晴らしい内容だった。
どのページも重要で、ピックアップが出来ないぐらい。
定期的に読むべき本である

なぜ、システム開発は必ずモメるのか？

事例を用いた解説で理解しやすい。1つのトピックが4ページと短く、会話形式で読みやすいので読んでいて面白い。ベンダ側・ユーザ側、元請け・下請けと相対する立場でそれぞれ気をつけること、押さえておくべきチェックポイントが参考になる。システム開発をするうえで手元に置いておいて何度も読み返したい本。

なぜ、システム開発は必ずモメるのか？

これは名著！
この本に書かれていること、全てが重要で付箋だらけになってしまった。
タイトルに引かれて手に取ったが、
書かれているのは、システム開発の流れの中で何に気をつけて進めていくのか、どういう箇所が後々問題のポイントとなるのかを説明している。

・何度も要件を追加するユーザ
・ベンダ任せにするユーザ
・ユーザの参加意識をどう高めるか
・プロジェクト完了は何を基準に判断すればよいのか

・・・など、耳は痛いが重要なことばかり。

しかも、これは解説書ではなく、小説形式で物語が進行していくので、
ユーザ・ベンダの立場を理解しやすい。

小説形式だが、トピックは見開きというわかりやすさ。
章末、巻末に収められているチェックリストは、実務に大いに役立ちそうだ。

たぶんこれは後日購入するだろう、
プロジェクト管理の基本として自分の会社でも広めたい本。

【ココメモポイント】
＜要件定義＞
・定期的に要件変更に関する会議を開く
　P.20

・その場しのぎで取り繕って、問題先送りにする態度こそ、不誠実この上ない
　P.21

・業務フローに載る人の意見をすべて収集する必要がある。
　（中略）失敗プロジェクトの９割は、要件定義が関連してる
　P.29

・要件はお客さんの責任って風潮が最近は強すぎる
　P.40

・トレーサビリティマトリクス
　要件定義、設計項目などにＩＤを振って、１つの表にまとめる
　
P.48

・ユーザの業界における“常識”は無視できない
　P.60

＜プロジェクト計画と管理＞
・定量的なプロジェクト管理方法をユーザにもしっかり理解してもらって、定例会の場で認識を共有すること
　P.83

・“紙芝居”をつくってユーザに触ってもらったり、（中略）
　ユーザの興味や参加意識を継続させる
　P.90

＜設計＞
・困ったときには、周りの人と会話したり、考えていることを口に出したり、書いてみるだけでも頭は回転し出すもの
　P.121

・システムで大切なのは、それを使った業務がつつがなく行えることであって、中身じゃないって考え方が一般的
　P.133

＜テスト＞
・システムの品質を守る最後の砦は受入テストではなく、それに向けたテストケースやテストデータのレビューだと思ってる
　P.178

・ＩＴ紛争は、そのすべてが開発中にユーザがベンダに不信を募らせることが土台になってる
　P.186

＜契約と仕事の完成＞
・ベンダは契約書に書いてある事柄を全うするギリギリの作業をして引き揚げる
　P.210

・メンバの机がいつもより乱雑になっていることに気づく細かい神経も求められます
　P.213

・プロジェクト計画をユーザと検討する際には、実力以上の役割を負わず、双方がある程度妥協もしながら役割分担を決めていくことが紛争に発展しないポイント
　P.258

なぜ、システム開発は必ずモメるのか？

システム開発のもめるポイントを主に法律的観点から見て注意点や意識することがわかる本。
システム開発の経験がない人が読んでもハテナとなるかもしれないけど、経験ある人が読んだら納得できることが多い。
そして、訴訟の時に問題になるポイントはそのまま円滑なシステム開発成功の鍵にも当然つながっていくので、法律的観点とはいったら、システム開発に携わる人ならぜひ読んだほうが良い本。

敏腕女性弁護士、中小ベンダ女性SE,ユーザー企業の御曹司、大手ベンダの男性PMを中心としたストーリー仕立て。
「要件定義」「プロジェクト管理」「設計」「プログラミング」「テスト」「契約終了」の章立て。
「要件定義」「プロジェクト管理」のところが個人的には興味をもった。
というか筆者がだんだん疲れてきたのか後半は登場人物のストーリー展開の割合が増えてきた気がする（それはそれで面白かったが）

なぜ、システム開発は必ずモメるのか？

東京地裁のit専門の調停委員によるトラブル事例
とはいってもしっかりpmbok cmmi itilなどの模範的マネージメント概説もある
数時間で読める

なぜ、システム開発は必ずモメるのか？

お仕事で読みました。発注側です。
堅苦しくなく、大切な部分は強調されていて、
読みやすかったです。
ただ、受注側、発注側それぞれに特化した本を
書いて頂ければなお嬉しいです。発注側としては
不要と感じる部分がありました。

なぜ、システム開発は必ずモメるのか？

いわゆるべからず集。顧客と折衝するような立場にある人は一読の価値あり。一度読んで終わりではなく、事あるごとに参照したい内容でした。しかし、思った以上に情報ベンダの責任は重いんだな•••

なぜ、システム開発は必ずモメるのか？

各工程におけるユーザ・ベンダ間の問題について、法律観点で解説されている。
IT契約は、契約書の文言云々よりも、実態ベースで判断がされることは覚えておいたほうがいい。
設計書に書いているから大丈夫！承認貰ってるから大丈夫！という甘い考えでは、後々大トラブルのタネとなること請け合い。

「信義則義務」「善良なる管理者の注意義務」など、プロジェクトをマネジメントする側で参画する立場の人は知っておくべき。

それにしても、結局塔子と一郎はどうなったのだろう…
まあ一郎は有能なPMのようなので、大丈夫かな。

なぜ、システム開発は必ずモメるのか？

名著！
プロジェクト管理云々より最初に、「ベンダはプロフェッショナルなのだから、プロフェッショナルとしてユーザの目的達成に協力しなければいけない」ということに気づかされた。

例えば、建築家が、お客さんがリビングを広げたいというからと言って、リビングを広げる代わりにトイレをなくして、後で「あれっ、図面見せましたよね」なんて言ってはいけないのだ。

なぜ、システム開発は必ずモメるのか？

システム開発を請負、マネジメントする立場になった私にとって、本書はとてもわかりやすく、有意義なポイントが整理され、とても勉強になりました。

システムを「外注」するときに読む本

当たり前のようにおこなわれるシステムの「外注」について正面から取り上げたものは珍しい気がする。外注という視点なので、ベンダではなくユーザが主なのも斬新かも知れない。書いていることは当たり前と言えば当たり前のことばかりと言えなくもないが、これだけ整理されたものはなかなかないかも。