- Amazon.co.jp ・本 (270ページ)
- / ISBN・EAN: 9784534051158
感想・レビュー・書評
-
2017年6月6日読了。IT開発にまつわる過去の訴訟・調停の例などを引きつつ、IT開発においてユーザ・ベンダそれぞれがやるべき業務の範囲・責任などをストーリー仕立てで読み解いていく本。そっけない装丁とマーケティング狙いじみたタイトルと、素っ頓狂なキャラがやり取りを繰り広げる中身とのギャップがすごいが、自分の仕事に大いに関わる内容でもあり、当事者だけに内容は非常にグッとくる。「ユーザがやってくれない・決めてくれないからしょうがない」というだけのベンダであればいらないし、裁判になった時に「専門性を有したベンダとして果たすべき責務を果たしていない」と判断される可能性も大ということなのだな…。目的を定め、計画を立て、関係者の合意を得て、実行して問題の兆候を見つけ解決し、ユーザに満足してもらい会社として利益を得る、とこれらは全てPMPにある内容であり、PMが当然やるべきことなのだが…難しいよな、日々努力が必要や。
詳細をみるコメント0件をすべて表示 -
物語調で進んでいくのでイマイチかと思っていたが、大事なポイントは押さえられている気がして、良かった。
ただ、物語のせいでやや冗長なので、自分で一度まとめ直したいな、と思う。 -
■書名
書名:なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術
著者:細川 義洋
■概要
実に、およそ7割が失敗するというシステム開発プロジェクト。そ
の最悪の結末である「IT訴訟」の事例を参考に、トラブルの予防策
と対処法が学べる1冊です。“IT訴訟専門弁護士・塔子”がトラブル
を解説するストーリー!
(From amazon)
■感想
この方の本は2冊目です。
ITの訴訟調停委員という肩書を持つ方で、ネットの連載も読ませて
いただいておりますが、日本+ITという特殊な事情が裁判を法律通り
の結果にさせない感じになっているのがしっかり伝わってきます。
例えば「検収したら判を押した側がその後全責任を持つ」と考えて
いる方も多いと思いますが、検収をしても納品したものがあまりに
実際の業務とかけ離れている場合、業界特殊の常識を満たしていな
い場合には、納品下側が負ける可能性が高くなります。
こういうのは、こういう調停に関わらない限り知らない部分だと思い
ますし、会社の法務関係、弁護士でも知らない部分も多いと思います。
面白いのは、裁判官は結構実際の業務、業界特有の常識、ITプロジェクト
特有の契約などを考慮し、判決を下している部分ですね。
そんなの「当たり前じゃん」と言われれば元も子もないのですが、法律
一辺倒では無いのが裁判の面白い部分であり、難しい部分でもあります。
私も裁判に発達した案件に関わっていたので分かりますが、裁判沙汰
になると、この本にや他の本でも書いてあるように、基本的に信頼関係
は崩壊しますので、後はごまかし/嘘を言ってないなどもう情報の隠し
合いになります。
自分の感覚では、客が偉そう/圧力的であればあるほど最終的に客が損
すると思います。ベンダは作っているけど、言わなくても良い事(要件に
入っておらず詳細なプログラムの動きなど)は言いませんから、後でそう
いう時限爆弾が破裂する可能性が高くなり、その時に困るのは客となります。
勿論、こういう事ばかりではありませが、こういう事も起こり得ると
言う事です。
どの本でも言われていますが、結局、争いを生むのは全てコミュニケー
ション不足、高圧的な態度によるものです。
コミュニケーション不足の中には、「当事者意識の不足」も含まれます。
「言うが易く行うは難し」ですが、もうこれは言ったうえで出来る範囲で
実際に実施していくしかありません。
正直に謝れば怒られますが、その後ある程度は許して頂けるはずなのですが
これをしない会社/プロジェクトの多い事、多い事。
これは、色々と言い訳して、怒られるのが仕事のはずのPM、責任者
が仕事をしていないだけです。
責任者は責任を取るのが仕事でありその代償に大きな金銭を受け取って
いるはずなんですけどね。
経験的にですが、謝れないのは大きな会社(ベンダ)の方が多い気がします。
無駄なプライドがあるのでしょうね。
謝ろうが、謝らなろうが、結局納品したものがダメなら責任を取らされる
はずなので、小さい事に拘りすぎている事が多い気がします。
(こういうのは言っても聞いてもらえないですけどね。)
■気になった点
・要件変更が無いプロジェクトは無い。
・最初に要件変更の会議を開くようにしておく。
そこで、目的/経営方針に従い、本当に必要な要件か?優先順位
はどうか?メリット/デメリットを議論する。
・その場しのぎで取り繕って問題先送りにする態度こそ不誠実この上ない。
・要件について何を決めるべきかの責任はベンダにある。
その決めるべきことをユーザに説明し、実施させる義務がある。
・もめるのも最初の内ならなんとかなると腹をくくる。
・結局、ベンダの情報開示意識とユーザの当事者意識が最後はものを
いう。
・安いが一番というユーザとは、付き合いを考えた方がいい。
・プロジェクトを完遂する事が優秀な管理者では無い。優秀な管理
者は問題早めに検知してうまく損切りしながら最終的に組織に利益
をもたらす。
・信頼せよ。されど検証せよ。
・こじれたときは、敵の中に味方を見つける。
お互い完遂したいと思っているのであれば、個人的に腹をわって
話せば落としどころを見つける事が出来る事が多い。
・業界の常識を知らないでベンダが負けた裁判もある。
・方針をもとに要件定義の範囲を定義する。
・大切なのは内部でも外部でも血の通ったコミュニケーションと
なる。
・ユーザの参加意欲を刺激する方法として、会議で催し物を計画
する。
・個人の視点で見れば早くても、プロジェクト全体としては工数の
無駄遣いというケースは結構ある。
・ユーザは綺麗なプログラムを求めているわけでは無く、システム
を導入し得られる経営的なメリットをもとめている。
・バグは放置せず迅速に修正する。
・バグは簡単に直りますと言っても、ユーザは不安である。
・後から来た第3者の方が、当事者より冷静で妥当な解決策を見つ
けやすい。
■自分がこの作品のPOPを作るとしたら?(最大5行)
ITプロジェクト
裁判
この2つのキーワードに引っかかる人には読む価値あり! -
いわゆるべからず集。顧客と折衝するような立場にある人は一読の価値あり。一度読んで終わりではなく、事あるごとに参照したい内容でした。しかし、思った以上に情報ベンダの責任は重いんだな•••
-
この類の本は一般論や理想論に終始しがちだが、本書は改善の具体策も書かれていて実践に向けてのヒントが満載である。「オーダメイドのシステム作りはベンダと顧客との協同作業である」という判決文はまさに金言。
私はユーザ側のシステム担当者であるから、(ユーザ側の視点に立ちながらも)どこかではベンダとユーザの双方が合意できる落とし所を模索しなければならない。
そういう意味では、協同作業が出来なくなり、裁判まで行き着いてしまった泥沼プロジェクトに対して、裁判所という第三者がどういう視点でジャッジし、または調停でどういう落とし所に持って行っているかを知ることが重要である。
本書に書かれていることは、プロジェクトが無益な泥沼陥らない為に、陥る前に引き返せるように、ベンダ側、ユーザ側の双方が知っておくべき基礎知識なのだと感じた。 -
名著!
プロジェクト管理云々より最初に、「ベンダはプロフェッショナルなのだから、プロフェッショナルとしてユーザの目的達成に協力しなければいけない」ということに気づかされた。
例えば、建築家が、お客さんがリビングを広げたいというからと言って、リビングを広げる代わりにトイレをなくして、後で「あれっ、図面見せましたよね」なんて言ってはいけないのだ。 -
読み物形式で読みやすい
-
・各種のチェックリストは有用
・プロ管費は10%、場合によっては15%。要件定義は1/9、変更管理を合わせると2,3割 -
システム開発
ビジネス