本棚登録 : 
感想 : 
- Amazon.co.jp ・本 (352ページ)
- / ISBN・EAN: 9784478065792
感想・レビュー・書評
-
発注者から眺めた、IT関連のプロジェクトの怖さ、難しさを言語化した問題提起の書。
情報システムの構築にあたっての最上流 要件定義の以降の工程をとらえて、しかも発注者の立場からシステム開発を論ずる書です
プロジェクト中に発生するさまざまな問題に対して、ベンダと一緒に対応したり、ベンダの作成したシステムをテストするなど、発注者にもたくさんの役割を果たす義務があります。
これを、「ユーザの協力義務」といい、その義務を果たさない発注者は、使えないシステムに膨大なお金を払った上に、損害賠償まで請求される危険すらあります。
プロジェクトの失敗とは、「納期オーバ」、「コストオーバ」、「完成したシステムに当初望んだ通りの機能が備わっていない」という３つのいずれかに当てはまるケースです。
本書の目的は、「本当に役に立つシステム」を完成させるための最低限の知識をお伝えすることです。
著者は、ソフトウエア開発会社にて、プロマネを経験し、ＩＴコンサルとなり、経産省にて政府ＣＩＯ補佐官として政府の基幹系システムに従事した経験をお持ちです。
システム開発プロジェクトは発注者が構想し、リードする時代に入ったといっています。
気になったのは、以下です。
・いきなり要件定義書を造ってはいけない。
・まずは、社内全体の業務を俯瞰して、全体最適の視点から業務の問題点や新しいシステムが実現することで改善される点、全社的なメリットなどがひと目でわかる資料を作成します。
・そのためには、まずは、業務フローを作成します。そして、その中にさまざまなことをメモ書きしていきます。
・ベンダーにどんな機能や性能をもつシステムがほしいかを決めて、ベンダに伝えることは発注者の役割になります。
・そのためには、２つの業務フローを作成します。ＡｓＩｓ：現在の業務の流れ、ＴｏＢｅ：現在の問題点を解決して実現する新しい業務の流れ
・システム化を行うのは、効果が明確に説明できるところのみを対象とします。そのために、システム化する範囲は何度も考えて決定します。
・業務フローをつくっていい点は、会社の各部門が有機的につながってこそ機能するということが、１枚の図でよくわかることです。
・次に業務フローに合わせて、社内の発注者の役割を付していきます。①エンドユーザの責任者、②プロジェクト承認者（社長など）、③プロジェクトマネージャー、④システム担当者
・そしておもな作業は、さらに工程別にブレークダウンします。①要件定義、②委託先選定、③プロジェクト計画、④設計・要件変更、⑤受け入れ試験、⑥移管・サービスイン
・システム開発成功のキモは、受託ベンダーの「リスク管理」にある
・ベンダーの能力は「プロジェクト管理計画」で評価できる
・プロジェクトを管理するためのツール、プロジェクト計画書、プロジェクト管理計画書、ＷＢＳ，リスク管理票、課題管理表、故障管理表、
・プロジェクト管理工数は、全体工数の１０％前後、プロジェクトの進捗遅れは、５日以上遅れたらアラートを上げる
・ＩＴシステムは、ビジネスの主役になりつつあり、本業と同様重要な課題になっている。
・各部からは、多忙を理由に要望の取りまとめに協力してくれないケースが多い システム担当者が孤立してしまいがち。
・ユーザからは、ベンダー自体のリスクは見えにくい。いわば盲点となっている。
・ベンダーのリスクもユーザと共有すべき リスクチェックポイント、リスク管理表
・ベンダが勝手に作業を進めても、黙認すると「合意」したとみなされる
・要件定義終了時に宿題と、方針をチェックポイント会議で確認する
・技術的な話は、最終的にベンダが責任をもつが、それを決める過程では発注者だって口出ししてかまわない
・気になることがあれば、何度でもエンジニアに質問したり設計のやり直しを依頼する
・もやもやが消えるまで質問や注文を繰り返すことで、発注者もベンダも、今のやり方の正しさに自信が持てる
・業務フロー図に、現状の問題だけでなく、自分たちのいいところ、残したい業務も書いて貼っておく
目次
はじめに 発注者は「お客様」ではなく「プロジェクトメンバー」
第１章 システム作りは業務フロー図から
第２章 発注者がこれだけは知っておくべき最低限のこと
第３章 失敗しないベンダの選び方
第４章 社内の強力を得るために
第５章 リスク管理で大切なこと
第６章 ベンダとの適切な役割分担
第７章 情報漏えいを起こしてしまったら
エピローグ
ISBN：9784478065792
出版社：ダイヤモンド社
判型：A5変
ページ数：336ページ
定価：1980円（本体）
発売日：2017年06月14日第1刷
7
詳細をみるコメント0件をすべて表示 -
システムを外部のベンダーさんと一緒に開発したことは何度か経験あるけども、
外注をしておまかせすれば、思った通りに夢を叶えてくれるわけではない。
注文した側も、きちんと責任と役割を分担して進めていかないと、いけないんだよね。
これって、システムに限らず人にものを頼むときもそうだと思う。
丸投げして、あとでチガーウ！と言われても、頼んだ方の責任も大きいよね。
1
-
「業務フローに社員の感情を書き込め」にはハッとした。全体最適を考えるとどうしても負荷が増える部門が発生してしまうが、特に経営陣に説明するときに使えると感じた。他にも「ベンダー内のトラブルも言ってもらえるような関係性を構築する」などシステムを外注している情報システム部門担当者は一読しておくと良い。, 当然、ストーリー通りにいかないケースは多数あるが、この本を「基本」とすると良いのではないか。
1
-
基本的なことで、頭ではわかっていることが中心。
ただ、実際は工数の関係やコミニュケーション不足で、できてないことも多い。
発注者、ベンダーで立ち位置は異なっても、プロジェクトを成功させるために、お互い意見を交換して、進めていくことが大切。
1
-
システム開発に関わらず、発注者は他部署に影響するサービスを購入する場合、サービスの基礎知識・周りを巻き込む力・目的、手段を伝える力がないと優秀なコンサル、商品力があってもビジネスの成功率は低い。業者への丸投げ体質が負の遺産を作る仕組みになってるように思えた。
1
-
Appendixに価値がある。発注者の役割や要件定義のチェックリスト、プロジェクト計画書に盛り込むべき項目に、リスクを洗い出すときのチェックリスト等。
全体的に外注する場合の注意点として、主にリスク管理に重点を置かれている。特に、発注者側のベンダの内部に潜むリスクへの対応の仕方やスタンスは参考にする価値あり。
ただ、ストーリーはやや冗長でコスパは若干悪い。
1
-
普段システムを受注して作る側なわけなんですが、一方で発注側支援コンサルみたいなこともやっていて、お客様側の話も理解したいなと常々思ってました。
わりと最後の方ですが、発注側がベンダのキャリアパスとか考えてモチベートしていかないとみたいな話があって、まさか、お金出す側がそんなこと考えないといけないなんて、、と思いますが、私も最大限気を遣っていただいているのだなと思うと、なかなか胸熱だったりします。
しかし、ヒューマンドラマの最後のオチ、あれはないわあ。
1
-
本書は各章でよく起こりそうな問題をストーリ仕立てで紹介しており、解決に導くにはどうしたらよいか？を考えさせる内容になっている。とはいうものの所々に「Hint」が記載されており、理解の助けとなっている。読み物としてみればなかなか面白いが、よくある一般的な管理手法等を体系的に学びたい人には不向きである。
また合間合間にチェックリストの付録があり、自分が使用しているひな形と比べる事が出来た。
開発側としてはプロジェクトスタート時には無関心でいられ、出来上がってから文句を言われるのが一番困る。システム開発はあくまでも協調作業という事がこれを読んで広まればうれしい。
1
著者プロフィール
細川義洋の作品
