システムコンサルティング

１．ショボい！業務を回せるだけの機能が全く足りていない

「パッケージがあればオールOK？」

残念ながら、素晴らしいパッケージソフトウェアだけでは、インタフェース設計はうまく行きません。特に、インタフェース設計に求められるのは、お客様の業務を詳細まで理解することです。

たしかに、旧システムからパッケージに入れ替えることで、既存の業務をなるべく標準化、効率化してしまうことは、まさにDXの目指すところでしょう。極端な話、パッケージを兎に角入れてしまって、旧システムを使った業務は全てパッケージに合わせましょう、ということもできてしまうわけです。

しかし、置き換えた新しいシステムと、それ以外の、引き続き使われるシステムとの関係は、どうなるでしょうか？全業務システムを丸ごとERPへ置き換えて、それを継続運用しない限り、新システムと他システムとのデータ連携、つまりインタフェースは必ずどこかで発生します。

そのため、インタフェースに関しては、結局のところ、モノ(パッケージ)が優れているかどうかではなく、他システムを使ってどんな業務が行われていて、どんなデータを流す必要があるのか、ヒト(コンサルタント)が漏れなくパターン分析することが、最も大事になります。

２．遅い！プロジェクトが全然計画通りに進まない

「インタフェース設計は計画に入っていますか？」

DX案件では、パッケージの理解と、ソフトウェア要件のFit/Gap分析には、沢山の時間と人材が投入されます。しかし、意外とインタフェースの考慮は見落とされがちで、気づいたときには時間が足りない、という状況に陥る危険性があります。また、大慌てで人をかき集めて、設計に手を付けても、必要な情報が足りない、ということもありがちです。

その主な原因は、インタフェースの要件とは、本質的に受け手(下流システム)側の要件であるためです。つまり、データの送り手(上流システム)は、受け手が何を求めているのか、受け手側から示してもらわなければ、わからないということです。

この状況を打破するためには、それぞれの検討チームを乗り越える、下手をすると、プロジェクトの垣根を飛び越えて、情報を取りに行かなければいけません。そんなときに、その垣根を越えて行ける覚悟とバイタリティを示すことが、真の顧客第一である、と私たちは考えます。

３．高い！パッケージをそのまま入れるはずなのに、やたらカスタマイズ費用がかかる

「そのインタフェース、本当にそのままで良いですか？」

いくつかのプロジェクトでは、インタフェースの受け手を刷新するが、送り手は旧システムのままいったん据え置き、あるいはその逆、ということがあります。そうすると、せっかく片方が変わっても、もう片方を変えることができないため、結局以前と同じ種類のデータを、別のレイアウトで受け渡すためだけに、インタフェースをカスタマイズするという非合理が、繰り返されてしまいます。

また、幸運にも、受け手と送り手のシステムを両方刷新できたとしても、その後に、例えば、受け手側のシステム構成を更新したい(例.下流システムの構成に新たなサブシステムを追加する)と思えば、再び同じジレンマに悩まされてしまいます。

これらの問題に対して、私たちは、「インタフェースの抽象化」という解決策を提案します。 インタフェースの抽象化とは、受け手と送り手のレイアウトを、直接マッピングするのではなく、その間に中間層を設けるという方法です。 こうすることで、お互いの物理的なレイアウトに対する相互依存性が解消され、受け手と送り手のどちらかが刷新される都度、インタフェースで受け渡すデータ品質を高めることが可能になります。

御社のDX案件では、抽象化を十分に考慮し、将来の変更にも拡張対応できるインタフェース設計になっているでしょうか？