システムリニューアル担当者必見！古いままのシステムを脱却する近道、お教えします。

頻繁に行う操作を、もっと速く簡単にできないものか…

イレギュラー対応は、システムを使わず手作業で行っています。

必要な情報を取り出すために、複数の操作が必要なのが面倒。

改修を繰り返したせいで、システムがブラックボックス化しています…

操作が複雑すぎて、誤操作が頻発。作業も属人化されています。

こちらのコラムでもご紹介したとおり、現在では古いシステムを放っておくことは、イコール経営リスクとみなされます。しかし一方で、現場でお話を伺うと「基幹システムが古すぎて、安易には手を出せない」というお悩みが多いと感じます。

補足しておくと、“レガシーシステム”は、主に1980年代頃に導入されたメインフレームやオフィスコンピュータを使ったシステムを指します。いまから30～40年以上前のものですから、パフォーマンスやセキュリティに不安があったり、使い勝手が悪かったり、ブラックボックス化して全容がわからなかったり、という問題を抱えています。

ただ、最近は技術革新が速いので、経過年数が５～10年程度でも”レガシー化“してしまうケースがあります。またコロナ以降は、世の中のニーズがガラッと変わったことで、実業務にシステムが追い付かない、というケースも多くなってきました。

PIVOTが得意としているのは、こちらの比較的若く、広義の意味での”レガシーシステム“です。

技術革新、特にUIやUXといった分野での技術や研究が、この5～10年で大きく進んだという点も大きいと思います。

それまで「システム」中心だったのが、人間を中心に考えるUIやUXをはじめとする「デザイン」 の視点が入ることで、より使いやすく快適なシステムがつくられるようになった。これは、サイトやアプリといった消費者向けプロダクトだけではなく、業務支援アプリなどビジネス分野も同様です。

いまは「必要な機能があって、問題なく動く」だけでは不十分で、日々の業務がより円滑に進むように、実際の利用シーンを具体的に考えて、システムに落とし込んでいくことが必要になります。

まずはこちらの図をご覧ください。

一般的に1つのサービスを動かすとき、システムの構成としては

①サイト/アプリ

②業務支援アプリ（入力端末・管理ツールなど）

③基幹システム（DBなど）

の3つに分けられると思います。

よくある困りごととしては、①と②の部分を改修したいけど、③の基幹システムがレガシーすぎて触れません、というケースです。①②を改修するには③も改修が必要なのですが、そうすると見積もりもスケジュールも重くなります。

そこで、PIVOTでは③の部分を触らず、その代わりに③と①②の仲介役を担ってくれる、いわば「通訳サーバー」をつくります。

例えば、欲しい情報が別々のテーブルに格納されていたとしても、「通訳サーバー」が必要な情報を１セットにして②の業務支援アプリ側に渡してくれる。そうすると②の業務支援アプリ側では、これまで複数画面を操作して取得していた情報を、1つの塊として取り出すことができるようになります。

逆に、情報を更新するときも、1画面で入力すれば、基幹システム側の複数のテーブルに自動で反映してくれるようになります。

コスト面でもスケジュール面でもメリットが大きいですが、これが実現できるのは、「基幹システム」の中身を理解するエンジニアと、システムを使う「人」を理解してデザインとして実現するデザイナー、両方の力があってこそです。

利用者を理解して「体験」をデザインするのがデザイナー、その体験の実現に向けてシステムをデザインするのがエンジニア、という形です。互いの共通言語であるデータは、デザイナー・エンジニアが共同でデザインします。

業務支援アプリを利用する担当者は、プロのエンジニアやディレクターではないケースが多くあります。

例えば、クライアント様が外食チェーンなら、各店長やエリアマネージャーの方が業務支援アプリ（端末）で「今日のメニュー」を入力したり、売上状況を確認したり…といったケースです。

業務担当者の使い方や業務の背景を知って、「ここは効率的に一気にやりたい」とか「すぐに更新できるようにしたい」といった要望に応えるUXと、その効率性を担保するUIは、デザインとエンジニアリングがセットでないと成り立ちません。

担当される方は、日々の業務にプラスして、その先にいるコンシューマーに向けて情報を発信する仕事もあるわけで、「サイトやアプリで、どういうレコメンドをしたらアップセルに繋がるか」といった部分も、デザイナーとエンジニアのタッグでしくみを考えていきます。

DX推進では、業務効率化が目的とされますが、本来は業務を効率的に行うことで、より本業の部分に資源を集中させて、競争力を高めていくことが求められるはず。その観点でも、エンジニアリングとデザイン、どちらの力も欠かせません。

「使う人」を理解するのがデザイナーで、「システム」を理解するのがエンジニア。システムと使う人の真ん中で、互いの強みを最大限に生かせるようなしくみをつくるのが僕らの役割だと思っています。

先にもお話した通り、市場ニーズの変化が激しい昨今では、経営ビジョンも柔軟に進化させることが求められますから、システムもそれに合わせて、ミニマムでフレキシブルなものが必要だと考えています。このしくみなら、短いスパンで現場や市場のニーズを組み込んでアップデートしていくことができます。

これまでの業務システムは、ある程度長期間使い続けることを想定してつくられていましたが、もう少し短いスパン、例えば、一般的にシステムの減価償却期間とされる５～10年程度を目安にアップデートしていくという考え方にシフトチェンジしていく必要があると思います。

PIVOTが得意としているのは、事業の一番外側、エンドユーザーとの接点に近しい部分だと思っています。

例えば、金融システムとか、会計ソフトのようなプロしか使わない完全なBtoBの領域ではなく、ユーザーの顔が見えるBtoC、BtoBtoCのような領域でこそ、デザイン×エンジニアリングの力が生きるのかなと思います。

基幹システムを担当するエンジニアリングの会社か、サイトやアプリの構築が得意なデザイン中心の会社か、という二分になってしまっているところはありますね。

業務支援アプリの使い勝手が悪かったり、基幹システムの理解が浅くてバグが多発したり…といったトラブルは、得意分野をどちらかに特化したベンダーが多いためだと思います。

PIVOTは創業当時から「デザイン×エンジニアリング」を掲げてきた会社で、デザインとエンジニアリングが生み出すシナジーを最大化することを目指してきました。DXを見据えたシステムリニューアルには、この力が役立つ場面が多くあると考えています。