はじめに
社内SEとして仕事をしている中で、今回ひとつの業務改善システムを完成させることができました。
名前は、
「Project Comfort」
です。
もともとは、労務課が行っている健康診断の取りまとめ業務を少しでも効率化できないか、というところから始まったプロジェクトでした。
開発にはExcel VBAを使用しています。
ただ、完成した今振り返ってみると、
「Excelマクロを作った」
という感覚よりも、
「ひとつの業務システムを設計して、リリースまで持っていった」
という感覚の方が強く残っています。
今回はProject Comfortがどのように始まり、どのような機能を追加し、Ver1.5の正式リリースまでたどり着いたのかを振り返ってみたいと思います。
Project Comfortを作ろうと思ったきっかけ
健康診断の時期になると、労務課では各事業所の対象者を取りまとめ、Excelファイルを作成して配布します。
各事業所から回答されたExcelを回収した後には、その内容を確認しなければなりません。
しかも単純な入力確認だけではありません。
病院によって、
- 選択できる胃検査
- 健診内容
- 希望日の条件
- その他の予約条件
などが異なります。
そのため、担当者がExcelを一つずつ確認する必要があり、かなりの作業時間が発生していました。
そこで、
「この作業をシステム側でできるだけ自動化できないだろうか？」
と考えたのがProject Comfortの始まりです。
最初はExcel VBAによる業務効率化だった
最初から大規模なシステムを作ろうとしていたわけではありません。
まず取り組んだのは、
人事CSVから健康診断対象者を抽出し、各事業所向けのExcelファイルを生成すること。
ここから少しずつ機能を増やしていきました。
CSVプレビュー、検索、入力チェック、事業所別ファイル生成……。
一つ機能を追加すると、
「ここも自動化できそう」
「ここは利用者が間違えそう」
「エラーが起きたときに原因が分からない」
と、新しい課題が見えてきます。
そうしてProject Comfortは、単純なExcelマクロから少しずつ「システム」へ成長していきました。
Ver1.4でLogging Systemを実装
開発が進んでくると、正常に動作することだけでは不十分になってきました。
必要になったのが、
「何が起きたのかを後から確認できる仕組み」
です。
そこでVer1.4ではLogging Systemを実装しました。
ログレベルは、
- INFO
- WARN
- ERROR
の3種類。
正常終了だけでなく、キャンセルや異常終了についても記録します。
さらにErrorHandlerも整理しました。
このあたりから、自分の中でも「便利なマクロを作っている」というより、保守まで考えた業務システムを作っている感覚が強くなってきました。
Ver1.5でHospital Rule Engineを開発
Project Comfort Ver1.5の中心機能となったのが、
Hospital Rule Engine
です。
これは、各病院の健康診断予約ルールを自動判定するための仕組みです。
回収されたExcelファイルを読み込み、
- ファイル・シートを判定
- 入力内容をチェック
- 病院別ルールを判定
- エラー内容を入力チェック列へ統合
- チェック済みExcelを保存
- Logging Systemへ結果を記録
という流れで処理します。
特にこだわったのが、
利用者が確認する場所を増やさないこと。
Hospital Rule Engine専用の結果列を利用者に確認してもらうのではなく、既存の「入力チェック」列へ判定結果を統合しました。
そのため担当者は、
「入力チェック列を確認する」
という従来の考え方のまま利用できます。
UIも「使う人」を意識して作り直した
機能だけでなく、メニュー画面も改善しました。
回収ファイルをチェックすると、
- 状態
- チェック日時
- 対象者数
- エラー件数
- 正常件数
- 保存件数
が表示されます。
処理結果を消すためのクリアボタンも追加しました。
開発者にとって分かりやすい画面ではなく、
実際に操作する労務課のスタッフが迷わない画面
を目指しました。
労務課レビューへ
Ver1.5のRelease Candidateが完成したところで、実際に労務課のスタッフへレビューしてもらいました。
システム概要、Hospital Rule Engineのルール定義表、エラーチェック仕様書なども用意し、実際の画面を使ってデモを実施しました。
結果は、
大きな指摘事項なし。
軽微な修正を行えば、そのままリリースできることになりました。
ここまで作ってきたものが実際の利用者に受け入れられた瞬間は、とても嬉しかったです。
最後まで「現場の使い方」が仕様を作った
正式リリース直前にも、実際の運用を聞いたことで細かな仕様変更が入りました。
例えば事業所によっては、健康診断の希望を一度に全員分集めるのではなく、申告があった人から少しずつ労務課へ連絡していることが分かりました。
その際、
「この人は申告済み」
と分かるよう、氏名セルへ色を付けて管理しているとのこと。
そこでシート保護を見直し、氏名列については事業所側で操作できるようにしました。
また、備考欄についても読みやすいよう左揃えへ変更。
こうした細かな改善は、コードを書いているだけではなかなか気付けません。
実際に使う人の業務を知ることが、システム開発ではとても重要だと改めて感じました。
「マクロを作る」から「システムを作る」へ
今回の開発では、VBAそのもの以上に多くのことを経験できました。
要件整理、設計、共通化、UI、ログ、エラー処理、テスト、レビュー、仕様変更、リリース。
そして何より、
「この機能をどう作るか」ではなく、「利用者がどう使うのか」を考えること。
これが今回一番大きな学びだったと思います。
Project ComfortはExcel VBAで作っています。
しかし、使っている技術がVBAだからといって、単なるマクロではありません。
現場の課題を整理し、それを解決する仕組みを設計し、実際の利用者にレビューしてもらい、改善してリリースする。
一連の流れを経験したことで、
「業務システムを一本作った」
と感じています。
おわりに
Project Comfort Ver1.5は、無事にリリースできるところまで完成しました。
開発途中では、
「本当に完成するのかな……」
と思った瞬間もありました。
それでも一つずつ問題を解決し、期日までにリリース版を用意できました。
この経験は、社内SEとして今後システムを作っていくうえで大きな財産になったと思います。
そしてProject Comfortの本当の成果が分かるのは、これからです。
実際に使ってもらい、
「確認作業が楽になった」
と言ってもらえたら、このプロジェクトは本当の意味で成功だと思っています。
Project Comfortの開発はいったんここで一区切り。
そして――
次の業務改善プロジェクトも、すでに始まりつつあります。
