既存業務をシステム化しよう⑥
６記事目となりました。業務改善の取り組みとして、ITを導入した事例の実体験を複数回に分けて書いています。この取り組みは現在進行形で進んでいる内容です。私自身の取り組みや振り返り、次に活かしたいことなども含めて書いていきます。今回は、納品したシステムの検証作業と、リリースに向けた準備です。
関連記事
既存業務をシステム化しよう①
既存業務をシステム化しよう②
既存業務をシステム化しよう③
既存業務をシステム化しよう④
既存業務をシステム化しよう⑤
既存業務をシステム化しよう⑥
既存業務をシステム化しよう⑦
（IT用語）既存業務をシステム化しよう
（システムの改修を考える） 既存業務をシステム化しよう
既存業務をシステム化しよう⑧
システム納品
期間にして１年半。やっと納品されました。ここまで長かった、と思う一方メイン業務担当の私はここからが本番とも言えます。
検証による不具合解消やUI向上のための改修依頼、実際にシステムが業務改善につががるように「うまく使う」ための工夫、自社社員、取引先への説明など目白押しです。
一方で社会情勢は活動自粛となっており、思うとおりに進めるのは困難を極めました。打ち合わせも対面からビデオ会議になっていますが、すでに納品フェースになっていたことは救いです。
検証開始
これまでの業務フローと同じことを新システムで試していくことが検証作業です。商品別、顧客の注文パターン別、などで進めていきます。
検証の目的は、不具合・バグの解消、UI向上のための改修です。
検証⇒不具合などの発見⇒改修の依頼⇒改修後の動作確認、となるため、不具合が発見された時点で、同じ条件での検証作業がもう一度発生することになります。
この検証作業にかける労力は多大なものがありました（というか今まさに進行中でくたびれています）。
主な理由は、①新システム検証以外の仕事との両立、②自粛期間による労働環境への対応、③不具合の多さ、です。③について、ベンダー企業の担当者はとても優秀な方と思っています。これまでの業務対応を可能な限り実現しようとしたため、複雑な機能要求だったことが要因でしょう。
改修のカテゴリ
改修は以下のようにカテゴリ分けできると考えます。
①仕様書通りにできていない
②仕様書通りにできているが、変更したい
③仕様の認識違い
①仕様書通りにできていない
文字通り、仕様通りのものとなっておらず、想定した動作とならないものです。「バグ」「不具合」と呼ぶべきものです。業務への支障が出るため、優先度は高いものとなります。
改修することはもちろんですが、発見することがより重要と思いました。そのためにも、検証作業の回数は上げていかないいけません。
②仕様書通りにできているが、変更したい
不具合・バグではなく、UI（操作性）の向上やシステム改善に近いものです。業務改善を目的に開発したシステムである以上、使い勝手が良いものでなければいけません。ユーザーは自社、顧客、委託先に分かれているため、自社のUI向上改修は最後となります。
③仕様の認識違い
仕様書の認識、解釈が発注側の自社と、開発側のベンダーで異なっていたことに起因する改修です。発注側の伝え方、あるいは機能要件確認の際に、十分詰めることができなかったことが考えられます。納品段階前ににモック画面での確認もしていたため、現状あまり発生しておらず、あっても影響範囲の少ないもので済んでいます。
しかし、この改修が出てしまうと、場合によっては追加費用も発生するでしょうから、③の不具合はかなり怖いものだと思います。
不具合は検証開始当初からあらゆる場面で見つかりました。ベンダー側の改修作業という面では、簡単に直るものから影響範囲の広いものまで分かれ、運用者側としては影響範囲が大きくとも業務上の支障があれば迅速な改修を求める場合もあり、パターンが多岐に渡ります。
改修作業終了後に、同じ条件での検証を行う必要があるため、発注者側、ベンダー側双方で高頻度の情報交換をすることになります。
これまでの要件定義から開発フェーズで協力関係をしっかり整えておけた点は良かったと思います。
連携テスト
既存データの取り込みや、運用開始後の自動連係のためのテストです。
データ取り込みは、前回記事に書いた移行データの用意はありましたが、テーブルの形や項目が異なるため、正しく取り込めていないものが散見されました。
パッチの動作タイミングも確認します。
セキュリティ診断
日本語では脆弱性診断とも言います。大きくアプリケーション診断とサーバー診断にわかれます。より重要なのは、スクラッチで開発したアプリの方で、費用も高く時間もかかるものでした。その間検証作業もストップしなければなりませんでした。
お知らせ文書の作成
実際にシステムを使うことになる社外の関係各位（委託先、顧客）へのお知らせ文書の作成です。社外向けの公式文書となるため、システム外のものではありますが、重要な業務項目です。
マニュアル作成
委託先、顧客、自社用に３通り作成します。
顧客向けが優先度は最も高いのですが、使う機能が限られるため、内容は委託先、自社に比べて薄くなります。
中小企業診断士の実務補習ではWordを使った診断報告書を作成するため、その経験は役立ちました。
自社の分は、システム外の業務も含めたもので作る必要があり、時間を要することから作成順序は一番最後となります。
以上、システム納品後の準備でした。対外向けお知らせ文書の作成などは、システム納品前から手をつけられたはずでしたが、迫られないと手が動かないものですね。
次回はいよいよ運用開始です。
旧来のAccessデータベースと二重に走らせることでリスク回避をしますが、逆に言えば二度手間作業ともなっており、引き続きの検証作業と合わせて進めるため、周囲からの協力と自身の時間捻出に腐心しました。
= to be continued ⇒
この記事が気に入ったらサポートをしてみませんか？