AWS パートナー企業でテクニカルサポートに従事して2年経ったので思うところをまとめてみた

2024年4月6日に開催された JAWS-UG北陸新幹線 ( 福井開催 )で登壇した際の資料です。
AWS に限らず、テクニカルサポートへの問い合わせをする際に留意した方が良い内容など、私が日々業務をしていて感じていることをお伝えしたいと思います。
AWS を使いこなしている方から、これから利用しようとお考えの方の参考になれば幸いです。

＜4月15日追記＞
17スライド目のサブタイトル部分や21、28スライド目で「SLA」と表記している箇所は、正確には「応答目標時間（SLO）」とすべき箇所でした。
なんらかの登壇機会があれば正式に資料側を訂正したいですが、AWS サポートとしては SLA「は」存在せず「SLO」なので訂正させていただきます。

Transcript

1. AWS パートナー企業でテクニカルサポートに従事して 2年経ったので思うところをまとめてみた [JAWS-UG北陸新幹線] 株式会社サーバーワークス 市野 和明（JAWS-UG 関⻄） 2024-04-06
2. ⽬次 1. ⾃⼰紹介 2. 先に結論 3. お伝えしたいこと 4. まとめ
3. ⾃⼰紹介
4. 4 あらためまして 名前︓市野 和明（いちの かずあき） 所属︓株式会社サーバーワークス マネージドサクセス部 テクニカルサポート課 好きな AWS サービス︓ AWS CLI （テクサポとして） 嫌いな AWS サービス︓ Amazon FSx for Windows 趣味︓⾳楽鑑賞、酒を飲む @kazzpapa3
5. 先に結論
6. 6 解決スピードを上げるには︖ AWS Support として顧客に望むことはすでに公式⽂書に書いてある 少なくとも AWS に対して問い合わせをするロールの⼈は、まずは⽬を通しておくべき 技術的なお問い合わせに関するガイドライン https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines 問い合わせ⽂章は 5W2H を意識する 担当しているプロジェクトの全容について、 ペライチで良いので、簡単に説明できる資料があればベター 結局、急がば回れ
7. お伝えしたいこと
8. 8 ありえないだろう…、と思われるが、よくある問い合わせ例 > 今朝から AWS につながりません。 > 障害など起きていないでしょうか。
9. 9 は︖ > 今朝から AWS につながりません。 > 障害など起きていないでしょうか。 これは私が夢でみかけた⽂章 ある特定のお客様からいただいた⽂⾯そのままではない
10. 10 は︖ > 今朝から AWS につながりません。 > 障害など起きていないでしょうか。 ただ、多少誇張した妄想的な⽂⾯ではあるものの 100％ 妄想というわけでもない 本質的な部分では同質なお問い合わせをいただくことは、実は結構ある これは私が夢でみかけた⽂章 ある特定のお客様からいただいた⽂⾯そのままではない
11. 11 あの⽂⾯で（私が、かろうじて）読み取れること • AWS マネジメントコンソール⾃体か、 AWS で作成した何らかのリソースに対して接続できない状態が発⽣している︖ • 「AWS に繋がらない」の部分から
12. 12 あの⽂⾯で（私が、かろうじて）読み取れること • AWS マネジメントコンソール⾃体か、 AWS で作成した何らかのリソースに対して接続できない状態が発⽣している︖ • 「AWS に繋がらない」の部分から • すでに収束した事象に対して原因究明をしたい問い合わせではなく、 現在も継続中の事象に対しての問い合わせではないか︖ • 今朝から AWS に繋がらない ← 繋がらない時間帯があった。という書き⽅ではない点から推測
13. 13 あの⽂⾯で（私が、かろうじて）読み取れること • AWS マネジメントコンソール⾃体か、 AWS で作成した何らかのリソースに対して接続できない状態が発⽣している︖ • 「AWS に繋がらない」の部分から • すでに収束した事象に対して原因究明をしたい問い合わせではなく、 現在も継続中の事象に対しての問い合わせではないか︖ • 今朝から AWS に繋がらない ← 繋がらない時間帯があった。という書き⽅ではない点から推測 • ⽇本国内のお客様なので、「今朝」と記載されているのは、 私が思う今朝と同じ頃︖ • 7時 〜 9時すぎくらいまでの間あたりとか︖
14. 14 あの⽂⾯で（私が、かろうじて）読み取れること • AWS マネジメントコンソール⾃体か、 AWS で作成した何らかのリソースに対して接続できない状態が発⽣している︖ • 「AWS に繋がらない」の部分から • すでに収束した事象に対して原因究明をしたい問い合わせではなく、 現在も継続中の事象に対しての問い合わせではないか︖ • 今朝から AWS に繋がらない ← 繋がらない時間帯があった。という書き⽅ではない点から推測 • ⽇本国内のお客様なので、「今朝」と記載されているのは、 私が思う今朝と同じ頃︖ • 7時 〜 9時すぎくらいまでの間あたりとか︖ ただしこれらは、あくまで私の推測に過ぎない 聞かなわからん
15. 15 ツッコミどころは多いが… お客様に確認したいポイントは思いつく限り以下かと思われます。 • 接続できない対象は何︖ • AWS マネジメントコンソール︖AWS アカウント内に存在する何かのリソース︖ • 接続できないのは「誰もが接続できない」のか「特定のユーザーだけ」なのか︖ • 発⽣時間帯は︖ 今朝というアバウトな時間軸ではなく、明確に何時ごろ、という情報がほしい。 • さらに⾔うなら、⽇本時間ですよね︖という確認はしておきたい。 • 現在も継続中なのか︖収束しているのか︖ • 時間軸の話で⾔うなら「今回初めて」なのか「⼀定程度発⽣していた」のか、発⽣頻度の情報もほしい。
16. 16 ツッコミどころは多いが… お客様に確認したいポイントは思いつく限り以下かと思われます。 • 接続できない対象は何︖ • AWS マネジメントコンソール︖AWS アカウント内に存在する何かのリソース︖ • 接続できないのは「誰もが接続できない」のか「特定のユーザーだけ」なのか︖ • 発⽣時間帯は︖ 今朝というアバウトな時間軸ではなく、明確に何時ごろ、という情報がほしい。 • さらに⾔うなら、⽇本時間ですよね︖という確認はしておきたい。 • 現在も継続中なのか︖収束しているのか︖ • 時間軸の話で⾔うなら「今回初めて」なのか「⼀定程度発⽣していた」のか、発⽣頻度の情報もほしい。 確認したいポイントはいくつもある
17. ところで、AWS サポートにも SLA があります
18. 18 契約中のサポートプランと選択したケースの重要度に応じて… ⽬安となる初回応答時間の設定があります 「AWS サポート プラン⽐較」（ https://aws.amazon.com/jp/premiumsupport/plans/ ）より抜粋
19. 19 契約中のサポートプランと選択したケースの重要度に応じて… ⽬安となる初回応答時間の設定があります ただし、「合理的な範囲でできる限りの努⼒を」と記載のある通り、 「ベストエフォート」であることには注意が必要 「AWS サポート プラン⽐較」（ https://aws.amazon.com/jp/premiumsupport/plans/ ）より抜粋
20. 20 例えば ⽬安となる初回応答時間の設定があります ただし、「合理的な範囲でできる限りの努⼒を」と記載のある通り、 「ベストエフォート」であることにも注意が必要 エンタープライズプランを契約しているお客様で、 「ミッションクリティカルなシステムのダウン」を選択したときには、 おおむね 15分以内には初回の回答をもらえることとなります。 「AWS サポート プラン⽐較」（ https://aws.amazon.com/jp/premiumsupport/plans/ ）より抜粋
21. 21 ただし… ⽬安となる初回応答時間の設定があります ただし、「合理的な範囲でできる限りの努⼒を」と記載のある通り、 「ベストエフォート」であることにも注意が必要 ただし SLA は初回応答のみで、2ターン⽬以降には設定がない 「AWS サポート プラン⽐較」（ https://aws.amazon.com/jp/premiumsupport/plans/ ）より抜粋
22. ってことは︖
23. AWS サポートの初回ターンを 問い合わせ内容の再確認に費やすのは もったいない
24. 24 SLA の待機時間を待った挙句… 先ほどの問い合わせ⽂⾯を送信していた場合、 初回回答では⼀発で課題解決する回答を得られないであろうことは、ほぼ明確
25. 25 SLA の待機時間を待った挙句… 先ほどの問い合わせ⽂⾯を送信していた場合、 初回回答では⼀発で課題解決する回答を得られないであろうことは、ほぼ明確 「ツッコミどころは多いが…」のスライドで書いたような ヒアリング事項が初回回答として返ってくることは容易に想像できる
26. 26 SLA の待機時間を待った挙句… 先ほどの問い合わせ⽂⾯を送信していた場合、 初回回答では⼀発で課題解決する回答を得られないであろうことは、ほぼ明確 「ツッコミどころは多いが…」のスライドで書いたような ヒアリング事項が初回回答として返ってくることは容易に想像できる 前述の応答時間を待機して、ようやく得られた返事に ヒアリング項⽬しか書かれていない状況は寂しいものがありますよね。
27. 27 SLA の待機時間を待った挙句… 先ほどの問い合わせ⽂⾯を送信していた場合、 初回回答では⼀発で課題解決する回答を得られないであろうことは、ほぼ明確 「ツッコミどころは多いが…」のスライドで書いたような ヒアリング事項が初回回答として返ってくることは容易に想像できる 前述の応答時間を待機して、ようやく得られた返事に ヒアリング項⽬しか書かれていない状況は寂しいものがありますよね。 本番環境にクリティカルな障害が発⽣している場合であれば、 虚無感と落胆は相当のものだと思います。
28. 28 SLA の待機時間を待った挙句… 先ほどの問い合わせ⽂⾯を送信していた場合、 初回回答では、⼀発で課題解決する回答を得られないであろう 「ツッコミどころは多いが…」のスライドで書いたような ヒアリング事項が初回回答として返ってくることが想像できる 前述の応答時間を待機して、ようやく得られた返事に ヒアリング項⽬しか書かれていない状況は寂しいものがありますよね。 本番環境にクリティカルな障害が発⽣している場合であれば、 虚無感と落胆は相当のものだと思います。 （実際に AWS から⾔われるかどうかは別として） ヒアリング事項をまとめて SLA 時間内に初回応答しましたよね︖ あとは順次対応しますね。だと、もったいないですよね。
29. 結局のところ
30. 客観的に理解してもらえるように書く
31. 31 客観的に理解してもらえるように書く 結局のところ、これに尽きるのだと思います。
32. 32 客観的に理解してもらえるように書く 結局のところ、これに尽きるのだと思います。 障害や発⽣事象により緊急度や内容も違うが、 問い合わせへの逆質問の発⽣を極⼒減らしてやり取りのターン数を削減すること で、可能な限りスピーディな課題の解決につながると考えています。
33. では、どのように伝えようか
34. 34 そもそも、相⼿は誰なのか︖ 問い合わせを送る相⼿は、会社の中で隣にいる同僚や上司、あるいは取引先や協 業先などではなく、まったくの第三者である点が重要なポイントです。
35. 35 そもそも、相⼿は誰なのか︖ 問い合わせを送る相⼿は、会社の中で隣にいる同僚や上司、あるいは取引先や協 業先などではなく、まったくの第三者である点が重要なポイントです。 相⼿に対して理解を求めるにあたり、同じ⽂化圏にいない⼈が対象であるという 点で、ハイコンテクストな記述は避けるべきです。 社内の⼈間であれば知っているであろうことも伝えないと、 相⼿は知り得ないという点に注意が必要だと考えます。
36. 36 そもそも、相⼿は誰なのか︖ 問い合わせを送る相⼿は、会社の中で隣にいる同僚や上司、あるいは取引先や協 業先などではなく、まったくの第三者である点が重要なポイントです。 相⼿に対して理解を求めるにあたり、同じ⽂化圏にいない⼈が対象であるという 点で、ハイコンテクストな記述は避けるべきです。 社内の⼈間であれば知っているであろうことも伝えないと、 相⼿は知り得ないという点に注意が必要だと考えます。 そもそも、何も事情を知らない⼈に伝えるのだから、 本来、それ相応の労⼒がかかるはずです。
37. 37 そもそも、相⼿は誰なのか︖ 問い合わせを送る相⼿は、会社の中で隣にいる同僚や上司、あるいは取引先や協 業先などではなく、まったくの第三者である点が重要なポイントです。 相⼿に対して理解を求めるにあたり、同じ⽂化圏にいない⼈が対象であるという 点で、ハイコンテクストな記述は避けるべきです。 社内の⼈間であれば知っているであろうことも伝えないと、 相⼿は知り得ないという点に注意が必要だと考えます。 そもそも、何も事情を知らない⼈に伝えるのだから、 本来、それ相応の労⼒がかかるはずです。 > 今朝から AWS につながりません。 > 障害など起きていないでしょうか。 雑に投げては、伝わるものも伝わらないはずです。
38. 相⼿は何を知り、何を⾒られるのか
39. 39 簡単にですが、 AWS の利⽤者、AWS テクニカルサポート、そして、私が所属している企業の ようなパートナーの三者で、誰が何を知り、何を⾒られるのかを簡単にまとめて みました。 それぞれの⽴場で、⾒られる⾒られない、知っている知り得ないがあり、 それらについてはより意識して伝える必要があると考えられます。
40. 40 それぞれがどの情報にアクセスできるか、知りうるか 対象 AWS 利⽤者 （お客様） （私の所属企業のような） パートナー企業 AWS テクニカルサポート 設計背景や実装 ◦ 知っている × 知り得ない × 知り得ない 障害や事象の影響度 ◦ 知っている × 知り得ない × 知り得ない AWS マネジメントコン ソール ◦ 閲覧可能 ◦ 閲覧可能 ※⼀部例外あり1 × 閲覧不可能（閲覧しない） AWS で構築されたサーバ 内部のデータやログ ◦ 閲覧可能 × 閲覧不可 （ログインしない） × 閲覧不可 （ログインしない） AWS 物理基盤 × 閲覧不可 × 閲覧不可 ◦ 閲覧可能 1. サービスのポータルや操作画⾯の閲覧のために、IAM Identity Center によるユーザー管理となっているサービスの場合、その発⽣事象の閲覧ができない AWS サービスもある
41. 41 それぞれがどの情報にアクセスできるか、知りうるか 対象 AWS 利⽤者 （お客様） （私の所属企業のような） パートナー企業 AWS テクニカルサポート 設計背景や実装 ◦ 知っている × 知り得ない × 知り得ない 障害や事象の影響度 ◦ 知っている × 知り得ない × 知り得ない AWS マネジメントコン ソール ◦ 閲覧可能 ◦ 閲覧可能 ※⼀部例外あり1 × 閲覧不可能（閲覧しない） AWS で構築されたサーバ 内部のデータやログ ◦ 閲覧可能 × 閲覧不可 （ログインしない） × 閲覧不可 （ログインしない） AWS 物理基盤 × 閲覧不可 × 閲覧不可 ◦ 閲覧可能 1. サービスのポータルや操作画⾯の閲覧のために、IAM Identity Center によるユーザー管理となっているサービスの場合、その発⽣事象の閲覧ができない AWS サービスもある
42. 過不⾜のない問い合わせのために
43. 43 考え⽅の⼀例 「いつなにがどうした」を整理する⽅法としてよく使われている 5W1H の スキームに、もう⼀つ How Much を追加して 5W2H として整理してみました。
44. 44 考え⽅の⼀例 「いつなにがどうした」を整理する⽅法としてよく使われている 5W1H の スキームに、もう⼀つ How Much を追加して 5W2H として整理してみました。 あくまで、整理⽅法の⼀例ですし、私も書きながら「なにが」と「なにを」、 「なにに」をすべて What に詰め込めなくもないなぁと思ってしまったところ もありましたので、お客様組織内やプロジェクト内でアレンジいただいて良いか と思います。
45. 45 考え⽅の⼀例 「いつなにがどうした」を整理する⽅法としてよく使われている 5W1H の スキームに、もう⼀つ How Much を追加して 5W2H として整理してみました。 あくまで、整理⽅法の⼀例ですし、私も書きながら「なにが」と「なにを」、 「なにに」をすべて What に詰め込めなくもないなぁと思ってしまったところ もありましたので、お客様組織内やプロジェクト内でアレンジいただいて良いか と思います。 ガチガチに決めておく必要まではないけど、 プロジェクトの担当者ごとで差異が⽣まれないように、とか いざ障害が発⽣したときに、まごまごしなくていいように、 ある程度フォーマット化しておくといいよね、くらいに捉えていただけると幸い です
46. 46 5W2H の例 5W2H ⽬的 問い合わせ時の記載項⽬として考えられる事柄 When ・時間軸、頻度、継続の有無を伝える ・事象を観測できた⽇時 ・タイムゾーン ・観測した事象は１回のみか ・観測した事象は継続中か、収束しているか Where ・事象が発⽣している箇所を伝える ・事象が発⽣している AWS リソースの ID や ARN What ・何をした時に発⽣する（発⽣した） かを伝える ・すでに試してみていることがあれば 合わせて伝える ・＜How＞で伝える発⽣事象に対して、何をした時に発⽣ するのか。 あるいは何をした時には発⽣しないのか。 ・事象の解決を⽬的として、すでにやってみた⾏動はある か。 Who ・事象に関与する⼈物、モノ（操作主 体）の有無や詳細を伝える 上記の＜What＞に対し、関連するヒト・モノがあれば記載 する 例） ・操作主体（呼び出し元）としてのIAM ユーザーやロール ・操作主体（呼び出し元）としての Lambda など他の AWS サービス・リソース
47. 47 5W2H の例 5W2H ⽬的 問い合わせ時の記載項⽬として考えられる事柄 Why ・発⽣事象をなぜ問題視しているかを 伝える ・実装しようとしている背景を伝える ・発⽣している事象において AWS の不具合・不備を疑うに ⾄った理由を伝える ・構築中や検討中などで想定するゴールのイメージに対し て、設計意図を伝える How ・どのような症状かを伝える 発⽣している事象を記載する。 例） ・接続ができない ・操作不能となる ・〇〇という結果となることを想定しているが△△となる How Much ・影響度はどの程度か伝える 事象が発⽣していることの業務への影響（ビジネスインパ クト）を記載する。 定量的な記載であればより客観的に判断が可能になる 例） ・〇〇⼈のユーザーのアクセスを処理することができず、 〇〇円／⽇の損失がある
48. 5W2H それぞれのポイント
49. 49 When 時間軸、頻度、継続の有無を記載いただきたい点はもちろんですが、 AWS ではグローバルサービスということもあり、グリニッジ標準時/GMT（⼀ 部 太平洋標準時/PST）が利⽤されていることもあるため、意識齟齬を⽣まない ためにタイムゾーンを記載いただくとより良いと思います。
50. 50 Where, Who EC2 インスタンスの Name タグなど、タグの値は、同⼀の値を許容しうるため、 ⼀意に特定できる値としては適切とは⾔えません。 意識齟齬を⽣まないために、インスタンス ID や ARN など、⼀意となる値を使 ⽤することをお勧めいたします。
51. 51 Where, Who EC2 インスタンスの Name タグなど、タグの値は、同⼀の値を許容しうるため、 ⼀意に特定できる値としては適切とは⾔えません。 意識齟齬を⽣まないために、インスタンス ID や ARN など、⼀意となる値を使 ⽤することをお勧めいたします。 また、同様に意識齟齬を回避する⽬的で、お客様固有の俗称や略称の利⽤ （AWS が正式に⾏なっていない略称も含む）も避けることで、スムーズな共通 認識につながると考えます。
52. 52 Where, Who EC2 インスタンスの Name タグなど、タグの値は、同⼀の値を許容しうるため、 ⼀意に特定できる値としては適切とは⾔えません。 意識齟齬を⽣まないために、インスタンス ID や ARN など、⼀意となる値を使 ⽤することをお勧めいたします。 また、同様に意識齟齬を回避する⽬的で、お客様固有の俗称や略称の利⽤ （AWS が正式に⾏なっていない略称も含む）も避けることで、スムーズな共通 認識につながると考えます。 また、通信経路や登場⼈物の把握のために構成図などの補⾜資料を共有いただけ ると理解が早まる点もありますので、複雑な構成をとっているような場合や被疑 箇所を明⽰したいような場合に添えていただけると幸いです。
53. 53 Where, Who EC2 インスタンスの Name タグなど、タグの値は、同⼀の値を許容しうるため、 ⼀意に特定できる値としては適切とは⾔えません。 意識齟齬を⽣まないために、インスタンス ID や ARN など、⼀意となる値を使 ⽤することをお勧めいたします。 また、同様に意識齟齬を回避する⽬的で、お客様固有の俗称や略称の利⽤ （AWS が正式に⾏なっていない略称も含む）も避けることで、スムーズな共通 認識につながると考えます。 また、通信経路の把握に構成図を共有いただけると理解が早まる点もありますの で、複雑な構成をとっているような場合や被疑箇所を明⽰したいような場合に添 えていただけると幸いです。 余談ですが… SQL Server が関連するお問い合わせで RDS と記載されていた箇所を Amazon Relational Database Service と認識し対応していて、どうも話が⾷い違うな︖ と思ったところ、Windows Server リモートデスクトップサービス（RDS) のこ とだったと判明し、対応⽅針の変更を迫られた場⾯もありました。
54. 54 What, How 事象が発⽣する際の再現⼿順として記載いただくと良いと思います。
55. 55 What, How 事象が発⽣する際の再現⼿順として記載いただくと良いと思います。 AWS では（弊社でも）事象の再現性を確認して お客様固有の問題か否かの判断をしたり、回避⽅法の有無の⽬的で、 実際に検証を⾏う場⾯は多々あります。
56. 56 What, How 事象が発⽣する際の再現⼿順として記載いただくと良いと思います。 AWS では（弊社でも）事象の再現性を確認して お客様固有の問題か否かの判断をしたり、回避⽅法の有無の⽬的で、 実際に検証を⾏う場⾯は多々あります。 「やってダメだったから意味ないわ」と思わず、 やってみてダメだったことも添えていただけると検証項⽬からの排除できたり、 別観点を加えてもう⼀度やってみてほしいなどの観点につながり、 結果として迅速な課題解決につながると考えます。
57. 57 Why 予備知識のないテクニカルサポート担当側からは、 AWS マネジメントコンソールで発⽣している事象や設定は、 拝⾒する段階での事実（の集合体）でしかない側⾯があります。
58. 58 Why 予備知識のないテクニカルサポート担当側からは、 AWS マネジメントコンソールで発⽣している事象や設定は、 拝⾒する段階での事実（の集合体）でしかない側⾯があります。 設計の意図や⽬的（ゴールのイメージ）などの情報をいただいていることで、 現在の実装⽅針では実現できないと判明したことに対して、 代替案のご提⽰をすることが可能になる場合があります。
59. 59 How Much 前述の通り、初回応答時間はベストエフォートであるため、 同時に同程度の緊急度設定のサポートケースが上がってきた際に、 取捨選択が発⽣してしまう可能性はあると考えられます。
60. 60 How Much 前述の通り、初回応答時間はベストエフォートであるため、 同時に同程度の緊急度設定のサポートケースが上がってきた際に、 取捨選択が発⽣してしまう可能性はあると考えられます。 その際に、定量的な記載を⾏うことで、お客様のお困り度合いをより適切に、 かつ、より客観的な判断基準として相⼿に伝えることにつながると考えられます。
61. 61 How Much 前述の通り、初回応答時間はベストエフォートであるため、 同時に同程度の緊急度設定のサポートケースが上がってきた際に、 取捨選択が発⽣してしまう可能性はあると考えられます。 その際に、定量的な記載を⾏うことで、お客様のお困り度合いをより適切に、 かつ、より客観的な判断基準として相⼿に伝えることにつながると考えられます。 「このシステムが停⽌していることで〇千万円／⽇の機会損失となる。」 みたいな具体的な記載です。
62. 62 テンプレート化の⼀例 AWS サポート ご担当者様 いつもお世話になっております。〇〇と申します。 〇〇について確認させてください。 （〇〇で△△という事象が発⽣しています。） ・発⽣した⽇時・タイムゾーン、発⽣頻度、事象の継続性 ・環境について(リソースID等含む) ・事象を観測した経緯、発⽣までの⼿順 ・既に調査したこと、およびその結果 ・なぜこの設計となっているか （なぜ本問い合わせ⽬的を達成したいのか） ・緊急度、業務への影響度について（定量的に書く） --- 以上、よろしくお願いいたします。
63. まとめ
64. 64 解決スピードを上げるには︖ AWS Support として顧客に望むことはすでに公式⽂書に書いてある 少なくとも AWS に対して問い合わせをするロールの⼈は、まずは⽬を通しておくべき 技術的なお問い合わせに関するガイドライン https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines 問い合わせ⽂章は 5W2H を意識する 担当しているプロジェクトの全容について、 ペライチで良いので、簡単に説明できる資料があればベター 結局、急がば回れ
65. 余談
66. 66 回答・サポートに対する評価 AWS のサポートケースは、進⾏中の問い合わせであっても、 回答⽂⼀つ⼀つに５段階の評価をつけることが可能です。 サポートエンジニアに対するフィードバックとなるようで、可能な限り⼊⼒して あげると良いようなのですが、⽇本⼈的感覚で「普通＝★ ★ ★ ☆ ☆ 」ってつ けると、⽂化の違いで、割と低めの評価を与えていることになるっぽいです。 なので過不⾜なかったよ、なのであれば星５としてあげたほうが良いようです。