株式会社 日立製作所
マネージド＆プラットフォームサービス事業部
フロントエンゲージメント推進本部
第一ソリューションエンジニアリング部
担当部長
平山 浩二
前編では、DXに対するお客さまが抱えている課題やDXの必要性を紹介した。さらにDXを成功に導く6つのポイントのうち２つを解説。続く後編では、残る4つのポイントを紹介する。本稿でも、引き続きDXを始めとする産業系各種案件の総合窓口を務める平山浩二に話を聞く。
DX推進のポイントは、以下の６つでした。今回は３からお話いただきますが、運用方法を考えて開発を始める必要があるのはなぜですか。
DXはシステムを開発して終わりではありません。PDCAサイクルを回しながら新たな価値を生み出し続け、ビジネスを取り巻く環境の変化にも対応していくことが求められます。ビジネスの進め方、技術そのもの、技術の使い方は変化していくので、新しくてなおかつ優れた考え方および技術は、どんどん取り入れる必要があります。
このような変化があることを前提にすると、DXシステム自体は修正やメンテナンスは素早く・効率よく行わなければいけません。そのためには、新たに登場する多様な製品/サービスと容易に連携できるデータ基盤が求められます。
システム構成はシンプルな疎結合アーキテクチャーを採用し、小さなサービス機能を組み合わせてプログラムを構築する「マイクロサービス技術」を利用してサービス機能単位で入れ替えしやすくすることも有効です。当社はこういった考え方で設計・開発をするので、変化に対応しやすい環境を実現できます。
例えばあるメーカーでは各製品にセンサーを搭載し、稼働データを収集していました。製品がアップデートされる度に新機種向けの機能をベースとなるプログラムを付け足していったところ、いわゆるスパゲッティーコーディングになってしまい、新機種が加わる度に膨大なテスト工数がかかるようになっていたのです。そこで、最初のプログラムをリファクタリング(外部から見た時の挙動は変えずに、プログラムの内部構造を整理すること)し、変更した箇所だけをローコードで作り変えられるように提案したところ、継続的な保守が容易になりました。
さらに、当社は一旦開発したシステムは責任を持って運用しますので、古い機器やプログラムもできる限り保守し、ベストの状態に保たれるよう最善を尽くしています。私が入社2年目の頃、当時でも古くなっていた磁気ドラムのストレージを修理したことがあります。上司に「１回お付き合いを始めたら、最後までメンテナンスするものだ」と言われました。このような考え方はシステム運用においても日立のDNAに息づいていると感じます。
計画を終え、実行フェーズに入る際のポイントに入りますね。
できる限りしっかりした計画や装備を用意することが理想的ではありますが、DX推進においてはスピードも重要です。ある程度の計画が固まったら手を動かしましょう。その際、MVP（Minimum Viable Product：価値を提供できる最小限のプロダクト）から始め、アジャイル開発で修正しながら大きくしていくことをお勧めしています。
実際にモノが動くと、マインドが変わります。成功体験を積む機会にもなりますし、関係者のモチベーションはアップするでしょう。関係者の世界観が広がり、知らなかった技術に気づいたり、見えなかった課題が顕在化したりする可能性が高まります。
手戻りを少なくするために、ロードマップを作成するのではなかったのでしょうか。
DXに取り組んでいる間に、周囲の状況は変わります。「計画を作った以上、それを死守する」という考え方は、変化の激しい時代には適していません。ビジネスを取り巻く環境が大きく変化し、新しい技術も次々と登場する現在では、ロードマップは変わるものだということを念頭に置いておく必要があります。
特に想定していたほどの成果が得られないときは、一度立ち止まって状況を整理する必要があります。前編でお話しした登山をイメージしていただきたいのですが、山道で視界が悪くなったときに前進しては遭難してしまいます。
成果が出せないときに行うべきは、社内外の関係者がそれぞれの状況を正直に開示することです。我々ベンダーが包み隠さず実態を報告するのはもちろんですが、お客さまにも正確な社内状況を教えていただく必要があります。そのうえで、一旦前の段階に戻る、方向転換をするといった決断を下さなければなりません。
状況が大きく変わったり、成果がでなかったりする場合であっても、当社ならこれまでの豊富な経験からさまざまな代替案をご提案できます。正確な状況を教えていただければ、より精度の高いご提案が可能です。
日本企業は総じて臨機応変な対応が苦手な傾向にあると思います。私自身も以前ミドルウェアの開発を担当した際、当初はスクラッチ開発を選択していました。しかし当時の上司に「今世の中には優れたオープンソースソフトウェア（OSS）がたくさんあるのだから使わない手はない」と言われました。最初は「日立は自主独立の精神で100年近くやってきて、自分もそれで育ってきた」と思ったのですが、冷静に世の中の状況を見渡してみると、確かに上司の言う通りでしたね。そこで一気に考え方を変えOSSを主体に使いながら、必要に応じて日立なりの工夫を施すという開発方法に転換しました。それ以降は、視界が一気に広がり成長できた実感があります。
どういったズレが存在するのでしょうか。
例えば、同じ言葉を使っていても部門によっては異なる解釈をしていたり、同じことを別の言葉で表現したりする例はよく見受けられます。動き出してからそれに気がつくことは珍しくありません。
システム面で言えば、OTとITを連携するときにズレが生まれがちです。例えば、あるお客さまでは生産機械から情報を取得し、ITで処理するしくみを構築した際、取れていると思っていたデータが実は取れていなかったことがありました。そのプロジェクトはOTの企業と協業したのですが、言葉や考え方が異なっていたのです。そのときはお互いに少しずつ歩み寄ることで、解決しました。こういう局面ではお互いヒートアップして水掛け論になりがちですが、冷静に議論し原因を追及する必要があります。そのためには、お客さまやプロジェクトを一緒に進める企業との信頼関係が重要になってきます。
また、自動車メーカーのプロジェクトでは、当社と自動車部品メーカーの日立Astemoが連携して、お客さまと協業し、プロジェクトが成功しました。自動車部品のプロフェッショナルと一緒に取り組むことで、よりお客さまの状況がよく分かったので、適切なご提案ができたと思います。当社グループには多様な業種業態の会社がありますし、当社自身もさまざまな業界の業務に精通しているので、幅広いお客さまにご対応できます。
最後に、DXに取り組もうとお考えのお客さまにメッセージをお願いします。
成功体験を得るには、新しいモノやコトに興味を持って使ってみる、取り組んでみる姿勢が重要となります。実際に、私はどんな仕事がきても嫌とは言わず、「面白そうですね」と言うように心掛けています。
小さな成功体験を積み重ねるうちに、大きな成果を得られるようになっているはずです。お客さまがDXで新たな価値を生むことができるよう、日立のエンジニアが全力でサポートいたします。
ありがとうございます。今回の記事が、皆さまの挑戦の後押しになれば幸いです。
