2023年と2024年4月までの振り返り【仕事編】

こんにちは。
前回の2023年と2024年4月までの振り返り【プライベート編】に続いて、お仕事編です。
前回の記事はこちら。
ishikawa-pro.hatenablog.com

本業

去年は、新卒の頃から関わっていたサービスをクローズしました。裏側は社内のプラットフォームとして生きているのですが、外向けのサービスとしての側面は終了しました。いろいろ関わってきたので感慨深いです。

あと去年から、会社のこれから1年や数年先の技術戦略を考えたりするのに関わるようになりました。これは、半年に１回くらい職種別でいろいろロードマップを引いたりする取り組みで去年から始まりました。僕はバックエンドエンジニアの技術的な方向性とかを他のリードエンジニアと一緒に考えました。
この技術戦略会議で、ここ数年は PolyRepo でマイクロサービスをたくさん開発していたのを方向転換して、 MonoRepo で Modular Monolith 的な感じに集約していこうという流れなりました。その方針に合わせて内部向けに作っているライブラリを改修したり、 MonoRepo + Modular Monolith なアーキテクチャの設計とかもやりました。まだまだ課題はありますが、年始くらいには大体軌道に乗ってきたのでよかったです。

あとは、2023年の始め頃から Platform Engineering という分野に興味を持ち始めました。僕は新卒で今の会社に入社してからずっと、社内向けの Backend as a Service のようなプラットフォームを利用した新規サービスを開発したり、プラットフォームの開発・運用や SRE と協力しながら DevOps の強化とかをやっていました。プラットフォームを構成するマイクロサービスのパフォーマンス改善や社内の開発者体験を向上させるような取り組みはとても楽しく、世の中ではこれはどういう職種になるんだろうと気になって、いろいろ調べていたところで Platform Engineering について知りました。これをきっかけに、 2023 年は仕事以外でも Platform Engineering に関する勉強会の運営に関わりはじめました(後述)。また、 2024年からは仕事でも Platform Engineering のチームが立ち上がり、社内プラットフォームの複雑化している部分を整理したり、ドキュメントを拡充させたりなどの開発者体験を向上させるための取り組みをやっています。
なので、今年は社内でも Platform Engineering という取り組みを通して開発者の生産性を上げて、間接的に事業へ貢献することで、このチームが解体されないように頑張ろうと思います。

エンジニアとしての活動

先ほども書いたように、Platform Engineering という分野に興味を持ったことで、Platform Engineering Meetup(PFEM) という勉強会の運営に関わるようになりました。
platformengineering.connpass.com きっかけはこのツイートです。

Platform Engineering Meetup、第2回以降一緒に運営やっていただける方を募集します！

1人だと開催が不定期になったり、イベントの方向性が偏ったりという可能性があるため、複数人で運営することで安定して良いイベントをできるようにしたいと思っています。

手伝って頂ける方はコメントください！

— Kazuto Kusama(jacopen)☄ (@jacopen) 2023年2月20日

jacopen さんとは面識もなかったですが、こんな機会は滅多にないと思い、思い切って飛び込みました。僕と同じように面識もなく勉強会運営が初めての人もいれば、もともと知り合いで他のイベントを一緒に運営しているという方もいらっしゃいましたが、僕のような人も暖かく迎え入れて頂き、いろいろ学ばせて頂きながら運営をやらせてもらっています。 活動としては、去年の3月から隔月くらいのペースで勉強会を開催しています。現地 + オンラインというハイブリッド型でいつもやっていて、基本は東京でやってたまに地方(名古屋, 福岡, 大阪) で開催したりしています。

夏には Cloud Native Days Fukuoka (CNDF) という福岡で開催されたカンファレンスと、前夜祭として PFEM の福岡回があり、自分も旅行がてら福岡へ行きました。CNDF と PFEM を通して、色々な人と交流できてすごく楽しかったです。あと、食べ物もおいしかった。
福岡までの交通手段で、自分はいつも東京から岡山まで新幹線で帰省するから深く考えずに同じノリで新幹線を選んだら、みんな飛行機で福岡まで行っていて、ちょっと恥ずかしかったです笑。あと、適当に駅前のホテルを選んだら喫煙可の部屋でめっちゃタバコ臭かったのも今となってはいい思い出です。(めっちゃ旅慣れてない笑)

もう一つ PFEM 関連で大きなトピックは、PFEM の運営メンバーとして Developers Summit で登壇させて頂きました。
event.shoeisha.jp こういう大きなイベントで話した経験はなかったので、いつかはやってみたいと思っていましたが、その夢が叶ってよかったです。登壇は他の運営メンバーを合わせて4人でやったので、心細くもならずに発表に挑めて本当にいい機会でした。オンラインで4人で集まって発表内容を考えたり資料を作ったのも大変でしたがいい思い出です。

その他

目標を書いたことすら忘れていましたが、書いていたので振り返っておきます。 ishikawa-pro.hatenablog.com

仕事面

引き続き頑張る。
インフラの知識をもっと深ぼる。
多分 Go を書く。

基本的に達成しました。 k8s とか istio も結構普段から扱うようになりました。DB のコネクション周りでずっとあった問題を自分で突き止めて直したりする機会もあったり、確実に以前よりは成長した実感もあります。
Go もそこそこ書くようになり、3つくらい新しいサーバーを書きました。どれも結構いい感じに社内で利用されているので、目標達成といってよさそうです。

勉強面

とりあえず、技術書を読む時間を作る。
去年はあまり読めなかったので、読み方とかを改善しながら読み切る本を増やしたいです。
目標は6冊以上読みたい。

このブログで書いたように、iOS の読み上げ機能を活用するようになり、本を読む量が爆増しました。
ishikawa-pro.hatenablog.com
技術書以外も含めると10冊以上は読みました。なのでこちらも目標達成ですね。

英語の勉強

引き続き duolingo と スピークバディは毎日継続する。 今年はプラスで TOEFL の勉強もして、1回 TOEFL の試験を受けてみる。 特に留学するつもりとかはないけど目標があった方がいいので。 勉強を通して、英語の技術書を読んだり英語の記事をもっとスラスラ読めるようにしたいなと思っています。 1冊は英語の技術書を読んでみる。

duolingo は継続していて、連続記録が500日を超えました。
スピークバーディはやらなくなりましたが、代わりに DMM英会話を始めました。 DMM英会話も最初は習慣化が難しくて、一時期やらなくなっていましたが、やる曜日と講師と時間を固定することで、継続する障壁をなるべく無くしたら継続するようになりました。講師は日本語が分からないので、全て英語で話さないといけないのが最初は緊張しましたが、講師の人は優しいし頑張って言いたいことを汲み取ってくれるので慣れればなんとかなりました。
TOEFL は受けられてないですが、なかなかそこまでのモチベーションを維持できないので、一旦ステイにしようと思います。
英語の技術書も、今はほとんど読み上げ機能に頼って本を読んでいるため、腰を据えて英語の本を読む時間を作るのが難しそうなので、ステイにしようと思います。

ブログ書く

去年はほぼブログ書けてないので、もうちょっとハードルを下げてアウトプットしていく。

これは全くできませんでした。これは今年も目標にしようと思います。

時間管理
目標とは関係ないですが、去年の終わり頃から、ToDo 管理やスケジュール管理をやるようになりました。
今まで適当に頭の中でやっていたのですが、仕事・勉強会・家族 の予定ややることを全て頭の中で管理することは不可能だと気づき、 Google カレンダーと Todoist を使い始めました。
時間管理をすることで、ルーティン化できるところを見つけたり、前日にある程度予定を組んでおくことで、頭のメモリが結構解放されるので、かなり生産性があがりました。
前日に予定を立てるようになってから、自然と朝早く起きられるようにもなったので、本当に生活がかわりました。

まとめ

振り返ってみるとエンジニアとしても変化の多い年でした。
目標を立てたことも忘れていましたが、意外と取り組めていることも多かったのでよかったです。
去年買ってよかった物や、読んだ本も紹介しようと思いましたが、長くなるので、また別の記事にしようと思います。

2023年と2024年4月までの振り返り【プライベート編】

こんにちは。
すっかりブログを書かなくなってしまいました。

毎年振り返りだけは書いていたのですが、それも忙しくて書けていなかったので、色々落ち着いたこのタイミングで書こうと思います。 まずはプライベート編です。
多分、仕事編も別で書くと思います。

同棲開始

2023年2月頃から妻(当時は彼女)と同棲を始めました。
もともと近所に住んでいたのですが、ほぼ僕の1LDKの部屋で半同棲していました。 ほとんど住んでない部屋の家賃を払うのがもったいないのと、ときどき自分の部屋に帰ると、大きめな地震がきたり、深夜に突然火災報知器が誤作動で鳴り出すなどの事件をきっかけに、妻の部屋を解約することにしました。
ただ、僕の部屋だけでは2人で住むには少々狭いのも課題でした。
そこで、同じマンションの部屋をもう1つ借りることにしました。3部屋しかないうちのマンションは、内廊下になっており、3階が僕の借りている部屋、2階が妻の借りている部屋になっています。2階は妻の部屋兼2人の寝室で、3階が僕の部屋とリビングなどがあり、実質2階建ての家に住んでいるような感じです。家賃的には同じエリアで2LDKを借りるのとそんなに変わらないですが、光熱費を2部屋分払っているなどのオーバーヘッドがあります。ただ、2人とも週2日はリモートワークをしているので、ミーティングなどで気を使わなくていいのはメリットです。
1月頃から引越すための諸々の作業をしたり、同棲にあたり妻の実家に挨拶に行ったりしました。
実家に行くのも家族に会うのも初めてだったので、とても緊張しました。妻の引越しも色々ギリギリだったりして、1月2月は結構大変でした。

結婚

2023年12月25日入籍しました。
2023年後半は、それ関連のイベントが大量にあり、本当に大変な1年でした。トピックを色々ピックアックしておきます。

まずは7月16日にプロポーズをしました。すでに同棲も始めており、結婚することは2人で決めていました。妻が、プロポーズされることに憧れていたのと、自分的にも交際と結婚の区切りをつけるような意味合いでプロポーズしました。日付だけ決めて、いく場所は内緒という感じでしたが、事前に分かっていてもしっかり感動して喜んでくれたのでよかったです。

プロポーズを終えて正式に婚約したので、両家へ挨拶へ回りました。
まずは、8月には自分の親へ挨拶をしました。両親は島根の超ど田舎に住んでおり、初回から実家へ行って泊まるのは色々ハードルが高かったので、神戸まで出て来てもらって挨拶をしました。
そして、10月初旬に妻の実家の名古屋へ。会うのは2回目でしたが、結婚の挨拶は緊張しました。 10月末には両家の中間点っぽい京都で両家顔合わせをしました。
7月〜10月は、

• プロポーズ
• 神戸で挨拶
• 福岡でカンファレンスのボランティア
• 結婚式の前撮り
• 名古屋で挨拶
• 京都で両家顔合わせ

というイベントの多さで、精神的にも休まらないのと、金銭的にも大変な時期でした。

最後に12月25日に入籍をして無事夫婦になりました。

結婚式

2024年4月14日に結婚式をあげました。プロポーズもする前に、ゼクシーフェスタという合同企業説明会の結婚式場版みたいなイベントへ行き、あれよあれよと6月に式場を決めてしまいました笑
ドレス選びなどは10月から始まり、具体的な打ち合わせは年末から始まりました。
妻は、付き合っている頃から、結婚式はしっかりこだわりたいと言っていたのとデザイナーなのもあり、演出をはじめ、動画制作から小物までこだわり抜いた結婚式となりました。僕はデザインなどは一切できないため、妻がデザインした紙類をキンコーズやアクセアにとりにいくなどのアシスタント業や簡単な小物制作に徹していました。
結婚式はただでさえ決めることが沢山ありますが、こだわればこだわるほど自分達で用意するものが多くなります。とくに2024年になってから4月までの間、仕事と並行してさまざまな準備をするのは社会人になってから一番大変でした。式1週間前に2人で小物製作の追い込みで徹夜をして、そのまま仕事もしたのは今となってはいい思い出です笑
また結婚式にはとてつもない費用がかかります。妻のこだわりも聞きつつ、費用についてもしっかり管理しておかないといけません。あとどれくらい費用が増えるか、ちゃんと費用を払えるか、無理ならローンを組むか、などが常に頭の片隅にいるのはかなりストレスでした。無事にお金を振り込み終わった時はすごく安心しました。
そんな大変な結婚式でしたが、当日は参加者の皆さんにも楽しんでもらえたし、こだわりにもちゃんと気付いてもらえていい結婚式になりました。

まとめ

振り返ってみると、全て1年以内にあったことだとは思えないくらい色々ありました。
あと、毎月2人で振り返りをして notion に議事録を残したりしているのですが、振り返りブログを書くときの手助けになって良かったです。日々の不満を溜め込まないためにもおすすめです。

色々大変な1年だったので、今年は夫婦でゆっくり旅行とかもしたいなと思います。

iOSの読み上げ機能で本を読むと捗る話

こんにちは。
ここ1ヶ月半くらい仕事が忙しくて、あんまりブログの更新ができていませんでした。
今日は、会社の上司に教えてもらった読書の方法についてです。
ぼくはこの方法で本を読むようにして、本を読む時間を爆増させることができました。
やってる人は結構いそうですが、色々な人におすすめしたいのでブログにまとめておきます。

これまでの読み方

技術書を効率的に読むために、これまでいろいろ試行錯誤してきました。
たとえば、↓の記事で書いたように精読しすぎないようにして読み進めて、1冊に時間をかけすぎないようにするなど意識していました。
ishikawa-pro.hatenablog.com

また、物理本の方が個人的に読みやすいので、電子書籍をやめて今年から物理本に回帰したりもしていました。

教えてもらった方法

会社の上司に教えてもらった読書方法は、電子書籍を iOS のアクセシビリティにある「読み上げコンテンツ」機能を利用し、音読してもらう方法です。
上司はこれを利用してビジネス書などを読んでいるらしいです。

やり方は簡単で、

1. iOS の「設定」アプリで「アクセシビリティ」の項目に行く
2. アクセシビリティのページにある「読み上げコンテンツ」の設定に行く
3. 読み上げコンテンツの設定で、「画面の読み上げ」を有効する

これだけです。

読み上げコンテンツの設定方法

設定が終わったら、 「kindle」 や 「ブック」アプリで読みたい本を開いて、指2本で画面上部から下へ向かってスワイプすることで、読み上げが開始されます。
開いているページの読み上げが終わると、自動で次のページへ移動して読み進めてくれます。

読み上げ機能で本を読むメリット

個人的に感じているメリットは3つあります。
1つ目は、当たり前ですが自分の目で読まなくてもいいので、移動しながらや家事をしながらでも本が読める点です。
紙でも電子でも、本を読む際は自分の目で読む必要があるため、基本的に本を読んでいる間はそれ以外のことはできません。しかし読むという行為を機械にやらせることにより、音声によって受動的に内容が入ってくるため、他のことをやりながらでも本を読めるようになります。

2つ目は、本やタブレットなどを使う必要がなく、 iPhone とイヤホンがあればいい点です。技術書はスマホサイズの画面だと小さすぎるため、本かタブレットで読む人が多いと思います。
そのため、通勤中や外出先でも本を読みたい場合は、従来の読み方だと本かタブレットを持ち歩かないといけませんでしたが、読み上げ機能の場合はそれが不要になります。
スマホは大抵どこへ行く時も持ち歩いてるので、ちょっとした空き時間ができた時などにも本を読み進められるようになり、読書時間をさらに捻出できるようになります。

3つ目は、人によると思いますが、僕は音声で読み上げてもらった方が、普通に読むよりも集中して読書できることに気づきました。
僕は、人の声が頭に入ってきやすい体質なので、読み上げてもらった方が逆に他のことに気を取られなくて集中して本を読むことができる気がします。
また、文字を読むという行為自体が意外と集中力とエネルギーを使うようで、それを機械にオフロードすることで読書する心理的障壁を下げて、読書する機会が増やせたと思います。

向いている本

全ての本が読み上げで読めるわけではありません。
技術書でもサンプルコードが多いような本だと読み上げには向いていません。
文字が多い系の技術書やビジネス書などがいいと思います。
あと、ウェブ上の記事なども読み上げに向いていると思います。
safari のリーダー表示を使って、コンテンツに関係ない文章をなるべく減らすことで読み上げ機能が利用できると思います。(ぼくはあまり使い込んではいない)

自分の読書時間の変化

まずは通勤中の読書時間の変化についてです。
僕は会社まで、ドア to ドアで30分くらいのところに住んでおり、バス5分+電車10分+徒歩15分 という内訳です。
今までのやり方だと、バスと電車の時間しか本が読めなかったので、移動時間の半分以下くらいしか本が読めていませんでした。
しかし読み上げ機能のおかげで、歩いている最中でも本が読めるようになり、通勤中全ての時間を読書に充てることができるようになりました。

また、何かをしながら読書をすることができるようになったため、朝起きて会社に出るまでの支度をしている30分間くらいも本が読めるようになりました。
あとは、会社で一人でご飯を食べる時や休憩でコンビニや会社のカフェスペースに行く時なども読書にあてることができるようになりました。

そういう感じで、何かと並行して本を読むことができるようになったので、毎日トータルで1~1.5時間くらいは本を読むことができるようになったと思います。

その他

読み上げ機能の機械的な音声で本が読めるか懐疑的な人もいると思います。
しかし iOS16 から siri の声がアップデートされており日本語をかなり流暢に喋るようになりました。 そのおかげで、本もかなり自然な喋り方で読み上げてくれるようになっています。
音声は３種類とそれぞれに拡張版が用意されているので、聞き取りやすい声を探してみると思います。

あと、以前ブログで紹介した HUAWEI Eyewear との相性が抜群なのでおすすめです。
メガネをかけていればいつでも読書が開始できるし耳を塞ぐ必要がなくなるので読書体験があがります。
ishikawa-pro.hatenablog.com

実際に読んだ本

システム運用アンチパターンを読み切りました。
電子書籍で半分手前くらいで読むのが止まっていましたが、読み上げ機能を使い始めて１週間以内くらいで読み終わりました！
内容も良かったので別途ブログにします。
www.oreilly.co.jp

まとめ

今日は、iOSの読み上げ機能を使った読書術について紹介しました。
このやり方を教えてくれた上司には大感謝です。
ぼくは積読を猛スピードで消化中なので、みなさんもぜひ試してみてください！

1月の振り返り

こんにちは。
あっという間に1月がおわりましたね。
この記事を書いている今、僕は風邪をひいてお休みしています。
ちょっと体調も落ちついて来たので、1月の振り返りでも書こうと思います。

仕事

今年の目標で書いていた Go を早速書き始めました。
Go は A Tour of Go を１周したくらいの知識でしたが、まあまあ手に馴染んできました。
Go は言語仕様がシンプルなのと、 TypeScript ほど型システムが複雑ではないので、すごく学習コストが低くていいなと思いました。
あとは、 go fmt でコード整形もしてくれたりして、普段 Node.js を書いている身としては eslint や tsconfig の設定などをするのが嫌いなので、コードを早く書き始められていいなと思いました。

あとは、大きめのリリースがあって、それに合わせて社内基盤の負荷対策をせっせとやっていました。
こちらは何とか乗り切ってひと段落したのでよかったです。

調べたこと

Platform Engineering について調べました。
最近はサービス開発に直接関わることは少なく、社内のエンジニアがなるべく早くサービスを開発できるように、社内の開発プラットフォームを改善したりしており、それってどういう分野なんだろうと調べてみたのがきっかけです。
Platform Engineering という言葉を知ったことで色々調べやすくなったのでよかったです。
ishikawa-pro.hatenablog.com

技術書

今月は結構たくさん本を買いました。

実践Redis入門

業務で Redis を使ってますが、しっかり Redis について学習したことがないなと思っていたので購入してみました。
すでに知っている基本的なところは軽く流して、 面白そうなところだけ読んでいます。
さっと読めて内容も実践的だったのでよかったです。
gihyo.jp

実践Node.js入門

普段 Node.js を書いていて、タイトル的に面白そうだったので買ってみました。
3年くらい Node.js を書いてるので、流石に知らないこととかはなかったですが、内容的にはすごくよかったので、これから業務で Node.js を書く人とかにはすごくおすすめだなと思いました。
gihyo.jp

実用Go言語

去年、Go を書くにあたり1冊本を読みたいなと思って買いました。
ぼくの大好きな Real World HTTP の著者である渋川さんが著者に入っていたので、きっといい内容だろうと思って買いました。
基本的な文法は知った上で、Go らしく書くにはどうするか、などが書かれており、ちょうど自分が読みたい内容でした。
まだ読み切っていないので、早めに読んで仕事に活かしたいなと思います。
www.oreilly.co.jp

ソフトウェアアーキテクチャ・ハードパーツ

テックリード的なポジションでもあり、アーキテクチャの相談やレビューをすることも多いのですが、色々なトレードオフを加味した上でより適切なアドバイスができたり、自分が設計する時に役立てたいなと思って買ってみました。 現在積読リストへスタック中なので、2月中には読み始めたいなと思っています。
www.oreilly.co.jp

Googleのソフトウェアエンジニアリング

仕事に関わってくるエンジニアの数が、ここ1〜2年でまあまあ増えてきました。
自分自身も単にコードを書くだけでなく、コードや設計のレビューをしたり、他のエンジニアに仕事を振り分けたりすることも増えて来ました。
そういう人が増えたり、自分のポジションが上がったりした時に、効率的にものごとをすすめたり、自分以外の人も巻き込んでうまくスケールさせるために、Googleではどうしてるのか、とかが気になって買ってみました。
まあまあ分厚い本なので、まずは1章を読んだ後、目次を見て気になった項目から読み始めています。
アメリカカルチャーのネタ的な部分が、日本人の僕には分からないので、たまに何を言ってるのか分からないところもありますが、読み物的に面白く読んでいます。
www.oreilly.co.jp

たくさん並行して読んでいますが、その日の気分に合わせて本を選んで、精読しすぎずに頭に index を貼るように読み進めることで、モチベーションを維持しています。
あとは、電子書籍をやめて物理本に回帰したので、目の前に本があることで、読もうという気持ちになりやすくなりました。
ちゃんと読み終わった本は感想などを記事に残そうと思います。

物理本といえば、渋谷のMARUZEN & ジュンク堂が東急百貨店の閉店に伴い閉店してしまいました。
技術書の品揃えがよく、会社や家からのアクセスもよかったので、重宝していたのですごく残念でした。
電子書籍の時代だから物理的な本屋さんはなかなか厳しいんですかね。。

【ご挨拶】
本日19時をもって、当店は閉店いたしました。
2010年にオープンしてから本日までの12年間、当店をご利用いただき、本当に、本当にありがとうございました！
いつかまた渋谷の地で皆さまにお会いできることを信じています。
従業員一同#12年間のご愛顧に感謝を込めて pic.twitter.com/MwGhnJ2DgM

— MARUZEN＆ジュンク堂書店　渋谷店 (@junku_shibuya) 2023年1月31日

まとめ

とりあえず風邪を治して2月も頑張ります。
あとは何冊か本を読み切れるようにしたいと思います。

Platform Engineering とは

こんにちは。
もう１月が終わりですね。
今日は Platform Engineering についてちょっと気になって調べていたので、ついでに自分なりに簡単にブログにまとめみます。

調べたきっかけ

僕はバックエンドエンジニアとして、ここ１年くらい、社内のサービス開発プラットフォームの開発・運用などをしています。
特に最近は SRE の人たちと一緒に プラットフォームの改善や CI/CD の改善などについて取り組んでいます。
そういうプラットフォームを作ったり改善したりする上で、どういうことを考えながら取り組んだらいいのかとかを色々調べていたら Platform Engineering という言葉が最近流行っているようだったので、気になったのがきっかけです。
あとは自分がやっていること的にバックエンドエンジニアなのか？とちょっと疑問に思ったのもきっかけの一つです。
特に肩書を気にしてるわけではなく、ロールモデル的なのがあるといいなと思って色々調べたという感じです。

Platform Engineering とは

いろいろなサイトから引用してみます。
Gartner ではこう紹介してあります。

• 再利用可能なツールとセルフサービス機能を実装し、インフラストラクチャ・オペレーションを自動化することで、開発者のエクスペリエンスと生産性を向上させる
• アプリケーションの再利用可能で構成可能なコンポーネントとサービスを活用する
• 標準化されたツールとコンポーネント、そして自動化されたプロセスを利用できるというメリットがある

www.gartner.co.jp

PlatformCon という Platform Engineering に関するカンファレンスを運営しているコミュニティのサイトがあり、そこではこう説明されていました。

Platform engineering is the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era. Platform engineers provide an integrated product most often referred to as an “Internal Developer Platform” covering the operational necessities of the entire lifecycle of an application.

プラットフォーム エンジニアリングは、クラウド ネイティブ時代のソフトウェアエンジニアリング組織のセルフサービス機能を可能にするツールチェーンとワークフローを設計および構築する分野です。プラットフォーム エンジニアは、アプリケーションのライフサイクル全体の運用上の必要性をカバーする「Internal Developer Platform」と呼ばれる統合された製品を提供します。

platformengineering.org

The Global Home for Platform Engineers

↑で書かれているように Internal Developer Platform (IDP) も他のサイトや記事などをみても、セットでよく語れている印象でした。
ちなみに IDP のサイトもあります。

internaldeveloperplatform.org

Gartner の2022年のハイプサイクルで Platform Engineering は黎明期の真ん中くらいにあり、 Plateau will be reached は水色なので 2 ～ 5 年くらいで普及するとの予想みたいです。

www.gartner.com

つまり、自社のエンジニア組織にフィットした、アプリケーションの構築方法やデリバリー方法・環境を提供して、アプリケーションエンジニアがプロダクト開発に専念して高速に本番環境へリリースできる仕組みやサイクルを作って上げるのが Platform Engineering なのかなと思いました。

SRE と Platform Engineer の違い

ambassador の SRE vs. Platform Engineering という記事が面白かったです。
www.getambassador.io

この記事によると、 Platform Engineer は、ソースコードから本番環境までのソフトウェア開発ライフサイクル全体を常に見ていて、開発から本番環境へのデリバリーが高速にされるワークフローを構築することに責任を持つようです。
また、ベストプラクティスやプラットフォームの最適な利用方法について、アプリケーション開発者を教育することも役割の１つのようです。

一方 SRE は、SLO(サービスレベル目標) を設定して、SLOが達成できるようにシステムを組む。そして、監視、インシデント管理、単一障害点の排除、障害の軽減などを含むプラットフォームとワークフローに進化させるために取り組む。

記事にある図がイメージしやすくてよかったです。

その他関連しそうなこと

Microsoft と Alibaba Cloud が共同でやっている Open Application Model（OAM）というプロジェクトがあります。
これは、 k8s はアプリケーションエンジニアへの負担が大きいという課題を解決するために提案された、k8s などのプラットフォームに依存しない、アプリケーションに特化したスペックです。 oam.dev

そして OAM に準拠して作られたプロダクトに KubeVela があります。

kubevela.io

これらは、 アプリケーションエンジニアが k8s などのインフラを意識せずに、サービス開発に専念できるようにするためのプロダクトなので、 Platform Enginnering を手助けするツールだなと思いました。

まとめ

自分のやっていること・やりたいことを、なんとなく言語化できたような気がしてちょっとすっきりしました。
去年作った社内用の Next.js ホスティング基盤なんかは、Platform Engineering の一部なのかなと思います。

cam-inc.co.jp

developers.cyberagent.co.jp

Platform Engineering には、ある程度インフラの知識も必要だし、ソフトウェア開発の知識もないと開発速度や開発者体験の向上はできないなと思ったので、どっちも頑張って勉強しないとなと思いました。

2023年の目標

2022年の振り返りで来年の目標とか書いてなかったので、技術面での目標を書いておきます。

仕事

引き続き頑張る。
インフラの知識をもっと深ぼる。
多分 Go を書く。

勉強

とりあえず、技術書を読む時間を作る。
去年はあまり読めなかったので、読み方とかを改善しながら読み切る本を増やしたいです。
これを実践する。

ishikawa-pro.hatenablog.com

目標は6冊以上読みたい。
あとは、オフラインの勉強会で面白そうなのがあれば参加してみる。

英語の勉強

引き続き duolingo と スピークバディは毎日継続する。
今年はプラスで TOEFL の勉強もして、1回 TOEFL の試験を受けてみる。
特に留学するつもりとかはないけど目標があった方がいいので。
勉強を通して、英語の技術書を読んだり英語の記事をもっとスラスラ読めるようにしたいなと思っています。
1冊は英語の技術書を読んでみる。

ブログ書く

去年はほぼブログ書けてないので、もうちょっとハードルを下げてアウトプットしていく。
去年は毎週ニュースレターを書いてみた時期もあったけど大変だったので、もうちょっと緩くやっていく。
目標は月3回投稿。

以上、がんばります。

技術書の読書方法メモ

とりあえず雑にでもアウトプットをしてみようという取り組みで、ちょっと調べたこともメモしてみます。
今回は技術書の読み方について。
去年は読み切れた技術書が少なかったので、ちょっと読み方とかも変えてみようと色々調べてみました。
今まではすみずみまで読み切りたくて時間とエネルギーを費やして読んでいました。
しかし、「データ指向アプリケーションデザイン」みたいな分厚くて内容も難しい本を読もうとすると、とてもそのやり方だと読み切れなかったです。
なので、今年はもうちょっと効率重視で読む方法とかを身につけたいなと。

インデックス読書術というのが、なんとなく良さそうだなとおもいました。
qiita.com

blog.jnito.com

自分も技術書を読んでいて、頭に本の内容のインデックスを貼っている感覚はよくわかります。
業務中に、これについて前にあの本のあそこらへんで読んだ気がするなと本を取り出すことも時々あります。
ただ、今までは精読した副産物としてインデックスができていました。これからはインデックスを張ることに重きを置いて1度読み、必要になった or 興味があるところは精読するという感じでやってみようかなと思います。

今は、Goの勉強をしていて、「実用 Go言語」を読んでいるので、この本からそういう感じで読んでみようかなと思います。
www.oreilly.co.jp

あとは、去年買って読み切れてない、「システム運用アンチパターン」と www.oreilly.co.jp

さらに前に買って読み切れていない、「データ指向アプリケーションデザイン」は読みたいなと思っています。
www.oreilly.co.jp

あとは、それ以外に最低3冊は技術書を読みたいなと思います。
うまくいくかわからないので、試行錯誤しながら途中経過とかもブログにかけたらなと思います。

それでは今日はここまで。