四半期ごとの個人OKR振り返りです。

2020年7〜9月は、プラットフォームエンジニアとして必要な技術要素を学びつつ、レバレッジの効くプラクティスの中でも特にDevOps/SREを学ぶのが主な内容でした。

振り返り対象の個人OKRはこの記事2020年4〜6月ふりかえり 〜より抽象的なプラットフォーム仕草を身につける〜で立てています。

OKRの振り返り

3段階で見ていきます。

  • できた
  • 微妙
  • できなかった

Objective 1

プラットフォームのインフラを支える技術の基礎力向上

Key Result 1 【できた】

Terraformの概念、書き方を理解しデバッグできる

  • 技術書典9で『GCPで学ぶTerraform』を書く

本は「基礎編」になってしまったものの、出展できました。

技術書典9の『Google Cloud Platformで学ぶTerraform 〜基礎編〜』の振り返り #技術書典

直近の四半期は、Terraformのステートのデバッグができないと終わり!!!という状況でした。最初は詳しい同僚にコマンドをレビューしてもらいながらおそるおそるやっていたオペレーションももう大丈夫です。

また、振り返り記事でも触れているように、執筆と読書を通じて「学びのフォーム」自体を体系化できるようになってきたと思います。

個別の技術を理解する。目の前の本を締め切りに間に合わせる。どちらもこのKR達成には不可欠です。

ただ、長期的に大事なのは、学び方自体を改善し続けることや、新しいやり方に挑戦して習得し、これまでと違うスピードを体感することです。

Key Result 2 【できた】

DevOpsのプラクティスを身につける

チームの先人たちが組織に根付かせてくれたDevOpsやSREの文化はとても多く、日々学びがあります。しかし、新しく自分が何かを導入するとき、運用を考えるときの共通言語となるため、それらの起源を自分でたどるのはめちゃくちゃ有益です。

KRのアクションアイテムの中では、特にサイトリライアビリティワークブックがよかったです。SLI/SLO/SLAの考え方やエラーバジェット、ポストモーテムなどはもちろん、大規模システムの継続的設計改善(NALSD)の話や負荷分散の話など第二部の話が参考になりました。具体的事例なので、業務で活かす場面もイメージしやすいです。ただ、読み終えられなかったので次Qも継続します。

試験は無事でした。Q開始時点ではリモート受験非対応でしたが、途中で受けられるようになったので9月末受験で予約しました。

CKAD、CKA、Professional Cloud Architectとすべて自宅で受けれてよかったです。教材はすべて英語だったものの、本番の問題は日本語でした。一方で、Professional Cloud DevOps Engineerは日本語未対応なため、初英語受験。これからは英語でいいかなぁと思いました。教材も業務も英語です。

準備で読んだ『Google Cloud Professional Cloud DevOps Engineer Exam - All in One Guide: Get Certified Efficiently in Google Cloud!』はオススメできません。説明内容は可もなく不可もなく(英語はおかしいし、別の本のフォーマットがかなり残っているので推敲してほしい)ですが、各章や最後に付属しているテスト問題・解答ともに品質が厳しいです。SRE本とOperationsの公式ドキュメントを読むとよさそうです。

今回の目的に合う形で、複業で手を動かす機会はありませんでした。しかし、8月から開発しているCloud Runでホストするアプリケーションでは、TerraformとGCPのCI/CDサービスやログ、モニタリング系サービスなどに触れることができました。運用するモチベーションのある、コントローラブルな個人サービスのありがたみを感じました。

実務の経験が足りないと感じる部分は多いので、経験するためのアクションはとっていく所存です。

Key Result 3 【できた】

学び方の改善

以前途中まで読んだ本ですが、前Qに「知的生産のフォーム作り」の必要性を強く感じたので読み直しました。本に書いてあることは変わりませんが、本を読む自分の経験は絶えず変わります。本の内容を理解するに足る経験をある程度積んだ状態でその本に出会えると効果的かなぁと思います。本で提示されるモデルを自分の経験で検証できない場合、知識としては増えても自分の中に構築しているモデルがブラッシュアップできません。

読む本のリストはNotionにまとめました。

Platform Engineerへの闘争🐸

区分は便宜的ですが、現在目指している一人前プラットフォームエンジニアに必要と思われる技術要素やプラクティス、思考を含めています。どうなったら、何ができたら一人前か、一人前になってどんな問題が解決したいのかはあまり考えていないので、あくまでも方向性の話です。OKRの中にいい感じに組み込みます。

ベースはtcnksm/recommended-books-2020です。実際に読んでみると、学びの多い本(プラットフォームチームで働く上でレバレッジが効く)ばかりに思います。たぶんプラットフォーム周りのエンジニアでなくても学びが多いです。

Objective 2

より気持ちよく暮らす

重要だが緊急性が低く、積極的にやる気も起きないので放置していたことを片付けます。

Key Result 1 【微妙】

断捨離と整理

  • いらない服捨てる
  • 紙の本減らす

紙の本はたくさんメルカリで売りました。新しく本を買う場合ほとんど電子にしていた一方で、本棚は2列詰め込んで放置している状態でした。(文庫本以外)そういう状態が解消しました。

服の断捨離には着手できず。外出しなくなり、場所を占拠しているだけ率はさらに高まっているので減らしたいものです。

古くなったTシャツは一掃して10YCとかで揃えようかなとか思っています。

Key Result 2 【できた】

猫たちとのよりよい共生

  • 大きいトイレに交換する
  • ラムちゃん去勢
  • ふわふわくん外散歩できるようにする

トイレはメガトレーというかなり大きいものを購入しました。

ふわふわくんけっこう大きいんです。おかげでメンテコストも下がり、猫も人間も快適です。

ラムちゃん去勢直前の1週間は壮絶な戦争でした。

ふわふわくん外散歩はまだかなわずです。抱っこして供用の廊下を歩きはするんですが、それを求めて玄関で鳴くなどしています。

Key Result 3 【できなかった】

ume, yamazoeに行く(状況が許せば)

状況が許さなかったので行ってないです。クラウドファンディングのチケットがあるので、来年6月までには…

Key Result 4 【できた】

冷蔵庫買い換えるか検討する

もうちょっと今のにがんばってもらいます。

ログ

OKRとしては追ってないものの、記録しておきたいことのコーナーです。

読書

記事中ここまでで書いた以外のものです。

Cloud Runを触る中でSandbox: Unsupported syscall系のエラーに何度か出会いました。サンドボックスを含むコンテナランタイムやシステムコールもそろそろ学ぶタイミング!Goで学べる!ということで、就寝前の紙本枠(ブルーライト避けたい)で少しずつ読んでいます。きっと実装力++です。コンテナは別途。

プラットフォームエンジニア本の中ではまずこれ!と言われたので素直に読み始めました。具体的設計手法より一段抽象的な「設計する上で避けたいこと」が書かれていて、顧客が求めていたものっぽいです。

今年1月からプラットフォームエンジニアへの闘争をする中で主要な要素技術を見てきましたが、次Qでは設計に足を踏み入れる予定です。その中でこの本は大事な役割を果たしてくれそうです。

オーディブルで利用できるようになったので、久々に復習しました。「何を解くべきか?」を見誤らないことで、ゼルダをプレイする時間が増やせます。

同僚がすごいリノベをやり遂げててすごかったので影響を受けました。

あと著者ちきりんさんが「職業とか人生とかと同じで、人気とかスペックとかで決めてしまうこともあるかもやけど、自分がどう暮らしたいかを決めろ」みたいなことを言ってて(元Tweet見つけられず)、最初はピンときませんでした。でも、自分がスペックと写真の差で探そうとしてて、なるほど至言やなと思ったので、思考過程を追ってみることにしました。

首都圏から出るときに失うものの知見を得られました。中身あんまり覚えてないなぁ…。

イシューからはじめよ ― 知的生産の「シンプルな本質」』に包含されてそう。

英語

7〜9月の英会話(NativeCamp)の受講状況はこんな感じでした。

  • 7月: 31回、13時間7分
  • 8月: 33回、13時間54分
  • 9月: 25回、10時間10分

日次・週次MTGのファシリテーションの中で話すのがちょっと楽に感じる場面や、これまで聴きとり辛かった人の話が聴きとりやすくなったりする場面が出てきました。設計上の問題を解決するために、テーマを設定してディスカッションするような機会も2〜3人だと何とかなるっぽいです。日常会話はダメです。

英語単独で解決できるものではないけれど、楽に感じる場面が増えるのは心理的にいいことです。

もし英会話のレッスンが「会話」的な意味で億劫な人がいたら「カランメソッド」がオススメです。2回早口で質問されるのに対し、答えを(先生のサポートも得つつ)代名詞で省略せず喋るをひたすら行うものです。

レベル別に12分冊になっていて、レベルのマッピングはつぎのようになっています。


https://callanonline.com/english-course より)

オンライン英会話のNativeCampではカランメソッドをサポートしています。レッスン予約は1週間先までできるので、レッスン終了時に1週間先の分まで予約するようにすると途切れません。

実験を経て、祝日・有給も関係なく火、木、土、日の9:30〜10:30に2レッスン受けるのが定着しました。朝から試験があったり、ドタキャンされたりした日はスルーしたり、代わりにライティングの本を学んだりしています。

登壇

久々に登壇しました。今年初の社外登壇です

ホームサウナである金春湯さんが提供してくださっているAPIを利用し、混雑状況を可視化しているお話です。

サウナイキタイさんと何かできないかなぁと思ったりもしています。開発に加わりたい思いは届きそうにない気配を感じています。

ゼルダ

前Qからやり始めたゼルダの伝説 ブレス オブ ザ ワイルド。通常編の追加コンテンツもとうとうやり終えました。

次QのOKRの1つであるゼルダ無双 厄災の黙示録が発売されるまで、マスターモードを楽しみます。

業務のみならず個人でもOKRを追いかけ、とにかくいろんな誘惑を断ち切りOKRに全振りする。みたいな人生はしんどいです。一方で、OKRの時間以外に何をするのか考えたときに情熱を注げるものも思い浮かばない。ずっと続けていた音楽もやめてしまった。

そんな中で感動するほど楽しいと思えるもののひとつがゼルダでした。

今後の話

2020年10〜12月のOKRです。

Objective 1

設計よくしていこうな

今年学んできた個々の技術を組み合わせて、保守性と信頼性が高いサービス設計を学び、実践する。

Key Result 1

実践的な設計を3つ世に送り出す

・12月の技術書典10で『Google Cloud Platformで学ぶTerraform 〜実践編〜』を執筆する
・『サイトリライアビリティワークブック ―SREの実践方法』を読む
・Professional Data Engineerを受ける
・『Official Google Cloud Certified Professional Data Engineer Study Guide』を読み、模試を解く
・『A Philosophy of Software Design』を読む

このKRがも最重要なため、KR2、KR3が厳しく感じたら迷わずKR1を選ぶ。

Professional Data Engineerは実践編のログとデータパイプライン周りのインプットに、『A Philosophy of Software Design』と『サイトリライアビリティワークブック ―SREの実践方法』はTerraformのモジュールやTerraform化するアーキテクチャ設計を説明する言葉のインプットに位置付けます。

Key Result 2

Cloud Runのユースケース集を世に送り出す

・Serverlessなカンファレンスがあればワークショップ、なければZennなどで出す
・『Building Serverless Applications with Google Cloud Run

技術書典9で『Google Cloud Platformで学ぶTerraform』を書き終えていれば、機能も出揃ってきたし、使ってるし、Cloud Runを体系的に整理しようと思っていました。書き終えられなかったものの、両立できないこともないのでやってみることにします。

Key Result 3

KompalWeatherをGAに

  • production用のプロジェクトに移す
  • BigQuery MLで混雑状況予測
  • UIを生やす
  • ログ・エラーレポート周り改善

技術的な実験をしつつ、自分以外のユーザーを見つけようと思います。

Objective 2

Key Result 1

嫁氏のストレスを軽減する

Key Result 2

ミファーを護り抜き、あの頃のように遊びに行く

11月20日です。休みます。

Key Result 3

旅行する

ふるさと納税奴で石川県に行くか、GoToの波に乗るか、それともシー=>ミラコスタ=>ランドの夢を叶えるか…日常の物理的範囲が狭まる中、非日常を得たいです。

Key Result 4

(不確定要素はある中で)もし居住エリアに職場の制限がないなら、どこにどう住むのがよいか?みたいな話を最近よくします。その中で今の家はよいという話や、もっと広い家に住みたいという思いがあります。よい椅子を買ったのでもう十分という気持ちもあります。

更新タイミングも近いので、どうするか2020年時点の結論を出します。

なんとなく最近公私問わずワクワクした気持ちになることや感情が揺さぶられる体験が少ない気がしています。何もせずに勝手に生えてくるものでもないと思うのでなんかしよう。

四半期ごとの個人OKR振り返りです。

2020年4〜6月は、プラットフォームエンジニアとして必要な技術要素であるGCPとTerraformを学ぶのが主な内容でした。

振り返り対象の個人OKRはこの記事2020年1〜3月ふりかえり 〜HCLエンジニアとしても闘争〜で立てています。

OKRの振り返り

3段階で見ていきます。

  • できた
  • 微妙
  • できなかった

Objective 1

プラットフォームのインフラを支える技術の基礎力向上

Key Result 1 【微妙】

Terraformの概念、書き方を理解しデバッグできる

  • 技術書典9で『GCPで学ぶTerraform』を書く
  • 『実践Terraform』『Terraform Up & Running』を読んで理解が必要な見取り図を描く

今期は目次を作るところまででした。OKRを立てた時点では、つぎの技術書典を7月と想定していました。しかし、次回は9月という公式アナウンスがあったので、それを目指して書こうと思います。

少しTerraform関連の本を読んだり、GCPを学んだりした現段階ではつぎのような目次を考えています。

1 Why

なぜTerraformが必要なのか
解決する課題

  • Why IaC
  • Why Terraform
  • (Why GCP)

2 What

  • Terraformを使ってできること
  • 使い方の調べ方
  • GCPのデフォルトとTerraformのデフォルト
書き方
  • 文法
  • HCL?

機能

なんのためにあるのか
やってはダメなこと

プロバイダー
* tfsatate
* terraform import
* terraformer

3 How

準備
  • CLI
  • Terraformのバージョニング
  • VSCodeのサポート
  • tflint
ハンズオン
  • あるアーキテクチャを作っていく
    • 3 layered
  • テンプレート
    • Module
    • Microservice、プラットフォーム
    • ベストプラクティス or Opinionatedのテンプレート化
    • 早めに楽な運用にたどり着くためのガイド、複雑さを導入したいわけではない
  • GCP上のベストプラクティス
    • Log
    • データ分析
    • パイプライン
    • 権限管理 IAM

コンテナ触れたいが、KubernetesのYAMLとの住み分けとかの話になりそう
VM -> サーバーレス
GCE -> GKE -> App EngineかCloud Runなど

4 Operation

  • CI/CD
    • ローカル
    • GCP CI/CDサービス
    • CI/CD SaaS
    • GitHub Action
  • tfstate分割
    • すでに動いてるの安全に分割する
  • tfnotify
  • Providerアップデート
  • 開発環境・本番環境
  • デバッグ
    • TF_LOG=DEBUG
    • プレイグラウンド

フルで書くのは厳しそうなので、特に興味あるものや、ここにないけど決定的に必要な要素などあればぜひ教えてください!

読んだ・読んでる本。

Why Terraform、Why IaCがめっちゃみっちり書いてあってすごい。

Key Result 2 【できた】

GCPの全体像を把握する

GoogleさんのProfessional Cloud Architect試験に合格しました。自宅からのリモート受験です。6/28に受験し、まだ最終結果メールがきません。

当初はGCPのコンピューティング、ネットワーク、ストレージの目次程度が頭に入れば試験は受けなくてもいいかなと思っていました。しかし、6月頃にいざ本格的にTerraformの本の準備を始めるにあたり、もう少し足腰鍛えた方がよさそうと思い6月はGCPの勉強をすることにしました。

また、同時期に複業でGCPのアーキテクチャなどの相談に乗るお仕事もいただいたので、腕力向上必須でした。

準備過程では、上記のProfessional Cloud Architect Certification 2020を一通り見ました。これは星5つで評価を求められたら星1つです。結局最後まで見てしまったのが悔やまれます。

Official Google Cloud Certified Professional Cloud Architect Study Guide』はとてもよかったです。章末問題や模試2回分は、本番より難易度が低かったものの、アプリでの復習がとてもやりやすかったです。各サービスの説明は細かいわけではなかったですが、「アーキテクト」として働くための視点の持ち方がイメージでき、今後の仕事にプラスになりそうでした。

他にも、複業の準備も兼ねてつぎの本を拾い読みしました。試験文脈ではないですが、役立ちました。

機械学習系は置いておくにしても、GCP文脈でもう少しデータプラットフォームやDevOps系の話題に馴染んでおきたいなぁと感じています。

Key Result 3 【できた】

『KnativeとIngress Gateway』の完成

  • レビューコメントをもらっている内容を一通り反映する
  • 今あるissueをすべて閉じる

だいぶ追記し、Boothで第2版を発売中です!

KnativeとIngress Gateway 〜Ambassador、Contour、Gloo、Kourier、Istioの比較〜(PDF、ePubセット) #技術書典

初版との差分はこちらにまとめています。

増補・改訂にあたっては、toVersusさんにたくさんフィードバックいただきました。ありがとうございました!!

商業版も、インプレスR&Dさんから2020年7月10月発売です。

KnativeとIngress Gateway Ambassador、Contour、Gloo、Kourier、Istioに見出すEnvoyコントロールプレーンの実装パターン

あくまでも「KnativeでなぜIngress Gatewayが差し替えられるのか?」という自身の疑問に答えるための本です。結果的にAPI Gateway、Envoyなどさまざまな発見がありました。この喜びを、よりたくさんのエンジニアと分かち合うことができたら嬉しいです。

推敲過程でいろいろな本にお世話になりました。

Objective 2

生きてる実感を得て心をワクワクさせる

Key Result 1 【できた】

ゆったりとした時間を過ごすための自分なりのルールを作る

「ゆったりとしていない」と感じるのは、自分で立てた目標とはいえ目標以外に向いた興味から目を背けていたからです。限られたプライベートな時間を最大限自身の成長に繋げるためのストレッチな目標を立て、リソースをそこに集中するのだから必要な犠牲かもしれません。それでも持続できなければ元も子もないので、「スイスイ検証水曜日」というのをはじめました。

スイスイ検証水曜日

興味持ったことは手を動かして検証して良い枠を週1設けます。数時間でアウトプットまでたどりつくのはなかなか難しいですが、結果的に業務に流用したり、複業に活かしたりしながらワイワイできて楽しかったので続けようと思います。

ちなみにこの記事はスイスイ検証水曜日のアウトプットの一部です。

Terraform Kubernetes Providerとkindで試すNetworkPolicy

あと、ゲームを解禁した結果、(やや罪悪感はあるものの)楽しみが増えました。同僚に激推しされたゼルダ。面白すぎて、このゲームを知らない状態に戻れなくなるのが少し寂しいです。

Key Result 2 【できた】

趣味と闘争する

  • 体脂肪率12%

noteで書いたこの腹の3ヶ月後のさらに3ヶ月後の世界です。このOKR振り返りを書いている時点で14.6%くらいです。

一時期13%台まで落としたものの、体重は落ち体脂肪率は上がっていく状況になって立ち往生しています。

もろもろの自宅ジム化に必要な器具は揃ったので、数値目標は掲げず、筋トレ週2を継続して体づくりを継続しようと思います。

カロリー計算目的であすけんというアプリを使い始めました。3食記録し、アドバイスがもらえたり、栄養素の内訳が表示されたりします。思ったよりカロリーが足りてなさそうな日が多かったり、ビタミンA・食物繊維が絶望的に足りなかったり、いろいろな気づきがあり改善しました。Fitbitで計測した体重、体脂肪、歩数、などを連動できたり、写真からメニューを登録できたり便利です。

写真のBASE BREAD週4朝、BASE PASTA週1昼か夜も定着しました。

  • 燻製料理を生産できるようにする(from ワクワクリスト

Zwilling(ツヴィリング)社の燻製用の鍋を購入しました。

燻製の基本』という本を読み、燻す木材の種類やそれに合う食材、難易度等があることを知りました。よきです。

クロノ・トリガー好きなら好きかも!と同僚に勧められてはじめました。何回かやったものの、執筆期間に始めたため定着せず…執筆期間後にでゼルダに出会い、今はゼルダのない土日が考えられません。

あと、昔おじさんにもらってやっていたファミコン。くにおくん ザ・ワールド クラシックスコレクションに時代劇が含まれていたのでやりました。

勇者シリーズが30周年を迎えたのを記念し、サンライズが公式YouTubeチャンネルでエクスカイザー全話と他のを5話まで無料公開!テレビで見始めたのは4作目からで、元祖のエクスカイザーは観たことなかったので観ました。

後続シリーズの場面がいろいろと頭をよぎる原点でした。その後、2作目のファイバードも観終わり、今は最終作のガオガイガーシリーズを観ています。在宅勤務になってから昼は勇者シリーズ、夜は最近のやつ(Dr.STONEシーズン1を観終わり、鬼滅の刃を観ている)をご飯を食べながら観るようになりました。

Key Result 3

ワクワクリストを整理する

  • 優先度
  • 何をしたら実現できるか
  • 費用
  • 期間

とりあえずカテゴリタグをつけてみたら、半分が旅行でした。


(旅行系の一部)

今旅行のこと想像しても、何もピンときませんね。いざ実現するとなると、それぞれ1週間休みとらないと厳しいので(ほんまか?)、予約できる状況になったらチケット予約する心積もりはしときます。

そもそもこれを書き始めたのは、OKRに追われすぎてしんどいというのがきっかけでした。Objective 2のKR1がいい雰囲気になってきたところで、この項目にそこまで希望を見出さなくて良くなってきた感があります。よいことです。

今は個人OKRを適度に達成し、プラットフォームを作るチームで挑戦し続け、嫁氏と適度に競争しながらゼルダを嗜み、猫たちを眺め、筋トレし、サウナで整えるならそれで満足です。

在宅勤務に慣れ、サウナも復活したのはけっこうでかいのかもしれません。

ログ

OKRとしては追ってないものの、記録しておきたいことのコーナーです。

読書

記事中ここまでで書いた以外のものです。

自分の興味に蓋をして息苦しさを感じていたときに、マネージャーさんとの1on1で「自己肯定感足りてないのでは?」という話を聞いて読んでみた本です。一連の流れをつぶやいています。

最終的にスイスイ検証水曜日で回収されました。

「OKRと関係ない、自分の好きなことについてnoteに記事を書こう」という動機で書いた記事の1つです。今の今まで、4月に突然noteに記事を書き始めた理由を忘れていましたw

サウナは自分にとって大事なライフワークの1つ。自分以外のサウナ好きがサウナについて語るのに触れながら、自分にとってのサウナを考えてみようと思って読みました。

『さうなと』を読んで

前Q読んでいた『遅いインターネット』にも、さきほど登場した『20歳の自分に受けさせたい文章講義』にも評論家としての吉本隆明さんが登場します。よしもとばななさんのお父さんなんですね。

何となく気になって、何かしら本を読んでみたいと思って検索したらこの本に出会いました。たぶんこういう本がメインではないです。

よその家の猫の話(生態)ってあまり聞いたことなかったので新鮮でした。吉本さんちの猫は、適当に外にも出かける半野生的な猫さんなだけに余計に。

スポーツ系に限らず、いろんな研究分野が関係しているのだなぁと思いました。科学的とは?の説明から始まるのがいい感じです。

筋トレをしてくれるトレーナーさんの経験で語られる世界からの変遷が書かれてましたが、トレーナーさんもこういうの読んでないのかな?とも思いました。

人生の先輩が語る教訓には真理が含まれてると思います。ただ、大昔から人間は同じものに苦しみ、それが研究されて名前もついていると思うので、研究の成果として受け取る方が好みかもなぁと思いました。

初期案と実際に放送されたデザインが全然違うのが多くて最高でした。

学び方を学ぶのはよい投資と思っています。エンジニアとしての経験(課題とそれに対する解決策の適用)も増えてきたので、目の前の具体的な技術を学ぶのを継続しつつももう少し原則、プラクティス、この分野ならこれみたいなみんなオススメ系の本比率も上げていいのかなと感じました。経験が少なすぎるタイミングで少し抽象度の高い事柄に触れても実感がわかないし、抽象化した自身の経験を適用できる範囲も限られます。

最近の仕事では、何かしらの技術を導入するにあたって性質上影響範囲が大きく、設計ドキュメントでwhy?を考える機会が増えました。その中で、ソフトウェア開発の原則、ベストプラクティス、それらが目の前のか課題解決になぜ適用できるのか、メリット・デメリットは何かなどを議論し、合意し、利用者の疑問に答えられる必要があります。つまり「この技術をこう使ったら、動く!」のようなスタンスでは、物事が何も前に進みません。これまで以上に具体と抽象を行き来して、戦闘力を高める必要があります。

学びて思わざれば則ち罔し、思いて学ばざれば則ち殆し、はどちらかに偏りがちなので肝に銘じたいです。

不合理な人間の行動にもパターンがあるので、そういうのを自覚すると気づきがあるし、パターンを利用する意図が透けて嫌気がさすこともあるでしょう。

転職したい気持ちはないですが、鬼気迫るエピソードで面白かったですw

英語

チーム構成の出自のダイバーシティが以前よりさらに増してきました。MTG、設計ドキュメント、Slackでのやりとり、議論はもちろんリモート飲み会もすべて英語です。大体において、これ日本語でも厳しそうみたいなことが多い一方で、英語で話すのも書くのも余裕はないです。継続して学習しています。

4〜6月の英会話(NativeCamp)の受講状況はこんな感じでした。

  • 4月: 30回、12時間48分
  • 5月: 30回、12時間48分
  • 6月: 28回、11時間53分

火、木、土、日の朝25分 * 2。受けた直後はやった感はあるものの、月単位でみるとそこまで時間割いてないですね。ペースを落とさなければ、年150時間。無理なく続けられそうなペースな気がします。

思いどおり喋れるようになってきたのを感じるときもあれば、頭が回らなくて喋る内容を先にすべて書くときもあります。

成長度を測りたいような、測りたくなような気がします。

Microsoft MVP

かなりコンテナマネジメント系の実績を推したのですが、Cloud & Datacenter ManagementカテゴリーでなくMicrosoft Azureカテゴリーでの受賞になりました。いずれにせよ光栄です。やっていくことも変わりません。

今後の話

Objective 1

プラットフォームのインフラを支える技術の基礎力向上

つぎでTerraform周りをいったん整理し切ろうと思います。2019年10〜12月あたりから、プラットフォーム仕草(プラットフォームを開発するエンジニアが習得すべき技術要素やプラクティスなどの素養全般)を身につけるために、具体的な技術をテーマに据えてきました。Kubernetes、GCP、Terraformなど、業務との関連性の高い順になっています。

目の前の業務に必要なものばかりなので、いい感じにプライベート時間の学習をアラインできたと思います。

一方で、読書セクションに書いたように、ソフトウェア開発の原則、ベストプラクティス、古典、基礎系に割く時間も長期的目線で増やしていくタイミングなのかなぁとも思います。

7〜9月は技術書典だけで大変だと思うので徐々に…。

Key Result 1

Terraformの概念、書き方を理解しデバッグできる

前回から引き続きです。本番が9月のいつなのかけっこう気になります。

  • 技術書典9で『GCPで学ぶTerraform』を書く

Key Result 2

DevOpsのプラクティスを身につける

理論を学びつつ、目の前のクラウドサービスにどう適用するのかを学ぶのはよいタイミングっぽいです。

Key Result 3

学び方の改善

知的戦闘力を高める 独学の技法』にはとても影響を受けました。1テーマに据えます。

Objective 2

より気持ちよく暮らす

重要だが緊急性が低く、積極的にやる気も起きないので放置していたことを片付けます。

Key Result 1

断捨離と整理

そこまで物に溢れてるわけではないけれど、広めのクローゼットに甘えてる感があります。日常生活で光が当たらない部分を含め、物を減らしたい欲もあります。手を動かし始めたらちゃんとやりそう!

  • いらない服捨てる
  • 紙の本減らす

Key Result 2

猫たちとのよりよい共生

より大きくなり、外にも興味を持ち始めた猫たちとの生活をよりよくします。

  • 大きいトイレに交換する
  • ラムちゃん去勢
  • ふわふわくん外散歩できるようにする

Key Result 3

ume, yamazoeに行く(状況が許せば)

奈良育ちなのもあり、クラウドファンディングで支援したのでタイミングが合えば行きたいです。

静かな山里で、サウナ。最高っぽいです。

Key Result 4

冷蔵庫買い換えるか検討する

めっちゃ困ってるわけでもないですが、野菜室の野菜が凍ったりします。凍っててもサクサク切れるやつとか気になるので、ひとまず調べてみます。

今期の総合的な気分です。

スイスイ検証水曜日

プライベートも、20%ルールを導入しようと思います。題して「スイスイ検証水曜日」です。

OKRと人生

僕は3ヶ月の目標管理にOKRを利用しています。

業務未経験で駆け出したエンジニアの5年後 〜目標管理の変遷と個人OKR〜

これは、やりたいことや気になることが無限にある中で、直近3ヶ月で集中すべきことややらないことをはっきりさせるためです。

自分への成長圧から、「あれもやらないと」「これもやらないと」と人生が苦しくなり始めたためスタートしました。

割り切って目の前のことに集中でき、できた・できなかったを継続的に振り返ることができるので、今後も愛用します。

一方で、土日を全部割いても達成できるか微妙なラインのハードな目標を立てるため、なんのための人生かよくわからなくなります。これを受け、技術的な目標と、ゆるふわ系の目標を分けることにしました。

たとえば、2020年4〜6月のOKRはつぎのとおりです。

  • Objective 1: プラットフォームのインフラを支える技術の基礎力向上
  • Key Result 2: GCPの全体像を把握する
    • Professional Cloud Architectを取得する
    • 物理的に受けれない状況が続くなら「Google’s – Professional Cloud Architect Certification 2020」を受け終わったらOK
  • Key Result 3: 『KnativeとIngress Gateway』の完成
    • レビューコメントをもらっている内容を一通り反映する
    • 今あるissueをすべて閉じる
  • Objective 2: 生きてる実感を得て心をワクワクさせる
  • Key Result 1: ゆったりとした時間を過ごすための自分なりのルールを作る
  • Key Result 2: 趣味と闘争する
    • 体脂肪率12.5%
    • 燻製料理を生産できるようにする(from ワクワクリスト
    • オクトパストラベラーやってみる
    • エクスカイザー観終わる
  • Key Result 3: ワクワクリストを整理する
    • 優先度
    • 何をしたら実現できるか
    • 費用
    • 期間

Objective 1は仕事上必要な技術要素を念頭に置き、基礎力を鍛えるものです。Objective 2がゆるふわに人生を謳歌するためのものです。

今回の主眼はObjective 1です。

20%ルール

技術的な成長を目指し、必要な技術を不断に学び続ける。字面はかっこいいし、有意義だと思います。ただ、自分の今の取り組み方では息苦しいです。

「Kubernetesのリソースを管理するkptというツールが出たのか!ちょっと触ってみよう!…いや、時間ないしやめよう」

Knative EventingのGCP用の実装、最近どうなんかな?きっと元気なんやろ勉強しよう」

「最近Go書いてないなぁ…まぁYAMLエンジニア養成期間やし、割り切ろう」

「CNDTのプロポーザル書くか!…日程的に無理そう」

やりたいことを絞るためのOKRが、自分に好奇心にフタをしているようで悲しくなってきます。何かに没頭するような感覚も、忘れつつあるような気がします。

そこで、20%ルールを採用することにしました。20%ルールは、『How Google Works』で紹介されているような、「業務時間の20%を好きなことに使ってよい」という制度です。実際今使われているかどうかは、関心事ではありません。

僕の場合は、水曜日の夜を気になった技術の検証に使うことにしました。つぎの四半期のテーマ探しにもつながりそうです。

OKRの立て方自体にも改善余地はありそうですが、とりあえず試してみることにします。

ちなみに、Objective 2の「Key Result 2: 趣味と闘争する」過程で、「土日は1時間ずつゲームやっていい」ルールが生まれました。

ゼルダをクリアするのに、1年近くかかる可能性があります。

感情の取り戻し方

今日は、マネージャーさんとの1on1でここまで書いたような話をしました。すると、『1分で話せ』などで有名な伊藤羊一さんの主張を紹介してもらいました。

中でも、彼の主張する「Lead the Self」という概念と取り組みが今の自分に必要そうでした。

まず、さまざまな物事に「すげー!やべー!」と言い続ける。好奇心をもつ。

そして自分もやってみて、言語化する。それが自分にとってどういう意味があるのか?を考える。気づきを得る。

この過程の繰り返しが好奇心を育み、スキルやマインドへの落とし込みを加速させるというものです。

これまでのように自分の好奇心にフタをし続けると、OKRで達成できることと失う機会のどちらが大きくなるかよくわからないなぁと感じました。

その落としどころとしての「スイスイ検証水曜日」です。

最初から無理しないのは大前提として、つぎの記事のような形でアウトプットできるとよさそうです。

継続的なアウトプットはなぜよいか? 著作も数多いエンジニアが語る、社外向け発表がチームまで成長させる話

アウトプットにはこだわりがあるものの、OKR1つ1つが重くなるにつれ数自体は以前よりかなり減ってきていました。

検証する内容も業務から離れなさそう(離れてもよいとは思う)なので、いい形にできればなぁと思います。

四半期ごとの個人OKR振り返りです。

2020年1〜3月は仕事ではメルペイからメルカリのMicroservices Platformチームへの正式な異動・転籍が決まったタイミングでした。

振り返り対象の個人OKRはこの記事2019年10〜12月の振り返りと2020年 〜YAML Engineerとしての闘争〜で立てています。

個人OKR(特にObjective 1)は会社のOKRとは別でその基礎を固める意味合いのもので構成していました。

OKRの振り返り

3段階で見ていきます。

  • できた
  • 微妙
  • できなかった

Objective 1

プラットフォーム開発の基礎力向上
※働きはじめて特に厳しそうな分野が見つかれば変更してフォーカスする

当初定めたものと業務上必要そうなものにずれはなかったので変更していません。

Key Result 1 【できた】

CKAを取得2020年3月までに取得する

3月に集中的に取り組んで達成できました。別の記事で詳しくまとめています。

CKAとCKADを受験した動機とよかったこと

CKA(とCKAD)を取得できても、新しいチームで自分が戦力になることは保証されません。しかし、これらすら取得できなかったら適性面で厳しいと言えるような内容だったり、実務に活きるような実践が積めたりしました。時間をかけて取り組んでよかったです。

Key Result 2 【できた】

サービスメッシュ、LBなどの動作の仕組みをKubernetesの文脈で説明できる

  • 『Istio Up and Runnning』読む
  • 技術書典8でKnativeに利用できるGatewayコンポーネントの話を書く

説明しました。お仕事でIstioのワークショップを開催したので、その過程でキャッチアップも兼ねました。

別の記事で詳しくまとめています。

技術書典応援祭の『KnativeとIngress Gateway』と『JavaScriptとSEO』の振り返り #技術書典

プラットフォームでマイクロサービスを開発するエンジニアに概要、メリット・デメリットを説明し、納得して使ってもらう(そこまでは至らなかった)というプロセスは視点を上げる上でも重要な経験に感じます。

Key Result 3 【微妙】

CloudNativeを実現するOSSを開発する(3PR以上)

  • issueを閉じる
  • テスト足す
  • 機能足す

issueをアサインしてもらってPRマージまで持っていけたのはこの1つだけです。

https://github.com/tektoncd/pipeline/pull/1875

他は普段通りの設定ファイルの追加で特に成長がありません。

https://github.com/syndbg/goenv/pull/116
https://github.com/syndbg/goenv/pull/110
https://github.com/syndbg/goenv/pull/109
https://github.com/syndbg/goenv/pull/108
https://github.com/syndbg/goenv/pull/107

成長していきたい分野ではあるものの、今は新しいチームで成果を出すのに必要そうなスキルに集中すべき時期です。

Objective 2

生きてる実感を得て心をワクワクさせる

Key Result 1 【できた】

嫁氏とゆったりした時間を過ごす

  • スターウォーズを観る
  • 低温調理できるようにする(from ワクワクリスト)

妻はスターウォーズ(とアベンジャーズ)が大好きなので映画を観てそのまま食事しました。

何かが理由で行くのをためらった気がするのですが、OKRに入れることでやめずに実行できてよかったです。

あとは低温調理。単に興味があったのと、Key Result 2との兼ね合いで飽きずに美味しく鶏肉を食べる必要がありBONIQを購入しました。

低温調理といえばAnovaの印象が強いかもしれませんが、比較した結果我がにはBONIQという結果になりました。

  • コンセントの変換器不要
  • Amazonで買える(今は中古しかなさそう)
  • クックパッドにメニュー豊富

が主な理由です。Anovaを買ってもたぶん満足していた気がします。

別で記事を書けたらと思いますが、特にルーロー飯とレバーのコンフィが絶品です。

6 packsチャレンジ中ひたすらBONIQで低温調理した鶏肉を食べていて、まったく飽きなかったのが何よりも大きな成果です。

あと、なんとなくこのノリでドラム式洗濯乾燥機導入できてよかったです。

Key Result 2 【できた】

趣味と闘争する

  • スノボする(from ワクワクリスト)
  • 腹筋を割る(from ワクワクリスト)
  • 土日のうち1時間をピアノに充てる(from ワクワクリスト)

ピアノは1月の最初こそやってたものの、Objective 1に押しつぶされたり、キーボードが置いてある部屋が寒かったりで諦めました。

スノボは何年かぶりに前々職の同僚と行けたので満足です。ただ、1日目に膝を打ち過ぎ、2日目はサウナなど1人旅になってしまったので膝を守る術を身に付けたいですね。

それはそれで楽しかった説もあります。

これら3つの中で特に時間を割いたのは「腹筋を割る」でした。結論としては成功と言ってもいいかなと思います。

1月の半ばからパーソナルトレーニングに通い、食事制限やランニングと合わせてがんばりました。

明確に目標体脂肪を宣言するともっとストイックになれたかもしれません。しかし、けっこうな自粛ムード、慣れないリモートワークの中での食事制限はこれ以上きつくすると挫けそうでした。

とりあえず豚カツ、カツカレー、天ぷら、皿うどん、焼肉、家系ラーメン、うな重、餃子、酢豚、良いコース料理、イタリアンプリン、タルト、チーズケーキなどが食べたいです。

筋トレや低脂質高タンパクな料理などの知見が増えたので別で記事にしようと思います。

OKR文脈では体脂肪率12%台になるまではがんばります。

Key Result 3 【できなかった】

ワクワクリストを整理する

  • 優先度
  • 何をしたら実現できるか
  • 費用
  • 期間

まったくできませんでした。ワクワクリストというのは、OKRを決めてその達成を追えば追うほどよくわからなくなってしまった「俺何するために生きてるんやっけリスト」のことです。

前回のO2 KR3で作成しました。

旅行系はGWが直近のチャンスかと思ってましたが、当分無理そうですね。技術系はきっとできることがあったり、実現に向かって進捗してることもあるので、次回もう一度このまま掲げます。

ログ

読書数、登壇数などの習慣目標は前回を最後にいったん追わないことにしました。

しかし、残しておくのはよいと思うのでセクション自体は残します。

読書

読んだ

元々インフラをやっていたわけではない人にとって優しい書き方で好感度が高かったです。

MEAP(Manning Early Access Program)なのでメールでアップデートが通知されるのもよかったです。

オライリーさんの方もやってくれたらなぁ。

細かくて読み進めている間に前に書いてあることを忘れました。

あるコンポーネントが落ちてるとき、何がダメで何が生きてるのかコンポーネント毎に書いてるのがよかったです。

CKAの準備タイミングで読んでました。内容はあまり覚えてないです。

内容覚えてる本はないかもしれないですね。

技術書典の方を読みました。開発合宿で同僚が入門してたのを見て、そういえばやってなかったなぁと。

人間の性質上、知らないうちに陥ってしまう罠を自覚するのは大事と思っています。

新刊の『SSLをはじめよう』を購入したらサービスしていただき、読みました。

けっこう長いこと積ん読になってたな…

サピエンス全史の人の本です。オーディブルで聴きました。

徴税官のイメージ変わります。オーディブル。

短いスパンの振り返り取り入れてみようと思いました。オーディブル。

罠避けたいシリーズです。オーディブル。

読んでる

『KnativeとIngress Gateway』なりIstioなりはネットワークの理解が必要です。

これまでSIerの営業で情報系の試験勉強をしたり、エンジニアとしてネットワークごしの通信をするコードを書いたりする中でピンと来たことはありませんでした。

しかし、ようやく基礎から勉強して実感がわく時期がきたので読みはじめました。

同僚のKubernetesセキュリティ関連の登壇をレビューするにあたり読みはじめました。

Kubernetesよりも相対的にDockerの方が馴染みがないので、その復習から入るのが助かります。

復習といっても知らなかったことが多い…

久々にエモい気持ちになった技術書です。

AmplifyでReact、Lambda、AppSync、API Gateway、Cognitoベースのアプリケーションを動かしながら作っていきます。

DXはLambdaみたいな運用の手間を減らす基盤だけでなく、開発を支える程よく抽象化されたライブラリ、裏でよく管理してくれるIaC、CLIが一体となって実現されるのだなぁと強く感じさせられました。

まだアーリーアクセスですが、最終版は提出される雰囲気です。

オライリー本の日本語版の監訳、できるのならやってみたいんですがどなたか伝手ありませんか…!

Design Docなど英語で書く機会が増えたのと、英語に限らず技術文脈で書くことは多いのでライティングは投資していきたい分野です。

技術自体のキャッチアップは当然やるとして、インフラ、プラットフォーム、SRE的な考え方だったり、チームが立脚する文化を学ぶことの大事さを感じる機会が増えました。

体が「活字」を求めているときに読みたい著者の1人の本です。

とても鮮明に僕らが立っている・立たされている精神のあり方が描写されています。

英語

チームでのやりとりは基本的にすべて英語になりました。

受験英語は好きだったものの、実際に仕事でガッツリ使うのは初めてなのでトレーニングをはじめました。

スピーキング

会社サポートでオンライン英会話のNativeCampを受講しています。カランメソッドと実践!仕事の英語というのを半分ずつ受けています。

  • 2月: 30回、12時間40分
  • 3月: 28回、11時間54分

25分/1レッスン * 2連続平日の朝1時間を週数日、土日に各1時間。レッスンが終わったら次のレッスンの予約をその場でとり、なるべく途切れないようにしています。

話しやすくなったようなそうでもないような、成長は実感しづらいです。

リスニング

Podcastを去年の夏頃から聴いてます。この辺が特に好きです。

あとはUdemyの技術系講座は基本英語なのでそれを受講しています。元のスピードの遅いのは1.25倍にして聴いてます。それより速いと頭に全然残りません…

最近少し聴き取れる割合が増えた気がします。

言語問わず話が長いと集中できない感はあるなぁと日本語のオーディブルを聴くようになって思いました。。

リーディング

会社でSafari Books Onlineを契約しているのはありがたいですね。

あと暇なときにエンジリッシュで単語を覚え直しています。中級単語とかでも真新しいのはないですが、記述もあるので定着はします。

ライティング

読んでいる本のセクションに書いた本を読んだり、Grammarlyでチェックしたり、DeepLで比べたりしています。

定量的な変化を感じたいのでTOEFLでも受けようかとも思うのですが、技術面のキャッチアップを優先します。

今後の話

仕事のオンボーディングは進んでいるので、中核となる技術のキャッチアップを中心に進めていきます。

Objective 1

プラットフォームのインフラを支える技術の基礎力向上

Key Result 1

Terraformの概念、書き方を理解しデバッグできる

  • 技術書典9で『GCPで学ぶTerraform』を書く
  • 『実践Terraform』『Terraform Up & Running』を読んで理解が必要な見取り図を描く

Key Result 2

GCPの全体像を把握する

Key Result 3

『KnativeとIngress Gateway』の完成

  • レビューコメントをもらっている内容を一通り反映する
  • 今あるissueをすべて閉じる

Objective 2

生きてる実感を得て心をワクワクさせる

これ続けたいですね。

Key Result 1

ゆったりとした時間を過ごすための自分なりのルールを作る

食事制限したり、資格とったり、目標は達成できて人生進捗した気分になります。

でも、過多で息苦しくて、あんまり生きてる心地しないんですよね…

Key Result 2

趣味と闘争する

Key Result 3

ワクワクリストを整理する

  • 優先度
  • 何をしたら実現できるか
  • 費用
  • 期間

明けましておめでとうございます。2019年は2匹の猫を家族に迎え入れ、安らぎとは何かを教えてもらった1年でした。

仕事では2018年9月に転職してから開発に取り組んでいたメルペイが世に出たりしました。その中でKubernetesなどに出会い、いろいろあって2020年はメルカリのMicroservices Platformチームに移って基盤の開発・運用に取り組みます。

リンクはない目次

  • OKRの振り返り
  • 習慣目標の振り返り
  • 2020年の話
  • 2019年アーカイブ

OKRの振り返り

2019年の振り返り

2019年10〜12月の振り返り

KR毎に3段階で達成度を判定し、それぞれ所感を書いていきます。

  • できた
  • 微妙
  • できなかった

Objective 1

O1: プラットフォームエンジニアへの闘争

Key Result 1 【できた】

DIY Serverlessプラットフォームを構築する

  • ServerlessDays Tokyo
  • ServerlessDays Fukuoka
  • CLI
  • server -> functionのミドルウェア

ServerlessDays TokyoとFukuokaでFaaSプラットフォームを作るワークショップを担当する過程で作りました。

ServerlessDays Tokyo 2019でWorkshop 03「Knativeで作るDIY FaaS」を担当しました #serverlessdays


https://github.com/toshi0607/build-your-own-platform-with-knative

HTTPリクエストを受けて処理するのが主なユースケースです。既存のKubernetesでFaaSを利用したいのはイベントハンドリングだと思うので、その観点ではだいぶ未熟です。

CLIはkubectlのプラグイン形式で公式の手続き的なコマンドを追加し、ミドルウェアは薄いのを書くつもりでした。しかし、CLIについてはtriggermesh/tmで、ミドルウェアはopenfaas/faasで実験用途には十分だったので自作しませんでした。

本格的に検討するときには①イベントハンドリング②ミドルウェア③CLIの優先度で深掘ろうと思います。

ワークショップは社内でもやってみました。福岡でも感じましたが、FaaSやサーバーレスに興味がある人よりは、普段Kubernetesを触ってるエンジニア(アプリケーションでもプラットフォームでも)に対してKnativeを触ってもらうといろいろ議論したり有意義なのかなぁと思いました。

Knativeに限らず勉強会のノリでやっていけるとよさそうです。

Key Result 2 【微妙】

Kubernetesの知識を網羅的・原理的に理解する

  • CKA取得
  • 何かコントローラー作る
  • what-happens-when-k8sを図を書きながら説明できるようになる

CKAについては、11月半ばに2020年1〜3月に回しすることにしてCKADを受験しました。10、11月は平日毎朝30分~1時間『Kubernetes完全ガイド』を読み直す時間とり、(いろいろ落ち着いた)12月の半ばからdgkanatsios/CKAD-exercisesをGKEのクラスタ上で3周やってみました。

12月28日に受験して合格しました。

コントローラーは未着手です。この振り返り記事が終わったら『実践入門Kubernetes カスタムコントローラへの道』で入門はしたいです。

what-happens-when-k8sの説明については必要があったのでホワイトボードで図を書きながら説明する必要にかられてやりました。

特にネットワーク周りが弱かったので次四半期の課題です。

Key Result 3: プラットフォームを支えるOSSにコントリビューションする 【微妙】

機能 > テスト > リントツールでわかるもの > 設定ファイル > ドキュメント・コメント

https://github.com/syndbg/goenv/pull/105
https://github.com/syndbg/goenv/pull/104
https://github.com/GoogleCloudPlatform/functions-framework-go
https://github.com/GoogleCloudPlatform/functions-framework-go/pull/14
https://github.com/syndbg/goenv/pull/103
https://github.com/syndbg/goenv/pull/102
https://github.com/syndbg/goenv/pull/101
https://github.com/dapr/dapr/pull/631
https://github.com/gcpug/handy-spanner/pull/1

何もやっていないわけではないですが機能なりテストないでコントリビューションしたかったです。tektonで割り当てられているissuesを解決するコードを書くところから…

Objective 2: ゆとりある心で秋〜冬を感じる

KR1: 心があたたまる食べ物を食べる 【できた】

鍋パする

しました!

KR2: 季節のイベントに参加する

  • ディズニーハロウィン
  • 温泉
  • もみじ、山

ディズニーはハロウィンに間に合わなかったのでクリスマスに行きました。

温泉は昨年のふるさと納税で長野へ。大学のゼミで訪れた小布施にも久しぶりに行ってきました。

奥多摩にもみじ狩に行ったらあまり紅葉が進んでない日もありました。

KR3: やりたこと、いきたいことリストをつくりワクワクする 【できた】

やってみました!OKRに家庭の時間を入れるようにしたものの、3ヶ月単位で考えると計画的にやらないと実現できないことを含めることが難しいと感じました。その一方で生きてるうちにやってみたいことって何なんだろう?と思ったのが取り組んだきっかけです。

  • カッパドキアで気球に乗る
  • シャウエンを歩く
  • ピラミッドを見る
  • ミラコスタに泊まる
  • 開発者のプラットフォームを開発する
  • クラウドを開発する
  • このOSSと言えばtoshi0607みたいなのを開発する
  • 仕事でOSSを開発する
  • OSS開発が仕事になる会社で働く
  • クリスマス島でカニの大群を見る
  • 久石譲のSummerをピアノで弾く
  • 腹筋を割る
  • 宮古島で野生のヤシガニに遭遇する
  • 技術書典の本を底本にしない単著の技術書を出す
  • オライリーの本を監訳する
  • 湯らっくすで整う
  • ロックマンX系の曲演奏する
  • また歌うのが楽しいと思えるようになる
  • 低温調理できるようにする
  • 大きめの甲殻類を飼育する
  • 本場でノドグロを食べる
  • パラグライダーする
  • 燻製料理を生産できるようにする
  • サグラダファミリアを見る
  • 古民家に泊まる
  • 宿坊に泊まる
  • マカオタワーのバンジージャンプする
  • 砂漠をラクダでゆく
  • オーロラを見る
  • フィンランドでサウナに入って湖に飛び込む
  • 弘前公園の花筏を見る
  • 裸眼で視力1.5
  • ニュルンベルクのクリスマスマーケットに行く
  • スイスの登山鉄道に乗る
  • サントリーニ島に行く
  • イグアスの滝を見る
  • モアイ像を見る
  • 船旅をする
  • ガンジス川を見る
  • ペトラ遺跡を見る
  • クアッカワラビーと写真を撮る
  • 氷に糸垂らして魚釣る
  • ザリガニ捕まえる
  • 毎年スノボする

海外旅行、仕事、趣味などいろいろですね。準備した上で良いタイミングにめぐり合えないと実現できなさそうなものや、時間をとってお金を払えばOKなものもあります。

基本は今後のOKRに盛り込みつつ、このTODOリストみたいなやつひたすらチェックつけていったら本当に人生よかったって言える?とか人生の進捗を考えていこうと思います。

OKR総括

今四半期の最大の焦点は7〜9月の振り返りで書いたこの部分でした。

プラットフォームの運用・構築・開発、利用サポートができるエンジニアになりたい思いが強まったので、個人OKRもそれに寄せていきたいです。人と話して目の前の技術スタックに活きる順番ではまずKubernetesの使い方・動作原理を理解してより低レイヤーに降りていくのが現実的そうでした。本業として実現できるように頑張る。

本業として実現できるように頑張る。頑張ってもらいつつ頑張った結果、2020年から(最終的に)メルペイからメルカリのMicroservices Platformチームに移ることになりました。

大きなチャレンジになりますが、早く一人前のYAML Engineerになれるようキャッチアップしつつ頑張ります。

習慣目標の振り返り

習慣という意味では、7〜9月の予定が厳しい時期にスマホゲームを(クロノ・トリガー以外)全部アンインストールしました。その結果、歩いてる時間にPodcastを聴く習慣が身につきました。来年は仕事では基本的に英語コミュニケーションになるのでよかったっぽいです。

2019年の目標

本(執筆): 2冊/年

技術書典が2回あったので2冊出しました。初版が不完全燃焼でも、Knativeの歩き方のように第2版で大幅アップデートして手に取ってくださった方に届けられ、自分の知識もアップデートできるうちは有効に思います。

CFP: 4ヶ月に1回出してみる

  • CloudNative Days Tokyo(登壇)
  • Serverlessconf New York City '19
  • ServerlessDays Melbourne 2019(登壇)
  • ServerlessDays Fukuoka(登壇)

今年は年間を通じてプロポーザルが必要なカンファレンスに挑戦するようになりました。Serverlessconf New York City以外は幸い採択され、登壇の機会をいただきました。おすすめなカンファレンス用プロポーザルの書き方を読んで審査員の方々の気持ちを考えたり、社内の強くて親切な方にプロポーザルを添削していただいたり手厚いサポートあっての登壇でした。

業務未経験で駆け出したエンジニアの5年後 〜目標管理の変遷と個人OKR〜にも書いたのですが、個人活動のアウトプットにおいていかにフィードバックをもらうかは注力すべきポイントなので今後も意識して継続していきたいです。アンケートとるのもいろんな人からたくさん声をいただく上でとても有効な手段の1つだと思います。お願いして時間をいただいてヒアリングしたりバイネームで臨むのが僕にとっては後の活動への影響が大きかったです。

OSS: 1PR/月

新しく作ったには2リポジトリです。

https://github.com/toshi0607/build-your-own-platform-with-knative
https://github.com/toshi0607/jctl

自分が作ったもの以外へのOSS PRは前年比だいぶ習慣にはなったものの、7〜9月の振り返りに書いたこれに尽きます。

自分な好きなOSSに対しリリースノートに載るようなインパクトのあるコントリビューションがしたいという思いを強めました。

1〜3月

https://github.com/syndbg/goenv/pull/71
https://github.com/cncf/wg-serverless/pull/74
https://github.com/syndbg/goenv/pull/68
https://github.com/jamiehannaford/what-happens-when-k8s/pull/18
https://github.com/syndbg/goenv/pull/66
https://github.com/syndbg/goenv/pull/65
https://github.com/serverless/serverless/pull/5726
https://github.com/syndbg/goenv/pull/64

4〜6月

https://github.com/ahmetb/cloud-run-faq/pull/22
https://github.com/syndbg/goenv/pull/86
https://github.com/syndbg/goenv/pull/84
https://github.com/knative/docs/pull/1373
https://github.com/syndbg/goenv/pull/83
https://github.com/syndbg/goenv/pull/78
https://github.com/syndbg/goenv/pull/73
https://github.com/knative/docs/pull/1147

7〜9月

https://github.com/mercari/wrench/pull/7
https://github.com/mercari/wrench/pull/5
https://github.com/mercari/wrench/pull/4
https://github.com/mercari/wrench/pull/3
https://github.com/mercari/go-emv-code/pull/8
https://github.com/mercari/go-emv-code/pull/7
https://github.com/virtual-kubelet/virtual-kubelet/pull/774
https://github.com/syndbg/goenv/pull/97
https://github.com/google/ko/pull/89
https://github.com/knative/client/pull/412
https://github.com/knative/pkg/pull/646
https://github.com/ijin/serverlessdays-tokyo/pull/16
https://github.com/k1LoW/tbls/pull/137
https://github.com/kedacore/keda/pull/343
https://github.com/GoogleCloudPlatform/cloud-run-button/pull/82
https://github.com/google/kf/pull/659
https://github.com/google/go-cmdtest/pull/1
https://github.com/syndbg/goenv/pull/95
https://github.com/kedacore/keda/pull/323
https://github.com/syndbg/goenv/pull/94
https://github.com/deislabs/osiris/pull/37
https://github.com/kedacore/keda/pull/323
https://github.com/syndbg/goenv/pull/88
https://github.com/syndbg/goenv/pull/86
https://github.com/kubernetes-sigs/kubebuilder/pull/967
https://github.com/knative/client/pull/388
https://github.com/knative/eventing-contrib/pull/557
https://github.com/knative/eventing/pull/1732
https://github.com/syndbg/goenv/pull/91
https://github.com/syndbg/goenv/pull/90

10〜12月

https://github.com/syndbg/goenv/pull/105
https://github.com/syndbg/goenv/pull/104
https://github.com/GoogleCloudPlatform/functions-framework-go
https://github.com/GoogleCloudPlatform/functions-framework-go/pull/14
https://github.com/syndbg/goenv/pull/103
https://github.com/syndbg/goenv/pull/102
https://github.com/syndbg/goenv/pull/101
https://github.com/dapr/dapr/pull/631
https://github.com/gcpug/handy-spanner/pull/1

ひとまとまりのソースコード公開: 1リポジトリ/月

技術書(読む): 30分/日

(2019年10〜12月分)

CKA/CKAD受験にあたり読み直しました。2019年はこの本でKubernetesに入門し、結果的にKubernetesを中核技術とするチームに移ることになりました。僕の2019年を象徴する本になりました。

CKADにちょうどよい本でした。Kubernetesでアプリケーションを開発するエンジニアのKuberentesリソース入門に最適です。

今読んでいてCKA向けに感じます。admin視点で各コンポーネントの入門に最適そうです。

その他本(読む): 30分/日

(2019年10〜12月分)

OKRの登壇をするにあたり読み直しました。各社のユースケースが載っていて実感がわきやすく、OKR登場の歴史がわかりやすいです。巻末のチェックリストだけでも読む価値があると思います。

OKRの登壇をするにあたり読みました。Measure What Matters比コンパクトにまとまっていて読みやすく、入門に最適です。個人でやる場合はこれ1冊読むだけで十分そうでした。

サンプル部分だけ読みました。上で紹介した2冊と別の情報が得られそうになかったので続きは読みませんでした。

筋トレしながらオーディオブックを聞くようになりました。日本語でも聞いた後に覚えてるかと言われると怪しいので、英語のリスニングって母国語でない以上のハードルがあることに気づきました。

ふぁーーーこれやーーーって本に出会いがっつり感想書く: 1回/3ヶ月

今四半期は読み直しが多く新しい出会いを強く感じることはありませんでした。

読んで強い影響を受けた本2冊(Kubernetes完全ガイドとMeasure What Matters)に必要に駆られて立ち返ったのは偶然ではないはずです。必死に生きて課題にぶつかり、先人の知恵に感謝しつつ本を読むことを継続していけたらと思います。

ピアノ晒す: 1回/月

1度も触らず。やりたいことリストに久石譲さんのSummerをピアノで弾くのとロックマンX系の曲をやるが入ってるので再開します。

筋トレ: 1回/週

週1品川健康センター通いを継続できました。12月半ばにリングフィットを導入したので、22時までに帰宅する日はやろうと思います。

腹の未来が気になるので、とりあえず割ります。

2020年の話

2020年はプラットフォームを開発・運用するチームで働くにあたって、必要な実力をつけて成果を出したいというのが本分です。

グループ内の異動とはいえ、これまではプラットフォームの利用者だったので転職以上に仕事への影響は大きいと思います。
そのため、これまで開発上でバンクエンドエンジニアとして感じてきた課題やインフラ面での難しさは念頭に起きつつ、Kubernetesを起点にレイヤーを下ってキャッチアップするのは大前提です。

具体的にどういう部分で知識・経験不足を感じるかがわからないだけに四半期単位くらいでOKRを定め確実に身につけていくサイクルはより重要です。今の段階で確実に厳しそうに感じる部分を盛り込んで直近3ヶ月のOKRを考えます。

あとは業務上得たよい知見でもって大きなカンファレンスで登壇したいという気持ちがあります。入門や概念説明系の登壇も裾野を広げる観点では意味があると思いますが、結局現実世界でどんな課題を解決したのかに対して去年何も応えられなかったのが僕はいたたまれませんでした。

習慣目標はいったん無くして、やっぱり欲しくなったら復活させます。英語も必要そうであれば何かしら足します。

OSS系は掲げるだけではやらないので、土日の一定時間をカレンダーで抑えてみようと思います。

Objective 1

プラットフォーム開発の基礎力向上

※働きはじめて特に厳しそうな分野が見つかれば変更してフォーカスする

Key Result 1

CKAを取得2020年3月までに取得する

Key Result 2

サービスメッシュ、LBなどの動作の仕組みをKubernetesの文脈で説明できる

  • 『Istio Up and Runnning』読む
  • 技術書典8でKnativeに利用できるGatewayコンポーネントの話を書く

Key Result 3

CloudNativeを実現するOSSを開発する(3PR以上)

  • issueを閉じる
  • テスト足す
  • 機能足す

Objective 2

生きてる実感を得て心をワクワクさせる

Key Result 1

嫁氏とゆったりした時間を過ごす

  • スターウォーズを観る
  • 低温調理できるようにする(from ワクワクリスト)

Key Result 2

趣味と闘争する

  • スノボする(from ワクワクリスト)
  • 腹筋を割る(from ワクワクリスト)
  • 土日のうち1時間をピアノに充てる(from ワクワクリスト)

Key Result 3

ワクワクリストを整理する

  • 優先度
  • 何をしたら実現できるか
  • 費用
  • 期間

2019年アーカイブ

登壇

やってみたかった海外登壇やServerless Meetup Tokyo、Serverless Days(Conf)への登壇が果たせてよかったです。大テーマが同じワークショップ3時間*2をやってみるのも、それを社内向けに展開してみるのもよい試みでした。業務との距離が近いテーマであればあるほどフィードバックに現実味がある一方で、多少距離があるのも技術的な出会いや別の視点を提供する場として有意義に感じました。

自分のKRと紐づけてアウトプットする場としては登壇でも執筆でもなんでもいいと思うものの、一種のお祭り感や人との交流がある点で無理なく続けていけたらと思います。

2019/12/13・14 ServerlessDays Fukuoka 2019

Microsoft Ignite The Tour 2019 Tokyo

業務未経験で駆け出したエンジニアの5年後 〜目標管理の変遷と個人OKR〜

2019/10/21・22 ServerlessDays Tokyo 2019

2019/9/19 Serverless Meetup Tokyo #14

2019/8/29 ServerlessDays Melbourne 2019

2019/7/22 CloudNative Days Tokyo 2019

2019/7/7 エンジニア銭湯#2

2019/6/14 mercari.go #8

2019/3/6 Serverless Meetup Tokyo #11

Kubernetes・Serverlessとの出会いと、Knative入門 @logmi

執筆

寄稿

技術書典での活動を継続しつつ、初めて雑誌寄稿する機会をいただきました。

記事

OSS

https://github.com/toshi0607/build-your-own-platform-with-knative
https://github.com/toshi0607/jctl
https://github.com/jamiehannaford/what-happens-when-k8s/tree/master/ja-jp
https://github.com/toshi0607/pse

受賞

概要

  • 状況変化が激しい環境で、向き合うべき課題と方向性を適切に定め、素早く成長していくためには「技術の学び方を学ぶことへの投資や管理」が不可欠
  • 経営管理手法の1つであるOKRを個人の目標管理に適用することはとても有意義
  • 個人でOKRをやる上ではフィードバックのもらい方や振り返りを工夫しない限り効果が半減してしまう

Microsoft Ignite The Tour 2019 Tokyoでの登壇

12月5、6日に開催された東京でのMicrosoft Ignite The Tour 2019個人OKRで加速させる技術力向上というタイトルで登壇しました。自分が45分間もOKRの話をするなんて夢にも思っておらず、後述する個人OKRにも含めているものでもなかったので依頼いただいたときには少し迷いました。しかし、つぎの理由から挑戦してみることにしました。

  • 定期的に目標管理手法を見直し、改善していくことには価値がある
  • キャリアの話と不可分で、需要がないこともなさそう

自由に資料公開できる雰囲気もないので、登壇をベースにまとめ直すことにしました。新年間近なこのタイミングでこの記事を書くことで、何かしら目標管理したい人の一助になれたらいいなぁと思っています。

OKRとは

OKRとは「会社内のあらゆる組織が、同じ重要な課題に全力で取り組むようにするための経営管理手法」です。

  • O(Objective、目標)は「何を」達成するか
    • 重要で、具体的で、行動を促し、人々を鼓舞するようなものです。
  • KR(Key Results、主要な結果、成果指標)は目標を「どのように」達成するかモニタリングする基準
    • 具体的で時間軸がはっきりしており測定・検証可能なものです。

採用企業

つぎのような企業で活用されています。

Intel、Google、AOL、Dropbox、LinkedIn、Oracle、Slack、Spotify、Twitter、Zynga、Anheuser-Busch InBev、BMW、Disney、Exxon Mobil、Samsung、freee、Mercari

OKRの設定例

まずIntelの例を見てみましょう。

  • O
    • 「8086」を業界最高性能の16ビットマイクロプロセッサ・ファミリーにする。以下をその尺度とする。
  • KR(1980年第2四半期)
    • 「8086」ファミリーの性能の優位性を示すベンチマークを5つ開発し公表する(アプリケーション)
    • 「8086」ファミリーの全製品をリリースし直す(マーケ)
    • 8MHz版の製造を開始する(技術、製造)
    • 演算コアプロセッサのサンプルを遅くとも6月15日までに製作する(技術)

マイクロプロセッサ開発で競合がひしめく中、業界トップになるために全社一丸となって取り組んだ際のOKRです。KRには担当の部門が割り振られており、それが各部門のOになりさらにKRが設定される階層構造になっています。

もう1つはYouTubeの例です。

  • O
    • 以下を成長の推進力として(2016年末までに)1日あたりの総視聴時間10億時間を達成する
  • KR
    • 検索チームとメインアプリ(+X%)、リビングルーム(+X%)
    • エンゲージメントと、ながら視聴を増やす(1日あたり総視聴をX時間にする)
    • 「ユーチューブVRエクスペリエンス」を開発し、VRカタログの動画本数をXからYに増やす

KRすべてが達成されるとOが達成されるという構成です。

OKRの特徴

OKRを採用すると何がよいのかについては『Measure What Matters 伝説のベンチャー投資家がGoogleに教えた成功手法 OKR』に書いてあります。かいつまんで紹介します。

  1. 優先事項にフォーカスし、コミットする
  2. アラインメントと連携がチームワークを生む
  3. 進捗をトラッキングし、責任を明確にする
  4. 驚異的成果に向けてストレッチする

①優先事項にフォーカスし、コミットする

何より大事なのは集中すべき大事なことがはっきりするということです。これからの3ヶ月で一番重要なことは何か?という問いは重要でないことも同じように明確にします。

意思決定せずに、あれもこれも大事な状態で闇雲に手を動かすこともよしとしません。はっきりと選択することで修正もできます。意思決定をしない、あるいはすぐ決定を変えてしまうと何も学べません。リーダーは何が重要か選択することに時間とエネルギーを注がなければならないとされています。

②アラインメントと連携がチームワークを生む

透明性の高いOKRというシステム下ではCEOを含めた全員の目標がオープンに共有されます。それにより、個人は自らの目標を会社の戦略と結びつけ、他部門との補完関係を理解し連携できます。

トップから現場までのアラインメントによってすべてのコントリビューターが組織の成功と結びつくようになります。

③進捗をトラッキングし、責任を明確にする

OKRは定期的な確認、客観的評価、継続的再評価により実効性が高まります。

OKRの進捗を確認する中で、主要な目標の達成が危ぶまれる事態になれば、立て直すためのアクションを作成します。進捗確認も定量的に設定されたKRがある上で行えば、主観を排し責任を明確にすることができます。

④驚異的成果に向けてストレッチする

OKRを設定するときには60〜70%の達成率になるような野心的な目標を立てます。100%達成するコミット目標も設ける場合もあります。設定したOKRのうちどれが野心的目標で、どれがコミット目標であるかという位置付けを明確にします。

四半期が終わり達成状況を確認するとき、達成率が常に100%の場合は目標が低すぎるため設定レベルを見直します。

OKRは評価と直接的に結びつけないことで、失敗する可能性がある目標にチャレンジする文化を醸成します。評価にOKRの達成度をまったく含めないという意味ではありません。

OKRを支えるCFR

OKRはCFRとセットで運用することで実効性が高まります。前述の「③進捗をトラッキングし、責任を明確にする」でも触れました。

CFRとは年1回の勤務評定の限界から生まれた継続的パフォーマンス管理のことです。

  • C(Conversation、対話)
    • パフォーマンス向上を目的にマネージャーとコントリビューターの間で行われる意見交換
  • F(Feedback、フィードバック)
    • プロセスを評価し、将来の改善に繋げるための同僚とのコミュニケーション
  • R(Recognition、承認)
    *貢献への感謝

1on1ミーティング、360度評価、社内表彰制度、ピアボーナスなどもこの文脈に位置付けると目的がはっきりします。

OKRのプロセス

チームでOKRに取り組み、各個人まで降りていくスケジュールはつぎのようになります。

1月から新しいサイクルがスタートする場合、11月頃から目標設定の議論がはじまります。12月末には1年と四半期単位の目標が決め全社目標を共有します。そこから1月の半ばには各個人が設定し、2月には定期的なチェックが始まっています。

re:Work OKRを設定するより

従来の管理手法との比較(参考)

KPIとMBO

  • KPI(Key Performance Indicator)
  • MBO(Management By Objective)
    • ビジネスの成功のために何を目的とするか
    • 部門の売上貢献、組織のオペレーション改善、チームの特定スキルの底上げなどを箇条書き

OKR運用失敗の3つの理由―、なぜ高すぎる目標が逆効果になるのかより

MBOとの比較

年次評価との比較

OKRを個人の目標管理に

僕は個人の目標管理にOKRを活用するようになりました。自分が置かれた状況に合う方法をいろいろと試した結果採用するに至ったため、置かれた状況と目標管理の変遷を合わせて紹介します。

2015年

状況

2014年、SIerで企画営業をしていた僕は(中略)海外でMBAをとって戦略系のコンサルに行くぞ!と思ったりしつつ、書き物が好きだったのでブログ書いたり、高校のときに情報の授業が異様に楽しかったりしたので週末にプログラミングを教えてもらったりして人生の模索をしていました。

その中で6月くらいに自分たちでサービスを作って、フィードバックを集めながらサービスをよくしていく体験にとても感動して、9月頃にはエンジニアになる気持ちでいました。そこから転職活動をはじめ、1社目は書類で落ち、2社目はやる気はすごいと思うけど育成コストが払えないと断られ、3社目に受けたfreeeでエンジニアとしての第一歩を踏み出すことになりました。上場本当におめでとうございます。

正社員ではなく、まず1ヶ月の業務委託からスタートということで生きるのに必死でした。2015年の1年の中で、Railsでサーバーを書くWebサービス単体のリリースからSeleniumを使った銀行明細取得エンジンの開発、WPFのWindowsデスクトップアプリ開発と色々なプラットフォームでの開発をしました。必死でした。

  • 転「職」
    • SIer企画営業からfreeeのソフトウェアエンジニアに
    • 1ヶ月の業務委託 → 6ヶ月の業務委託 → 正社員
  • プロジェクト
    • 青色申告承認申請書送信サービス(Web)
    • 銀行明細取得エンジン
    • 銀行明細取得用Windowsアプリ
  • 技術スタック
    • Ruby on Rails、HTML、CSS、Selenium、C#、XAML、WPF

目標

2015年の1月にエンジニアになるにあたって掲げていたのはこれです。

「技術寄りでサービスを考え、作り、変え、大きくしていくことができるエンジニアになる」

1年や四半期ではなく、長期スパンの理想像ですね。何をやればそうなれるのか具体的なプランや、何をもってそうなった言えるのかの指標はありませんでした(わかりませんでした)。状況が状況なだけに、エンジニアとして働き続けられるようにひたすら目の前のことに取り組みました。

SIer企画営業をやめ、クラウド会計ソフトのfreeeでエンジニアとして働きます

2015年も半ばになる頃にはつぎのような状態を目指していたようです。

  • 目の前にある、必要とされることを何でもこなせる
  • みんなが必要と思っている仕組みを一から(とは言わなくても「自分がやったった」って言えるくらいの貢献度で)作りたい
  • 特定の分野と、逆に誰もやってないけど誰がやるといいやろう?みたいなときにアイツや!って声かけてもらえるようになりたい

27歳になりました

2016年

2016年にはWindowsアプリ開発を中心にロールやプロジェクトが広がりました。Windowsアプリ経由で取得できる銀行明細の種類を増やすためのアーキテクチャの変更を行いつつ、Webからアプリを利用するまでのフロー全体の改善やサポートチームと協力して問い合わせ削減などをしていました。

UX改善は問い合わせ内容を分析した上でKPIを決めてメトリクスを取得、可視化、効果測定、分析して打ち手を考えることや、WebからシームレスにWindowsアプリを利用できるようにするためのWebフロント実装など、前年よりも必要な技術スタックが広がりました。

状況

  • 開発 + プロダクトマネジメント
    • 利用率、ダウンロード率などKPI設定
    • サポートチームと協力し、問い合わせ内容調査
  • プロジェクト
    • Windowsアプリ利用のためのUX改善
    • 銀行明細取得用Windowsアプリ対応行拡大
  • 技術スタック
    • Ruby on Rails、HTML、CSS、Backbone.js、CoffeeScript、C#、XAML、WPF、Embulk、Redush

目標

目標としては年初につぎのようなものを掲げていました。

  • フロントに限らず、QAテスト的な文脈やいろんなプラットフォームで使えるクライアントアプリという文脈でJavaScriptと真剣に向き合いたい
  • クライアントアプリ書いたよしみでAndroid触りたい
  • APIを整備できる人になりたい

転職して1年が経ちました。2015年の振り返りと2016年の目標!

分野は前年比具体的になりましたが、曖昧で指標もありません。

ただ、半年後に考え直し、腰を据えてC#を学ぶことにしたようです。当時社内ではRubyを書く人が多かったことからC#を腰を据えて頑張るのに覚悟が必要でしたが、フォーカスすることで他の言語、プラットフォーム、プロジェクトにも活きる力を伸ばすという意図でした。

2017年

2017年はMicrosoft関連の技術を扱うチームというくくりでチームを作り、そのリードをがんばるという年でした。Windowsアプリは継続的に育てつつ、別のWindowsアプリのMac版の開発にXamarinを活用するプロジェクトにも挑戦しました。サーバーレスにも出会い、Windowsアプリのバックエンドの負荷対策の一環でAWS Lambdaも本番環境に導入したりしました。AWSのコンソールに入ったり、IAMで権限設定したり、クラウドサービスの設定を少しでもしたのはこのときが初めてだった気がします。

状況

  • チームリード
    • Microsoft Platformチーム
    • 日本マイクロソフト様とのHackfest
  • プロジェクト
    • 銀行明細取得用Windowsアプリ対応行拡大
    • サーバーサイド負荷対策でAWS Lambda(C#)
    • 電子申告アプリMac版をXamarinで開発
  • 技術スタック
    • Ruby on Rails、HTML、CSS、Backbone.js、CoffeeScript、C#、XAML、WPF、Xamarin、VSTS、AWS Lambda

目標

目標はつぎのような感じでした。

  • クエリ、データベース: 自分で早くKPIを追えるように、それが動く土台も詳しく
  • 機械学習: 経営者が一歩先に進むための判断をサポートするという文脈かつ良いタイミングなので追いたいです
  • 設計: 打ち手を増やして、サービスを作る、変える、大きくするを継続的によくするために。汎用的なデザインパターンとクライアントサイドの定石をまず身につけます。まだまだベストプラクティスを追うフェーズでよいと思っています。
  • フロントエンド: ユーザさんが直接的に触る部分をよくするための技術、問題解決できるサービスであることを伝えるための手段として。サービスで使われてるメインの技術をまずは追えるように…C#(WPF)的な文脈ではもう少しXAMLを理解しようと思います。
  • Linux: もう少しコマンド自由に使えるように…去年はLinux標準教科書を環境作って追ってみたら多少ましになったので、その復習プラスサーバの負荷状況調べれるようになりたいです。
  • Git: 最低限もわかってない感があるので、本一通り見るのは最低限やります
  • Xamarin: C#のコードが自分のスマホで動くのは純粋に楽しそう
  • エディタ: RubyMineとVisual Studioもう少し使いこなそう

転職して2年が経ちました。2016年の振り返りと2017年の目標

わからないと自覚できてきたことの羅列です。どのタイミングで何をがんばり、何をもってできたとするか基準が曖昧で何も管理できていません。

XAML、Xamarin、Visual Studio、機械学習(Azure ML)は業務との関連が深く、Microsoftプロダクトという共通性から結果的に集中的に取り組み、登壇や記事執筆を通じて結果的に多くの学びを得られました。しかし、土日は完全に消失しました。

2018年

状況

2018年はMicrosoft Platformチームから離れ、明細取得エンジンのマイクロサービス化に取り組みました。その中でGoに2週間ほど触れたことをきっかけにGopher道場に通い、「お金」に関して思うところもあったのでメルペイに転職しました。

メルペイではすべてが業務未経験技術スタックかつ担当マイクロサービスへの1人目のアサインだったため刺激が大きかったです。入社前のアサインの面談で、一番大変なところに配属してください!とお願いした通りでよかったです。

  • 9月に転職
    • すべて業務未経験の技術スタック
    • テックリード
  • プロジェクト
    • 明細取得エンジンマイクロサービス化(前職)
    • 精算マイクロサービス設計、開発
  • 技術スタック
    • Ruby on Rails、HTML、CSS、React(前職)
    • Go、gRPC、GKE、Spanner、Terraform、CircleCI、Spinnaker、Datadog

目標

  • 本: 2冊/年
  • 登壇: 6回/年
  • OSS: 1PR/月
  • ひとまとまりのソースコード公開: 1リポジトリ/月
  • 技術記事: 2記事/月
  • 技術書: 30分/日
  • その他本: 30分/日
  • カラオケ: 2回/月、歌練習: 1回/週
  • 品川健康センター: 2回/月、走る: 1回/週

転職して3年が経ちました。2017年の振り返りと2018年の目標

できた・できなかったがはっきり判断できる習慣を目標にするようになりました。しかし、なんのための習慣かはよくわかりません。
副次的効果として、振り返りやすくなため3ヶ月に1度振り返り記事を書き、行動自体を頻繁に見直せるようになりました。

2019年

状況

2019年はメルペイ全体のサービスリリースと、新たに設計・実装したリリースといろいろリリースが続きました。定期的なリリースはいまだに手が震えます。

  • マイクロサービスの設計、開発、運用
    • サービスリリースし、運用開始
  • プロジェクト
    • 精算マイクロサービスリリース
    • レポートマイクロサービス設計、開発、リリース
  • 技術スタック
    • Go、gRPC、GKE、Spanner、Terraform、CircleCI、Spinnaker、Datadog、Kubernetes、Pub/Sub、Dataflow
  • 2020年から新たな挑戦が…!

目標

目標管理は習慣目標を継続しました。

  • 本(執筆): 2冊/年
  • CFP: 4ヶ月に1回プロポーザル出してみる
  • OSS: 1PR/月
  • ひとまとまりのソースコード公開: 1リポジトリ/月
  • 技術書(読む): 30分/日
  • その他本(読む): 30分/日
  • ふぁーーーこれやーーーって本に出会いがっつり感想書く: 1回/3ヶ月
  • ピアノ晒す: 1回/月
  • 筋トレ: 1回/週

2018年の振り返りと2019年の目標 〜何かしらCFP出すぞ!〜

行動目標を継続することで目的は依然として不明瞭です。

行動に対する直接的なフィードバックが欲しかったため、プロポーザルが必要なカンファレンス登壇志向になりました。

重めの執筆や登壇が重なり、土日だけでなく平日朝・夜もいっぱいいっぱいに…『Measure What Matters 伝説のベンチャー投資家がGoogleに教えた成功手法 OKR』をそのタイミングで読んでいたこともあり個人の目標管理にもOKRを導入してみることにしました。

2019年7〜9月のOKRはつぎのように設定しました。

  • O1
    • DIY FaaSのためのKnativeのユースケース、動作の仕組みを理解する
  • KR1
    • どんな課題に対してどう使うのかを説明できる
  • KR2
    • Knativeを使ったプロダクトでどう利用されているか説明できる
  • KR3
    • Knativeの主要機能の実装方法を説明できる
  • O2 嫁氏とゆったりした時間を過ごす
  • KR1
    • スパイダーマン観に行く
    • バンブルビー観る
  • KR2
    • 花火大会に行く

2019年4〜6月ふりかえり 〜個人OKR運用開始〜

Measure What Matters』を読み、習慣目標はObjectiveなきKey Resultsの羅列であることや、目標管理とC(対話)F(フィードバック)R(承認)はセットだと気づきました。集中して身につけるべきことを絞り、家庭の時間も大事にすることにしました。

2019年10〜12月の振り返りと2020年1〜3月の目標設定記事は近日投稿予定です。

個人OKRをはじめてよかったこと

まだ取り組み始めてから2四半期で改善の余地はあると思うものの、取り組み始めてよかったなぁと思うことは多いです。

  • 無限にある「やらないといけないと思っていたこと」から解放され、やるべきことに集中できるようになった
  • 基本的に何でもやる自分に「やらない」や「断る」ための基準が生まれた
  • 「これをやることで何を達成したいのか」を考えるようになった
  • 3ヶ月という単位が何かを試すのに短すぎず長すぎずちょうど良い
  • エンジニアとしての人生に進捗が生まれ始めた

1年単位でテーマを設定したり、より長期的なスパンでどうなって何を達成したいのかも考えておくと各四半期でOKRを決めるときの指針になりそうと感じています。企業のOKRも場当たり的に決めているわけではなく、ミッション、ビジョン、バリューがある上でその進捗や課題感に応じてつぎの3ヶ月の目標設定をするのが妥当なのと同じです。

ただ、それを考えあぐねて何も着手できないよりは3ヶ月単位でも明確な目標を定めて動くことが有益です。行動により長期的ビジョンがブラッシュアップされ、それを基につぎの目標が持て、長期的視野が育っていく場合もあるでしょう。

個人OKRのtips

個人でやる場合、企業でやるのと同じように制度的に強制され人の目がある中で取り組むわけではないので、多少工夫が必要に感じました。

OKR設定のベストプラクティス

まず、目標設定においてはSMARTの枠組みに従うとよさそうです。

  • Specific(達成したいことの具体性)
  • Measurable(指標の計測可能性)
  • Attainable(ゴールの実現可能性)
  • Relevant(自身との関連性)
  • Time-bound(期限)

基本的に会社のOKR設定のベストプラクティス的なものはそのまま使えばよいです。本や記事もたくさん出ていて、特に良いものを最後に紹介します。

ただ、きれいなOKRを作るのが目的ではありません。自分が実現したいことに近づくのが一番大事なのでまずはやってみるとよいでしょう。

フィードバックの効果を高めるための工夫

個人でやる場合、制度的にフィードバックが保証されるわけではないので、人の関心が集まるオープンな場へアウトプットするのが重要です。

  • 期限付きのアウトプットの場とKRをセットにする
    • 技術書典、登壇、アドベントカレンダー
  • プロポーザルが必要なカンファレンスに申し込む
    • 聴く人、聴く人を代表する審査員の関心が高ければ通るし、最初からテーマがはっきりして関心のある人が聴きに来るのでフィードバックの精度が高い
  • 会社のOKRに紐付ける
    • サポートやフィードバックが得られる可能性が高い

振り返る習慣をつける

四半期の頭に立てたOKRを見直すのは次の四半期の頭ではありません。日々見直して軌道修正しながら取り組むことで実効性が高まります。

  • 設定したOKRを毎日見る
    • 毎朝SlackのReminderに通知させるなど
  • KRに紐づくイベント単位で振り返りをアウトプットする
    • Oの達成に近づけたのかどうか
    • 関連性の高い別のKRの質も高められる
  • 日々の活動を記録し、OKR関連のものとそうでないものの比率を見る
    • 関連の薄いものは無くしたり効率化したりできないか
  • 四半期最初の土日に振り返りと次のOKRを考える時間を確保する

個人OKRをはじめる

いいタイミングなのであなたも2020年1月〜3月のOKRを決めてみませんか?

Microsoft Ignite The Tour 2019 Tokyoでも5分各自がOKRを考える時間を設けました。

あなたのOKR

  • Objective
  • Key Result 1
  • Key Result 2
  • Key Result 3

OKRを深める

このセクションではオススメの本や記事を紹介します。

Measure What Matters

  • ジョン・ドーア著、日本経済新聞社、2018年10月16日
  • OKRがIntel、Google、ゲイツ財団などでどのように活用され、どのような成果が挙がったのかに関するケーススタディが収められた本
  • OKRとそれを支えるCFR、文化などにも触れられたOKRを知るための決定版
  • 参考資料にグーグルのOKR実践マニュアルが掲載されており、チェックシート的に使うだけでも価値がある

OKR シリコンバレー式で大胆な目標を達成する方法

クリスティーナ・ウォドキー著、日経BP、2018年3月15日
OKRを採用して困難に立ち向かう架空のスタートアップの話の前半とOKRの設定と運営のノウハウが紹介された後半に分かれる
『Measure What Matters』よりコンパクトで、個人で取り組むときにはちょうどよい内容

OKRを設定する

  • Google re:Workの1つ
    • https://rework.withgoogle.com/jp/guides/set-goals-with-okrs
  • OKRの概要、導入、評価まで網羅的かつ簡潔にまとめられている
  • 超簡略版『Measure What Matters』
  • 設定・評価用のシート付き

OKR運用失敗の3つの理由

  • Coral Capital社
    • https://coralcap.co/2019/11/three-reasons-okrs-backfire
  • いざやってみると目標の高低などちょうどいいものを見つけるのは難しい
  • Objectiveに垣間見る自分や成し遂げたいことの意義

いいキャリアとは

  • 青田努(@AotaTsutomu)さん、いい感じにはたらくTips Advent Calendar 2019 1日目
    • https://note.com/aotatsutomu/n/n3d783f60403e
  • 主観の価値を、他人や社会は決めてくれません
  • もし何も成し遂げられなくても、あとでふりかえった時に「それでも良かった」と言えるような日々

まとめ

  • OKRはチャレンジングな目標設定と計測可能な指標から構成され、継続的パフォーマンス管理とセットで大きな成果達成を可能にする手法
  • 個人でやるにあたってはSMARTの原則などベストプラクティスに沿ってOKRを設定し、アウトプットの工夫などでフィードバックをもらえる状況を作り、継続的にふりかえる
  • 限りある時間の中で重要なことに集中し、公私共々大きな成果を挙げましょう!!

四半期ごとの人生振り返りです。

2019年の目標とは別に個人OKRの運用を開始したため、そちらを中心に振り返ります。

サマリ

プラットフォームエンジニアへの闘争を開始します

OKRの振り返り

基本的にやるべきことに集中するために大事なことを列挙する形で設定したのでつぎの3段階くらいでいいかなと思います。

  • できた
  • 微妙
  • できなかった

Objective 1

DIY FaaSのためのKnativeのユースケース、動作の仕組みを理解する

Key Result 1 【できた】

どんな課題に対してどう使うのかを説明できる

  • CloudNative Days Tokyo 2019 登壇
  • ServerlessDays Melbourne 登壇

CloudNative Days Tokyo 2019で『Knativeで実現するKubernetes上のサーバーレスアーキテクチャ』を話してきました #CNDT2019

ServerlessDays Melbourne 2019でBuild serverless application on top of Kubernetesを話してきました #sdmel19

CloudNative Days TokyoではKnativeが「どういう課題に対し、なんの機能がある」という形を意識してユースケースを組み立てました。

それに対してもうちょっとKnativeの大枠の意義や、どういうロール人の何を解決するのか、個々のコンポーネントの使い方でなくて構築したプラットフォームをどう使うのかという部分が知れるとよくなるのではないかというフィードバックをいただきました。

ServerlessDays MelbourneではKubernetesで運用するアプリケーションのツラミからそのソリューションの1つとしてのKnativeのような形に構成を変更して臨みました。

他のソリューションとの比較や構築したプラットフォームの活用までは至っていませんが、それは10〜12月のOKRに深く関係します。

対外的な発表だけでも検証した内容の抽象化や再構築にはとても役立ちますが、フィードバックをいただきブラッシュアップするプロセスはとても大事だと改めて感じました。

また、発表する前にレビューしてもらう段取りができなくて落ち込むこともありました。しかし、長期的なテーマを設定していろいろと取り組む前提で、イベントが終わってからじっくり感想をいただく形式も必ず進捗が生まれるので気が楽になりました。

Key Result 2 【できた】

Knativeを使ったプロダクトでどう利用されているか説明できる

  • CloudNative Days Tokyo 2019 登壇
    • Knative Lambda Runtime
  • 技術書典7執筆 既刊Knative本アップデート
    • Pivotal Function Service
    • OpenFaaS functions on knative
  • 何かCloud Runの話できる機会があれば

技術書典7で『Knativeソースコードリーディング』『Knativeの歩き方 第2版』『Goで学ぶAWS Lambda』を出展します #技術書典

CloudNative Days Tokyoではユースケースの後半にKnative Lambda RuntimeとOpenFaaSのWatchdogを活用したプラットフォーム構築のお話をしました。

その過程で整理したこの1枚のスライドは、Knativeを使って自分でFaaSを組み立てるときに何を開発する必要があるのかという観点でとても大事なことのようです。この知見を元に10〜12月実際に触れるサーバーレスプラットフォームを構築します。

その調査内容を文字化して『Knativeの歩き方』に章を増やす形で足しました。

Cloud Runの話はServerlessDays Melbourneで少し触れました。会社ではGCPを中心にサービスを構築しており、検証環境も充実しているので自然なユースケースで活用できる可能性も高いかなと思います。その観点で仕様の詳細を理解しておくと意味がありそうです。

Key Result 3 【できた】

Knativeの主要機能の実装方法を説明できる

  • 技術書典7執筆 新刊KubernetesのコントローラーをKnativeで理解する
  • 技術雑誌寄稿 kube-apiserverのクライアント
  • Programming Kubernetes: Developing Cloud Native Applications 再読

技術書典7の『Knativeソースコードリーディング入門』の振り返り #技術書典

6月にかなりお世話になったProgramming Kubernetes: Developing Cloud-native Applicationsを再読し、Knativeの実装を追う本を書きました。

Kubernetesのクライアントライブラリを含むコントローラーの追い方は慣れてきたものの、Knativeの固有実装部分までは終えてないなぁと思います。

メトリクスベースでスケールさせる仕組みや証明書管理、イベント関連の抽象化設計などはKnativeに閉じずプラットフォームの設計・実装にとって重要な要素だと思うので引き続き追っていこうと思います。

寄稿については技術書典が終わってからツール作成に着手し、初稿もなんとか10月頭に間に合いました。社内や編集者の方からたくさんのコメントをいただいたので今後の執筆にも大いに役立ちそうです。別途振り返る予定です。11月半ばに発売されるはずなので楽しみにしていてください!

コントローラーではないもののKubernetesのクライアントを書いたり、関連書籍を読むと自分で書きたい気持ちは高まりました。

Objective 2

嫁氏とゆったりした時間を過ごす

Key Result 1 【できた】

  • スパイダーマン観に行く
  • バンブルビー観る

観た!

Key Result 2 【できた】

  • 花火大会に行く

行った!

行ってみたいところ、やってみたいことは突発的に発生するところだけではなく、計画しないと実現できないこともあります。

カッパドキア行きたいとかクリスマス島のカニ見たいとかディズニーのミラコスタ泊まりたいとか。

リストにすると「やるべき」こと感が出る一方で、本当に実現したいなら先に時間を確保しないと「俺は強くなりたいので今期はそういうのしない」という判断を永遠に繰り返しそうです。でも今期爆進だけではしんどいということを強く体感しました。

10〜12月期はリスト化して、各期そこから1つOKRに入れてみようかなと思います。

OKR総括

全達成よく頑張ったたまには褒めてあげよう!

習慣の振り返り

2019年の目標

  • 本(執筆): 2冊/年
  • CFP: 4ヶ月に1回出してみる
  • OSS: 1PR/月
  • ひとまとまりのソースコード公開: 1リポジトリ/月
  • 技術書(読む): 30分/日
  • その他本(読む): 30分/日
  • ふぁーーーこれやーーーって本に出会いがっつり感想書く: 1回/3ヶ月
  • ピアノ晒す: 1回/月
  • 筋トレ: 1回/週

進捗

本(執筆): 2冊/年

2/2

終わり!

CFP: 4ヶ月に1回出してみる

合計5本提出のまま変わらず。この振り返りが終わったら2本書く予定です。

OSS: 1PR/月

30/3

1つ1つは細かいですがたくさん出しました。lintツールを実行してそれに基づく修正をしているだけです。

何もリントエラーが出ないプロジェクトと、大量すぎて比較的大事な項目だけ選んでPRを出すプロジェクトの差が激しいです。

このgolangci-lintを利用しています。

https://github.com/mercari/wrench/pull/7
https://github.com/mercari/wrench/pull/5
https://github.com/mercari/wrench/pull/4
https://github.com/mercari/wrench/pull/3
https://github.com/mercari/go-emv-code/pull/8
https://github.com/mercari/go-emv-code/pull/7
https://github.com/virtual-kubelet/virtual-kubelet/pull/774
https://github.com/syndbg/goenv/pull/97
https://github.com/google/ko/pull/89
https://github.com/knative/client/pull/412
https://github.com/knative/pkg/pull/646
https://github.com/ijin/serverlessdays-tokyo/pull/16
https://github.com/k1LoW/tbls/pull/137
https://github.com/kedacore/keda/pull/343
https://github.com/GoogleCloudPlatform/cloud-run-button/pull/82
https://github.com/google/kf/pull/659
https://github.com/google/go-cmdtest/pull/1
https://github.com/syndbg/goenv/pull/95
https://github.com/kedacore/keda/pull/323
https://github.com/syndbg/goenv/pull/94
https://github.com/deislabs/osiris/pull/37
https://github.com/kedacore/keda/pull/323
https://github.com/syndbg/goenv/pull/88
https://github.com/syndbg/goenv/pull/86
https://github.com/kubernetes-sigs/kubebuilder/pull/967
https://github.com/knative/client/pull/388
https://github.com/knative/eventing-contrib/pull/557
https://github.com/knative/eventing/pull/1732
https://github.com/syndbg/goenv/pull/91
https://github.com/syndbg/goenv/pull/90

自分な好きなOSSに対しリリースノートに載るようなインパクトのあるコントリビューションがしたいという思いを強めました。

ひとまとまりのソースコード公開: 1リポジトリ/月

1/3

雑誌寄稿に向けて作りました。10月分のような気もします。

https://github.com/toshi0607/jctl

ワンコマンドで下記全部やってくれます。

  • Goアプリケーションビルド
  • コンテナイメージビルド
  • レジストリにプッシュ
  • Kubernetes Jobとして実行

client-gogo-containerregistryを活用したCLIです。

GitHub Actionsでkindを使ってE2Eテストもやってみました。

以上…!

10〜12月期にはこんなの作りたいです。

  • 何かしらコントローラー
  • サーバーとfunctionsをつなぐミドルウェア
  • DIY FaaS用CLI

意図通りのものがあれば詳しく調べて記事にするのでもよさそう

技術書(読む): 30分/日

読んだ

Kubernetesがもっと好きになる!この本がなければKnativeソースコードリーディング入門 Knativeで学ぶKubernetesのカスタムリソースとカスタムコントローラーは生まれませんでした。Knativeに限らずKubernetes本体はもちろん、作られたタイミングがどうであれ他のコントローラーも読める雰囲気が出てきました。

kedacore/kedaとか読むとよさそうです。

【レビュー】『改訂2版 みんなのGo言語』(2019/8/1、技術評論社)の感想

技術書全然読んでへんわろたw

その他本(読む): 30分/日

読んだ

前作に引き続き読みました。日報とか強化し始めた気がします。社会を形作るのは絶対的な原則ではなく人間なのでたまには処世術に触れるのもよいのではないでしょうか。

氏の本は読むのに時間がかかる本の後にパーッと読みたくなります。

プレゼンの神様、Microsoft澤さんの本です。自分のプレゼンを直視して改めて絶望したので、聞く人の気持ちを考えることにしてみました。まずは社内でやるプレゼンにいくらか活かしてみました。

今も自分が喋りたいことを喋る基本姿勢は変わってません。けど、喋る目的は発信することでフィードバックを得てよりよい理解・アウトプットに繋げることです。なのでこの本で言われているように伝えたい中核となるものや聴衆観点で何をもって帰ってもらうのかを整理することは結果的に自分がもらえるかもしれないフィードバックの質を確実に上げます。

任天堂のWiiの企画をした方の本です。既知の良さと未知の良さがあって、最初は受け入れられないかもしれない未知の良さを探求する方法が具体的なお話を添えて解説されていました。

未知の良さを提供し、最終的に世界を良くするのは大変かもですがやりがいはありますよね。サーバーレスとか直感的に現実的でない、良さよくわからんみたいな声が依然として強いのでチャンスです。

読んでる

Windowsプログラミングの父?チャールズペゾルドさんの本です。コンピュータが動く仕組みを解説する「読み物(≠技術書)」です。めちゃくちゃ面白い。バイナリコードの説明が、「通りを挟んで反対側に住む子供同士が夜中にどうやって会話するか?」から始まって懐中電灯、モールス信号みたいな風に進んでいって「コンピュータの仕組み」的な本と一線を画しています。

CAREER SKILLSで紹介されてて読んでみて正解でした。けっこう時間かかりそう。

あとは筋トレ中のAudible始めました。

ふぁーーーこれやーーーって本に出会いがっつり感想書く: 1回/3ヶ月

今Qベストは世界№1プレゼン術でした。

ピアノ晒す: 1回/月

鍵盤1回も触らなかった…久石譲さんやっていきたい。

筋トレ: 1回/週

完璧!締め切りがいろいろ厳しくて2回くらいスキップしようとしたもののちゃんと行ってえらい。

今後の話

プラットフォームの運用・構築・開発、利用サポートができるエンジニアになりたい思いが強まったので、個人OKRもそれに寄せていきたいです。人と話して目の前の技術スタックに活きる順番ではまずKubernetesの使い方・動作原理を理解してより低レイヤーに降りていくのが現実的そうでした。本業として実現できるように頑張る。

サーバーレスも何かしらのPaaSやFaaSを使って開発することが目的ではなく、嫌なオペレーションを少なく、ビジネス価値により集中できるプラットフォームを活用して開発するのが本旨です。

これらを踏まえて技術スタックを3ヶ月単位で積み上げていきます。そういう方向性をもって人生を歩んだ結果3ヶ月後に全然違うことを言うのはありとします。7〜9月のOKRや集中すべきことを考えたり、運用したりする中で、何をやってもなにかしら自分にとってプラスの経験にもなるし思いもよらないよい出会いもあるけれど、長期的に目指したい姿を思い描いた上でやる方がよりワクワク過ごせそうです。集中もセレンディピティも失うことなく進んでいくのです。

10〜12月の個人OKRはつぎのような感じでいきます。

Objective 1

プラットフォームエンジニアへの闘争

Key Result 1

DIY Serverlessプラットフォームを構築する

  • ServerlessDays Tokyo
  • ServerlessDays Fukuoka
  • CLI
  • server -> functionのミドルウェア

Key Result 2

Kubernetesの知識を網羅的・原理的に理解する

  • CKA取得
  • 何かコントローラー作る
  • つぎの図をソースコードに基づき説明できるようになる

Key Result 3

プラットフォームを支えるOSSにコントリビューションする

機能 > テスト > リントツールでわかるもの > 設定ファイル > ドキュメント・コメント

Objective 2

ゆとりある心で秋〜冬を感じる

Key Result 1

心があたたまる食べ物を食べる

  • 鍋パする

Key Result 2

季節のイベントに参加する

  • ディズニーハロウィン
  • 温泉
  • もみじ、山

Key Result 3

やりたこと、いきたいことリストをつくりワクワクする

登壇

執筆

記事

四半期ごとの人生振り返りです。

サマリ

個人OKRで集中とゆとりを

習慣

2019年の目標

  • 本(執筆): 2冊/年
  • CFP: 4ヶ月に1回出してみる
  • OSS: 1PR/月
  • ひとまとまりのソースコード公開: 1リポジトリ/月
  • 技術書(読む): 30分/日
  • その他本(読む): 30分/日
  • ふぁーーーこれやーーーって本に出会いがっつり感想書く: 1回/3ヶ月
  • ピアノ晒す: 1回/月
  • 筋トレ: 1回/週

進捗

本(執筆): 2冊/年

1/2

前回から変更ないです。技術書典7に出典申し込みしたので、8〜9月にもう1冊を書けたらいいですね。

CFP: 4ヶ月に1回出してみる

CloudNative Days Tokyo 2019のあと、海外カンファレンス2つに計4本のプロポーザルを出しました。合計5本になったので今年の目標は達成です。

年初のプロポーザルを提出したことがない状態から「とりあえず書いてみる」はできるように成長したと思います。

テーマがあれば関連する国内外のカンファレンスに提出する習慣はできたので来年は別の目標にしようと思います。

今年修正しないのは今年提出予定のカンファレンスがあと2〜3回あり、まずはそれをできる限りいい感じにこなすので手一杯だからです。

いっぱいいっぱい感がすごいのでそれをなんとかする目標は早い段階で立てないとちょっと体がもたなそうで、断るというのを覚えた方がいいかもしれません。

8月のServreless Days Merbornは審査に通過したので15分Knativeのお話をしてきます。初海外カンファレンス登壇ドキドキ!

ServerlessDays Stockholmもプロポーザル出したいのですがServreless Days Tokyoに近すぎるので自重するか迷います。CFPのクローズが9/1なので、8月半ばに考えます。

OSS: 1PR/月

8/3

https://github.com/ahmetb/cloud-run-faq/pull/22
https://github.com/syndbg/goenv/pull/86
https://github.com/syndbg/goenv/pull/84
https://github.com/knative/docs/pull/1373
https://github.com/syndbg/goenv/pull/83
https://github.com/syndbg/goenv/pull/78
https://github.com/syndbg/goenv/pull/73
https://github.com/knative/docs/pull/1147

達成したものの、ただGoがリリースされた瞬間にgoenvの設定ファイル足すマンになってるだけですね…

CloudRunのFAQ修正はGCPUGで話題になったことを一応手を動かして確認したのでよかったかもしれません。

数を追う目標はこの辺でおいておいて、本当にコントリビューションしたいOSSに腰を据えて取り組む方が意に沿っているかもしれません。

ひとまとまりのソースコード公開: 1リポジトリ/月

ダメです。

技術書(読む): 30分/日

読んだ

カスタムリソースやコントローラーに入門するのにうってつけでした。今度の技術書典のテーマなのでもう一度読んで咀嚼したいです。

読んでる

その他本(読む): 30分/日

読んだ

めっちゃよかった。前職からOKRで目標管理されているけどO/KRの設定仕方やそれをいい感じに運用するためのC(対話)F(フィードバック)R(承認)への認識を見直せた。

薄々意識しつつあまり考えないようにしていたけど、個人の振り返り(四半期ごとにやるこのブログ状のもの、会社のではない)ではよさげな習慣を身につけるべくコントローラブルな目標をどの程度達成したかを確認しています。

けどそれってO(目標)なきKR(主要な結果)なのではと思います。

よさそうな習慣なんて取捨選択しなければ自分ではこなしきれないほどある中で、何を大事にするのかは目指すべき方向性から考えると平和そうです。何を捨てるかも同じです。

最近は登壇と執筆の1つ1つが重い中、業務も産みの苦しみを味わっている真っ只中で公私ともに心のゆとりを失いました。

自身の挑戦や成長に伴って得られた思いもよらない機会を大事にしたい一方で、1つ1つクオリティが下がっても元も子もないなと思います。

読んでる

If you want to go fast, go alone. If you want to go far, go together.

の後者の意味を忘れつつあるので思い出したいです。

1人でやってるわけでも全然ないのになんやろう?

ふぁーーーこれやーーーって本に出会いがっつり感想書く: 1回/3ヶ月

今QベストはMeasure What Matters 伝説のベンチャー投資家がGoogleに教えた成功手法 OKRでした。

ピアノ晒す: 1回/月

とうとう晒し始めることに成功しました!

YouTube チャンネル

が、早々にピアノを触る余裕を失ったので取り戻したい。

筋トレ: 1回/週

完璧!

往復40分、1回500円、回数券とポイントありのところに通い続けるか、近くのエニタイムに変えるかはちょっと迷っています。

外部的要因が無ければチャリも運動と思って続けそう。

技術面

12月のServerless Days FukuokaのCFPに応募して「Knativeで作るDIY FaaS」みたいな話がしたいです。

話せなくていいから作りたい。そしてServerless Advent Clendarとかでコード交えてじっくり説明したい。

OKR

OKR本の文脈で書いた取捨選択らへんの話をもう少し考えてみます。

今年の予定はここから雑誌寄稿を追加する予定なのと、Serverless Meetup Tokyoの登壇が次の回にずれるというのと8月のSeverless Days Merbornに登壇する以上には増えないかもしれません。

とは言え、7月段階で考える半年の予定なのでかなり当てにならなそうです。

個人OKRを決めて集中すべきことに集中してみようとなったときに、仮に「FaaS作るぞ!」をObjectiveに据えると

  • 今関心があってやってみたいことなので、3ヶ月これに集中するぞ!という絞り込みには有効そう
  • 長期的に何ができるようになりたくてどう位置付けるべきかは考えないと「で?」ってなる
  • 登壇や執筆は求められるテーマとタイミングによるところもあるが、そこまで乖離することもないのでObjectiveから導ける範囲で取り組むと有効に活用できそう
  • 暗黙の長期目標(これを明らかにしたい)の中で足腰鍛えたいなぁと思うこと、例えば前回の振り返りの技術面で書いたネットワーク(L4/L7、DNS、名前解決)なども「Knativeを触る上で必ず出てくるので1つKey Resultにおいてみる」とかするとモチベーションを保ったまま強くなれるのかもしれない

という感じで、概ねポジティブな印象です。

一方、これから7〜9月のOKR考えるぞ!ってなったときに、ある程度の執筆や登壇のテーマは先に決まっていて、それらをこなすだけでも時間かかりそう。

ただ、技術書典の出展申し込みをしたときのスタンスとして、「今はKnativeの実装をKubernetesのコントローラーを見ながら詳しくなりたい。ただし、書き始めたタイミングで興味関心が変わればそっちを書く」としていて

  • 事前申し込みするときテーマ・解釈に幅を持たせると気持ちが楽
  • 1〜2ヶ月(申し込んでから実際に準備したりするまで)でそこまで興味関心すぐ変わるというわけでもなさそう

とも思うのでクオーター単位のOKRから始めていって様子を見ることにします。ただし必ず生活面のOKRも含めることとする!

2019/07〜09

Objective 1

DIY FaaSのためのKnativeのユースケース、動作の仕組みを理解する

Key Result 1

どんな課題に対してどう使うのかを説明できる

  • CloudNative Days Tokyo 2019 登壇
  • ServerlessDays Melbourne 登壇
Key Result 2

Knativeを使ったプロダクトでどう利用されているか説明できる

  • CloudNative Days Tokyo 2019 登壇
    • Knative Lambda Runtime
  • 技術書典7執筆 既刊Knative本アップデート
    • Pivotal Function Service
    • OpenFaaS functions on knative
  • 何かCloud Runの話できる機会があれば
Key Result 3

Knativeの主要機能の実装方法を説明できる

Objective 2

嫁氏とゆったりした時間を過ごす

Key Result 1
  • スパイダーマン観に行く
  • バンブルビー観る
Key Result 2

花火大会に行く

よさそう。長期的なことや次のQを意識しつつ直近3ヶ月に集中すること書くのは目的意識を持てそうです。

筋トレとかピアノとかも年間で掲げている習慣を意識するのもいいかもしれないですが、3ヶ月で何を目指すかの方が調整もできてやる気も出るかもしれません。

長期の目標を達成する上で3ヶ月単位では漏れてしまうことは1年の習慣の方においておいてもいいかなと思う一方で、長期目標を達成するための過程として各QのOKRが設定できてるなら敢えて分ける必要もないかも。

登壇

mercari.go ♯8で『Goで学ぶKnative』を話してきました #mercarigo

執筆

技術書典4月でしたね。BOOTHでも継続して販売してます!

関連記事

記事

バズらないことに定評があるので嬉しいです。

3月の登壇をログミーさんに記事にしていただきました。

話した通りに完璧に文字起こししていただいたのですが、自分の言葉遣いが酷くて反省しました。

結果、読める程度に大幅に修正することに…

仕事面

生きたい。

とある目標を持ち始めたので、それを実現するために個人OKR活用できるかもしれません。

仕事は仕事で達成すればええやんとも思うものの、ストレートに結びつかないこともありそう。

生活面

ひたすら猫がかわいい。

haru201907121

技術書典6の売り上げで購入した食洗機、本当に買ってよかったです。

分岐水栓取り付けについては、固着してカバーが外れなかったので自力では全部できず大変でした。本当にほぼ新築なのか…?

四半期ごとの人生振り返りです。

サマリ

  • プラットフォームのプラットフォームを実装しよう!
  • 猫かわいい
  • リリースした

習慣

2019年の目標

  • 本(執筆): 2冊/年
  • CFP: 4ヶ月に1回出してみる
  • OSS: 1PR/月
  • ひとまとまりのソースコード公開: 1リポジトリ/月
  • 技術書(読む): 30分/日
  • その他本(読む): 30分/日
  • ふぁーーーこれやーーーって本に出会いがっつり感想書く: 1回/3ヶ月
  • ピアノ晒す: 1回/月
  • 筋トレ: 1回/週

進捗

本(執筆): 2冊/年

1/2

技術書典6に出す新刊がなんとか間に合いました!ということで年間進捗50%です。

技術書典6で『Knativeの歩き方 KubernetesからServerlessを訪ねて』と既刊第2版を出展します #技術書典

技術書典6は単体で学びや反省があるので、それは本番が終わってからまとめます。

お陰様で紙本は売り切れましたが、BOOTHで販売してます!

Knativeの歩き方 KubernetesからServerlessを訪ねて(PDF、ePubセット版) #技術書典

CFP: 4ヶ月に1回出してみる

初めてプロポーザルを出しました。講演内容の字数制限が200字とけっこう厳しめでした。「どんな人に向けた講演かこの講演によって受講者がどんな情報を得られるかを含めることをおすすめします」を書くことが推奨されていて、それを書くだけで埋まります。

こんな内容で提出しました。

[講演タイトル]
Knativeで実現するKubernetes上のサーバーレスアーキテクチャ

[講演内容]
Kubernetes(k8s)上でサーバーレスアーキテクチャを実現するKanativeが何を解決するのかをユースケースを交えて紹介します。
本講演は次のような方を対象にしています。
・Knativeがなんなのか、k8sとどのような関係にあるのか、どういう仕組みなのかを知りたい
・k8s上でもサーバーレスアーキテクチャを実現したい
・k8s上のアプリケーションの開発・運用負荷を下げ、機能開発により集中したい

会社でたくさん登壇をしている方のスライドでこの記事が紹介されていたので熟読し、ポエムになったり、過度に理解の前提をおいたりしないよう気をつけました。

肝心のKnativeをタイポしてて悲しくなった…。

登壇の可能性をあげる!カンファレンスプロポーザルの書き方のススメ

プロポーザル一覧

採否がわかったのは振り返りスコープ外の4月になってからですが、採択していただけたようなのでがんばります!

そしてプロポーザルを出すことに抵抗を感じなくなったので、自分のテーマに関連のあるものは出していこうと思いました。プロポーザルを出したカンファレンスでまだ登壇したことないにも関わらずw

わくわくしながら継続的に取り組みたいテーマがあるのはやりやすいです。

OSS: 1PR/月

what-happens-when-k8sは頑張った感があります。今年に入ってKubernetesキャッチアップするにあたってだいぶ勉強になりました。

Serverless FrameworkへのCloud FunctionsのGoテンプレート追加はServerless Meetupのきっかけにもなったのでよかったです。

設定ファイルばっかり追加してても自分には何も進歩ももたらさないので、もうちょっとサンプルなりKubernetes周辺のコードなりいじっていこうな!

ひとまとまりのソースコード公開: 1リポジトリ/月

2/3

Cloud Functions Goは技術書典終わるまで触るまいと思ってたのですが、Serverless Frameworkを見てみたらテンプレートがなかったのでほんのちょっとだけ触ることにしました。

pseは年末〜正月に書いていたCloud Pub/SubのエミュレータをいじるためのCLIツールです。社内の勉強会で発表したら需要皆無だったのでまぁお疲れさまみたいな気持ちです。

最近個人プロジェクトも何も書いてないですね。

Knative周りは概念理解フェーズが終わっていよいよユースケースをいろいろ検証するフェーズに入るので何か書こうと思います。

技術書(読む): 30分/日

読んだ

この本に出会ったおかげでKubernetesを深めていこうという気持ちが湧きました。今年のすべてはここから始まった。

読んでる

8章のFunctions and Event-Driven Processingだけとりあえず読みます。

今読んで意味がありそうなのと、読まずに実装と概念の間ばっかり追ってても設計力上がらなそうなので一歩引いてみたいです。

近々邦訳版が出ると思いますが、たしか何かのときにタダでPDF配ってたはず…?で手元にあったのを読んでます。

その他本(読む): 30分/日

読んだ

内容的にビジネスライティング的な域を出てない気がしました。が、社内ドキュメントを書くときに意識してみると構成を改善できたのでたまにこういうのも触れるといいなぁと思いました。

自分(というか人間)が思い込みで判断しがちな観点に自覚的になれそうです。

たぶん2、3日くらいで忘れるのでまとめページたまに見返すとよさそう。

学び方を学ぶのには定期的に投資したいです。

チューターのときによく話していた忘却曲線の話が乗っていたり、苦しくて避けてしまう「意識的に思い出す」出すなどいろいろと技術習得に取り入れるとよさそうなことが書いてありました。

特定言語の文法など、反復せざるを得ないことは必要期間忘れないかもですが、Kubernetesの仕様など体系が大きく、習得が困難なものや概念の理解に特に活かせそうです。

すごいいいこと書いてあった気がするけどだいたい忘れました。技術を離れて知らない「概念」に出会う機会が最近なかった気がするので新鮮でした。

結局身近なものとのアナロジーで理解しようとするので歪めてる気はしつつ、そういう自覚をもって向き合うことも大事そう。

書いてあったことだいたい忘れました。

ふぁーーーこれやーーーって本に出会いがっつり感想書く: 1回/3ヶ月

今QベストはKubernetes完全ガイドでした。

感想とは。

ピアノ晒す: 1回/月

MIDI出力あるキーボード使っててその録音方法がわからん…!

スピーカーはない。こんな感じです誰か助けて!!!

YAMAHA ステージピアノ P-90
これ

筋トレ: 1回/週

完璧!

技術面

Knativeを追う中でプラットフォーム(を作るためのプラットフォーム)を作りたい気持ちが強くなりました。

それを抽象化するミドルウェアも楽しい。

けど現状作るには全然いたらずなぞってるだけなので、次の3ヶ月はユースケースを追う、作るなどやっていきます。

カスタムコントローラーに限らずKubernetesのAPI叩く何かを実装するのはいろいろと楽しそう。

なのでこれ読んだりもしたいです。

導入的なところだけ読んだらKubernetesを拡張する仕組みはCRDとカスタムコントローラー以外にもいくつかありそうで最高っぽかったです。

あとKubernetes追いながらそもそも弱すぎると思ったのがたくさんあったのでがんばれっていう感じです。

・データ構造
 ・計算量
・アルゴリズム
・ネットワーク
 ・L4/L7
 ・DNS、名前解決
・暗号化
 ・KMS
 ・ローテーション
・CPU/memory

登壇は目標でなくなったけど記録。

仕事面

リリースしました。

生活面

昨年末にペット可物件に引っ越し、とうとう1月末に猫を迎え入れました。

豆柴かその他猫か迷ってたのですが、ペットショップにどんな子がいるか見に行った帰りには子猫を連れて帰っていました。

数日間ケージや餌をもらってホームステイさせてもらえるところがあったので乗っかりました。

自分が猫・犬アレルギーだったのが最後の懸念点だったのですが、まぁ死にはしなさそうだったので、契約後正式に家族に。

種類は大きくなるノルウェージャンフォレストキャットで、論理的帰結として名前はハルくんです。

プラス、リリースできる未来があまり描けてなかった冬、僕らにも春が来るようにとの過度な希望を託しました。ごめん。

ちゃんと来たよ、春。

もうほんとかわいくて、かわいい以外の感想が出てこない程度にかわいいです。

最初こそ自分から寄って来ることはそんなになかった気がしますが、最近は帰宅して座っていると膝の上に乗ってきて迎えてくれます。

かわいさしかない。

引っ越しや新たな家族迎え入れを契機にいろいろ買いました。

最新はV11とか出てますが、吸引力十分で音もそこまでうるさくなくて満足です。

テレビでこれを使って撫でられてる猫の表情がやばかったので買ってみました。

とりあえずうちの子はこれを噛みます。

お出かけ時に入ってもらう用。普段から部屋の中に置いていて、狭いところが好きなのでたまに自分から入ります。

最初こそこれで爪をといでましたが、最近はソファーと半々くらいです。

ソファー意外と痛まないので好きにさせてます。

これで遊ぶと絵的にかわいいという下心で買いました。

最初こそ猫キックしてましたが最近はオブジェです。

これ本当によくて毎日遊んでます。まだ飽きてないし、140円とかコスパ良すぎる…。

そこまで耐久性はないかもなので、まとめて買っておくとよいかも。

何使っても爪切るのは嫌がるので、眠そうなときを狙うとなんとか切らせてもらってます。

よく切れます。

これで毛を抜いてます。ふわふわしてるので隔週くらいでお手入れです。

帰宅して膝に座って甘えてくるタイミングが狙い目です。

毛抜いたら整えます。

大きくなる猫種なので大きめのを選びました。

留守のときケージに入れときたくもないけどもうちょい受け入れ体制が必要。

水かえやすくてよいです。

大きめでよいです。

前傾姿勢で食べるので、ちょっとでも高さがある方がよいと思って選びました。まぁ何使ってもよく食べます。

技術書典も無事終わったのでものいろいろ捨てよう。あと食洗機買おう。

明けましておめでとうございます。

2018年はGoに出会って気づいたら転職し、新婚旅行し、ロールが変って闘争が激化し、引っ越し、初の単著商業誌が発売された年でした。

新婚旅行記事毎日書いたのにいまだにブログのっけてない…

振り返りは3ヶ月単位でやってるのですが、年単位のやつも10〜12月分の振り返りに組み込みます。

それに加えて2019年の目標と立てます。

2018年10〜12月と2018年の振り返り

2018年の目標(再掲)

年初に立てる目標は定量的に白黒はっきりするアクションにしました。

特定の技術領域に詳しくなる、的なテーマはその時その時で変わるのでアクションの方向付けくらいに考えています。

  • 本(執筆): 2冊/年
  • 登壇: 6回/年
  • OSS: 1PR/月
  • ひとまとまりのソースコード公開: 1リポジトリ/月
  • 技術記事: 2記事/月
  • 技術書: 30分/日
  • その他本: 30分/日
  • カラオケ: 2回/月
  • 歌練習: 1回/週
  • 品川健康センター: 2回/月
  • 走る: 1回/週

これまでの振り返り

進捗

本(執筆): 2冊/年

2/2

一応達成しました。2冊目は1から書いたものではないもののよいことにします。

『GoとSAMで学ぶAWS Lambda』がインプレスR&Dさんから発売されます!

GoとSAMで学ぶAWS Lambda (技術書典シリーズ(NextPublishing))

1冊目は技術書典5版の『Goで学ぶAWS Lambda(PDF、ePubセット版) #技術書典』です。

(そういう意味ではExtensive Xamarin ─ひろがるXamarinの世界─が出たもの今年ですね!こっちは本当に自分は何も加筆修正してません)

もう1冊自分の担当章 + 追加で依頼された分書いてたのですが、結局全体として校正プロセスに進みませんでした。

自分がいまいまやってる分野に近ければ調べて書くなり、完了状態に持っていくためのアクションをとったかもしれません。

けど自分の担当した章ですら再現する環境がもう無い程度に離れてしまったのでそういう気もおきませんでした。

2〜3月の土日をだいたい返上して書いただけに残念ですが、

  • 今の興味関心と合致するか?
  • 本書くことが目的になってないか?
  • 共著であれば全員やりきってくれそうか?

みたいな自分が本を書くべきかどうかを判断すべき基準ができた1年でした。

共著と単著と商業誌とフィードバック

共著は何かしら共通するテーマで本を書くだけに、共著メンバーのレビューも期待できる(かもしれない)し、分量が求められる局面でも一人で頑張るよりは応えやすいです。一方、「技術書典に出す」などのどうあがいても覆らない期限がないと完成しないこともあります。

単著でかつ非商業誌の場合は完成しなければ単にそこで終わりだったり、適当なサイズで技術記事にしてしまえば書いた分が無駄になることもなく、共著よりスケジュール面でコントロールできる裁量は大きいです。

ボリュームについては、自分が読者として本を読むときは知りたいこと、知ってよかったことが書いてあるかどうかの方が本全体のボリュームより大事だと感じます。なので自分が本を書いて世に送り出すにあたっては量は気にせず、何が書いてあったら嬉しいか、(分量を稼ぐための)冗長な表現があるとしたらかえって理解を阻害していないか、などに集中すればよいと思います。

商業誌としてAmazonに出ると「分量の割に値段が」というレビューがついてしまうのが頭を過ぎります。この「分量」が単に本全体の分量なら知らんがなページ数書いてるやろっていう感じですが、有益に感じられる部分が少ないのだとしたらレビューを書いた人にとってその本に知りたい内容が含まれるかどうかを判断できる情報を出す努力もすると平和そうです。過剰なキャッチで出さない、いい感じに各章にサマリをつけるなど工夫の余地があります。

そういうレビューすらつかなければ世間でどう見られているのかわからんですね。

本が技術書典を飛び出し、商業誌として出版されること自体の価値はわからないです。ある程度の分量の文章を期限内に書けるということは技術書典で本が出せたら対外的に示せます。

もし商業誌がたくさん売れたら幅広い人にウケる内容の本をウケる書き方で仕上げることができる、というのが結果的に示せるのかもしれません。

色々と思索に耽ることはできると思います。しかし、僕が本を書く根底にあるのは、ある程度人への説明になる言葉で一定量以上まとめることでその技術の知見を深めることです。

なので読んで欲しいと思う人々に書いてる事実を知ってもらいつつ、確実にフィードバックがもらえる行き渡らせ方をできるようにしたいなぁと思いました。こういう感じで告知したり、勉強会でタダで配ったりしても期待する成果は得られませんでした。

フィードバックが欲しいなら高めたい技術と仕事で扱う技術を完全に一致させてレビューを受けざるを得ない状態にしたりするそもそも論があります。それでもやっぱり本という形に仕上げるのはとても楽しいので、これからもよいやり方を探りながら続けようと思います。

今年も2冊は出したいです。技術書典が年2回続く限り達成できるけど、毎回コンスタントに自分が向き合うべき技術に関して本書くのってただそれだけで難易度高いと思います。

今のところこの辺りで考えています。自分が向き合うものが変わったり新しく出てきたらそっちを優先します。

  • Knativeのアーキテクチャ
  • Knativeで提供するFaaS
  • Goで学ぶ Cloud Functions(GA期待)

登壇: 6回/年

5/6(年)

1回足りませんでした。

2018年10〜12月には1回。登壇かと言われると違うけど[秋葉原] Vue.js入門 輪読会 10章 中規模・大規模向けアプリケーション開発 (実装)で資料まとめて発表するマンをやりました。

資料
Vue.js 入門の第10章「中規模・大規模向けのアプリケーション開発③実装」

サーバーレスの文脈でフロントを書くにあたりVue.js使いたくて、各章週1で進んでいく勉強会の敢えて最終回に立候補しました。

勉強会では早く終わりすぎかつそういう場合を想定したネタの仕込みもなく至らなかった感が大きいです。

大体実装の説明が書いてある章でどうやったら輪読会として意味が出るのか考える過程でこういう枠で整理したらよさそうみたいなのが見つかったので今度こういう機会があればまたやってみます。

  • 概要: 本の内容をまとめたもの
  • 仕様: 本で使われている技術の仕様を確認するもの
  • 議論: 本で論点が提示されていて意見を聞いてみたいもの
  • 質問: 読んでてよくわからなかったので助けてください
  • 感想: 感じたこと

同じ目的の整理用フレームワークとかありそう。

本を書くのと同根で、自分が知見を深めたいテーマの勉強会やカンファレンスに申し込むのはこれからもありだと思います。

発表すること自体を目的にせず、何かしらコードを書いたり、調べてみて世に問うてフィードバックをもらえる状態にすることが前提です。

キャパや工夫が足りず実現できなかったのものの、2018年ならserverless Conf TokyoでLTなりセッションするなりできればよかったです。

ウケ狙わず純粋に自分の興味関心分野でCFPを出して通ればよりフィードバックに期待できそうですね。

CFP出すのにリスクはたぶん無いので出してみようと思います。

目標として「6回何かしら登壇する」よりも「テーマ決めて覚悟決めてCFP出す」って挑戦しがいがありそうですよいと思いました。

出す、というのもコントローラブルです。

OSS: 1PR/月

7/3(10〜12月)

2018年10〜12月としては

です。Goを初めたきっかけの1つはサーバーレスなOSSがGoで書かれることが増え、PR出すワンチャンあると思ったからです。

Serverless Frameworkはjsですが、Goのテンプレート生成する部分なのでGo書く必要があり、目標の1つが果たせてよかったなぁという感じです。

1年まとめると

10〜12月: 7
7〜9月: 5
4〜6月: 3
1〜3月: 5

ということで20のPRを出しました。これもPR出すことを目的とせず、自分が深めたい分野のOSSを読んだり使ったりしていると直せる部分は必ず出てくるので、それを放置せずみんなが使いやすいようにしようという感じで続けられたらよいなぁと思います。

今年も去年と同じく四半期3PR目安くらいでがんばります。

ひとまとまりのソースコード公開: 1リポジトリ/月

2/3(10〜12月)

できませんでした。

10〜12月は

の2つです。

custom-runtime-go-sampleはLambdaの新機能Lambda Custom RuntimesをGoで実装したものです。ライブラリ書いたの初めてです。

公式でもGoはサポートされてるだけあってわざわざ実装してる例はパッと見GitHub上にはなかったのでこういう「自分の理解を測るための無駄」はどんどんやっていきたいです。

pseは久々のCLIツールです。Cloud Pub/Subのエミュレータをいじる公式のツールがなく、公式ドキュメント上ではPythonのスクリプトをダウンロードさせて実行させてたので作りました。

数的には届かなかったけど僕はそれぞれ好きなので満足です。

1年全体としてはhomebrew用のリポジトリは除いてちょうど12リポジトリでした。

去年はGopher道場に参加してからCLIツールを作ったり、技術書典に本を書く前提としてまとまった分量のコードを書いたのが大きいし、そうしてとてもよかったと感じました。

「影響を受けて俺も似たようなコードを書いてみた。こういう仕様にしたらもっとよいのでは?みたいなイシューも立ててもらって公開しておいてよかったみが強かったです。

逃げかもですが、UIをHTMLとCSSとJSで書かなくてもツールをシュッと公開・配布ができることで世界が広がりました。

別にJSでもPythonでもなんでもCLIツールくらい書いて出せばよいと思うものの、自分が書いてて楽しいと思う言語自体と周辺環境がいい感じに実現しやすい状態になっていると思うので、なんというかありがとうという気持ちです。

ボットも同じ文脈でUI書かなくても公開できるのには変わりないですね。

ツールを公開する上ではビルド環境がある人向けにはコード書いてGitHubにでも置いておけばいいですが、各OS向けにビルドしたり、HomebrewやScoopに継続的に対応する過程でCIの知見も増えました。

いい流れだと思うので、同じ目標で継続します。

本や登壇と絡めつつ、WebなUIを伴うものも書けるといいですね。

技術記事: 2記事/月

4/6

年間は17でしょうか?あんまり書いた記憶もないですね。

4〜6月に職場で書いたQiita::Team計算に入れてた雰囲気があるので、現職のWikiを加えるともう少し増えそうです。

本、登壇、リポジトリで大体目的は果たせてそうなので技術記事の数値目標は置かなくてよいと思いました。

GitHubのREADMEとか、多くの人に知ってほしいツールは英語記事書くとかそういうのがんばろう。

削れるものは削ってシンプルにしたいですね。

振り返りが手間的に辛くなったら元も子もないです。

本: 30分/日

技術書とそれ以外30分ずつということでおいてますが、11月くらいから毎日技術書は読めてないかもです。

読めなくなるまではコンテナ系の本を読んでたのですが最近は気持ち的に焦り日々の仕事の状況整理に充てていました。

長期的にみてよくないので戻そう。

読んだ

去年一番影響を受けた本です。

テックリードとしての闘争

でも触れています。

やっぱちっさくてもいいから自分が作りたいものを作ってみないとわからんと思いました。

もっと色々検査した方がよさそうと思いました。口周りの病気、思ったより全身に影響ありそうなので四半期に1回は検査受けるとよさそう。

ある言論の妥当性を判断するとき、昔からそうやってきたからそうあるべきとか、普通はそうだからそうとか、自分の考えに沿わせたいからそうしないのは嫌とかになっていないか?(主観が含まれていてもいいがそれも含めて)妥当でなく、手間が増えるだけとかならはっきりNOと言おうと思いました。

あんまり覚えてないですがここまで徹底できるのすげぇと思ったし、仕事最高!!!みたいな価値観で石原さとみさんを勝ち得ているので完全に勝っていると思いました。

「断捨離」とイメージするものよりもちょっとスコープの広いもので、いろいろやめてみてもいいかもなぁと思いました。

自分が人に対して嫌だなぁと思うことって自分を写す鏡(自分にも少なからずそういう部分があって、自分は抑圧している)なのでまず自分と向き合え(?)みたいなのなるほど身がありました。

好きなことにとことん熱中しような!

『えんとつ町のプペル』の宣伝かな?って思ってたんですが、読んでみたらまさにタイトル通り「現代のお金と広告」の話でめちゃくちゃ面白かったです。

本音で生きような!

読んでる

まず本のスタイルとして、哲学通史的な説明だとつまらんから人生に洞察のある切り口ごとに紹介していくというものになっていて面白いです。

また、机上的な話が多いと思いきや心理学の実験 + 直接しがちな状況への適用など、自分が生きる上で目の前の現象の捉え方に影響があるような書かれ方がされているので、エンジニアリングにもマネジメントにも活きている実感があります。

はよ読まな…

歌系

とうとうやめました。歌に限らず、飲み会など大きめの声を出さないと会話できない状況で話し始めの一音目が出ない(空気が漏れる感じで音にならない?)状態です。

ほぼ聞き直されるので余計焦って一層声出ないみたいな感じで結構つらいです。

「どもる」といってイメージされる症状とは違うんですが、これに名前ってついてるんですかね?

日常生活で普通に不便なので治せるものなら治したいです。が、症状だけでググってもなんと呼んでよいものかわからずです。

一方、前職退職時にこのキーボードをいただき、ちょろちょろ弾くようになりました。

動画と音別で録ってYouTubeに上げたいのですが録音したやつ取り出す方法がようわからんです。

もともと幼稚園のときに買ってもらった61鍵のめちゃくちゃタッチの軽い電子ピアノしか持ってなかったので、家に88鍵のいいタッチのピアノがあることは憧れの1つでした。

今年は5曲くらい上げれたらと思ってます。

運動系

  • 品川健康センター: 2回/月
  • 走る: 1回/週

去年1月から品川健康センターに通い始め、毎週土曜日か日曜日、5月の1回を除き通い続けることができました。

いい感じに習慣にできたのではと思います。

年末に引っ越したので品川健康センターは多少遠くなりましたが、目黒区民センター体育館が近くなりました。

週末に行ってみようと思います。

総合

1年をざっと振り返ると、技術面はGoとの出会いを起点に色々と手を動かしながら学べた年だったんではないかなぁと思います。

仕事に寄り添いつつも仕事の外で立てた習慣目標も達成できた(習慣かできた)ことが多く、今年も続けたいことがたくさんありました。

ただ、この実感は直近の仕事に対する感覚とけっこう乖離してしまっていて課題に正面から向き合わねばと思っています。

目標としては自分がコントロールできて、習慣化できるものを設定する(この方針よかった)ので、課題に向き合うための足腰を鍛えるようなものになりそうではありますね。

あとこれもはや懐かしいです。

好評の Windows 版に続いて急遽リリースを決めた Mac 版アプリの開発に、Xamarin.Mac を採用して大幅な開発効率のアップと機能の標準化を実現。

今となっては関連技術からだいぶ離れてしまいましたが、Microsoft MVP関連でシアトル行けたのもよかったです。一応まだMVPです。

行こう行こうと思って行けていなかった新婚旅行、憧れの長期ヨーロッパ旅行も行けました。よかったよかった。

運動は最高でした。

音楽はつらかったけど聴くと落ち着くピアノで好きな音楽弾けるのはそれはそれでよいでしょう。

ちょっと広めの家に引っ越しも無事終わってよかったです。

引っ越し準備でものを減らしたいだったり、メルカリ使ってみたいだったりでたくさん本や使わない家具・家電を出品したのもよかったけど無駄なものは多いと感じるのでどんどん捨てたいですね。

習慣目標に上げたものは振り返りやすいしそれに対する思いもすごい出てくるけど、そうでないものはものすごいふわっとするというかあんまり覚えてないな…

と思ったら習慣以外にもどんな感じにしたいか書いてました

複業はMS関連のセミナー講師やったりや本書いたり下のとは別に開発チームに入ってやろうとしてましたが、話を聞いてから実際に手を動かせるタスクまで時間が空きすぎて状況が変わったり、いつもそんな暇なわけではないっす…みたいな気分になったりで結局やりませんでした。

身に付けたいけどできないことに飛び込むだけの余裕って今は完全にスケジュールコントロールできないと厳しいのと、それなら本業打ち込むとよさそうな気はします。

給与が大きく変わったのも大きい気はします。

Go、GCP、サーバーレス、コンテナあたりで人的ストレスなければ受けてみたいという謎のスタンスでお待ちはしてます。

2019年目標

仕事面

リリースするぞ以外考える余裕はないです。

テックリード観を持ち、今何が課題で、課題を解決するために自分に何が足りないのかがわかり、足りないことに対してアクションが取れる状態にはしたいです。

今は何に集中すべきというのがいまいちわからず、ただただつらいです。

まずはここから!

  • テックリードとは的な記事読んでなるほどせやなって思うことがあるのでまとめてみる
  • テックリードとかテックリードだった人とかに話聞いてみる

その結果、ロールとしてあるべき姿、自分がこうあるべきと思った姿と自分が目指したいことがずれていたらちょっと考える。

習慣

  • 本(執筆): 2冊/年
  • CFP: 4ヶ月に1回出してみる
  • OSS: 1PR/月
  • ひとまとまりのソースコード公開: 1リポジトリ/月
  • 技術書(読む): 30分/日
  • その他本(読む): 30分/日
  • ふぁーーーこれやーーーって本に出会いがっつり感想書く: 1回/3ヶ月
  • ピアノ晒す: 1回/月
  • 筋トレ: 1回/週

家庭

今年も捨てるぞ!

そして犬か猫を迎え入れます。

食洗機、ダイニングテーブルも迎え入れたいです。

まとめると大体技術的に頑張りたいことが多くて、技術はまだまだ追うことあるので項目として大きく増やしたり減らしたりすることもないなぁという感じです。

家をすっきりさせて、適当に旅行とか温泉とか行って、サウナ毎週行って、たまにピアノ弾いて、基本コード書いたりいい感じに頭使えたらええんではと思います。