論文の練習 平成28年 午後2 問2 情報システムの移行について

もともとの勉強計画では、7月26日以降を午後2の練習として決めていたので、まずは過去問で論文を作成することにしました。

もともとは攻略法を示してから論文を書くというエレガントなスタイルを目指していたのですが、うまい見せ方ができなかったので、とりあえず今の状態て論文を書いてみることにしました。

1時間半程度で、鉛筆ではなくタイピングなので、時間的にはぎりぎりかオーバーしているかもしれません。とくに書くネタを(論文の対象となるシステム)をどうするかについて悩んでしまいました。今回のシステムは架空のものですが、改めて、事前にシステムの概要や特性について整理しておく必要があるなと思いました。

書いてみるとなかなか難しく、「うまく構造化する」「システムアーキテクト的な視点で書く」といったところができていないような気がします。もう少し練習が必要だと思いました。

エントリの調整や、回答時に意識したポイントなどはのちほど説明します。。!

 

  1. 問題(平成28年午後2問2 情報システムの移行方法について)

    f:id:siiseku:20170730232421j:plain

回答
設問ア

この論文の対象となるシステム移行は、インテリア用品を販売するインターネットショッピングサイト(ECサイト)の移行である。

私は、インテリア用品を店舗・オンラインで販売するA社のシステム部門のマネージャであり、ECサイトの移行のプロジェクトマネージャを担当した。

現行システムは、インターネットサービスプロバイダーB社のホスティングサービス上のサーバに、自社でECサイト用パッケージを導入、自社で保守・運用を行っている。これまでの事業成長に合わせて、機能追加やシステムリソース増強を行ってきたが、システムの老朽化や拡張性のなさ、高度化するサイバーセキュリティ対応に加え、スマートフォン対応やインスタグラム連携など、ユーザーエクスペリエンス向上を目的とした新規機能追加に自社のリソースでは対応ができなくなりつつあり、今回ハードウェア更新のタイミングでC社が提供するSaaS型のクラウドサービスに移行することを決定した。

SaaS型の特徴として、ECサイトの全機能をサービス型で利用できることで、リソース管理やセキュリティ対応、顧客向けの新規機能追加はC社が責任をもって管理を行う。そのため、A社のシステム部門は空いた人的リソースをマーケティングやデータ分析といった、攻めのIT活用に注力することを見込んでいる。

しかしながら、パッケージシステムからSaaS型のシステムへ移行するためには以下の2点の特性がある。

ECサイトの業務はパッケージとSaaSで基本的には似ているのの、データ構造が大きく異なるため、構造の違いを意識しながらデータの整合性を保つ必要がある。

ECサイトは単体のシステムではなく、入出庫システムや、データ分析基盤等と接続している。そのため既存他システムとの接続仕様も変更になる。
(724文字)


設問イ

移行方法を選択するにあたり、特性を踏まえた制約条件の洗い出しを行った。

  • 現行システムと新システムでは、データ構造に大きく違いがある。そのため、データの移行結果について単純に比較することができない制約がある。移行データは商品データ、在庫データ、顧客データ、顧客の購入履歴等で数千万件の単位であり、比較作業をシステム化する必要があるが、それでも大量の時間がかかり、不備が発生するリスクもある。
  • データ分析などで利用するログデータや購入履歴のデータフォーマットが変わる制約があり、現行システムとデータを統合した分析ができないリスクがある。
  • 既存他システムの接続仕様を変更するに伴い、既存他システム側を停止してシステム変更を行う制約がある。顧客向け業務ではないデータ分析基盤などでは、システム停止による影響は軽微だが、入出庫システムを停止する場合、入出庫業務も停止する必要があり、顧客向け配送業務や、仕入先からの入庫処理が滞るリスクがある。

上記踏まえ、リスクを最小化するために次のような移行方式をとることとした。

(1)事前のデータ移行
データ量が膨大であることから、新システムへの正式移行日の1か月前からデータの段階的移行を実施し、データ移行に伴う時間経過のリスクを最小限にした。

(2)既存他システム側のインタフェース変更の先行移行
既存他システム側は、業務の閑散期の週末を利用して、現行システム、新規システムの両方に対応するインタフェースの導入を事前に移行した。これにより、現行システムから新規システムに移行する際の既存他システム側の作業を最小限にすることで、移行時の変更作業を最小限にとどめリスクを削減した。

(3)移行時間帯の現行サービス停止
新システムは既存システムの完全な置き換えとなるため、データ整合性においても完全である必要があり、現行サービスを停止、顧客向けにはメンテナンスとしてアナウンスし、現行システムから新規システムへの最終的なデータ移行を行うことで、現行・新規でデータの整合性がとれないリスクを最小限にした。

 (4)データ移行の優先順位付け
データ分析用のデータ統合については、ECシステムが完全に移行した後で、空いたリソースで対応することとし、移行作業のスコープ外とし、データを統合した分析作業をすぐに着手できないリスクは受容することとした。
(970文字)


設問ウ

現行システムから新規システムへの移行において、移行作業後の業務に支障が出ないようにするために、次のような工夫を行った。

  • 現新データの比較ツールの利用
    現新では、大量のデータ構造が異なるデータの移行を行うため、データの整合性確認作業の正確性や時間がかかり、正しく移行ができない支障がある。そのため、現新でのデータを比較するツールを作成、移行作業前にテストを行った上で、移行作業で利用することにより、データの整合性を維持することとした。
  • 切り戻しの準備
    今回の移行は、現行システムから新規システムへの完全な置き換えとなるため、移行作業中に遅延や障害が発生し、移行が継続できなくなった場合、業務が再開できないといった支障がある。そのため、移行作業の継続付加時には現行システムへの戻しを行うこととし、移行判定基準の設定、戻し手順の確認や、戻し次元の定義を行い、リハーサルで確認を行った。また、移行作業時の既存他システムの変更作業を最小化したことが、戻し作業の安定性に寄与した。
  • 新システム移行後の、ユーザー限定での試行期間の設定
    移行作業は万全を期すものの、顧客目線で不備がある可能性は排除できない。しかしながら、すべての顧客に新規システムを解放すると不備があった場合大きな混乱を起き、既存のサポート体制では対応できないという支障がある可能性がある。その対応として、優良顧客向けに「リニューアル・シークレットセール」を開催し、ECサイトを回遊させることで、データ移行の不備等があった際の影響を最小限に留めることとした。

上記踏まえ、移行作業を実施した。十分なリハーサルの成果により、移行作業はスムーズに進み、問題がなかった。「リニューアル・シークレットセール」期間中に顧客から軽微な不具合の指摘を受けたが、サポート部門も混乱なく対応を行うことができた。

現行システムの完全停止や、優良顧客向けのセールは、経営から見た場合売上減少となるものだったが、マーケティング部門や経営企画部門と議論し、経営陣に新システムへの移行は必須であり、移行作業に高いリスクがあるものの、将来的な事業拡大のためには新システムへの移行が必須であることについて説明し、理解を得ることができたことが、今回の成功の大きな要因と考えている。以上
(944文字)