既存業務をシステム化しよう⑧ 報告会
これまで、業務改善の取り組みとして、ITを導入した事例の実体験を綴ってきました。私自身の取り組みや振り返り、次に活かしたいことなども含めて書いてきています。
このシリーズ本編は今回で最後の記事になると思います。というのも来月に人事異動で業務部門を離れ、営業部門へと異動になったからです。
今回の記事は報告会です。システム納品により当初のシステム開発にかかる契約が完了となることから、ベンダー企業側からの要請で開催されました。
ここ３か月はWeb会議で定例会を開催していましたが、最後なので直接訪問を受けての開催となりました。
関連記事
既存業務をシステム化しよう①
既存業務をシステム化しよう②
既存業務をシステム化しよう③
既存業務をシステム化しよう④
既存業務をシステム化しよう⑤
既存業務をシステム化しよう⑥
既存業務をシステム化しよう⑦
（IT用語）既存業務をシステム化しよう
（システムの改修を考える） 既存業務をシステム化しよう
既存業務をシステム化しよう⑧
報告会概要
開発時期
最初のキックオフからリリース前日までを期間として報告されました。ベンダー側としての反省点は要件定義に大きく時間を取られてしまい、設計に時間を取れないまま実装となったことが多くの不具合につながった、ことが挙げられました。コロナの影響でリリースを後ずれしたことは開発側としては都合が良くなったということも正直に話してくれました。
セキュリティ診断やサーバーの設定は外部委託をしたことでスムーズに遅滞なく進んだことも報告されました。
スケジュールは、確認作業を怠っていた点があり、しっかりPMとしてグリップしておくべきだったことが報告されました。一方それは発注側である自社でもあるべき機能の決定に時間をかけすぎてしまったことの裏返しとも言えます。
自社における、責任リスクを負った決定、いつまでに決めるのか、そのための時間を捻出してきたか、などは反省点でした。
毎週、長い日は６時間も定例会で大きく時間を割きましたが、より関係性を強めて現場業務の調査を詳細に詰めていく必要があったのだと思います。
納品物（成果物）の確認
主に依頼した機能についての簡単な確認です。途中で変更になったり追加・二次開発行きになった項目も確認しました。振り返ると非常に多くの機能を盛っており、実務でしっかりと使いこなす体制整備がこの先は求められます。
不具合件数と区分け
納品後に報告されたエラーについての確認や反省点です。受け入れ時に100超、テスト時に70件、リリース後に60件ほどのバグ・エラーが確認され、さらにそのうち30件は仕様変更でした。これは要件定義に時間を取られ。障害・品質テストを強化できなかったことが要因です。仕様変更は、要件の詰めの甘さだった点とも指摘がありました。
確かに感覚としてエラーは多いという印象でした。検証回数を重ねていないのにも関わらず、多くの不具合と遭遇したためです。説明を聞いて納得しました。さらに隠れたエラーがあることも予想されますが、発見の都度報告し修正を進めることが求められます。
今後について
初期開発ではリリースしきれなかった機能が二次開発に回っています。機能そのものは確認できており、細かい内容の詰めや金額が焦点になります。
初期開発の反省を活かすなら、少し長めのスケジュールを組み、要件の詰めをしっかり行い進めていくことが好ましいと思います。追加機能であるので、ある程度開発には余裕を持てるはずです。
終えてみて
報告会をやってくれるベンダーがどれだけいるのか、という点では「これまで委託してきた業者の中にしっかりと報告完了会を開催してくれた業者がいなかった」ということでした（役員談）。開発や各種対応を含めて、良いベンダーに発注できたのだなと素直に思えます。
アサインされたPMやリーダー、プログラマー陣も優秀な層を揃えてくれたという印象も強かったです。
納品後の運用保守、改修のスピードも素晴らしく、良いパートナー企業だと思っています。
異動
残念ながら、７月から人事異動でこのプロジェクトからは外れます。このシステム化の取り組みには、業務担当としてベンダー探しから１年半携わってきました。納品された業務システムをしっかりと運用に乗せるためには、丸１年は必要と考えていたので、「いざ使う」フェーズで外れるのは心残りでもあります。
一方で完成品の納品まで見届けることができたのは、非常に良い経験となりました。
IT化による大型の業務改善に主要人員として参加したことは、この先どんなIT化に取り組む際も役立つものと思っています。
ブログで書いてみて
時系列で書いてきた分、まとまりはなかったかもしれません。
しかし文章に書き起こすことで振り返りの効果は大きかったように思います。
振り返る中で、「書けない内容＝知識がない部分」も明らかになったと思います。システム開発を外注する側としてあるべき姿、最低限押さえておくべき知識も考えるきっかけとなりました。
中小企業診断士試験では経営情報システムという科目があり、それなりの高得点でしたが、それでも今回のようなシステム開発に役立つ知識はごくわずか、ということも体感できました。必要なのは知識だけでなく現場での経験、ということも記事を書きながら振り返れた点です。
以下は、担当者として関わる際に参考にした書籍です。特に１冊目の「図解でよくわかる ネットワークの重要用語解説」は辞書のように片手に置いていました。
また、テーマ絞った記事は書いていきたいと思います。
以上です。
この記事が気に入ったらサポートをしてみませんか？