1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

問いからはじめるAWS 〜正解を探すな、Whyから始めよう〜

Last updated at Posted at 2025-11-22

はじめに

AWSをやっていると、誰もが一度は悩むと思います。「この構成、正しいのかな?」と。

ネットや社内の過去資料を見ても、答えはバラバラ。似たような要件でも、設計者によって構成が全然違う。

理由は簡単で、AWSには唯一の正解がないからです。同じ要件でも、重視するのがコストなのか可用性なのかで設計はまったく変わります。

そんな中で、現場で痛感しているのは、「答えを探すより、問いを立てる1ほうが大事」なのではないかということです。

「問い」を立てることが設計の出発点になる

設計をレビューしていてよく見るのが、手段から入っている構成。

たとえば「とりあえずマルチAZ」「とりあえずALB経由」。
でも、なぜそうしたのか?と聞くと、「そうすべきと聞いたから」という回答が帰ってきたり、明確な回答答えられなかったりする経験はないでしょうか。

大事なのは手段ではなく、その前の問いです。

  • Why(なぜ)この構成が必要なのか?
  • How(どうすれば)要件を満たせるのか?
  • What if(もし)前提が変わったら?

この3つの問いをきちんと丁寧に考えるだけで、設計の質は驚くほど変わるのではないかと思います。

タイプ AWS設計でよくある問い 得られる気づき
Why(なぜ) なぜマルチAZにするのか?
なぜECSでなくLambdaなのか?
背景要件が整理される。冗長化=目的ではない
How(どのように) どうすれば障害時に自動復旧できる?
どうすればコストを抑えられる?
サービス選定に根拠を持つことができる
What if(もし) もしトラフィックが10倍になったら?
もしリージョン障害が起きたら?
将来の変化を前提にした柔軟設計ができる

AWSの世界(だけには限りませんが)では、この問いの深さがそのまま設計の深さなります。

Well-Architected Framework

Well-Architectedレビューって、よくベストプラクティスと言われます。
ですが、W-Aっていわゆる「答え合わせのためのチェックシート」として使っていたりしませんか?ではなく、正確には問いのカタログであり、いわば設計品質を担保するための問答集と言えるのではないでしょうか。

Why-How Ladder で掘り下げる

たとえば「分析基盤をサーバレス化したい」という課題。
普通に考えると、「Glue使う?Athena?Redshift?」みたいに手段の話になりがちです。
でも、ここで“Why-How Ladder”を使うと全然違う展開になります。

レベル 問い 気づき
Why① なぜサーバレス化したいのか? 運用負荷・コスト削減が目的
Why② なぜ運用コストが高いのか? EC2常時稼働、スケールしない構成
How① どうすれば動的にスケールできる? Glue+Athena+Step Functions化。
How② どうすれば観測性を保てる? CloudWatch Logs+Application Signals
What if もしデータ量が10倍に増えたら? Iceberg+Redshift Serverlessも視野に

WhyHowを往復させるだけで、構成案が整理され、「なぜこの設計にしたか」を自信を持って説明できるようになります。

FinOpsの観点でも「問い」が効く

コスト最適化においても、「とにかく安く」という発想より、「どの価値を最小コストで実現するか」が本質です。

少し具体化してみましょう。

  • なぜこのインスタンスサイズ? → 利用率40%なら、AutoScaling+SP再検討
  • なぜこのワークロードは常時稼働? → LambdaやFargateでイベント駆動化できないか
  • なぜS3 Standard? → アクセス頻度を観察してIA/Glacier移行を検討
  • FinOpsはツールじゃなく「問いの連鎖」で成り立っています。

数字の前に、なぜこのようなコストが発生しているのかを問えるかどうかが分かれ目になるのではないでしょうか。

おわりに

クラウドの技術は日々アップデートされますが、問いの力はどの時代でも通用します。

  • 「なぜ」から始めると、設計がブレない
  • 「どうすれば」で、具体策が出る
  • 「もし」で、変化に強くなる

この3つを癖づけると、単に構築できる人から、設計を導ける人、本当の意味でのアーキテクトとして成長できるのではないでしょうか?

設計って、結局は選択の積み重ねです。その選択を支えるのが、問いの深さです。
サービスに対する知識は最低限として、「なぜこの構成なのか」を語れることの方がエンジニアとしての価値が高まると思います。

いつもこの問いの精神をわすれないようにダンプしてみました。

  1. https://ems.eireneuniversity.org/blog/the-art-of-questioning/

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?