プロンプトエンジニア　と　ググり方　に通じること。

LLMにはじまり、Qが昨年公開され　コンソール上でちょこちょこ使うようになり便利だなと思う反面、
上手い質問を投げて欲しい情報を得ることって「ググり方」の調べ方に並んで必要だなと思うこの頃です。

AWSでアーキテクチャをレビューしてと言われる時によく思うことを伝えたいと思った矢先、
プロンプトエンジニア　という、「うまく質問して、欲しい情報を得る」ノウハウを持つエンジニアのことをこう呼びますも大事だなと思いながらおそらく、皆がソースコードや設計ドキュメントをレビューする事前の準備も定義してあげると効率が上がるんじゃないかと思って情報共有させてください。

「全部見て」よりも「どこを特に見て欲しいかかいつまんで欲しい」と思ったり「言われないまま見た方がいい」

アプリでもインフラでも言えること含めて　
こういうのを書いておいて事前　チェックみたいなの前例にして欲しいなと思ったものです。

AWSで仕事で入るなら必ずビジネスプラン以上は入っておくことをお勧めするのですが「自分たちの工数考えたら調査します！よりもプランに入って　〜かもしれない　を頑張るよりも　QAを投げることのほう」が効率が良く感じます。
合わせて、　AWSでも　質問ヘルプの回答を欲しい情報として得るためのTipsが掲載されています。

　参考：　https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/

まずわからないながらに頑張った君たちへ、こんなことチェックしてみよう

今回クラウドを使うという要件や戦略は　どんなストーリーで説明を持っていこうとしていますか

　　- → クラウドにするとおしゃれだから。客がなにもいわずにクラウドだからは何か意図を作らないと破綻しやすいため。

ソースレビュー、ドキュメントレビューと同じ観点で見ていきます。　

　　- → 何を見てほしい。ゴールと要件を満たすための情報がありますか。誤字脱字レベル以外で　指摘すべきポイントはどこを見てほしいでしょうか。

本件で本当にやるべきことは何ですか　

→　RFPや　お客様要件によるリソースの使い分けを検討します。

何に重点を置いて設計をしますか　

→　セキュリティ、価格、パフォーマンス、復旧時間などの非機能は選択方法が様々になるので、目的によって検討観点を変えます。

ほんとに見てほしいところは何ですか。　

→　ドキュメントレビューと同じで、全体見る前に　聞きたいポイントをまず確認してご提案する。

いきなりこの構成図でいいか？　

→　目的を聞いてからいいか判断します。

この構成図の中で、やりたいことは何ですか。　

→　そのうえで　部分的にフォーカスして実装や利用理想すのベストを提案します。

全体的にみて　

→　セキュア、ログ・監視、運用、ロール管理、アプリケーションなどの実装ロジック実現、　非同期・同期、　サーバレス分離　などを　それぞれ見ていきますが、すべてを網羅できなくなるので　目的ごとに聞きながら確認します。

ベストプラクティスを教えてください　

→　やりたいことは何ですか。　と　注意してみてほしいところでのその構成はどこに書きましたか　。　（様々なリソースを組み合わせるときに目的のやりたいことと比べて検討します）

よくわからないからこれにしてみたはありますか　

→　よくある　LambdaにするかEC2にするかContainerにするか　（EKS,ECS,Fargate, 自前onEC2）、どれにするかで「めんどくさいので」「よくわからないので」　Lambdaにしました　みたいなやつ。

今回の案件は　リフトシフトなどではないでしょうか

→　７Rの柱という考え方があるので、そちらをベースに相談していきます。
　　（いきなり、移行やサーバレス化。リファクタリングをやろうとすると難易度が上がります）

ＳＬＡやコストや　クラウドにすることで変な価格が下がり升みたいな話にしていませんか

→　目的と使い方で安くもメリットも感じないになるため。

まとめ：

AWSで、DOP/SAPを最初に取ることになり　あとからPractionar の問題を読むことになったのですが　Pracの問題はとても大事なことがたくさん書いてある。（実は、最初は　入門低レベル試験だと軽視していた：すみません）

AWSがいう「責任共有モデル」にはじまり、さまざまなことを学ぶと「AWS リソースの機能以上に」　システムを設計することって大事だな。視点が変わるなと思ったことがあります。

・リフト・シフトする　
・ウェルアーキ
・取り急ぎ　システム構成図、見積もり妥当性、設計の妥当性　

ここ最近のAWSからのメッセージは、エンジニアおじさんにはとても刺さることが多いんです。皆も一つの参考になればと思います。　

2022年　re:inventでは　Kubernetes 部門のVPからの「たくさんのリソースが出て、技術者が追いつけないのは。焦る必要はなく。必要になった時にエンジニア皆が」

　　　　- 　　「選択肢」を提供する。

2023年夏には re:inforce でセキュリティ部門VPからのメッセージ　「どの部門にもどのチームにも　IT問わず、セキュリティを舞台を立てること」

「ガーディアンズ」を作ろう。

2023年 re:invent では、CTOが　Keynoteではなしていた、「コスト」を　非機能にいれて設計と運用を検討することがとても大事だ」という話。　

「フリューガルアーキテクト　と　７つのBizDevOps的な思想」

フルスタックを目指す皆で、フルスタックな世の中にしませんか。