Entries

細川義洋『なぜ、システム開発は必ずモメるのか?』

なぜ、システム開発は必ずモメるのか?  49のトラブルから学ぶプロジェクト管理術なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術
(2013/09/27)
細川 義洋

商品詳細を見る

良書。ITプロジェクトでトラブルとなる場面と、それを防ぐために何に注意して何をしなければならないかについて。それを49のトピックに分けて、トピックごとに小説仕立てで書いている。とても読みやすい。トピックごとに4ページほどで書かれている。やや話題がばらばらになっている印象も受ける。

この本がユニークなのは、東京地方裁判所でIT事件を担当する民事調停委員が書いていること。ITプロジェクトがもっともトラブルになって、ユーザとベンダの間で訴訟になった時、その調停を行う人。裁判での判決や、調停の結果を踏まえつつ、ユーザの責任とベンダの責任について書いている。プロジェクトの単なる失敗集というよりも、裁判という場面での経験に基づいていて、類書にはない視点を持っている。ベンダの責務といっても、契約書に記されたものを納品して、検収されればOKなわけではない。たとえユーザの検収をもらっていても、ベンダに責任があるとされる判例もある。機能としては問題ないが、データベース構造が複雑すぎて保守に工数がかかりすぎるシステムの場合など(p.130-133)。こうした裁判の様子はつぶさに語られるものでもないから、なかなか貴重な記述だろう。裁判所の判断も杓子定規ではなく、かなり現実的になされていることは何度も強調されている。

IT紛争はユーザとベンダの相互の責任やタスクについての認識相違によるものが多い(p.56)。またほとんどは相互の信頼関係が損なわれているからこそ、裁判となる(p.258)。いかにベンダ側が不利な、無理のあるプロジェクトであっても、ユーザときちんと信頼関係を築き、率直に話せる関係があればそれだけで訴訟という最悪のケースは回避できる。例えばベンダもよく知らないパッケージを導入する場合に、パッケージ開発会社の研修の受講や問い合わせ窓口の確保など、メンバーのスキルアップ計画をプロジェクト計画とともに立案してユーザに提出したケースなど(p.34-37)。また、システム開発の目的と方針をきちんと区別して、要件は方針に紐付けること(p.64f)というポイントが刺さった。この二つは相対的でもあるだろう(方針を達成するための方針を考える場合は、元の方針は目的となる)けれども、あまりきちんと区別したことがなかった。

プロジェクトオーナーの役割・責務について的確に書かれているのも印象的(p.208-215)。進捗を把握して追加コストの判断をすること、予備費や後工程での手戻りのための費用を用意しておくこと。プロジェクト管理はだいたい全体費用の10%を確保すべき。要件の再調査費用としても10%ほどを確保すべき。特にプロジェクト管理費用は税金のようなもので、値引き交渉の対象とすべきなど様々に参考になった。

リスク管理こそプロジェクト管理のなかでもっとも重要なものという認識に同意(p.75)。また、もっとも難しいものでもある。本書は基本的にユーザとベンダという2者の登場人物を想定して書いている。したがって請負契約を念頭に置くのがメインになっているのだろう。法律論として準委任の場合とどういった違いがあるのかについても書かれているとよかった。
スポンサーサイト
この記事にトラックバックする(FC2ブログユーザー)
http://exphenomenologist.blog100.fc2.com/tb.php/716-9217e744

トラックバック

コメント

コメントの投稿

コメントの投稿
管理者にだけ表示を許可する