制約環境下における
業務日報テンプレート運用設計
Excel業務改善 ／ 業務設計
以下の例は、制約条件の多い環境下でのExcel業務日報テンプレート運用設計に関するものです。
内容的にはExcel関連ですが、主に「設計力」「業務改善力」「制約条件下での対応力」を示すことを目的としています。
これらはWeb作成においても重要なスキルであるため、ポートフォリオとして掲載します。
背景・前提条件
Microsoft365（オンライン版Excel）を利用した業務日報の運用において、以下の制約がある環境での対応が求められました。
- VBAが使用できない
- Power Automate / Office Scripts は権限上利用不可
- 既存の「原本テンプレート」は変更不可
- Excel操作に不慣れな利用者が多い
- オンライン運用が前提
- 私自身は一時的な関与で、長期メンテナンスを前提としない
その中で、毎日テンプレートをコピーして日報を作成する手間とミスを減らしたいという課題がありました。
課題設定
- 日報は1日1シートで管理されている
- 毎日原本をコピーして作成するのは非効率
- 自動化を入れすぎると、利用者が理解できず混乱する可能性がある
- 関数やリンクが残ると、流用時に正確性が損なわれる懸念がある
「便利すぎず、壊れにくく、説明不要で使える形」
をゴールに設定しました。
業務の分解（設計の考え方）
業務を以下の最小単位に分解しました。
- 対象月の日付を決める
- 土日・祝日を除外する
- 原本シートをコピーする
- 日付ごとのシートを作成する
- 完成した1ヶ月分のファイルをアップロードする
このうち、②～④は月初に1回やれば十分、日々の入力は完全手動でよいと判断しました。
設計上の判断と理由
全自動化を行わなかった理由
- 実行環境・権限が限定されている
- 利用者のITリテラシーが不明
- トラブル時に説明・復旧が困難になる
「月1回の作成だけを効率化し、日常運用は手書きに近づける」
設計を選択しました。
関数・リンクを使わなかった理由
- 他者へ流用された場合に意図せず壊れる可能性がある
- 日付や計算結果は確定値として残したい
- 印刷文化に近い安心感を保つため
結果として、生成後のシートはすべてテキスト入力のみという運用にしました。
祝日対応について
祝日は一時的に「祝日リストシート」を作成し、月次作成時の判断材料としてのみ使用しました。
- 日常運用には含めない
- 完成後は削除可能
- 会社側への説明や保守を不要にするため
自分が関与しなくなった後も、運用が破綻しないことを優先しています。
将来の拡張・差し替え余地
本設計は、Office Scripts・Power Automate・Python等による自動化へ差し替え可能な構造になっています。
「可能だからやる」ではなく
「必要になったら置き換えられる」
という判断を取りました。
この設計で重視したこと
- 制約条件を正確に読み取ること
- 利用者の理解コストを最小化すること
- 自分がいなくなっても使える形にすること
- 技術よりも運用の安定性を優先すること
使用技術・スキル
補足
この案件では「テンプレートありきの業務」にどう向き合うかという現場的な課題に対し、最小限の改善で最大の安定性を得ることを重視しました。
まとめ
業務では、ツールありきではなく制約条件を整理したうえで、壊れにくい運用を設計することを重視しています。
例えばExcel業務では、自動化できる部分とあえて自動化しない部分を分け、利用者が迷わず使える形を優先しています。
今回の具体例では、Microsoft365のオンラインExcel環境で、VBAや自動化ツールが使えない状況がありました。その中で、毎日日報シートを作る手間とミスを減らしたいという課題があり、月初に1ヶ月分をまとめて作成し、日々の入力は完全手動にする設計を行いました。関数やリンクはあえて使わず、他の人に流用されても壊れない形にしています。
全自動化も検討しましたが、権限や利用者スキルを考慮し、便利さより安定性を優先しました。自分が関与しなくなっても運用が破綻しないことを重視しています。
将来的にはOffice ScriptsやPythonなどで自動化できる構造ですが、現時点では「やらない」判断をしています。ただし、必要になれば処理部分だけ差し替えられる設計です。
現場では「作れること」より
「使われ続けること」を意識して設計しています。
つまり、制約の多い環境で、自動化と手作業の線引きを行い、壊れにくい業務フローを設計しています。月次作成のみ効率化し、日常運用は手入力に近づけることで説明不要・事故の少ない運用を実現しました。