【システム改修を考える】 既存業務をシステム化しよう～番外編～
これまで新システムの導入記事を時系列で書いてきました。今回は、その６記事目で触れた「システム改修」にフォーカスして書いていこうと思います。
システムの改修ってそもそもどんなもの？どんなときに改修を行う？そのために必要なことは？これは実際に社内交渉やシステム業者と打ち合わせの機会を持たないとなかなか想像が難しいでしょう。
私はここ２年ほどで新システムの導入に携わり、この経験を積むことができました。その経験をもとに本記事を書いています。
システムの改修で一番大切なことは、「一人のユーザーであっても、システム改修を進められることを知る」ということだと考えます。そして、改修すべき点や費用などのポイントを押さえることで、現実にシステム改修を進めることができるでしょう。
関連記事
既存業務をシステム化しよう①
既存業務をシステム化しよう②
既存業務をシステム化しよう③
既存業務をシステム化しよう④
既存業務をシステム化しよう⑤
既存業務をシステム化しよう⑥
既存業務をシステム化しよう⑦
（IT用語）既存業務をシステム化しよう
（システムの改修を考える） 既存業務をシステム化しよう
既存業務をシステム化しよう⑧
システム改修とは何か
そもそも改修って何？ということですが、何を「システムの改修」とするかは、見方や考え方、程度の認識により異なると思います。例えばボタンを押すと所定の用紙に必要事項が印字されて印刷する機能があるとします。その印字される項目の増減となるとプログラムの制御が必要なので、これは改修と呼べるでしょう。一方で、印字させる用紙の様式を一部変更する場合は、単に様式を差し替えるだけの作業になります。その作業は、様式の準備から設定された指定フォルダへの様式格納までユーザー企業側で行うこともできるでしょう。これらは改修とは呼ばないかもしれません。
この記事では大雑把に「組まれているプログラムの変更」をシステム改修と意識しています。
システム改修の流れ
改修の流れです。といってもそんなに大きなことではなく、考えてみれば当たり前のプロセスを踏みます。私は以下の８つをフローとして考えます。
①不具合、不便さを感じる
②不具合、不便さを周囲と共有する
③改修された場合の便益を明らかにする
④必要な改修を明らかにする
⑤改修後の業務フローを書きだす
⑥システム業者に見積もりを取る
⑦費用対効果を明らかにし、社内コンセンサスを得て、発注する
⑧納品されたシステムを検証する
このうち、重要なのは、④の必要な改修を明らかにすることと、⑦の社内コンセンサスを得ることでしょう。④はきちんと明らかにしていないとシステム業者に説明できません。システム業者に説明するにはある程度のシステム知識と、そのシステムで処理したい業務内容を知っておく必要があります。担当者レベルでは、どちらか一方しか把握できていないことが多いのではないでしょうか。しかしこの点が疎かになっていると、改修されたシステムが正しく動作しない可能性が高まります。自分自身が詳しくないもう一方を知る事や、双方を把握できる方の協力が必要です。
⑦は言うまでもありません。費用がかかるほど同意を得るハードルが上がります。
改修を考えるとき
ではどのような場面でシステム改修を検討するのでしょうか。
既存業務をシステム化しよう⑥ではシステム納品期での改修について書きました。以下、３点です。
①仕様書通りにできていない
②仕様書通りにできているが、変更したい
③仕様の認識違い
これは、あくまで納品時の改修事由です。特に、①仕様書通りでない、③使用の認識違い、を事由とした不具合（②、③の場合はユーザー企業側視点）は頻発します。これらの不具合解消は必ず必要で重要です。導入初期は検証回数を重ね、また本格稼働後の多種多様な操作によって起きることを記録し、不具合報告・改修・再検証が求められます。不具合が少ないなら検証の試行回数不足と言え、多すぎるなら要件定義が不十分であったか開発の問題を考えます。
そして使用期間が長くなるほど、これら①～③を減少していき、より改善や機能追加を目的とした改修へと変遷していきます。
本記事では、納品してある程度こなれた状態での、システム改修の検討について書いていこうと思います。
つまりシステムを、より便利に、より使いやすくするための改修です。
①不具合
②改善
③機能追加
の３点に分けて考えていきます。
改修①不具合
納品してシステムをある程度使いこなしていくとともに、不具合も解決されていき、エラーも減少していくと思います。一方でシステムに搭載されている機能は、毎日必ず使うものから月１回、年１回と用途により使用頻度が異なります。①不具合は、使用頻度が少なく不具合に気づくのが遅れたり、初めて試してみた使い方で期待した動作がされない場合のものを想定しています。
数年使っていても想定外のところで不具合が見つかった、というのもままある話です。年に何回かはこうした発見と改修がされています。納品当初は動作していても、その後の改修で別の動作に不具合が発生するケースもあります。こうした不具合に迅速に対応してもらうためにも。ベンダー企業の運用保守サポートは重要です。
この手の不具合はおおむね毎月の運用保守費用で賄われると想定できます。発見次第、すぐ改修に取り掛かるべきことがポイントです。
改修②現状改善
問題なく動作はするが、次にどの操作をすれば良いのか、ボタンの位置などがわかりにくい。正しく操作すれば間違いなく動くが、誤った操作をしてしまいそうなため、アラートなどのポカよけ機能が欲しい。そんな画面の操作性向上が②現状改善のイメージです。現状の業務を滞りなく、より効率的に遂行するために必要な改修です。
大きな改修ではなく、ちょったしたことで改善されることも多いため、保守費用の範囲内で対応してもらえることも多いです。
日々の業務担当者が手間やストレスを感じる部分で、業務の中で忙殺され、意見としては挙げられても、そのまま忘れられることもしばしば。リーダーはそうした現場の声を聞き流すことなく吸い上げて、細かい改善を進めていきたいですね。また、改善後に変わるであろう業務上のルールも検討していく必要があります。
費用は保守範囲内か、追加費用がかかる場合でも少額で収まるものが多いでしょう。その改修の必要性を明確にして訴求することで話を進めていければ、業務改善につなげることができるでしょう。小さな費用で大きな成果を出す改善は、高く評価されるべきです。
改修③機能追加
システム範囲外のデータ活用のため、毎月CSVでデータを出力しExcelで資料を作成していた。そうしたものを、システム機能に載せてしまい、手作業をなくす。こうした種類のものは機能追加と呼べるでしょう。新機能により、従来は別の方法で行っていたことをシステム上に追加し、機能向上を図ります。②では新たな機能を追加することを考慮していない点で違いがあります。程度でいうと③の方が大がかりで改修費用もより大きくまります。
しかし導入することで、膨大だった手作業が自動化され、間違いが減り、休日出勤や残業代削減につながる。利便性向上により、売上増加につながる。など大きな費用に見合う成果を上げられる機会となります。
新システムの二次開発、三次開発もこれに該当します。
③については、現場の意見だけでなく経営判断が必要なケースもあるでしょう。機能追加は売上向上につながったり、大きな費用削減につながるものでなくてはなりません。部門をまたいだ影響も考え、他部門を巻き込んで進めていきます。自社が提供しているサービスの付加価値そのものに関わることもあり、改修ハードルは先の二点より高くなります。
逆に、成し遂げることができれば社内での人脈が広がったり新たな知見を得る機会となるでしょう。
まとめ
システム改修について、書いてきました。
常に問題意識を持ち改善していく、そのための手段の一つがシステム改修です。
重要だと思うのは冒頭に述べた通り、深いIT知識がない「一人のユーザーであっても、システム改修を進められることを知る」ことです。ざっくり、企業から企業への発注にすぎませんからね。
不便だな、こうなったら使いやすいのにな、と感じることは日常的にあると思います。そこで止まらず、どう変わればより良くなるかを具体化させていきイメージを湧かせていきましょう。
システム改修は誰にでもできます。一方で誰にでもできることなのに、やらない人が多いのが社会というもの。そうしたことを成し遂げていくことで、自身の市場価値を高めていけるのではないでしょうか。
以上です。
この記事が気に入ったらサポートをしてみませんか？