一から勉強させてください

最下級エンジニアが日々の学びをアウトプットしていくだけのブログです

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

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

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

記事一覧

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

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

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

まとめ

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

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

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

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

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

経験学習について

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

経験学習サイクル

経験学習サイクルは以下の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の運用が地味によいなと思っていて、プライベートでやったこと、わかったことが仕事に活きているのが見える化するともっとやろうという気持ちになれたりします。

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

参考

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

引っ越しました。

zenn.dev

Dockerとplantuml-serverを使って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 確認できるようになった。若干スマートさに欠けるけどまあいいかという感じ。

エンジニアの自分がインプットのためによく聴いている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 さん、帰国子女とかではないのにあのレベルなのヤバすぎる(参照)

まとめ

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