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

読書メモ。他人の不幸は蜜の味と言われるが、他人の失敗はノウハウの塊だと思っている。というわけで、ソフトウェア開発の失敗の極みである「IT紛争」に関する本「なぜシステム開発は必ずモメるのか？」を読んだ感想。この本も、ノウハウの塊になっていると思う。

• 過去に書いた「失敗」に関する関連記事
  • 成功事例には興味がない - 勘と経験と読経
  • 上流工程の失敗カタログ - 勘と経験と読経

本書については著者ブログのこの記載がズバリ内容を言い表していると思う。

ベンダだけではなく、ユーザに対しても行われる様々なアドバイスは、単なるテクニック論だけではなく、ITの導入・開発に必要なメンタリティや責任分担にも及び、付録として付けた解説やチェックリスト等を合わせて読んでいくことにより、おそらく2日でIT開発プロジェクトのエッセンスが学べる内容となっています。
有栖川塔子弁護士が語る"開発におけるベンダとユーザの責任"：IT紛争のあれこれ：ITmedia オルタナティブ・ブログ

なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術

メンタルへのダメージが・・・

さて、本書は東京地裁のIT調停委員をされている著者が、事例と判例を使って、いわゆるオーダーメードのシステム開発や、企業向けのパッケージ導入などでトラブルになるポイントを説明している体裁となっている（ゆえに、サービス開発やパッケージ開発など顧客と受発注の関係が無いソフトウェア開発には参考にならないと思う）。

で、とても良い本なのだけれども、何故かドラマ仕立てになっており、登場人物の会話が刺さってくるので注意である。主人公である美人弁護士が例えば以下のようなセリフで読者のメンタルを攻撃してくるのが、正直辛い。ある種「なれる!SE 2週間でわかる?SE入門 (電撃文庫)」に近いものを感じる。

「以前IT紛争の調停をやったエンジニアとその手の話をしたことがあるけど、やっぱりベンダの技術者が不勉強で無責任だって。”要件はお客さんの責任”って風潮が最近は強すぎるんじゃないかって」

うっっ

「安いが一番ってユーザとは、付き合いを考えたほうが良いって前にも言ったわよね？　ビルを建ててもらう施主は作業員の安全のために貼る防護ネットの費用をケチらないし、船で物の輸送を頼む人は船舶保険代をケチらないわ。具体的な成果物が見えなくても、必要なものは必要なのよ」

わかってるんだけど、、、

失敗に学ぶ重要性

過去のエントリでも何度か書いているのだけれども、皆もっと失敗事例に目を向けるべきだと考えている。

• 自分が現役のうちに参加できるソフトウェア開発プロジェクトの数なんて、たかが知れている
• 自分の経験したプロジェクトからしか、学ばないのは効率が悪い
• 失敗は成功の母だと言われるが、自分の参加するプロジェクトでは失敗したくない
• 成功は模倣できないけれども、失敗は回避できる

たしかに以前は、ほかの人の成功事例をマネすることが、成功への近道だった時代がありました。そうした時代には、決められた設問に正確な解を素早く出す学習法が有効だったのは事実です。
しかし、ほかの人の成功事例をマネすることが、必ずしも自分の成功を約束するものではなくなったのがいまの時代です。昨日までの成功は、今日の成功を意味しません。そのような時代に大切なのは、やはり創造力です。そして創造力とは新しいものをつくりだす力を意味している以上、失敗を避けて培えるものではありません。
創造力を身につける上でまず第一に必要なのは、決められた課題に解を出すことではなく、自分で課題を設定する能力です。あたえられた課題の答えのみを最短の道のりで出していく、いまの日本人が慣れ親しんでいる学習法では、少なくともいまの時代に求められている真の創造力を身につけることはできません。
失敗学のすすめ (講談社文庫)

失敗学のすすめ (講談社文庫)