明けましておめでとうございます。
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曲くらい上げれたらと思ってます。
運動系
去年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回/週
家庭
今年も捨てるぞ！
そして犬か猫を迎え入れます。
食洗機、ダイニングテーブルも迎え入れたいです。
まとめると大体技術的に頑張りたいことが多くて、技術はまだまだ追うことあるので項目として大きく増やしたり減らしたりすることもないなぁという感じです。
家をすっきりさせて、適当に旅行とか温泉とか行って、サウナ毎週行って、たまにピアノ弾いて、基本コード書いたりいい感じに頭使えたらええんではと思います。
