🐸2019年をふりかえる🐸
本記事は コネヒト Advent Calendar 2019の25日目 のエントリーになります。
年の瀬ですし、今年は公私と共に色々あったので1年の振り返り的なことを書くよ。
仕事
仕事での一番の大きな変化はやはりCTOになったこと！
CTOは組織の中の一ロールに過ぎないと考えていますが、それでもやはり責任や管掌領域が一気に増えたせいか、それともただの加齢のせいなのかは分かりませんが白髪が増えました。とは言え、基本的にやったことがないことに対して、面白さを感じるタイプなので迷ったり悩んだりすることはありつつも愉しくやっています。
その中でも、有り難いことに広報の @chida_miki が露出をたくさん増やしてくれたので、今年は例年以上に発信する機会が多かったです。
こちらは前CTO たつしむ と喧々諤々の議論をした（嘘です）インタビュー記事です。CTOになる前は色々偉そうに意見してたんですが、いざ自分がなってみるとたつしむの偉大さが分かりました。
こちらはクックパッドのCTOの @mirakui さんとBASEのCTOの @dmnlk さんと一緒にパネルディスカッションさせていただいたイベントの記事です。二人とも僕とは違うタイプのCTOでとても刺激的なイベントだったので、今でも二人の発言を時々思い返したり、反芻したりしています。もちろん、エンジニアとしてもめちゃくちゃ尊敬出来る二人なので負けないように頑張るぞ〜という気持ちもあります。
他にもAWSさん主催のCTO Night & Day 2019で登壇させてもらう機会もいただきました。喋りはまだまだですが発信していくことの重要さを感じたので、引き続き頑張っていこうと思います。
もちろん、CTOとしての最大の責務はテクノロジーの力で、事業を成長させ、ひいては社会を良くすることだと思っています。そして、そこに対してはまだまだバリューを発揮出来ていないので、来年はもっと攻めていくことで、そこにコミット出来るようにしていきたいなと考えています。
アウトプット
前半のトピックは人生初の技術書を出版させてもらったことです。
お陰様でけっこう？売れているようで、誰かのエンジニア人生を支えるものになっていれば作者冥利に尽きます。
後半のトピックは国際カンファレンスであるCakeFestで登壇したことです。
また、せっかくの機会なのでCakePHPについてのインタビューを受けました。
個人的にはここ数年で一番チャレンジングなイベントでめっちゃ大変でしたが、少しは自信がついたので来年は海外で開催されているカンファレンス絶対参加するぞ！という気持ちを新たにしました。
あとはGoについての記事を書いたり、ス・マイル制度についての発信をしたりしていました。
Goについては、これまで個人的に使ってるレベルでしたが、コネヒト社のプロダクション環境に導入するレベルになったので、またどこかでちゃんと書きたいと思います。
ス・マイル制度については今のところ評判も良く、順調にマイルも貯まったり、使われたりしています。しかし、この手の制度は放っておくと経年劣化していくものなので、来年が勝負かなと感じています。
インプット
ブクログさんによるとは今年は21冊読んだらしい。役割が増えて、技術書はあんまり読めなかったのですが、その分いろんなジャンルの本を読めたのはよかったかな。
面白かった本5選を挙げると…
という感じです。『エンジニアのためのマネジメントキャリアパス』は正月に読んでて、この時はまさかCTOになっているとは思っていなかったのですが、結果的に読んでおいた良かったです。いま読んでいる『両利きの経営』も面白いので、来年はもっと読書する時間を増やしたいな〜。
あとは、英会話に通ったり、技術的なところで言うと最近はPython（というかデータ分析周り）を勉強したりしています。
プライベート
家を買いました。
まとめと来年の目標
去年の振り返りで書いた今年の目標と結果はこんな感じでした。
- 大きなカンファレンスで登壇
- ◎: CakeFestで登壇したぞ！
- 英語の技術書をスラスラ読めるようになる
- △: モタモタは読めるけどスラスラは読めない！
- インディー開発2本以上リリース
- ☓: 既存のバージョンアップしか出来なかった…
- 本を最低でも12冊以上読む
- ◯: 達成！
- 引っ越しを無事終える
- ◎: 完璧に終えた。新居最高〜！
達成度で言うと、60点くらいという感じですね。今年は社会人11年目ということでこれまでの10年間の経験や知見を棚卸ししたり、大放出したりした1年でした。新しい役割の中、ややインプット不足を感じることも多く、やや無理くりこすったというか擦り減らした感もあるので、来年はもう少しインプットに割く時間を増やしたいなと思っています。あと、今年は久しぶりにインディー開発で新しいサービスをリリース出来なかったので、来年こそという気持ちで…
- インディー開発で2本以上リリースする
- 一緒にやりたい人Wanted！
- 本を最低でも24冊以上読む
- 技術書は10冊以上読む！
- 海外に3回以上行く
- 1回はカンファレンスに参加！あわよくば登壇！
- 楽器か運動をはじめる
という感じで来年は頑張りたいと思います。
それではよいお年を〜来年もよろしくお願いします！
PR枠
冪等性マネジメントを高めるための思考と試行
本記事はコネヒト Advent Calendar 2019の23日目のエントリーになります。
今日はマネジメントの話がしたくなったのでマネジメントの話をします。マネジメントは「ナマモノ」なので、その人のパーソナリティはもちろん、関係性や状況によって、有効な手段が変わるので銀の弾丸はないのですが、ナマモノだからこそ、現場のノウハウを公開していく必要があると考えています。
また、マネジメントのテクニックを公開すること=手の内をメンバーに見せることになるので、公開することを敬遠するマネージャーもいますが、僕は正直でいることが最大の戦略だと思っているので、自分の考えの整理も兼ねて書いてみたいと思います。
というわけで誰かの一助になれば幸いです。
冪等性マネジメントとは？
僕がマネージャーとして意識していることの一つに「冪等性マネジメント」（Idempotent Management）というのがあります。冪等性マネジメントとは、 どんな時でも誰とでもいつも同じようなコミュニケーションのインターフェイスでメンバーと接することです。冪等性と表現するとロボットっぽいコミュニケーションを想像するかもしれませんが、ここで言う冪等性はテンションや態度のことを指します。
なぜ冪等性が大事なのか？
例えば、ある時は優しかったのに、またある時は冷たいといったような日によって態度にムラがあるマネージャーがいたとしましょう。そういうマネージャーの場合、メンバーからするとマネージャーの様子を伺って「今日は機嫌悪そうだから話しかけるの止めておこうかな〜」という力学が働いてしまいます。そして、このような状況が常態化すると、マネージャーとメンバーの関係性が希薄になります。
個人的にマネージャーとしてメンバーとのコミュニケーションの総量を増やすことは、メンバーの成果を最大化させる上で非常に重要だと考えています。もちろん、アカデミックな理論に裏打ちされたハウツーやコーチングのスキルもマネージャーには必要不可欠だと思いますが、それらの習得には一定時間がかかります。しかし、コミュニケーションをとることは誰でも今日からはじめられます。また、それらのスキルが有効になるのも一定以上の関係性を築いたうえでの話ですので、そのためにも日々のコミュニケーションは欠かせません。
にも関わらず、ムラのある態度を取ると、その日々のコミュニケーションの総量が減るリスクがあります。毎回返ってくる値が違うようなメソッドを誰も使いたくないのと同様に毎回態度が違うマネージャーとは誰も仕事をしたくはありませんよね。少なくとも僕は嫌です。
冪等性を保つ難しさとその方法
とは言うものの人間はシステムではないので、冪等性を保つのはなかなか大変です。僕はよく人から「いつも穏やかねですね〜」と言われるくらいには、良くも悪くも気分の浮き沈みが少なく、あんまりイライラしないタイプではあります。ですので、パーソナリティ的に冪等性を保ちやすいタイプだとは思うのですが、それでもこれまで人とのコミュニケーションで失敗してきたことは当然ありますし、聖人ではないので今でも日々の暮らしの中でテンションの移り変わりがあります。
もちろん、そういう人間味を開示していくこともマネージャーには必要な要素だとは思っていますが、冪等性マネジメントという観点ではなるべく自分の感情と上手く付き合っていく必要があります。というわけで、冪等性を保ったり高めたりするために僕が普段意識していることを紹介してみたいと思います。
長々と講釈を垂れましたが、要は穏やかに過ごすための心構えみたいなものとして読んでいただければと幸いです。
一時の感情で判断しない
アンガーマネジメントに近いかもしれませんが、人間である以上どうしてもイライラしたりプライベートの事情などで落ち込んだりすることは避けられません。そういった状況で、例えば批判のようなものを受けるとカッとなります。こういう状況ではまず正常な言動が出来ないと思っているので、一時的な感情で判断しないことが大切です。経験則ですが、次の日になればほとんどの出来事は取るに足りないことです。逆に次の日もその感情が残っていれば、何らかのアクションを取ればよいと思います。恐らく多少は冷静になっているので、昨日よりも筋のよいアクションをとれるはずです。もちろん、エンジニアの三大美徳である「短気」の逆の考え方なので、マッチしないケースもあるかもしれませんが、少なくともマネジメントでは一時の感情で判断しないことが大切かなと考えています。
0か1ではなくグラデーションで考える
これは主に対人関係の話ですが、仮にちょっと合わないなというか自分をイライラさせる人がいた場合に、一時の感情で判断しなかったけどやっぱり「イライラする！」となった時でもそのイライラさせる要因はその人の一面に過ぎないことを意識することが大切だと思います。たまにゼロサムで一つの出来事だけで「この人は嫌い！」というレッテルを貼る人もいますが、個人的にはもったいなと思っています。基本的に僕は他人のことなんて分からないという前提でコミュニケーションをとっていて、この人のこの部分は好き、あの部分はちょっと考えが違う、でも見えていない部分がたくさんあると思っているので、その人を嫌いと判断するのは難しいなぁと思ってしまうし、そういう考えのほうが個人的にはその人と仲良くなる可能性が残っているし、わくわく感があって楽しいなと考えています。
性善説で相手を信じる
先程、人を嫌いと判断するのは難しいと書きましたがこれは性善説ありきの考え方なので、性善説で相手を信じることが冪等性マネジメントでは重要なことなのかなと思っています。性善説で物事を考えると仮にイライラさせるような人がいても、別に悪気があるわけではないという考えになるので「ヒト」ではなく本質的な「コト」に向かいやすくなると考えています。また、相手のことを信じると向こうも信じてくれる可能性が高まると感じていて、そうするとコミュニケーションコストが下がるので、冪等性マネジメントもやりやすくなる気がしています。
ちなみに全く別の話ですが、世の中には本当にEvilな人もいる（幸い僕の周りにはいませんが）ので、そういう人からは逃げるようにしましょう。
問題を自分側に置く
ここまでイライラを相手に問題があるかのように書いてきましたが、そもそもイライラしているのは自分なので問題を自分にある前提で考えるのも有効な手段と思います。いわゆる、自分ごと化というやつですが、個人的には自分ごと化したほうが楽なことが多いと思っていて、それは自分に問題があるのであれば、それはコントロール可能な問題なので、何らかの対処が出来るからです。ややもすれば傲慢な考えかもしれませんが、世の中の全ての出来事に全ての人が関与していると僕は考えていて、そんな感じで何でも自分ごと化して、問題がコントローラブルになると、ある程度感情もコントローラブルになると思います。（もちろん、解決出来るどうかは別ですが…！）
たくさん寝る
凄く当たり前のことですが、めちゃくちゃ大事なことなので書いておきます。今まで書いた方法は十分な睡眠時間を確保した上で実践出来るものだと思いますし、睡眠不足の時は本当に気分にムラが出やすいので、きちんと睡眠時間を確保をすることはどんなに強調してもしすぎることはないと思います。と言いつつ、僕はよく夜ふかしをしてしまうので自戒を込めて…。
最後に
それっぽく書きましたが、冪等性マネジメントという言葉自体は（たぶん）造語で2秒で考えました。あと、文章にすると自分が高尚な人間っぽい感じがしてしまうかもしれませんが、全然そんなことはなく日々試行錯誤の連続なので、コネヒト社では是非そんな僕を支えてくれるメンバーを募集中でございます！
英語で登壇するためにやったこと in CakeFest
先週 CakePHP の国際カンファレンスである CakeFest 2019 に登壇させていただきました。人生初の英語でのプレゼンテーションということもあり、ここ数ヶ月プレッシャーが凄かったのですが何とか無事終えることが出来ました！（たぶん）
終わってみればとても良い経験が出来たと思いますし（生存バイアス）、「英語で登壇をしてみたいな」と考えているエンジニアの方も多いのかな？と思うので、振り返りも兼ねて英語で登壇をするためにやったことをまとめてみたいと思います。
ちなみに、本旨ではないので登壇内容やプレゼン自体のテクニックについては触れませんが、スライドはこちらです。
前提情報編
最初に前提となる情報を簡単に紹介します。変わったバックグラウンドがあったり、特殊なシチュエーションがあったりするわけではないので、ある程度一般化出来るかなと思っています。
自身の英語レベル
まず、僕がもともと英語ペラペラだったら 「そりゃプレゼンぐらい出来るやろ！」ってなると思うので、念のため、僕の英語レベルをお伝えしておきます。
- 日本生まれ日本育ち
- 中学の夏休みにオーストラリアにホームステイしたことがあるぐらい
- 英語は高校までは得意科目だったが、大学以降全くやっていない（10年以上）
- 大学生の時は何故かドイツ語とイタリア語しかやった記憶がない
- 海外旅行に行くと、単語を羅列して何とかコミュニケーションをとるタイプ
- よく使うフレーズは「Two coke, please.」*1
- 普段、英語のドキュメントはGoogle翻訳を駆使して読んでいる
- Google翻訳に甘えて、英語の勉強が捗らないことがあります
というわけで、典型的な英語話せないタイプの日本人です。
準備期間
ちなみに、cfpを出したのは今年の元旦で登壇が決まったのが5月でした。ぶっちゃけcfpが通ると思っておらず、勝手に落ちたと思っていたので、準備期間は半年ぐらいでした。この時点でだいぶヤバい。
CakeFestについて
改めてになりますが、CakeFestはPHPのフレームワークであるCakePHPの国際イベントです。 これまでは海外で開催されていたのですが、初めての日本（東京）開催となりました。規模としては全体で100人ぐらいで、今回は半分ぐらいの方が海外からの参加者だったと思います。*2
英語力向上編
では、ここから具体的にやったことを紹介していきます。まず、皆さんが大好きな？英語の勉強方法について。
英会話スクールに通う
とりあえず「このままじゃアカン！」と思ったので6月から某英会話スクールBに通い始めました。最初はDMM英会話のようなオンラインの英会話にしようと思ったのですが、自分の性格的に怠けて受けなくなりそうだなと思ったので、ある程度の強制力のある英会話スクールを選びました。ちなみに、いくつかスクールの体験レッスンを受けたのですが、その中で一番厳しいレベル判定をされた英会話スクールに通うことにしました。*3
しかし、正直英会話スクールは直接的な効果はあんまりなかったです。ただ、これは英会話スクールが悪いわけではなく単純に自分の英語力が低いのが原因で、英会話スクールで習っている内容がまだ日常会話中心で、登壇で必要な英語力は鍛えられなかったからです。*4
とは言え、英語を話すことに慣れることが出来た点は良かったと思っているので、間接的には効果があったのかなと思います。また、直前に買い切りのレッスンでプレゼンの練習をすることが出来て、そこで先生に褒めてもらえたので自信がつきました。
日常的に英語の接点を増やす
また、ありきたりですが英会話スクールに加え、通勤中に英語のPodcastを聴いたり、スキマ時間で英語のアプリをやったり、休日に参考書を読んだりしていました。こんな風に書くと「めっちゃ勉強やってんじゃん！」という感じなのですが、モチベーションにムラがあったので、1ヶ月を切るまでは気が向いた時にやるレベルでした。登壇が近づくにつれ「何でもっと勉強しなかったんや…」と過去の自分を呪いましたが、その中でよく使っていたアプリやサービスは以下です。
他には映画を吹き替え版で観たり、YouTubeで過去のCakeFestの動画を観たりしていました。YouTubeには字幕表示機能があって、それが結構スピーチの作成に役立ちました。
あとは英語用のTwitterアカウントを作成しましたが、これはあんまり上手く活用出来なかったな…。
資料作成編
次に本丸のプレゼンテーションの資料をどうやって作成したかについて。
プレゼン資料を作成する
まず、プレゼン資料については最初から英語で作成しました。ちなみに資料は1ヶ月を切ってから作り始めましたが、心臓に良くないので2ヶ月前くらいから作ったほうが絶対いいです。一通り作った後は、社内の英語が堪能な方にお願いして*5、添削をしてもらいました。Googleスライドで作成していたので、スライドに直接コメントを貰えて便利でした。
ちなみに、本筋とは書けないですがスライド中のコードは Codeimg.io を利用しました。
スピーチ原稿を作成する
日本語の場合、軽く箇条書き程度に原稿を用意すればOKなのですが、今回はガチガチに話す内容を用意しないと詰むと思ったので、まず、日本語でスピーチの原稿を作成して、その後、翻訳経験のある方や識者の方に全面的にサポートしてもらいながら英語の原稿を作成するというステップを踏みました。
プレゼンテーション編
一通り資料が出来たのが本番5日前だった（白目）のですが、そこから猛烈な勢いでプレゼンの練習をしました。
とにかく話す
これは日本語のプレゼンでもやることだと思うのですが、英語の場合は丸暗記するぐらいので勢いで何回もやったほうがいいなと思いました。特に僕みたいな普段英語を喋っていない人は口が英語に慣れていないので、実際にきちんと声を出して、身体に英語を染み込ませていく必要があります。最終的に5回以上は本番と同じ感じで練習をしたのですが、振り返るともっとやったほうがよかったなと思っています。また、練習する時は録音をしておいて、後で聞き返すようにしていました。*6
どれくらいのペースで話せるのかを確認する
また、自分が1分間にどれくらい単語を話せるのかを確認しておくと当日慌てないかなと思います。日本人が英語でプレゼンをする場合は、1分間で120〜150単語くらいが適切なスピードらしいのですが、僕は最終的に130〜140単語くらいが限界だったので、それに合わせて、原稿の内容を調整しました。
発音を確認する
あとは各単語の発音を確認するために、スピーチを読み上げてくれるサイトやアプリを使って何度も（と言ってもラスト3日くらいですが…）自分の原稿を耳に叩き込みました。実際に使ったサイトやアプリは以下になります。
ちなみにこれらのサービスでもこのスピードだと1分間に何語ぐらい話しているのかを確認して、自分の話すスピードの参考にしました。
当日編
では、最後に当日やったことを紹介します。
翻訳者さんとコミュニケーションをとる
実は直前に英語の発表でも通訳（同時通訳ではなく逐次通訳）が入ることが決まったため、事前に提出していた資料から内容をかなり削りました。ですので、当日最新の原稿を通訳さんにお渡ししたのですが、結果的にこれはやっておいてよかったなと思っています。事前に通訳さんがそれに目を通してくれて、僕が話す内容と通訳さんが見ている原稿にdiffがないため、逐次通訳のコミュニケーションも比較的上手くいったかなと思います。*7
発表する
発表する時は、座ってやるスタイルと立ってやるスタイルが選べたのですが、せっかくだから立ってやったほうがそれっぽい？と思ったので、立ってやりました。ただ、立ってやるとスライドのカンペが見れないので、予め原稿をPDF化してiPhoneのKindleアプリに突っ込んで、プレゼン中はそれを見るようにしていました。反省点としては割と丸暗記したつもりだったのですが、緊張であんまり前を見ながら話せなかったことなので、このあたりは次回に生かしていきたいです。
メンタルコントロール
よくよく考えたら30分以上喋るカンファレンス初登壇が英語ってHARD MODEすぎじゃない？(今更)
— いとしょ (@itosho) November 1, 2019
こんなつぶやきをするなど1ヶ月前くらいからプレッシャーが凄かったのですが、途中から「世界で英語で喋れる人は15億人もいるし、自分も喋れるやろ」という謎理論でメンタルを保っていました。あとは、同じく登壇者だったBASEの東口さんとランサーズの金澤さんとSlackでお互いの進捗を共有させてもらったのはメンタル的にとても助かりました。大感謝！
最後に
ってな感じで、一時期は海外逃亡したい気持ちもあったのですが何とか無事終えることが出来ました！*8特に発表の中で紹介した自作のOSSである「Easy Query」をCakePHPのコアコミッターの方に褒めていただいたのは非常に嬉しかったです。
ただ、今回無事終えることが出来たのはCakeFestがアットホームな雰囲気の暖かいカンファレンスであったことが一番の要因かなと思います。凄く話しやすい空間を作っていただき、本当に運営の方には感謝の気持ちでいっぱいです。また、初の国際カンファレンスの登壇の場が東京だったのは非常に運が良かったなと感じています。個人的にはやはりQ&Aは英語で回答出来なかったり、上手く話せないこともあったりして反省点もあるのですが、やはり一人のエンジニアとして世界で勝負していきたいという想いが更に強くなったので、引き続き英語の学習を続けて、来年は海外カンファレンスでの登壇にチャレンジしたいと思います！
*1:完全に間違った英語なので、皆さん真似しないでください。
*2:公式情報ではないので、間違っていたらごめんなさい。
*3:週イチ80分の少人数のレッスンを受講しています。
*4:誤解なきようにお伝えしておくと、レッスンの内容自体は非常に素晴らしく、純粋な英語力は上がっていると感じているので今も通っています。
*5:協力してくれた方には頭が下がる思いでいっぱいです。
*6:自分の声が嫌いなので苦行でしたが、発音の確認のために絶対やったほうがいいです。
*7:もちろん、これは通訳さんの技量によるところが大きいです。
*8:おそらく今後登壇の映像が配信されると思うので、全然無事じゃない可能性がありますが…。
『新時代の野球データ論 フライボール革命のメカニズム』を読みました
仲良くさせていただいている id:shinyorke さんから『新時代の野球データ論 フライボール革命のメカニズム』という本を献本いただきました。*1
やきう好きとして、最高に面白かったのでネタバレしない程度に感想を書きたいと思います。
どういう本なの？
昨今話題の「フライボール革命」をはじめとする野球理論を膨大なデータやスポーツ科学の観点から検証・考察する本です。EPILOGE（あとがき）にも書かれている通り「分かりやすさより」も「正しさ」を重視して書かれているそうなので、少し難しい箇所もありましたが、野球の知識があるソフトウェアエンジニアなら「ふむふむなるほど」といった感じでサクッと楽しく読めると思います。 また、オリックスの吉田正尚選手のインタビューやシアトル・マリナーズの菊池雄星選手の対談記事もあり、 現役のプロ野球選手がデータとどう向き合っているのかを知ることも出来ました。
特に面白かったところ
個人的には「上から叩いて打つ」とか「ヘッドを立てる」とか「低めに投げる」とか「球持ちを長くする」といった、これまで正しいとされてきた定説や感覚に基づいた指導法が本当にそうなのか？をしっかりとデータを利用して、検証している点が非常に面白かった。 もちろん、その中で感覚が正しかったものもあれば、実は正しくなかったものもあるんだけど、大切なのは正しい/正しくないの二元論ではなく、そうやってデータや科学を上手に活用することで、再現性を高めて進化していくことなんだなと思いました。アスリートに限らず、僕はデキる人≒再現力が高い人だと思っているので、野球の世界でも、試行錯誤を繰り返しながら、変化をし続けられる選手が超一流になれるのかな〜なんて想像しました。
そんなことを考えているうちにわいも超一流になりて〜と思ってやる気が出たし、この本のお陰でもうすぐ始まる夏の甲子園もより深く楽しめそうです！ というわけで、素敵な本をありがとうございました！
*1:献本をいただく、という表現は正しくない表現っぽいけど、すっとぼけておきます。
コネヒト株式会社の二代目CTOに就任していました
いわゆる退職エントリーというやつです。
この度4月末にSupership株式会社を退職し、6月にコネヒト株式会社の執行役員CTOに就任しました！*1
ちなみに、コネヒト社におけるCTO交代の経緯や意気込みについては以下の記事にまとまってるので、ここではどちらかというとパーソナルな話を書こうと思います。ですので、僕に興味がない人はここで離脱してもらって もっとためになるブログ でも読んでください！
Supershipでの思い出
今回のCTO就任によるプレスリリースや対談記事で、唯一の心残りがお世話になったSupership（nanapi）についてあまり言及出来なかったことなので、最初にSupershipでの話をします。
ちなみにSupershipへの転職エントリーもあるので、ご興味がある方はどうぞ。
個人的にSupershipで働けたことは、自分のキャリアの中で大きなターニングポイントだったかなと思います。Supershipに入社する前は受託のお仕事が多かったので「リリース≒ゴール」のような感覚が強かったのですが、Supershipに入ってからは180°変わって「リリース≒スタート」という考えをすることが多くなりました。それは日夜オンライン/オフライン問わず、みんながプロダクトについて議論をわいわい交わしていた影響が大きく、「人の生活に彩りを与えられるプロダクトをつくりたい」と思っていた僕にとってそういった環境は正に求めていたものであり、非常に刺激的な毎日でした。
しかし、その中で辛いこともありました。僕は入社後「アンサー」というコミュニティサービスに長く携わっていて、非常にやりがいを持って開発をしていたのですが、最終的にサービスクローズという結果になってしまいました。クローズした理由は様々あったとは言え、サービスを継続させることが出来なかったという事実に対して自分の力不足を痛感したのを昨日のことように思い出します。
その後、コネヒトでは「ママリ」という別の種類ではあるものの同じコミュニティサービスを開発しているのは何か縁かなと思うし、ママリへのモチベーションはいくつかあるのですが、あの時の悔しさと哀しさを二度と味わいたくないというのも原動力の一つになっています。
そういった辛いこともありましたが、その中でもSupershipは優しい人や面白い人が多く、いい意味でプライベートと仕事の線引なく仲良くしてくれて、トータルで考えると本当にたのしく働けたなと思ってます。というわけで、Supershipでお世話になった皆さんには本当に感謝しかありません。ありがとうございました＆これからもよろしくお願いします！
次の10年をどう生きるか？
次に今回何故CTOを引き継いだのかという話をします。
最初に紹介した対談記事でも少し触れているのですが、今回CTOの打診を受けた時、ちょうど社会人丸10年で（ソフトウェア）エンジニア歴も10年になったので、次の10年をどう生きるのがよいのだろう？ということを結構真面目に考えていました。嬉しいことにいくつかお声がけもいただいたり、選択肢として起業というのも割とリアルにあったりしました。*2
しかし、そういった選択肢を考える一方で、今の場所でもう少しエンジニアとしてやるべきことがあるのでは？という気持ちやもっとエンジニアとして頑張りたい！という思いが意外にも沸々と湧いて来ました。「意外にも」と書いたのは、自分からこういう感情が生まれてくることが単純に驚きだったからです。と言うのも、僕は元来エンジニアになりたいという気持ちが学生の頃はそこまで大きくはなく、転職活動が上手くいかない中で「ものつくるのは好きだからエンジニアも面白いかもな〜このままだとどこも決まらないから受けてみよう！」ぐらいの気持ちでこの世界に飛び込んだので、エンジニアとしての拘りはあんまりないと思ってました。
もちろん、自分が 10Xプログラマー だとは思わないです（念の為言っておくと、エンジニアである以上そこを目指してます）が、10年エンジニアをやって、いつの間にかエンジニアとしての矜持が自分の中に芽生えていたのは一つの発見であり、今はエンジニアになって心から良かったと思ってます。エンジニア最高〜。
そんなこともあり、次の10年の最初の一歩をエンジニアとして新しいチャレンジをするというのは自分にとって、チャレンジングではあるものの自然な選択なのかと思うし、あとはやはり、コネヒト社の「人の生活になくてはならないものをつくる」というミッションに自分の人生を捧げる価値があると思ったのが大きいかなと考えてます。
CTOはゴールではない
最後にこれからの話を少し。
CTOになってちょうど一ヶ月経ったのですが一ヶ月の感想は、思った以上に目先のことばかりやってるとあっという間に忙殺されるな！という感じです。*3
こういうよくあるマトリックスで言うと、CTOは「重要だが緊急ではない」課題に対して、きちんと時間を確保しないといけないんだろうなぁということを改めて感じたので、これからそういう時間を増やしていく所存です。
ですので、そういう課題を考える時間を増やすためにも、自分が組織の中でボトルネックにならないようするためにも業務でコードを書く時間は徐々に減らしていければいいなと考えています。ちなみに、今年のGitHubの草の様子はこんな感じ。
草の状況から分かるかもしれませんが、4月くらいからそれっぽい仕事が増えてました。
もちろん、いわゆるマネジメント業務が増えるとコードが書けなくなる問題はあり、腕がなまらないようにする必要性は一エンジニアとして感じてます。*4ですが、やはりCTOとしての役割の一つは経営にエンジニアリングの力を反映させて、事業を成長させていくことだと思います。ですので、CTOになる少し前あたりから会計やファイナンス、会社法あたりをざっとですが勉強したり、先月から英会話もはじめたりしているのですが、これからはそういうエンジニアリング以外のスキルや知識も伸ばしていかねばと思ってます。
とは言え、CTOになったからと言って、いきなり何でも出来るスーパーマンになれるわけではないので、変に自分を大きくみせることも小さくみせることもせず、粛々と努力していきたいなと考えてます。CTOがエンジニアのキャリアにおける一つのゴールに思われる方もいるかもしれませんが、個人的にはゴールでは全然なくて、コネヒト社の「人の生活になくてはならないものをつくる」というミッションを実現するための新しいスタートだと思ってるので、これからめっちゃ頑張るぞ！
そして、めっちゃ頑張るには仲間がたくさんいると嬉しいので、少しでもコネヒト社に興味がある方は Twitter や Facebook からお気軽にお声がけください！
最後に 例のブツ です。
『はじめてのPHPプロフェッショナル開発』という本が出版されます
このたび生まれて初めて本を出版することになりました！
『TECHNICAL MASTER はじめてのPHPプロフェッショナル開発 PHP7対応』というタイトル（以下、プロフェッショナル本）で2019年2月26日（火）に秀和システムさんから発売されます。
会社の同僚と書いたので、是非買ってください！（石直球）
しかし「せっかく買ったのに思ってたんと全然違うやんけ！」となるのも申し訳ないので、プロフェッショナル本がどういう本なのか簡単に紹介したいと思います。
プロフェッショナル本の概要
一言で言うと プログラミングの入門書を読み終えた人が、実際の開発現場で活躍するために必要なアレコレをPHPを題材に解説している本 です。ボリュームは実質390ページほどになります。中身は導入編、入門編、実践編、発展編の4つのパートで構成されています。
最初の導入編では昨今のPHPとそれを取り巻くエコシステムを紹介しており、具体的にはPSRやComposer、PHP7の新機能などを解説しています。
入門編ではPHP質問広場というオリジナルのQAサイトを実際に作っていきます。実装以外にもDockerを利用した開発環境構築があり、設計やユニットテストの方法についての解説もあります。ちなみに、Webアプリケーションの開発にはCakePHP（3系）を採用しています。
実践編ではチーム開発にフォーカスを当て、GitHubやSlackの使い方を紹介しつつ、チーム開発でも特に重要なコードレビューについて解説をしています。更に複数人での開発に役立つツールとしてPHP_CodeSnifferとPHPStanの紹介や昨今のトレンドであるコンテナベースのCI/CDについても触れています。
最後の発展編ではPHPの枠を越えて、障害への向き合い方やSQLチューニングの解説に始まり、実際の運用では重要なセキュリティの話にも触れています。また、最後にOSSへのコントリビュートについても簡単に紹介しています。
つまり、めっちゃ盛り沢山な内容になっております！もう少し知りたい方は最後に目次をまとめておきましたのでそちらも併せてご覧ください。
プロフェッショナル本の立ち位置
まえがきでも触れているのですが、プロフェッショナル本は初心者向けの入門書ではありません。かと言って、PHPの文法書やCakePHPの専門書でもありません。
もちろん、PHPの本ではあるのですが、扱っているトピックが多いので、ややもすると「帯に短し襷に長し」という印象を持たれるかもしれません。ただ、そういう印象はある意味間違っておらず、プロフェッショナル本は 入門書は巷に（特にPHPは）溢れているものの、それを読み終えた初心者が実際の現場で活躍するための次に読むべき本がないのでは？ という問題意識から企画が始まっています。
ですので、プロフェッショナル本は最新のPHPを学びながら入門書と個別具体的な技術の専門書との架け橋となる本を目指して書きました。
想定している読者
上述の内容を踏まえつつ、主な読者としては以下のような方をイメージしています。
- 昔PHPを触っていたが、最新のPHPは知らない人
- プログラミングはある程度出来るが、Webアプリケーションの開発業務経験が少ない人
- 昨今の開発現場で多く採用されているツールや開発プロセス、考え方を一通り知りたい人
もちろん、上記以外の方にも是非読んでいただきたいなと思っています。ちなみに、個人的にはPHPer以外の方にも読んでいただけると嬉しいです。
あんまり想定していない読者
逆に以下の人は難しく感じたり、逆に物足りなく感じたりするかもしれません。
- プログラミング「超」初心者の人
- 初心者の方でも理解出来るよう工夫はしていますが、フレームワークって何？Gitって何？というレベルだと少し厳しいかもしれません。
- モダンな開発現場で何不自由なくバリバリ働いている人
- コードレビューやテストを日常的に行っており、開発プロセスも自動化されているような現場で働いている人は特に得るものがないかもしれません。
- CakePHPの詳細な解説を求めている人
- CakePHPを利用してWebアプリケーションの開発を行っていますが、それだけを目当てに読むと説明が浅いと感じるかもしれません。
フィードバックについて
少しでも誰かの役に立てばという気持ちで一生懸命書きましたが、今回技術書の執筆は全員が初めての経験だったので、もしかしたら読み辛い箇所や間違いがあるかもしれません。初めてということに関して言い訳するつもりはないのですが、イケていないところは真摯に受け止めてきちんと改善していきたいと思っています。
ですので、僕のTwitterでもAmazonのレビューでも何でもよいので感想などフィードバックいただけると嬉しいです。また、プロフェッショナル本に掲載されるコードはGitHubにも公開しておりますので、当該リポジトリにIssueやPull Requestを作成していただいても構いません。また、正誤表に関してもリポジトリ内のWikiを随時更新していく予定です。
目次
最後に目次を紹介します。前述の通り、幅広いトピックを扱っているので気になる章だけ読むことも可能な構成になっています。
一応、僕が担当した章は★マークをつけておきます。
Part01 導入編
Chapter01 進化するPHP
Chapter02 PHPのエコシステム
Chapter03 PHPをはじめよう
- 03-01 エディタ
- 03-02 DockerでPHPの開発環境を整える
Chapter04 モダンPHPの文法と基礎文法
- 04-01 基本的な構文
- 04-02 型と演算
- 04-03 分岐処理
- 04-04 繰り返し処理
- 04-05 関数
- 04-06 PHP7の新機能
Part02 入門編
Chapter05 チームのための開発環境構築
- 05-01 開発環境のプラットフォーム
- 05-02 Dockerで開発環境を立てる際のポイント
- 05-03 実践的なアプリケーション開発のための環境を作る
Chapter06 設計から始める★
- 06-01 設計の重要性
- 06-02 要件定義をしよう
- 06-03 設計時の注意
Chapter07 CakePHPを使ってみよう★
- 07-01 実装を進める前に
- 07-02 CakePHPについて
- 07-03 テーブル設計とURL設計
Chapter08 質問と回答機能の実装★
- 08-01 質問一覧画面の実装
- 08-02 質問投稿画面の実装
- 08-03 質問詳細画面の実装
- 08-04 回答投稿機能の実装
- 08-05 質問/回答削除機能の実装
- 08-06 テーブルクラスの活用
- 08-07 バリデーションの実装
Chapter09 ユーザー管理機能の実装★
- 09-01 ユーザー登録画面の実装
- 09-02 ログイン画面の実装
- 09-03 ログアウト機能の実装
- 09-04 その他のユーザー管理画面の実装
- 09-05 質問/回答機能をユーザー情報と連携する
- 09-06 機能改善をしてみよう！
Chapter10 テストコードを書く★
- 10-01 本書で扱うテストについて
- 10-02 ユニットテストの必要性
- 10-03 CakePHPにおけるテスト
- 10-04 テストの準備
- 10-05 テストコードの書き方を学ぶ
- 10-06 テストコードはいつ書くべきか？
Part03 実践編
Chapter11 チーム開発の現場★
Chapter12 Pull Request駆動によるコードレビュー★
- 12-01 コードレビューの必要性
- 12-02 Pull Requestを利用したコードレビューの方法
- 12-03 コードレビューをしてみよう
Chapter13 開発に役に立つツール
- 13-01 なぜツールを使うのか
- 13-02 PHP_CodeSniffer: コーディング規約チェックツール
- 13-03 PHPStan: コード解析ツール
Chapter14 継続的インテグレーション
- 14-01 なぜ継続的インテグレーションが必要なのか
- 14-02 CIツールとは
- 14-03 CIを利用してみる
Chapter15 デプロイの自動化
- 15-01 Webアプリケーションの公開
- 15-02 ソフトウェアのデプロイメントサイクル
- 15-03 デプロイ自動化のメリット
- 15-04 コンテナベースのビルド&デプロイ
- 15-05 コンテナのデプロイサイクル
- 15-06 コンテナのデプロイを楽にするオーケストレーションツール
Part04 発展編
Chapter16 障害と向き合う
- 16-01 障害は突然やってくる
- 16-02 障害についての重要な考え方
- 16-03 障害と向き合うためのツール
Chapter17 SQLチューニング
Chapter18 PHPとセキュリティ
- 18-01 セキュリティの基礎知識
- 18-02 SQLインジェクション攻撃
- 18-03 XSS攻撃(クロスサイトスクリプティング攻撃)
- 18-04 CSRF攻撃(クロスサイトリクエストフォージェリ攻撃)
Chapter19 外の世界に飛び出そう★
- 19-01 OSSへの貢献
- 19-02 最新情報のキャッチアップ
- 19-03 更にその先へ
最後に
ここまで読んでくれた方は是非買ってください！
(私的)GoのWebAPI開発における現状: 論理編
この記事は？
インディー開発をしたり、本を読んだり、勉強会に参加したりして、GoのWebAPI開発における自分なりの実装パターンが固まってきたので現状を整理します。
具体的にはORM、フレームワーク、パッケージ構成あたりの話。
ある程度アンチパターンを踏んできてますが、僕自身プロダクションレベルでのGo開発経験がバリバリあるわけではないので、ここは間違ってるぞ！とか自分はこうしてる！など（建設的な）マサカリや大歓迎でございます。
tl;dr
前提
WebAPIの規模
以下のような小〜中規模程度のJSONで話すWebAPIを想定。
- APIの数は20本前後
- シンプルなCRUDベースのAPIが多いが、ちょっと複雑なリレーションやビジネスロジックも多少あり。
- 外部システムとの連携は（システム内の）DBがメイン。しかし、Push通知など外部のAPIと連携する箇所も。
ちなみにインディー開発中心なので、ミッションクリティカルなシステムであることは想定してません。とは言え、ある程度の規模までプロダクションレベルに耐えうるものを想定。（と言うより、そこを目指しています…！）
テクノロジースタック
このあたりは好みもあると思いますが、僕は以下の構成でやることが多いです。
上記の環境をDockerで作って開発してます。hot reloadの仕組みを入れるために fresh などを使うのはありだと思いますが、僕はIDEとして GoLand を使っており、ファイル保存時に自動でビルドが走るようにしてます。*1
なお、環境というかインフラはAWSやHeroku、VPS想定。GAE/GCPだとDatastoreを使うことが多いと思うので、また違ってきそう。*2
方針
銀の弾丸はないので、何が正しいか正しくないかは状況次第ですが、アーキテクチャやライブラリの選定基準や開発方針としては以下の2つを意識してます。
- やりすぎない（オーバーエンジニアリングしない）
- done is better than perfect!
- 郷（Go）に従う
- Rails way!
現状
前置きが長くなりましたが、ここからGo界隈でよく盛り上がるトピック別に現状を書いていきます。
ORM関連
いろいろ使いましたが、最終的に sqlx に落ち着いています。sqlx自体はORMというよりは database/sql パッケージをいい感じに使えるようにしたライブラリ。database/sql パッケージで頑張るのがGoっぽいとは思うのですが、structへのマッピングを自分でやるのは大変なので、メンテもきちんとされているsqlxを使うようになりました。
ActiveRecordに慣れている人は GORM もアリだとは思うのですが…と言うか自分も最初使ってました。しかし、エラーハンドリングが重要なGoの世界観と合わないと思ってるのと便利な分コードが複雑なので、慣れてきたら薄いライブラリを使うのがいいかなと思ってます。
ちなみに、スキーマ管理は schemalex か sqldef がおすすめです。MySQLならschemalexが枯れてて安心感があります。
その他の選択肢
フレームワーク関連
いわゆるWAFは使ってません。フレームワークを採用するのも良いと思いますが、個人的には余計なDSLを覚えずに可能な限りGoだけで書きたいので、現状は使ってません。RubyにおけるRailsみたいなデファクトスタンダードとなるフレームワークが誕生すれば、また別かもしれない。
とは言え、全部自前で実装するのはつらいので、ルーティングは Gorilla/Mux 、ミドルウェアは negroni を利用しています。JSONではなくHTMLをレンダリングするような場合だと、これだけだと辛いかもしれませんが、JSON形式のWebAPIならこれで充分かなと思ってます。
その他の選択肢
パッケージ構成
個人的にはGoに慣れてきて、一番困るのがこれかなと思ってます。フレームワークを利用していればまだいいのですが、使ってないと自由過ぎて困ります。ですので、これは今も試行錯誤していますが、最近はいわゆる？レイヤードアーキテクチャ+ポートパターンを採用しています。*4
概要図
こういうやつです。
基本的に通常のレイヤードアーキテクチャのように上から下に流れるようにしてる（下位のレイヤは上位のレイヤに依存しない）のですが、ドメインレイヤーにインターフェイス（ポート）を置くことで、ドメインレイヤだけどこにも依存しないようにしてます。
なお、破線部分については後述します。
フォルダ構成
こんな感じでやってます。
. ├── Gopkg.lock ├── Gopkg.toml ├── application │ ├── article.go │ └── user.go ├── config ├── domain │ ├── article.go │ └── user.go ├── infrastructure │ ├── db.go │ ├── article.go │ └── user.go ├── main.go ├── presentation │ ├── controller │ │ ├── handler.go │ │ ├── article.go │ │ └── user.go │ └── view │ └── render.go └── vendor
各レイヤの責務
僕がよく使うRailsやCakePHPのようなMVCモデルと比較しながら説明していきます。
プレゼンテーション層
MVCで言うコントローラーとビューにあたる箇所。コントローラーの責務はリクエストを受け取り、それをアプリケーションレイヤで利用出来る形にしてアプリケーションレイヤを操作すること。そして、その結果を（ビューと連携して）レンダリングすること。ここは極力コード量が少なくなるように意識しています。ビューの責務はレンダリングに関すること全般。ただ、JSON形式のWebAPIだとコントローラー側でJSONを出力するだけで事足りることが多いので、あんまり書かないことが多いかも。僕は汎用的なレンダリングのロジックだけ書くことが多いです。
アプリケーションレイヤ
いわゆるサービスクラスっぽい役割をする箇所。アプリケーションレイヤの責務はドメインレイヤとインフラストラクチャレイヤのビジネスロジックを操作すること。ちなみに、DBのトランザクションはここで制御しています。
ドメインレイヤ
みんな大好きモデルを扱う箇所。ドメインレイヤの責務はビジネスロジックの実装を持つことですが、技術的な実装（直接的なDBの操作やPush通知の送信など）は行ってません。また、先述の通り通常のレイヤードアーキテクチャとは異なり、ドメインレイヤとインフラストラクチャレイヤとの間にインターフェイスを設け、技術と実装を分離するようにしています。DBのモデル（struct）はここで定義していますが、インフラストラクチャレイヤで DTO を定義することもあります。*5
インフラストラクチャレイヤ
技術的な実装を扱う箇所。インフラストラクチャレイヤの責務は直接的なDB操作（SQLの実行）やPush通知の送信など技術的な実装を行うこと。通常のレイヤードアーキテクチャでは、インフラストラクチャレイヤはどこのレイヤにも依存しませんが、技術と実装を分離するために必要に応じてドメインレイヤのインターフェイスに依存させています。
オレオレルール
- 厳密なレイヤードアーキテクチャでは直下のレイヤにのみ依存すると思うのですが、2個下のレイヤに依存するのはある程度OKにしています。
- これが上記概要図の破線の意味です。
- 理想は直下のレイヤにのみ依存させるのがベストだと思うのですが、現実問題として厳密にやりすぎると辛いときがあるのである程度は許容してます。
- ただ、3個下は流石にダメ！（明らかに責務を越えてる）
なぜレイヤードアーキテクチャを採用しているのか？
個人的にはGoで小〜中規模のWebAPIを開発する時にクリーンアーキテクチャはちょっとtoo muchかなと思っています。*6 とは言え、薄いライブラリしか使っていないとMVCモデルでは少し辛いケースが多く、また、テスト観点から技術と実装を分離したくなることが多いので、このようなアーキテクチャにしています。ですので、逆に言うと、フルスタックなフレームワークやORMを使っている場合はMVC（+サービスクラス的なもの）で充分なケースも多いと思います。また、テスト観点だけであれば、インフラストラクチャレイヤがDBのみの場合は、インターフェイスを置かず通常のレイヤードアーキテクチャでもいいかなと思ってます。もちろん、単体テスト時のDBアクセスは低速でアンチパターンですが、RailsやCakePHPをこれまで使ってきた身からすると、そこまで違和感ないので。
その他の選択肢
- 縦割りパッケージ構成
- レイヤではなく、機能で分けるパターン。具体的にはuser packageやarticle packageを作るパターン。
- microservies化を想定しているならアリかなと思います。
- Goっぽいなと思いつつ、個人的には共通処理の扱いが難しいなと思ってます。
パッケージ管理ツール
Go1.12から vgo が正式導入されますが、3rd partyの対応状況を鑑みると、まだ（2019年1月現在）は dep が無難かなと思います。とは言え、今後はvgoを使うのが主流になっていくはず。
最後に
書いてみて、コードがないと分かりづらい気がしたので次はコード編を書いてみたい。その時は今回書けなかったログとかエラーハンドリングのことも書くぞ。
あと、冒頭にも述べましたが、Goは導入事例が増えてきたとは言え、RubyやJavaに比べると枯れておらず、ベストプラクティスがそこまで世に出回っていないので、自分なりの考えや現状を書くことで誰かのためになったり、議論のきっかけになったりすればいいなと思ってます。*7
2019年もGoGo！
参考サイト
- Go言語でのORMを色々検討してみた
- SQLで羃等にDBスキーマ管理ができるツール「sqldef」を作った
- https://qiita.com/bussorenre/items/0ec8722a8f0ecd977104
- Goのパッケージ構成の失敗遍歴と現状確認
- Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
- GolangでAPI Clientを実装する
- Goにおけるバージョン管理の必要性 − vgoについて −
脚注
*1:単純にMakefike経由でビルドしているだけ。
*2:『Clean Architecture 達人に学ぶソフトウェアの構造と設計』でも言及されている通り、技術的な実装に引っ張られないアーキテクチャが本当は理想なのでしょうが…。
*3:ただ、フレームワークはそんなにたくさんは試していないので、他にもっと良い選択肢があるかもしれない。
*4:この用語は『pospomeのサーバサイドアーキテクチャ』を参考にしています。
*5:このあたりは現在進行系で悩み中です…リポジトリパターンやDAOをどうやって使うとか…難しい…。
*6:もちろん開発するプロダクトや個人/チームのスキルにも依るとは思います。
*7:翻って、そこからまた自分が成長出来ればいいなとこっそりと思ってます。
2018 Retrospective
みんなが2018年の振り返りをやっているので、僕もやってみよう。
どうでもいいけど、昔はみんながやってることはあんまりやらないタイプだったのに、最近流行っているものをやっていないと、自分の感性や感覚がズレて来てるんじゃないか？と思って不安になる。知らんけど。
2018年のよかったこと
- 7回登壇することができた！
- ほとんどLTだけど、年末にPHPカンファレンスという大きなカンファレンスで登壇出来たのは、とても良い経験になった。 speakerdeck.com
- Podcastに初めて出演した！
- 恥ずかしくてまだ自分では聴いていないけど、何人かの人によかったよと言ってもらえたのでよかった！ takattata.github.io
- 南山大学の公開講座が最高of最高だった！
- ここ数年で最高の学びがあった。体験学習に勝るものなし。 itosho525.hatenablog.com
- 30冊ぐらい本を読めた！
- 今年は読書を習慣付けるために1スプリント（2週間）に1冊本を読むというのにトライしたけど、波はありつつ数はクリア出来たのでよかったかな。
突然の2018年読んで良かった本ベスト3
第3位: 『プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化』
プロダクションレディ・マイクロサービス、UberのSREが書いてるだけあって説得力がすごい
— いとしょ (@itosho) 2018年7月17日
第2位: 『NETFLIXの最強人事戦略 自由と責任の文化を築く』
NETFLIXの本に「人をいい気分にさせたいって言うじゃない〜？でもそれ正しいことをしたいからじゃなくて、自分もいい気分になりたいだけですから〜残念！」みたいなことがいっぱい書いてあって、身につまされる。
— いとしょ (@itosho) 2018年9月3日
第1位: 『ナナメの夕暮れ』
若林のエッセイ読んで泣いてる
— いとしょ (@itosho) 2018年11月17日
2018年のわるかったこと
- あんまり技術的な挑戦が出来なかった…
- 特に後半はとあるプロジェクト（これはもうすぐお話出来るのでもう少し待ってけろ！）で忙殺されて、成長実感が関西人くらい薄味。あかん。
- Gopher道場に参加したりGoでインディー開発をしたりしたぐらいかなぁ。
- インディー開発のリリースが1つだけだった…
- しかもチームのやつだけなので、個人では何も出せなかった！これまたあかん。
- というわけで年末年始は早速インディーやってます。
- 相変わらず英語を学んでいない…
- 海外旅行に行けなかった…
- というか今年は国内もあんまり行けなかった！お金を貯めないと〜！
- 来年は海外のカンファレンス行きがてら、観光とかしたい。
【番外編】2018年のプライベートなこと
- 凄い勢いでBリーグにハマっています🏀
- 引っ越しが決まりました！
2019年の目標
- 大きなカンファレンスで登壇（出来るような成果を出す）
- 英語の技術書をスラスラ読めるようになる
- インディー開発2本以上リリース
- 本を最低でも12冊以上読む
- 引っ越しを無事終える
全体的な抱負で言うと、今年は手広くいろんなことに手を出し過ぎた感もあるので、 来年は少しわがままをテーマに自分が本当にやりたいことだけをやっていきたい！ （仕事はちゃんとやるという前提）
ひとこと
今年も大変お世話になりました〜。来年も再来年もよろしくお願いします！
