クラウド移行に「コスト削減」ばかりを求めてはいけない理由〜経営層に贈る言葉〜：特集：日本型デジタルトランスフォーメーション成功への道（3）（3/3 ページ）

[文：高橋睦美／インタビュー：内野宏信,＠IT]

企業経営は「アジャイル」になっていくべきだ

編集部　次に少し具体的なクラウド移行の話に入りたいのですが、リフト＆シフトではクラウドに移行すべきではないもの、移行すべきもの、クラウドネイティブで新たに作り直すものなどを切り分け、適切に移行計画を進めることが重要とされています。自社内のシステム特性を全て把握していない例も多い以上、こうした切り分けは事前にしっかりと行う必要があるのでしょうね。

吉羽氏　そうですね。ただ注意したいポイントがあります。オンプレミスにたくさんあるシステムを少しずつ仕分けて、順番に「3年計画」「5年計画」で移行するというケースがよくあります。やり切れるならそれでもいいのですが、経営環境の変化を受けて、計画途中で投資できるお金がなくなる可能性も十分にありますよね。怖いのは、それでクラウド移行が中途半端に止まってしまうことです。元の状態よりも複雑でコストもかかる状態で止まってしまう。従って、クラウド移行もよりスピーディーに進めた方が良いと考えます。

編集部　変化が速い「今の経営環境」に即したシステム体制を整備するには、時間をかけてクラウド移行すると、移行を終えたころには「今の経営環境に必要なシステム」とはズレてしまう可能性もある。よって移行自体もアジャイルに進める必要がある――先の話に立ち返れば、クラウド移行はビジネス目的を達成するためにどう各種技術を適用するかという「経営の話」ということでした。すなわち、経営自体もアジャイル型に変えていく必要があるということでしょうか。

吉羽氏　不確実な時代ですから、アジャイル型の経営にならざるを得ないでしょう。1年先は予測できても、5年先、10年先が予測できない以上、5カ年計画や10カ年計画を立ててもその通りになる保証はどこにもありません。

　また、立てた計画を振り返っている企業がどれだけあるかも疑問です。計画通りにやり切ったか、狙い通りの結果が出たか、高い精度で検証している企業は意外に少ないのではないでしょうか。「今は計画1年目だが、差分はこうだからこのままでいいだろう」「こういう変化があったから、こう変えていこう」といった評価を行い、目標とのズレを修正するためにITという実行手段をひも付けていく。こうした継続的改善が大切です。

「銀の弾丸」は存在しない

編集部　いずれにせよ、まずは経営層がITを理解するとともに、目的を現場にしっかりと伝える。現場も目的に応じた取り組みの成果をしっかりと測り、修正していくことが何より大事だということですね。

吉羽氏　そうですね。As IsとTo Beの設定なしに、Howの話だけしてクラウドに移行するのは賛成しかねます。また、ビジネス目的と言っても複数あると思いますが、全てをトッププライオリティにすると、大体どれも中途半端になります。優先順位を付けなければいけません。

　その意味で、ちょっと話はそれますが、最近のマイクロサービスばやりにも若干の危うさを感じています。というのも「マイクロサービスを使いたいんです」という相談が結構あるのですが、やはり手段ばかりが先にあって、肝心の「何のために使うのか」を尋ねても「素晴らしい未来が待っているから」といった答えしか返ってこないのです。

　より具体的には、「一枚岩の大きなアプリケーションで、ちょっとメンテナンスするのにいろいろなところを気にしなければいけないから」「テストを自動化したいけれど難しいから」「そもそもコードが汚いので作り直したいから」といった理由から着目されるようです。しかし、マイクロサービス化すればきれいなコードが書けるかと言うと、残念ながらさらにひどいことになる公算が大きいですね。

　業務ドメインを設計し、どのコンポーネントとどのコンポーネントは分離しても大丈夫か、そのやりとりはどう行われるかといった設計ができて初めて成り立つものですから、そうしたものがなく取り組んでも、マイクロサービスが入り乱れてぐちゃぐちゃになると思います。全ての起点になるのは、やはり「ビジネス目的」なんです。クラウドサービスと同じで「手段」を目的化してはいけません。何らかの方法論に対して「銀の弾丸」思考を持つ方は結構多いのですが、解きたい問題は何かから考えることが必要です。

経営層には、ITの価値、エンジニアの価値を正しく理解していただきたい

吉羽氏　また、経営層のITに対する理解という意味では、実験や検証を行うための予算を削ることも避けていただきたいですね。もはや安定運用を担うだけがIT部門の役割ではありません。ITにコスト効率だけを求めてビジネス効率を求めないというアプローチではなく、「差別化の源泉を開拓するための実験」ができる余力を持たせることが大事です。

編集部　そうすると、言われたままに作る、運用する形ではなくなるわけですから、求められるエンジニア像も、エンジニアの遇し方も変わってくるのでしょうね。

吉羽氏　はい。エンジニアは主体的かつ探索的に課題に取り組むスタンスが求められますし、会社側も彼らを競争力の源泉と捉え、減点法ではなく、加点法で扱うべきです。また優秀な人ほど、オーナーシップや自由を求めます。「これをこういうふうにやれ」というのではなく、“実験に取り組むための余裕”をある程度認めるべきです。

　一方、運用はある程度、自動化される流れになるのは間違いないと思います。しかし、運用をやったことのない人が自動化すべきプロセスの選定・設計などができるかというと、そうではないと思います。どう設計すべきか、トラブルに備えてどんな用意をしておき、障害をどうすれば的確に検知できるかを把握するには経験が必要です。従って、運用エンジニアが不要になるといったことはないでしょう。

　ただし、コードを書いて一連のプロセスをツール化し、同じことが二度起きないよう自動化していくのが、これからの運用エンジニアの役割になると思います。運用エンジニアもコードを書ける方がいいですし、逆に、夜中に電話がかかってきて対応に追われるといった厳しい現場の経験がないと、いいコードは書けないと思います。

編集部　そうしたエンジニアが、またそうしたエンジニアを育てることが差別化の源泉になる以上、ジョブローテーションも必要になるのかもしれませんね。

吉羽氏　AmazonやGoogleなどさまざまな会社で、「これをやってみたい」と手を挙げた人が他部署に応募し、ロールを変える支援をする「インターナルトランスファー」という制度を用意していますよね。転職させずにエンジニアのスキルを伸ばす環境を用意するわけです。こうした機会の提供の他、給与面でも優秀なエンジニアは優遇しないといけないと思います。

編集部　実際、米国では優れたエンジニアはプロスポーツ選手のような形で認識されていますね。その意味では、エンジニアのキャリアパスを設計・改善することも、経営層がリードすべき重要な仕事なのかもしれません。例えば、管理職とスペシャリストという2つのコースを用意する企業も増えていますが、過去の取材の中では、「自分より高い給料をもらえるエンジニアを出すことが自分の役割だ」と話すマネジャーもいました。

吉羽氏　その通りだと思います。プロ野球でも、球団フロントよりも野球選手の方が圧倒的に高い給料をもらっていますが、それと同じことです。それぞれ果たすべき役割や責任が違い、中には余人に変えがたい、高い給料を出さないと獲得できないタレントがあるわけです。

　どうか経営層の方々には、断片的な方法論だけにとらわれることなく、目的に対する手段としてクラウドをはじめ各種テクノロジーやメソドロジーがあること、それらは全て目的にひも付いていること、そして差別化の源泉を生む取り組みの中心にいるのはエンジニアであることを、ぜひご理解いただきたいですね。

　ITを知っている人が経営層に加わり、クラウドやAIといったテクノロジーをビジネスに活用する姿勢を鮮明に打ち出したファーストリテイリングのような企業も実際に現れ始めています。「ビジネスのためのIT」に正しく投資する状況が広がっていくことを、私としても期待しています。

特集：日本型デジタルトランスフォーメーション成功への道 〜“他人事”ではないDXの現実解〜

テクノロジーの力を使って新たな価値を創造するデジタルトランスフォーメーション（DX）が各業種で進展している。だが中には単なる業務改善をDXと呼ぶ風潮もあるなど、一般的な日本企業は海外に比べると大幅に後れを取っているのが現実だ。では企業がDXを推進し、差別化の源泉としていくためには、変革に向けて何をそろえ、どのようなステップを踏んでいけばよいのだろうか。本特集ではDXへのロードマップを今あらためて明確化。“他人事”に終始してきたDX実現の方法を、現実的な観点から伝授する。

特集：日本型デジタルトランスフォーメーション成功への道 〜“他人事”ではないDXの現実解〜