考え方
「利用者が困っていることだけを解決する」という対応を何年にも渡って続けていると、ツギハギだらけのメンテナンス困難なシステムが出来上がってしまう。できるだけ業務の本質（やりたいこと）を捉えて、それを実現するシンプルな業務フローとシステムを提供するという考え方で対応する。
進め方
- 該当業務の目的を聞く
- やってる本人も良く分かってないことも多いので、ヒアリングしながら一緒に考えるイメージ
- 業務フロー全体を聞く
- とりあえずヒアリングしながら箇条書きで
- エッジケース（特殊なケース）を聞く
- エッジケースを拾えていないと、〇〇のケースでは前のシステムを使う、といったダブルスタンダードが発生する可能性あり
- エッジケース専用の機能は複雑になるので作りたくない
- エッジケースもカバーできる、汎用的な機能の提供を検討する
- 多少使いにくくても、エッジケースは発生頻度が低いので、問題になりにくい
- 利用者の困っていることも聞く
- 現状困っていることは、できるだけ解決したい
- とはいえ、ここに引っ張られすぎるのは良くない
- as-isの業務フロー図を作成
- 大変だったら箇条書きでも
- to-beの業務フロー図を作成
- ECRSの原則
- 不要な業務の廃止（やらなくても良い業務はないか）
- 業務の統合（複数の業務を同時に実行できないか）
- 業務の整理（順番を返ることで効率的にならないか）
- 業務の簡素化（同じ結果をもたらすより簡素な方法）
- 優先順位
- 社内or社外のデファクトスタンダードツール
- 車輪の再発明はNG
- 例）GoogleForm、Google Spread Sheet、JIRA、tableau、salesforceなど
- 汎用的なツール
- 例）csvをinputに何らかの処理をしてcsvをoutputする、など
- git管理可能な専用ツール
- 普通のプログラミング言語で書かれたもの
- git管理不可能な専用ツール
- Excel VBA、GASなどは避けたい
- 開発
- トライアル
- 本番運用