会社のITはエンジニアに任せるな！をエンジニアが読んでみた

インフルエンザに罹ってしまった。予防接種はしていたけど、やはりそれでも罹ることがあるのを身をもって実感。しかし予防接種受けてれば熱もそんなに上がらないと聞いていたが普通につらかったんですけど。。薬のおかげで熱はすぐに下がりベッドの上にいるのが暇だと感じる余裕が出てきたため、普段おろそかになってしまっている読書をすることに。こんなときにベッドの上にいながらネットで本が買えるというのは非常にありがたい。選んだ本はこちら。

会社のITはエンジニアに任せるな! ―――成功率95.6%のコンサルタントがIT嫌いの社長に教えていること

自分はIT機器メーカーのプリセールスSEという立場のためIT部門の方と会話することがほとんどだが、提案にあたっては当然経営部門や現場の方にとってのメリットを考える必要があるし、直接会話する機会もある。この本は商品説明を読んだ限りではITエンジニアでない人に向けてITとどう付き合っていくかを指南するような内容だと理解したので、これを読むことで経営や現場の方の気持ちが少しでもわかるのではないかと思った。

まず率直な読後感としては非常に気持ちがよかった。自分がITエンジニアとしていつも説明や説得に苦労する「ITの重要さ、難しさ、コスト」を明快に代弁してくれているからである。これについて引用したい部分は山ほどあるが、一つ選ぶなら次の文章になる。

この本の初めてで「ITを丸投げするな」と書きました。これをもう少し具体的に書くと「正解のない、数字で表せないような判断を現場に押し付けるな」ということになります。

この本で主にフォーカスしているのは会社の業務と密接に関わるシステムで、これを石油プラントに例えて「プラント型IT」と呼んでいる。プラント型ITは簡単に取り換えができる「ツール」ではなく会社の業務プロセスを実装し、社員の働きを決め、競争力の源泉となる重要かつ複雑なシステムとしている。そのため、基本的には自社で作らなければならないし、IT部門に丸投げするのではなく経営と業務部門も積極的に関わる必要がある。(一方で、メールやプリンタなどは「ツール型IT」と呼んでいる。自分が普段提案しているのはこちらの製品のほうが実は多いかも。。)

個人的に目から鱗だったのは、ITプロジェクトの成功率は30%程度のため、プロジェクトに臨む意識としては、「普通にやれば失敗するものであるものをなんとか成功させる」ということが必要であるという点。仕事柄あまりがっつりしたプロジェクトに直接は関わらないのだが、この意識をプロジェクトリーダーの人が持っていれば想定外のことが起きても冷静な対処ができるのではないかと思った。本の中では具体的な方法として、「オープンなコミュニケーション」、「曖昧さを排除したコミュニケーション」「衝突を恐れないこと」を挙げている。また、当初の予定からぶれがちなIT予算。これもプロジェクトは不確実なものであるという前提のもと段階的に予算承認・意思決定をしていくやり方は合理的だと感じた。

それから、ITプロジェクトを成功に導く上で非常に重要なのが経営・業務部門・ITの間に立ってプロジェクトをリードするプロジェクトリーダー。(いわゆるITベンダーのPMではない)このプロジェクトリーダーが何人社内にいるかで、その会社のITのスピードが決まる。つまり、プロジェクトリーダーの数がボトルネックになる。ただし、プロジェクトリーダーは素質＋経験が必要となり普通には育たない。そのため、会社によっては専門の部署をつくったり、優秀な人材を海外のIT部門長にさせたりしているとのこと。

ITビジョンの具体例ついても参考になった。2つ具体例が出ていたが、いずれも短い言葉ながら意思決定の拠り所となるシンプルな言葉となっていた。自分も提案する側としてお客様と一緒にそんなビジョンが作りたい。難しいんだけど。

ITビジョンの作り方と合わせて、IT部門の立ち位置もいくつかパターン分けがされている。自分のお客様は基本的にその中では「IT構築は外部に任せ、IT部門はPLに専念」と「ITはアウトソースする」の2つかその中間に分類される。その結果だと思うが、IT部門の人のIT知識・スキルがさすがに低すぎるんではないかと感じることがよくある。自分たちにその意識があればまだマシで、中には「自分は初心者ですから」とか「技術力がないんで」という枕詞をつけて無茶ぶりや本質的でない興味本位な質問をしてきたりする。それに対峙する自分としては単純にめんどくさいから困るという個人的感情はあるが、会社にとってみればそれが結果としてITについての意思決定のスピードや、正しい意思決定の妨げとなってしまうのではないかと思う。本にもITをアウトソースする割合が高いと、IT部門は「IT購買部門」に近い存在になると書いてあり納得。

そして最後に自分の仕事に役立てそうだと思ったのが、ROIについての考え方。お客様からはもちろん社内からも提案にはROIを示せ、とよく言われる。でも難しいことのほうが多い。ROIでなくてもお客様に提案を受け入れてもらう合理的な理由を示せればいいんだけど、それが思いつけなかった。この本に書いてあった例はシステムの更改という売り上げに直結しないプロジェクトにおいて、どうやって投資の判断をしてもらうかという話。システムを更改せずに使い続ける場合のコストと今更改した場合のコストを長期的に比較した結果、システム更改の判断となったとのこと。提案の一つのストーリーとして使えそうである。ちなみに、ROIの話の中で、「効果が数値で示せるならば、社長が判断する必要はないだろう」とおっしゃるCIOの方の言葉には激しく同意。ROIは必要な考え方だけど、そればかり要求してくるのは思考停止なんではと思っていました。

また、つぎはぎだらけのシステムを熱海の旅館に例えており、これもITエンジニアとしては実感がある内容。業務プロセスの足かせとなるだけでなく、「遅い、不安定、変えられない、高い」という困った状況になる。根本解決には抜本的なシステム再構築が必要だが、仮に再構築を決断したとしてもどういうITがほしいのか誰もわからないという事態が発生する。これの解決策の一例として、一定のサイクルでITシステムの再構築を強制的に行う方法が紹介されていた。それにより業務プロセスを棚卸し、最新テクノロジーを適用したものに作り変える。たいていは運用コストも下がるし、古い技術のサポートが受けられなくなる事態も防げる。また、再構築プロジェクトによりそれに関わる人も成長できる。ITベンダーの目線から一つ付け加えると、お金を使ってくれるお客様には優秀な担当がアサインされるので、その点もメリットになるのではないでしょうか。

結びとして、「あらかじめ決められたQCDを守る」ことよりも、経営目線で成功と言えるのがITプロジェクトとしての成功である、ということで本書は締めくくられている。この本に書かれてあることを多くの人が実践してくれたら経営、業務部門、IT部門のみんながもう少し幸せになれるんではないかと思う。ITエンジニアとしても「ITがなぜ大事か」を整理できたので勉強になる内容であった。

しかし初めてまじめに感想文を書いてみたが半日かかったぞ。インフルのおかげで仕事・家事・育児を免除されてる故にできたけど、普段からここまでやるのは難しいな。ただアウトプットなき読書は効果が低いから精度が低くても書いたほうがいいんだろうな。書くぞー。