著者：ボストンコンサルティンググループ
| IT・デジタル投資で、様々な業界の様々な企業が取り組みに失敗している。それは日本だけではないが、日本に多いのも事実である。
日本企業や日本の人々は、真面目に、規律正しく、品質にこだわり、決められた役割だけに縛られず人のためにも動く。このような文化を持っているのに、なぜ無駄なことをやってしまうのか。なぜすれ違っていくのか。なぜ生産性が低くなってしまうのか。
経営としてIT・デジタルを活用していくための心構えから、最適な投資についての考え方を、日本企業は早急に学ぶべきである。単なる正論や進め方を学ぶだけでは十分ではない。先人が失敗した内容、失敗の理由、失敗を回避するにはどうすべきなのかを理解し、投資の最適化を進めるべきである。つまり、失敗を学び失敗を減らす、ということだ。
IT・デジタル投資に関して業務効率・コスト効率のみを求めるがゆえの悪循環が起こっている。低いレベルでの均衡を脱却し、すべての企業がIT・デジタルを自社内で自在に扱えるようにする「手の内化」を実現し、ビジネスの成長につなげられることを願っている。
（「はじめに」より一部抜粋）
＜目次＞
第1章 なぜ日本企業はIT投資で失敗するのか
●日本企業が置かれている状況と直面している課題
〝守り〟のために事業側企業のIT投資の増加が続く／業界・企業により異なるIT投資、レガシーシステム脱却状況／レガシーに依存する小売業／先進的な大手チェーンが躍進する飲食業／IT投資とレガシー依存の金融・保険業／地方のデジタル化が遅れている電気・ガス／「翻訳力」が不足している製造業／デジタル化が進まない不動産業／デジタル化が遠い農業・林業、漁業／メインフレームの登場から現在に至るまでのテクノロジーの進化／クラウドからデジタルへ／システム導入に関する海外との思想の違いとその影響／日本・海外におけるIT人材の位置づけと人材マーケットの違い
●レガシーシステムからの脱却
日本企業に警鐘を鳴らしていた「2025年の崖」とは／「攻め」のITへ向かうのか／DXになかなか成功できない日本企業／経営層のIT・デジタル領域における専門性の低さ／IT部門の人材不足／事業側企業における課題のまとめ
●ベンダー企業が置かれている状況と直面している課題
IT業界の構造の変化と事業側企業との関係性／事業側の人材不足がベンダー依存を深刻化／ベンダー企業における人材不足の実態／ベンダー企業における課題のまとめ
●政府・官公庁の動き
政府のIT投資適正化・レガシーシステム脱却への取り組み／日本企業が抱える構造課題の解決に向けて
第2章 ＩＴ・デジタルプロジェクト成功に向けての準備
●基礎を知るということ
IT・デジタルリテラシーの基礎力／現実を理解する（1） テクノロジーの進化／現実を理解する（2） 社内のIT・デジタル経験／現実を理解する（3） ITベンダーの変化／現実を理解する（4） 企業のIT部門の人材問題
●経営者のマインド改革
IT・デジタル投資を成功に導く4つのマインド／日本企業特有の3つのポイント／最も重要な「向かう気力」と「認める勇気」
●組織構造の改革
あるべき組織構造とは／改革（1）システム部門の改革は急がば回れ／改革（2）CIO・CDOの任命は、強い意思を持ってやるべき／改革（3）CHROの寄り添いが必須
第3章 プロジェクトの各フェーズでやるべきこと
●3ステップと陥りがちな罠
大型案件ではウォーターフォール型開発を／3つのフェーズの罠
●システム開発特有の事情
システム開発ならではの特徴／共通イメージを持ちにくい／用語が統一されていない／目的設定や費用対効果が曖昧になりやすい／責任分界点がわかりづらい
コラム 状況悪化の元凶のひとつはコンサルティング支援にある？
●企画構想フェーズで押さえるべきポイント
企画構想フェーズの罠を回避する／目的と手段をはき違えない／あれもこれもと盛り込まない、目的や効果を後付けしない／スコープをしっかりと定める／対象外の領域への影響を見極める／事業側の合意を得る
コラム グローバル企業だからシステムの統合や標準化が必須というのは誤解？
●企画構想フェーズに求められるマインド
IT案件を特別扱いしない／当事者特有のバイアスを念頭に置く／ベンダーの計画をうのみにせず、自社のIT主権を取り戻す
●要件定義フェーズで押さえるべきポイント
要件定義フェーズの罠を回避する／企画構想で定めた方針を変えない／適切な粒度で要件を定義し、やりきってから次へ進む／事業部門がサインオフする／現状を是とせず、To Beを考える／実装フェーズの計画（テスト・移行など）の大きな方針を定める／データのポリシーやデータ構造を定める
●要件定義フェーズに求められるマインド
ベンダーに丸投げしない／投資対効果を意識する
●実装フェーズで押さえるべきポイント
実装フェーズの罠を回避する／自社としてベンダーの仕事を評価する基準を持つ／安易に雁行せず、しっかりと立ち止まる／ベンダーの前提や見積もりを自社として検証する
●実装フェーズに求められるマインド
自社としての算段を持つ／空気感に流されないようにする
第4章 失敗から学び 失敗を活用する
●IT投資の見えない失敗
失敗の種類／進行中のプロジェクトにおける失敗対策／軌道修正の検証ポイント（1）目的や効果は明確か、当初掲げたものから逸脱していないか／軌道修正の検証ポイント（2）中身（品質、コスト、進捗）に問題はないか／軌道修正の検証ポイント（3）プロジェクトが適切に運営・管理されているか
コラム 頓挫しがちなのはシステム開発プロジェクトだけなのか？
●「失敗」を繰り返さないためのIT・DX戦略
すべての日本企業が取り組むべきこと／IT・DX戦略の視点（1）戦略・ロードマップ：経営が関与すべき案件を特定する／IT・DX戦略の視点（2）ガバナンス・プロセス：経営レベルで注視する／IT・DX戦略の視点（3）組織・体制：自社にITの主権を取り戻す
第5章 日本企業が勝つためのアプローチ
●スタンダードプロセスからスタンダードデータへ
業界全体を変えていく／日本企業が遅れを取り戻すためには／基幹システムは「データを集めるもの」／守るべき基本から優先順位を考える／現場の忖度が余分なデータを増やす
●業界特性や企業規模特性に基づく対応
業界・規模別の効率化／共通システム活用の可能性／社会的基盤構築の目的
●IT・デジタル人材育成
何のためにデジタル人材を育てるのか／いま求められているのは成熟した技術の活用
●ITベンダー、企業、国が今後すべきこと
ITベンダーがすべき競争と協業／成熟した領域に求められるもの／まずは「通訳」的人材から
●地域での連携の可能性
人材育成の内製化／業界間連携の例／政府や自治体の人材育成 |
かなり勉強になります。しっかり読み込んでいきたい書です。
失敗の認識や状態にもよるが、システムがまったく使えないもの、動かないものになってしまうと手が付けられない。失敗のステータスを区別すると、
- システムとして完成していない
- システムとしては完成したが、業務として使えない
- 一部の業務としては使えるが、データとしてのつながりが成立していない
- 完成はしたが、本番稼働段階で問題が発生し、稼働停止となる
というパターンだ。（p.8） |
| 米国は1990年代後半のインターネット勃興でデータ連携の重要性を認知し、2000年代の基幹システム刷新において企業内データ統合を強く推し進め、2010年代には、経営、事業、機能の意思決定における必要情報の整理に集中し、経営と事業が過去の情報、統計に基づいて一定の意思決定、判断ができる状況を作り出してきた。そのため、未来のビジネスに向かうためのIT投資に目が向いているのである。（p.43） |
| ここから逆転するためには、米国企業が20年先行したものを学び、データをできる限りシンプルな形で整備し、未来のビジネス開発、商品開発、顧客開発に投資できる状況を作るべきである。そのためには、無駄なことはやっていられない。失敗している暇はない、という危機感が必要だ。（p.44） |
| 特にIT投資が後手となっている業界では、それが経営リスクにいずれ繋がるため、基幹システム刷新を計画すべきである。ただ、取り組むためには小手先の対応だけでは追いつかない状況も見えてきており、経営層を含めたマインド改革から実施していくことが重要だ。（p.49） |
IT・デジタルを活用して自社の成長につなげていくために、経営者に求められる重要なマインドがある。もちろん、業種や業態、規模などによって求められるレベルは異なってくるが、共通して言えるのは次の4つだ。（p.77）
- 常に事業ストーリーと連動させて考える
- 常に学び、常に関心を示す
- 任命が最重要、任命責任こそ経営責任
- 大胆な意思決定と細心の状況判断
|
この4つのマインドは、結構ハードルが高いと思います。その前に書かれていましたが、経営者もITをかなり分かっていてITと事業を結合して考えられる必要がありますよね。そういう意味でも右腕になるようなコンサルタントのニーズが高まってくるような気がします。コンサルタントも利益を考えるとおいしいところだけやっていくのがいいのでしょうけど、伴走して長期的な関係を繋いでいくというのが大事だと思います。
| 遅れをとってしまっている日本企業においては、役員ポジションでなくてもいいが、CIOの役職とCDOの役職を分けて、守りの専門が守り、攻めの専門が思い切り攻めていく形を取らない限り、グローバルの先陣には追い付けない。簡単なことではないことは重々承知だが、育成やビジネス側からの抜擢を含め、体制を作っていくことが重要である。（p.96） |
確かにCIOとCDOは質が違うと言えば違いますけど、ちょっと違和感は感じますね。急に外からCIOやCDOが来てあるべき論を語られても現場はついてこないというのもありますしね。個人的にはやっぱり社長なんじゃないかなと思います。社長が舵を切るべきなんだと思います。そのための右腕は社内にはいないとなると、伴走できるコンサルタントということになると考えます。
p.105～p.107にシステム開発を進める上での3つのフェーズの罠が書かれていて、これは押さえておくべきポイントだと思いました。
■企画構想フェーズの罠
- 何を成し遂げたいのかが分からず曖昧なまま投資の意思決定をしてしまう
- 経営層がプロジェクトの中身を理解しないまま、現場主導で進めている
- システムを利用する事業部門がコミットしないまま、IT部門が突っ走っている
- 目的を達成するための実現手段のめどを立てないまま要件定義に進む
- ベンダーの計画をうのみにし、自社として十分な検証をしていない
|
■要件定義フェーズの罠
- 細部の議論に終始し、大きな論点の意思決定が行われない
- 企画構想フェーズで定めた総論に対して、各論について反対の声が上がる
- スケジュール優先で、要件定義が曖昧なまま次のフェーズに進めてしまう
- 既存の業務のやり方を見直さずに、「現行踏襲」のまま要件を定義してしまう
- 新しいものをつくるからと「To Be（あるべき姿）」だけを定義し、「As Is（現状）」を十分に把握せずに要件を定義する
- 実装フェーズで必要になる作業（テスト・移行など）の計画策定を後回しにしてしまう
- 業務のプロセスや機能の使用ばかりに注力し、データを意識しない
|
■実装フェーズの罠
- 要件定義からの仕様変更の発生の見立てが甘い
- ベンダーの仕事を評価する基準がなく、ベンダーの報告を鵜呑みにする
- 計画が遅れ、安易にベースを雁行（前野フェースが完了していない段階で後のフェーズを同時並行で進めること）する
- メインベンダー以外の関係者（発注者、他のベンダー）が担う作業の見積もりが甘い
|
要件定義の「データを意識しない」というのはまさに日本の経営革新の遅れの最たるものなのではと思います。なかなかそのタイミングでしか取れないデータというのも多々あり、そのあたりはビジネスや顧客を理解したデータアナリストやデータサイエンティストが参画できるともう少しそこはフォローできると思うのですが、これまたそういう人材が要件フェーズから入るということ自体、日本の開発工程の中では、標準ではないと思うんですよね。そういう人材をそこに置いたうえで新しいシステム開発がでいるとバリューの高いシステムになると思います。
終盤に基幹システムは「データを集めるもの」とありました。まさにそうだと思います。そしてそのデータを活用する仕組みまでがあってのシステムだと思います。そういったシステム開発が標準になるようにならないと競争に勝てない。そこを支援できるように私自身も知見を蓄えていきたいと思っています。
