IBM i のウンチクを語ろう
～ その57：DXレポート2を読んでみた -1
皆さん、こんにちは。「DX（デジタルトランスフォーメーション）」という言葉が世間に認知されるきっかけとなったのは、今を去る事約2年半、平成30年9月7日付けで経済産業省から公開された「DXレポート」（以下、本編）ではないでしょうか。ITやビジネスの変革を語る際に度々引用される用語であり、今や目にしない・耳にしない日は無いと言っても過言ではありません。先日もぼんやりと朝のTVニュースを見ていたら、DXを推進した企業とそれを支援する金融機関が紹介されており、DXという言葉は日常に入り込みつつあるなという思いを強くしました。ところがこれだけ浸透すると、人それぞれの都合に合わせた我田引水的な用語解釈が入り乱れます。ともかく何らかの方法論でITを刷新しさえすればDX扱いされるようになると、旧来のモダナイゼーションと何ら代り映えがしません。その現状を憂いたのか、経産省は昨年末の12月28日に「DXレポート2（中間とりまとめ）」を続編として公開しています。今回のコラムでは、この続編が主張しているITのあるべき姿をざっくりと読み解いてみようと思います。
ちなみにレポート本文は50ページを超える分量がありますので、要領良く内容を把握するためには簡易版を先に読む事をお勧めします。さらに短いサマリーもありますが、まとまり過ぎていて最初に読んでも良くわかりませんでした。私は簡易版に目を通してポイントをある程度把握しながら本文の該当箇所を参照する、といった具合に簡易版と本文との間を往復しながら読み進めました。
そもそも何故続編を公開する必要があったのでしょう。本編レポートでは、ブラックボックス化したITを放置する事が原因で、2025年になると全国で毎年12兆円もの損失リスクがあると警鐘を鳴らしました。ところが対策を急がねばならないにも関わらず、90％以上もの企業では未だにDXに全く取り組めていないか散発的な取り組みに終わってしまっている、という危機感が背景にあります。日本人一人あたりの労働生産性は、OECD加盟36ヶ国中21位と低迷しているという統計値も意識しているかもしれません。DXとは何かという本編の主張が正しく世間に伝わっておらず、単なるIT刷新をもってDXとしていたり、既に競争優位にあるからDXは不要としたりする誤解も見られると続編では指摘しています。そして「レガシー企業文化」から脱却するべき、すなわち旧来の業務そのものや、組織、プロセス、企業文化・風土を変革するべきと強く主張しています。DXの対象はITに留まらず、企業文化にまで及んでいるという事です。さらにどのようにしてDXを推進しデジタル企業に変貌を遂げれば良いのか、そのシナリオを示すと共に、DXの重要な要素であるITのあるべき姿も描いています。ちなみに「デジタル企業」とはDXを推進できている企業、といったくらいの意味と考えれば良さそうです。
シナリオは3つのステップで構成されています。直ちに実施するべき超短期の実施項目は、DXの正しい理解と業務のデジタル化・オンライン化実践です。次の短期的事項はDXのための体制整備、戦略策定、進捗状況の把握を行えるようにする事です。DXを正しく理解するという点を除けば、ここまではごく一般的なプロジェクト推進と変わるところは無いように思います。仕上げの中長期的段階において、デジタルプラットフォームを形成してビジネス環境の変化への対応力を高め、それを支える人材確保の考え方もあわせて変革します。ちなみに業務効率改善やコスト削減のためのIT刷新は、DX実現に向けて踏み出された第一歩であり続きがあってしかるべき、という事になります。
「デジタルプラットフォーム」なるものがITのあるべき姿というわけですが、どのようにしてこれを形成すれば良いのでしょうか。
まず企業内の様々な業務が「協調領域」と「競争領域」のどちらに属するのかを識別します。協調領域とは自社の強みとの関係が薄い領域であり、ここに関わるIT投資はできるだけ抑制する事を狙います。自前主義を排し業務プロセスを標準化して、クラウド・サービスを活用したりパッケージ・ソフトウェアを導入したりします。場合によっては業界内他社と連携して、共通プラットフォームを形成する事も検討するべきとしています。例えば人事・給与・総務といった業務や、生産・販売の中でも法的規制に対応する業務など、企業による差が無い標準的な仕事は協調領域にあると言えるでしょう。これらについては既に自前主義を排している企業は多いのではないかと思います。ただその目的はコスト削減であり、そこで終わってしまっているケースが多いのも現実ではないでしょうか。DXの狙いはコスト削減ではありません。ここで生み出された投資余力を競争領域、例えば生産・販売といった自社の強みとする業務に振り向けて、内製化したシステムを活かしながら変化に迅速に対応できる体制を整えます。
さて、競争領域のためのシステム構築について、従来のように外部への委託を前提とした、要件定義からテスト実施までの各段階を順に踏むようないわゆるウォーターフォール型の開発プロジェクトでは、変革・迅速という要素を満たす事は極めて困難です。ここには4つの問題があるとされます。すなわち曖昧さ無く要件定義を行うのが困難であること、ソフトウェアの価値を測るのに人月単価と工数という妥当性が不透明な尺度を慣習的に用いていること、開発ベンダーによる成果物の価値が明らかになるまで時間がかかること、新機能を欲しい人と開発する人との間に距離があるために意思の疎通が困難であることです。前段階の作業が完璧である事を前提にしながら次の段階に進む、変化というものをあまり想定しない方法論だということなのでしょう。
これら問題を解決するために、続編ではアジャイルな開発体制を整備するよう提言しています。プロジェクト開始時点では厳密な仕様を定められない事を前提として、小さな単位で、計画・設計・実装・テストのサイクルを短期間で反復しながら、ソフトウェアの価値を最大化させます。プロジェクト進行中においても変化を取り入れることが可能になる方法論です。
プロジェクトに投入される要員数にも違いがあります。ウォーターフォール型では最初の要件定義やソフトウェア展開後のフォローの段階では少人数ですが、中間の開発段階においては多人数を必要とします。必要となる要員数の波が大きくユーザー企業が自前で全てを賄うことは通常不可能なので、日本ならではの多重下請け構造の元で、ベンダーが需要の波を吸収するクッションの役割を果たします。開発作業の丸投げになりがちなため、ユーザー企業は自社アプリケーションであるにも関わらず社内にそのノウハウを蓄積できない、という問題も生じます。ブラックボックス化の元凶ですね。他方のベンダー企業にとっては、求められる役割が労働力提供だとすると、生産性を高めようとする意欲はなかなか生まれません。効率を高めて投入する労働力を減少させたら、売り上げの減少を招いてしまうので無理もありません。大局的に見れば、日本のソフトウェア産業の進歩の妨げになっているとも言えます。
アジャイル体制の元では、仮説と検証にユーザー企業自身が関与することが求められます。常にある程度の自社要員が関与し、必要に応じてスポット的にベンダーの支援を仰ぎます。要員需要は平準化され、ベンダーの役割は労働力供給から価値あるノウハウの提供へと変化します。提供されるものの価値という視点に立てば、ベンダーは生産性向上や高付加価値化に積極的になるはずです。ユーザー企業に対するベンダー企業の立場は、受注・受託開発・納品の関係から、協力して内製開発を実践する関係へと変貌することになります。DXを推進できる人材を確保する事が急務となるので、ベンダーは評価基準を定め、ジョブ型の人事制度を拡大するべきと「DXレポート2」では主張します。
さて、RPG言語で記述されたアプリケーションを持っているユーザーはどうすれば良いのでしょう。「高齢化」したアプリケーションの多くは、ブラックボックス化もしくはその直前の状態にあります。急ぎアジャイル型プロジェクトを立ち上げて、アプリケーション再構築に乗り出すべきなのか、仮にそうだとしてどういったテクノロジーを採用すれば良いのか、明確な指針はありません。DXのためには、システムはオープン系である事が望ましかったのでしょうか。もしそう感じられることがあるとしたら、手段と目的とのはき違えという罠に陥っているかもしれません。DXはビジネスの話であって、ITはそれを支えるための手段ないしツールに過ぎないからです。他とちょっと違う毛色のツールであるIBM i の機能を活かすことで、他とは違うアプローチであったとしても目的であるDXを効率良く達成できればそれで済むはずです。逆にオープン系システムを採用しているからと言って、ブラックボックス化やレガシー化を避けられるわけではありません。
ここから先は、IBM i 独自の観点からデジタルプラットフォーム形成を目指して、レポートを評価し対応策を考えなければならないようです。次回はそのあたりに取り組んでみたいと思います。
ではまた
