はじめに
職場にある神エクセルはどこか属人化しているケースが多いように感じます。
そのおかげで、他の人への引き継ぎが難しく、その人がいる限りは問題ないのですが、退職や異動が発生した際に大きな問題となります（仮に自分が作ったExcelだとしても、数式の可読性は低く、複雑になるにつれて、計算の元となる値を追うだけでも数時間かかることはざらにあるため、デバッグなども非常に大変です）。
また、ExcelのマクロやVBAは保守性が低く、バグが発生しやすいことも課題です。テストが書きにくいことも一因です。
今回は、スクラム的アプローチで段階的に移行を進める方法を検討しました。
どのようにDX化を進めるか
DXの進め方は色々あると思います。ただ、今回は少しずつ進める方向で検討をしたいと思います。
というのも、「完璧なシステムを作ろう」としてしまうと、開発が長期化する上に、現場のニーズに合わないシステムが出来上がる可能性があります。
そのため、すこしの機能からでよいので段階的に提供することが大事だと考えます。
そこで、使える考え方がスクラム開発です。
スクラム的アプローチで進める
スクラム開発は、価値の高い機能を優先的に開発し、短い期間でリリースを繰り返すことで、ユーザーのフィードバックを反映しながら開発を進める手法です。
その上で重要なのは先にテストコードを作成することや、Definition of Doneを明確にすることです。
スクラム開発は反復的に開発を進めるため、以前に開発したものは常に完成されている必要があります。Definition of Doneを定義しない場合、都度都度の品質がよくわからない状況になり、品質が下がり最終的におおきく出戻りが出てしまう可能性があります。
これは、ソフトウェアにおいては、テストがされていたり保守性が高かったりすることを意味します。
スクラムガイドはスクラムガイド | スクラムガイド日本語版を参照してください。
今回は、月次売上に関するエクセルについてDX化を進めるようにしたいと思います。
ケーススタディ：月次売上集計ExcelのDX化
Projectの例として、月次売上集計を行うExcelをDX化するケースを考えます。
現状把握
まず、現状のExcelの機能を把握します。
例えば、以下のような状態だとします。
- 部署より細かいチームごとに売上データを集計している
- 計算についてエクセルごとにマクロを組まれているが、チームが異なると計算方法も異なる
- 毎月月初に前月のデータを集計している
- データの入力ミスが多く、集計結果に影響が出ることがある
Definition of Doneの設定
上記の現状把握をもとに、Definition of Doneを設定します。
Definition of Doneは完成の定義で、いわゆる「これができたら完成」とする基準です。
特に、スクラム開発においては、各スプリントの成果物が完成していることを保証するために重要です。
今回は、以下のように設定します。
| 項目 | 基準 |
|---|---|
| 単体テストのカバレッジ | 80%以上 |
| チームごとに異なるフォーマットの売上データを読み込める | 〇 |
| 実データ以外については、ユーザーの入力含めてgitで管理される | 〇 |
| ユーザーが操作をするためのGUIが提供される | 〇 |
| 表のフォーマットについてハードコーディングしないで、ユーザーから設定可能にする | 〇 |
| 計算式についてハードコーディングしないで、ユーザーから設定可能にする | 〇 |
| 自動テストが実行されているる | 〇 |
| 実データの管理について認証認可がされている | 〇 |
上記の内容はあくまで一例です。
実際のDefinition of Doneを定義する際は、その後のProjectにおける品質にも関わるため、多く議論をして共通認識の取れる基準を設ける必要があると思います。
TODOリストの作成
次のように、TODOリスト（いわゆる、プロダクトバックログ）を作成します。
| PBI | 概要 | AC (Acceptance Criteria) | Story Point |
|---|---|---|---|
| GUI-000 | 初期画面 | GUIの外観を作成している | 2 |
| GUI-001 | 設定ファイル入力画面 | チーム設定をGUIで入力・表示できる | 3 |
| GUI-002 | データ読み込み設定・画面 | 売上データの読み込み、計算結果が確認できる | 5 |
開発をする
一つのTODOごとにPRを対応させていきます。
そして、その際に毎回Definition of Doneを満たしているかを確認します。
今回、実際にStreamlitやPandasを使って、生データはExcelで管理しつつ、計算はYAMLで管理し実行結果はStreamlitで表示するような仕組みを作成しました。
参考になれば幸いです。PRごとにDefinition of Doneを確認しています。
ステークホルダーからフィードバックをもらう
各スプリントの終わりに、ステークホルダーに対してレビューを行い、フィードバックを収集します。
これにより、ユーザーのニーズに合ったシステムを構築できます。
例えば、下記のような画面を用いたデモを行うなどのことを検討できる
まとめ
Excel業務のDX化は、段階的に進めることが重要です。
スクラム的アプローチを採用することで、ユーザーのフィードバックを反映しながら、価値の高い機能を優先的に提供できます。
また、Definition of Doneを明確にすることで、各スプリントの成果物が完成していることを保証できます。
ぜひ、今回紹介した方法を参考に、Excel業務のDX化を進めてみてください。
感想
- 今回、比較的簡単な内容（行ごとの計算のみで、認証認可などはなしで、データもファイルから直接読み込むもの）でコーディングをしましたが実際のExcelは複数Tableについて紐付けをしたり、複雑な関数を適応したりすることが多いように思えます。そのため、結局Pythonコードでどれだけテストを書いたとしても、結局複雑になりメンテナンスコストは上がってしまうように思えます。どのようにすれば、Excel業務をDX化できるかは非常に難しい課題だと感じます。
- また、そもそもExcelで管理しないと行けないものに対してアプローチを取りましたが、根幹としてどのように生データ（raw data）を管理しているかが極めて重要だと考えています。もし、すべてのデータについて共通のDBで管理されているのであれば、そこからクエリ文などを利用するだけで柔軟に実行・管理できます。ただ、ExcelやCSVで管理されている場合、そもそもデータの一貫性が保たれていないことが多く、そこを解決しないとDX化は難しいように思えます。