無駄な機能を備えたメタボなITシステムが、多くの企業の運用コストを押し上げている。メタボシステムを2度と作らないための方法を解説しよう。

 再構築対象のメタボシステムでどの機能を残すかが決まったら、その機能の改善を検討する。ただし、ユーザーからの改善要望を全てうのみにしてはいけない。

 再構築プロジェクトでの要件定義の手順は「方針決定」「業務分析」「機能分析」「業務設計」という4フェーズ、10ステップで進める。ここではそのうち、再構築後に残すと決めた機能の改善について検討する、「継承機能の改善内容の整理」ステップを解説しよう。

「継承機能の改善内容の整理」ステップ:効果と実現性で改善の可否を判断

 継承機能は業務を実施するうえで必要かつ重要だが、利用部門が現状の処理内容や画面レイアウトなどに満足しているとは限らない。そのため再構築プロジェクトでは必要に応じて、継承機能の処理内容や画面レイアウトなどを改善する。改善要望を聞くことも、無駄な機能の削除を受け入れてもらううえで重要だ。

 ただし利用部門の要望に合わせてやみくもに改善すると、開発や運用保守の工数が膨らむ。そのため継承機能の改善は、ビジネスや業務での効果を期待できる範囲に絞る。

 「継承機能の改善内容の整理」ステップでは、継承機能に対する利用部門の改善要望を把握し、効果を期待できる改善要望を選択したうえで、具体的な改善策を検討する。

 最初に「改善要望アンケート」というフォーマットを使って、検討メンバーから継承機能についての改善要望を集める。改善要望アンケートは、対象機能を指定し、改善要望を「現行機能の問題」「業務上での影響」「改善したい内容」「改善による効果」の4項目に分けて記入するようになっている。

改善要望アンケートと改善要望一覧表
改善要望アンケートに記入してもらい、改善要望一覧表に整理する
[画像のクリックで拡大表示]

 検討メンバーにアンケートの書き方を説明する際に、所属部署を代表する立場で改善要望を記入するように依頼することが重要だ。

 3~5日間かけてアンケートを記入してもらい、回収する。最後に、検討メンバーそれぞれに1時間程度ヒアリングし、アンケートに記入した内容を正確に把握する。

 ここでは「改善による効果」が適正な内容かどうかを確認することが重要だ。もし適正でない場合には、ヒアリングの場で修正してもらう。

 アンケートとヒアリングで改善要望を把握したら、その内容をサブシステム別、業務用途別、システム機能別に並び替えて「改善要望一覧表」に整理する。

 そして、それぞれの改善要望に対策を打つことによる効果と実現性を踏まえて、実施するか否かを決める。効果が期待できなかったり実現性が低かったりして対策を打たないと決めた改善要望については、検討メンバーと合意しておく。

 A社の例では、見積もり管理サブシステムの「商品組み合わせ可否チェック」に対する「よくある商品の組み合わせにセット型名を付けて、一度に入力できるようにする」という改善要望は、対策を実施することで「営業員一人当たり月に200分の入力時間短縮」という効果が想定される。そのため、対策を打つことに決めた。

 一方「見積もり承認/修正指示」に対する「申請された見積もりの修正内容を、あらかじめ設定したパターンから選択して入力できるようにする」という要望は、申請された見積もりの中で修正を指示する割合が少なく、修正内容のパターン化が難しいことから、対策を打たないことにした。

 改善要望を選別したら、対策を検討する単位を決める。複数の改善要望が、同一あるいは類似の対策で解決できることがあるためだ。

 例えば、「よくある商品の組み合わせにセット型名を付けて、一度に入力できるようにする」と「よくある商品の組み合わせを一括で入力できるようにする」はどちらも、「セット型名の単位で複数の商品をまとめて入力できるようにする」という対策で解決できる。

 また「見積もり申請」に対する改善要望「商品組み合わせチェックがOKの場合、その内容を引き継いで見積もり申請が行えるようにする」も、上記と類似した対策で解決することが可能だ。そこで、上記の3つの改善要望を「よくある商品の組み合わせにセット型名を付け、見積もり作成や見積もり申請にかかる工数を削減する」と集約し、まとめて対策を検討することにした。

この先は有料会員の登録が必要です。「日経SYSTEMS」定期購読者もログインしてお読みいただけます。有料会員(月額プラン)は初月無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら