結果に git commit する

技術的なことはあまり書きません

CAmotionで学んでいるチーム開発で大事な7つのコト

はじめに

adventar.org

このエントリーは、CyberAgent 19新卒 エンジニア Advent Calendar 2018の1日目の記事です。

株式会社サイバーエージェントの2019年度新卒内定者として内定者バイトをしている僕が、内定者だけの子会社である株式会社CAmotionで、エンジニアとしてチーム開発をしていく中で学んでいることを残したいと思います。
エンジニア視点とはいっても、絶賛開発中ということもあり、具体的な使っている技術などの話はしません。

株式会社CAmotionで働いています

www.cyberagent.co.jp

現在、株式会社サイバーエージェントの2019年新卒内定者として、内定者バイトをしています。
働いているところは、19卒内定者だけで立ち上げた株式会社CAmotionという子会社です。
↑の記事に載っている4名が、選抜型インターンシップ「DRAFT」で事業を提案し、子会社を設立することになりました。

僕はサーバサイド・インフラを主に担当しています。
サーバサイドは僕含め2人、iOSエンジニアが2人、デザイナーが1人、そしてビジネスサイドが3人というメンバー構成になっています。

www.cyberagent.co.jp

最高の環境です

基本的に自分たちだけで仕様決定やサービス開発を進めていくので、何から何まで全部自分たちでやっています。

ですが、内定者だけの子会社とはいえ、サイバーエージェントの子会社であり、他のチームと同じビルで仕事をしていて、社員さんのサポートもあります。
インフラ、iOS、サーバサイドともに技術的な相談ができるメンターさんがついてくれています。
そのおかげで、サイバーエージェントの技術資産を利用しながら0からサービス開発をできて、とても有意義です。
実際に動いているサービスの技術や、もうクローズしてしまったサービスのソースコード、インフラなどを中心とした知見を容易に得ることができるのはとても助かっています。
そして技術だけでなく、ビジネスの面でも様々な知見を利用できていると思います。

また、メンバーが19卒内定者だけということもあり、とても仲良しです。仲良し最高。
そのメンバーがとても優秀です。自分ができない仕事を安心して任せることができています。

チーム開発で大事な7つのコト

そんな環境でエンジニアとしてチーム開発をする中で、学んでいることを話していきたいと思います。

ビジネス職、デザイナー職との仕事を通じて

まずは、ビジネス職、デザイナー職のメンバーと一緒に仕事をしていく中で学んでいることを話していきます。

①チームビルディングはとても重要

心理的安全性という言葉はときどきTwitterなどで見かけますが、心理的安全性が保たれたチームが一番生産性が高いそうです。Googleさんが言っていました。
ちゃんと理解できているかは分かりませんが、心理的安全性とは要するに「なんでも言える」ことだと思っています。
CAmotionでは、ビジネスサイドのメンバーが率先してチームビルディングをやってくれて、遠慮することなくみんな意見を言える雰囲気で仕事ができています。
これはサービスを開発・運用していく中でとても重要なことだと思います。
そして、チームに新しいメンバーがジョインするたびにチームビルディングの時間をしっかり取っているのもすごいことであり、重要なことだと思います。
どんなことをやっているかについては、いつかビジのメンバーの誰かがブログでも書いてくれると思います。

②仕様決めではエンジニア的目線でフィードバックする

サービスの仕様を決める際のエンジニアの役割は、仕様に対して技術的なフィードバックをして、技術とのギャップを埋めることだと思っています。
機能の仕様を考えるとき、どのようなエラーが起きうるかなどのエンジニア以外には馴染みのないケースを示して、想定していない状況が発生しないようにします。
そうすることで、ビジネスサイドやデザイナーには機能のコア部分をより良くすることに集中してもらうことができます。
ビジネスサイドやデザイナーが、技術的な考慮漏れをまったく不安に思うことなく進める世界にしていきたいですね。

③技術を知り、実装方法の幅を広げる

仕様と実装の工数との間にはギャップがつきもので、例えば2つの候補があり、仕様的にはそこまで変わらなくても工数が大きく変わったりすることは少なくありません。
その際に、仕様と工数を照らし合わせて、何をどこまでやるかをチームで決めていく必要があります。
ときには工数と相談して妥協(目的を変えずに手段を代替)する必要もあります。
そのとき、エンジニアが複数の選択肢を提示できたり、工数を正確に提示できたりすることはとてもプラスになってきます。
そのためには、エンジニアが日頃から様々な技術を知り、実装方法の幅を広げていくことが大事だと思いました。

エンジニアとの仕事を通じて

④お互いのタスクがボトルネックにならないようにする

複数人での開発では、互いのタスクどうしがボトルネックになることを避けることが大切なのはよく知られています。
さらに、僕たちは内定者なので、みんな大学があり、他のバイトをしている人もいて、出勤日が合うことがとても少ないです。
そのため、互いのタスクがボトルネックにならないようにできるかどうかがよりクリティカルになっています。
タスクの担当を振り分けるとき、お互いのタスクが依存しないように意識し、一方の手が止まってももう一方に影響を与えないことに注意して担当を決めています。

⑤並行して進められるタスクを選択する

とはいえ、いくら自分たちで依存し合わないタスクを選択できても、何らかの申請が通るのを待ったり、社内システムについての質問の回答を待ったり、なにかと外部に依存してしまうことはよくあります。
そのようなときでも、それ以外のタスクを進めて手を止めないために、依存し合わないタスクを個人が同時に担当するよう選択したりすることも重要になってきます。

⑥簡単なタスクも並行して進める

手を止めないことはとても大事ですが、頭を使いすぎると人間は疲れます。
そのため、簡単なタスクをところどころに挟んで脳を休ませることが大切です。
これは地味にけっこう大事で、こうすることで他のタスクの効率が上がったりすることがあると実感しています。
あと、ときには簡単なタスクすらやめて、休みましょう。
これもとても大事です。
特に僕はしんどいときはまじで何もしてません。

⑦誰が書いても同じコードになるアーキテクチャ

これはどのチームにも当てはまるものでもないですし、どんな事業にも当てはまるものでもありません。
ですが、僕のチームではフィットしているので紹介したいと思います。
サーバサイドでは、Go言語を使ってDDDライクのアーキテクチャに則って開発しています。
責務の分離や依存関係の明確化ができており、どこに何を書けばいいのか、迷わない状況を作ることができています。
そして、どう書くかもほぼ迷わないので、メンバーのコードが自然とほぼ同じになり、レビューのコストなどが大幅に削減できています。
詳しいアーキテクチャなどは別の記事に書きたいと思っていますが、責務の分離や依存関係の明確化ができ、チームメンバーがどこに何を書くか迷わないようにする、というアーキテクチャ選定の一番の目的を達成することは非常に重要だと実感しています。

おわりに

もちろんこれだけではありませんが、チーム開発で重要だと感じていることを紹介してきました。
今後はチームで使っている技術やアプリケーションアーキテクチャ、さらにインフラ設計・構築などの技術的なアウトプットもしていければと思います。

自分たちで新規サービス開発のすべてを行い、技術面でもビジネス面でもメンターさんを含めた社員さんにフィードバックをもらいながら開発を進められる、そんな素晴らしい環境での0→1の新規サービス開発に興味のある方がいらっしゃればお気軽にご連絡ください(特にCA19卒内定者)。

twitter.com

それでは、最後までお読みいただきありがとうございました。

明日は、CAmotionで一緒にサーバサイドエンジニアとして仕事をしている、

twitter.com

の担当です。お楽しみに。