四半期ごとの個人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回/週

家庭

今年も捨てるぞ!

そして犬か猫を迎え入れます。

食洗機、ダイニングテーブルも迎え入れたいです。

まとめると大体技術的に頑張りたいことが多くて、技術はまだまだ追うことあるので項目として大きく増やしたり減らしたりすることもないなぁという感じです。

家をすっきりさせて、適当に旅行とか温泉とか行って、サウナ毎週行って、たまにピアノ弾いて、基本コード書いたりいい感じに頭使えたらええんではと思います。

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

サマリ

  • 技術書典で書ききれなかった章足すぞ
  • GCPのサーバーレスやるぞ
  • 今年もアドベントカレンダーがんばろう

習慣

今年の目標(再掲)

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

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

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

この中で歌系は前回の振り返り時点でやめています。

進捗

本(執筆): 2冊/年

1/2

前回の振り返り時に技術書典5の申し込みをし、落選も脱落もせず当日を迎えられそうです。

技術書典5で『Goで学ぶAWS Lambda』を出展します #技術書典

終わったらこれはこれで振り返ろうと思います。

もう1冊技術書典関係なく共著で書いたやつもう無理かなぁ…

登壇: 6回/年

4/6

登壇と呼ぶかどうかは置いておいて、XamarinとAzure APIを使ったハンズオンの講師をしてきました。振り返り記事を書こうと思って完全に忘れていました。

副業の一環でした。たしかソースコードは3月くらいに書いたはず。

コードはmacで書いたのですが、参加者たぶんWindowsやろと思ってハンズオン教材をWindows向けに作ったら参加者全員macという大惨事でした。

今回お誘いいただいたkazuyukimiyakeさんに助けていただきました。今後もなにかしら一緒にお仕事させていただきたいです。

なにかしらコードを書く前提 + 喋るみたいなお仕事はいいですね。

ただ、扱う技術は直近の仕事で使うものや近いもの、もしくは仕事関係なくてもついつい触ってしまう領域だと人生的な効率はよいかもと思いました。

あと、時間が余ったとき用に過去の登壇資料を読み直していたのはやっといてよかったです。

今後についてはテーマのところでちょっと考えます。

OSS: 1PR/月

5/3

やらないよりましなものの設定ファイル追加とかハンズオンの手順修正だけして「OSSにコミットした!!」とか言いたくないなぁ。

そういう意味でもServerlessconf Tokyo 2018 Contributor Dayは今後の活動のよいきっかけできればと思っています。

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

4/3

下3つは技術書典向けに書いたものです。現実のユースケースがそれなりに見える形(ほんとに初めて触るサンプル +α的なもの)をコンセプトに書いてるので、1つ1つそこそこ時間がかかっています。いや、そうでもない?

ただ言えるのは「現実にこれ運用するならこういうコード書いた方がいいかも」って思った書いたコードは仕事でもたぶんそういうコード書くと思うし、今の実力(?)こんなもんかという感じです。手を抜かずに書こう。

技術記事: 2記事/月

1/6

何も書いてないな?技術書典の本は技術記事の延長にあると思うけど、その中から細かい粒度で「こうハマったけど、こうしたら解決できた」みたいなの出してけばよかったかもですね。

あと会社では今細かめにドキュメントに残してるので、毎日書いてると言えば書いてる。

もうすぐアドベントカレンダーの季節もやってくるのでテーマ部分で合わせて考えようと思います。

技術書: 30分/日

読んだ

AWSでいう…みたいな感じで予習になりました。仕事用のキャッチアップとしては遠い…

JSのテスト先に書いてるのがんばってますねみたいな感じであんまりサーバーレス!!!みたいなのは覚えてないですね。

一度読んだ気がするのですが技術書典の参考にすべくもう一度読み直しました。

イメージしやすいサンプルのためのサンプル過ぎない具体的なユースケースとGUI操作は行わずとことんコマンドで操作する感じがとてもよかったです。

読んでる

向き合い続けるものとは思いますが、設計が大事な時期なので。

DynamoDB localのDockerイメージとの出会いで覚醒しました。そういうタイミングに学ぶのが一番モチベーションが高く効率がよいので一気に読みたいです。

技術書典の本の最後のユースケースはサーバーレスSPAにしたかったんですができなかったのと、『Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド』で最後のユースケースでVue.jsが使われていてこれは…!!!って思ったので入門することにしました。

無駄に洋書で読むマン。Safaru Books Onlineのアカウントを得ました。

インプット・アウトプットの質向上には常に取り組むべき。

その他本: 30分/日

別でまとめてるのでそちらで!

カラオケ: 2回/月

声が出なくなったのでやめました。

歌練習: 1回/週

声が出なくなったのでやめました。

品川健康センター: 2回/月

週1で通う習慣が続いています。

走る: 1回/週

品川健康センターで走ってるのでこれも続けられてます。

転職

新しい会社で働き始めてから1ヶ月が経ちました。もう3ヶ月くらいいるような感覚です。

freeeでの闘争を終え、メルペイで闘争します

試用期間大丈夫かなぁ…///などは考える余裕は一瞬もありませんでした。

仕様把握、設計から新たなマイクロサービスを作るというのはまさにやりたかったことで、配属の希望面談どおりです。

はい闘争です。

9月は仕事ではコードを書きませんでしたが、設計もひと段落しとうとうコードを書き始めました。設計も楽しいですが、実装が見えてくると一層楽しい!!

一緒に課題を解決してくれる仲間を探しているので、もしご興味あればご飯でも行きましょう!

merpay Careers

夏休み

転職にあたり、7月末を最終出社として8月はお休みしていました。

前半の記憶があまりないのですが、技術書典のユースケースの実装1つ終わらせた気がします。

後半は新婚 #とは 旅行に行ってきました。結婚したのは一昨年の2年なのでけっこう経ちましたが行けてなかったので。

個人的にずっと行きたかったクロアチア(ドブロブニク、スプリト)、セルビア・モンテネグロ、イタリア(ベネチア)、フランス(モン・サン・ミシェル)に行ってきました。

毎日旅行記を書いていてまだ公開していないので、写真も添えつつちょっとずつ出していこうと思います。

テーマ

直近3ヶ月でいう技術書典的な位置付けでつぎの3ヶ月なにをやるかどうしようかなぁと思っています。

『Goで学ぶAWS Lambda』の続きとVue.js

今回頒布した本の目次は構成要素を考えている段階ではもっと豪勢な感じでした。

少なくとも最終章のURL短縮サービスはサーバーレスSPAにするつもりで、構成要素はつぎのようなものを含むはずでした。

  • 認証・認可(CognitoとかAutn0とか使う) 
  • Vue.js

あとは

  • Lambda上でヘッドレスブラウザ使うユースケース
  • GitHubアサインのSlack通知
  • AWS Serverless Application Repository
  • Kinesisを使うユースケース
  • DLQの設定
  • Alexaスキル系
  • GraphQL(AppSync)
  • SQS(FIFOキュー)のユースケース

GCPのFaaS

Cloud FunctionのGoサポートの申請を待ちつつ…

GCPではまずコンテナやみたいな雰囲気をスルーして本で扱ったようなユースケースを実装してどう違うか触ってみたい気持ちがあります。

GCPのサーバーレス

GCPも最近「サーバーレス」って言い始めたもののAWSやAzureのそれとは何か異なる気がしてその辺を追いたいし、つぎの技術書典のテーマにしたくもあります。

この勉強会とても楽しみです。

GCPUG Shonan vol.32 feat. Serverless & Knative

GCP関係ないけど、Serverless Confで触れたOpenFaaSも近そうで気になります。

Docker/k8s

マネージドサービスでどう扱うかについては仕事上避けて通れないし、GCPのサーバーレスに触れる上では一緒に触れそうです。

アドベントカレンダー

この3ヶ月に技術書典はないので、周囲とワイワイしながらヒーヒー言うイベントは12月のアドベントカレンダーが大きそうです。

去年も相当気合を入れて書きました。

Advent Calendar 4記事の背景にあったテーマ

その結果、問題意識を形にできたり、よい習慣ができたり、書籍の執筆に誘っていただけたりいろいろいい影響がありました。1つのアウトプットの場として今年もなにかしら書こうと思います。

取り組み

一通り並べたところでどう取り組むか迷いますね。アドベントカレンダーの季節にはまた別の興味が生まれているかもしれません。

なにするにしても「これ作ろう」「これ書こう」というアウトプットの形なしに何となく「勉強」を始めるのはとても効率が悪いので、

  • サーバーレスSPA(短縮URL)
  • Lambdaでヘッドレスブラウザ動かすやつ

に実装観点の主軸を置きつつGCPの勉強会でアウトプットの形を探るみたいな感じで行こうと思います。

まとめ

  • 技術書典で書ききれなかった章足すぞ
  • GCPのサーバーレスやるぞ
  • 今年もアドベントカレンダーがんばろう

あ、あとPokemon GO復帰したので友達申請させてください!

freeeでの闘争と謝辞

2018年7月末を最終出社日としてfreeeを卒業します。

2015年1月に入社して以来、社内外関係なくいろんな人、コミュニティ、組織にお世話になりました。

freeeには職業エンジニアとしての経験のない僕を受け入れ、特に最初の1年くらいは自分でも引くくらい成長速度が遅かったにも関わらず見放さずに育ててもらいました。

やる気以外何もないところから、よい会社に移ってよい給料がもらえる程度の1人のエンジニアを育てる環境を提供できてそれだけで死ねる

長生きして欲しいですが、こんなこと言って送り出してくれる会社他に無いと思います。言われた後トイレで10分くらい泣いてたのは内緒です。

エンジニアとして育ててもらったのはもちろんなのですが、それ以上に学びが大きかったことがあります。それは愚直に課題に向き合って価値を届けるということとそれに必要なマインド(freeeでは価値基準という)です。

僕はコードを書いたり勉強したりするだけで楽しいし、力がついていってるような錯覚に陥ってしまいます。ただ、その結果として何が解決される?本当にそれは解決されるべき大事なこと?は常に考えないと、何をするにしてもよい流れにならなかったり、求める結果を得るのに膨大な時間がかかったりでうまくいかなかったです。

手段自体楽しいと思える方が人生楽しいとは思いますが、だからこそ一層意味のあるものにしたいという願いのような意味合いでもあります。

エンジニアとしても(働く、あるいは世の中に価値を届ける)人としても大事なことを学ばせてもらったfreeeに出会えて本当によかったし、今でもfreeeが大好きです。

そんな状態でもfreeeを去るのは、自分が届けたい価値に向き合った結果です。

これまでfreeeで対峙してきたデータや自分のお金に対する考え方(捕らわれ方)、これまでとこれからのお金が表現するすべきもの、価値の表し方を考えていたときに9月から働くメルペイのビジョンに出会いました。

メルペイが実現しようとしていることはまさに自分が解決に携わりたい思う分野での大きな社会的課題の解決です。

これまで扱ってきた技術スタックとはまた異なりますが、freeeで身につけた課題に向き合う姿勢を忘れずに価値を届けます。

約3年半、本当にありがとうございました。

これは例のリストです。

ふりかえり

新しい開発組織や自分がそんなに触れたことが無い技術になるべく早くキャッチアップできるように、freeeで携わったプロジェクトを出せる範囲でふりかえります。

Web

青色申告承認申請書メール送信サービス

入社3ヶ月目くらいのとき初めて自分メインでリリースしたサービス。今はもう別のサービスが包含してるのでありません。

リリース期限がどうしてもずらせないときは他の変数で調整してなんとかやり切るしかないというのを学びました。

電子証明書連携アプリ(Windows)

対応口座拡大と品質向上

入社7ヶ月くらいのときに電子証明書ログイン対応1行のときにWindowsデスクトップアプリを引き継ぎました。

まだRubyも覚束ない中、C# + Visual Studioに初めて触り対応口座数を増やしていきました。

  • 拡張できる設計とリファクタリング(当時テストは…)
  • 防御的プログラミング(確実なこととそうでないことの切り分けと制御)
  • ログ
  • エラー通知
  • サポートチーム、セールスチームと協力しながら問題解決
  • 優先順位、割り切り
  • 目の前の技術を一歩引いてみる(技術的マイノリティプロジェクトで幸せに過ごすための5つの方法

を身につけました。

当初他のプロジェクトやりながら半稼働、という状態が1年弱あったんですが、社内的に知見があるわけでもなかった技術を身に付けるには思い切って全投入するのが真っ当なやり方だったみたいです。

この会社でC#…みたいな迷いも大きかったですが、何人の方にもアドバイスを頂いた通りまずは自分の目の前の技術をしっかり身につければ応用も効くから頑張れという言葉を信じ頑張ってみました。

あと、技術単体で解決できないときには他のチームの協力を得てできることもあるというのは大きな学びでした。

価値は技術だけでは届きません。

このプロジェクトだったり、得た知見を他の分野にも活かすことで大きな成果に繋がりました。

アプリ + Web UX改善

デスクトップアプリの品質がよくなってきたところで、本来使うと作業が効率化できるはずのユーザーさんに存在や利便性に気づいてもらえなければ意味がありません。

  • 問い合わせ内容分析
  • KPI設定
  • ユーザーさんへのインタビュー
  • サポートチームへのDemoやFAQ共有
  • Webの導線やアプリの使い勝手の改善、リニューアル
  • 保守しやすいコード(しにくいコード)

などを通して、Web上で登録する導線から問い合わせしてくださったユーザーさんに価値が届く(トラブルシューティングを含む)までの全フロー(の中で効果がありそうな順)に対して施策を打ちました。

サポートチームとの知見共有は(もともとの仕様共有が甘ければ)目先のやり取りが減りプロダクトの改善に割ける時間が増えます。駄菓子菓子、その後は問い合わせが減ったとしても

  • サポートチームのメンバーがユーザーさんからの問い合わせに精度高く答えてくれて単にエンジニアまで届く声が減ったのか
  • 「改善」の結果ユーザーさんが離脱してしまっていないか

など目に見える現象だけで判断せず、何か数字がよくなる代わりに他にしわ寄せが及んでいないか、本当に改善したいものは改善できているか、改善そのものの数値化が難しくてもなんとか可視化できないか、その数値が妥当かどうかベンチマーク取れないかなどいくつか考える必要がありました。

プロダクトマネジメントの文脈での「解決すべき課題に向き合う」を実感する日々でした。

この本にとてもとても影響を受けました。

Inspired: 顧客の心を捉える製品の創り方

プロダクトにどういう立場で関わるにしても忘れてはいけない視点として肝に命じています。

あと、改善の過程でフロントに保守しづらいコードを結構足した自覚はあるものの、じゃあどういう設計だったら保守しやすいんだみたいな理想形が全く見えませんでした。

そこからよい設計とは?を考える、学ぶ、意識して書く時間が増えました。

パフォーマンス改善

Windowsアプリといえども、サーバーサイドは他サービスと同じくRailsのサーバーです。

C#を書きつつ、サーバーサイドで必要な修正も行なっていました。

利用してくださるユーザーさんが増えるとAPIサーバーに問題が出て段階的に対応していきました。

非同期化の過程で色々と学びがありました。

  • 時間とコストを考えて段階的に理想的なアーキテクチャに近づけていくやり方もある
  • 問題に対する打ち手を複数考える(※結論ありきの比較にしてはいけないが、自分の推しは持つこと)
  • AWS Lambdaをきっかけにインフラを含めたアーキテクチャ(特にサーバーレスアーキテクチャ)に興味を持った
  • PaaSへの抵抗(食わず嫌い?)が激減
  • OSSヘのコントリビューションのきっかけになった

自分が携わるプロジェクトに対して新しい技術をまるっと(?)導入したこともなかったので大きめの粒度で設計・導入することは考えることが多い分学ぶことはめちゃくちゃ多かったです。

電子申告アプリ(Mac)

すでにリリースしているWindowsアプリのMac版を作って明確な期日までにリリースするプロジェクトです。

Macアプリ開発の知見が社内に無い中、色々なことにチャレンジしました。

Windowsアプリ資産を活用するためにXamarin.Macを採用し、技術検証期間も取りつつチームリードとしてプロジェクトマネジメントするなどです。

  • アジャイル風プロジェクトマネジメント
  • コミュニティから力を借りること、貢献すること
  • CI/CD環境作り
  • ビルド、コンパイル入門

リリースにこぎつけただけでなく、結果的に日本マイクロソフトさんの事例掲載、大型イベント登壇、商業出版(共著)、Microsoft MVP受賞、福岡やシアトル出張などこれまでになかったくさんの機会に恵まれました。

アジャイルはこの本にだいぶ影響を受けました。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アカウントアグリゲーションエンジンのリプレース

2018年はC#を完全に離れ、この記事にある「アカウントアグリゲーションエンジンのリプレース開発」に携わっていました。

Goも利用するプロジェクトで、2週間くらいGoも書く期間はあったものの、だいたいRubyを書いて過ごしました。

かつあまり読み書きできなかったRailsのコードやRspecも昔よりは理解できるようになっていたり、改めて追い直してみると理解できたり最後の最後まで発見が多い毎日でした。

  • 昔読めなかったコードが今も読めないとは限らない
  • データ移行に必要な計画とシミュレーション
  • 防御的プログラミング(困るデータができる前に徹底的に落とす、ロールバック)
  • テストと設計のよい関係(?)
  • インフラ構築やWebアプリのデプロイフロー

この本に出会って設計良くなったかはわかりませんが、Rubyの文脈でpublicメソッドとしてクラスが持つべき責務は何か?を考えることでテストがとても書きやすくなり、テストに助けられたことも何度もありました。

オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方

あと、個人的にGoに興味をもち、コマンドラインを作ってみたりAPIを書いてみたりもかなり楽しかったです。

コマンドラインを作ってみることでコマンドラインを使うときもどう使って欲しいかちょっと理解が及ぶようになったり、シェルスクリプトが書きやすくなったりいろいろいいことがありました。

教訓

最後に、自分がエンジニアとして働く上で今のところ注意したいなぁと思うポイントをまとめます。

デバッグ環境できるまでが環境構築

  • とりあえず対象のサービスがローカルで実行できるようになった、で環境構築を終えたことにしない
  • コーディングとテストを含むフィードバックサイクルを効率的に回せる状態にすることに最初に一気に投資する
  • 同じ文脈でIDE、エディタの使い方は暗記する、できる(使いこなせる)ことを増やす時間はとり続ける

担当する(マイクロ)サービスは全部追え

  • エントリーポイントへのアクセスからそれが返るまで
  • コードを増やしてからデプロイが終わって稼働するまで(デプロイスクリプトや設定を含む)
  • 依存するライブラリ
  • サービスの基盤の性質
  • どう動くかわかるが意味がわからんならドメイン知識を聞くか調べる

本当に無駄なことはするな

  • 議論のための議論
  • 議論したことは残して立ち帰れる状態にする、前提を必ず書く
  • 登壇のための登壇
  • 2回くらいキー連打したり面倒に感じたことはショートカット覚えたりするために立ち止まる
  • 適度に無駄っぽいことはする、脇道にそれる

思い上がるな

  • 時間を空けて読んだコードが読みやすいと思ったとき、自分が成長してるかもしれないし、自分の知らないところで他の人がいい感じに直してくれたのかもしれない(git blameしろとかそういう話でない)
  • 読みやすいと思って書いたコードもきっとそのうち…
  • 自分が過ごしやすいなと感じたとき、その環境を作ってくれた人がいる
  • いいものは偶然発生するかもしれないけど大体は誰かが作り、そういうものであり続けるように維持してくれている

四半期めどに振り返ろうと思います。

次の四半期のアクションや意識することが出てくるのが理想ですが、最低限年末にこの1年何やってたか思い出すための記録ができてればOKとします。

サマリ

  • 技術書典5とServerlessconf Tokyo 2018がんばろうな
  • 振り返り観点に「失敗」足そうな
  • 「ひとまとまりのソースコード公開: 1リポジトリ/月」この調子で続けていこうな

習慣

今年の目標

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

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

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

この中で歌系はやめることにしました。

進捗

本(執筆): 2冊/年

1冊は自分の担当部分終えて待ちです。もう1冊は10月の技術書典5で書くことにしました。

当落発表は8/1ですが、AWS LambdaとGo言語、サーバーレスアーキテクチャ関連で書きたいことがあるので、仮に落選してもnoteなどで販売する予定です。

当選してもnoteでも販売すればいいですね。

この辺り詳しい方にレビューお願いするかもしれないのでよろしくお願いします。

登壇: 6回/年

3回終わりました。

今年もServerlessconf Tokyo 2018の季節がやってくるので、そこで技術書典5のテーマ関連でお話できたらなぁと思っています。

LT想定ですが、7月でいい感じに進んだらCFP出すのもありではと思ってきました。

サーバーレスアーキテクチャの認証認可のお話。

OSS: 1PR/月

ドキュメントや設定ファイルでわーわー言いたくないですが、設定ファイル1つ足すのも普段使ってるOSSがどういう仕組みで動いてるのか勉強になってよかったです。

その仕組みに思うところがあると、自分が何か書くときのインプットになったりするので続けていきたいです。

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

  • toshi0607/StampCard
    • Xamarin.FormsとDurable Functionsでつくるサーバーレスな承認フローを経由するスタンプカードアプリです。
    • Global Azure Bootcamp 2018のときに作ったやつ。
  • toshi0607/gig
    • generate (or output) .gitignore using github/gitignore
    • Gopher道場期間に作ったコマンド
  • toshi0607/release-tweeter
    • API to tweet the latest release tag version using AWS Lambda(Golang) & API Gateway
    • Gopher道場期間に作ったAPI
  • toshi0607/bookInfoSpreader
    • get book info by ISBN on Google Sheets
    • 会社の書籍管理用。Google Apps Script初めて書きました
  • toshi0607/kakuyasuuu
    • WIP
    • Goでクローラー書いてます

習慣の中で一番重視したいのはこれなので、この3ヶ月の仕事以外の進捗としては悪くないなぁと思っています。

それぞれそんなに大きくないけれど、挑戦したいことや検証したいこと、反省して改善したことが詰まっていてどれも思い入れがあります。

技術記事: 2記事/月

下の2つの記事はこのブログの記事で、ブログではそんなに技術的な話をするつもりなないけどまぁアウトプットはしてるし、特定の技術にも触れてるしよしとします。

Goで書いたコマンド関連でmediumに英語記事投稿しようと思いつつ、そのコマンド完成してなくて書いてもないです。

技術書典の準備の次くらいの優先度でやっていこうかなぁと思います。

  • gig: もう1つオプション足せたら。単に実装すれば終わりという感じでもなくて、pecoと一緒にいい感じに使える実装考えるのが難しくて放置気味
  • release-tweeter: 機能的には完成してるけどGitHubのタグのとり方微妙なのと、AWS Serverless Application Repositoryにのっけたい

技術書: 30分/日

けっこう続いてますね。

4〜6月に読んだ本の整理

読んだ

テストの書き方から変わったし、よい設計したいと思う気持ちと実務の最高の架け橋でした。

この本にも書いている設計の考え方を元にたくさん(考えながら)コードを書いて、実際それがよいコードかフィードバックを受けてよくしていくしかないので人生はじまたという感じです。

大好物でした。サーバーレスアーキテクチャの認証認可を学びたいというのがモチベーションの1つだったのですが、認証認可だけで1章割いているのと、その前の章で章でIAMユーザーとロールについて丁寧に説明されているのが好感度高かったです。

あと、AWSを中心に説明しつつもAuth0やFirebaseなどのFunctional SaaSなどを取り入れていたのが印象的でした。

全体を通してYouTubeのような動画シェアサイトを作る流れになっていてUIも作るんですが、自分がいざ何か作るときにはその部分を今風に作るのが一番苦労しそうな気がしました。

たくさんユースケースのっててかつ関連サービスの設定方法もしっかり説明されてるのでさっとパターンを学びたいときによいと思います。

読んでる

もともと毎朝読んでたのですが、最近は自分のプロダクトのコードなり、会社のサポートツールなり書いてるのでおやすみ気味。

Gopher道場期間中になんとなく手に取ったのがきっかけでした。

Goの標準パッケージの読みやすさからちょっとずつレイヤー低めのところまで読んでみる習慣ができつつあったのですが、この本を読むと個々の処理同士の繋がりが見えやすくなってきた感があります。

例えば、TCPやソケットを意識して書かれたサーバーとクライアントではこれまで個人的にあまりメソッド名としてしっくりきていなかったListenだったり、Acceptだったりの意味合いが把握できるようになってきました。

情報処理の試験でなんとなく聞いたことがあった言葉と実装が繋がり始めた感覚です。

尊い本なので引き続き読んでいきます。

その他本: 30分/日

読んだ

この本を読んだ2〜3日後に爆誕したのがtoshi0607/gigですw

基本的にうだうだ言ってないでとっととやれ、しか書いてないので、うだうだ言ってないでとっととやる気持ちになれます。

前職で営業してモヤモヤしてるときにもゼロ―――なにもない自分に小さなイチを足していくを読んで影響を受けた記憶があります。

何を書いてあったかは何も覚えてないですがたぶんどっかに書き残してるはず…

20代でもっとも影響を受けた本の1つになりました。

他者からの注目と言う貨幣換算が難しい価値を好きなタイミングで人脈、金、情報という別の価値に転換できる。ネットの普及で自分の価値をどんな方法で保存しておくか選べるようになってきた

昨今、これまでのお金による価値把握(交換・保存・尺度)も変わりつつあります。

その流れの中でお金の流れはどうあるべきかだったり、それをどう活用するかだったり、自分はどう関わっていくべきかだったり考えるのはとても楽しかったです。

この話は近々改めて記事を書く予定です。

なんでだと思います?漫画要素はタイトルの字面ほど強くないですが面白そうと思って読んでみたら面白かったです。

ただ、人間認知によって商品そのものの価値と関係ないところに左右されるのは事実なんだとしても、本質的に価値あるものを作って届けたいなぁと強く思いました。

ザ・ゴール コミック版を読んで以来、有名な(できれば再現性のある理論に基づいた)本から自分の行動を変える程度の影響を受けるのに別に文字の羅列はいらないし、たかだか1つ実行に移せればラッキーと思うようになりマンガでわかる系の本も読むようになりました。

が、この本を読んでピンときたことは特になかったです。

飯要素強いときの方が好きでしたね。けどきっと新巻出たらまた買うんだと思います。

読んでる

どういうきっかけかまったく覚えてないのですが、功利主義に影響を受けた時期があり久々にJ.S.ミル氏読もうと思って読んでます。

高校のとき隔週の学年新聞にずっと(受験勉強中も…!)連載していてその中で自由私論()とかいう記事を書いたことがあったりしたので、今書いたら何書くんだろうとか考えるのも楽しいです。

世界史の勉強するとき、テーマ史の話の流れ追うのすごい楽しかったものの覚えられなくて論述爆死した記憶しかないですが、今特に興味ある分野を読んでみるとどうなるんだろうと思って読んでみたらしんどい。

一定の時期・地域の流れを追ったあとに同一時期・別地域の流れを追うというのが全然できない。

覚える必要あるのかと言われたらそんなことはないですが、覚えてるからこそ脳みその中で浮き彫りにできることもある気がしているし、覚えるほど反復するからこそ何か気づいたのかもしれないし、その辺の向き合いかたは未だにようわからんです。

仕事ではそんなことも言ってられないので、一度に扱うこと絞るなり分担するなり生き方を模索しています。

カラオケ: 2回/月

声が出なくなったのでやめました。

歌練習: 1回/週

声が出なくなったのでやめました。

品川健康センター: 2回/月

週1で通う習慣ができました。プロテインもはじめました。

走る: 1回/週

品川健康センターで走るのでこれも続けられてますね。

テーマ

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

とは書いたものの、明らかにサーバーレスアーキテクチャとGo言語に振ってる感がありますね。

ただ、それらの技術自体というよりもそれらを通じてよい設計を考えるだったり、もうちょっとレイヤーを掘り下げて実装したいだったりが主要な感心です。

最近はSQSがLambdaのイベントソースに指定できるようになったのにテンションが上がりました。

AWS Lambda Adds Amazon Simple Queue Service to Supported Event Sources

発表当日に早速aws/aws-lambda-goなりaws/aws-lambda-dotnetにPR出すかと思ったところアナウンス前後にはもう対応されていました。

イベントソースから送られてくるjsonをパースするための構造体なりクラスなりは比較的にPRが送りやすい一方で、公式ページに掲載されているjsonサンプルでは必ずと言っていいほどサンプルでは網羅できずパースこける的なissueが上がっている部分でもありました。

PRの機会が減るのは残念ですが、今回みたいな誰もが待ってました!みたいなものに関しては中の人が足してくれるのがよいなぁと思った次第です。

「よい設計をしたい」と思ったときに、クラス設計に止まることはないと思いますし、サーバーレスアーキテクチャとしてサービスを切り出すタイミングで担うべき責務を考えざるを得ません。

サーバーレスアーキテクチャを考える中でLambdaのようなFaaSだけではなく、その文脈の外でよく使うPaaSに触れることで日常業務にもよい影響があります。

今は一エンジニアとしての関心と、趣味(純粋にサーバーレスアーキテクチャなりGo言語なりは触れていて楽しい)と、業務的関心の交点にいる感んじがしてとても楽しいです。

まとめ

振り返り記事を書いてよかったかどうかと言うと、よかったかなぁと思います。

技術書典申し込もうと思いつつ申し込んでなくて、技術書典に触れる部分を書きながらサークル申し込みしました。

本とかも読み終わって全部の本で反芻してるわけではない(お金2.0はけっこうハイライトした部分読み直した)ので、その本の位置づけなり、次どうしたいと思ったのかなり考える時間をちょっととるだけでも、読書に費やした自分の時間の自分にとっての価値は上がるように感じました。

習慣の枠には書いてないですが、同僚とランチしたときに「最近ちゃんと失敗してる?」的な話題が上がって大事な振り返り観点な気がしました。

誰も失敗したくて失敗するわけではないし、当然失敗すること自体に目標を置くことはないです。(得られるものが増えるわけでもないのに)敢えて失敗する手法を選択することもないです。

万全の体制で臨んでも失敗するような、それまでの自分の枠を超えた不確実なイベントに向き合っているか?そこから次の一歩のために何をしたのか?という観点は選択や振り返りを行う上で大事っぽいということです。

記憶に残ってる範囲ではあるけど書けないので次に活かします。

この3ヶ月はお金2.0とGopher道場に受けた影響がとても大きかったように思います。

Gopher道場期間の振り返りはこちら

Gopher道場♯1でメルペイさんにお世話になりました #gopherdojo

そんなこんなで6月にとうとう30才になり、いろいろと環境が変化していきそうです。

そっと例のリストを置いてみます。

https://www.amazon.co.jp/hz/wishlist/ls/355R1ZKLIIDFM