業務の課題に対応するための業務機能の変更又は追加

平成27年度 秋期 システムアーキテクト試験 午後Ⅱ 問題 問2「業務の課題に対応するための業務機能の変更又は追加について」である。

問題文

システムアーキテクトは，業務の課題に対応するために，情報システムの業務機能を変更したり追加したりする。

例えば，通信販売業で，受注量や納品場所などの変更を出荷指示直前まで受け付け，受注当日中に出荷したいという業務の課題に対応するためには，次のような業務機能の変更又は追加が必要となる。

• 翌日以降分だけが可能であった受注内容の変更を，出荷指示直前まで受け付け，変更内容を作業計画や作業指示に反映する。そのため，受注から出荷指示までの既存の各業務機能を，日次起動方式から随時起動方式に変更する。
• 出荷作業時間を短縮するために，既存の出荷指示機能に，出荷作業者の倉庫内の移動距離が最短となるピッキング順序を指示する機能を追加する。

このような業務機能の変更又は追加では，既存機能の活用や既存の情報システムへの影響の最小化のために，例えば次のような工夫をすることも重要である。

• 既存の出荷指示のロジック部分をそのまま利用し，処理方式を随時起動方式に変更することで，受注内容が変更される都度，出荷指示内容に反映できるようにする。
• 出荷機能に影響を与えないよう，ピッキング順序を最適化する機能を新たに開発し，既存の情報システムから利用する方式にする。

あなたの経験と考えに基づいて，設問ア～ウに従って論述せよ。

設問ア

あなたが携わった情報システムにおいて，業務機能の変更又は追加を必要とするような業務の課題はどのようなものであったか。対象となった情報システムの概要，及び業務の概要とともに，800 字以内で述べよ。

設問イ

設問アで述べた業務の課題に対応するために，どのような業務機能の変更又は追加が必要となったか。業務の課題に対応できると考えた理由とともに，800 字以上 1,600 字以内で具体的に述べよ。

設問ウ

設問イで述べた業務機能の変更又は追加の際，既存機能の活用や既存の情報システムへの影響の最小化のために，どのような工夫をしたか，600 字以上 1,200 字以内で具体的に述べよ。

論文案

第１章　対象となった情報システムの概要，及び業務の概要

１．１　対象となった情報システムの概要

　私は送配電会社の事業部門において，業務システムの企画・開発に携わっている。送変電設備に関する作業を管理する作業管理システムの課題に対応した経験について述べる。

　作業管理システムは，送配電会社の社内システムであり，社内ユーザのみが使用できる。システムには，作業計画受付機能，作業着手機能，作業終了機能の３つの機能がある。このシステムは，数年後のハードウェアの更新に合わせてリプレースが計画されている。

１．２　業務の概要と業務の課題

　業務の概要を作業管理システムの機能に合わせて説明する。

（１）作業計画受付

　直営作業の場合は，社員が作業管理システムに直接作業計画を入力する。請負作業の場合，請負者は作業管理システムへアクセスできないため，作業計画申請フォーマットに作業計画を入力し，作業を受け付ける箇所へメールで送信する。作業受付箇所では，メールで受信した作業計画申請フォーマットを作業管理システムへ取り込む。
　
　作業受付箇所の営業時間は９時～１７時であるため，翌日の９時前に作業を実施するときは，前日の１７時まで作業計画申請フォーマットを送付する必要という課題がある。

（２）作業着手

　現地での作業着手に合わせて，作業管理システムで作業のステータスを受付から着手に変更する。申請した作業計画に変更がある場合は，着手前に変更が必要という課題がある。

（３）作業終了

　現地での作業終了に合わせて，作業管理システムで作業のステータスを着手から修了に変更する。作業計画通りの場合は「計画通り」と入力し，作業計画通りではない場合は，その内容を入力する。

第２章　業務機能の変更又は追加，業務の課題に対応できると考えた理由

２．１　業務機能の変更又は追加

　翌日の９時前に作業を実施するときは，前日の１７時まで作業計画申請フォーマットを送付する必要という課題，申請した作業計画に変更がある場合は，着手前に変更する必要という課題に対応するため，作業着手の直前まで作業受付を可能とする。具体的には，以下のように業務機能を変更又は追加した。

　

1. メールで作業計画申請フォーマットを受け付けていたのに変えて，Ｗｅｂシステムで作業計画申請を受け付けるようにする（以下，作業計画受付システム）。
2. 作業計画受付システムで申請した作業計画は作業着手まで変更可能にする。
3. 作業計画申請時，または，申請されている作業計画に変更があった場合，作業計画受付システムより，作業計画申請フォーマットをダウンロードする。
4. ダウンロードした作業計画申請フォーマットを作業管理システムに取り込む。

　以下は現行の業務と同じである。

２．２　業務の課題に対応できると考えた理由

　業務機能の変更又は追加により，作業着手の直前まで作業計画の変更が可能となる。ただし，作業計画申請フォーマットを作業管理システムへ人手で取り込むのは業務負担が大きい。送配電会社ではＲＰＡを使用することが可能であり，ＲＰＡにより作業計画申請フォーマットを作業管理システムに取り込めるようにした。

　送配電会社では，作業管理システムで翌日の作業を確認している。翌日の作業確認では，作業の輻輳がないか等の観点で確認する。業務機能の変更又は追加においても，作業計画の一次申請は前日１７時までに実施するように運用することにした。これにより，従来と同様に作業管理システムで翌日の作業確認が可能である。

　以上より，業務の課題に対応できると考えた。

第３章　業務機能の変更又は追加の際の工夫

　作業管理システムは，数年後にリプレースが計画（前倒しは不可）されていることから，作業管理システム改修をすることなく，業務の課題を解決する必要があった。そこで，Ｗｅｂシステムの採用，ＲＰＡの採用の２つの工夫を行った。また，作業管理システムのリプレースによりＡＰＩ連携が可能になる見込であることから，それを設計に反映した。

（１）Ｗｅｂシステムの採用

　作業管理システムと独立した作業計画受付システムを新規に構築することにした。請負者の作業計画を受け付けできるようにするため，Ｗｅｂシステムを採用した。必要最小限の機能にすることで，開発費用を抑え，工期を短縮する。

（２）ＲＰＡの採用

　作業管理システムを改修することなく，人手に頼らずに作業計画申請フォーマットを作業管理システムへ取り込むためにＲＰＡを採用した。送配電会社では，従来よりＲＰＡが導入されていたため，作業計画受付システムから作業計画申請フォーマットをダウンロードし，作業管理システムへ取り込むシナリオ作成のみで，人手に頼らずに取り込みを可能とした。ＲＰＡを活用することで，シナリオ作成のみとして，コストを低減することができた。

（３）作業管理システムリプレース後のＡＰＩ連携を想定

　作業管理システムがリプレースされると，現行のバッチ連携だけでなく，ＡＰＩ連携が可能となる。ＡＰＩ連携が実現すれば，作業計画受付だけでなく，作業着手，作業終了も作業計画受付システムから実施できるようになる見込である。その将来構想を見据え，作業計画受付システムでは，ＡＰＩ連携を想定した設計を行った。