私の現場でもベンダへ外注を行っており、いろいろ悩みがあったので、その答えやヒントがあれば良いなぁと思い手に取りました。
本書はITシステムを想定したもので、組み込み開発とは少し毛色が異なっておりましたが、学べる点は多々ありました。特に、発注側がベンダをうまくコントロール*1できなければいけないということを痛感しました。現場でも度々感じることではありますが。油断すると、ベンダ側だけの論理でものが進んでいきます。そして、最終的に損害が発生した場合、補償は発注者側が負うことになります。ここが最大の学びでした。状況に依る部分もあるのでしょうが、最後に困るのは発注側であることを肝に銘じます。
そうした中で、いかに信頼関係を築くか、ということが命題と考えます。それは、すべきことやリスクなどを明確に共有できていたり、定期的なコミュニケーションがとれていたりと、いろいろな行動の積み重ねによってもたらされるものだと思います。最悪ケースは裁判沙汰であっても、そうそう裁判沙汰が起きるものでも無いような気もしています。
さて、本書を読むと発注者側ばかりが被害を被りやすそうに感じますが、下記の記載もありました。
ITエンジニアは他業界と比べて精神疾患にかかる率がはるかに高く激務であることが多い(page242)
つまり、ITベンダで働いている個人が最大の被害者だと考えます。発注者側がベンダをコントロールせず、その中でベンダが奮闘し使い潰されるという。。。こういった状況からも発注者側がシステムに対する要求を明確にして、順調な開発ができるようにしていくなければならないと考えます。裁判でベンダへ補償がされたとしても、それはベンダ会社に対してであり、個人に対してではないですし。
また、本書では各章ごとにシステム外注における、種々問題を取り上げその解決策案を提示してくれています。しかし、それはあくまで案であって、すぐに現場に適用できるようなものではないと思います。例えばWBS*2がプロジェクト進捗管理手法として基本はOKみたいに書かれています。しかし、そもそもWBSで十分に管理できるかといったら、そんなことは無いように感じています。WBSの作業単位であるWP*3の設定方法ってかなり難しいような気がしています。このように感じる部分が散見されました。本質はそこではないと言われるような気もしますが、、、もやもやです。
総括としては、タイトル通りです。システムを「外注」するときに読むことで、抑えるべき注意点を概観することができます。最終的な対応策はそれぞれの現場で考える必要がありますが、羅針盤として本書はとても有用だと思います。外注に悩みを抱いた上で本書に出会えて私は良かったです。
以下、本書で良いなと思ったセンテンスの抜粋です。
- 業務フロー図を書くからこそ、今の業務の問題点が明らかになって何を改善するべきかわかる。(page39)
- 発注者側に責任があってプロジェクトが中断した場合は、たとえ仕事が完成していなくても、ベンダは作業をした分の請求ができる(page107)
- プロジェクトにどっぷり浸かった人間は、いろいろなことに鈍感になるもの。落ち着いて考えればすぐに気が付きそうな問題を見逃してしまう。(page155)
- ベンダが何の提案も見積もりも出さずに、結果プロジェクトが失敗した場合、損害賠償の対象になる。(page162)
- 相手に時間がないなら作らせればいい。技術用語がわからないなら勉強させればいい。それをしないのはプロジェクトオーナーである社長の意向に背くことだって言えるくらいの強い気持ちと押しの強さがなきゃ、発注者企業のシステム担当者なんて務まらない。(page222)
- 早く作業を進めたいと考えるベンダのペースに乗ることなく、言うべきことは言って、待たせるべきものは待ってもらなわなければなりません。(page275)
- 発注者が「何かをしてやった」と思えるのは責任のある行動をとっているから(page306)
- 要件定義の段階が重要なのは、発注者とベンダの間でそういう信頼関係を築く時期でもあるから(page308)
