SoEとSoRを区別するのは“当然”なのか？ 「SoRだって進化したい」その理由：「不真面目」DXのすすめ

SoE（つながりのためのシステム）とSoR（記録のためのシステム）は区別して考えることが一般的であることに、筆者は疑問を呈します。「『SoEはアジャイルでSoRはウオーターフォールだ』という主張は大嫌い」と筆者が言い切る理由とは。

[甲元宏明，株式会社アイ・ティ・アール]

この連載について

　この連載では、ITRの甲元宏明氏（プリンシパル・アナリスト）が企業経営者やITリーダー、IT部門の皆さんに向けて「不真面目」DXをお勧めします。

　「不真面目なんてけしからん」と、「戻る」ボタンを押さないでください。

　これまでの思考を疑い、必要であればひっくり返したり、これまでの実績や定説よりも時には直感を信じて新しいテクノロジーを導入したり――。独自性のある新しいサービスやイノベーションを生み出してきたのは、日本社会では推奨されてこなかったこうした「不真面目さ」ではないでしょうか。

　変革（トランスフォーメーション）に日々真面目に取り組む皆さんも、このコラムを読む時間は「不真面目」にDXをとらえなおしてみませんか。今よりさらに柔軟な思考にトランスフォーメーションするための一つの助けになるかもしれません。

「『不真面目』DXのすすめ」のバックナンバーはこちら。

　本連載では、これまで常識や一般的とされてきたことに疑問を持つことをお勧めしていますが、今回のターゲットはSoEです。

　SoE（System of Engagement：つながりのためのシステム）という概念が日本に紹介されてから長い年月がたちました。今でも、SoEとSoR（System of Record：記録のためのシステム）を区別してITシステムの設計や開発、運用の方法を使い分けることが推奨されています。こうした区別は果たして今の時代に合うものなのでしょうか。

　改めて、SoEとは何かを考えてみましょう。

そもそもSoEに定義はあるのか？

　SoEは、顧客や一般消費者、取引先といった自社ビジネスに関わる人たちとのつながりを強化することを目的としたシステムを指します。その対意語としてよく使われるのがSoRです。

　従来存在するシステムは正確にビジネスデータを記録することを第一としてきたために、データ化することが容易ではないユーザーの嗜好（しこう）や自社に対する印象といった定性的かつ主観的な情報は対象外としてきました。ユーザーインターフェース（UI）にもあまり配慮されていませんでした。

　SoEを最初に提唱したジェフリー・ムーア氏は、顧客のニーズや価値観が多様化している現代においては、ファクトデータだけを記録するシステム（SoRのこと）だけでは駄目で、洞察、アイデア、ニュアンスといった定性的な情報を扱うシステム（SoE）が重要になると説いたのです（注1）。

　SoEという新しい概念は素晴らしいものだと思いますし、これまでITシステムが無視してきた価値ある情報を取り込むことも非常に重要です。しかし、SoEというのは概念であり、どのような要件を満たせばSoEと呼べるのかはあいまいです。

　例えば、SoEシステムの例にCRM（Customer Relationship Management：顧客関係管理）を挙げる人も多いのですが、CRMはSoEが提唱されるはるか前から存在する名称です。顧客に関するデータを記録しているのでSoRと分類しても間違いではありません。筆者がSoEとSoRについての解説や意見を見る度に疑問を持つのは、多くの人がSoEとSoRを別のシステムと考え、それぞれ別のアプローチで設計／開発／運用を行うことを推奨している点なのです。

SoRだって進化したい

　まず筆者がモヤモヤするのは、「SoRは一般的にレガシー系であり、『守りのシステム』だから、大きな機能追加は不要でユーザーインターフェースに凝る必要はない」という主張です。SoRはビジネスにとって極めて重要なシステムです。SoRだってAI（人工知能）を活用するなど今どきのテクノロジーを適用して進化すべきです。優れたUIを準備してデジタルネイティブ世代の若い従業員に使いにくい入力画面を無理に使わせることを止めるべきなのです。

　また、「SoEは変化が激しいが、SoRはさほどでもない」という主張もありますが、ずっとSoRを使っているユーザーに同じことを言えるでしょうか。システムアーキテクチャやIT部門の都合でユーザーからの改善要望に迅速に対応しなかった結果、使い勝手が悪いために作業効率が上がらず、バックログが積み上がっているのではないでしょうか。SoRのほとんどは、変化がないから変わらなかったというわけではなく、変化を受け入れてこなかっただけなのです。

「SoE=アジャイル、SoR=ウォーターフォール」という考え方はやめよう

　筆者が最も嫌いな主張が「SoEはアジャイル（指向の開発が可能）で、SoR（のそれ）はウォーターフォールだ」というものです。「SoRは変化が乏しいから」というのがその主張の根拠ですが、SoRにも変化はあるというのは前述の通りです。そもそも、欧米ではSoEという概念が全く存在していなかった2000年代初頭からアジャイルを取り入れる企業が多くありました。筆者も2003年からSCM（サプライチェーンマネジメント）というバリバリのSoRにアジャイル開発の手法を適用しました。SoRも変化は激しいので、アジャイルを適用した方がよいのは歴史が証明しています。

　また、一つの会社や組織の中に、「アジャイル組」と「ウオーターフォール組」を作るべきではありません。アジャイルでは開発に携わる人全員が親密にコミュニケーションを取ることが重要で、他のメンバーの意見にも十分に耳を傾けます。その結果、アジャイルチームは「和気あいあいとした楽しいチーム」になります。

　それに対して、一般的なウオーターフォールではコミュニケーションは重視されず、ユーザーが決めた要件を粛々とエンジニアが設計し、その仕様をコーダーが実装するという流れになるので、「楽しくないチーム」が一般的です。楽しいチームと楽しくないチームが同じ組織の中に存在するのは避けるべきです。

　SoRはビジネスにとってもDX（デジタルトランスフォーメーション）にとっても極めて重要なシステムであることは論をまちません。「SoEとSoRという、重視するポイントが異なるシステムが存在している」という考え方は重要ですし、システムに関わる人は全員理解しておくべきです。ただし、SoEとSoRを明確に区別する必要はないのです。

（注1）「Systems of Engagement and The Future of Enterprise IT」（Geoffrey Moore）

筆者紹介：甲元 宏明（アイ・ティ・アール　プリンシパル・アナリスト）

三菱マテリアルでモデリング／アジャイル開発によるサプライチェーン改革やCRM・eコマースなどのシステム開発、ネットワーク再構築、グループ全体のIT戦略立案を主導。欧州企業との合弁事業ではグローバルIT責任者として欧州や北米、アジアのITを統括し、IT戦略立案・ERP展開を実施。2007年より現職。クラウド・コンピューティング、ネットワーク、ITアーキテクチャ、アジャイル開発／DevOps、開発言語／フレームワーク、OSSなどを担当し、ソリューション選定、再構築、導入などのプロジェクトを手がける。ユーザー企業のITアーキテクチャ設計や、ITベンダーの事業戦略などのコンサルティングの実績も豊富。