こんにちは、中途採用担当のシェリーです！
いやー、ビールがおいしい時期ですね！
私はすぐ顔が赤くなってしまうのですが、飲むのは好きです！
今日は、8月23日にSansanさんの緑あふれたイベントスペースで実施したレポートをお届けします。
とっても素敵なスペースなので、いるだけでテンションあがります！
ハンモック、家に欲しい～！！
さて、イベントレポートです。
今回はこんなテーマで実施しました。
「Sansan×GMOペパボ」で活躍するモバイルアプリエンジニアの生態とは？！
イベント内容についてはconnpassページをご覧ください → こちら
Sansanさんとのイベント化は、今後もシリーズ化できればいいね、と話しており、まず1回目はモバイルアプリエンジニアをキーワードに、各社「中堅／若手」×「Android／iOS」が登壇しました。
今回はトークセッションもあるので、2回に分けてレポートしたいと思います！
まずは前半、登壇部分。
19時半、スタート。
1人目 Sansan： 坂本（@kazu0620）さん
2015年にSansanさんに入社、名刺管理システム「Eight」に所属されているiOSエンジニア。
後のトークセッションで知るのですが、双子のようです。
テーマ：「ひまわりチーム」のスプリントの流れ
スクラムについての説明のあと、チーム体制についてのお話。
事業部は昨日やKPIごとにチームが分かれていて、その中の「ひまわりチーム」に属しています。
アプリは6名いるけれど、チームに1人配属するには不足しているので、ひまわりチームに属しているとのこと。
スプリントは2週間で回すこととしていて、まずは事業部全体のリポジトリから優先順位順にチケットがあり、そのチケットごとに仕様を見ながらどのようにしていくか判断、見積もりを行います。
おもしろかったのが、見積もりをSlackチャンネルで行っている点です。
最大値と最小値を一斉に全員が出す、というもので、一斉に出すからこそ懸念点が出てくるといいます。
ポイント差に注目して議論していくことが大切とおっしゃっていました。
その後チームのバックログに移動、実行していくフローとなるのですが、ここでもユニークなSlack活用法がありました。
GitHubのIssueごとにSlackチャンネルがあり、そこで仕様や実装について相談して決めていくとのこと。
決定事項はPin留めしているので流れに追いつかないことはないのだそう。
テスト、部内でのお披露目が終わるとKPTで振り返るのですが、ここではスプレッドシートを利用しているようです。
他社さんのフローやツール活用法が知れるのはおもしろいですね！
1人目 ペパボ：黒田（@kuroyam）
2014年8月に30daysAlbum™ にジョイン、iOSエンジニア。
それまでは別の部署でゲームを作ったり、フリマアプリを作ったりしていました。
テーマ： アプリ設計改善の旅路
2015年にモバイル界隈で設計の話が盛り上がるようになってきたことにより、「おや、これは求めているところだ！」ということでやってみたけど、いろいろ不安が出てきたことから解決した話。
当時、形（手法）は持ってきたけど、役割についての認識の不足などがあり、大きな改善にはならなかったとのことで壁にぶち当たっていたものの、会社の別プロジェクトをみたら、RxSwiftが導入されていたり、同僚のエンジニアが激しくUnityを押してきたりと刺激があったので、やってみるかと思って進めてみたとのこと。
ここでよかったのは話せるエンジニアがいたこと。
いつもは事業部制で仕事をしているけれど、技術については横断して周りのエンジニアが助けてくれる環境があったので、乗り越えていけたようです。
社内での勉強会の開催もするようになりますが、人に説明するためには理解していないとできないので、かなり勉強したようですが、勉強することで誤解していたところが解けたことにより、コード修正がし易くなったり、楽になったこと。
そして何よりコードを書いていて楽しいと感じるようになったというよい話でした。
結論としては、
・形だけで導入するのではなく、目的をもったうえでプロダクトに会う設計を考える重要性や
・モバイルアプリそのものだけではなく、少しはみ出したと頃の技術からも学べることが多い
・アウトプットするためのインプット、そこから学びがあり質の向上にも繋がっていく
ということで、悩み、考え、勉強し、アウトプットする一連の流れを学ぶ旅はまだまだ続くよ、と締めくくられました。
そんな黒田の発表資料はこちら。
3人目 Sansan：新保（＠Keita Kagurazaka）さん
2017年入社（・・・に思えないSansanさんへの馴染み方！）のAndroidエンジニア。
KotlinのTシャツを着て登場。
スプラトゥーンがお好きでよくやっているということでしたので、ペパボパートナーは仲良くなれそうです！
テーマ： Androidアプリの開発環境（仮）
タイトルがなかったので、私が聞いた内容から付けてみました・・・！
新保さんは全社で人脈を共有する「Sansan」事業部に所属しており、Androidアプリのリニューアルプロジェクトを担当されています。
「ビジネスの出会いを資産に変え、働き方を革新する」とうミッションを軸にした開発を心がけているということで
・技術はプロダクトのためにある
・同様にプロダクトはミッション実現のためにある
というところから「ミッションの実現に必要な機能」「世界観」「ユーザーが望む機能」「ユーザー体験」のバランスを考えて開発されているとのことでした。
SansanさんはKotlinがgoogleの公用語になる前から採用決定をしていらっしゃり、勉強会も積極的に行っています。
Javaとは生産性が全然違う！ということで導入においては「ひとりでも詳しい人がいれば簡単」としており、難しければ部分的に入れていくのでも良いので対応していくことを推奨していました。
ミッションに立ちかえって「設計は本当に必要？」と様々な環境から検証することと、目的に見あった技術・アーキテクチャを選択しようというお話でした。
4人目 ペパボ：夏坂（@n_t_s_k_）
2017年入社、minneのAndroidエンジニア。
ペパボカレッジ2期生として入社したのですが、彼の前職はなんと営業！
そこから得たチーム開発についての話です。
テーマ： 元営業でもできるチーム開発～ペパボカレッジで学んだこと～
ペパボにはCTL（チーフテクニカルリード）という各事業部の技術責任をもつエンジニアがいるのですが、そのエンジニアから「チーム開発で重要なことは分かりやすいアウトプットをチームのメンバーに伝えること！」と言われ、
「分かりやすいアウトプット」という表現が既に分かりにくい！
なんで？
と思ったとのこと。
minneのサービスはエンジニアをはじめ、デザイナー、ディレクター、マーケティングやCSなどを含め70名規模で動いています。
サービスはチームで作るため、その最大化を図るには得意分野を活かす必要がある。
そして、そのメリットを活かすためには個人のアウトプットが分かりやすくないと難しいと言います。
アウトプットを理解し、理解してもらうことが大切ということです。
エンジニアにおいてはコードというアウトプットが分かり易ければ、レビューもし易いし、変更が簡単にできます。
分かりやすくするためには、テンプレートを使ったり、単位を小さくしたり、意図をしっかりすることが大切。
これらができることで、チームは高速で意思決定を繰り返すことができます。
元営業でも大丈夫！という話でした。
（経歴の補足をすると、夏坂は営業を辞めた後、アプリの勉強を行い、リリースから運用、改善まで一通りの経験を独学で行っていました）
夏坂の発表資料はこちら
各社の特色やユニークな話が聞けたトークセッションはレポート後半に続きます！