みなさん、こんにちは！
タカハシ(@ntakahashi0505)です。
会社のITはエンジニアに任せるな! ―――成功率95.6%のコンサルタントがIT嫌いの社長に教えていることという本を読みました。
タイトル名が良いですよね。
完全に「同感！」と思いまして本書を手に取りました。
ITプロジェクトは色々な意味で失敗しているケースが多いです。
本書は、なぜITプロジェクトで失敗が多いのか、また失敗をしないようにするためにはどうしたらよいのかを、ITが苦手な経営者、業務担当者でもわかるように解説してくれています。
ですが、内容的にはちょっと大きめの会社向けかなーと思う印象がありました。
ということで、今回の記事ではもっと小さな企業（例えば1～100人くらいの規模）を想定して、ITプロジェクトを失敗させない方法について、本書の力も借りながらお伝えできればと思います。
ITプロジェクトの成功率はとっても低い
本書でも書かれているのですが、ITプロジェクトの成功率はとても低いようです。
2003年と2008年なので少し前の調査ですが、こちらの記事でレポートされています。
調査結果によると
1回目の調査で、コスト、納期、品質の全てで問題がない成功プロジェクトは全体の26.7％に過ぎなかった。2度目の調査では少し改善したものの成功率は31.1％に過ぎない。システム開発の難しさを改めて浮き彫りにした。
とあります。
低！
成功率わずかに3割程度…。じゃんけんで勝つ確率のほうが高いです。
これでは経営者としてはITに投資する気が失せてしまいますよね。
ITプロジェクトの成功・失敗とは何か？
そもそもITプロジェクトの成功とか失敗とかって何なのか？って話ですよね。
上記の調査でいうと、その定義は
「Q（Quality）、C（Cost）、D（Delivery）」、すなわちシステムの「品質」「コスト」「納期」の3点について当初の計画を順守できたかどうか
としているようです。
このQCDによる評価は一般的によく使われるのですが、私はITプロジェクトの成功か否かを測る指標としてQCDを使うのは実際どうかなーと思っています。
というのも、ITプロジェクトの失敗のカタチって本当に色々あるんですよ…。
ITシステムのヌシが誕生する
本書では長年をかけて増改築を繰り返したITシステムを「熱海の旅館」と例えています。
あまりにも例えがうますぎるので笑っちゃいます。
ですが、そのITを使わなくてはいけない当の本人たちにとっては悲惨です。
熱海の旅館化というのは、その都度の改築で行き当たりばったりに機能を追加したり、仕様変更を加えていくことで、
- ITシステムのユーザーが守らなくてはいけない制約や手順がどんどん増えていったり
- 構造が複雑化してメンテナンスの難易度が上がる、システムが重くなる
などの状態を言います。
業務の現場を見ると、結果として、そのシステムを使いこなすための高い専門スキルが求められるようになってしまいます。
残念ながらそのスキルは一歩外に出たらほとんど役に立たないのですが…しかし、その方がいないと業務が回らないので、ものすごい発言力を持つようになります。
このようにして「ヌシ」が誕生するわけです。
以降、ITシステムにつぎはぎを繰り返すとさらに複雑な操作や知識が求められ、その方はさらにその業務から離れられなくなる…といったスパイラルから抜けられなくなってしまうのです。
このような状況を打破すべく、システムの作り直しを検討したくても
経営や業務部門から見ると、特に機能がアップするわけではない。だから投資額に応じた効果を示せず、社長は決してYESと言ってくれない。
という非常に悩ましい状況になりがちです。
ITシステムの奴隷が誕生する
別のパターンとして、ITシステムの奴隷になってしまうパターンがあります。
ITシステムを使うのではなくて、ITシステムに使われてしまうってやつです。
ビジネス上重要な判断基準やチェックすべきこと、計算式などの「ビジネスロジック」もすべてITに埋め込まれているから、理解していません。
（中略）
こうして「この会社を動かしている一番重要なロジックは、ITというブラックボックスの中にだけある」というSFのような事態は、いまでは普通に起きています。
将来、コンピュータが人間に単純労働を強いるような話は映画などの架空の話のように思えるかもしれませんが、実際に近いことは起きているということです。
しかしこの場合、業務担当者としては残念ながら失格です。
どのようにビジネスを発展させていくか、そしてそれを実現するためにITシステムにどう変更を加えたらよいのかという判断はまず難しいからです。
身の丈に合うITの導入
このようにITプロジェクトはとても成功が難しいです。
QCDがうまくいったとしても、前述のように運用フェイズですっかり価値を失ったり、ビジネスの重荷になってしまったり…本当によく見かけます。
そうならないように、どうすれば良いでしょうか？
それは、身の丈に合ったITを導入するということです。
つまり、自分たちの手で確実にコントロールができるものを、確実にコントロールできるように導入するということです。
当たり前のことなんですけどね、なぜかITプロジェクトだと見失ってしまいます。
「できる」スタッフが複数人いる
身の丈にもいくつかパターンがあります。
一つは事業メンバーがちゃんとITシステムをコントロールする体制を整えるということです。
- そのビジネスに精通しており
- 導入しようとしているITシステムをメンテナンスできる
- スタッフが複数人いる
のであればそのITプロジェクトに関しては問題ないといえます。
複数人いるので、一人に何かがあっても乗り切ることが可能です。
エクセルVBAでチーム規模のシステムを作るのであれば、既存メンバーを数カ月から半年くらい教育すればそのような体制は作れます。
WebサイトであればWordPressで構築します。あれこれ高望みをしなければ、ブログ運営をしたことがある程度のスキルがある人が二人以上いれば運用はなんとかなります。
…というように、高価で複雑で多機能なシステムを一気に導入せずとも、小さくて細かくて身近なところから手を打つことはできますので、まずはそこから始めるというのも手ということです。
社内にIT部門があるから、技術的な対応はそこにお任せ！という方針は、私はあまりオススメしていません。
IT部門担当者がビジネスを理解するよりも、業務担当者がITを身に着けるほうが、会社にとっても業務担当者本人にとってもメリットが限りなく大きいからです。
システムに完全に依存する
もう一つはシステムに完全に依存してしまい、業務をそちらに合わせていくという方法です。
クラウドサービスであれば、不特定多数の企業が同じサービスを利用しますから
- コストが安い
- 情報が豊富に存在する
- 不具合やバージョンアップが期待できる
などのメリットがあります。このメリットを享受できるのであれば、業務を合わせていくという手間には目をつぶれるという作戦です。
ただ自社の大事な強みになっているところをスポイルしないように気を付けなくてはいけませんね。
まとめ
ITプロジェクトに関しては、エンジニアに丸っと任せるのではなくて、業務担当者にできるところから任せていくというのがオススメです。
そして中長期的に見たら、社内のITスキルを全体で少しずつ底上げしていくという道筋が描けるととても良いですよね。
だって優秀なエンジニアを最初から採用したいと思ったらホント大変ですから。
あと本書では「熱海の旅館をどうするか？」という問いに対して、「伊勢神宮」という解が示されていました。
これも例えとしてはとても絶妙なのですが、ぜひ興味を持たれた方は読んでみて下さい。
