はじめに

エンジニアになったばかりの頃、私は「正常系」を中心に考えていました。

例えば、

• 入力値が正しい
• APIが正常に返る
• ファイル形式が正しい
• ネットワークが問題ない

という前提です。

実際、学習段階では「まず動かすこと」が重要なので、それ自体は間違っていないと思います。

ただ、実務に入ってかなり印象が変わりました。

実際のシステムでは、“想定通り”に動かないケースがかなり多いです。

例えば、

• ファイルが壊れている
• 必須項目が空
• APIタイムアウト
• 権限不足
• 想定外データ
• 一時的なAWSエラー

などです。

そして実務では、「正常系が動くこと」より、「異常時にどう壊れるか」の方が重要な場面があります。

今回は、実務を通して感じた「異常系を考える重要性」について書いてみたいと思います。

正常系だけでは実際かなり危ない

新人時代の私は、

「正常系通ったしOK」

と思っていました。

例えば、

data = response["Item"]

のようなコードを書いていました。

ただ実務では、想定通りデータが返らないことがあります。

例えば、

• Itemが存在しない
• APIレスポンスが空
• keyが無い
• Noneが返る

などです。

すると、

KeyError: 'Item'

のようなエラーになります。

最初は、

「なんでこんなこと起きるんだ？」

と思っていました。

しかし実際には、“正常系前提”でコードを書いていたことが原因でした。

実務では“想定外入力”がかなり来る

これもかなり驚いた部分でした。

新人時代は、

「入力チェックされているだろう」

と思っていました。

ただ実際には、

• 空文字
• None
• 型違い
• 文字化け
• 壊れたExcel
• 想定外フォーマット

など、かなり色々来ます。

特にCSVやExcel処理では、

「なんでこんなデータ入ってるんだ…」

というケースも多かったです。

例えば、

• 数値項目に文字列
• 郵便番号列に住所
• シート名違い
• 列不足

など。

実務では、“綺麗な入力”だけを前提にするとかなり危険でした。

AWSも普通に失敗する

AWSを触り始めた頃、私は

「クラウドだから安定している」

というイメージを持っていました。

もちろんAWSはかなり安定しています。

ただ実務では、

• 一時的失敗
• タイムアウト
• スロットリング
• 権限エラー
• 接続失敗

なども普通に発生します。

例えば boto3 を使っていると、

Unable to locate credentials

や、

AccessDeniedException

などのエラーもよく見ます。

最初はかなり焦りました。

ただ実務では、「失敗する前提」で考えることが重要でした。

そのため、

• retry
• exception handling
• ログ出力
• エラー通知

などもかなり大切になります。

異常系を考えると設計も変わる

面白かったのが、異常系を意識し始めるとコードの書き方も変わったことです。

例えば以前は、

result = func()

だけで終わっていました。

しかし実務では、

• funcが失敗したら？
• None返ったら？
• timeoutしたら？
• リトライ必要？
• rollback必要？

などを考えるようになりました。

すると自然に、

• try-except
• validation
• retry処理
• ログ出力

などを意識するようになります。

これはかなり実務で変わった部分です。

---

pytestを書いて異常系意識が強くなった

個人的に大きかったのがpytestです。

最初の頃は正常系しかテストしていませんでした。

ただ、実務では異常系テストがかなり重要でした。

例えば、

mock_s3.upload_fileobj.side_effect = Exception()

のようにして、意図的に失敗を発生させます。

これによって、

• ログ出力されるか
• エラー通知されるか
• retryされるか
• 処理継続できるか

などを確認できます。

実際、障害時は「正常系コード」より、「異常時どうなるか」の方が重要になることもあります。

pytestを書くようになってから、かなり異常系を意識するようになりました。

“壊れ方”を考えるようになった

実務でかなり印象が変わったのが、

「どう動くか」

だけではなく、

「どう壊れるか」

を考えるようになったことです。

例えば、

• エラー時に止まるのか
• 継続できるのか
• 一部だけ失敗するのか
• データ不整合起きないか

などです。

特に運用中システムでは、“中途半端に壊れる”のがかなり危険です。

そのため、

• エラー時どうするか
• どこまで処理続けるか
• 何を通知するか

も設計の一部なんだと感じました。

まとめ

新人時代の私は、

「正常系が動けばOK」

という考え方をしていました。

ただ実務では、

• 想定外入力
• AWS失敗
• タイムアウト
• データ不整合
• 外部サービス障害

など、“異常”がかなり発生します。

そして実際の運用では、

「正常時に動くこと」

だけではなく、

「異常時に安全に壊れること」

もかなり重要でした。

私自身も実務を通して、

「異常系を考える」

意識がかなり変わったと思います。

今では実装中でも、

「これ失敗したらどうなる？」

を自然に考える時間が増えました。

そして、それが実務ではかなり重要な視点なんだと感じています。