flowchart TB
    subgraph Before["❌ キューなし"]
        U1[👤 ユーザー] -->|待機中...| S1[システム]
        S1 -->|待機中...| E1[外部処理]
        E1 -->|やっと完了| S1
        S1 -->|結果| U1
    end

    subgraph After["✅ キューあり"]
        U2[👤 ユーザー] --> S2[システム]
        S2 -->|即座に| R[受付完了✓]
        S2 --> Q[(Queue)]
        Q --> W[バックグラウンド処理]
        W -.->|後で通知| U2
    end

    style Before fill:#ffebee
    style After fill:#e8f5e9
  

忙しいのは、システムが「今すぐ」を要求するから

経理の田中さんは、毎月20日になると憂鬱になる。

請求書の締め日だ。営業から上がってきたデータを確認し、システムに入力し、PDFを生成し、送付先を確認し、メールで送る。1件あたり5分。月に200件。単純計算で16時間以上。

でも実際はもっとかかる。

なぜか? システムが「今すぐ判断しろ」と迫ってくるからだ。

「この顧客の請求先住所、変更されていますが続行しますか?」 「PDFの生成に失敗しました。再試行しますか?」 「メールアドレスが無効です。修正して再送信してください。」

1つ1つは小さな確認だ。でもそれが100回、200回と積み重なると、田中さんの1日は「確認ボタンを押す作業」で埋まっていく。

これは田中さんが悪いわけでも、システムが壊れているわけでもない。

システムの設計が「人間を待たせる」構造になっていないだけだ。


キューを使わない世界:「電話応対」のような仕事

キューがない世界のシステムを、電話応対に例えてみよう。

電話は「同期的」なコミュニケーションだ。相手が話している間、こちらは待っていなければならない。保留にされたら、受話器を持ったまま待つしかない。

キューがないシステムも同じだ。

同期処理 vs 非同期処理の決定的な違い

❌ 同期処理(キューなし): 合計28秒拘束

    graph TD
    S1[👤 ユーザー] -->|請求書作成| S2[システム]
    S2 -->|顧客データ取得| S3[外部サービス]
    S3 -->|5秒待機...| S4[データ返却]
    S4 -->|PDF生成依頼| S5[外部サービス]
    S5 -->|20秒待機...| S6[PDF完成]
    S6 -->|メール送信| S7[外部サービス]
    S7 -->|3秒待機...| S8[送信完了]
    S8 -->|処理完了| S9[👤 やっと解放]

    style S1 fill:#ffcdd2,stroke:#c62828
    style S9 fill:#ffcdd2,stroke:#c62828
  

⏱️ 28秒間ずっと画面の前で待機 → 他の仕事ができない

✅ 非同期処理(キューあり): 0.1秒で解放

    graph TD
    A1[👤 ユーザー] -->|請求書作成| A2[システム]
    A2 -->|キューに登録| A3[(Queue)]
    A2 -->|受付完了 0.1秒| A4[👤 即座に解放]
    A4 -->|別の作業開始| A5[他の200件も登録可能]
    A3 -.->|バックグラウンド| A6[Worker]
    A6 -.->|処理完了後| A7[📧 通知]

    style A1 fill:#c8e6c9,stroke:#2e7d32
    style A4 fill:#4caf50,stroke:#2e7d32,color:#fff
    style A5 fill:#c8e6c9,stroke:#2e7d32
  

⏱️ 0.1秒で解放 → 他の仕事ができる

同期処理の問題点:

  • ユーザーが処理完了まで待機(28秒)
  • エラー発生時に即座に判断を求められる
  • タイムアウトすると最初からやり直し

非同期処理のメリット:

  • ユーザーは0.1秒で解放される
  • その間に他の200件の請求書も登録できる
  • エラーは自動リトライ、本当に必要な時だけ人間に通知

ユーザーが「請求書を作成」ボタンを押す。システムは顧客データを取得し、金額を計算し、PDFを生成し、保存する。その間、ユーザーは画面の前で待っている。

3秒で終われば問題ない。でも30秒かかったら? 3分かかったら?

そして途中でエラーが起きたら?

ユーザーは「今すぐ」判断を求められる。

  • 「タイムアウトしました。再試行しますか?」
  • 「一部のデータが取得できませんでした。続行しますか?」

この「今すぐ判断しろ」が、人間の仕事を増やしている元凶だ。

電話応対が疲れるのは、相手のペースに合わせなければならないからだ。メールなら、自分のペースで返信できる。その差は、1日に数十件の対応をする人にとっては決定的な違いになる。


キューを入れると何が変わるか:「メール」のような仕事になる

キューとは、**処理の依頼を「一旦預かる場所」**だ。

郵便ポストを想像してほしい。手紙を投函したら、あなたの仕事は終わり。届けるのは郵便局の仕事だ。届いたかどうかは、後で追跡番号で確認できる。

キューを入れたシステムは、こうなる:

    [図のイメージ]
ユーザー → システム → キュー →「受け付けました」→ ユーザーは自由
               バックグラウンド処理
                  完了したら通知
  

ユーザーが「請求書を作成」ボタンを押す。システムは「請求書を作ってください」という依頼をキューに入れる。ユーザーには「受け付けました」と返す。

ユーザーは待たなくていい。

PDFの生成には30秒かかるかもしれない。外部サービスとの連携で3分かかるかもしれない。でもユーザーは、その間に別の作業ができる。

処理が終わったら、システムから通知が来る。「請求書が作成されました。ダウンロードはこちら」

これが「メールのような仕事」だ。自分のペースで確認し、自分のペースで次のアクションを取れる。


本当に変わるのは「判断」の回数

キューを入れて一番変わるのは、実は処理速度ではない。

「人間が判断しなければならない回数」が激減する。

判断回数の劇的な削減

❌ キューなし: 200件処理で200回判断

    graph TD
    W_Start[200件開始] --> W_Loop[1件ずつ処理]
    W_Loop --> W_Error1[エラー発生<br/>👤 再試行?]
    W_Loop --> W_Error2[タイムアウト<br/>👤 続行?]
    W_Loop --> W_Error3[データ不整合<br/>👤 スキップ?]
    W_Error1 --> W_Next[次の処理へ]
    W_Error2 --> W_Next
    W_Error3 --> W_Next
    W_Next --> W_Loop
    W_Loop --> W_Result[結果: 195件成功<br/>5件失敗]

    style W_Start fill:#ffcdd2,stroke:#c62828
    style W_Error1 fill:#fff3e0,stroke:#f57f17
    style W_Error2 fill:#fff3e0,stroke:#f57f17
    style W_Error3 fill:#fff3e0,stroke:#f57f17
  

👤 判断回数: 約200回 | ⏱️ 拘束時間: 2時間 | 😫 ストレス: MAX

✅ キューあり: 200件処理で5回判断

    graph TD
    Q_Start[200件をキューに投入] --> Q_Quick[即座に受付完了]
    Q_Quick --> Q_Free[👤 別の作業へ]
    Q_Start -.-> Q_Process[バックグラウンド処理<br/>自動リトライ3回]
    Q_Process -.-> Q_DLQ[致命的エラーのみ<br/>失敗キューへ]
    Q_DLQ -.-> Q_Notify[📧 完了通知:<br/>195件成功 5件要確認]
    Q_Notify --> Q_Review[👤 5件だけ確認]

    style Q_Start fill:#c8e6c9,stroke:#2e7d32
    style Q_Free fill:#4caf50,stroke:#2e7d32,color:#fff
    style Q_Review fill:#c8e6c9,stroke:#2e7d32
  

👤 判断回数: 5回 | ⏱️ 拘束時間: 10分 | 😊 ストレス: 低

キューがない世界:

  • 処理の途中で問題が起きるたびに人間が呼び出される
  • 「接続がタイムアウトしました」→ 人間が再試行ボタンを押す
  • 「データが不整合です」→ 人間が確認して続行を選ぶ
  • 「外部サービスがエラーを返しました」→ 人間がどうするか決める
  • 200件処理で約200回の判断 = 確認作業員化

キューがある世界:

  • タイムアウト → 自動で再試行(3回まで)
  • 一時的なエラー → 少し待ってから再実行
  • 致命的なエラー → 「失敗キュー(DLQ)」に入れて、後でまとめて報告
  • 200件処理で5回の判断 = 例外処理のプロ

※ もちろん、キューを入れただけでこれらが自動化されるわけではない。リトライ処理やエラーハンドリングは別途実装が必要だ。ただし、キューという「一時的な退避場所」があることで、こうした仕組みを作りやすくなる。

人間が判断するのは、「自動では解決できなかったもの」だけになる。

これが「仕事が減る」の正体だ。100回の確認が、10回のまとめて確認になる。


エラーハンドリング戦略:システムが賢くなる

キューの真価は、エラーハンドリングの設計にある。

自動リトライとDead Letter Queue(DLQ)

    flowchart TD
    Start[メッセージ受信]
    Process{処理実行}
    Success[✅ 成功]
    TempError{一時的エラー?}
    RetryCount{リトライ回数}
    Wait[待機<br/>Exponential Backoff]
    Retry[キューに戻す]
    DLQ[(Dead Letter Queue<br/>失敗キュー)]
    Alert[📧 人間に通知<br/>まとめて報告]

    Start --> Process
    Process -->|成功| Success
    Process -->|失敗| TempError
    TempError -->|タイムアウト<br/>接続エラー| RetryCount
    TempError -->|致命的エラー<br/>データ不正| DLQ
    RetryCount -->|1回目| Wait
    RetryCount -->|2回目| Wait
    RetryCount -->|3回目| Wait
    Wait --> Retry
    Retry --> Process
    RetryCount -->|3回超過| DLQ
    DLQ --> Alert

    style Success fill:#4caf50,color:#fff
    style DLQ fill:#ff9800,color:#fff
    style Alert fill:#f44336,color:#fff
    style Wait fill:#2196f3,color:#fff
  

自動リトライの例:

  • 1回目失敗: 1秒待ってリトライ
  • 2回目失敗: 2秒待ってリトライ(Exponential Backoff)
  • 3回目失敗: 4秒待ってリトライ
  • 3回超過: DLQに移動 → 人間に通知

エラーの種類別対応:

エラー種別 自動対応 人間の介入
タイムアウト 自動リトライ3回 3回失敗後のみ
接続エラー 自動リトライ3回 3回失敗後のみ
データ不正 DLQに即移動 即時通知(まとめて)
権限エラー DLQに即移動 即時通知(まとめて)

人間の仕事:

  • リトライで解決できない「本質的な問題」だけを見る
  • 1日の終わりに「失敗リスト」をまとめてレビュー
  • パターンを見つけて恒久対策を打つ

業務システムでの具体例

例1:請求書の一括作成

    graph TB
    subgraph NoQueue["❌ キューなし: 2時間拘束"]
        NQ_Start[👤 200件処理開始]
        NQ_Loop[1件ずつ処理]
        NQ_Wait[⏳ 待機...]
        NQ_Error[❌ エラー発生]
        NQ_Human[👤 スキップ?再試行?]
        NQ_Repeat[次の件へ...]
        NQ_Done[完了<br/>195件成功 5件失敗]

        NQ_Start --> NQ_Loop
        NQ_Loop --> NQ_Wait
        NQ_Wait --> NQ_Error
        NQ_Error --> NQ_Human
        NQ_Human --> NQ_Repeat
        NQ_Repeat --> NQ_Loop
        NQ_Loop --> NQ_Done

        NQ_Note["👤 人間: 2時間画面前<br/>😫 判断200回"]
    end

    subgraph WithQueue["✅ キューあり: 10分だけ対応"]
        WQ_Start[👤 200件投入]
        WQ_Quick[✓ 受付完了 0.1秒]
        WQ_Free[👤 別の作業開始]
        WQ_BG[⚙️ バックグラウンド処理<br/>自動リトライ]
        WQ_Notify[📧 通知: 195成功 5失敗]
        WQ_Review[👤 5件だけ確認<br/>10分で完了]

        WQ_Start --> WQ_Quick
        WQ_Quick --> WQ_Free
        WQ_Start -.-> WQ_BG
        WQ_BG -.-> WQ_Notify
        WQ_Notify --> WQ_Review

        WQ_Note["👤 人間: 10分だけ<br/>😊 判断5回"]
    end

    style NoQueue fill:#ffebee,stroke:#c62828
    style WithQueue fill:#e8f5e9,stroke:#2e7d32
    style NQ_Note fill:#fff3e0
    style WQ_Note fill:#c8e6c9
    style WQ_Free fill:#4caf50,color:#fff
  

キューなし:

  • 200件の請求書を1件ずつ処理
  • 途中でエラーが起きるたびに画面に表示
  • 人間が「スキップ」か「再試行」か選ぶ
  • 2時間かかる(待ち時間 + 判断時間)
  • 判断回数: 約200回

キューあり:

  • 200件の請求書作成依頼をキューに投入
  • 「受け付けました」と表示(0.1秒)
  • 人間は別の作業へ
  • バックグラウンドで処理(エラーは自動リトライ)
  • 完了後「195件成功、5件要確認」と通知
  • 人間は5件だけ対処する(10分)
  • 判断回数: 5回

処理時間は同じかもしれない。でも人間が拘束される時間が圧倒的に違う。

例2:CSV/PDFの生成

大量データをCSVやPDFにエクスポートする機能。

    graph TB
    subgraph NoQueue["❌ キューなし: 3分間画面の前で待機"]
        NQ1[👤 エクスポートボタン] --> NQ2[データ抽出 1分]
        NQ2 --> NQ3[⏳ 画面固まる...]
        NQ3 --> NQ4[PDF生成 2分]
        NQ4 --> NQ5[⏳ まだ固まってる...]
        NQ5 --> NQ6[ダウンロード開始]
        NQNote["⚠️ ブラウザ閉じたら最初からやり直し<br/>⚠️ タイムアウトしたら最初からやり直し"]
    end

    subgraph WithQueue["✅ キューあり: 0.1秒で解放"]
        WQ1[👤 エクスポートボタン] --> WQ2[システム]
        WQ2 --> WQ3[(Queue)]
        WQ2 --> WQ4[📧 完了したら通知します]
        WQ4 --> WQ5[👤 別の作業開始]
        WQ3 -.-> WQ6[Worker]
        WQ6 -.-> WQ7[データ抽出 1分]
        WQ7 -.-> WQ8[PDF生成 2分]
        WQ8 -.-> WQ9[(ストレージ)]
        WQ9 -.-> WQ10[📧 ダウンロード可能<br/>24時間有効]
        WQNote["✅ いつでもダウンロード可能<br/>✅ 失敗しても自動リトライ"]
    end

    style NoQueue fill:#ffebee,stroke:#c62828
    style WithQueue fill:#e8f5e9,stroke:#2e7d32
    style WQ5 fill:#4caf50,color:#fff
    style NQ3 fill:#ffcdd2
    style NQ5 fill:#ffcdd2
    style NQNote fill:#fff3e0
    style WQNote fill:#c8e6c9
  

キューなし:

  • 「エクスポート」ボタンを押す
  • 画面がフリーズしたように見える
  • 「処理中…」のまま3分待つ
  • ブラウザを閉じたらやり直し
  • タイムアウトしたら最初から

キューあり:

  • 「エクスポート」ボタンを押す
  • 「完了したらメールでお知らせします」(0.1秒)
  • 別の作業をする
  • 5分後「ダウンロード可能になりました」とメール
  • いつでもダウンロード(24時間有効)

「待っている時間」がゼロになる。

例3:承認ワークフロー

経費精算の承認フローを考えてみよう。

キューなし的な設計:

  • 申請者が提出
  • 上長にメールで通知
  • 上長が承認画面を開く
  • その場でコメントを入力して承認

上長が忙しいと、申請はずっと「承認待ち」のまま。申請者は「いつ承認されるんだろう」とやきもきする。

非同期的な考え方を適用:

  • 申請者が提出
  • 「承認依頼」が上長のタスクリストに入る
  • 上長は自分のペースでまとめて処理
  • 申請者は進捗をいつでも確認可能

※ 注意:これは技術的な意味での「メッセージキュー」とは別物だ。ただし、**「依頼と処理を分離する」「即時の応答を求めない」**という設計思想は共通している。技術としてのキューを使うかどうかより、この「依頼を預けて、後で処理する」という考え方が重要だ。


よくある誤解:「キューを入れると複雑になる」

「キューを入れると設計が複雑になるのでは?」

この懸念はもっともだ。実際、何でもかんでもキューにすればいいわけではない。

でも、この誤解には2つの視点が抜けている。

誤解1:「シンプルな同期処理」は本当にシンプルか?

同期処理がシンプルに見えるのは、「うまくいっているとき」だけだ。

  • タイムアウト処理は?
  • エラー時のリトライは?
  • 途中で失敗したときのロールバックは?
  • ユーザーがブラウザを閉じたら?

これらを真面目に実装すると、「シンプルな同期処理」はどんどん複雑になっていく。

キューを入れると、こうした「異常系」の処理が整理される。「失敗したらキューに戻す」「3回失敗したら別のキューに移す」というシンプルなルールで対処できる。

誤解2:「複雑さ」はどこに行くべきか?

複雑さは消えない。どこかで引き受ける必要がある。

問題は、誰が引き受けるかだ。

キューがない世界では、人間が複雑さを引き受ける。エラーが起きるたびに判断し、例外的な状況に対処し、失敗したら手動でやり直す。

キューがある世界では、システムが複雑さを引き受ける。人間は「最終的な結果」だけを見て、本当に判断が必要なことだけに集中できる。

設計の複雑さが少し増えても、運用の複雑さが大幅に減る。この視点が大事だ。


なぜ業務システムでキューが効くのか

業務システムの特徴を考えてみよう。

  1. 大量のデータを扱う — 請求書200件、勤怠データ1000人分
  2. 外部連携が多い — メール送信、帳票生成、他システム連携
  3. エラーが「日常」 — データ不備、一時的な障害は当たり前
  4. 同じ作業の繰り返し — 毎月、毎週、毎日のルーティン

これらすべてに対して、キューは相性がいい。

  • 大量データ → まとめてキューに入れて、順次処理
  • 外部連携 → 失敗しても自動リトライ、人間を待たせない
  • エラー → 失敗分だけ後でまとめて対処
  • 繰り返し → 「依頼を入れたら終わり」で手離れ良く

逆に言えば、業務システムはキューと相性が良いケースが多い

「リアルタイム性が求められるシステム」にはキューは向かないこともある。でも業務システムの多くは、「今すぐ」ではなく「今日中に」「明日までに」で十分なことが多い。

その「今すぐじゃなくていい」を活かすのが、キューの本質だ。


まとめ:キューは「人間の時間」を守る技術

キューの本質は、非同期処理でも分散処理でもない。

**「人間の判断・作業を、適切なタイミングまで待たせられる構造」**を作ることだ。

これによって:

  • 人間は「システムの都合」で待たされなくなる
  • エラー対応が「その都度」から「まとめて」になる
  • 判断が必要な回数が激減する
  • 本当に頭を使うべきことに集中できる

経理の田中さんの話に戻ろう。

キューを入れたシステムなら、田中さんは「請求書200件を処理」ボタンを押して、別の仕事に取りかかれる。30分後に「195件完了、5件エラー」と通知が来る。田中さんが対処するのは、その5件だけだ。

200件を1件ずつ確認する作業が、「5件のエラーだけ対処する」作業になる。

これがキューの力だ。もちろん、実際にどれくらい効率化できるかはシステムの作り込み次第だが、「すべてを人間が見張る」構造から「例外だけ人間が対処する」構造への転換は、確実に負担を減らす。

技術的に難しいことをしているわけではない。ただ、「人間を待たせない」という設計思想を持っているかどうか。それだけの違いが、毎日の業務を大きく変える。

あなたの作っているシステムは、人間を待たせていないだろうか?


キュー導入判断フローチャート

    flowchart TD
    Start([処理の設計を検討])
    Q1{処理時間は<br/>3秒以内?}
    Q2{ユーザーは<br/>結果を待つ必要?}
    Q3{エラー発生<br/>頻度は?}
    Q4{大量データ<br/>処理?}
    Q5{外部サービス<br/>連携あり?}

    Sync[同期処理<br/>シンプルでOK]
    Queue[キュー導入<br/>を検討]
    MustQueue[キュー導入<br/>強く推奨]

    Optimize[まず最適化<br/>インデックス追加<br/>N+1解消]

    Examples["具体例:<br/>・請求書一括作成<br/>・PDF/CSV生成<br/>・メール一斉送信<br/>・データ集計<br/>・外部API連携"]

    Start --> Q1
    Q1 -->|Yes| Q2
    Q1 -->|No| Queue

    Q2 -->|Yes<br/>決済確認等| Sync
    Q2 -->|No| Q3

    Q3 -->|高い| MustQueue
    Q3 -->|低い| Q4

    Q4 -->|Yes<br/>100件以上| MustQueue
    Q4 -->|No| Q5

    Q5 -->|Yes| MustQueue
    Q5 -->|No| Optimize

    Queue --> Examples
    MustQueue --> Examples

    style Start fill:#e3f2fd
    style Sync fill:#fff3e0,stroke:#f57c00
    style Queue fill:#e8f5e9,stroke:#388e3c
    style MustQueue fill:#4caf50,stroke:#2e7d32,color:#fff
    style Examples fill:#e1f5fe,stroke:#0277bd
  

補足:キューを検討すべきサイン

以下の状況があれば、キューの導入を検討してみてほしい:

サイン 深刻度 キュー導入効果
「処理中…」の画面で30秒以上待つ ⚠️ 中 ユーザー解放
大量データ処理でタイムアウト 🔴 高 確実に完了
エラーの度に人間が判断 🔴 高 判断回数激減
「一括処理」で画面が固まる 🔴 高 バックグラウンド化
外部サービス連携で待ち発生 ⚠️ 中 非同期化
処理の「やり直し」が頻繁 🔴 高 自動リトライ

1つでも🔴があれば、キューを入れることで人間の仕事が大幅に減る可能性が高い。

技術の問題ではない。設計の問題だ。


実装のヒント:主要なキューシステム

キューを導入する際の代表的な選択肢:

クラウドマネージド

サービス 特徴 適用ケース
AWS SQS フルマネージド、無限スケール AWS環境、シンプルなキュー
Google Cloud Tasks HTTPエンドポイント呼び出し GCP環境、簡単な非同期処理
Azure Queue Storage Azureネイティブ Azure環境

セルフホスト

ツール 特徴 適用ケース
Redis + Bull/BullMQ Node.js向け、軽量 小〜中規模、Node.js
RabbitMQ 高機能、複雑なルーティング 複雑なワークフロー
Apache Kafka 超大規模、ストリーミング ビッグデータ、イベント駆動

シンプルな実装例(Node.js + BullMQ)

    import { Queue, Worker } from 'bullmq';

// キュー作成
const invoiceQueue = new Queue('invoice-generation');

// ジョブ投入(APIエンドポイント)
app.post('/api/invoices/bulk', async (req, res) => {
  const { invoiceIds } = req.body;

  // 200件をまとめてキューに投入
  await invoiceQueue.addBulk(
    invoiceIds.map(id => ({ name: 'generate', data: { id } }))
  );

  res.json({ message: '受け付けました。完了したら通知します' });
});

// ワーカー(バックグラウンド処理)
const worker = new Worker('invoice-generation', async (job) => {
  const { id } = job.data;

  // PDF生成などの重い処理
  await generateInvoicePDF(id);
  await sendEmail(id);

  return { success: true, invoiceId: id };
}, {
  connection: { host: 'localhost', port: 6379 },
  autorun: true,
  concurrency: 5, // 5件並行処理
  limiter: { max: 10, duration: 1000 }, // レート制限
  attempts: 3, // 自動リトライ3回
  backoff: { type: 'exponential', delay: 1000 }
});

// 成功・失敗の処理
worker.on('completed', (job) => {
  console.log(`✅ 完了: ${job.data.id}`);
  notifyUser(job.data.id, 'success');
});

worker.on('failed', (job, err) => {
  console.error(`❌ 失敗: ${job.data.id}`, err);
  saveToDLQ(job.data.id, err);
});
  

設計判断の背景

キューの導入は「技術的なかっこよさ」のためではなく、「運用する人間の負担を減らせるか」という観点で判断している。同期処理のほうがコードは単純になることが多いが、異常系を含めた全体の複雑さを考えると、キューを入れたほうが結果的にシンプルになるケースは多い。特に「エラー時に誰が対処するか」を考えると、システムに任せられる部分は任せるべきだと考えている。

現場での判断基準

「今すぐ結果が必要か」を最初に確認するようにしている。業務システムでは「今日中」「明日まで」で十分なことがほとんどで、その場合はキューが有効な選択肢になる。一方、ユーザーが画面の前で結果を待っている必要がある処理(決済完了の確認など)は同期で処理すべきだ。過去に「とりあえず全部非同期に」して、かえってユーザー体験を損ねた経験があり、それ以来「本当に非同期でいいのか」を意識的に確認するようになった。

見るべきポイント

レビュー時は「エラーが起きたときに誰が何をするか」を最初に確認する。同期処理でエラーハンドリングが「ユーザーにメッセージを表示して終わり」になっている場合、運用時に人間の手作業が増えるサインであることが多い。また、処理時間が読めない外部連携がある場合は、キューを検討する価値があるかを確認している。


関連記事