ドキュメントを整理していたら我ながら良いこと書いてるなと思ったので、供養がてらシェアします。
主にiPaaSツールを使用した自動化を想定して原則を記載しています。
要件定義
原則1：依頼者の言うことをそのまま実現しない
-
理由
- 依頼者を喜ばせることが目的ではなく、全体の業務効率を上げることが目的。
- 依頼者は現行プロセスには詳しいが、効率的な業務設計には詳しいわけではない。
原則2：手動で運用を固めてから自動化する
-
理由
- 運用が固まらない状態での自動化は、仕様変更が頻発し、コスト増に繋がる。
- 運用設計から対応する必要があり、スキルも工数も高くつく。
原則3：「手動工数 × 反復回数 ≫ 自動化工数」を守る
-
理由
- 自動化の判断基準は、「継続的に発生する作業が自動化コストを上回るか」。
- 自動化には構築だけでなく、メンテナンスコストもある。
原則4：自動化前に業務プロセスを改善する
-
理由
- 自動化しても、元の業務プロセス自体が非効率だと、効果が出ない。
- プロセス改善により、そもそも自動化が不要になることもある。
原則5：長期的に使われない自動化はしない
-
理由
- 数回しか使わないものは、手動の方が安いことが多い。
- 後にプロセス変更が起きたとき、暗黙知化した障害になることもある。
原則6：自動化されたプロセスは暗黙知化しやすいと理解する
-
理由
- 時間の経過とともに処理内容を理解している人が減る。
- 条件分岐をシンプルに保ち、陳腐化しないドキュメントが必要。
原則7：工数は要件ごとに吟味する
-
理由
- 一つの要件を外すだけで工数が半分になることもある。
- 本当に必要な要件か、依頼者と確認を行う。
原則8：「便利だろう」で自動化しない、「どうしても」で自動化する
-
理由
- 「便利そう」で作ると使われないリスクが高い。
- 本当に困っている人と一緒に作ることで、無駄な開発を避けられる。
- 依頼者の要求が「便利」止まりではないか注意する。
運用
原則1：不要になったプロセスはすぐに停止・削除する
-
理由
- 暗黙知化すると削除判断が困難になる。
- 削除せず保管する場合は、
【サンプル】等の名前に変更し、意図を明示する。
原則2：未来の自分のために丁寧な仕事をする
-
理由
- 小さなコメントや簡易ドキュメントが、後の自分やチームを助ける。
- メンテナンスや引継ぎがしやすくなる。
原則3：依頼者にテストしてもらう
-
理由
- 実装者の意図と依頼者の目的が一致していないことがある。
- 要件に含まれていない仕様バグは、依頼者にしか気づけないことが多い。
- 修正は後になればなるほどコストが高くなるため、完成直後に確認を依頼する。