It is the top of the page

Link for moving within the page
To text (c)

このウェブサイトではサイトの利便性の向上のためにクッキーを利用します。サイトの閲覧を続行されるには、クッキーの使用にご同意いただきますようお願いします。
お客様のブラウザの設定によりクッキーの機能を無効にすることもできます。詳細はこちら

The main part starts here.

  1. 企業情報
  2. netone on netone

第3回 デジタル基盤の存在

はじめに

第1回は、サービスを提供する側の論理ではなく、利用する側の視点にたちストーリーを作ること、そしてその実現に向けて全社的に支援をする仕組みについて触れました。第2回では、データの持つ意味と全社共通となるデータの必要性について説明をしました。今回は、これまでの話を少し掘り進んでデジタル基盤の存在について議論したいと思います。

With コロナの時代になって

未知の状況に柔軟な対応

With コロナの時代になり、働き方を変えていく必要に迫られています。どのような形にするべきか、これからどうなるのか。想像できることもありはしますがこの規模の事態は経験もなく、この先も未知であることをベースに考える必要があると思います。このような状況下で業務を支える基幹システムに対しては、確固たる堅牢制だけではなく、同時に柔軟性も求められているように感じています。
例えば、当社は10月よりテレワークを主とする働き方に変わりました。15分単位だった勤務時間の管理は1分に、これまでのタイムカードは廃止され、代わりに社内ポータルで打刻することになりました。これが決まったのが9月の取締役会で、事前に相談は受けていたもののシステムを改修する側としては、なかなか急な話です。大慌てで設計、開発をしてなんとか工期約2週間でリリースすることができました。

必要なものが揃っている

このような短期間で開発ができたことには理由があります。この打刻システム(以下、ウェブ打刻)は、第2回でご紹介したServiceNowの上に実装されています。各種申請や承認ワークフローとしてServiceNowを使い続けてきたため、こうしたものに利用する機能とデータは既に揃っていました。たかが打刻するだけではありますがゼロから開発するとなればそれなりの時間を要します。必要とするものが用意された状態からスタートすることができ、実現したいことに対して最短距離で開発をすることができる環境がそこにありました。
未知なことで埋め尽くされている昨今、よく考えられた計画よりも数多く試すことでデジタル経験を積むことが戦略として適切です。この経験を経て、デジタル基盤とは「デジタル化に必要な機能やデータが揃っている基盤」ではないかと考えるようになりました。

デジタル基盤に求められること

業務プロセス、人、技術、そしてデータ

必要な機能やデータとは、どのようなものを指すのでしょうか。
誰かに何らかの価値を提供する業務やサービスは、定められた業務プロセスと実行する体制、その実行を助けるツールや基盤、業務遂行に必要となるデータから構成されます。これらの要素は相互に依存しており不可欠なものです。裏を返せば、これらの要素が最初から必要十分に用意されていれば、検討する領域を大幅に減らすことができるようになります。例としてあげているウェブ打刻の場合は、既に確立された業務プロセス(勤怠管理)とデータ(従業員や組織マスタ)が存在したため、新規に必要となるのはブラウザやスマートフォンといったインターフェースへの対応だけでした。

サイロなシステムがデジタル化を阻む

ウェブ打刻が簡潔な実装で済んだもう一つの理由に勤怠データの連携先が人事システムに限られていたこともあります。もし、複数の業務に渡って利用されているデータであれば、それぞれの業務の間で矛盾なく利用できるようにまず共通化・標準化から始めなければなりませんが第2回でも述べたように全業務を見渡してデータを作成することは骨の折れる作業です。加えて特定の業務に閉じたシステムが行く手を阻みます。サイロなシステムのデータはそのシステムに閉じるため、そこで使われるデータは共通化・標準化からはかけ離れたものになります。システムごとにデータの形は異なりますし、そこでしか利用しないデータはシステムの中に閉じていても問題ありませんが、共通で利用するデータについては各システムの外に置き、必要に応じて各システムから参照する仕組みが必要です。
システムを適切な機能単位に分割、ウェブサービスAPI等で連携をすることで、データとシステム、システムとシステムの関係を疎にしていくことは、データの利活用の観点から大切です。システム連携は不確定性や調整コストが大きいため、実際は設計・開発が容易な業務プロセスと対となる形で開発される傾向が強いと思いますが、デジタル基盤にとってサイロなシステムからの脱出はテーマになるでしょう。

デジタル基盤に向けて

サイロ化されたシステムに、「銀の弾丸」はありません。まだ道半ばではありますが、これまでの実践の中で気づいた点について話をしたいと思います。

コアを決める

「コア技術を視える化することにより、製品構造の変えてはいけない部分と変えていい部分の見極めが可能になる。さらにその部分をモジュール化することにより、誰でもコア技術の正しい活用が可能となる。」(実践!モジュラー設計, 日刊工業新聞社)これは機械設計の書籍からの引用ですがITにも適用できる示唆に富んだ内容を持っています。密結合なシステムを疎結合にする(つまりバラバラにする)と言っても組み合わせのパターンが無数にある上にどれも大きな差はなく、ほどなく迷子になります。そのとき、この引用が効いてきます。引用文での「コア技術」とは自社にとって差別化要素となる技術という意味で使っており、それは「変えてはいけない」と定義しています。
基幹システムで「変えてはいけない」と言えば、ガバナンスで固められた会計周辺でしょう。ということで SAP S/4 HANAを中心に据えて「変えてはいけない」としました。そこからは業務プロセスに沿って周辺システムの検討をしていきます。「変えてはいけない」を中心に置くとそれが設計ポリシーになり、そういった制約がかかることで選択肢が絞られ、設計が進むようになります。

Fit to standardと単一責任の原則

業務に合わせてカスタマイズするのではなく、業務を既製のプロダクトやサービスに合わせることをFit to standardといいます。簡単そうで難しいものの一つです。何をもってカスタマイズとするのか?ここでは、実際に遭遇した例を使って説明をします。
「すみません、今度の物流システムは製品検査という機能がありません。ここはカスタマイズしますか?」当社の場合、出荷システムの中で製品検査を実施しており、この製品検査という機能はシステム導入時にカスタマイズした(作りこんだ)ものです。さて、基幹システムの更改にあたり物流システムも変えたいという話になったのですが、どれをみても“標準”では期待する製品検査という機能がありません。そもそも物流システムに製品検査機能って不思議な感じがしませんか。
オブジェクト指向プログラミング分野にはSOLIDという原則があり、その中に単一責任の原則(Single responsibility principle)があります。「1つのクラスは1つだけの責任を持たなければならない。すなわち、ソフトウェアの仕様の一部分を変更したときには、それにより影響を受ける仕様は、そのクラスの仕様でなければならない。」(“SOLID”, Wikipediaより)この説明では分かりにくいのですが、ここでのケースに当てはめると次のようになります。「もし製品検査機能をリニューアルするときは物流システムも入れ替えるのですか?」
システムを疎結合化する際、コンポーネントの数を減らすと設計ポイントも減るため多機能なコンポーネントを作りたくなりますが、変更に対して弱くなるだけでなく、むしろ設計が複雑になる場合もあり注意が必要です。

まとめ

突発的な事柄に対応してきた経緯からデジタル基盤とは「必要なものが揃っている基盤」と思うようになりました。ここで必要なものとは、業務プロセス、体制、技術(基盤)、そしてデータです。システムだけあっても体制が無ければ動きません。サイロなシステムには利用できるデータがありません。そこでシステムを疎結合化、共通で利用するデータを外に出すという発想に至るのですが、そのアイデアとして「変えてはいけない」と「単一責任の原則」を紹介させて頂きました。
単に業務をシステムに置き換える“Digitize”とテクノロジーを活用して業務や事業を変革する“Digitalization”という二つのデジタルな言葉あります。“Digitize”でも十分過ぎるほど大変なことですが、その先の”Digitalization“を想像したシステムであって欲しいです。
最後までお読みいただき本当に有難う御座いました。