【書評】「IT専門調停委員」が教える モメないプロジェクト管理77の鉄則

日本実業出版社の今野様より献本御礼。

「IT専門調停委員」が教える モメないプロジェクト管理77の鉄則

なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術に続く、細川氏の第２作。前作ではITシステム開発の難しさを題材に網羅的にユーザーやベンダーがプロジェクト運営で失敗してしまうポイントを挙げられておりました。いわば、入門編という位置づけですね。本作では実際にプロジェクト運営でモメてしまう所も判例を通じて論じており、いわば「実践編」という立ち位置になっています。モメてしまうポイントを先回りして、フェーズ毎にヘルスチェックをして頂いております。

本書は女性弁護士キャラは出てきません。悪しからず。

システム開発は複雑系の極み

本書ではITプロジェクト運営を成功裏に導くために、77個の鉄則(チェックポイント)を掲げてこのチェックポイントをうまく抑えておかないと水が漏れるように浸水する可能性があるぞ、という警鐘を鳴らしています。

・・・77個もあるのか、というのが僕の正直な気持ちです。請負でこのリスクを背負うベンダーはよく商売ができるなと。ディフェンシブになるのが当然。転ばぬ先の杖を提供するのがプロの仕事だから当然のことだよ。転べば転ぶほど金も時間も喰っちゃう。

MosCow分析を徹底する

僕が自社の業務システムを運営している中で感じるのが、どの課題も等しく同じ重要だと考えがちな人がとても多いこと。これでは課題管理にならない。課題管理表を回覧板にしないために、WBSの粒度(更にはタスクを定義)を決めるために最も重要なのが、本書の132pで触れられているMosCow分析だと感じました。

Must	その要件が実現されなければ、システムやサービスの導入目的が果たせないもの
Should	その要件が実現されなうても、システムやサービスの導入目的が果たせるが、メリットが大きく損なわれるもの
Could	その要件が実現されなくても、システムやサービスの導入目的が果たせるしメリットもあるけれども、実現すれば更に大きなメリットを享受できるもの
Would	現時点で議論する必要がないもの。実現の要否判断をしたところで、導入目的にもメリットにも寄与しないもの

この区分けができていれば、課題を構造的に管理できるし、どの課題を潰せば他に影響が出るのかも議論しやすいと思う。

他人に仕事を任せることに不安な方にもおすすめ

本書は最も複雑なIT系のシステム開発プロジェクトを題材にしてモメないようにヘルスチェックが出来ますので、細かく厳密に状況を俯瞰できます。本書に挙げられた基準を元に他社様に依頼した作業の管理手法を見なおせば、ご自身のお仕事の管理効率UPにも繋がります。部下を持った、パートナーと共に働く。そういったことに、ちょっとでも不安を感じた方は一読をおすすめします。

ここから本書と関係ない話

モメないプロジェクト運営をする最適な方法を教えます

非常に簡単な事です。開発をベンダーに依頼しないで自社で開発することです。これで全てのリスクは自社内だけ。僕は本気でそう思っている。日本の会社の99%は中小企業だし、中小企業が日常的に使うシステムを作るインフラは有り余っている。弊社内製システムはVPSで動かしているので、モメるのは物理的障害(プリンタ接続)ぐらいしかない・・・。中小企業のトランザクションなど年間で１万レコードあるかどうかだし。パフォーマンスの問題などまず出ない。

オーダーしたことでコントロール出来ないなら、オーダーしてはいけない。自分でExcel/Access/各種PaaSで自作すればいい。もしくはASP/SaaSを借りたっていい。いわば、自習。Access使って簡易的システムを構築する本など巷にあふれている。これがWebベースでかつインターネット上に構築して売上を取るようなサービスになると話は別だけど、事務作業の代替手段なら自習しよう。お兄さんとの約束だ。

言い方悪いけど、素人だから生兵法は怪我の元でプロに依頼して、プロに対する仕事の依頼方法がわからずに爆死すること程、愚かしいことはない。

ソフトウェアは完全にコモディティ化しており、制作するだけならいくらでも手段がある。何百万もかける予算があるなら自習期間にお金をかけたほうが、後々IT戦略を立てる時に地に足の着いたものになります。