1. 航海(後悔)日誌とは

過去の自分を振り返りながら、前進するための種を探す取り組みです。
当時の自分がどう理解していたのか。何が見えていて、何が見えていなかったのか。

今回は AWS Lambda を題材にしてみました。

2. 当時の理解

当時の Lambda に対する理解は「コンパクトで便利な実行環境」でした。

サーバーレスでインフラ管理が不要、必要なときだけ実行されて自動でスケールし、課金は従量制。特に サーバーを意識しなくていい(=運用負荷が下がる) という点に強く惹かれていました。

使うときは、

短時間処理にする
ステートレスにする
単機能に分割する
コールドスタートを考慮する

あたりを意識する。そういうサービスなんだな、という表面的な理解だったと思います。

3. 後から気づいたこと

今振り返ると、当時は「どう便利か」「どう使うか」しか見ていませんでした。「なぜそういう設計なのか」という視点が抜けていたのです。

Lambda には実行時間の制限があり、ステートレスが前提で、起動コストがあり、イベント駆動が中心になります。当時はこれらを単なる「制限事項」として見ていました。

でも今見ると、これは制限というより「スケーラブルに大量実行するための前提条件」だったんだと思います。ステートを持たないから大量に並列できる。短時間実行が前提だからリソースを制御しやすい。イベント駆動だから疎結合にできる。Lambda の設計そのものが、クラウド環境での運用課題への回答になっているのかもしれない。

当時はそこまで見えていませんでした。

4. 今感じていること

改めて感じたことは、様々なサービスは課題解決の結果として存在しているのではないか、ということです。

以前は「Lambda はこう使う」「SQS はこう使う」と、サービス単位で覚えようとしていました。今は、なぜそのサービスが必要だったのか、どんな運用課題があって、どの制約を解決したかったのかを考えるようになりました。

ベストプラクティスも同じで、以前は守るべきルールとして見ていましたが、その実は過去に起きた失敗の積み重ねの結果なのかもしれない、と思います。

こういう背景を探ると、個々の要素を立体的に繋げて整理しながら捉えられる気がします。

5. 視点の変化

「サービスを覚える」から「解決したかった問題を見る」へ、少しずつ視点が変化してきた気がします。

そうなると「このサービスは何ができるか」よりも「何を解決したかったのか」の方が気になってきます。サービス同士のつながりも見えやすくなって、Lambda、SQS、EventBridge、DynamoDB あたりが単体のサービスではなく、「分散システムをどう安定運用するか」という一つの文脈でつながって見え始めます。

6. 最後に

技術やサービスの背景、解決したかった課題といった視点が持つと、一段と理解が深まり、様々な要素が立体的に頭の中で繋がっていく感じがします。

生成AIが開発現場の在り方を変えている昨今において、個々のエンジニアが、より上流の抽象的な概念を扱う必要性が増しているとも感じます。

そんな中で、こういう背景に対する視点を持つことは、インプットや知識整理の効率を高めることに役立つかもしれません。