ポスト
目次
via pixabay.com
はじめに
こんにちは！入社2年目のエンジニアです。
最近、小規模の保守案件でプロジェクトリーダー（PL）を任せていただく機会がありました。
直近では、Salesforceのワークフロールールやプロセスビルダーの非推奨化に伴い、これらを標準の「フロー」へ移行する案件を担当しました。これまでは「仕様書通りに作って、テストでちゃんと動けばOK！」と思っていたのですが、PLとして他人の作ったフローやテスト結果をレビューする側に回り、「作った後も安全に動くか？」「他の人が見てもわかりやすいか？」という視点の大切さを痛感しています。
今回は、このフロー移行案件のテストレビューにおいて、先輩のサポートのもとで自身が見落としていた「ハードコーディング（ベタ打ち）のリスク」と、そこから学んだレビュー時のチェックポイントをご紹介します！
最近、小規模の保守案件でプロジェクトリーダー（PL）を任せていただく機会がありました。
直近では、Salesforceのワークフロールールやプロセスビルダーの非推奨化に伴い、これらを標準の「フロー」へ移行する案件を担当しました。これまでは「仕様書通りに作って、テストでちゃんと動けばOK！」と思っていたのですが、PLとして他人の作ったフローやテスト結果をレビューする側に回り、「作った後も安全に動くか？」「他の人が見てもわかりやすいか？」という視点の大切さを痛感しています。
今回は、このフロー移行案件のテストレビューにおいて、先輩のサポートのもとで自身が見落としていた「ハードコーディング（ベタ打ち）のリスク」と、そこから学んだレビュー時のチェックポイントをご紹介します！
1.レビューで指摘されてハッとした「レコードタイプIDのベタ打ち」
テスト実行時、一部の処理が想定通りに動かないエラーが発生しました。原因を調べたところ、フロー内で判定条件に使われているレコードタイプIDの値自体に誤りがあることが判明しました。
当時の私は、「正しいIDに打ち替えて、もう一度テストを通せば解決だ！」と考えていました。
しかし、先輩PLから「そもそもフローの中のハードコードを修正する必要がある」という指摘を受けました。
ただのIDの入力ミス修正で終わらせようとしていた私は、この指摘を受けてハッとさせられました。
しかし、先輩PLから「そもそもフローの中のハードコードを修正する必要がある」という指摘を受けました。
ただのIDの入力ミス修正で終わらせようとしていた私は、この指摘を受けてハッとさせられました。
ハードコードの問題点
ハードコーディングがもたらす問題点として、IDを直接入力する最大のリスクは、「テスト環境（Sandbox）で正常に動作しても、本番環境へリリースした際に確実に処理が失敗する」点にあります。
Salesforceの内部IDは組織（環境）ごとに異なる値が採番されます。移行元のワークフロールールやプロセスビルダーでID直打ちがされていた場合、それをそのままフローへ移植してしまうと本番リリース時に大きな障害につながります。
ハードコードの解決策
レコードタイプIDを直接指定するのではなく、フロー内で「レコードを取得」要素を使って DeveloperName（API参照名）を条件に動的に取得するか、カスタムラベルなどを参照する構成に修正します。
2. 初心者を脱出！レビューで気をつけたい3つのポイント
① ループの中で「更新や取得」をしていないか？
ダメな理由: 繰り返し処理（Loop）の中でデータベースに毎回アクセスすると、データ量が増えたときにSalesforceの制限（ガバナ制限）に引っかかり、本番環境で突然エラーが発生してシステムが落ちてしまいます。
対策: ループ内では「割り当て」を使ってデータを溜めておき、ループを抜けた後に一括で取得・更新処理を行う設計になっているか確認します。
②名前が「レコードを作成_1」のままになっていないか？
ダメな理由: 処理の名前をデフォルトのままやその時適当につけた名前で放置すると、後から別の人が見たときに何のための機能なのか解読不能になります。
対策: 未来の自分やチームメンバーがわかりやすいように、処理の目的や意図が明確に伝わる命名がなされているか、主要な分岐点に説明が記述されているかをチェックします。
③エラーが起きたときの「逃げ道」があるか？
ダメな理由：システムエラーや入力値の不整合が発生した際、障害パスが定義されていないと処理が異常終了し、利用者に不適切なエラーが表示されたり、ログが残らず原因究明が困難になります。
対策：データベース操作を行う要素に「障害パス（Fault Path）」が引いてあり、管理者へのエラー通知や適切な画面表示が行われるか確認します。
3.実践している確認プロセス
単に「テストが通ったか」だけでなく、「リリース後も安全か」という視点を持つために、以下の2つを意識し始めました。
「本番環境に持っていったらどうなる？」と想像する
Sandbox環境で動いたとしても、「リリース後も安全か？」「大量データでも大丈夫か？」と一歩引いて考えるクセをつけています。
チェックリストを使って確認する
指摘された部分はチェックリストにして、個人の感覚や思い込みに頼らず抜け漏れがないように確認しています。
・IDや特定文字列のベタ打ちがないか？
・ループの中に「取得・更新・作成」が入っていないか
・要素や変数の名前がデフォルトのまま放置されていないか？
・エラー発生時の「障害パス」が考慮されているか？
・ループの中に「取得・更新・作成」が入っていないか
・要素や変数の名前がデフォルトのまま放置されていないか？
・エラー発生時の「障害パス」が考慮されているか？
おわりに
新卒2年目で最初は「とにかく案件を予定通りに進めないと」と目の前の作業で必死でした。
ですが、今回のフロー移行案件で先輩から指摘を受けたことで、レビューとは単なる作業確認ではなく「リリース後の障害リスクを防ぎ、未来の自分やチーム、そして本番環境の平和を守るための予防策」だと気づくことができました。
Salesforceのフローは手軽に作れるツールだからこそ、裏側の仕組みや安全性まで目を配れるエンジニアを目指して、これからも頑張りたいと思います！
最後までお読みいただき、ありがとうございました。
この記事が少しでもお役に立てば嬉しいです。
ですが、今回のフロー移行案件で先輩から指摘を受けたことで、レビューとは単なる作業確認ではなく「リリース後の障害リスクを防ぎ、未来の自分やチーム、そして本番環境の平和を守るための予防策」だと気づくことができました。
Salesforceのフローは手軽に作れるツールだからこそ、裏側の仕組みや安全性まで目を配れるエンジニアを目指して、これからも頑張りたいと思います！
最後までお読みいただき、ありがとうございました。
この記事が少しでもお役に立てば嬉しいです。
38 件
