こんにちは、藤田です。
シリーズの締めとして、今回は開発の実装フェーズではなく、要件定義・設計・仕様調整・運用の準備フェーズで感じた小さな摩擦や思わぬ足止めの記録を残しておきます。
実装者として「コードを書く前に考えたり、整理したりする時間」って、思った以上にボリュームがありますよね。この回はそんな“前工程”に関する備忘録です。
⚙️要件定義と実務の“微妙なズレ”
-
業務側から受け取ったファイルと、実際の運用ファイルが数列だけ違っていた
→ 例えば受領データの郵便番号が「1234567」だったが、本番ファイルは「123-4567」。仕様を見直すと「ハイフン付きが正」で、PAD側と整形処理を1からやり直すことに。
小さい差だけど「これは仕様違反かどうか」の判断に思った以上に時間がかかり、「データ仕様のブレ幅」を初期設計時に想定しておくべきだったと反省しました。 -
CSV形式は“カンマ区切り”と聞いていたが、実際はタブ区切りだった
→ Access出力はカンマ前提で設計していたため、タブ区切りの本番データを取り込んだ際にSplit(lineText, ",")が機能せず。
フローとしては軽微な修正で済むが、「どこに何の定義があったか」「誰がこの形式を決めたのか」を確認するために少し社内を動く羽目になりました。
📄業務手順書が整備されていなかったことによる影響
-
「業務手順書を参考にしてください」と言われたが、実際は数年前のExcelで、最新の業務には対応していなかった
→ 処理順やロジックが古く、現行業務との乖離が大きかったため、結局ヒアリングで一から再構成。
こういう場面では、単に「作業指示書をください」よりも「現在、どうやって作業していますか？」と業務フローごと聞く方が正確で早いことに気づきました。 -
手順書の「1. Accessでデータ取得 → 2. Excelで整形」という記載が、実際は「Accessで3種類のデータを取得 → それぞれに整形方針が異なる」だった
→ 一括処理のつもりが、データ種別ごとに整形ルールを切り分ける必要があり、VBA側に条件分岐を追加するはめに。
このあたりは「工程の説明」だけでなく、「例外ケースや作業者による判断基準」まで聞いておくべきだったと痛感。
🧭仕様変更が“正式な変更”になるまでの時間
-
当初は“Accessのみ”の設計だったが、現場で「SQL Serverでも取得したい」と言われ、SQL連携を追加
→ 実装そのものはスムーズだったが、「どのテーブルか」「SELECT条件はどうするか」「SQL認証かWindows認証か」などの情報整理に数日。
「あとでSQLにも対応したいので拡張性を持たせてください」と言われるより、「SQL対応を正式要件として記述してもらう」方が動きやすかったなと感じました。 -
Accessの出力項目が1列追加されていたが、現場ではそれが“処理対象外”のつもりだった
→ つまり開発側としては整形処理対象に入れるつもりだったが、業務では「あの列は見ないから不要」とのこと。
結局、仕様書上の“全列出力”を「使う列だけ」の記載に修正 → 成形処理にも対応。
このように「実務では使わないけど出力には入ってる列」の扱いは、設計時に丁寧に確認しておかないと地味に齟齬が起きます。
🔐実行環境に関する“前提のズレ”
-
「タスクスケジューラでPADを定時実行します」と伝えたが、運用PCは夜間シャットダウンされていた
→ 一括フローは「朝6時に自動実行する」仕様だったが、実際にはPCが起動していない時間帯。
結局、朝8時に起動直後に自動実行されるよう設計変更。こういった「運用時の物理環境」確認はもっと早く聞いておくべきでした。 -
PADの一括フローはシステム管理者アカウントでしか動かなかったが、業務担当者は別ユーザーだった
→ バッチの実行権限やファイルパスの制約があり、手動起動でも失敗する事象が発生。
運用引き渡しの前に「誰がどの環境で動かすのか？」をしっかり詰めておく重要性を実感しました。
✨このフェーズで得られた実感と教訓
-
初期設計時は「PADとVBAをどう連携させるか？」だけを考えていたが、
実際は「その前後に何があるのか」「フローがどう広がるのか」「誰が使うのか」に思考を向ける必要があった -
“技術的な実装はスムーズでも、運用上の細かい前提がズレていると、その対応に時間がかかる”
-
「明確な仕様書が欲しい」と言いたくなる場面でも、「仕様は業務の現場にある」と捉えて、対話と確認を繰り返す方が早い
-
完全自動化を目指すなら「フローの完成」だけでなく「前提の保証」も含めた設計が必要
🧊まとめ
この蛇足回では、コードや処理ロジック以前に立ちはだかる、「業務設計・仕様整備・運用環境との折り合い」について記録しました。
どれも地味ですが、開発工数の多くがこのフェーズにかかってくるんですよね。
「PADとVBAで何を作るか」以上に、「どう運用するか」「誰が使うか」「どう整備されているか」が、開発の質とスピードを左右すると感じました。
今後、類似の業務自動化に挑む際には、このあたりも設計初期から意識して動いていきたいと思っています。