2021-12-29

マイクロサービスをやっていく上で参考にしたい記事

Microservices

ブログ納めとしてマイクロサービスをやっていく上で参考にした(い)記事をざっくりまとめました。

現状、がっつりマイクロサービスをやっているわけではないけれど、考え方を取り入れたりはしているし、来年の今頃はどこかでがっつりやっていったりもするかもしれない。

記事一覧

James Lewis/Martin Fowlerの"Microservices"日本語訳

THE マイクロサービスとは、的な記事。ここから全てが始まった...(本当か？)

リンク: https://kimitok.hateblo.jp/entry/2014/11/09/211820

"Microservices"を読んだ

上述の"Microservices"を読んだ後に読むと整理されそうな記事。

リンク: https://deeeet.com/writing/2014/09/10/microservices/

マイクロサービス運用の所感 #m3dev

エムスリーさんのマイクロサービス所感。

リンク: https://www.slideshare.net/seratch/microservices-ops

Microservices Architect in DMM Platform

マイクロサービスアーキテクトの話、アーキテクチャ全体の設計から組織設計など網羅的に役立ちそうなことが書かれている記事。

リンク: https://inside.dmm.com/entry/2021/12/05/microservices-architect-in-dmm-platform

マイクロサービスにひそむ複雑さに立ち向かう

より現場の生々しいマイクロサービスを想像できる記事。

リンク: https://qiita.com/behiron/items/017b12ee7ffa6dfeb254

マイクロサービス分割点の見つけ方

経験に基づいてどうやってマイクロサービスの分割点を見つけるかが書かれていて助かる記事。

リンク: https://lab.mo-t.com/blog/extracting-microservices

絵で見てわかるマイクロサービスの仕組み

これは記事じゃないけど、図が多くて良本の予感がしたのでついでに載せる。

絵で見てわかるマイクロサービスの仕組み

Amazon

まとめ

我々の間にマイクロサービスなどという都合のよい言い訳は存在せん。あるとすればスタンドプレーから生じるマイクロサービスだけだ

2021-11-14

経験学習とYWTをベースに、持続可能な個人の振り返り手法について考えてみた

振り返り YWT

チーム開発を行う際、スクラムのような手法に準拠し、レトロスペクティブでKPTなどで振り返りを行うことが多いと思います。良かったこと、良くなかったことを振り返って、TRYするアクションを決め、次のスプリントに活かし、また評価するサイクルを回す感じでしょうか。

これを個人でも継続的にやっていきたいと考えているのですが、闇雲に振り返りをしてもあまり効果を感じられないし、KPTも個人でやるとなるとあまりしっくり来ません。わざわざ時間をとって自分のPROBLEMを列挙するのは辛いです。

そこで今回、経験を学びに変え、次に活かすためのフレームワークである「経験学習サイクル」の考え方や振り返り手法の一つである「YWT」を取り入れて、持続可能な個人の振り返り手法について考えてみました。

経験学習について

経験学習の概要を学ぶ上で良さそうだった「職場が生きる人が育つ「経験学習」入門」という本をベースに簡単に内容をまとめておく。

職場が生きる人が育つ「経験学習」入門

作者:松尾睦
ダイヤモンド社

Amazon

経験学習サイクル

経験学習サイクルは以下の4ステップを回す。

具体的経験をする
その内容を「内省（振り返り）」する
そこから教訓を引き出す
その教訓を「新しい状況に適用する」

ただし、このサイクルを単純に回すだけでは不十分で、「よく考えられた実践」の中でサイクルを回す必要がある。

よく考えられた実践とは以下。

課題が適度に難しく、明確であること
- 難しいけど懸命に手を伸ばせば届きそうな目標を持つ
実行した結果についてフィードバックがあること
- 実施した結果、どこが良くてどこが悪かったかについての情報を得ることができる
誤りを修正する機会があること
- それを次の機会に活かすことができるような練習や仕事のやり方をする

経験から学ぶための三つの力

経験から学ぶためのベースとなる三つの力が以下。

ストレッチ
- 高い目標に向かって挑戦する姿勢
リフレクション
- なにかアクションを起こしている最中やアクション後に、何が良くて何が悪かったかについて振り返ること
エンジョイメント
- やりがいや意義を見出して仕事を楽しむこと

またそれぞれの方略は以下であると述べられている。

ストレッチの方略

挑戦するための土台を作る
周囲の信頼を得てストレッチ経験を呼び込む
できることをテコにして挑戦を広げる

リフレクションの方略

行為の中で内省する
他者からフィードバックを求める
批判にオープンになり未来につなげる

エンジョイメントの方略

集中し、面白さの兆候を見逃さない
仕事の背景を考え、意味を見出す
達観して、後から来る喜びを待つ

その他、自分や他人への思いについてや啓発者とのつながりの大切さについても述べられていたが、ここでは割愛する。

また本題とは外れるのだが、紹介した書籍でOJTに関して言及している章があり、これは後輩や部下を持つ全ての人にとってとても参考になると思うのでぜひ読んでみてほしい。

YWTについて

YWTは、振り返りのために「日本能率協会コンサルティング」が提唱し日本で開発されたフレームワークです。Y（やったこと）、W（わかったこと）、T（つぎにやること）の日本語の頭文字をとって名付けられました。経験したことを思い出してから次の段階に進むので、問題点だけでなく良かった点も認識できる手法です

YWTの概要についてはこちらの記事を参考にさせてもらった。

経験学習の本からも感じられたが、成功したこともしっかり振り返ってそのエッセンスを言語化し、再現性を持たせられるようにするのが重要だと思う。

そのため個人的にはKPTよりも、「Y -> W」の過程で自分が具体的に経験したことから教訓やエッセンスを言語化し、次に活かせそうな雰囲気のあるYWTはしっくり来る。これは経験学習サイクルのプロセスとも合致する。

というか自分が無知なだけで、経験学習サイクルを回す目的でYWTが誕生した説あるな…

YWTはシンプルなのでシュッとできそうな予感はあるが、こちらの記事で言及されていた点に注意しなければならないと思った。

Y (やったこと)を挙げる際のポイント

客観的に事実を記載していく
自分の主観や感想は切り離す
良いことだけでなく、悪いことも記載する

W (わかったこと)を挙げる際のポイント

やったことを通じて感じたこと、考えたことを書いていく
「わかったこと」という言葉で勘違いしがちだが「考えたこと」を挙げる
- 「xxという技術で開発をした」というYと、「xxという技術についてわかった」というWになるような浅い振り返りでは意味がない
- その開発という仕事を通じて、自分は何を考えたのか、どのように次の行動が変わるのか、を考えるべき
「どうしてそう考えたのか？」「経験を通じた変化は何か？」「他の人に伝えるには？」「今回の得られた学びは何か？」といった問いを立てることで、抽象化と言語化を促す

T (つぎにやること)を挙げる際のポイント

「次にやること」を考える際に重要なのは論理性
- せっかくの実績と考察をYとWとして出したにも関わらず、まったく関係のないことをTとして挙げてもうまく行かない

振り返りのやり方

経験学習サイクルとYWTの考え方、コツをざっくり学んだ上で「俺が考える最強の振り返り手法」を確立してみる。

ただ、ここまで色々言っておいて何なんだが、結局シンプルにTrelloで毎週YWTをやってみようというものになってしまった。Trelloに個人用YWTボードを用意し、workとprivateのラベルぐらい用意しておいて、毎週ひたすらYWTをするだけである。だがYWTする際はちゃんと経験学習サイクルや前で取り上げたYWTのポイントを意識するようにする。

Y

仕事、プライベートでやったことを最低1つずつ出す
- 頑張りすぎるとW以降がしんどくなり続かなくなるので、特に振り返っておきたいYに厳選して行う
もちろん悪かったことも含める
仕事、プライベートそれぞれラベルぐらいはつけてカードを作成する

W

「○○についてわかった」「○○完全に理解した」みたいな浅い振り返りは禁止
Yに対して、抽象化や経験学習を促す問いを立てる
- ストレッチ、リフレクション、エンジョイメントの観点でアクションできていたか？
- 「どうしてそう考えたのか？」
- 「経験を通じて起こった変化は何か？」
- 「他の人に伝えるには？」
- 「得られた学びは何か？」
上記問いを参考にカードを作成し、箇条書きでも良いのでdescriptionも必ず書くようにする

T

最低1つ出す
- 良かった点に対しては継続できるようなアクションを考える、もしくはよりストレッチなチャレンジを宣言する
- 悪かった点に対しては改善案を考える

あとはGoogleカレンダーなどで週次のYWTイベントが通知されるようにしておけば準備完了。やっていくのみ。

まとめ

経験学習サイクルに関してざっくり学んだ結果、「これ要するにYWTでは？」という結論に至り、結果、個人でYWTを運用することになりました。効果があり、かつ頑張れば続けられそうなギリギリを攻めた感じです。

ただおそらく以前から課題に感じていた、具体的な振り返り方、振り返り時の問いの立て方の精度は上がったように思います。

またプライベートや仕事のラベルをつけるTrelloの運用が地味によいなと思っていて、プライベートでやったこと、わかったことが仕事に活きているのが見える化するともっとやろうという気持ちになれたりします。

やはり振り返りは難しいですね。皆さんが考える最強の個人振り返り手法、ぜひ教えてください。

参考

2021-06-08

Auth0のSilent Authentication (サイレント認証)とRefresh Token Rotation (リフレッシュトークンローテーション)を完全に理解した (い)

Auth0 認証

Auth0 の Silent Authentication (サイレント認証)と Refresh Token Rotation (リフレッシュトークンローテーション)を完全に理解したい気持ちが急に高まってきたので書きます。全体の流れとして

React SPA with Auth0 での認可フローについて
Silent Authentication (サイレント認証)について
Refresh Token Rotation について
まとめ

みたいな流れで書きつつ、Silent Authentication や Refresh Token Rotation は何を解決しようとしているのか、それぞれのリフレッシュ方法でどのような挙動になるのか、などについて理解を深めていきたいと思います。

また、React SPA with Auth0 の認可フロー部分のイメージを沸かせるために以下のサンプルリポジトリを用意しています： https://github.com/danimal141/auth0-react-playground

こいつは

frontend
- React の SPA でログイン、アクセストークンを取得する
  - auth0-react を使用
  - リフレッシュトークン利用する or 利用しないの挙動をシュッと確認可能
backend
- Rails ベースの GraphQL API は SPA からアクセストークン (JWT)を受け取って、トークンを検証する
  - 検証が成功したら認可が必要な情報を返却する
auth0
- Auth0 も一応コードからデプロイして環境構築可能
  - めっちゃ個人名の入ったアプリ名になってしまっているので名前変えてください w
- 一部、設定ファイルだけでは更新できない設定もあるので注意 (デプロイ用のアプリ作成など）

みたいな構成になっていて、アクセストークン取得まわりの動作検証に使ったものなのでよかったら見てみてください。ちなみに GraphQL とか使っちゃっていますが、今回の文脈において GraphQL の知識は特に必要ありません。

React SPA with Auth0 での認可フロー

Auth0 の React 用 SDK: auth0-reactを利用した場合、認可フローはこちらに Under the hood, it implements Universal Login and the Authorization Code Grant Flow with PKCE. と書かれているように、Authorization Code Flow with Proof Key for Code Exchange (PKCE)になる。より詳細な説明はこちらに書かれている。

PKCE は雑にいうと、「OAuth2 の Authorization Code Flow で認可コード奪われたらアクセストークンも奪われちゃうからツラいですよね、認可コード送信元も検証して、せめてアクセストークンは取られんようにしましょうや」っていう仕組み。こちらの記事の解説がめちゃめちゃわかりやすかったのでオススメ。

auth0-reactを使う場合、Authorization Code Flow with Proof Key for Code Exchange (PKCE)な実装は SDK 側でサポートしてくれているので自前で code_challengeなどをハンドリングするような必要はない。

ちなみにauth0-reactは元々あったauth0-spa-jsを React の Hooks ベースの実装でいい感じに抽象化しただけのものなので、実装詳細を知りたい場合はauth0-spa-jsの方のコードを読んだほうがよい (読まざるを得ない）。

ログイン -> アクセストークン取得 -> ログアウトまでのライフサイクル

会員登録済みで Auth0 上にすでにユーザが存在する前提で、ログインからアクセストークン取得、ログアウトまでの流れはざっくり以下のようになると思う。

auth0-reactのloginWithRedirectを利用してログイン処理を呼び出す
- ログインボタンなどを設置して、そいつの Click イベントで loginWithRedirectを呼ぶみたいなイメージ
- Universal Login の画面が表示され、認証情報を入力する
  - ここで Auth0 とのセッションが生成される
    - Auth0 ドメイン側の Cookie にこちらで記載されているような値がセットされているはず
  - セッションの有効期限は Auth0 の Tenant Settings にある Log In Session Management の項目で設定できる
    - こちらの記事がわかりやすい
Auth0 の Application (SPA)で callback URL として許可している URL に?code=xxxのクエリパラメータ付きでリダイレクトされる
- codeなどが URL に含まれててツラいが、auth0-reactの onRedirectCallbackを指定しておくと勝手にその辺のツラいクエリパラメータが除外された URL に勝手にリダイレクトしてくれる
上記のcodeを使って {auth0_domain}/oauth/tokenにリクエストを投げてaccess_tokenを取得
- アクセストークン以外にもscopeなど色々情報は返ってくるはずだけど、今回は割愛
- auth0-reactのgetAccessTokenSilentlyというメソッドがその辺やってくれている
トークンストレージはデフォルトではインメモリ
- 画面をリロードしたらアクセストークンは再取得する必要がある
- localStorage を利用することも可能 (後述するけど、リスクを理解せずノリで使うのは危険)
auth0-reactのlogoutを呼ぶとログアウトし、Auth0 ドメインとのセッションも切れる

Silent Authentication (サイレント認証)

上述したが、アクセストークンはデフォルトではインメモリにキャッシュされるので画面リロードなどで都度、再取得が必要になる。「Universal login -> ログイン成功 -> ?code=xxx付きで SPA にコールバック」の流れでは特に問題なかったが、それ以降、Auth0 ドメインとのセッションが生きている状態でアクセストークンの再取得はどうするのか、またログインからやり直しなのか...？

Auth0 はアクセストークンをリフレッシュする手段としてSilent Authentication (サイレント認証)という仕組みをサポートしている。2021 年 6 月時点ではデフォルトで Silent Authentication がデフォルトのアクセストークンリフレッシュ手段になっている。リフレッシュトークンは auth0-reactの実装で Provider にuseRefreshTokens=trueを渡すと利用できるようになる (その他、Auth0 の設定側で offline_accessスコープを API で許可する設定なども必要）。

これは雑に説明すると、画面遷移などを介さずひっそりとセッションを確認してアクセストークンを再取得する仕組みで、Chrome のネットワークタブなどをよく見てみると{auth0_domain}/authorize?xx=xxへのリクエストで prompt=noneとresponse_mode=web_messageが含まれているのが重要なポイントである。

prompt=noneをつけることで画面表示が行われない状態でセッション確認ができる。そしてresponse_mode=web_messageによってユーザからは見えない iframeを作って、「そいつから {auth0_domain}/authorizeにリクエスト -> codeの含まれたレスポンスを受け取る -> そいつを Web Messaging API 経由で親に渡してアクセストークン再取得」みたいな動きを実現している。

詳しくはこちらの記事がわかりやすく解説してくださっている。

こいつのメリットは localStorage を使わないで、かつ毎回ログインを要求されるみたいなクソな挙動を避けてアクセストークンを再取得できることだと思う。SPA はブラウザが前提になるのでネイティブと違ってセキュアなストレージがない。こちらの記事にあるように localStorage は悪意のある npm ライブラリ経由でシュッとトークンが抜かれるリスクがあるなど、セキュアではない。アクセストークンのようなデリケートな情報を長期間そこに入れておくのは危険なので、そういったリスクを避け、かつユーザ体験をそこまで損なわないこの仕組みは非常によい。

ただこいつも完璧ではなく、こちらに書かれているように、昨今の Safari の ITP のような、3rd party cookie がブロックされがちなご時世では Silent Authentication がうまく動作しないケースがある。

実際、Safari や Chrome で 3rd party Cookie をブロックする設定のまま Silent Authentication ベースのアクセストークンの再取得を試みると期待通り動作せず、以下のような感じになる。

SPA (iframe) <-> Auth0 ドメイン間でのリクエストのやり取りの際に 3rd party cookie に当たる情報が取得できない
セッション確認失敗
login_requiredの Error Response が返るため、codeが取得できない
アクセストークンも取得できない

これを回避するには Auth0 のカスタムドメイン機能を使って SPA をapp.example.com、ログイン URL を login.example.comみたいに設定して回避するか、後述の Refresh Token Rotation がサポートされたリフレッシュトークンを使う、あたりが選択肢になってくる。

Refresh Token Rotation (リフレッシュトークンローテーション)

上述のような Silent Authentication の弱点をカバーするための手段として生まれたのが Refresh Token Rotation (という理解で合ってる？)。詳しい説明はこちらに書かれている。

これまでリフレッシュトークンに有効期限がなかったので、それを localStorage に入れるのはリスキーだったが、Refresh Token Rotation を使うとリフレッシュトークンを使ってアクセストークン取得する際に新しくリフレッシュトークンも再発行され、以前のものは無効化されるのでよりセキュアにリフレッシュトークンが使えるようになった。

もちろんリスクが無くなるわけではないが、有効期間をそれなりに短めに設定して localStorage にトークンをキャッシュするアプローチも悪くはないと思う。

Refresh Token Rotation を有効にして localStorage をキャッシュに利用した場合のフローは以下のようになると思う。実際に色々設定をいじったり、 auth0-spa-jsのコードを読みながら挙動を確認したんですが、間違ってたらご指摘ください。

アクセストークンの有効期限が切れる -> リフレッシュトークンを使って再取得の流れ

まずアクセストークン取得からそいつの有効期限が切れる -> リフレッシュトークンを使って再取得するまでの流れは大体こんな感じかと思う。ちなみにアクセストークンの有効期限はデフォルトで 1 日、Auth0 API の Token Expiration の設定に依存する。

最初のログインで Auth0 のセッションができる
- ここでアクセストークンとリフレッシュトークンを取得
- localStorage にこれらの情報が保存される
- localStorage の有効期限はアクセストークンの有効期限と同じになる
アクセストークンの有効期限が切れた場合
- localStorage のキャッシュもクリアされる
- リフレッシュトークンを使ってアクセストークンを再取得
- このタイミングでリフレッシュトークンも更新されるので、以前のリフレッシュトークンは無効になる
- localStorage 上の値も更新される

アクセストークンの有効期限が切れる -> リフレッシュトークンも有効期限切れ / 無効だった場合の再取得の流れ

次にアクセストークンが無効になって再取得しようにもリフレッシュトークンも期限切れ、もしくは無効だった場合は設定によって挙動が変わる。ちなみにリフレッシュトークンの有効期間は Auth0 の SPA の Refresh Token Expiration にある Absolute Lifetime の設定に依存する。

リフレッシュトークンが invalid となって 403 が返る
- セッション有効期間 > リフレッシュトークン有効期間な設定の場合
  - リフレッシュトークンが使えなかった場合の Fallback として、Silent Authentication が呼ばれる
    - セッション有効期間内の場合
      - 3rd party cookie が問題なく使える場合、ここで iframe 経由でcodeを取得 -> アクセストークン、リフレッシュトークンも取得できる
      - 3rd party cookie が使えない場合、Silent Authentication が失敗、内部的にlogout({ localOnly: true })が呼ばれる
        
        ローカルのキャッシュや Cookie のauth0.is.authenticatedの値がクリアされる
        
        ここでは Auth0 セッションは生きている想定なので振り出しに戻る (おそらく{auth0_domain}/authorizeにresponse_mode=queryで再リクエスト -> code、アクセストークン、リフレッシュトークン再取得になるかな、あまり自信ない...)
    - セッション有効期間を過ぎている場合、再ログインを要求される
- セッション有効期間 < リフレッシュトークン有効期間な設定の場合
  - リフレッシュトークンの有効期間が実質セッションの有効期間みたいになる

まとめ

Silent Authentication はブラウザのあまりセキュアではないストレージに頼らないかつ、UX を損なわないアクセストークンのリフレッシュを実現できるが、3rd party Cookie の扱いに厳しくなってきた昨今、いつ動かなくなるかわからないというリスクがある
- 代替案として Refresh Token Roation のサポートされたリフレッシュトークンを利用する
- もしくは Auth0 のカスタムドメインを設定して、3rd party cookie を扱っているとみなされないよう設定することで解決することもできるかもしれない
Refresh Token Rotation はリフレッシュトークンをローテーションさせることで以前よりも気軽にトークン情報をブラウザのストレージに入れられるようになったし、3rd party cookie、いつ使えなくなるんだろうという恐怖から開放される(と信じたい）

参照

2021-02-14

Dockerとplantuml-serverを使ってPlantUMLの実行環境を用意する

Docker plantuml

手軽に PlantUML をいじれる環境が欲しかったけど、軽く調べた結果、Mac での環境構築が悩ましかった。

色々検討した結果、ひとまず Docker で環境構築する方法をとった。

候補

ローカルでbrew install graphviz, brew install plantumlする
- 変な依存ライブラリとかめっちゃ入れられそうなので、できればgraphvizをローカルに入れたくない w
PlantUML Viewerを使う
- 悪くなさそうだったが、試しにいれてローカルのファイルを開いてみたが CORS っぽいエラーが出て面倒そうなのでやめた
- Chrome ウェブストアのレビューでもDoesn't work at all.って言ってる人いたので最近の Chrome のアップデートで死んだのかな
plantuml-serverを使う
- Docker の image があるので一番手軽に使えそうだし、軽く PlantUML を書いて UML を確認できれば十分だったのでこれを使うことにした

環境構築

Vim

Vim を使っているので PlantUML を書く用に plantuml-syntaxだけ入れておいた。他のエディタを使っている人も何かしらシンタックス用のプラグインはあるはず。

Docker

上記の plantuml-server 用の image が公開されているのでシンプルにそれを使う。こんな感じ。

# docker-compose.yml

version: '3.7'

services:
  plantuml-server:
    image: plantuml/plantuml-server
    ports:
      - 8080:8080

あとは docker-compose upして open http://localhost:8080すれば PlantUML の実行環境が手に入り、サクッと UML を確認できる。

まとめ

とりあえず Vim で PlantUML 書いて、ローカルで plantuml-server を立ち上げてコピペで UML 確認できるようになった。若干スマートさに欠けるけどまあいいかという感じ。

2021-02-07

エンジニアの自分がインプットのためによく聴いているPodcastの番組まとめた

Podcast 英語プログラミング勉強法ビジネス

最近はなにがし.fm みたいな番組がめっちゃ増えてきましたね。

普段、移動時間やジョギングする時とかに Podcast をよく聴いているけど、何をどういう目的で聴いているか自分で整理するためにもジャンル別に聴いている番組をまとめてみました。

Tech 系

Rebuild

言わずもがなの番組、まだ番組が乱立してなかった頃からずっと聴いている
話題になった Tech 系の話題や最新情報をキャッチアップできて良い
最近はガジェットだったりコンテンツ系の話題が多い気がするけど、新しい言語とか新しい技術、マネジメント等について議論してる回は特に面白い
英語回は英語の勉強も兼ねて死ぬほど繰り返し聴いた
- これとか
- これも

fukabori.fm

マネジメントや開発組織、アジャイル系の話題など、個人的に好きなトピックを多く扱ってくれるので好き
- これとかめっちゃ勉強になる
- これも何回も聴いた

EM.FM

これもマネジメントとかキャリア考える上で参考にしている
- 1on1 とか、プロダクト開発とか、エンジニア評価についてとかトピックがめっちゃ刺さる
- この回とか好き

Misreading Chat

CS みが強すぎて完全に理解できない時もあったりするけど、面白いので結構聴いてる
- 特に言語の歴史振り返る系
  - これめちゃめちゃ好き
- 個人的に Rust 好きなので、Rust 関連の回とかも

The Changelog

Go とか Rust とか GraphQL とかイーサリアムとかトピックが個人的に刺さりまくることが多いのでチェックしてるけど、ガチの英語なので聴く頻度は少なめ
- めちゃめちゃ集中しないと聴き取れないので元気な時だけ聴く
  - ~~集中しても全然聴き取れない~~
- Go の Rob Pike がゲストで来てたりでアツい
余談だけど、公式サイトは Elixir でできてる

hidek のエンジニアと長話

Podcast 枠に入れてよいかわからないが、stand.fm もたまに聴いていてその中でもこの番組が好き
他の Podcast 番組にはあまり出られていないような著名な方がゲスト出演されていたりして面白い

y_matsuwitter 相談部屋

こちらも stand.fm から y_matsuwitter さんの相談部屋、トピックがエンジニアリングから経営、生産性、勉強法など自分が好きなものが多い
1エピソードが5分程度なのでさくっと聴きやすい、特に良い回を何回も聴く

ビジネス系

前田ヒロ Startup Podcast

SaaS 界隈のスタートアップに投資されている前田ヒロさんの Podcast、SaaS 系のゲストや話題多め
個人的にも創業期のスタートアップにいた期間がキャリアの中で圧倒的に長いので、トピックが刺さりまくる
- ゲストの起業家の方々のマインド、考え方、失敗談などをインプットしまくれるので高まる、よい
2021 年2月現在、もはや Tech 系の番組よりもよく聴いているかもしれない
この回とかめっちゃ面白い、URLからしてSUGOI

ゼロトピック

10X Yamotty さんの Podcast
こちらも起業家の方やスタートアップみの強い方の経験談や考え方をインプットできて楽しいのでチェックしている
プロダクト開発みたいな観点でもめちゃめちゃ参考になる
- 自分はスタートアップが長いエンジニアなので、こういう回は特によさを感じてしまう

その他

バイリンガルニュース

上述の Rebuild でもたまに話題が上がっていて、英語学習のためにチェックするようになった
話題もわりとテック系多めで英語と日本語が混ざっているので、フル英語の番組より気軽に聴けてよい
- 英語の学習抜きにしても面白い内容
Mami さん、帰国子女とかではないのにあのレベルなのヤバすぎる(参照)

まとめ

今後も面白い番組を発見したら更新していきたい。