こつつみ

コツコツ積み上げる

年間目標を立てるのをやめました

タイトルの通り年間目標を立てるのをやめた。

2021, 2022年と年間目標を立ています。

kotsutsumi.hatenablog.com

kotsutsumi.hatenablog.com

2021年はそれに向かって行動してきて、それなりに照準合わせてできた。 しかし、2022年は途中で予想していなかった作業が発生したり、気持ちが変わって目標とはズレていったりしてしまった。

一度決断しても、全く反対に舵を切っても良い

感じたことは、1年間もあればやりたいことも、やるべきことも変わっていく。 一度決断しても、全く反対に舵を切っても良い。自分は現在エンジニアですが、マネジメント方面や、フリーランスになったり、または自分が想像していなかった職業を目指すかもしれない。 年の初めに決めたこと守り続けることも良いことですが、将来のことなんて誰もわからない。

年間目標たてた人も、途中で変わっても良いんだという気持ちを持ちつつ、目標をアップデートし続けるのが大切だと感じる。世の中は変化しやすいし、だから気持ちも変わる。

週、月目標を立てる

とは言っても目標は立てておきたいと思う性分なので、より期間を短くして月、さらには週まで細かくして目標を立ててみる。

年間だと目標が大きくしすぎてしまって、最後達成できなくて挫折を味わうことが多い。なので、達成可能な小さな目標に分解してみる。達成感を感じながら継続をしていくことで大きな目標に向かっていくことにする。

2022年振り返り

ブログを更新しないまま一年が経とうとしている。 2022年初めに目標を立てたので、振り返りをしていきます。

目標については↓

kotsutsumi.hatenablog.com

振り返り

O1. 自分の意見をもつ

KR1-1. 毎週このブログを更新する

おかしい!!?!?目標を立ててからブログを一つも更新していないです。

2021年12月からslaherというチームでお仕事もらったりしていたので、一旦ブログをお休みしたら、そのまま忙しさもあって書く習慣がなくなってしまいました。

KR1-2. 技術書以外の本を30冊読む

上記で挙げた活動に加え、2022年3月頃から、Mokuren for GitHubの開発に携わり始め、本も上記同様に読む時間を思うように確保できなくなってしまいました。

ただ何冊かは読んでいて、スモールビジネスの本は特に面白かったので、おすすめです。

Amazon.co.jp: スモールビジネスの教科書 eBook : 武田所長: 本

O2. エンジニア技術の向上

KR2-1. 技術書を10冊読む

DDDやTDDなど設計本中心に何冊か読みましたが、10冊は読めなかったです。ただし、DDDに関しては業務やMokuren+αで実践をしながら学べたのでエンジニアの向上という面ではかなり良い一年でした。

KR2-2. 技術記事を15個書く

このブログを動かしてなかったこともあり未達成です。Qiitaでは、Mokurenについての記事を2つ書きました。

KR2-3. TOEIC800点以上とる

800点取ることは99%できていないです。 10月半ばからTOEIC 700点を目標に勉強を始め、12/18に受験しました。手応えは60%くらいです。 入社以来、英語に関しては全く勉強していなかったので、ひとまず勉強を始めることが出来て良かったです。

O3. 生活の充実

KR3-1. ルーティンの確立

2021年にカレンダーに行なったことを入力する習慣はついたのに、その習慣がなくなってしまいました。 しかし、手を動かす習慣は継続して進めることができたのは良かったです。

KR3-2. 自己投資を50万円以上つかう

電動昇降机など買いましたが、記録もつけておらず、目標すらも忘れていて10万くらいしか使っていなそうです。

KR3-3. 週3日筋トレを15分以上行う

3月からジムに行き始めました。当初は週2, 3で行けていましたが、今では週1です。

総括

結果的には全て未達成です。1月の時点から目標を振り返ることを今年はできていなかったので、どういった目標なのかも忘れていました。 状況は変化していくので、1年という長い期間で目標と振り返りをするのではなく、1週間や1ヶ月単位で行うように変えていかないと対応できないと感じました。

目標に対しては未達成でしたが、プログラミング設計に関しての知見が溜まった1年でした。特に業務ではドメインに向き合って改善しながらできました。 また、新たな取り組みとしてISUCONのPython移植を行いました。

ISUCON12 オンライン予選の利用言語比率 : ISUCON公式Blog

Web技術についての知見はまだまだ足りてないなと感じたので、アウトプット先行で引き続き学んでいきます。

2022年のOKR

OKR

今年も去年に引き続きOKRで目標を立てていきたいと思います。

2021年のOKR (俺の今年の理想) - こつつみ

O:Objectives

  • 定性的な目標
  • チームを鼓舞するようなチャレンジングなもの
  • シンプルで覚えやすいもの
  • 1カ月~四半期(3カ月)で達成できる目標
  • 定量的な指標(数字など)を入れない
  • 最大でも3〜4個

KR:Key Results

  • 定量的な指標で、数値で測れる
  • 数は3つくらい(2~5個程度)
  • ストレッチゴール(ストレッチ目標)
  • 60~70%の達成度で成功とみなす
  • 自信度10分の5の難易度
  • OKRのKRとはKey Results(主要な結果)であり、Objectiveへの進捗を図るための具体的な指標を意味する

以下、2022年の自分のOKRです。

O1. 自分の意見をもつ

KR1-1. 毎週このブログを更新する

去年に引き続き、自分で考える習慣を持つため、に読んだ本で感じたことを言語化したものであったりを毎週ブログ更新を目指していきたいと思います。

KR1-2. 技術書以外の本を30冊読む

著者の考えや思考を吸収するために、技術以外の本を多く読んでいきたいと思います。

O2. エンジニア技術の向上

KR2-1. 技術書を10冊読む

去年は20冊という目標を立てましたが、今年は10冊を深く理解できるまで読み込みたいと思います。

KR2-2. 技術記事を15個書く

去年は技術記事10記事だったところ目標達成できたので、今年は増やして人に伝えられる技術記事を書いていきたいと思います。

KR2-3. TOEIC800点以上とる

目的は技術リファレンスを読むことができるレベル、また、YouTubeで英語の聞き取りができるレベルになりたいと思っています。 定量的にするためにTOEICを基準に考えていきます。 ちなみに、現在のTOEICの最高点は3年前に580点です。そこから勉強をしていないです...

O3. 生活の充実

KR3-1. ルーティンの確立

去年はカレンダーに行なったことを入力する習慣はついたので、今年は毎日カレンダーで予定を立てるところをしていきたいです。 そうすることで、毎日、毎週、毎月の振り返りを行えるようにしていきます。

KR3-2. 自己投資を50万円以上つかう

去年と以下のようにこじつけで43万を使いました。

趣味の金は入れないようにして、50万円以上使っていきたいです。

KR3-3. 週3日筋トレを15分以上行う

筋トレが毎日継続できなかったので、今年は少なくとも週3回できるようにしていきます。

最後に

他にもルームシェアが今年の2月末に終わったり、チームでの受託開発が始まったりするので気を引き締めてやっていきたいです。

2021年の振り返り

こんにちは、ueshoです。

本当は振り返り記事と抱負の記事を別々に書こうと思っていましたが、もう2021年が終わり2022年になってしまいました。 2021年は色んなことがたくさんありました。良い転換期の年でした。

OKR振り返り

くそ恥ずかしいタイトルになっているが、今年の頭にOKRを策定していたので、まずはそれに沿って振り返りたいと思います。

kotsutsumi.hatenablog.com

以下、2021年OKR(Objectives and Key Results)です。

##  O1. 自分の意見をもつ

* KR1-1. 毎週このブログを更新する
* KR1-2. 毎日取ったメモをまとめる

## O2. エンジニアリングの追求

* KR2-1. 本業で 1 レベルの上の評価を得る
* KR2-2. 技術書を20冊読む
* KR2-3. 技術記事を10個書く

## O3. 生活の充実

* KR3-1. ルーティンの確立 (ToDoリストを作らずに全てカレンダーで管理する)
* KR3-2. 自己投資を惜しまない
* KR3-3. 同居人とランニングを続ける
* KR3-4. 毎日筋トレを10分する

OKRに合わせて以下の視点で一年間の目標を作成しました。 

  • 学習時間週21時間する(3時間/日)
  • メモを週21個とる(3個/日)
  • 読書を週1冊する完読する
  • ブログを週1個投稿する
  • 自己投資を年50万円する

f:id:ue-sho:20220101114506p:plain

以下が1日ごとに目標と比べて現在の達成度合いを表したグラフです。 夏あたりまで継続して頑張っていたが、10月あたりから遅れを取り返せなくなっていき、12月はかなり休んでいました。

春、夏前半は組み込みエンジニアとして新卒2年目の成果報告でプレゼンする機会があったり業務も忙しかったですが、社内の配属先を変えるためにAWS勉強したりしていたので、かなり頑張れてました。 夏後半は、無事配属先もAWSを使ったクラウドの部署に異動して残業も無く、割とやりたいことを出来ていました。 秋に入ってからは急に残業が増えました(月30時間程度)。このタイミングで小さいことからアウトプットをしていこうと思いTwitterで #uesho開発 のタグを使って毎日GitHubの草を生やそうという取り組みを行なったが、途中で折れてしまった。 12月頭の方で1年の振り返りを行ったところ、満足してかなり休んでしまったので目標と達成度の遅れがすごいことになってしまいました...

f:id:ue-sho:20220101163834p:plain

KeyResults振り返り

KR1-1. 毎週このブログを更新する

自分の考える習慣を持ちたくて、本読んだら自分の感じたことをブログにしようと思って始めました。 しかし、「とりあえず投稿!」って感じなので見せるの恥ずかしくて隠して投稿していたので、そこは反省点です。 もともと文章書くの下手で、レポートとか読書感想文とか書くの苦手だったが、思ったよりは継続できたので良かったです(年で52個記事にする予定が、現在44記事)。 ただ、このまま適当にやっても上手くならないと思うので、ちゃんと構造化を意識したりして来年は数もこなしつつ質も意識して継続していきたいです。

KR1-2. 毎日取ったメモをまとめる

これもメモを抽象化して考えて自分の意見を作れるようにと立てた目標です。 これは手段が目標みたいになってしまい、とりあえずTwitterや記事で「なるほど〜」と思ったところをNotionに投げるだけでになってしまい自分の意見をあんまり考えられなかったです。 後半はメモを取る回数が激減して、今は特にメモを取らなくなってしまいました。

f:id:ue-sho:20220101180921p:plain

KR2-1. 本業で 1 レベル上の評価を得る

これは来年にならないと分からないので割愛します。自分なりに今の等級にしてはやったとは思います。

KR2-2. 技術書を20冊読む

スプレッドシートのやつに落とし込まなかったので、目標を立てたことを忘れていました。 9冊くらいしか読んでいないです。 来年は積読されている技術書が大量にあるので、それらを消化したいですし、今まで読んだやつで振り返りたいやつもかなりあります。 技術書は何回も読んでアウトプットして自分の中に落とし込みたいので、2022年は8冊くらいを目標にしていきたいと思っています。

KR2-3. 技術記事を10個書く

この目標の存在もスプレッドシートに落とし込んでいないので忘れていました。 技術関連なら12記事くらい書いたが全て内容が浅いし、技術書読んだ振り返りとかになっている状況です。 2022年は、人に伝える記事を書いていきたいです。

KR3-1. ルーティンの確立 (ToDoリストを作らずに全てカレンダーで管理する)

毎日カレンダーに予定を入れて、それを実行するということを習慣化させることで自分の作業時間を増やそうとこの目標を立てました。 最初の頃は予定を決めてカレンダーに入れていたが、今は記録することだけが習慣になっています。

2021年後半は漫画を読む時間がとても増えてしまった。

f:id:ue-sho:20220101215811p:plain

KR3-2. 自己投資を惜しまない

自分はラーメンのトッピングをケチるくらいには、ケチなので金を使うことに罪悪感を持たないように設定した目標。 計算したところ1年で50万は余裕で使えることが分かったので、スプレッドシートのやつに落とし込んみました。 自己投資(学習)だけで50万使おうと思っていましたが使いきれないので、バイク(通勤時間の短縮)や一眼レフカメラ(気分転換になる)とこじつけて割とお金を使えました。 ただし、お菓子を買う頻度も爆上がりしてしまったので、反省です。

KR3-3. 同居人とランニングを続ける

自分は現在大学の研究室の人たちとルームシェアを行なっている。その同居人が誘ってくれるので、ランニング大会(6月)までは継続できました。 しかし、そこからモチベーションが無くなり、ほぼ走ることがなくなってしまいました。 ランニングをしていた頃の方が、気分転換になっていたのか?集中力や作業始めるまでのモチベーションがあった気がします。

KR3-4. 毎日筋トレを10分する

夏ぐらいまでは10分とか意識していませんでしたが、割と筋トレしていました。しかし、これも途中で全くしなくなってしまいました。 来年は、引っ越しがあるので近くにジムがあったら通いたいと思っています。


OKR以外の振り返り

部署異動のこと

自分の新卒で配属された部署が特殊で2年目で異動が行われるところでした。元々組み込みエンジニアとしてやっていたので、AWS SAAの資格をとって今の部署であるクラウドチームに来ることができました。 今後しばらくはクラウド/バックエンドをやっていくので、人生の大きな転換期でした。

設計のこと

今年に入って全然わかっていなかった設計についてかなり勉強してきました。技術書で言うと以下を読みました。

全然実践経験がないので、絶賛今設計について(実務でも自己啓発でも)自分に任せてもらえているので、段々と何をすると嬉しいのかが分かってきました。 しかし、まだまだ上記の本を読んだとしても身についていないので、繰り返し読んで自分の中に落とし込んでいきたいです。

プログラミング言語

元々は組み込み開発をしていたので、C言語を実務でやっていました。また、去年は競技プログラミンングをやっていたのでC++も使っていました。

クラウドチームに配属されてからは、Pythonをメインに使っています。しっかり勉強したことはなかったですが、酒井潤さんのUdemy が素晴らしく良く、体系的に学ぶことができました。 今では、チームの中でもかなりPythonについて知っているレベルになりました。

関係ないですが、一般社団法人Pythonエンジニア育成推進協会からイベントでPythonマグカップをいただきました。f:id:ue-sho:20220101223547j:plain

クラウドについて

AWS SAAの資格を取ったときは手を動かす回数がすくなったかったので、単語だけ覚えている状態でしたが実践経験を積みながら段々と分かってきました。 来年は、もっとインフラ周りの知識をつけていきたいと思います。

総評

組み込みエンジニアからバックエンドエンジニアになり人生の転換期でした。 そして、2021年はAWS、設計、Python、Web技術など自分の知らないことについて色々と学んだ年でした。インプットが多めでしたので、2022年はアウトプットを意識していきたいと思います。

f:id:ue-sho:20220101224218p:plain

ここまで読んでいただき、ありがとうございます。良ければ Twitterのフォローも待っています。

twitter.com

「Team Geek」を読んだ

本の基本情報

本の基本情報について紹介する。

  • 著者名:Brian W. Fitzpatrick, Ben Collins-Sussman
  • 翻訳者: 及川 卓也 (解説), 角 征典 (翻訳)
  • 書籍名:Team GeekGoogleギークたちはいかにしてチームを作るのか
  • 出版社:オライリージャパン
  • 発売日:2013/7/20
  • 頁 数:228ページ

Team Geek ―Googleのギークたちはいかにしてチームを作るのか | Brian W. Fitzpatrick, Ben Collins-Sussman, 及川 卓也, 角 征典 |本 | 通販 | Amazon

書評

絵も多く文章も堅苦しくなく読みやすかった。共感する部分が多くタメになった。 この書評では自分が心に残ったことを書いていく。

隠したらダメになる

完成してないものを見られたら、何か言われるんじゃないかと本当に不安だ。細かいところまで見られて、馬鹿だと思われないだろうか

この気持ちは誰しもが抱く感情だと思う。自分もこのブログなど誰でも見れる状態にはあるが、Twitterでわざわざ発信はしていない。なぜなら、変な文章を書いていて恥ずかしいからだ。

この本では、これが間違いであることを説明している。いつも1人でやっていると、失敗のリスクは高くなる。そして、成長の可能性が低くなると言っている。 1人でやっていると、自分が正しいことに取り組んでいるのか、それがうまくできているのか、すでに完成していないかを確認する必要がある。早い段階で失敗する可能性は高い。しかし、その段階でフィードバックを求めれば、それだけリスクは下がる。検証を重視した「早い段階で、高速に、何度も失敗せよ」の精神を忘れないようにするべき。

失敗を恐れずアウトプットすることが大事。1人で仕事をする方がリスクが高い。間違ったことをして、時間を無駄にすることを不安に思うべきだ。

ソフトウェア開発はチームスポーツ

隠れ家に1人でいたら、才能が開花することもない。秘密の発明をこっそり準備していたら、世界を帰ることもできないし、数百万人のユーザーを喜ばせることもできない。誰かと一緒に仕事をしなければいけないんだ。ビジョンを共有しよう。仕事を分担しよう。他人から学ぼう。そして、素晴らしいチームを作るんだ。

これはアフリカのことわざである「早く行きたければ、ひとりで行け。遠くまで行きたければ、みんなで行け。」を表していると思う。 素晴らしいチームを作れば、1人でやるより大きいことを成し遂げられる可能性が高まる。

HRT

あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ。

  • 謙虚(Humility)
    • 世界の中心は君ではない。君は全知全能ではないし、絶対に正しいわけでもない。常に自分を改善していこう。
  • 尊敬(Respect)
    • 一緒に働く人のことを心から思いやろう。相手を1人の人間として扱い、その能力や功績を高く評価しよう。
  • 信頼(Trust)
    • 自分以外の人は有能であり、正しいことをすると信じよう。そうすれば、仕事を任せることができる。

QiitaのガイドラインにもHRTについて書かれているので、この本でも一番有名な部分であり、著者も「この原則は本当に重要なので、本書はこれを中心に構成している。」と言っている。

Qiitaに面白い記事があったので、共有 qiita.com

人は植物

エンジニアも植物みたいなものだ。日光を必要とする人もいれば、水を必要としている人もいる。リーダーとしての仕事は、どのエンジニアが何を必要としているかを把握して、それを与えることだ。

自分はまだリーダーのポジションにはいないが、リーダーでなくてもこれはできると思う。難しいことなので、リーダーになる前から意識していきたい。

安全なポジションまで昇進する

昇進すれば、自分の運命をコントロールできるようになる。いい心地のいいポジションの時に少し頑張る。昇進プロセスを調べる。

別の章では以下のような記述もあった。

君のやっていることだけでなく、君が「うまく」やっていることを上司やチームの外部にいる人たちに知らせる必要がある。

仕事をうまくやれば昇進できるとは限らない。言わずもがなだが、昇進したいなら色々と手を打つ必要がありそうだ。

さいごに

本書が読者に伝えたいのはソフトウェア開発に限った話ではなく、人間関係が発生する全てに適用できる。 今回取り上げたのはほんの一部なので、少しでも興味が沸いたら手に取って読んでみることをオススメする。

僕の知らないところで大きい金が動いている

最近知った事実。会社員じゃない人の金の動きは大きい。

大手企業に勤めている人は一月100万で人を雇うのは安いって言ってた。自分は給料30万も無いのに。

フリーランスの友達のお金周りを聞くと時給5000円やら、月50万は安すぎるなど自分の概念が壊された。 (もちろん退職金やら税金周りの処理やらがあるので、実質使えるお金はかなり減ることは知っている)

外注してシステムを作ってもらうのもめちゃくちゃ高い。 自分の会社では、一サービスのサーバー費だけでも年何百万もある。

知らないところで大きい金が動いている。

日本の平均年収はどんどん下がってきているし、稼げない人が多くいる。しかし、お金大きな動きを知りトップの人が稼げる意味を知った。そんなことを考えていた日。

GitHub Actionsで「 CloudFormationで構築したLambdaにS3を介さずに自動でデプロイする」を作る

はじめに

以前の記事でLambda + CloudWatch Event でインフラをコード化した。

kotsutsumi.hatenablog.com

今回は、GitHubで管理しているLambdaに上げるコードをmasterブランチを更新するたびに、 AWS S3を介さずにデプロイする方法について書く。

CloudFormation

CloudFormationについては以前の記事でも記載したが、再度掲載する。

AWSTemplateFormatVersion: 2010-09-09

Description: Lambda for git commit count bot

Parameters:
  GitHubAccessToken:
    Type: String
  SlackApiToken:
    Type: String

Resources:
  GitCommitCountBotLambda:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: git-commit-count-bot
      Handler : lambda_function.lambda_handler
      Role: !GetAtt LambdaExecutionRole.Arn
      Runtime: python3.9
      Timeout: 10
      Environment:
        Variables:
          GITHUB_ACCESS_TOKEN: !Ref GitHubAccessToken
          SLACK_API_TOKEN: !Ref SlackApiToken
      Code:
        ZipFile: |
          def lambda_handler(event, context):
              print('dummy')

  LambdaExecutionRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: 2012-10-17
        Statement:
          - Effect: Allow
            Principal:
              Service:
                - lambda.amazonaws.com
            Action:
              - sts:AssumeRole
      Path: /
      Policies:
        - PolicyName: git-commit-count-bot-role
          PolicyDocument:
            Version: 2012-10-17
            Statement:
              - Effect: Allow
                Action:
                  - logs:CreateLogGroup
                  - logs:CreateLogStream
                  - logs:PutLogEvents
                Resource:
                  - '*'

  CloudWatchEventRule:
    Type: AWS::Events::Rule
    Properties:
      Name: schedule-every-day-0am-event
      ScheduleExpression: cron(0 15 * * ? *) # 日本時間で 0:00
      State: ENABLED
      Targets:
        - Arn: !GetAtt GitCommitCountBotLambda.Arn
          Id: git-commit-count-bot-lambda

  LambdaEventPermission:
    Type: AWS::Lambda::Permission
    Properties:
      Action: lambda:InvokeFunction
      FunctionName: !Ref GitCommitCountBotLambda
      Principal: events.amazonaws.com
      SourceArn: !GetAtt CloudWatchEventRule.Arn

GitHub Actions

GitHub Actionsとは?

GitHub Actionsとは、GitHub上でプッシュ・Issue・リリースなどのイベントをトリガーに起動し、対応するアクションを組み合わせてワークフローの自動化が行える。 いわゆるCI/CDツールです。類似のものですと、CircleCIやJenkinsなどがある。

ドキュメントや公開されているActionが多数あるので、これらを活用することで簡単に自動化の実装ができる。また、Github ActionsはYamlファイルを書くだけで良いため1つサンプルを準備すると、 同様の設定をエンジニア以外でも作成することができる。公開されているActionを使うことで自分で作らなくても良いものもある。

CloudFormationで構築したLambdaにS3を介さずに自動でデプロイする

適宜ファイルにコメントをつけて説明する

name: deploy

on:
  push:
    branches:
      - master  # masterにイベントが発生した場合をトリガーに起動する

jobs:
  lambda-cd:
    name: Zip the code to be deployed to AWS Lambda
    runs-on: ubuntu-latest
    env:
      ZIP_FILE_NAME: package.zip  # jobs全体に適用される環境変数を設定する
    steps:
      - name: Checkout
        uses: actions/checkout@v2  # 公式が提供しているGitHub Actions, イベントがあったブランチを仮想環境上に置く(チェックアウトする)

      - name: Setup Python
        uses: actions/setup-python@v2 # 公式が提供しているGitHub Actions, Python環境を準備する
        with:
          python-version: 3.9

      - name: Zip the code
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt -t ./   # Lambda上でpip installできないので、サードパーティーのライブラリのソースコードを置く 
          zip -r ${{ env.ZIP_FILE_NAME }} ./*  # サードパーティーのライブラリのソースコード と 自身のコードをZip化する
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1   # こちらもGitHub Actionsで公開されている, AWSの認証を行う
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ap-northeast-1

      - name: deploy to AWS Lambda
        env:
          TEMPLATE_FILE: cloudformation/git_commit_count_bot.yml   # CloudFormationのYamlファイルのパス
          STACK_NAME: git-commit-count-bot-cfn  
          LAMBDA_FUNCTION_NAME: git-commit-count-bot
        run: |
          aws cloudformation deploy \
            --template-file $TEMPLATE_FILE \
            --stack-name $STACK_NAME \
            --capabilities CAPABILITY_NAMED_IAM \
            --parameter-overrides \
            GitHubAccessToken=${{ secrets.ACCESS_TOKEN }} \
            SlackApiToken=${{ secrets.SLACK_API_TOKEN }}     # AWS上に環境を構築する
          aws lambda update-function-code \
            --function-name $LAMBDA_FUNCTION_NAME \   # CloudFormationのYamlファイルに変更がない限り変更コードが反映されない
            --zip-file fileb://${{ env.ZIP_FILE_NAME }} --publish   # そこで毎回Zipファイルを指定してLambdaのコードを更新する

このようにすれば、masterブランチを更新するたびに、AWS S3を介さずにデプロイできる。

最後に

今回はこのようにして行ったが、CloudFormationで AWS::Serverless::Function を用いれば簡単にできるかもしれないと後になって気づいた。 しかし、試していないので今度試してみて出来れば記事にしたいと思う。

docs.aws.amazon.com