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

第2回 一つのデータとアーキテクチャ

はじめに

前回は、当社のDXについて動機から考え方、進め方について説明をしました。今回は技術的側面から話を進めていこうと思います。

さて、私たちが目指すところは「全業務をシステム化。自動的に一連の業務が流れ、工数を最小限に」。全業務がシステム化されデジタル空間で業務をする世界をイメージしています。デジタル化された業務ではソフトウェアが基礎となり、そのプロセスとデータが厳密に定義されることになりますが、そこには様々な課題があります。データが本来の用途と異なる目的で利用されてしまったり、個人のエクセルで管理されていたり、異動によってメンテナンスされなくなったり。仮に個々のデスクトップにあるエクセルを含め全てのデータを集められたとしても、矛盾なく整理することなんてできるのだろうか。既製品を使うことで開発を省略しようとしたが、実際にやってみると現業務と合わない。とにかく悩みは尽きません。

本稿ではこうした悩みについてデータの話から始めてクラウドサービスを組み合わせるときの課題とアプローチ、特にPlatform的なサービスの利用について触れていきたいと思います。



一つのデータ


データありき

一見同じにみえる言葉も文脈によって違う意味を持つときがあります。「顧客」は、営業からすればビジネスの相手ですが、運用保守担当からすると問い合わせをしてくる人、問題があった場合の連絡先となり文脈によってその意味が変わります。ある特定の組織でしか利用していないシステムがありませんか?縦割り組織の文脈でシステムが作られると、そこで作られるデータは業務プロセスの中で組織を横断して流れるとき整合性が取れなくなります。全社共通語のデータとしては利用できません。

しつこくデータについて言及するのは、全てのアプリケーションはデータを必要とするからです。アプリケーションは、なんらかのデータが入力され、処理された結果が出力されます。入力されたデータが正しくなければ、出力されるデータもまた間違ったものになります。「DXなのだからAIを業務に活用しなければ」ということを良く言われるのですが、AIもまた正しいデータを必要とします。やはり、とにもかくにもデータありきです。


データが意味を持つとき

そもそもデータとはなんなのでしょうか。例えばここに“70”というデータがあります。この”70“に意味があるかといえば、これはただの数字です。この”70“という数字にkgと単位をつけ、さらに従業員リストの中にある私の名前と関連づけます。これで”70“という数字は”私の体重“という意味を持つようになります。

例えが適切ではありませんが、このようにデータはそれ単体では意味が持てず、データ間の関連として定義されて初めて意味を持ちます。名前の集合からなるデータだけでは、それが戸籍名なのか、通称なのか、正社員だけなのか、派遣社員の方も含まれているのか分かりません。点でデータをみていてもその意味は理解できません。

一つのデータとは

こうしたデータ間の関連を“データモデル”といいます。データモデルは、業務で扱うデータの意味を表し、そのデータの流れを業務プロセスとして定めます。企業にとってデータは共通の言葉であって、業務プロセスを遂行するための基礎となります。データは、いわば体を流れる血液で、どの器官(組織)にとっても等しいものです。企業の中では正となるデータは一つであるべきです。よりどころとなるデータが無ければ、どんなにシステムを作りこんだとしてもそのアウトプットを信用することができません。Garbage In, Garbage Outという言葉がありますが、まさにそのままです。しかしながら、いずれこの問題に直面することになるにも関わらず、業務プロセスに関心が向きがちで、なかなかデータモデルの話にならないことが多いと思います。

作る、利用する


アーキテクチャの視点から

それでも全ての業務をデジタル化するのであれば、全業務を想定したデータモデルが必要となりますが、それはかなり壮大な話です。いつ完成するのだろうか、完成したときには既に古くなっていないだろうかと不安になります。さらに、データは一つで、ゼロかイチな面が強く段階的なアプローチもとれません。幸運なことにERPを手作りしていた時代からすると現在では、先進的なパッケージソフトやクラウドサービスと多くの選択肢があり、これらを利用することで設計の手間を省くことができます。企業ごとの独自性を求められない領域については、時間をかけて内製開発するよりもこうしたものを選ぶことに利があると思います。

一方で既製品を採用することは、そのプロセスやデータモデルを受け入れることでもあります。そしてそれが現業務と完全に合致することは、ほぼありません。自社用に開発するか、既製品を使うかの違いは、スーツで言えば吊るし売りとオーダーメイドの違いと同じです。現場の意見が既製品を支持することはありません。また既製品の維持管理はベンダーが行うのに対し、自社開発したものはその寿命が尽きるまで開発体制を維持し続けなければなりません。どの機能を実現するのに何を使うのかに正解はありません。機能やコスト、工期だけではなく、導入後の運用保守も含め全体アーキテクチャ視点からの判断が求められます。


差分を埋める

既製品をそのまま受け入れるのではなく要求との差分をカスタマイズで対応する方法もあります。しかし、不用意なカスタマイズは、想定している使い方から逸脱、データモデルを破壊し、本来のパフォーマンスを殺してしまうときがあります。(データモデルを壊すくらいならスクラッチから開発する方が妥当)すべてのカスタマイズ行為が悪だとは思いませんが、本当にそれしか選択肢がないのか慎重な議論が必要だと思います。

適切に機能(業務)を分割し、それぞれに既製のアプリケーションをあてがう。どうしても作る必要があったとしても、その埋めなければならないギャップを最小化する。パッケージソフトやクラウドサービスといったピースを組み合わせてシステムを作るときは、それぞれのピースの役割を隙間なく重複なく組み合わ せ、さらに不足している部分を補完する必要があります。なかなか難しい問題です。

Platform的なサービス

作るでもなく、使うでもなく

特定の業務に特化して開発されたアプリケーションは、簡単に使えるという利点がある反面、自由度が低いという特徴があります。仮にデータモデルは受け入れるとしても、プロセスについては各企業の規模、組織体制、文化に影響される面が強いため自社の都合で実装したいケースも多いと思います。こうしたケースにはPlatform的なサービスを適用することができます。

ServiceNow

当社では業務フローの一部にServiceNowというクラウドサービスを利用しています。ServiceNowは、DXの波とともに非常に注目されているテクノロジーの一つになっています。ここでは実際に使ってみた視点で説明したいと思います。

通常、アプリケーションを開発する際には、さまざまなことを検討し設計に落としていきますが、ServiceNowでは一般的な業務プロセスについてはデータモデル、ビジネスロジック、ユーザインタフェース(フォーム等)が最初から用意されており、ゼロから開発する必要がありません。また、よく利用される機能についてはほぼ設定の範囲(ローコード、ノーコード)で作ることができ、さらにJavaScriptでコードを書けば細かい制御もできます。こうした部分は開発工程において大きな部分を占めており、これらを省略できることの効果は大です。これが開発スピードが数倍になるという理由です。

一方で、ServiceNowがどのような使われかたを意図して設計されているかを理解しないで開発をしてしまうと、カスタマイズの影響範囲がコントロールできなくなります。カスタマイズのためのカスタマイズのための・・・・と発散していきます。また「Low code, No codeだから誰でも簡単に使えます」という表現は私個人の意見としては正確ではないと思います。確かに巨大なコードを要求されることは無いため開発者としての習熟度はそれほど要求されません。それでもデータモデルを意識しながら目の前の業務をデザインする設計者としてのスキルは変わらず要求されます。どんなに努力してもデータモデルの想定を超えたことは実現できません。

ServiceNowは、その経験を積めば積むほど開発スピードが上がります。そこは間違いありません。ServiceNowにより開発言語の習得というハードルを下げ、もし業務知識を持つ人が自ら開発をするようになれば、要求定義をする必要がなくなり、さらにスピードが上がります。「ServiceNowのエクセル化」と表して仲間を増やそうとしているのですが・・・まだまだこれからです。

最後に

DXなのだからAIを活用して云々と言われることが多いですが、全てがデータありきです。まずはデータを整備しないことには次へ進めません。

データはデータ同士が関連を持つことで意味を持ち、会社の共通言語となります。これをデータモデルと呼びました。個人のエクセルで管理されているデータは、共通言語としては利用できません。

データモデルをゼロから作るのは途方もない労力が必要となりますが、既製品を利用することで設計と実装を省略することができます。特にどの企業でも共通している業務については積極的に採用すべきだと思います。独自性のないものに、リソースを割いてまで作ることの意義は見出せません。

それでも、それぞれの都合に合わせて制御したい業務もあります。そうした場面にはPlatform的なサービスがマッチするかもしれません。本稿では例としてServiceNowを紹介させて頂きましたが、ServiceNowであっても魔法の箱ではなく、開発言語知識はともかく、業務知識とデータモデルに立脚した設計スキルは変わらず必要です。

当社は”netone on netone”として、私たちの経験やそこから得た知見をお客様と共有することで、共に次のステップに進んでいければと考えております。

最後までお読みいただき有難う御座いました。