柔軟性をもたせた機能の設計

平成29年度 秋期 システムアーキテクト試験 午後Ⅱ 問題 問2「柔軟性をもたせた機能の設計について」である。

問題文

販売管理システムにおける販売方法の追加，生産管理システムにおける生産方式の変更など，業務ルールが度々変化する情報システムや業務ソフトウェアパッケージの開発では，様々な変化や要望に対して，迅速かつ低コストでの対応を可能にする設計，言い換えると柔軟性をもたせた機能の設計が求められる。

システムアーキテクトは，情報システムの機能に柔軟性をもたせるために，例えば，次のような設計をする。

• ”商品ごとに保管する倉庫が一つ決まっている” という多対 1 の業務ルールを，”商品はどの倉庫でも保管できる” という多対多の業務ルールに変更できるように，商品と倉庫の対応を関係テーブルにしておく。
• 多様な見積ロジックに対応できるように，複数の見積ロジックをあらかじめ用意しておき，外部パラメタの設定で選択できるようにしておく。

また，このような柔軟性をもたせた機能の設計では，処理が複雑化する傾向があり，開発コストが増加してしまうことが多い。開発コストの増加を抑えるためには，例えば，次のように対象とする機能や項目を絞り込むことも重要である。

• 過去の実績，事業環境の変化，今後の計画などから変更の可能性を見極め，柔軟性をもたせる機能を絞り込む。
• 業務の特性などから，変更可能な項目を絞り込むことで，ロジックを簡略化する。

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

設問ア

あなたが設計に携わった情報システムについて，対象業務の概要，情報システムの概要，柔軟性をもたせた機能の設計が必要となった背景を，800 字以内で述べよ。

設問イ

設問アで述べた情報システムで，機能に柔軟性をもたせるために，どのような機能に，どのような設計をしたか。柔軟性の対象にした業務ルールを含めて，800 字以上 1,600 字以内で具体的に述べよ。

設問ウ

設問イで述べた設計において，開発コストの増加を抑えるために実施した機能や項目の絞り込みについて，その絞り込みが適切であると考えた理由を，600 字以上 1,200 字以内で具体的に述べよ。

論文案

第１章　柔軟性をもたせた機能の設計が必要となった背景

１．１　対象の業務と情報システムの概要

　私は，送配電会社の事業部門で，送配電設備の設備保全システム再構築の企画・開発に携わった。送配電会社では，電力を安定的に供給するため，送配電設備の保全を行っている。設備保全を支援するため，送配電会社では設備保全システムを運用している。

　現行の設備保全システムは，紙帳票を出力し，書面で承認を行い，システムステータスを人手で更新する運用である。設備保全システム再構築では，紙帳票の出力を不要として，システム内で承認，システムステータスを自動で更新できるようにする。

　また，現行の送配電設備点検では，点検結果を紙帳票に記録している。設備保全システム再構築では，スマートフォンやタブレットなどのデバイスで点検結果を記録し，点検結果を設備情報と一元的にシステムで管理できるようにする。

１．２　柔軟性をもたせた機能の設計が必要となった背景

　柔軟性をもたせた機能の設計が必要となった背景は２つある。

　一つ目は，将来，送配電設備の保守業務を子会社へ委託拡大していくことだ。保守業務の委託拡大に合わせて，送配電会社から子会社へ出向する従業員を増やし，送配電会社と子会社の担う役割が変わっていくことが想定されている。

　二つ目は，電力広域的運営推進機関で定めている「高経年化設備更新ガイドライン」が改定される可能性があることだ。２０２１年に定められたガイドラインでは，送変電のリスクスコア化の対象設備は５品目であったが，対象品目を拡大することが明記されている。また，送配電会社でも，点検の合理化を進めており，点検項目の削除，点検頻度の変更が想定される。

　上記の２つの背景により，柔軟性をもたせた機能の設計が必要となった。

第２章　柔軟性をもたせた機能設計

２．１　子会社への保守業務委託拡大

　子会社への保守業務委託拡大に備え，設備保全システムの各機能の権限ロールを柔軟に変更できるように見直しを行った。現状は，送配電会社の保守課，子会社の点検班の２つの権限ロールしかない。委託拡大において，送配電会社の設備管理課，子会社の保守班，点検班の３つの権限ロールが必要になる。さらに，将来は子会社の保守班と点検班が一体化していく構想もある。

　現状の権限ロールに加え，設備管理，子会社の保守班，点検班の３つの権限ロールをあらかじめ用意しておく。また，子会社の保守班と点検班の権限ロールは，同時に担えるようにしておく。

　これにより，権限ロールを見直すだけで，システム内での承認のルートの変更が不要になった。

２．２　点検項目見直しへの対応

　点検項目や点検頻度が見直されるたびに，システム改修を実施するのは非常に非効率である。それを回避するために，ＭＶＣモデルを採用することにした。業務ロジック（Ｍｏｄｅｌ），情報表現（Ｖｉｅｗ），制御（Ｃｏｎｔｒｏｌｌｅｒ）を分離する構造で，想定しているスマートフォンやタブレットなどの活用に親和性が高い上，画面や制御から業務ロジックが独立されているため，画面そのものの修正に必要な労力を抑えることができるからである。

　具体的には，Ｍｏｄｅｌは送配電設備の点検項目マスタ，Ｖｉｅｗでは点検で使用するスマートフォンやタブレットの画面，Ｃｏｎｔｒｏｌｌｅｒは設備保全計画に３つに分離した。これにより，点検項目の変更はＭｏｄｅｌの変更，点検頻度の変更はＣｏｎｔｒｏｌｌｅｒの変更のみとし，いずれの変更も局所化することが可能になる。

　具体的には，点検項目の追加・変更・修正があった場合，点検項目マスタ（Ｍｏｄｅｌ）のみを見直す。点検項目マスタの見直しの頻度は多いため，後述するようにシステムのユーザでもメンテナンスできるように配慮している。

　また，点検頻度の見直しがあった場合，保全計画（Ｃｏｎｔｒｏｌｌｅｒ）を見直す。設備ごとに定める保全計画の点検頻度のみを変更すれば，その点検頻度での点検が行えるようになる。

第３章　機能や項目の絞り込み

３．１　子会社への保守業務委託拡大への対応

　子会社への保守業務委託拡大においては，今後１０年間の委託拡大の構想を確認し，機能や項目の絞り込みを行った。送配電会社と子会社の役割を細分化すれば，より柔軟性をもたせることも可能であるが，開発コストが増加し，システムの運用も複雑となる。将来の役割を，管理，保守，点検の３つに絞ることで，開発コストを抑え，システムの運用も簡素化した。

　一方，３つの役割を同時に担えるようにすることで，必要な柔軟性を確保することができたことは，適切であると考える。

３．２　点検項目見直しへの対応

　「高経年化設備更新ガイドライン」を確認し，今後，リスクスコア化の対象設備が増えていくことを考慮し，ユーザが点検項目をメンテナンスできるようにした。さらに，点検の合理化等により，点検項目の変更も可能にした。

　ユーザが点検項目マスタのメンテナンスを可能にするための機能開発を行ったことで，開発費用が増加した。しかし，ユーザが点検項目マスタのメンテナンスができなければ，点検項目マスタ見直しの都度，システムベンダへの委託が必要となる。「高経年化設備更新ガイドライン」が改訂される見通し，過去の点検項目の見直し実績をもとに，将来の点検項目見直しの頻度を予想すると，点検項目マスタをユーザがメンテナンス可能にする機能の開発費用は，点検項目見直しの都度，発生するシステム改修費用の累計よりも小さいため，当該機能の追加は妥当であると考える。