2018-04-17

技術書典4にて、KUGIBAKOとしてサークル参加します！

技術書典4とは

言わずもがなと思いますが、技術書オンリーの一大イベントです

Androidの設計の話をまとめました

Androidの設計にした理由は下記です

いろいろ設計方面の話を多めにしてきた割に、やっぱりLTや話すだけでは足りないなと感じていた
いろんなチームを外から支援する立場が多くなったときに、すっと差出せるまとまったものがほしかった

できたのか...?

一応、できました。本当はもっともっと書きたいことが山積みなんですが、時間の都合もあって削らざるを得ない状況になりました。それでも、一番重要なことたちは詰め込むことができました。これらの経緯もあって、今回は「~pocket~」というサブタイトルみたいなものが、タイトルの後ろにひっそりついています。

書きたかったけど書けなかったことは、別冊ではなくこの本に継ぎ足してつつ、また常に最新情報に改訂しながら、またどこかで出せたらなと思っています。（つぎはきっと変なサブタイトルはつかないはず。~β~ とか ~golden master~とか決してつかないはず。)

目次 & 表紙

こちらが 尊い表紙 と目次です。貼らないですが裏表紙も尊いです。

なにはともあれ

もし、興味ある方いらっしゃいましたら、立ち寄ってみてください！

お気に入り的にチェックできるので、下記からチェックしてもらえると当日楽かもしれません。

techbookfest.org

取り置きに関してです。取り置きしてほしいと、そんな酔狂な方がいるのかわからないのですが、同人誌に詳しい方からトリオキニというサービスを教えてもらいました。

こちらから取り置きを受け付けるようにしたので、酔狂な方よろしくお願いします。

2018-03-03

リクルートマーケティングパートナーズを退職しました

二月末にリクルートマーケティングパートナーズ (以下RMPとします) を退職いたしました。

感謝ばかりです

そもそも大きな会社で働いたことのない自分をすんなり受けいれてくれたことから感謝しています。

環境の話

同じリクルートグループでも雰囲気だったりローカルルールだったりで多少異なるかもしれないのでRMPに限った話として。

勤務場所・時間

RMPではリモートワークが本当にフルで使えました。

満員電車を避けるために朝だけリモートワークしたり、また家でなくても東京各地にサテライトオフィスを借りてるので集中したいときはそっちを使ったりしていました。

コアタイムなしのフレックスだったので朝はゆっくりしたり、逆にすごく早くから始業したりと自分のパフォーマンスが発揮できる時間帯で仕事ができました。

評価制度がしっかりしている

リクルートらしい評価制度でなるほどと思うところがたくさんありました。もともと営業の会社なので若干ミスマッチなところもあるのですが (エンジニアに向けて絶賛最適化中です) 、それでもしっかり評価されてるなぁと感じました。

2年9ヶ月いて、半年に1回の昇級タイミングではだいたい毎回給料が上がりました。 (もちろん人によります。言いたいのはちゃんと上がるってことです。)

給料が毎回上がったっていうのは実際は僕の初めの給料が低かったという可能性もあるのですが、それでも前職に比べたら全然もらえてた方でした。

本当に成長できた

0->1, 1->10 を経験できた

自分がもともとRMPに入ったのは 0->1, 1->10 を経験したかったというのが１番の理由です。

というのも、自分は個人でサービスを作って安定して売り上げがでるくらい使ってもらえるまで軌道に乗せる、というのを数スレッド回すというのが昨今の目標なんです。

スタートアップなども考えましたが、すでにノウハウを持ってるリクルートで新規事業に関われるのであれば...!と決めました。

実際入社してからはノウハウもなんとなく理解することができました。またリクルートのやり方は個人では再現性がないんだなことも理解できました。

アイデア自体に突拍子やユニーク性はあんまりいらなくて、しっかりしたものをしっかり作って、ちゃんと広報して顧客に合わせて営業するという、言葉にすればシンプルですがそれぞれを高いレベルで実行できればビジネスは育っていくんだなぁと思いました。

思想が変わった

もともとエンジニア至上主義みたいな考えがちょっとありました。企画もグロースも広報もデータ見て改善していくのも全部エンジニアがやればいいじゃんみたいな考えです。

前職がスタートアップで、その場所ではそれが正しかったんですが、大きな組織ではその限りではないなとすぐに悟りました。

RMPに入社してからは 優秀な企画の人 がいるチームで働き、「あぁ、企画もエンジニア並みに専門職じゃん」と考えるようになりました。数年以内に何億円何十億円のビジネスを作る約束をして実現する能力は、今のところ僕にはありません。

それ以降は一層リスペクトして接するようになりました。今では全部エンジニアがやるんじゃなくて お互い歩み寄っていくべきなんだ と考えています。

リードエンジニアや開発グループのマネージャーを務めさせてもらった

消去法かもなんですが、やらせていただきました。

グループマネージャーになってからは本当に血反吐を吐くほどにはいろんなことを考えて悩んで、ある程度実体験に基づいた考えみたいなものも持つようになりました。箇条書きで書くと下記みたいなところです。

どうやって強いグループにしていくべきなのか
チームの自立をどう促していけばいいか (自分がやってもしかたない)
どうやっていいエンジニアを採用していくか
エンジニアの働きやすい環境とは
エンジニアを評価するには
いいエンジニアの文化をどう醸成して行くか
エンジニアと非エンジニアの関係性(個人間)について
エンジニアと非エンジニアの関係性(グループ間)について
他エンジニアグループとの関係性について
などなど

結局、任命してもらったにも関わらずグループマネージャとしては未熟なまま、8ヶ月間ほどで外れさせてもらいました。外れた理由は複合的な理由が多くあるんですが、自分がメンバーだったら数ヶ月後に辞めるって言ってる人にいろいろ言われたくないなぁと思ったのが大きなところを占めます。

グループマネージャとしては微妙だった僕もリードエンジニアとしてはうまくやれたのかなと考えてます。僕は リードエンジニアのあるべきゴールは自分が外れてもしっかり回るチームを作ること だと考えています。 2年9ヶ月でプロダクトを作り上げながら若手を育成し最後は引き継いで自分は次の~~燃えている~~所へ、というのを三度ほどやれたので (若手がめちゃくちゃ優秀だったというのが大きいですが) 自分の中ではここだけは満足しています。

じゃぁなんで辞めるのか

若手に引き継いで回った結果やることがなくなった (あんまりやりたくない仕事ばかりになった)というのが大きな理由です。自分がやるよりは若手の成長機会や実績にした方がいいよなって思ってたら (いまでもそれは正しいと考えています ) 、いつの間にか雑務やマネージメントばかりになって技術者としての自分を維持できるかどうか不安になってしまったんですね。

もっと多くのプロダクトとエンジニアがいれば際限なく放牧民のようにプロジェクトを転々としていけたんでしょうが、まだそれほどでもない部署でした。

ミスマッチしてきたので辞めたということになります。

まとめ

結論、本当にお世話になりました！！！お疲れ様でした！！！

宣伝

また別途ブログに書くんですが、技術書典に出店します！

前職にて下記の記事を書きました。

tech.recruit-mp.co.jp

正直言うと、今見ると厳しいな...と感じる部分が多くあります。また大枠でしかないので、これだけだとわからないことも多くあるでしょう。

この記事から、もう3年経とうとしています。

この3年間で、僕が使った新しい技術や考えを豊富に取り込んだものを、記事ではなくて一冊の本に仕立てあげます。先日下記のツイートをしました。

アプリでレイヤードアーキテクチャで実装するなら Domain -> Infra -> UI -> UseCase (Application層ともいう) の順で書くといいと考えてるます。
ドメインを知ったら定義して、infraを実装して、UIを作ることでアプリケーションロジックが見えてきて、それをUseCaseに落として実装する、みたいな
— 有象無象@技術書典く-45 (@kgmyshin) 2018年3月1日

僕の中では結構いいねとかしてもらえたんですが、こういうレベルの実体験からしか得られなかったような知見をふんだんにぶっ込みます！

まだ少し先ですが、転職祝いがてら技術書典当日にぜひ く-45に寄って もらえたら嬉しいです！

以上、ありがとうございました！

2018-02-09

DroidKaigi 2018で「マルチモジュールのすヽめ」という内容で発表して来ました

DroidKaigi2018のDay1のラストセッションで「マルチモジュールのすヽめ」というタイトルで発表して来ました。

前回の2017年では「未熟なチーム開発」という技術というよりは、いわゆるエモい内容で発表したのですが今回はちゃんと技術的なお話で発表させていただきました。

スライド

speakerdeck.com

感想や反省点

人数

正直そんなに聞きに来る方いないのでは...と思ってて30人くらいいてくれれば和気藹々と話しながらやれるかなと思ってました。

蓋を開ければ、恐縮なのですが部屋が埋まる勢いだったので正直ちょっと怖かったです。

話すスピード

一人でリハをやってた時はなんどやっても27分くらいで終わってました。

実際本番ではもう少し早く終わってた記憶があるのでちょっと早口になってたかもしれないです。

よかったこと

聞いてくださってる中のツイートを見返して見たら、「発表が上手」というツイートがありまして、そこを褒められたのは初めてだったのでめちゃくちゃ嬉しかったです。

何をゴールにしていて、何を最低限使えればいいのかをあらかじめ設定していたのは効果があったのかもしれません。

セッションの内容について、聞いてくれてる方がどう感じるかをストーリー立ててagendaを組んでみました。

結果として、へんなもやもやみたいなツイートはあまり見られなかったので、うまくいったのかなと思います。

加えて、セッションの始まる前のみんなの移動時間に、セッションのタイトルだけでなく、「セッションのゴール」と「セッションで話さないこと」を写しておりました。

期待と違うセッションであれば、その時間であれば移動しやすい、、ということを狙ってました。

結果としては(見てないだけかもですが)、それによって出て行く人を観測はしてないんですが、共通認識をあらかじめ作ることはできたのではないかと考えてます。

また、たまたまなのですが最後のセッションということもあってホールに移動するため部屋に待機ということになり、その間の20分くらいずっと多くの方々に質問していただけたのが本当に良かった。

時間の都合上話せなかったほとんどのことをそこで話すことができました。

よかったかどうかわからないこと

事前にセッションの情報について公開しておりました。

motida-japan.hatenablog.com

ただ、これは正直効果があったかどうかわかってないです。その為にも「ブログ見てくれた方いますかー？」くらい聞けばよかったと反省。

上記のブログの記事を書くことによって、改めて個人的に整理できた点ではやってよかったです。

反省

リハを何度かやってここが終わったらだいたいn分経ってるみたいな感覚を掴んでいたんですが、テンパって肝心のストップウォッチを開始し忘れてしまったのは痛手でした。

開始前は掴み・どうやって話し始めていこうかなというところに頭を使ってしまってしまい、そこに意識が行き過ぎてたみたいです。

また、リハの時からボイスレコーダーに記録して見て気になってたのは「えっと」という言葉が多いなと感じていて気をつけようと思ってたんですが、本番ではその意識は飛んでたのできっと言ってしまってたと思います。

上記二つとも本番前の練習で解消できることではあるはずなので、もっと練習して場慣れして行きたいと思います。

残り1日、本日も気になるセッションがてんこ盛りなのでたくさん聞きに行きたいと思います！

2018-02-01

DroidKaigi2018 〈マルチモジュールのすヽめ〉というセッションについて

この記事では Droidkaigi2018で自分が話す〈マルチモジュールのすヽめ〉というセッションにおいて、 何を話すか・何を話さないか を共有します。

想定と違ってがっかりしてしまう方がいないことを願って。

また逆にこの記事で興味を持ってくれる方がいることを願って。

セッションのゴール

自分のセッションには下記のようにゴールを設定しています。

good: 聞いてくれた方が「...(マルチモジュールわんちゃんありやな)...」って思ってもらえた
very good: 聞いてくれた方のうち誰かが実践してくれた

話すこと

上記のゴールを満たす為に大まかには下記を説明することに焦点をおきました。

マルチモジュールでアプリを実装することの有効性
マルチモジュールの導入 (実践イメージが湧くレベル)

実際のagendaは下記となっております。

なぜマルチモジュール化するのか
マルチモジュール化するデメリット
モジュールの分け方について
Case Annict
実際にマルチモジュールにしてみる
モジュール間の連携について

下記のようなストーリーを思い浮かべてます。

章	聞いた後の想定する感想
なぜマルチモジュール化するのか	でもデメリットはあるんでしょ？
マルチモジュール化するデメリット	メリット・デメリットはわかった。じゃぁ実践するには？
モジュールの分け方について	具体的には？
Case Annict	分け方はわかった。実際どうするの？
実際にマルチモジュールにしてみる	なにか困ることない？
モジュール間の連携について	(実際に聞いた人のみぞ知る)

各章の聞いた後の疑問がなるべく次の章で解決するように、最後には実装イメージが湧くようにと考えました。

話さないこと

下記は話しません。

instant appsについて (キーワードで触れるレベルです)
kotlin nativeについて
その他agendaにないこと

元の仮案とのdiffについて

下記が元のdescriptionです。

自分の関わるAndroidのアプリ開発ではマルチモジュールな作り方を実践しています。
その中で得られた知見を共有します。

下記がagenda(仮)です。

- マルチモジュールに分けた動機
- メリット
- デメリット
- 技術的な実現方法
- ハマりポイント & 気をつける場所
- 途中からマルチモジュール化する
- etc

それぞれ統合、名前の変更、除外などあります。