2023年振り返り
2023年振り返り。 仕事で新しいポジションについたり、勉強を頑張ったり、日本各地を旅したりした。 そういえば5月で30歳になった。
プロジェクトの責任者になった
仕事で開発しているプロダクトの責任者的なポジションになった。主にバックエンド・インフラ部分を任されていて、今年は手を動かして実装するというよりは、コードレビューしたり、ヒアリングしたりの時間が多くなった。
開発フローや組織の成長に目が向いた
今までより視野が広がり、プロジェクト全体の開発フローや手法に目が向くようになった。ペア/モブプログラミングの導入やMTGの改善を主導していった。 経験が浅いメンバーの育成、チーム力の向上を頑張っていこうと意気込んでいたが、頭を悩ませる日々だった。
AWS認定試験12資格に合格した
2022年の9月に受け始めたAWS認定試験、すべて合格できた。AWSについて好きになった一方、まだまだ深掘りする必要があると思っている。
オフラインの集まりの良さを知った
今年はカンファレンスや技術コミュニティなど、オフラインイベントに参加した。人の集まりの熱気を感じることができて良かった。
転職活動を行った
人生2回目の転職活動だった。前回は未経験から異業種転職だったので右も左も分からずだったが、今回は少し落ち着いた活動ができたと思う。 準備不足だったりが露呈することもあり序盤は苦戦したが、カジュアル面談などを有効活用し、良いご縁に巡り会えた。2024年3月から新しい環境で働く予定。
関東IT健保の保養所に行った
- トスラブ箱根和奏林
- トスラブ箱根ビオーレ
- トスラブ湯沢
宿泊費が安く料理も安い。来年1月にトスラブ館山に行く予定なので、これでトスラブの名がつく施設はコンプリートする。 （2月にトスラブ箱根和奏林・トスラブ箱根ビオーレも行く予定）
気づけば旅を繰り返していた
- 佐賀（1月/2月/4月/5月/6月/8月/9月/11月/12月）
- 福岡（1月/5月）
- 高松
- 熊本
- 松本
- 函館（6月/9月/11月/12月）
- 京都
- 高崎
- 仙台
- 金沢（9月）
- 富山（9月/12月）
- 越後湯沢
- 新潟
- 弘前
- 青森
さすがに佐賀に居すぎた感は否めない。
エンジニアが「プロダクトマネージャーのしごと」を読んで
職種的にはエンジニアの自分ですが、プロダクトマネージャーの仕事という本を読んでみました。プロダクトマネージャーのことについて書かれている本なのですが、エンジニアにとっても響く内容が多く、読んでとても良かった！という感想です。
目次
- 1章 プロダクトマネジメントの実践
- 2章 プロダクトマネジメントのCOREスキル
- 3章 好奇心をあらわにする
- 4章 過剰コミュニケーションの技術
- 5章 シニアステークホルダーと働く（ポーカーゲームをする）
- 6章 ユーザーに話しかける（あるいは「ポーカーって何？」）
- 7章 「ベストプラクティス」のワーストなところ
- 8章 アジャイルについての素晴らしくも残念な真実
- 9章 ドキュメントは無限に時間を浪費する（そう、ロードマップもドキュメント）
- 10章 ビジョン、ミッション、達成目標、戦略を始めとしたイケてる言葉たち
- 11章 「データ、舵を取れ！」
- 12章 優先順位づけ：すべてのよりどころ
- 13章 おうちでやってみよう：リモートワークの試練と困難
- 14章 プロダクトマネージャーのなかのマネージャー（プロダクトリーダーシップ編）
- 15章 良いときと悪いとき
- 16章 どんなことでも
ベストプラクティス
ベストプラクティスは「汎用的な解決策として扱ってはいけない」ことを主張されていました。
- ベストプラクティスを確率した環境では試行錯誤してその形が生まれたことを忘れてはいけない。
- ただ取り入れるだけ、ではうまくいかないのは当たり前であること。
- 一方で、ベストプラクティスの素晴らしい点は、組織にポジティブな変化をもたらす最初のステップになり得ること。
- 取り入れたあと、検証して改善していけば意味があるものになる。
本書で一番響いた箇所がベストプラクティスについての言及でした。ベストプラクティスをまず考えることは多いのですが、どこかそれに頼り切ってしまっている自分に気づき、本書に書かれている意識を持って今後接していこうと思いました。
「なぜ」を使わずに理由を尋ねる
「なぜ」を問うのがプロダクトマネージャーの仕事だが、それをやりすぎると聞かれた側の不安を増長する可能性があることについて言及されていました。確かに、「なぜそうしたの？」のような投げかけは、裏に、「そうすべきではなかったんじゃない？」のような意図を持った質問にも思えることがあります。
「やり方を見せてもらえますか？」や「どうやってそのアイデアを思いついたのですか？」など角度を変えた投げかけを使うことを推奨されていて、自分も日々の言動を見直そうと思えるきっかけになりました。
あたりまえを問う
「あたりまえ」をチームの中で聞くことは勇気がいるが、その投げかけの有用性について記載されていました。「そんなことを今更？・あたりまえじゃん？」といった気持ちを抱かれるから、自分から改めて当たり前のことを投げかけるのは勇気がいります。「このリリース日って今日ですよね？ / この画面はこういった仕様でしたっけ？」
ただ、このあたりまえの問いによって救われる人がいるかもしれない。全員の共通理解ができているかを確認する、とても大切なアクションだと気づきになりました。
AWS認定試験全12種取得したので振り返り
タイトルの通り2023年9月にAWS認定試験全12種全て合格することができました。振り返りをかねて勉強したことや感想をまとめていきます。
認定試験の受験に至った経緯
始めての試験、Cloud Practitionerを受けた頃、アプリケーションをECS・Fargateで構成しているプロジェクトにバックエンドエンジニアとして参画しており、ビジネスロジック部分のアプリケーションのコードをひたすら書いていました。
そんな中、下記のようにAWSと関連する部分ももちろんあったのですが、構築・運用はインフラ担当のエンジニアに任せっきりで、自分はほとんどインフラ部分の詳細を知らない状態でした。
- S3にファイルをアップロードする処理、
- SystemManager Parameter Storeを使って認証情報を参照する
- CodePipeline（CodeCommit→CodeBuild→CodeDeploy）を使ったアプリケーションのCI/CD
- AuroraでDB構築されている
ただ、CodeBuildのメモリ不足・Auroraの不具合など、アプリケーション開発に影響する問題が発生した際、自分が全く役に立てず、「問題が起きたので調査してもらえますか？」とのお願いを続けていることに歯がゆさを感じていました。
「サービスに関わる部分は全部自分が見れるようになりたい」との思いからAWSについて幅広く学んでいきたい気持ちが高まり、その取り掛かりとしてAWS認定試験に目をつけました。
各試験のまとめ・感想
AWS Certified Cloud Practitioner
難易度はFoundationalで1番易しいとされているものの、個人的にはある意味1番苦労した試験かもしれません。おそらく多くの方がAWS認定で最初に受験する試験になるのではないでしょうか。
私自身、実は受験しようと思い立って合格するまで時間がかかりました。（始めてAWS認定を受験する怖さ・仕事・他の誘惑によって間延びしてしまいました。）
どうしても初受験の怖さで躊躇してしまいますが、後述する「まず受験を申し込む」姿勢を大事に、勇気を出してAWS認定への第1歩を踏み入れてみてください..!
等、まず知っておきたい知識が網羅的に身に着けられる良い機会になります。
AWS Certified Solutions Architect – Associate
Cloud Practitionerの次に受ける試験として最適な試験でした。単純なサービスの暗記ではなく、ある条件下でのベストプラクティスはどうすべきかという観点が登場してきます。問題を通して考える機会は実務に大変活きてくると感じました。
- 障害を意識した設計
- 可用性を意識した設計
- セキュリティを意識した設計
- コスト最適を考えられている設計
上記のような視点を身につけることができる試験となっています。
AWS Certified Developer – Associate
LambdaやDynamoDBを中心とした、アプリケーション開発でよく使用されるサービスが出題範囲です。
出題範囲のサービスを業務でよく使用するので学習はスムーズに進みました。
AWS Certified SysOps Administrator – Associate
12種のAWS認定試験で唯一不合格を経験した試験です。（しかも2度不合格に）
ラボ試験というマネジメントコンソールを使って実際に画面を操作しシステム構築する試験が設けられており、苦戦しました（2023年9月現在はラボ試験は無期限中止されており出題されません。）
2度の不合格で心が折れそうになりましたが、持ち直して3度目で合格したのが最終的に全種取得できたキーポイントだったと今思います。
AWS Certified Solutions Architect – Professional
「出題範囲の広さ・深さ」「問題文・選択肢の文字数量」「問題数75問（他Specialty試験では65問）」と、大変難易度の高い試験です。1問題にかけられる時間も短い中、長い問題文を読み解いて行く必要があります。
深い知識に加え、問題の読解力、体力も必要になってくる総合格闘技のような試験です。
ただ、この試験を一度経験することで、他の試験が少し楽に感じるという側面もあったように思います。
AWS Certified DevOps Engineer – Professional
Developer AssociateやSysOps Administratorの出題範囲を更に深掘りし、特にCI/CD周りのCodeシリーズやデプロイ戦略について重点的に出題されます。DevOps領域は個人的に特に好きだったので、比較的詰まらず学習を進めて合格することができました。専用の参考書等が不足している感は否めません（2023年9月現在）が、Developer AssociateやSysOps Administratorの参考書やBlackBelt等を活用することで十分補うことができると思います。
AWS Certified Security – Specialty
セキュリティ（KMS・GuardDuty・WAF...）やアカウント（IAM・Organizations）の分野について深く問われる試験です。他のSpecialty試験やProfessional試験でもセキュリティの分野が出題されてくるので、Assosiateレベルの試験を取得した後にまず受験する試験としておすすめします。
AWS Certified Database – Specialty
AWSが提供しているDataBaseサービス・DataBase移行等・耐障害性、可用性を備えた設計について深く問われます。
システムにおいてDataBaseは特に重要な部分の一つでもありますし、RDS・Aurora・DynamoDBなどの理解が深まり、適切なサービス選択や設計ができることに繋がってくる良い試験だと思います。
こちらの試験で得た知識がData Analytics・Machine Learning等の試験でも活きてきます。
AWS Certified Data Analytics – Specialty
Athena・Glueなどデータ分析のサービスを使った経験があるので、比較的学習はスムーズに進みました。ファイル形式やデータ分析サービスの組み合わせ・使い分けなど、場面に応じたベストプラクティスを考えることが特に色濃く出ている試験だった印象があります。個人的には学習・受験していて１番楽しかったです。
AWS Certified Machine Learning – Specialty
ChatGPT等最近欠かせなくなってきたAI関連にもつながる部分で関心は大きかったものの、「機械学習とは」部分からのスタートで不安でした。
そのため、まずはG検定の書籍等を活用して機械学習の単語レベルから学習していきました。
今後大きくキャリアチェンジしない限りがっつり機械学習を触ることはなさそうですが、機械学習に流す前のデータ分析・データ処理部分に関わることは大いにありそうで、その知見を得られたのが良かったポイントでした。
AWS Certified Advanced Networking – Specialty
Specialty試験の中で最難関だと感じました。私のようなWebアプリケーションエンジニアにとって、Direct Connectのようなサービスを使用する機会はめったに無いかと思います。（私はありませんでした）多くの学習時間をDirect Connect・Transit Gateway等の理解に使いました。
また、Solution Architect Professional試験と同様、問題文と選択肢の文字数が多く、問題を読み解くだけでも大変な労力がかかります。試験中のモチベーション・集中力管理が大事になってきます。
AWS Certified SAP on AWS – Specialty
Webアプリケーションエンジニアにはあまり馴染みがないSAPという領域の試験で、勉強を始めた際、結構苦戦しそうなイメージが大きかったです。
ただ、前職の経費の立替申請などでSAPを使っていたことを思い出し、そこから少しずつ興味と全体の理解が深まっていったような気がします。
SAPの専門的な部分だけでなく、EC2・EBS・システム移行の考え方やツールなどの知識も得られたのが受けてよかったポイントでした。
受験の個人的コツ
まず受験を申し込む
申し込んでいなければ合格率は0%です。しかし、申し込んだ時点で合格率は、合格か不合格かの50%に一気に跳ね上がります。あとは自分の努力次第で合格率を100%まで近づけることができます。受けたい、と思ったらまず申し込むことをオススメします。（その後2回まで受験日を変更できます）
短期集中型で勉強する（モチベーション）
仕事をしつつ、傍らで長期間試験勉強を続けるのはなかなか根気がいります。
また、勉強期間が長期になりすぎると中だるみしたり、別のやりたいことに目が奪われてしまうこともあります。（経験談）
難易度や自分の理解度とも相談しつつですが、個人的には2週間の期間がちょうど良かったと感じます。受けようと思った時点から2週間後に試験日を決め、集中的に勉強することをお勧めします。
遠方受験で楽しむ（旅行ついでに資格受けてみる）
居住地の東京都だけではなく、様々な街のテストセンターで受験しました。
観光の時間は多少削られてしまいますが、旅行とセットにすることで楽しみと受験の緊張・マンネリ化をうまく中和できたと思います。（楽しくて受験しているにせよ、数をこなすと少し辛くなる時もある）
もし試験がうまく行かなかったら、目一杯観光して発散しましょう...!
また、飛行機・新幹線等での移動中は意外と勉強に集中できました。
| 受験地 | 試験 |
|---|---|
| 東京都（新宿・秋葉原） | CLF,SAA,DVA,DOP,SCS,DBS |
| 佐賀県佐賀市 | SOA,PAS |
| 福岡県福岡市 | SAP |
| 群馬県高崎市 | DAS |
| 宮城県仙台市 | MLS |
| 神奈川県横浜市 | ANS |
AWS公式の学習リソースを使用する
AWS SkillBuilder
各サービスの解説コンテンツや、認定試験対策に特化した講座・認定試験の模擬試験など充実しているため、必ず利用したほうが良いです。（ほとんどのコンテンツが無料です。） aws.amazon.com
AWS BlackBelt
Youtubeに各サービスの解説動画が公開されており、視覚的にわかりやすい解説を視聴できます。通勤中などスキマ時間にぴったりなコンテンツです。 AWS Black Belt Online Seminar - YouTube
AWS 公式ドキュメント
正しい情報を正確に得るにはやはり公式ドキュメントを見るのが1番かと思います。 また、サービスごとに、よくある質問というサイトが設けられており、認定試験に関連性の高い項目も多く記載されている印象です。
docs.aws.amazon.com aws.amazon.com
まとめ
12種すべて合格することができましたが、実力・知識がついたというよりむしろ、知れば知るほど「まだまだ知らないことがたくさんあるなあ」、という感覚を得ました。まだまだ勉強不足な部分・経験不足な部分が多いです。
とはいえ、12種もの試験を受験した、受験のために学習した事実をまず自分自身肯定したいと思います。
これからもAWSサービスはどんどん増え、進化していくと思います。そのキャッチアップを続けるためのアンテナを、受験を通してしっかり整備できたと思います。慢心せず、今後も地道に努力を続けていきたいです。
「変化を抱擁せよ 人が増えても速くならない」を読んだ
タイトルに惹かれて、「変化を抱擁せよ 人が増えても速くならない」を読みました。ソフトウェア開発において、プロジェクトが佳境の際に追加人員を投入して炎上の解消を図る形がとられていることをよく聞きますし、自身が現在勤務している会社でもそういう動きをすることがあります。そのアンチテーゼ的なタイトルだったため、気になって手に取りました。
目次
本書は全133ページで比較的薄型の本になっています。文章量も多くないので、一気に読むことができました。 集中して読めば1時間ほどで読み終えられると思います。
- 1章. 完成しても、終わりではない
- 2章. 人を増やしても速く作れるわけでは無い
- 3章. たくさん作っても生産性が高いとは言えない
- 4章. 人に依存せず同じ品質で作ることはできない
- 5章. プレッシャーをかけても生産性は上がらない
- 6章. 見積もりを求めるほどに絶望感は増す
- 7章. 一度に大きく作れば得に見えて損をする
- 8章. 工程を分業しても、効率化につながらない
ポイント
得に参考になった、良かったポイントを4つ紹介します。
速く作ることはできないが、速く作れるチームは作れる
- 難易度の高いソフトウェアを作ることができるのは、エンジニア同士の哲学や文化が揃っているチーム
- ソフトウェアを開発できるチームを育てていくことで、スピード感を持って変化に適応していけるソフトウェアが手に入る
問題を解決できるのは突出した個ではなく、結束しているチームだと認識できました。
小さく作って、大きく育てられるのがソフトウェア
小さく作って、リリースし、お客様の反応を見て改善する・拡大していくというアジャイル的な取り組みがソフトウェアでは可能だということを再認識できました。
小さく作ることの開発視点での利点として、リリース差分が小さい・テスト範囲が明確など様々あります。
見積もりを守るためのバッファの功罪
1度見積もりを失敗してしまった人は、「見積もりの甘さ」を反省する。
そして次の見積もりを行う際に、失敗したくないため多めにバッファ期間を積んでしまう。
すると見積もりを守るための理由で期間を設定してしまうことについて言及されていました。
自分の周りで見たこともあり、自分自身も過去にやったことがある気がして、ゾッとしました。
不確実な未来を、少しずつ確実なものにしていく
「エンジニアリング組織論への招待」という本でも、不確実性に対する言及が多くされていて、その点で両書とも共通した考え方になっていたのが印象的でした。不確実性に対して向き合い続けること、がエンジニアとして永遠に求められることであると再認識できました。
まとめ
筆者がタイトルにも掲げている、「変化を抱擁すること」について、改めてソフトウェア開発における大事にしたいポイントだということを再認識できました。薄い本でスラスラ読めるので、側において定期的に読み返していきたいと思える本でした。
AWSサポートケースを書く際に気をつけたいポイント
AWSサービスを使用している際、予期せぬエラーや障害、不可解な挙動が合った場合等サポートケースを使用してテクニカルサポートの方に聞くことができます。 これまで実際に自分がサポートケースを書いた経験や、同僚が書いたサポートケースのレビューを行った経験から、サポートケースを書く際に気をつけたいポイントを紹介します。
AWSサポートとは？
AWSサポートとは、Amazon Web Services (AWS) の利用者に対して、テクニカルサポートや運用助言、問題解決のための支援を提供するサービスです。運用中の障害発生時や開発中のトラブル、サービスの使い方の相談など、AWS使用・運用中の開発者は必ずお世話になるものです。
チェックポイント
大前提として、AWS公式から提供されている資料を参考にすることをおすすめします。 こちらの資料にかかれている下記の大項目と付随する小項目の確認事項を事前に確認し、頭に入れておきましょう。
- 全般的な留意事項
- 解決したい課題を明確にする
- 状況を正確に共有する
- 経緯を共有する
①正確な語句で書けているか？
ちょっとした語句でも使い方を誤ると、主語が変になってしまったり、文脈が意図せず変化したりと思わぬ影響を及ぼします。細部までもう一度文を見直しましょう。 書き終えた文章を声に出して朗読してみることもオススメします。読むのに詰まってしまったり、読み間違えたりする箇所は怪しいです。
下記は、EC2を人が手動で起動させたのか、EC2が手動ではなにかのイベントで自動起動されたのか紛らわしくなっています。
A
EC2が起動しましたが
B
EC2を起動しましたが
②簡潔で読みやすい文章になっているか？
1文が長いと、文章にリズムが生まれず、読みながら文章の意味を読み解きずらくなります。文章を書いた後に、重複表現や不要な点がないか、見直してみましょう。 AWSリソースの情報を盛り込みたい場合は、本文の前段で先にリソース情報を定義し、本文と分離すると良いと思います。
A
S3 bucketに複数のファイルをアップロードして、そのイベントをトリガーにLambda関数（lambda-functions-name-hogehogefugafuga）を実行させます。Lambda関数（lambda-functions-name-hogehogefugafuga）の中でStep Functions（stepFunctions-name-hogehogefugafuga）を起動し、StepFunctionsのワークフローからGlue job（glue-job-name-hogehogefugafuga）を実行し、
B
対象リソース呼称 - S3 bucket (bucket-name-hogehoge) - Lambda関数（lambda-functions-name-hogehogefugafuga） - Step Functions（stepFunctions-name-hogehogefugafuga） - Glue job（glue-job-name-hogehogefugafuga） S3 bucketに複数のファイルをアップロードして、そのイベントをトリガーにLambda関数を実行させます。Lambda関数の中でStep Functionsを起動し、Step FunctionsのワークフローからGlue jobを実行し、
③実行ID・実行Arnが記載されているか？
経験上、AWSのサポートエンジニアの方から対象リソースArnやイベントの実行IDの提出を毎回求められます。事前に実行ID・実行Arnを共有しておくことで、やりとりする回数の削減につながります。
A
対象リソース呼称 - S3 bucket (bucket-name-hogehoge) - Lambda関数（lambda-functions-name-hogehogefugafuga） - Step Functions（stepFunctions-name-hogehogefugafuga） - Glue job（glue-job-name-hogehogefugafuga） S3 bucketに複数のファイルをアップロードして、そのイベントをトリガーにLambda関数を実行させます。Lambda関数の中でStep Functionsを起動し、Step FunctionsのワークフローからGlue jobを実行し、
B
対象リソース呼称 - S3 bucket (bucket-name-hogehoge Arn: arn:aws:s3:::aaaaaaaaaaaaaaaaaaaaaaa_bbbbbbbbbbbbbbb) - Lambda関数（lambda-functions-name-hogehogefugafuga Arn: aaaaaaaaaaaaaa-dddddddddddd-ccccccccccccc） - Step Functions（stepFunctions-name-hogehogefugafuga 実行Arn: aaaaaaaaaaaaaa-dddddddddddd-ccccccccccccc） - Glue job（glue-job-name-hogehogefugafuga Job runs id: aa_bbbbbbbbbbbbbbbbbbbbbbb_ccccccccccccccccc） S3 bucketに複数のファイルをアップロードして、そのイベントをトリガーにLambda関数を実行させます。Lambda関数の中でStep Functionsを起動し、Step FunctionsのワークフローからGlue jobを実行し、
④現象（事実）検証・仮説を分けて書けているか？
発生している現象・検証・仮説を一気に本文でまとめてしまうと、それぞれが本当に伝えたい事柄だったとしてもそれが発生している事実なのか・仮説なのか、検証結果なのかの解読が困難になります。 適切に文を区切り、それぞれの内容を分けて記載しましょう。 また、この分解作業は自分自身の頭の整理にもなります。眼の前にある情報を俯瞰して見て分類することで、新たな観点や、ヌケモレなどに気づく可能性も増えます。
A
先日からEC2インスタンスがうまく動作しなくなりました。何回か再起動してみたけれど、まだうまくいかないです。Webアプリケーションがとても遅いですし、たまにエラーも出て困っています。ここ最近AWSのシステムに変更はありましたか？コンソールの設定値で怪しいところが無いかの確認や、インスタンスのメモリのモニタリングをしてみました。それによって影響を受けているのかもしれません。もし何か原因や解決策がわかったらすぐ教えてください。
B
私たちのEC2インスタンスでパフォーマンス低下とXXXエラーの発生が確認されており、解決策を教えていただきたくお問い合わせをさせて頂きます。 【現象（事実）】 • 発生日時：2022年1月1日 9:00（JST）頃から • サービス・リソース：EC2インスタンス（インスタンスID：i-xxxxxxx） • エラーメッセージ：XXXエラーコードが表示される • 影響範囲：Webアプリケーションのレスポンスタイムが通常の5倍以上に低下 【検証】 以下の手順を行いましたが、問題は解決しておりません。 1. EC2インスタンスの再起動 2. AWSドキュメントに記載されているXXXエラーのトラブルシューティング手順の実施 【仮説】 AWSのシステム変更やアップデートが影響を与えた可能性が考えられます。そちらの状況に変更があった場合、教えていただけますでしょうか。また、その他可能性のある原因と解決策をご教示いただければ幸いです。
⑤（返信があった場合の回答編）質問に対して答えを適切に返せているか？
聞かれている質問に対し、過不足なく答えましょう。質問に対する回答を正確にすることで、回答に対するその後のやりとりがしやすくなります。 もし、付随して情報を共有したい場合、追加情報エリアを作って、別途記載しましょう。
A
質問内容 Q. Lambdaの実行時間と実行後のエラーメッセージを共有してください 回答 A. 実行時間1sでエラーメッセージは `Error()`です。ランタイムはNode.js 16.xで先日バージョンアップしました。こちらのバージョンアップが悪さしているでしょうか？また、実行ログも見ましたが、原因がわかりません。
B
質問内容 Q. Lambdaの実行時間と実行後のエラーメッセージを共有してください 回答 A. 実行時間1sでエラーメッセージは `Error()`です。
⑥相手に対し、敬意を払った文体になっているか？
基本的なことですが、今まであげたものの中で一番大切です。もちろん、サポートケースを書いているということはなにかに悩み・困っている状況であり、時にはイライラすることもあるでしょう。 しかし、そのイライラを文章に込めて、投げやりに書いてしまうのは厳禁です。サポートしてくれる方がいることに感謝し、丁寧な言葉づかいを心がけたいです。 もし自分がAWS側のサポートエンジニアとして、この文章を受け取ったらどんな印象を抱くか、一度想像して見直してみましょう。
終わりに
AWSサポートケースを書く際に気をつけたいポイントとして、6点のポイントを上げました。 どなたかの参考になれば幸いです。
また、問題を解決するためには、AWSの知識だけではなく、「文章を書く力・伝える力・相手を思いやる力」がとても大切だと本記事を書いていて思い直しました。
VSCodeにGitHub Actionsの公式拡張がリリースされたので試してみた
概要
CI/CD構築を可能にするGitHub ActionsのVSCode拡張機能が public bata版として発表されました。
使ってみた
インストール
VSCodeの機能拡張のサイドバーで検索、または下記リンクからインストールすることが可能です。
設定
使用するにはVSCodeでGitHubへのサインインを行っておく必要があります。 （サイドバーのタブを開くとサインインを求められると思います）
できること
① シンタックスハイライトとサジェストが効く
GitHub Actions独自の文法形式のハイライトが効くようになっています。
またGitHub Actionsのコンテキスト、github.に続くプロパティのサジェストも効きます。
② 説明
先程のコンテキストにカーソルをオーバーフローすると、そのコンテキストの詳細説明が表示されます。
${{ github.actor }}について
The username of the user that triggered the initial workflow run. If the workflow run is a re-run, this value may differ from github.triggering_actor. Any workflow re-runs will use the privileges of github.actor, even if the actor initiating the re-run (github.triggering_actor) has different privileges.
③ 文法のバリデーションが効く
例えばjobs配下に定義するruns-onをあえてtypoしてみると下記のようにエディタ上に警告と、PROBLEMSタブに
- Required property is missing: runs-on（必須項目の
runs-onが欠けています） - Unexpected value 'runs-ons'（
runs-onsという不明な値が記載されています）
といった詳細なエラー原因と箇所を出力してくれます。
④ ワークフローの一覧や履歴を確認できる・Runの再実行が可能
workflowsエリアで定義されているActionsの一覧と実行履歴を確認することができます。
また、VSCode上から再実行をすることが可能です
⑤ GitHub EnvironmentsやGitHub Secrets・GitHub Variablesの設定値の追加や参照が可能
SETTINGSエリアで実現可能です
新規追加する際は、VSCode上でフォームが出現します。
GitHub Environments
環境自体はGitHubサイト上でしか新規登録できなさそうでした。 登録されているEnvironmentがあれば、その配下のSecretsやVariablesの値を追加、参照できます。（Secretsのvalueは見えない）
リポジトリのSecrets
Secretsの値を追加、参照可能です。（Secretsのvalueは見えない）
リポジトリのVariables
Variablesの値を追加、参照可能です。
おわりに
今回はVSCodeでGitHub Actionsの公式拡張がリリースされたので、試して実現可能になっていたことを書きました！
今までGitHub Actionsの公式ドキュメントを調べながらコンテキストの内容を探り探り書いていましたが、サジェストが効くことでどの選択肢があるかすぐに分かるようになりました。
また、実際にActionsを動かしてみて気づくしかなかった文法エラーも、警告してくれるようになり、作業効率が大幅に上がると思います。
GitHub上でしか見ることができなかったRunの一覧や設定情報もVSCodeで確認できるようになり、またRunの再実行や設定値の追加更新ができるようになり、とても便利になったと思います！
環境の命名で気をつけること（Amazon S3の制約）
アプリケーション開発においては、成果物（ソースコード）を展開する環境を用途によって分けることが求められる。 例えばよくある命名は下記のようなもの。
- prod（本番）
- stg（検証）
- dev（開発）
ただ、もう少し踏み込んだ命名をする必要がある場合もあるかもしれない。
特定の大きなタスクに対応した開発環境を作る場合、hogeDevなどとdevのprefixに文字を付け加えたい。
このときに注意してほしいのが、Amazon S3ではバケット名に大文字が使えないという制約である。
バケット名は、小文字、数字、ドット (.)、およびハイフン (-) のみで構成できます。
hogeDevとつけたバケットを作成したいケースが出てきた際に、制約に引っかかってバケットが作れずに困るということだ。
hogeDevと命名したい場合はhoge-devとしておこう。
