モメごとになる前に、モメごと本を読んでおこう。

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

 　献本頂きました。なぜシステム開発は必ずモメるのか(以下、モメごと本と記す)。実は馴染みがある本です。というのも、「リーン開発の現場」を探して書店を回っていたとき、結構な頻度で隣に配置してもらっていたためです。

 　さて、こちらの書籍、書き手はIT訴訟の調停委員をされていた方ということで、法的観点からソフトウェア開発のさまざまな問題やリスクを評価、対策を解説する内容になっています。当然ながら法的な解釈については説得力があり、だいたいにおいて「まぁ、そういう判断になるんやろうなぁ」という妥当感があります。

　モメごと本の中で主人公がたびたび口にするように、法的判断といっても杓子定規なものではなく、意外と要件定義書とか設計書とか開発のためのドキュメントが判断材料になったり、「ふつう考えたらそらそうでしょ」な観点も盛り込まれることに気づきます。後者は例えば、ITベンダーは開発のプロなのだから、プロとして発注側に開発上のアドバイスを怠ったりすると、その責任を問われることがある、など。善管注意義務というやつですね。 

　構成は、7章からなり、要件定義、外部設計、内部設計、プログラミング・単体テスト、統合テスト、システムテスト、受入テストと章がふられています。下敷きにしている開発のコンテキストは、この章立ての字面の印象から受け取れるとおりです。また、システム開発の受発注を想定しています。なので、サービス開発を内製でしてきております、という方にはちょっと想像し難い設定かもしれません。

　では、ウォーターフォールや受発注型の開発でしか得るところが無いのかというと、そうでもありません。システム作りを頼む側と頼まれる側という文脈に立って、この本を読むと、様々な発見があるはずです。頼む側も頼まれる側も、双方がどのような期待を持っていて、何を考え、どんな姿勢で開発に臨む可能性があるのか推し量ることができます。それは、開発のリスク察知の上で参考になります。各章末にチェックリストがついていて、自分の経験が不足している局面についての良い補完になると思います。また、メインターゲットとなる受発注型の開発をされている方(で、まだプロジェクトの経験が浅い方)はとにかく一度目を通してみると良いかと思います。「え、この解釈ちょっと厳しくない？」と思えるものがあったら襟を正すには良い機会かもしれません(私もいくつかありました)。

　なお、文体というか書き方が人物の会話形式になっていて、こういう形式の開発関連本って最近見なくなったなーと同時に、たくさん字を追うのが苦手な方には読みやすいかもしれないと思いました。内容はみかけの文体ほど軽くはないので、自分だったらどうするという解釈を入れながら読み進められると良いのではないかと思います。