転職して半年が経ちました。
転職して半年が経ちました。あっという間だった。
色々と落ち着いたので、振り返りと今後の展望をメモしておきます。
現職について
食品ECの会社でエンジニアとして働いています。
普段は基本的にAndroidアプリを書いていて、時々IoTの工作をやったりしてます。
ちなみにAndroidはフルKotlinでやっています。ことりんかわいいよことりん。
前職について
前職はWeb/アプリの受託開発がメインの会社で、3年在籍しました。3年間で10社以上の受託案件に関わったと思います。
最初の1年半はPM兼ディレクターみたいなことをして、その後Androidエンジニアにジョブチェンジしました。
度々の炎上案件で精神的に不安定になった時期もあり、全体的につらい日々でした。(ひとりで仕様書持って客先行って詰められて監禁されたり、数千行のMainActivityを泣きながら修正したり)その節は大変ご迷惑をおかけしました。
所々楽しい案件もあったんですが、つらい時期は正直思い出したくないです。
転職のきっかけ
去年から趣味で電子工作を始めて、その流れでハードウェア系の勉強会によく登壇するようになりました。
秋頃にとあるIoTの勉強会で登壇した時、弊社のひとに声をかけられたのが最初のきっかけです。
(念のために補足すると、声をかけてくれたひとは採用目的で来ていたわけじゃなくて、その時僕が発表していた内容に単純に興味があったらしい。)
勉強会のしばらく後に「ご飯でもどうですか?」とお誘い頂いたときに「これからAndroidアプリを立ち上げます」という話があって、だったらそれ僕にやらせてください!と手を挙げました。 元々自社サービスの開発に関わってみたいという動機はあったので、良いマッチングだったと思います。
少人数のチームながら「Kotlinでいくぞ!!」という攻めの姿勢も良かったし、開発の裁量を自分から取っていけそうだなという雰囲気も決め手になりました。
ちなみに、IoTきっかけで知り合ったのにAndroid書いてていいの??と時々聞かれますが、どっちも好きなので大丈夫です。:)
ともあれ、勉強会の登壇きっかけで転職することになったので、やっぱり外部でのアウトプット大事だなぁと再認識する出来事になりました。
半年間でやったこと
- Androidアプリのリリース
- 自社サービスの会員向けアプリをKotlinでリリース
- QiitaOrganization作った。
- クリエイターズブログ(テックブログ)作った。
- GitLab→GitHub移行
- 採用活動
- Androidエンジニア1名採用
- 外部の技術顧問に来てもらった。
最近
転職直後は「オシャーー!!やっていきだコラァ!!!!!🔥🔥」みたいな感じで、今思うと過剰にエモい様子で燃えていたんですが、最近は比較的落ち着いて冷静になってきました。いいことだと思います。
それに伴って、やりたいこと・やるべきこと・できることがだんだん明確になってきました。
やりたいこと
やるべきこと
- ちゃんと事業を成長させるグロースハックをやる
- やたらめったらコード書くんじゃなくて、意味のあるコードで事業を成長させる。
できること
- IoT
- ハードウェアチョットデキル
基本的にコードを書くのが楽しくて、それ以外の優先度を下げがちなので、周りに迷惑かけないバランスでやっていきたいと思います。
あと早起きが苦手なので、頑張って朝型になりたい…
半年経って正直細かいツラミや不満はありますが、それはしょうがないな・・・と納得できるようになってきました。どこ行っても多少のツラミはあるはず。
大事なのはそれを変えていけそうかどうかという雰囲気で、そういう意味だと今の職場は前者なので、頑張って変えていきたいと思います。変えられそうになかったら、またその時考えます。
まとめ
幸せな転職ができてよかったです。色々相談に乗ってくれたり、お祝いしてくれた友人のみなさま、いつもありがとうございます。
これからもエンジニア続けていきます。💪
松亭行きたい! pic.twitter.com/7mN1mTsEmp
— shanon (@shanonim) 2017年8月3日
「Androidを支える技術」出版記念イベントに行きました。
さっき行ってきました。
正直に白状すると、まだ1巻の半分くらいしか読めてないのと2巻買えてない状況で行ったので、前知識が少ない状態での参加だったと思います。 それでも興味深い話・おもしろい話をたくさん聞けて楽しかったです。(話のすべてを理解できたとは言っていない)
あと、Android界のスターエンジニアの方がたくさんいて、緊張しました。。
とんでもない会にきてしもうた.. #androidを支える技術出版記念
— shanon (@shanonim) 2017年7月14日
終わった後にペーパーテストとかないですよね....(白目 #androidを支える技術出版記念
— shanon (@shanonim) 2017年7月14日
同時開催だった #startup_android も行きたかったなァ。。。
エンジニアであるということ
イベントであった技術的な話については、ここでは書かないことにします。(本の内容をまだ完全に理解できてないので..
それよりも、有野さん @karino2012 の話の端々から感じたエンジニアとしての心得のようなものに感銘を受けました。
Q&Aのときに、Androidの生みの親であるAndy Rubin氏の話になって、有野さんは「彼にはかなわない、エンジニアとしての敗北を感じる」と言った後に「いまのレベルでは敵わないので、もっとよいエンジニアにならなければならない」とおっしゃっていました。(たしかこんなニュアンスだったはず)
僕からすると、ガラケー時代を経てAndroid1.5の頃からずっと開発を続けているエンジニアなんて雲の上のさらに上、大気圏外宇宙の果てレベルの神エンジニアなのに、それでもまだ上を目指すのか・・というような気持ちになってしまって、途方もないレベル差を感じてしまったわけですが、
同時に、このひとは本当に技術のことが好きなんだぁという情熱が伝わってきました。やはり「好きこそものの上手なれ」なのでしょう。
自分も、最近ようやく好きな仕事を好きなだけできる環境に関われるようになってきたので、このまま引き続き邁進してゆこう〜〜という気持ちになりました。
つらみはあるけどね、がんばろうね。
まとめ
お酒しながら書いたのでエモみがつよくなってしまった・・・
来週からもがんばります。
実装を急ぐくらいなら、MVPでリリースすべき。
実装を急ぐくらいなら、MVPでリリースすべき。という当たり前ポエムです。
大昔、開発リソース足りないのにフル実装を目指した結果、負債的コードが残ってしかもリリースできなかった様子ありけり。
— shanon (@shanonim) 2017年6月5日
MVPは、Minimum Viable Product(必要最低限の能力を兼ね備えたプロダクト)です。
つらいパターン
- リリースがやばい。
- 実装を急ぐ。
- 「とにかく動けばええねん。」
- 技術的負債みの強いコードが残る。
- 「誰やこんなコード書いたやつ!!!😡😡」→「2ヶ月前のおれや…………..」
- 「誰やこんなコード書いたやつ!!!😡😡」→「えっ……..マジで誰……..(もうすでにいない担当者のcommit)」
- enhancement issueが重くなる
- つらい😇😇
つらい実装をしてしまう背景
MVPが判断できずにフル実装してしまう
MVPを判断できるプロダクトマネージャ、もしくはリードエンジニアがいるとベストなんだろうけど、実装メインのエンジニアだけではその判断が難しい。結局、プロジェクト開始当初のフル要件をリリースまで引っ張ってしまうパターン。
調整するのが面倒になってフル実装してしまう
実際にMVPを検討することになっても、ファーストリリースでどこまで機能を削る??→削った機能いつ実装できる??っていう決めが必要になるので、結局「あーー調整めんどいし実装したほうが早いわ!!!!」ってなってしまうパターン。
そもそも
スキル的に実装可能だけど時間がないという状況は、ミスを生みやすい状況だと思います。それでも完璧に実装するのがプロだろ!!!って言いたいのは、わかるけど・・・状況のイレギュラーをエンジニアに押し付けるのはよくないので、解決すべき🐯
つらい実装をしない🙅🙅
短期的には、
- 時間のかかりそうな機能は一旦削除してissueを切る。
- 落ち着いて段階リリースしよう。
中長期的には、
- コードレビューを徹底する。
- MVPのわかるプロダクトマネージャをしっかり立てる。
まとめ
念のために補足すると、今やってるプロジェクトがつらい状況っていうわけではなくて、むしろこうなりそうだったから修正している(軌道修正できた)という感じです。備忘録。
いいリリースをやっていきたい。💪
Go合宿2017@ 土善旅館に参加しました #golangjp
Go言語のプログラミング合宿に参加してきました。
なぜ参加したのか
普段触れる機会の少ないサーバーサイド言語を勉強するという目的で参加しました。仕事ではAndroidアプリ開発にフルコミットしているので、サーバーサイドの知識はほとんどと言っていいほど持っていません。とはいえ、今後必要になる機会は少なからずあるだろうし、クライアントサイドの実装をする上でサーバーサイドも分かるメリットは大きいと日頃から感じていました。(API周りの設計知識とか欲しい。)
サーバーサイド言語の中でもGo言語は前々から気にはなっていたのですが、始めるきっかけ掴めず・・・そこでちょうど合宿開催の話を聞いたので、この機会にチャレンジしてみようと思った次第です。
合宿場所
千葉県の土善旅館に行きました。
土善旅館[弓道合宿・開発合宿]
エンジニア界隈ではおなじみの開発合宿御用達の旅館です。今回初めて行くことができました。 東京からだと、片道2時間半〜3時間くらいです。結構遠い。
うおー成田乗り換えでさらに50分揺られるのか...思ったより遠い土善旅館😇 #golangjp
— shanon.kt (@shanonim) 2017年4月22日
参加費
1泊2食付き・開発合宿用の大部屋レンタル料金・合宿中のアルコールとお菓子込で一人13,000円でした。安い!😳
スケジュール
1日目は14時過ぎに宿に到着して、19時まで開発→夜ご飯を食べて、その後は眠くなるまでひたすら開発、
2日目は8時に朝ご飯→11時まで開発してLT大会、14時くらいに宿チェックアウトでした。
実際に開発作業していた時間は、合計で13時間くらいでした。就寝時間によって個人差があったと思います。
- (1日目) 15:00-19:00, 21:30-28:30: 11h
- (2日目) 9:00-11:00: 2h
雰囲気
終始和やかでありつつ適度なワイワイがあり、楽しい雰囲気だったと思います。Go言語初心者向けのチュートリアル講義があったり、参加者同士のQ&Aがあったり、作業自体はそれぞれの個人活動でしたが、技術的な会話や交流が盛んで良い感じでした。
↑合宿中のたのしい様子を応用して作ったWantedlyコラ画像
コラ画像作ってる場合じゃないんですよ
— shanon.kt (@shanonim) 2017年4月22日
あとこれも合宿ならではですが、作業中は基本的にずっとお酒を飲んでいました。困ったら乾杯。バグったら乾杯。ビルド成功したら乾杯。デプロイしたら乾杯。🍻🍻🍻
深夜3時に乾杯する開発合宿があるらしい #golangjp
— shanon.kt (@shanonim) 2017年4月22日
適度なアルコール摂取は作業効率アップに良い効果があるので(個人調べ)、たまにはアルコール駆動開発もいいかもしれません。
土善旅館の最高ポイント
「開発合宿に適した旅館」と言われても正直ピンときてなかったのですが、実際に行ってみてわかった最高ポイントがいくつかあります。
WiFi環境が最高すぎる
とにかくWiFiが速い。
これ、1日目の作業開始直後くらいに測ったやつですが、都内の光回線と遜色ありません。むしろ土善旅館の方が速いのでは・・・。
参加者30名弱で同時接続してこの速度なので、ネットワーク環境は盤石と言えるでしょう。しかもこのWiFi、旅館内のどこからでも繋がります。便利すぎる。
ひとをダメにするクッション
超絶快適に作業できるんですが、快適すぎて眠くなるので危険アイテムでした。自宅にほしい・・・。
各種備品
外部ディスプレイやMac用の変換ケーブル、電源タップなどはすべて旅館からレンタルできました。ホワイトボードも借りれるので、地味に便利。
24時間使える温泉
館内の温泉は清掃時以外、基本的に24時間使用可能でした。開発に疲れたら湯に浸かっていつでもリフレッシュできます。
猫
かわいい!!!!!!!!!!!!!!!!11
開発終わった.....🐱 #golangjp pic.twitter.com/gZ8rVqgDI5
— shanon.kt (@shanonim) 2017年4月22日
成果
個人アプリのサーバサイド開発をやりました。
具体的には、
- Go言語の基本を覚える(文法・開発方法・一般的なlibraryについて)
- 開発環境を整える(今回はIntelliJ CEにGolangPluginを入れて使いました。)
- APIサーバ構築に必要なlibraryを使ってみる
- 実際に個人サービスのAPIモックを作ってみる
という順番で作業しました。
反省
事前にTODOをまとめて合宿に臨んだのですが、計画していたほど進捗できなかったのが心残りです。
A Tour of Goなど、基本的なチュートリアルを事前に習得して参加しておけばもっと開発速度上げられたなぁという反省があります。
まとめ
知識まっさらな状態からの参加でしたが、週末2日間でかなりの経験値を得ることができました。勉強せざるを得ない環境にあえて身を置くのも、たまにはいいですね☺
あと、Go玄人勢のGolang愛がすごかったので、ぼくもそれにあてられてGopherくんが好きになりました。
この合宿で得たスタートダッシュを活かして、引き続きGo言語やっていきたいと思います。
@合宿参加者のみなさま
2日間ありがとうございました!また勉強会や次の合宿(!)でお会いしましょう🍺
おまけ
旅館の美味しいご飯
合宿ごはん、美味しかった☺ pic.twitter.com/QAAZPbQBKv
— shanon.kt (@shanonim) 2017年4月22日
旅館からの差し入れデザートに合宿会場が沸いた #golangjp pic.twitter.com/cF09J64VK7
— shanon.kt (@shanonim) 2017年4月23日
🍙🍻 #golangjp pic.twitter.com/gYb86UjiEn
— shanon.kt (@shanonim) 2017年4月23日
日報を書き続けるモチベーションについて
半年前に書いた記事。 shanonim.hatenablog.com
この頃は、
- DayOneに書き貯める
- 一日の終わりにSlackの分報チャンネルにsnippetを投げる
っていう運用にしてたけど、最近は
に変わった。
日報を書くモチベーション
2つの面があって、ひとつは「自分用のメモ」
- 今日やった作業を振り返る
- 明日の作業を棚卸しする
- 自分自身のアサイン率を確認する
もうひとつは「報告」
- チームに自分の状況を共有する
- 上司に自分の状況を共有する
仕事で書く日報においては、後者の目的の方が強い。(前者だけならDayOneに日記として書けばいいだけなので。)
つまり、「日報を書くモチベーション=報告するモチベーション」というように言い換えられる。
悩み
前提として、今のチームでは日報の提出ルールがなくて自分が勝手にやってるだけだったりする。書いても書かなくてもよいということはつまり、別に読まなくてもよいということ。
そういう状況で報告し続けるモチベーション維持ってのが結構難しくて、フィードバックのない作業を淡々と続けるのはキツい。アウトプットするからには何かしらのアドバイスがほしいと思ってしまうけど、だってルール上読まなくていいんだから「毎日ぼくの日報読んでください!!」ともなかなか言いづらい。。
「だったら書かなくていいじゃん」って言われるけど、そういうわけにもいかないなぁと思う理由がひとつあって「エンジニアの仕事って外から見ると何やってるかよくわからないよね」問題をなんとかしたい気持ちが強い。 作業内容が日報という形でオープンになっていれば「アイツはなんかやっとるな」というのがわかるし、理解してもらえる。逆に何やってるかわからない状態だと手が空いてるように見えてしまう時があって、そういう時の評価は大抵実績と噛み合っていない。
なので、やってることをちゃんとやってるアピールすることは必要。
まとめ
日報を読んでもらうために書くことをルール化したいって気持ちは全然なくて書きたいひとが勝手に書けばいいと思ってるけど、そういう自由な状況における報告の仕組みって難しい。。
何か良い解決方法があったら教えてください。
Kotlin初心者向けハンズオンにメンターで参加しました #teratail_kt
仕事で毎日書いてるとはいえ、たった2,3ヶ月の経験でメンターをやってもよいのだろうか・・・という葛藤はありましたが、良い機会をもらったと思ってがんばりました。
What’s Kotlin?
「Kotlinって新しいバンド。。?」
— shanon (@shanonim) 2017年4月15日
プログラミング言語です。
ハンズオン
ハンズオンの講師は、@ngsw_taroさんでした。
すでに知ってる文法でもたろうさんの説明で再理解できたところが結構ありました。やっぱり実際に話を聞きながらその場で手を動かすと理解度がぜんぜん違う。途中、メンタリングを忘れて普通に勉強してました。(すみません….
たろうさんのKotlinライブコーディングが見れる会😭👏 #teratail_kt
— shanon (@shanonim) 2017年4月15日
もくもく
ハンズオンで一通りKotlinの文法だったり便利な構文を学んだ後、もくもく作業をやりました。Twitterのハッシュタグ(#teratail_kt)を見て質問にレスポンスしたり、Androidアプリ開発でのユースケースについて話したり、メンターっぽいことを少し。
それ以外の時間は、個人アプリをKotlinで作ってました。
反省
基本、受けだった
質問があったら答えるものの、自分から参加者のテーブルを回って「何か質問ありますか?」とまではアクションできなかった。というかそこまでやって全ての質問に答えられる自信がなかったので、もっと勉強しようと思った。
気づくのが遅い
もくもく会の途中でTwitterに質問が来てたものの、自分の作業に夢中になってしまって気づくのが遅くなった件があった。とても申し訳ない・・・。
良かったこと
Kotlinの良さを再確認できました。
when式、最高すぎて涙出る #teratail_kt
— shanon (@shanonim) 2017年4月15日
はーーー見やすい。。。☺ #teratail_kt
— shanon (@shanonim) 2017年4月15日
読みやすいし書きやすいし簡潔だし賢いし、何より名前がかわいい。名前がかわいい。
あと、たろうさんの著書(通称赤べこ本)にサインを頂きました。🎉ミーハーなことしてすみません。。
Kotlinスタートブック -新しいAndroidプログラミング
- 作者: 長澤太郎
- 出版社/メーカー: リックテレコム
- 発売日: 2016/07/13
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
嬉しい!!!!!!!!!!!!!!!!!!!!1
まとめ
Kotlinはいいぞ。
イベント
「まだKotlin触ったことないけど興味あるなぁ〜」って人は、Event Driven DevelopmentでいますぐLT枠登録!💪 kotlin.connpass.com
会社のデスクに人工芝を敷いていい感じにした。
会社のデスクは、一日のほとんどの時間を過ごす大切な空間です。
ちょっとした工夫で、快適なデスク環境にすることができます。
アイテム
- 人工芝
- 折りたたみステップ
- なんか箱
- なんか植物(プラスチック製)
すべて100円ショップ(CanDo)で買いました。
敷く
敷きます。
折りたたみステップ
外部ディスプレイを置く用です。
技術書を重ねて置く人も多いですが、こっちのほうが安定感あるし見た目が良いのでおすすめです。
良い。
置く
置きます。
デスクが華やかになり、おしゃれな気持ちになります。
プラスチック製ですが。
片付ける
イヤホンやスマホを片付けると、
スッキリします。
アフター
💯
まとめ
- デスクには緑が必要
- 小物をまとめる箱、良い
おすすめです。💪