サービス業のシステム更改では、要求マネジメントの困難に直面することが多い。そうした困難を克服するためには、「人的な準備」や「中長期的なアーキテクチャの検討」を行うことが重要だと筆者は考えている。以下では、その背景や理由について説明する。

サービス業の特徴と情報システムへの要求

サービス業では、収益機会をできる限り多く捉えたり、繁閑の差を少しでも平準化しようとしたりすると、顧客に提供するサービスのバリエーションは増大していく。前者の典型的な例の一つが、「お客様要望により」というキーワードで標準サービスが少しずつ変形していろいろなバリエーションができる場合である（お客様の要望に請求書の様式を合わせることも、1つの変形である）。後者には、B2Cであれば期間限定で特別なサービスを付加するなど、自社主導で変化を作るケース等が挙げられる。

このような変化は、タイムリーに起きる／起こすことも重要であり、情報システムとしても柔軟性を残しておくことが求められる。一方で、システマティックに変化を取り込んでおかないと、顧客接点業務はもとより、バックオフィスでも例外処理が頻発することになってしまう。稼働してから長い期間使い続けてきた情報システムを見ると、バックオフィス側を支えるシステムにおいても、稼働後の改修要求に応じて逐次埋め込まれた多数の分岐が見られ、保守性を下げていることが多い。 サービス業の情報システムに多く見られる5つの問題点を以下に示す。

• (1)【手作業との2重作業】
  顧客接点業務へのシステム追従が不十分で、手作業との2重作業になっている
• (2)【業務の複雑化】
  基幹システム上の処理だけでなく、後から追加された紙帳票やワークフロー承認が必要な業務が組み合わさった複雑な業務になっていて、事務ルールも複雑化している
• (3)【保守性の低下】
  基幹システム上のロジックが複雑化しすぎて、特定の人物以外、保守できない
• (4)【多数の類似業務機能】
  多数のシステムに同じような業務機能が存在している上、仕様が微妙に異なる
• (5)【データの散在】
  経営管理に必要な計数値を収集しようとしても、データが散在していて統合できない

こういった問題点を解きほぐさずに、新しいシステムへの再構築をかけたりすると、要求の爆発や、仕様追加が止まらない状況を生み出してしまうことがある。特に、【業務の複雑化】、【保守性の低下】、【多数の類似業務機能】の現状をしっかり分析しておかないと、新たにどのような変更を加えて（もしくは加えずに）システム化するのか、システムの範囲から漏れるものの有無や漏れる場合の影響の分析や対応などができない。そのため、要件定義や外部設計自体が遅延したり、移行しようとして問題が発覚したりといった状況に陥ることがある。

サービス業では【業務の複雑化】、【保守性の低下】、【多数の類似業務機能】の変化の元が、顧客接点を有する現場サイドにあることが多く、現状を業務側から分析しようとしても、自社のサービスや業務の全貌をつかんでいる人材がいないことがほとんどである。逆に、情報システム側では、基幹システムのデータ項目調査は比較的容易に可能であることが多いが、顧客接点を担うWebシステム等において、仕様の把握が十分できていないことも多い。

サービス業の情報システム更改におけるポイント

サービス業の情報システム更改を行う場合、以下の点が重要である。

• 現状の主要な業務の全体像を押さえ、業務そのものを整流化してシステム化対象業務を見直す
• 現状のサービスを支えているビジネスロジックのバリエーションを押さえ、将来的に柔軟性のある方法で実装する
• 顧客接点の柔軟性の確保、業務ルール・サービス変化への追従性の確保、統制上・管理上必要な堅牢なバックエンドシステム等の「適材適所」なシステム構成をとる

この中で特に、自社の現状サービスの取り扱いを決める（変更を許容できるのか、システム外手作業で対応するのか）ことができるかは、1つの重要なポイントである。ここでは、いろいろなシステムに同じような業務機能をなぜ複数作っているのか、その理由がわかるレベルまで理解できていることが大切である。しかしながら、前項で触れたように、業務やサービスの全貌がわかる人材がいないことが多いという点がネックになる。

上記を踏まえ、筆者は以下のような「人的な準備」「中長期的なアーキテクチャの検討」を行った上で更改に取り掛かることが肝要と考えている。

人的な準備

以下のような人材をアサインしたプロジェクト体制を組むことがよいと考えている。

• A.　業務全体の整流化を図る業務設計の担当者
• B. サービスの分析と再体系化を行う「サービス企画」の担当者
• C.　A、Bの人材と協働してシステム設計を進める、領域別の情報システム担当者
• D.　A、B、Cの各人材と協働し、システム全体構造を検討・ガイドするアーキテクト

特にA、Bの人材は、適任者がすぐには見つからない場合もあるため、現状分析を行う段階から、プロジェクトの中で育成する形でもよい（その代わり、時間は十分に確保する必要がある）。 こういった人材が仕組みを考えることで、無秩序なサービス変更やバックオフィス側への無理な対応要求への対応も検討することが可能となり、自社として守る業務・変化させてお客様に追従する業務を切り分けることができるようになってくる。

これらの役割を立て、人材をアサインすることが難しい場合は、システム更改のリスクを回避する観点からも、現行システムを維持しながら、システム間の接続の改善や、ビジネスフロントを作り変えるなどのプロジェクトに切り替えて考える必要も出てくる。

中長期的なアーキテクチャの検討

以下の点についてアーキテクチャ設計を早期に確立してから取り組むことも重要と考えている。

• 多種の事業やサービスで「共通」的に利用するシステムと、事業やサービス固有に作ることが有利な領域を見極め
  例：汎用パッケージと業種特化パッケージの使い分け、パッケージと自社独自開発が必要な領域のすみ分け。
• システム間の接続性の担保
  例：業務フロー・業務ルールをワークフローシステム上で一貫して実装し、システム間接続を行う。
• データの統合性の維持
  例：マスタデータを統一もしくは、外部で統合する業務・システムの仕組みを作る。
• ユーザ要求の変更が多い領域について、変更要求の反映が容易な仕組み
  例：システムの自社内製化や内製化を支えるツールの活用。
• サービスをシステム的に表現
  例：サービスの変更・変化を情報システムとして、どのようなデータ項目、データロジックで表現するかの構造を検討。

おわりに

人的な準備や、中長期的なITのアーキテクチャの検討を踏まえた上で、しっかりとした計画を作って、実際のシステム更改に取り掛かることをお勧めしたい。