はじめに
メーカーのDX推進組織でテックリードとして働いているモンゴルです。
DX推進組織は自分たちが作るシステムを小さくすることで開発と導入がしやすくなる一方、その状態を継続し続けると自分たちの目的が達成できなくなり、存在意義が見いだせなくなるかもしれないと考えるようになりました。
この想いと、どのように進めていくべきかについての自分なりの考えを残しておこうと思います。
メーカーにおけるシステムアーキテクチャとサブシステムの課題
メーカーにおいては、基幹システムが中心としてあり、顧客向けにはそれに加えてカスタマーポータルがやや中心に近いシステムとして存在すると考えています。
カスタマーポータルからのリンク先として存在する、サブシステムには次の課題があると考えています。
- メインシステムの変更の影響を強く受ける
- 目指す世界観は、サブシステムの範囲内になりがち
DX推進組織が目指すべきところと、それに対するアプローチ
DX推進組織が社内受託先でなく、事業部とともにDXを推進していくためには顧客体験向上のための施策の策定 & 実行に関わる必要があると考えています。
ただし、この主導権は、事業部にありがちだと感じています。なぜなら事業部は既存のサービス事業やほかのサブシステムを含めて顧客体験を把握しているという視野の広さがあり、自分たちのビジネスモデル、ビジネスの方向性、将来性、顧客の課題の把握といった視座の高さもあります。
DX推進組織にシステム設計・開発のプロがいたとしても、DX推進の最終目標がビジネスの推進であれば、この責任を持っている、視野も広く、視座も高い事業部が主導権を握るのは当然のように思います。
それでは、そのような状況下で、どのようにして事業部と対等な関係を築けるのでしょうか？
私は次のようなことをしながら、信頼関係作りと自分たちの高い視座獲得 & 広い視野獲得が重要だと考えています。
- より高い視座の獲得
- 顧客向けシステムとして新たに必要になったデータの蓄積の仕組みづくりとシステム設計・開発（いわば、新しい基幹システムの開発）
- 顧客体験の起点となるカスタマーポータルを一緒に作る（より中心に近いシステム設計・開発に携わる）
- より広い視野の獲得
- サービス全体の体験設計を一緒に行い、そのうえでサービスの分割、連携に関する方針策定を自分たちで行い、一緒に開発していく（サブシステムの単位でチームが分かれることもあるが、互いに対話し、共通のドメインモデルを見出し、育てていく。）
- メリットある存在になる
- システムづくりのプロとして他社事例を引き合いに出したり、データ分析できる基盤を整える、基本的に事業部の方が何でもできる世界で、自分たちにしかできない価値はないか模索する
まとめ
DX推進組織は役割を果たすために、サブシステムの開発だけでなく、広い視野を持ち、顧客体験向上のための施策策定 & 実行に積極的に関わる必要があると思っています。
また、システム設計・開発に関してDX推進組織の方が知っていたとしても、基本的に事業部から教えていただくという立場であることを忘れず、しっかりと対話していく、ドメイン知識を明らかにしていく地道な活動が必要だと思っています。
ただし、DX推進組織としての専門的な意見を主張する場面も時には必要だと考えています。
