モメないプロジェクト管理77の鉄則

著者 : 細川義洋

• 日本実業出版社 (2014年7月10日発売)

感想・レビュー・書評

[9999modaさんの感想 · 2023年5月6日]

とあるシステムを市民開発することになり。『システムを「外注」するときに読む本』に続いて手にとりました。77の用語を知る、という観点で役立つと思いました。

[ちゅんさんの感想 · 2022年2月3日]

プロジェクトの契約、法律としての観点の話の本
誰がどういう責任、権利を持つかを書いてる

契約時、役割分担、開発範囲、見積もり
契約、請負、準委任、SLA
要件定義、目的、前提制約機能セキュリティ要件、業務フロー
プロジェクト体制、ステークホルダー、プロジェクトマネージャー、承認車
計画管理、憲章、スケジュール、進捗報告、会議、反省会

[Tohkoさんの感想 · 2019年3月11日]

・ベンダーのPM目線
・細かいところまで気が利いた一冊。洗い出しの観点例が良い

[ねこまたさんの感想 · 2017年12月20日]

社内で開発する際、もめずにプロジェクトを進める方法がわかればと思い購入したが、この本でいう”もめない” = “訴えられない”だったので、探していた本とは違った。

[u1000さんの感想 · 2017年9月3日]

辞書的に使える

[kusabyさんの感想 · 2017年7月24日]

出版は3年前だが、ITプロジェクトに携わる者であれば泣きたくなるくらい有用な本。気は滅入るのに読み進めずにはいられない。PMBOKフレームワークの国内PJ実態版に翻訳されたものと言ってもよさそう。とりわけ各章の冒頭のプロマネのひとりごとが涙が止まらなくなるくらい有用。より新しい出版もあるようなのでそちらも手に取る必要があるだろう。

[norikoniさんの感想 · 2016年10月29日]

もめることしかない

[からべーさんの感想 · 2015年2月18日]

■書名

書名：「IT専門調停委員」が教える モメないプロジェクト管理77の鉄則
著者：細川 義洋

■概要

元NEC&IBM、現・東京地方裁判所「IT案件専門調停委員」が教える
炎上しないプロジェクトマネジメントの進め方

「失敗率7割」とも言われるシステム開発プロジェクトにおいては、
全ての問題に通用する万能な解決策、いわゆる「銀の弾丸」はない
とされています。
しかし、失敗を限りなくゼロに近づけるためにすべきことは共通し
ています。
大手ベンダでプロジェクトマネージャ(PM)職を勤め上げた後、現在
はIT紛争の最前線でプロセスコンサルティングと「モメごとの仲裁」
を担う著者が、
「トラブルを起こさないためにPMが最低限知っておくべきこと」を
まとめました。

契約から保守まで、「誰にも言えないPMのホンネ」を踏まえた現実
的なトラブル予防策&解決策77連発!

　「ハナシが全然違うじゃん……」
「そんなこと言ったって、結局、全部オレが尻拭いするんでしょ……」

数あるプロジェクトマネジメントの教科書には、「あるべき論」は
書かれていても、現場で上司や客先やプロジェクトメンバなど様々
なプレッシャーに板挟みになって悩む「PMのホンネ」に寄り添った
本は少ないのが現状です。

本書は、提案見積り段階に始まり、要件定義、契約、プロジェクト
体制、プロジェクト計画と管理、各種開発方式から保守に至るまで、
PMが悩みがちで、かつトラブルになりやすい77のトピックを厳選。
誰にも言えない「プロマネのひとりごと」を踏まえて、トラブルを
知り尽くした著者だからこそわかる現実的なアドバイスを贈ります。

また、辞典のように「用語レベル」で検索できるので、「今、知り
たいこと」にすぐ役立ちます。常に、机上に置いておきたい1冊です。

★本書を役立てていただける人★
・プロジェクトマネジメントを行なう人
・ITプロジェクトに関わる技術者
・IT法務に携わる人
・これからシステム開発を発注しようとしているユーザ企業の人
(From amazon)

■感想

概要を読むと、「あるべき論」以上の事が多々記載されているよう
に思いますが、こういう本は、基本あるべき論に帰結するんだな～
と感じますね。

確かに、当たり前の事を当たり前にやればそこまで揉めないのは
その通りなんですけどね。

この本の面白い部分は、やはり調停という現場を知る人が、そういう
調停の経験、結果をもとに「あるべき論」を書いてあることです。
ここでいう「あるべき論は、実は他の書籍で書いている「あるべき
論」と少し違います。
というのも裁判結果が伴っているので、それなりに説得力があります。

裁判は面白いもので、「要件に定義されていなくても、ベンダはプロフェ
ッショナルであり、他の記載事項と照らし合わせれば、～～の要件が
あったことは分かるはずであり、その要件を満たす責務がある」という
判決が多々出ていたりします。

最善の策はどうしてもあるべき論ですが、実はこの書籍は一般のある
べき論以上の事を求めていたりします。
そのため、かなりハードルが高い事も記載されていますが、色々と
こうした方がいい(出来る出来ないは別にして)というのが記載され
ていますので、非常に勉強になります。

プロジェクトの一つ一つの作業は、それぞれの専門書を読んだ方が
いいですが、ITプロジェクトの全体像を捉えるには、非常に分かり
やすく有用な本だと思います。

■自分がこの作品のPOPを作るとしたら？(最大5行)

IT専門調停委員だからこその事例と提案が多々記載されています。
IT関連のプロジェクトに参加しているのであれば、読んでおいて
損は無いです。

■気になった点

・提案依頼書は、ユーザが最初に投げるべき悪球ということもでき
　ます。

・提案依頼書の記述も要件に化けるため、契約時に洗い直しが必要

・よく紛争となる項目。
　・システム化の目的と方針・メリットについての認識
　・基本要件、機能設計
　・ユーザとベンダの役割分担
　・コミュニケーション計画
　・開発方針

・工程の変更は見積もりやスケジュールを大きく変える可能性があ
　るのにその変更の余地について契約前にユーザと合意しておかな
　ければベンダは何があってもそれを遵守せざるを得ななくなると
　いう危険な状態に陥ります。
　ユーザの責任で作業の段取りを変えざるを得ないような時に備え
　提案書には、その特記事項として開発方針の変更についての注意
　書きを入れておくことが必要です。

・提案書の提案後に内容の誤りや、書きすぎがあった場合には、速
　やかに訂正すべきで契約前の文書だからと甘く考えることは、
　後々自分たちの苦しみの種となりかねません。

・ベンダには特に定義が無くても、システム開発に必要な作業専門
　的知見を用いる作業を行う義務があります。

・実施者、成果物をアウトプットを意識できるまでタスクをブレーク
　ダウンして書く。(WBS)

・義務をベンダに課す以上、その裏にある権利もユーザに認めても
　らうよう交渉する。

・契約書に明記された作業をやったとしてもシステムを使える状態
　にしていなければ契約を主旨をかなえていないという主張は裁判所
　でもよく聞きます。

・中途半端な行為は悪意より性質の悪いものです。

・契約書、仕様書に明記されていなくても、実際に行われる業務に
　照らし合わせてベンダに責を課す判決もある。

・機能要件は、機能ごとに入力、演算、出力が具体的に書いてあり、
　ユーザとベンダが同じ理解をできるものであることがポイントです。

・非機能要件の作業は、システムに関連する人や機会を洗い出す事
　から始めます。

・RASを非機能要件、SLAとして設定する。

・エンドユーザがフロー図を見て発する様々な不平不満と真摯に向き
　合う事が、プロジェクト成功のカギとなります。

・要件定義委には優先度をつけることが重要です。

・管理に必要な工数も「プロジェクト管理費用」としてユーザに
　認めてもらうことが大切です。

・「冷めた関係」を改善するには地道な方法しかないようです。

・WBSは成果物単位で書く。

・WBSは最初から全てを詳細化しない。

・リスク管理をするときは、まずはシンプルに人、モノ、カネで
　考えてみてはいかがでしょう。

・課題とは、プロジェクトの納期、コスト、品質を阻害する事象
　で顕在化しているもの。

[amaekさんの感想 · 2014年9月18日]

判例が豊富に乗っていて考え方の参考になる。プロマネのひとりごとはシュール。初版だからか、誤植が多いのが気になった。

[くろしろうさんの感想 · 2014年9月5日]

プロジェクト管理のツボは、計画段階で押さえておくに限る。

著者プロフィール

ITコンサルタント、政府CIO補佐官。システム開発・運用の品質向上や企業のIT戦略立案の支援を行いながら著述、講演も行う。現在は、政府CIO補佐官としてデジタルガバメントの推進やIT化による行政改革などに取り組む他、行政におけるAI活用の研究を行っている。

「2018年 『ある日突然AIがあなたの会社に』 で使われていた紹介文から引用しています。」