DroidKaigiのIssueに思い切って手を挙げてみたらすごく学びが深かった
はじめに
いきなり結論ですが、
Android開発初心者も思い切ってIssueを担当してみると圧倒的成長につながるよ
これがこの記事で1番言いたいことです。
具体的にはどういうことか、自分はどんなことをしてその結論に至ったのかを書いていきたいと思います。
対象の読者は、DroidKaigiをご存じない方、Androidにそれほど自信はないけどOSSへのContributeをしてみたい方です。 自分は初めてのOSS Contributorになれて嬉しさ満載なので、その気持ちをこの記事にぶつけます。
バックグラウンド
自分の経歴や開発経験は過去記事を読んでいただければ分かるのですが、ざっくりまとめると、
と言う感じです。
DroidKaigi
DroidKaigiはエンジニアが主役のAndroidカンファレンスです。
日本国内で最大級のAndroid技術カンファレンスです。
自分は1年前はDroidKaigiの存在をしらなかったため、参加するのは今回が初めてですが、各地の最強Androidエンジニアが長年培ってきた技術をとてもわかりやすく共有する場って、かなりワクワクしますね。
開催日は2020年2月20日(木)〜2020年2月21日(金)で、まだチケット販売もおこなっているそうなので、まだの方は是非申し込んでみることをお勧めします。
OSSなGithub Repository
こちらは、カンファレンス当日のタイムスケジュールやフロアマップをスマートフォンからみることができるアプリのソースコードです。
毎年、DroidKaigiのアプリを各地のAndroidエンジニアが有志で作っています。
例年、カンファレンスの約1ヶ月強前までにある程度実装されたこのRepositoryがpublicになります。
まだ一部機能が実装されていなかったり、バグが存在する状態なため、これまた有志のAndroidエンジニア達がContributorとして追加開発していく流れです。
2020年1月22日(水)現在では、合計100名ほどのContributorがいらっしゃるらしいです。
この、全体で知見を共有しつつ、最高のアプリを作っていく感じ、素晴らしいコミュニティ/カンファレンスだと思います。
そして1番何が良いって、
その年の最新のトレンドをふんだんに使用したコードなため、知見の宝庫なのです。
エンジニアという職業柄（まだ就職していませんが）技術のトレンドは毎年変わっていきます。流行り廃りが激しく、最近までのデファクトスタンダードが今はすでにレガシーになってしまったり。
毎年、この時期にこの 知見の宝庫 が共有されることで、キャッチアップがしやすくなる利点があります。
最強の教本ですね。
Issue
上述したように、DroidKaigiアプリは有志のエンジニアが募ってアプリを完成させていくため、好きなIssueを担当し、PRを出すことができます。
そのIssueは、運営?メンバーの方が立てたものはもちろん、自分がアプリを触っているうちに発見したバグや欲しい機能をIssueに追加することができます。
そのIssueの難易度にはかなり幅があり、
- Layoutのmerginを調節する
という簡単なIssueから、
- iOSアプリを対象にMPP(MultiPlatform Project)を進める
という力量が問われるIssueまで存在します。
冒頭でも行った、
Android開発初心者も思い切ってIssueを担当してみると圧倒的成長につながるよ
に繋がるのですが、
割と easy Labelの貼られたIssueが多く、誰でもContributorになれるチャンスがあるのです。
担当したIssue
実際に担当したIssueはこの2つです。
- スタッフ一覧を表示する画面に関して、ViewModelにUiModelを導入する、
- 上記のViewModelTestの記述
これらのLabel、 easy なんですよ。
UiModelってなに？テストなんてかけないよ って思われる方もいるかもしれません。なんなら最初見たときは自分もそうでしたが、
既にUiModelを導入したViewModelや、テストを書いた画面が存在するため、基本的にはその実装を模倣すればできるのです。
これが easy である所以ですね。
ただまあ、コピペエンジニアは自分のポリシー的にもタブーなので、しっかりと理解して自分なりに実装してみつつ、あくまで他の画面は参考にするという方針でコードを書きました。
この記事は、同じAndroidエンジニアの友人へ向けた（自分なりの）コード解説を含んでいるので、
下記に UiModelとは、ViewModelTestに関して少し言及したいと思います。
※解釈に誤りがあれば教えてください🙏
これをみる前に、まずご自身でDoroidKaigiリポジトリのREADMEを一読してからのほうが理解が深まると思います。かなり丁寧に書いてくださっているので。
README見たらだいたいわかったという人は飛ばしてもらってOKです。
UiModel
StaffsViewModel
class StaffsViewModel @Inject constructor( private val staffRepository: StaffRepository ) : ViewModel() { data class UiModel( val isLoading: Boolean, val error: AppError?, val staffContents: StaffContents ) { companion object { val EMPTY = UiModel(false, null, StaffContents.EMPTY) } } // 略 }
自分が担当したIssueで追加したUiModelです。
UiModelというのはおそらく、UI（ActivityやFragment）側の状態を司るクラスだと思います。
実際にUiModeのコンストラクタでは、下記の3つの状態があります。
- isLoading
- ローディング中かどうか
- error
- AppErrorはseald classで
ApiException等々のExceptionを複数定義しているクラス - errorではない可能性があるためNullable
- AppErrorはseald classで
- staffContents
- 表示するスタッフのリストを保持したModel
- repository等でデータ取得できればここで保持する
何も考えずにやるとすると、Loadingの状態をLiveDataとして普通にViewModelのメンバに持たせることになるかと思いますが、UiModelを挟むことで状態が散らばらずに一元管理できて便利なのでしょう。
StaffsViewModel
private val staffContentsLoadState: LiveData<LoadState<StaffContents>> = liveData { emitSource( staffRepository.staffs() .toLoadingState() .asLiveData() ) staffRepository.refresh() }
ViewModelのここでは、Repositoryを経由して StaffContents を取得し、それをLoadingStateに変換し、さらにLiveDataとして扱うよ〜〜というコードですね。
Repositoryを経由しているのは、Entityの取得をDatabaseから取得するかApiから取得するかを、ViewModel以上で知らなくて良くなるためです。
責務の分離ですね。
内部的には StaffRepository#staffs ではDatabaseから取得。 StaffRepository#refresh() はAPIを叩いてからDatabaseに最新のスタッフ情報を格納する挙動になっています。
これらの挙動をViewModel等が意識しなくて良くなるため、Databaseの種類が変わろうとViewModel以上には影響がなくて済むのです。
StaffsViewModel
val uiModel: LiveData<UiModel> = combine( initialValue = UiModel.EMPTY, liveData1 = staffContentsLoadState ) { _, loadState -> val staffContents = when (loadState) { is LoadState.Loaded -> { loadState.value } else -> { StaffContents.EMPTY } } UiModel( isLoading = loadState.isLoading, error = loadState.getErrorIfExists().toAppError(), staffContents = staffContents ) }
これも、やっていることは簡単です。
combine という、内部的には MediatorLiveData と同様のことをしている拡張関数で、引数を数個とることができます。
combine に渡したLiveDataの値に変更があれば、ラムダ式が実行されて、UiModelが更新されるという内容です。
今回はliveData1だけに止まっていますが、他にも hogeLoadState なるLiveDataがあった場合には、
staffContentsLoadStatehogeLoadState
のどちらかに変更があった場合にラムダが実行されます。
そのため、UiModelのisLoadingは
isLoading = staffContentLoadState.isLoading || hogeLoadState.isLoading
のように変えてあげる感じです。
詳しくはリポジトリの SessionDetailViewModel で複数バージョンのものが実装されているので見てみてください。
StaffsFragment
override fun onViewCreated(view: View, savedInstanceState: Bundle?) { //略 staffsViewModel.uiModel.observe(viewLifecycleOwner) { uiModel -> progressTimeLatch.loading = uiModel.isLoading groupAdapter.update(uiModel.staffContents.staffs.map { staffItemFactory.create(it) }) uiModel.error?.let { systemViewModel.onError(it) } } }
あとはFragmentのonViewCreatedでobserveして、UiModelの状態に応じてUIを切り替えてあげるだけです。
もしこれがUiModelとしてまとめておらず、ViewModelにLiveDataを乱立させていたら、observeが乱立し、UI更新処理が分散してしまい処理が追いづらくなるのです。
これですっきりまとめられましたね。
ちなみに、progressTimeLatchに関して、詳しくは内部実装を読んでいただきたいのですが、Fragmentでこのような実装がされていました。
StaffsFragment
progressTimeLatch = ProgressTimeLatch { showProgress ->
binding.progressBar.isVisible = showProgress
}.apply {
loading = true
}
ざっくりいうと、 ProgressTimeLatch のメンバ変数である loading の値を変更すると、上記のラムダ式が実行されるって言う感じですね。
上記はラムダ式の定義と同時に loading をtrueにしているため、 binding.progressbar がVisibleになる感じですね。
おわりに
思ったより長くなってしまった...
結論何が言いたかったかと言うと、繰り返しになりますが。
Android開発初心者も思い切ってIssueを担当してみると圧倒的成長につながるよ
です。
最初は何書いてるか全くわからん状態かもしれません。しかし、DroidKaigiは優しいため、大抵他の画面で参考になるコードがあったりするので、 easy Labelであれば後先考えず
「🙋♂️」
とコメントしてしまうと良いかもしれません。
広く全体のコードを読もうとするから全くわからん状態になってしまうのかもしれません、 easy なIssueを引き受け、一旦は狭い範囲を重点的にみて、他のコードを参考にしつつ理解を深めて全体に視線を広げていく方針はお勧めです。
おまけ
ちなみに、
easy なIssueなんてすぐ埋まっちゃうよ！！
みたいな人は、GithubとSlackを連携させてIssueが立ったら自動的に通知してくれる仕組みを導入すると見逃しがなくなったり、素早く反応ができるためお勧めです。
これを見ればすぐに設定ができるのでやり得です。
Firebase Startup Hackathonに参加しました
先日、FIrebaseを使ってサービス開発をするHackathonに参加したので、その概要と感想をまとめたいと思います。
Firebase Startup Hackathon
上記画像に記載の通り、SingularitySocietyさん主催のFirebase Hachathonでした。
自分は初のHackathon参加なので、新鮮でした。
内容は、
というもので、
Firestoreでのラフなデータ構造を共有して、それに基づいて、Web, iOS, Androidなど、各人各々の得意な環境で実装を行っていきます。
とのことでした。
ここでいうCMS（コンテンツ・マネジメント・システム）は、ブログのようなイメージで、現在台頭している、
のようなサービスを作ろうというものです。
企画側でfirebaseを使ってサービスを作るためのアイデアソンをした際、WordPressって以外と古くない？新しくfirebaseで作り直そうよ、となったそうです。
WordPressの特徴である
- サーバーが必要
- PHP
- 20年前の設計
- MySQL
- 複雑
と比較して、
firebaseを使うと
- スケールが青天井
- サーバレス
- Realtime Webで、クロスプラットフォームにも対応
- 無料枠がある
- NoSQL, NodeJS,Cloud Functionが使える
などのメリットがあり、確かにfirebaseでの再設計は良さそうという所感でした。
叩き台
今回のHackathonは、上述の通り1から実装するのではなく、既に主催側である程度実装したリポジトリに、新しい機能をつけるという趣旨でした。
そのリポジトリはこちら
詳細はconnpassにも記載あります。
firebase-community.connpass.com
で、こちらのリポジトリなのですが、 書かれている言語及びフレームワークが、
React
だったんですね。
自分は、1年前にプログラミングを始め、それ以降Android一筋で開発してきたため、
Reactは言うまでもなく、JavaScript自体全くわからん状態なのです。
いやconnpassに載ってるし予めRepositoryみとけよって話なんですけど、
本イベントでは、Firestoreでのラフなデータ構造を共有して、それに基づいて、Web, iOS, Androidなど、各人各々の得意な環境で実装を行っていきます。
とか、対象者欄に
と記載があり、
「あ、レベル感的にこんな感じなんだ。Androidで開発するぞ💪」なスタンスで参加したので少し驚きました。 ※全然文句を言ってるわけではなく、純粋に驚いたという感想です
今回自分は、Firebase運用経験もなく、枠が余ってそうだったので初心者枠で申し込みました。
Hackathonの参加者を見る感じ、
- SIerでマネジメント寄りのポジション
- デザイナーだが最近プログラミングを始めた
という初心者から
- 個人開発でも業務でもFirebaseを使っている
- 言語のコミッター
などのつよつよエンジニアまで幅広くいらっしゃいました。
初心者は中級〜上級者と一緒に設計/開発してみましょうという雰囲気でした。
やったこと
本題に入ります。
アイスブレイク（10:00~10:15）
特に初めからチーム分けされているわけではなく、適当に座った席の周りの人たちと軽い自己紹介のようなものをしました。
白紙を4分割して、
1. 名前/やっていること
2. Firebase習熟度（☆5段階）
3. どんな技術が好き/得意か
4. Firebaseを絵で表すとしたらどんな絵か
を互いに発表し合いました。
4つ目はみなさんもちろん"🔥"を描かれていて、
そりゃそうですよねw
って感じになりました。
リポジトリとHackathon概要説明（10:30~11:00）
これは上述したので省きます。
Firebase LT会（11:00~11:40）
Hackathonを始める前に、Firebase個人/業務で使っててすごく分かるマンな方たちが、1人10分で4名LTしてくださいました。
以前のFirebase Hackathon？Ideathon？で優勝された方々が、実際にFirebaseを使ってサービスを作ったそうで、LT会でもそのお話をされていました。
一言で言うと、リアルタイムなスライド共有サービスで、 登壇者がスライドを移動すると視聴者のスライドも追従します。
また、画面端にコメントを書き込めるので、わざわざ tweetdeckとかでハッシュタグ追いかけたり、公のTLを荒らさずに済むので良いなと思いました。
(個人的にTwitterにハッシュタグつけてLTの内容を連続投稿するのはあまり好きじゃない... 需要と供給が一致していないことが多い気がする)
LTのスライドも上記のリンクのFirebase Startup #3 Hackathonにあると思うのでご覧になりたい方は是非。
お昼休憩/チーム分け(12:00~12:20)
本当は実装の前に"設計"タイムがあったのですが、LTが白熱したため時間が取れませんでした。
お昼休憩も20分ほどしかなかったのですが、お弁当を用意していただいたので、食べながらチーム分けを行っていました。
叩き台は主に、
- ログインができる
- マークダウンで記事が投稿できる という2つの機能に止まっていたため、
チーム分けは、既存の叩き台にどんな機能を付け加えたいかをアンケートを取り、その機能を付け加えたい人同士が適当にチームを組んで実装するという割と勢いのある分け方でした。
機能の候補としては、
- SNSシェア機能
- お気に入り機能
- TypeScript化
- コメント機能
- テンプレート導入
- タグ導入
- etc...
がありましたが、Reactが全くわからん状態で複雑な機能を実装できる自身がなかったため、SNSシェア機能を選択しました。
チームメンバーはほぼ全員がReactを触ったことがなく、チームエンジョイ勢として実装に取り掛かりました。
実装（12:20~15:20）
まあここは言わずもがなですね。
ほぼ何も出来ませんでした
悔しい。
一応機能は完成したので全く出来なかったわけではないですが、参加前の自分の期待値より大幅に下回っていたので自己評価は低めです。
流れとしては、チームで要件を話し合い、要件を細分化し、チーム内で割り振ってReactで要件を実装する方法を調べて、できそうであれば実装
といった感じでした。
Android開発しかやっていないと、Android APIであったり、ライブラリの使い方、Androidにおけるライフサイクルには詳しくなれるのですが、
Web関連の知見が全くないんですよね。(あたりまえ)
なので、ルーティングであったり、リダイレクト、そもそもJavaScript/Reactがわからなかったり....
今回の限られた時間の中で全てを理解するのは至難の技でした。というか無理でした。
ですが、最低限のITリテラシーはあったため、なんとか見様見真似でTwitterシェア機能をつけることに成功しました。
おわりに
実装が終わったあとは発表、講評、懇親会でした。
とくに順位を競い合うイベントではなかったためここは省略します。
他の班も限られた時間ではなかなかうまく実装ができなかったようで、大変でしたね、と慰め合いました。
今回のHackathonは、参加前の期待値が高すぎて、少し思ったものとは違う感想ではあるものの、
クオリティの高いReact + Firestore + Cloud Functionのサンプルコードを得られてかつWeb領域へのやっていきの必要性を感じられた良い機会になったかなーと思います。
というか、今回Firebase HackathonなのにFirebaseのこと全く書いていないですね。
というのも、実装テーマがFirebaseにあまり関係なかったことと、設計タイムが取れなかったためFirebaseの知見はあまり得られなかったので、リポジトリを眺めつつ、勉強していこうと思います。
Firebaseのイベントは、次回は2月末の開催だそうです。
次も参加しようと思います。
Firebase + Webの知識つけるぞ。
2020年にやりたいこと
2019年の振り返りはこちら↓
kurutabrog.hatenablog.com
2020年にやりたいこと
2019年はエンジニアとしてのスタートダッシュの年でした。
右往左往しながら、とりあえず、やってみようが多かったように思います。
そこで、今年は目標をしっかりと定めてNotion等で管理するようにしようそうしよう。
私生活は一旦置いといて、エンジニア関連の目標をいくつか。
- 📕目標： - ✏️目的： - ✋ ルール：
みたいな感じで書いていきます。
- 📕：LTに5回以上登壇する
- ✏️：エンジニアとしてのプレゼンスを高めると同時に、得た技術をアウトプットする練習をする。
- ✋ ：登壇枠が空いていたら積極的に予約する。締め切りドリブンで。
- 📕：本を月に2冊読む（自己啓発本or技術書）
- ✏️：論理的思考力、語彙力、技術力を身に着ける。
- ✋ ：audio bookでの聞く本でもOK。ただし通勤中など、本に集中できる状況で聞くこと。
- 📕：月に4回、記事を書く。(Qiita,Mideum,はてブ)
- ✏️：エンジニアとしてのプレゼンスを高めると同時に、得た技術をアウトプットする練習をする。
- ✋ ：イベント参加記、読んだ本の感想でもOK。なるべく技術アウトプットを多くする。
- 📕：新しい言語を習得する。
- ✏️：Android開発以外にも手を広げる。
- ✋ ：サーバーサイド言語が好ましい。
- 📕：Webを完全に理解する
- ✏️：Android開発以外にも手を広げ、他分野のエンジニアとの会話を円滑にできるようにする。
- ✋ ：https://github.com/kamranahmedse/developer-roadmapのBackend側を一通りこなし、理解できること。
- 📕：毎日草を生やす
- ✏️：毎日コードを書く習慣をつける。
- ✋ ：Issueを立てるだけはNG。ちゃんとコードを書く。
- 📕：個人アプリを1つ以上リリースする。
- ✏️：業務ドメインで扱わない技術を触ったり、サービスをスケールさせる。
- ✋ ：乱立するのではなく、リリース後の運用まで見越したサービスをリリースする。
- 📕：つよめのAndroidエンジニアになる
- ✏️：基礎をしっかり。発展もできるように。
- ✋ ：頑張る。
まだまだ出てきそう&もう少し細分化した方が良さそうなところもあるけど、一旦これを目標にして一年頑張ろう。
今年もよろしくお願いします！
2019年を振り返って
はじめに
2019年は、本格的にエンジニアを目指し始め、人生で1番の転換期でした。そして、人生で1番充実した年でした。
エンジニアとしての道を歩み始めたこの1年を振り返り、文字に起こすことで、自分が将来見返したときに初心に立ち返るきっかけになれば良いなと思います。
また、これからエンジニアを目指す人にとっての参考になれば幸いです。
月ごとに振り返るのですが、その少し前から動き出していたので、2018年もさくっとバックグラウンドも含めて振り返ります！
2018年
- 4月：大学4回生で研究室配属
- 5月：やりたいことがなく、C言語を1ヶ月独学
- 6月~8月：卒論、院試勉強
- 9月：院試、Y社のインターンに落ちる
- 10月：卒論、エンジニアに関する情報収集、progateかじる
- 11月：卒論、ITパスポート勉強開始
- 12月：卒論ピーク、ITパスポート合格
2018年を要約するとこんな感じです。 人生の転換期になったと感じる出来事は太字で書いてます。
5月
自分は大学4回生のときまで、将来やりたいことが全くありませんでした。
専攻の好きでもない材料系の授業を受けて、サークルに行って、バイトをして1日を終えるようなごく普通の生活を送る大学生でした。
そのため、3回生で就活することもなく、8割が院進するからという理由で大学院に行こうと考えていました。
4回生で研究室配属があった際に同様の話を教授にすると、
「やりたいことがないなら、一回本気で何かに取り組んでみるといいよ」
とお言葉をもらい、
悩んだ結果、C言語を1ヶ月独学で勉強し、簡単なコンソールで動くゲームを作ることにしました。
プログラミング自体は、学部2回生の時に授業でFortranを触ったことがあるのですが、
- ゴリゴリの数値計算の練習をするだけで、実際にどう使われるかのイメージが沸かなかったこと
- 教授の授業スピードが早すぎて取り残されたこと
の思い出しかなく、プログラミングに苦手意識を持っていました。
しかしどの道研究で少しプログラムを読む必要があったのと、1ヶ月本気でやるのであれば苦手を克服できるかも、と考えてプログラミングを選びました。
いざ初めて見るとキツいのなんの。 独学でやろうと言っても何から始めたら良いかわからないし、図書館で借りたC言語の分厚い本は読みづらいし、1つのエラーで3日間一生悩んでたり...
ただ、エラーを解決できた時や、コードが一発で動いたときの快感は、これまでに感じ得ないほどでした。
やりたいことが全くなかった自分はここで、エンジニアのことをもっと知りたいと思うようになりました。
ちなみに当時作ったRPGチックなゲームがこれです笑
勇者が歩いて魔王の前でスペースを押すと、ランダムな技で攻撃するという単純なゲームです。たしかDXライブラリ使った気がする。
9月
9月後半までは、卒論のテーマが決まったり、院試があったりでプログラミングに手を付けられていなかったのですが、 7月くらいにY社のインターンを受けて落ちています。
「C言語を触ってみてプログラミングの楽しさを感じた」程度のほぼ知識がない自分は、なんとなくインターンを探し、なんとなく名前のカッコ良い
データサイエンティストのインターンに申し込みました。
余裕で落ちました。
しかし、参加できなかった人も懇親会（会社説明会）に参加することができたので、夜行バスで東京まで行ってきました。
すると、参加できなかった人の中でも個人でアプリを作っていたり、研究でゴリゴリ開発している人が多く、
を感じました。
よーし、もっと調査して頑張るぞと思ったきっかけでした。
2019年
#2019年を振り返る
— ほりす (@hohohoris) December 31, 2019
1月: 卒論と並行でAndroid始める
2月:ひたすらudemy
3月:Life is tech!入る
4月:基本情報技術者試験合格
5月:初のAndroidアプリリリース
6月:逆求人参加
7月:阪大休学届出す
8月:CA Tech Dojo最優秀賞
9月:リブセンス/Team Lab
10月:JOB/CA参加
11月:eureka
12月:Webに手を広げる
1月：卒論と並行でAndroid開発を始める
前述のようにプログラミングにはまってから、材料系の研究に関しての興味よりもエンジニアへの興味が大きくなっていきました。
そこで、卒論と並行して、Androidアプリ開発を始めた頃です。 本格的にプログラミングを始めたのもこの時期からです。
なぜ、Androidを始めたかというと理由は3つあります。
半分偶発的、半分戦略的ですね(笑)
侍エンジニア塾の無料相談とか、他のプログラミングスクールもみてはいたものの、学生の自分に払える金額ではないことや、独学でも学べるサイトが多くあったため、スクールにいくという選択はしませんでした。
2月：ひたすらudemy
卒論は気合で2月中旬までに提出して、この時期はひたすらUdemyをこなしていました。
Fortranや研究でのJavaのように目に見えない数値計算よりも、独学で作成したような視覚的に結果が出る作品を作りたかった当時は、実際にアプリを作りながら学ぶ講座を受講しまくっていました。
https://www.udemy.com/course/java-android-complete-guide/
ひたすら写経、手を動かし、アプリをつくる。
英語でしたが、テキストベースの教材やサイトよりも圧倒的に情報量が多く、体系的な知識を得ることができたと思います。
3月：Life is tech!に入る
自分の学科ではWeb系のプログラミングに勤しんでいる人は皆無に等しく、1人で細々と開発をしていました。 1人でも開発はできるのですが、開発仲間や環境が欲しいと思っていました。
そんなときに、TwitterでLife is tech!のメンターを募集していると聞きました。 Life is Tech !は、中学生・高校生向け IT・プログラミング教育サービスです。
これがめちゃくちゃ楽しそうで。 この、プログラミングの楽さを、ITの可能性を中高生に知って欲しい。 自分が気づくのが遅かった分、楽しさに触れられる環境を提供する側に周りたいと思い、メンターになるべく申し込みをしました。
小中学生の頃、青少年センターでよくカウンセラーさんにキャンプに連れて行ってもらったり、大学時代にカウンセラー側をやっていた経験から、どうすれば楽しんでもらえるか、リスクヘッジの仕方はある程度分かっていて生かせそうだし。
実際、かなり良い環境でした。
中高生にITを教える側として恥ずかしくないように、メンターも基本的なITスキルを身に付けられる研修がありました。
ITスキルだけでなく、ファシリテーションや、タスクマネジメントの知識も得ることができたのはすごく良い経験だと思っています。
そして何より、高いITスキルを持った先輩、同期にかなり刺激を受けることができました。
個人アプリを何個もリリースしている人、バリバリ企業でインターンをしている人、フリーランスとして仕事を受注している人等...
たまに、環境型人間にはなるなと耳にすることもあるのですが、上振れする環境、コミュニティは本当に良いものだと思います。
最近はあまり貢献できていないけど、2週に1回スクールでAndroidを教えています。 入ってよかったと思えるインターンです。
年に1度メンターの募集があるので、興味のある方は是非。
4月：基本情報技術者試験合格
2018年12月にITパスポートを受けた続きで、基本情報技術者試験も定期的に勉強していました。 特に資格が欲しいとかそういった意味ではなく 情報系学部ではなかったので、基礎知識をつけるための勉強でした。
やっほい合格😇
— ほりす (@hohohoris) May 22, 2019
まあこんなことしてる暇あればプログラミングしろってな#基本情報技術者試験 [pic.twitter.com/0Q0PGEF1iQ](http://pic.twitter.com/0Q0PGEF1iQ)
もちろん、同時並行でAndroidアプリ開発の学習もしっかりしていました。
4月はそれくらいかなー。 大学院に入学して、授業が忙しくなってきたくらい。 ちなみに大学院からは、同じ研究室で授業は"経営・マネジメント"を学習しつつ、専攻は材料系になりました。
5月：初のAndroidアプリリリース
5月は初めての自己作品である「乾かすちゃん」のAndroidアプリをリリースしました！ネーミングセンスは見逃してくださいw
※5月から全くアプデしてなかったらGoogleに消されてた... また改善してリリースし直すかは検討中。
付き合っている子向けに、 "ドライヤーで髪の毛が乾かすのが面倒くさい" という課題を解決すべく、ドライヤーの風(音量)を使った簡易的な育成ゲームを作りました。
色々相談に乗ってくださった先輩メンター、同期には感謝です。
今後の逆求人やインターンで大活躍してくれたアプリなので、感慨深いなあ。
ただFat Activity/Fragmentかつコードもぐちゃぐちゃなのでいつかリファクタしたい。
といいつつ5億年が経過した。
6月：逆求人参加、インターン申し込み
逆求人イベントがあったのは厳密には5月25日なのですが、まあきりが良いのと、逆求人とインターン面接をくくったので6月にしました。
逆求人に関してはさくっとブログにまとめているので、興味のある方は下記リンクから。
逆求人に参加していたベンチャー企業で、Androidエンジニアとしてインターンできるチャンスがありました。
その企業は、インターンといえども 即戦力を求めているため、中途採用向けのAndroid課題を受けることになりました。
社風や人もかなり惹かれるものがあり、必死に2週間食らいつきましたが、落ちました。
当時設計パターンやJetPack、Retrofit等の便利なライブラリ群を何も知らなかった自分は、課題の雛形すら理解できませんでした。
その経験がかなり悔しく、挫折しかけました。
ですが、逆に良い経験でもあり、今後のAndroidエンジニアとしてのロードマップをその課題から見出すことができましたし、
2週間ひたすら勉強して試して失敗してを繰り返した結果、
成長するために必要なのは"時間”ではなくて"濃さ"だと気付きました。
失敗から学ぶことって大きいなあ。
7月：大阪大学を休学
6月の挫折しかけた経験から、自分の未熟さに気付き、まだまだ色々なことを身を以て体験したい、Android開発したい、インターンしたい！と思うようになります。
しかし、それをするには時間が全くたりません。
特に前者2つがかなり重くて、とてもじゃないけどこの5つを両立させつつ、Androidエンジニアを目指すのは無理だと悟りました。
自分はそんなに器用じゃないので、1つのことに全力で力を注ぐ道を、つまり大学院を一度休学する道を選びました。
アルバイトも辞め、逃げ道を塞ぎました。
夏のインターンを経て成長し、並行して東京での長期インターン を探そうと、決意しました。
不安要素も山ほどありましたが、楽しみのほうが勝ってましたね。
正式な休学は秋学期の10月から。 フライングで8月から東京でインターンをしだしたので、実質8月からの休学です。
親はやっとやりたいことを見つけられたことから、快諾してくれましたが、
教授の説得が厄介でした。
結局、修論のテーマをインターン先で探してくるという体で休学を許してもらいました。 正直この段階で、もう研究室に帰る気はほぼなくなりました。
7月でした。
8月：CA Tech Dojoで最優秀賞
8月はひたすらインターンをしていました。めちゃくちゃ楽しかった笑
**
- 7/31~8/4：Life is tech!
- 8/6~8/16： CA Tech Dojo（サイバーエージェント）
- 8/19 ~ 9/13：プロダクトエンジニア養成講座（リブセンス ） **
それぞれの詳細はここでは書きませんが、一部下記記事にまとめているので、興味のある方は是非。
1番印象に残っているのが、CA Tech Dojoです。 初めての企業インターン（Life is techはメンターのため別枠）で、結果を残せたのはものすごく嬉しかったし、そこで得た学びと人脈は今でも自分のエンジニア人生の糧になっています。
9月：リブセンス/Team Lab
リブセンス 上記の記事にも書いていますが、リブセンスではプロダクトエンジニアとしての働き方を体験しました。
自分は、「乾かすちゃん」が全くスケールしなかったこと等から、プロダクトを成長させることができて、尚且つ自身でもコードを書けるエンジニアになりたいと思うようになっていました。
0→1での事業企画や、既存のサービスでより良いユーザー体験を届けるための施策を考えたり...
Team Lab ここで、初めてAndroidの実務インターンに参加しました。 書く時間がなく、インターン参加記は書いていませんが、すごくためになりました。
大きな規模の受託開発企業は初めてで、立ち上がってから2週間目の案件に参画しました。
2週間という短い期間の中で、独学でと実務の差を体感することができました。
メンターさんが気さくで話しやすく、毎日インターンに行くのが楽しみでした。
10月：CA Tech JOB参加
こちらも、インターン参加記を書いているので、興味のある方は読んでみてください。
5倍成長しました。
11月：eurekaでインターン
Nowなインターンのeureka。
Pairs JapanのAndroidアプリの開発に参画させていただいています。
また、インターン期間が終わった際に参加記を書こうと思うのでここでは簡単に...。
eurekaはビジョナリーな人が比較的多いイメージで、コアプロダクトに関わる人数が多い分、全社的に一体感があるなと感じました。
そんなプロダクトへの熱量を持ち合わせつつ、エキスパートとして高い技術力を持ち合わせるエンジニアの方も多くいて、インターンしながらすごく刺激をもらえています。
12月：Webにも手を広げる
これまでずっとAndroid開発のみを行ってきて、
「なんかしらんけど動いた、やったね」
のフェーズでした。
RetrofitでGETをしてみたけど、これがどいういう機構で通信しているのか、そもそもRESTAPIってなに、とか。
Web開発に関しての基礎知識が圧倒的に足りない状態でした。
Android開発も続けつつ、Web開発にも手を広げて点と点を線で繋ぐフェーズに入ろうと思い、
巷で流行っている"N予備校"をはじめました。
恥ずかしい話、ここで始めてJavaScript触りました(笑)
今までよくわからず使っていたLinuxコマンドやWebの仕組みを知れたり、言語そのものの学習にすごく良い教材だと思います。
おわりに
さくっと振り返ってまとめよう〜〜と思ったのに結局10000字近く行ってしまった...笑
本当に色々な経験ができた1年でした。
来年も充実した1年になると良いなあ。
それではみなさん、良いお年を！
【CA Tech JOB】CA Tech Dojoからの成長
ほりすです！例のごとくインターンに参加してきたので、振り返りブログを書いていきます。
はじめに
今回は、CA Tech JOBというインターンに10/3~10/31まで参加してきました！ www.cyberagent.co.jp
以前、CA Tech Dojoに参加した記事を書いたのですが、JOBは同じ株式会社CyberAgentが開催しているインターンです。
両者を簡単に説明すると、
Dojoは2週間で課題のAndroidアプリを1人で作りきるという「養成型」だったのに対し、JOBでは事業部や子会社に配属されてエンジニアとして実際にプロダクトを開発していく「実践型」です。
Dojoが始まった際のヒアリングで"Jobに行きたい"と伝えていたのですが、念願のインターンに参加できて感無量です。
通常であればDojoの次にCA Tech Challengeというハッカソン型のプログラムもあったのですが、日程が合わなかったので参加できませんでした...
他のJob生も振り返りブログを書いていると思います。 そこで少し他の人と差別化を図るためにも、 DojoからJobに参加した自分ならではの視点で振り返りブログを書いていければいいかなと思います。
CA Tech Dojo〜CA Tech JOB参加前
Dojoは、基本的にはプログラミング経験は割とあるけれど、あまりAndroidアプリをやってこなかった人向けに開催されたものでした。
自分は、これまでAndroidアプリしか作ってこなかったものの、プログラミングをはじめたのが2019年1月中旬頃だったので約8ヶ月の経験しかなかった状態です。
Dojoでやったことの詳細は上記の記事から読んでいただければと思いますが、Kotlin/Androidの基礎は比較的わかっている状態だったので、
・ Kotlin Coroutine
・ Dagger2
・ Room
・ Navigation
・ ViewModel
・ LiveData
etc...
の、Googleが推奨している設計であったり、ライブラリをはじめとした技術を「使ってみて」アプリを作りました。
メンターさんのサポートもあって、最優秀賞を取ることができたのですが、この時点で自分に足りないものも多くあるなとも感じていました。
- チーム開発
- PRで議論したい
- Gitを使いこなしたい
- 他の人のコードをみながら吸収したい
- 実務経験
- 上記のライブラリを「使ってみた」だけではなく、より高度な次元で使いこなせるようになりたい
- 効率的に開発するためのツールや設計、実装方法を知りたい
- サービス志向の考え方
- 実際にリリースするプロダクトのユーザー体験向上に貢献したい
つまり、1人ではなかなか達成できないようなことに挑戦したい欲がでてきていました。
これらの自分の足りないところを自覚することができたのもDojoでの良い収穫だと思っています。
CA Tech JOB
やったこと
自分は、Androidエンジニアとしてメディア事業部でJOBをさせていただきました。
メディア事業部にはAbemaTVやマッチングエージェントなどの子会社がそれぞれの事業を展開しています。
その中でもCATS(CyberAgent Advanced Technology Studio)という、いわゆる新規事業開発部署に参画しました。
新規事業開発部ということもあり、今回手がけたプロダクトも例に違わず口外禁止です。
そのため、サービス面よりも技術面、なおかつコアでない部分で習得したところを書いていきます。
新規事業ということもあり、100％Kotlinかつ、しっかり考えられたモダンな設計/技術選定がされていてかなり勉強になりました。
学び
個人では体験しづらい技術やツールに触れることができた
固められたCI/CD
これまで個人で開発してきて、CI/CDの概念などは聞いたことはあったものの、使ったことはありませんでした。
pushしたときやmergeされたとき等、多くのCIが走り、ビルドやテストしてくれる便利さに感動しました。
さらにCATSでは独自でスクリプトを作成し、複数のAndroid端末でスクリーンショットを撮り、その差分を元にCIを走らせることもしていました。
.config.yml
も一通り読んだので、個人で開発するときにCIの構築をしてみようというきっかけにもなりました。
「このスクリプトどういう意味ですか？」
とメンターさんに1聞くと5くらいの回答が返ってくるのも控えめに最高です。
Kotlinスクリプト
普段、Androidで開発する際はライブラリ等の依存関係をまとめるのにGroovyを使用すると思います。
が
CATSでは、KotlinスクリプトでVersion管理をしていて、
「こんなこともできるのか...」と関心の嵐でした。
マルチモジュール
今までは、デフォルトのappモジュールに全ての機能を詰め込むような、いわゆるモノリシックな構成での開発しか経験はありませんでしたが、初めてマルチモジュールに触れることができました。
サービスの特性に沿ったモジュールの切り方をしている部分を触る実装があり、結構苦しんだ。
複雑なDagger
Daggerは上述した感じでDojoで「使ってみた」程度だったので、実務でのDaggerの複雑さ、絡み合うDIに触れることができて良い経験。
ただ、最初結構苦しんだ。
DataBinding等のキャッシュいたずら🎃
Android StudioをStableでないVersionを使っているのが原因なのかわからないけれど、branchにcheckoutするとDataBindingやDaggerのキャッシュが残ってしまってビルドができないことがあった。
Clean Buildも聞かないので、
rm -rf ~/.gradle/cachesでglobalのキャッシュを綺麗にする必要がありました。
ビルド待ち時間でPRみれたりしたけど、めちゃめちゃ長かった...。
これも結構苦しんだ。
個人レベルでも活用できそうな技術に触れられた
前述のツールや技術は、なかなか個人でするのにはハードルが高い部類ですが、もちろん明日から活用できそうな技術にも触れられました。
- Arrow
- 関数型プログラミングライブラリ
- Try
- Option
- Test
- テストを書くタイミング、意味、書き方
- 個人ではほとんど書いたことがなかったけれど、Unitテストくらいはガンガン書いていこう
- Epoxy
- 色んなViewTypeのレイアウトを組み合わせてRecyclerViewに表示できる優れもの
- Paging
- 小さい単位でデータを取得してリストに表示する
- Protocol Buffers
そのほかにもDojoで使用したライブラリのより高度な使い方を知ることができた。
知って終わりじゃありません。
手を動かすまでが学習です。
というわけで書きました！ 初Qiita！
技術のキャッチアップをするために一つサンプルアプリを作ってまとめてたら知らないうちに卒論の分量超えてました。
チーム開発
自分の専攻は「材料系&経営」で自動車の材料強度の研究をしていたため、周りにWeb系の開発をしている人が1人もいませんでした。
9ヶ月目にして初のチーム開発、楽しみでした。
PRレビュー最高
PRレビューは、自分の中で勝手に怖いイメージがありました。 （良さそうと思って書いたコードに厳しい口調で修正を命じられるような）
心配とは裏腹に、すごく丁寧に優しい口調でレビューをしてくださり、かなり勉強になりました。
少ない変更のPRでもめちゃめちゃアドバイスいただきました。
ほかにも、チームの方のPRやコードを見るだけでもかなり多くを吸収できたと思います。
git最高
正直これまでgitは、branch切ってadd、commit、pushくらいしか使ってこなかったので、実践的に使うのはここが初めてでした。
（個人開発だとする機会なさめ）
一番の収穫としてはrebaseの悦びを知れたことですね。
commit履歴が綺麗になると幸せな気分になりますね(?)
これも、知って終わりじゃありません。
アウトプットするまでが学習です。
というわけで参加してきました。mixi git challenge
まだ、ブログはかけていないのですが、このイベントもすごく濃い1日でした。
こんなの知るかって内容から、ちゃんと考えれば解ける問題まで幅広く用意されてあり、gitへの造詣が少し深まりました。
ペアプロ
厳密にはペアプロではなかったですが、1日30〜60分時間をとっていただき、メンターさんに質問をしたり実際にコードを書いているところを見せてもらったりしました。
この時間、かなり良くて、
・緊急ではない疑問を聞ける時間
・人がやっているところを見て吸収できる
という点で有用だったと思います。
今後自分がメンターをする機会があればこのような時間を設けようとすら思ったくらい良かったです。
自分は基本的には今まで色々デフォルトで突き進んできたのですが、メンターさんが使っていたiTermやzshを使うようになりました。 そしてvimmerへの道も歩み始めましたw
今まで知らなかったことを知れる機会、無知の知を自覚してそれを吸収できたのは自分の中ではかなり大きかったです。
日常生活
毎日いろんな社員さんとランチに行きました。
1人で食べた日は1回もなかったくらいです。
そしてほぼ財布も開いたことがなかったです。
渋谷近辺の和食/海鮮にたくさん連れて行ってもらって幸せの極みでした。
メンターさんや人事の方にセッティングしていただいたのはもちろん、自分で社内のAndroidエンジニアの方を誘ってランチご一緒していました。
せっかくのなので自分から動いて機会を作っていくマインドは大事かなと。
他にも11Fのカフェドリンク無料券もらったり
終業後にスマブラに誘っていただいたり
（自信のあるネスで行ってボコボコにされた）
渋谷のマンスリーマンションを手配していただいた経験はすごく貴重でした。
(ハロウィンが被って地獄絵図だったのは置いといて)
Dojo→JOB
人生で初めて参加したインターンがDojoでした。
Dojoでは、
・自分が書いたコードをプロのエンジニアの方にレビューしてもらえること
・定められた要件に沿ってしっかりとアプリを作りきること
・個人開発ではあるけれど、時にはチーム/他のインターン生と助け合って行くこと
・CyberAgentの社員の方々の温かさ
を体験することができました。
Dojoで、自分の弱点/足りないものを知り、そしてCAの採用の本気さと人の良さを知りました。
そうすると、その次には
自分の弱点を埋めたい、どこまで通用するかを知りたい、技術力の高さを体験したい、もっとつながりを増やしたいと思うようになりました。
JOBは、上記の欲求を全て満たせる最高の環境だったと思います。
そしてこれらの欲求はDojoに参加していなかったら、気づくのはまだ先だったかも知れません。
養成型→実践型の順に体験したからこそ早く気づくことができましたし、環境を提供していただくまでの早さもさすがCAという感じでした。
JOBに参加した結果、
・知らなかったことを知ることができた（無知の知を自覚）
・より高度な技術に触れ、使用する機会を得た
・ランチを通して縦横のつながりができた
・5倍成長した
・今後の自走スピードが格段に上がった
というように、Dojoで得た知識や考えを実践で生かし、さらにそこで見えた課題に対してのアプローチ方法を学ぶことができました。
自分的には、今後自走していくために何をするべきか、どうしていくかを吸収することができたのが1番大きいかなーと思っています。
1ヶ月間本当にお世話になりました！！
リブセンスのプロダクトエンジニア養成講座に参加してきた
2019.08.19~2019.09.13の約1ヶ月間、リブセンスのプロダクトエンジニア養成講座（Android）に参加してきました！
プロダクトエンジニア養成講座は今期が初の試みとのことで、1期生になってきました。
今回の取り組みや感想を自分が発信して、そのリアクション等で来年以降も開催するか検討されるそうなので気合い入れて書いていきます（笑）
はじめに
この1ヶ月をスライドにまとめたものがあるので、是非先にそちらもご覧いただければと思います。
リブセンス プロダクトエンジニア養成講座(speakerdeck)
このブログでは、上記のスライドに沿って内容を整理し、1ヶ月間で行ったことやその感想を書き連ねていきます。
リブセンスについて
リブセンスについてご存じない方へ向けて簡単に紹介します。
リブセンスは2006年設立で、現在は従業員数約400名（内正社員約290名）の、中堅ベンチャーです。
このロゴが特徴的ですね。
このロゴには2つの意味があり、
1.徹底：この雫は「雨垂れ石を穿つ」を象徴しており、継続の大事さを表しています。
2.発想：物の見方を象徴しており、様々な角度から見ることの大事さを表しています。
インターン初日に聞いた時には「考えられてるなあ」と関心した記憶があります。
また、リブセンスは世の中の課題の解決にビジネスで取り組んでいる会社で、課題解決ドリブンな社風があります。
こういったビジョンを掲げているところからもその風潮が伺えます。
Vision
あたりまえを、発明しよう。
私たちの事業は、社会の問題や日常生活の中にある「？」が起点です。だれもがあたりまえだと思って諦めている世の中の常識や仕組みを疑い、課題の本質を見極め、テクノロジーを駆使して解決していく。そして、新しいあたりまえとして定着させていくことが、私たちの事業が目指すビジョンです。
多くの事業を立ち上げてクローズするような事業戦略ではなく、1つ1つにじっくりと取り組み、課題の根底をテクノロジーで覆していく堅実なイメージがあります。
とはいえ、スライドにも出てきますが、堅実ではあるけれど中堅ベンチャーならではのスピード感で意思決定はされるので、リリースの頻度が高かったり、PDCAをうまく回している会社でした。
事業ドメインは設定していないそうですが、現在は主に「人材」と「不動産」領域にサービスを展開されています。
特に人生の節目になる「仕事」と「家」の課題にフォーカスしているのだと思います。
エンジニアはあまり使わないかもしれませんが、学生間で馴染みがあるのは就活会議だと思います。
企業に関するインターンや面接の口コミが見れて、同サイトから説明会等のイベントも応募できるようなサービスです。
自分は学部生の時は材料系で、メーカー等を見ていたこともあり、何度かお世話になっていました。
ここで全て紹介するのは難しいので、簡単な概要をお伝えするに留めます。
詳しくは公式ホームページをご覧ください。
プロダクトエンジニア養成講座
概要
プロダクトエンジニア養成講座のサイトは冒頭にリンクを載せましたが、その中でプロダクトエンジニア養成講座の目的は以下のように記載されています。
せっかく知識を得ても、金銭的・時間的・地域的などのさまざまな理由から、在学中に不特定多数のユーザーに使ってもらうような実践的な経験を積めない学生もいます。
「プロダクトエンジニア養成講座」では、自分の持つ知識を利用しながら実際のWebサービスを開発する過程に携わり、プロフェッショナルなエンジニアになるための学びの機会を提供いたします。
1ヶ月間の経験を踏まえて要約すると
「独学や学校の授業である程度知識を蓄えている学生に、体系的かつ実践的な現場の知識をつける場を提供していただける」
だと思います。
「プロダクトエンジニア養成講座」という名前なだけあって、ここでいう「現場の知識」は技術だけと言うわけではなく、事業を創造する際の企画から、事業を育て上げるために施策を練る等までのビジネス側の知識も含まれます。
この養成講座の応募資格が、
1.在学中
2.プログラミング経験のある人
の2つのみで、プログラミングテスト等のコーディングはありません。
なので、応募してくる学生の現段階での実力に合わせて学びの場を提供してくださる感じですかね。
受け入れ人数はモバイルとWebそれぞれで1~2人（今回はAndroidは自分1人、Webは2人）なので、ここからも一人ひとりに手厚いプログラムがあるのは想像がつきます。
まあ、なにが言いたいかと言うと、実務未経験の初心者エンジニアでも受かる可能性はあります。
大事なのは実際に手を動かしているかどうかだと思うので、是非また開催されることがあれば応募してみるのもありだと思います。
時給が発生して、交通費や宿泊費も提供があり、現場のプロに質問ができる環境で学べたので、至れり尽くせりですごく良い経験でした。
4週間の流れ
何をしたかのざっくり流れです。
1週目
・リーダーのMTGに一緒に参加して体感。
◦ついていただいていたリーダーが主に人材系のアプリ3つを担当していらっしゃったので、同席して雰囲気を体感。
◦数字や施策面の詳細は1ヶ月で理解できることではないので、それぞれの役職の方が何を意識して話しているか、現場の流れを特に注意して見るようにしていました。
・Androidアプリ開発の基礎を復習
◦これに関しては人によります。社員の方も「どれくらいできるインターン生が来るかわからなかったから、自由にinputしてていいよ」と言っていたので自由でした。一応Androidの勉強の仕方や参考リンクをまとめていただいたものがあったので、codelabsをやったり基礎の復習をしていました。
◦他には、設計に興味があったので有名なサイトを写経したり、社員さんの私物のAndroidテスト全書を読んだり。
◦input時間も時給は発生していたので申し訳なかった...。
2週目
・1週目と同様のことをしつつ
・新規アプリの企画を考える。
◦会社は関係なく、自身で0-1を考えるフェーズ。
3週目
・フィードバックをもらい、実際に開発
◦3度修正してから1〜2画面を実際に自分なりの設計で作成してみる。
◦今回は勉強という意味も含めてMVVM+Clean ArchitectureにAACやDIを盛り込んだ結構ボリューミーな実装に挑戦。
・せっかくフィードバックもらえるのでチャレンジ精神大事。
・実際はプロダクト内容やリリース期間、チームの人数などを考慮する必要があります。
・プロダクトコードを見せてもらい、現場レベルの設計、コーディングを体感。
◦Androidアプリのリポジトリを見せてもらいました。
4週目
・実装しつつコードレビューをしてもらった。
◦実際にプルリクを投げて社員さんにレビューしてもらった。
学んだこと/感想
MTG
・デザイナー、ディレクター、エンジニアの深く、説得力のある発言が多かった。
◦なぜ右上にこの形のボタンを配置するか、この項目でアンケートをとって何を得たいのかなぜその項目なのか、など、発言の一つひとつにしっかりと意見を持って、理由を聞かれたら説得力のある答えが返せていた。
◦深いからこそ、お互いの意見を譲れないときもあり、意見の収束が難しそうだった。
・エンジニア/非エンジニア双方を理解するプロダクトエンジニアが間に入って収束へ持っていくイメージが湧いた。
・どうすれば「ユーザーが使いやすいか」を追求して議論していた。
◦課題解決ドリブンな社風が出ていた。
◦なんとなくや、とりあえずでリリースせずに堅実に検討。
◦とはいえ中堅ベンチャーならではのスピード感もある意思決定がなされていた。
アプリ企画
・0-1でプロダクトを作り上げるステップを学んだ。
◦様々なFWがあり、その一部を実践した。
・デザインスプリントやカスタマージャーニーマップ等、複数あるFWをきっちり使ったわけではないが、かいつまんでstep by stepで企画を作り上げていくフローを知れた。
◦リーンスタートアップのMVP（Minimum Viable Product）の考え方で、徐々に拡大していくやり方を身につけた。
・これまでは初めから大きくしようとしていたが、必要最低限の実装をしてから徐々改善を繰り返して拡大していくことができた。
・アプリGの方々からのフィードバックをもらった。
◦機能面だけではなく要件面も具体的なフィードバックをもらえた。
・普段1人だと盲目的になることが多く、良い経験でした。
◦コードをかけるだけがエンジニアなのではなく、実際の利用シーンを想像した上で最適な、ユーザーが使いやすい機能や要件を提案できるのがエンジニアだと感じた。
開発
・実際のプロダクトコードを見せてもらって感動。
◦作成途中ではあるが規模の大きいコードを見ることで設計や 細かいコードの記述面で参考になることがたくさんあった。
・プルリクはコミュニケーションの場
・コミット粒度もコードの書き方もコメントも、レビュワーやメンバーが読みやすいかを意識する
◦個人開発は自分が読めればいいし、自分が書いているのでコードを見るだけでやりたいことがわかるけど、チームは気をつけることがたくさんある。
・プルリク初めてだったので学びが多かった。コメントいただいたところ15個を全て1つのcommitで再レビュー出したのは今思い出すと暴挙すぎて笑える（笑）
・1番、これから頑張ろうと思えたところでもあり迷惑をかけたところでもあるので強調しています。
日常生活
・人の良さ
◦互いを尊重して気遣える
・誰かが発言するときはしっかり聞き、否定から入らずに意見を尊重していた。
・転職してこられた方が、育休をとると周りに言った時に「おっいいね、しっかり休みなよ」と何人かに言われたのが衝撃だったという話を聞いた。これも相手のことを考えているからこその発言なのかなーと勝手に思っていたり。
◦常に和やかな雰囲気
◦休憩を挟んだり、残業しないように呼びかけたり
・リーダーの方がこれを実践していて、特に自分には休憩を逐一はさんでいるかをなんども確認されました。（あまり休憩できずにぶっ通しでやってしまうタイプだったため）
・常にメンバーが最高のパフォーマンスができるようにな環境を作っている印象をうけた。
・考えを押し付けず、個人が最高のパフォーマンスができるような環境を作っていた
◦（上述した内容と少しかぶりますが...）
◦「リブセンスで学んだことは1つのinputとして引き出しにしまうと良い」というのをすごく強調されていた。
・多くの引き出しを持っていることで、柔軟に対応できるから
・色々なやり方を学んでやりやすいやり方に気づけると良い
◦プルリクやslackでのアドバイスも「と思います」と、I視点なので受け入れやすい
・事柄や意見に対して決めつけるYou視点の意見しないことでコミュニケーションが円滑に。
・この1ヶ月を通してすごく働きやすかった
反省点
・もっと質問をすればよかった
◦コード面では初めの2週間でinput時間が多く、アプリ実装も大きな躓きもなかったため質問があまりできなかった。
◦独学でやってきていたため、ある程度のわからないことはググって解決しようとしてしまっていた。
・自力で検索する時間を決めて、それ以上調べてわからなければぱっと質問すべきだった。
・人に話すことで整理されて解決できたりするし。
・何をやろうとしていて
・どこまで調べて分かっていて
・何がわからないか を伝えると答える側もわかりやすい。
◦リーダーやマネージャー目線では、質問をしてもらったほうがその人の状況が把握しやすいとのこと。
・職の垣根超えての交流もすればよかった
◦エンジニア以外にも個性的な方がたくさんいたのでもっと話したかった...。
・次はコードかけるようになってプロダクトに貢献したい
◦今回は自分のプロダクトを0-1で企画して、プロダクトコードを参考にして実装した形だが、実務したい！！
◦タスク管理ツール、CI、フォーマッタ等、個人開発している中でなかなか触れられないようなツールも触ってみたかった。
総括
総括というか、この1ヶ月で特に学べた/収穫のあったことが3つあるので、それに関してまとめます。
深く考える癖
この記事の、「4週間の流れ」以降、・や◦を用いて出来事や思ったことを記載していきました。
これは、この1ヶ月感のインターンで1番身についた深く考える癖に繋げるためにこのような形で書きました。
インターン2日目、面接を担当されていた人事の方と1on1ミーティングをしたのですが、その時にこんな面接のフィードバックをいただきました。
堀くんは、無意識に目標を帰納的に決めているね
自分自身で深く考えるというよりは、過去の出来事や、他人の経験から「こうすれば正解だ」と目標設定をしている傾向があるとのことです。
これを言われてハッとしました。
たしかに、面接の時に学生時代に頑張ったことを聞かれて、1段階の深掘りには答えることができても、さらにその行動や考えに対して何故？と聞かれると答えにつまることがありました。
これは、自身の行動や意思決定を深掘りして振り返っていないからなのでしょう。
フィードバックをいただいて、自分の思考の浅さに気付かされました。
そのため、
行動や意思決定・思考に対して徹底的にWhy/Howを考える
を1ヶ月の目標として掲げました。
そして、実践したのがとにかく書き出すことです。
何故を深掘って考えよう〜ってなんとなく考えるのは自分は向いていないと思ったので、ひたすら書き出しました。
そのときに実践したのが、・や◦を使って階層化する書き方です。
この機能をつけよう と考えた時に1段階深掘って、自分の思考を書き出す。
1段階深掘った思考に対してさらに深掘ってもいいし、1番上の階層に対して、最初とは違う視点でブレイクダウンしていくのでも良いと思います。
そうすることで、プレゼンする時も自分の思考を追って説明でき、質問が来た時も一度思考を可視化しているので回答しやすいです。
このようにして、最終日の面談では、見違えたと言っていただけました。
さらに、
後輩人事の教育に同じやり方使ったら、深く考える癖がついてきた
とも言っていただけたので誇らしいです。
まだまだ考えながら話すのは難しいですが、
思考を整理してから話す
を意識するのとしないのとでは違うので、これからも書き出していこうと思います。
プロダクト作りのアプローチの1パターン
step by stepでアプリを企画し、実装する、リブセンスなりの方法を教えていただきました。
この1ヶ月実感したのは、1つの正攻法を教えていただいたのではなく、考え方という観点で多くのことを教えていただきました。
先ほどの深く考える癖もそうですが、何か成し遂げたい課題があったときのアプローチの仕方”の考え方”だったりです。
上述した
「リブセンスで学んだことは1つのinputとして引き出しにしまうと良い」
というスタンスだったので、これからも柔軟で応用の効かせたアプローチができるように実際の現場を見せていただけたのだと思います。
第3者からみた自分
これは、自分という大きなくくりを使っていますが、第3者からみたコードであったり、企画、最高のパフォーマンスができるペースなど、普段1人だとなかなか気づけないことに対して多くフィードバックをいただきました。
フィードバックに関しても、1つのinputとして受け入れて、自分のやりやすい方法を作りたいと思います。
さいごに
少し長くなりましたが、書ききれないことの体験をしました。
プロダクトをスケールさせられるエンジニアになりたいと思い応募したプロダクトエンジニア養成講座ですが、人としても深くなれたのではと思います。
リブセンスのみなさん、1ヶ月間お世話になりました！
あんざいゆきさん講演、Androidエンジニアの成長戦略に参加した
今回は、からくり株式会社さんにお邪魔して、あんざいゆきさんによる「Androidエンジニアの成長戦略」という講演に参加してきました。
caraquri.connpass.com
あんざいゆきさん
Androidエンジニアをしていれば、おそらく一度はお世話になっているのではないでしょうか。
これです。このブログです。
僕は何度もお世話になりました。
紹介 uPhyca Inc. 代表取締役社長。 Android のアプリつくったり、本書いたり、講演したりしてます。
GTUG Girls、droid girls マネージャー。
Google Developer Expert for Android
Suica Reader 作ってます。
「Master of Fragment」「わかる！ドメイン駆動設計 」という本だしました。
あんざいゆきさんのブログのプロフィール欄より
ここに書いてある、Google Developer Expert、通称GDEは、Androidに関しては日本で2人しかいないめちゃめちゃすごい人たちです。
Kotlin Festや、DoroidKaigiを初め、国内外のカンファレンスに登壇している実績もあります。
数日前のKotlin Fest2019もAndroid初学者に向けた講演をされていました。
kotlin.connpass.com
Kotlinの便利な標準関数のお話をする予定だったのが、リジェクトされてしまい、クライアントサイドの話がないなということでAndroidに関する話をされたとのことです。
そんな、雲の上のまた上の存在のあんざいゆきさんの講演があると聞き、詳細すらよく見ずにすぐさま申し込みました。
後々見てみると、先着順で８名の枠しかなかったので、かなり運が良かったです。
講演
当初はあんざいゆきさんをお招きするという社内イベントを想定していたそうですが、せっかくだからということで「Caraquri TechNight」として、少人数の一般公開してくださりました。
講演内容が「Androidエンジニアの成長戦略」。
メインターゲットはエンジニア初学者&&Androidエンジニア初学者~中級者を想定されているとのことでした。
全てを転載するわけにも行かないので、これいいなと思ったところをポイントで抜粋してご紹介しようかと思います。
あんざいさんがお話しされていた部分を中点(・)、自分の感想とかひとことを矢印（→）で書いていきます。
情報工学の基礎を身に着ける
・CSの知識があるとないとでは後の伸び代が違う
・基本情報技術者試験の参考書を一通り読めばいいと思う。
・過去問もあるが、基本は教科書として参考書を読むだけで良い。
→
自分も非情報系からエンジニアを目指し始めた時、プログラミングと並行して基本情報技術者試験受けました。
ここは賛否両論あると思いますけど、"資格をとる"ことが目的でなければ基本情報技術者の勉強をするのもありだと思います。
これを勉強するだけでプログラミングができるようになるとか、ないとダメだとかそういうことはないけれど、もっと全体的な"コンピューターとは"を知ることは大事かなーと。
Androidの中でも得意なもの、好きなものを見つける
・1人で全部詳しくなるのは現実的ではない。広く全体的にAndroidを把握しつつ、好きなものに力を入れるほうが良い気がする。
UI作るのが好き
・Viewに詳しくなろう(RecyclerView,BottomSheet,ConstraintLayout...)
・Animationに詳しくなろう(Animator,Transition,Lottie)
・style,themeに詳しくなろう
・DarkThemeがAndroid10から本格的に入るよ
・Material Designに詳しくなろう（MaterialDesignComponent）
・ノンデザイナーズ・デザインブック
・センスは理論である
・個人でアプリを作る時になぜアプリの画面がダサいのかがわかるかも
・誰のためのデザイン
・D.A.ノーマンの本はみんな面白い（CSの知識いらない）
→
勉強するためのライブラリやコンポーネント、本を提示していただけるのはすごくありがたい...。
なんとなくUIやってみたいな〜って言う人はこれらをやってみて極めるといいのではないでしょうか。
ロジックをごりごり実装が好き
・Android Test必要！テストなしにロジック好きは語れない
・Instrumentation Test/Unit Test
・Truth AssertJ…
・テスト駆動開発
・最初からテストを書く方があとからテストを追加するよりはるかに楽
・UIをTDDで開発するのは大変，ロジック部分はTDDを取り入れやすい
→テスト大事ってわかってはいるものの後回しにしちゃいがちなんだよな...これを機に勉強しよう。
設計が好き
・Google IOのソースコード読んでも良い、参考になる
・AAC(Android Architecture Components)を使わない選択肢はまずない．
・LiveData, ViewModelは必須
・NavigationとかPagingは必要に応じて
・WorkManager
・Push通知のレジストレーションIDをサーバーに送る時とか．
・Kotlin coroutine
・ほぼ必須
・RxJavaからどんどん移っていくと思われる
・DIコンテナ（Dagger, Koin，Kodeinなど）
・現場で役立つシステム設計の原則（ガチ設計の話）
・読みやすい
・DDDへの助走
・DDDというよりオブジェクト指向の話ではある．
・あんざいさん的に「むむ？これはどうなんだ？」というのがあるけどまあいいでしょう
・わかる！ドメイン駆動設計
・いきなりEric Evansのドメイン駆動設計を読んでも挫折する．
・Droid Kaigi2017のあんざいさんの講演を見る！
・あんざいさんのブログ記事から飛べるよ
・準備をした上で，Eric Evansのドメイン駆動設計
・何言っているかわからなくても一旦は読み進めてみよう
・実践ドメイン駆動設計のほうがまだ読みやすい
・サーバーサイドの話なので，クライアントサイドではなかなか活かせるか微妙なところではある
→設計は本当に奥が深いけど、言語への依存度は割と高くないから、設計に強くなれば他のプラットフォームでも活躍できると思う。
自分は設計をゴリゴリに強くなりたい感あるのでガンバルゾ。
アウトプットする
・未来の自分のために書く
・完璧を求めない
・求めてたら永遠に終わらない
・別に拙い言葉でもいい、だって未来の自分への備忘録なんだから
・他人の反応を期待しないこと
・すでに誰かが書いているから は，あなたが書かない理由にはならない
・他の人が書いたものよりも，あなたが書いたことの方が未来のあなたに役立つ
・すぐ書く！
→はい！すぐ書きます！今書いてます！
カンファレンス・ミートアップに登壇
・数をこなさないとうまくならない
・最初はLTとか時間んの短いもので挑戦する
・おしゃれなスライドより話の流れが大事
・何をどういう順番で話すのか
・話の流れが大事だよ
・スライドは理解のための補助
・コードを乗せるときは白背景にしよう（黒背景のコードは見づらい）
継続は力なり
・少しずつでいいので，まずは続けること
・続けるのは大変
＝大抵の人は続かない
＝続けるだけで差がつく
→これは真理。
ひたむきにひたすらコツコツ続けていたら、そのスピードに個人差はあるかもしれないけど必ずどこかで成果がでるはず...！
