【Quipperブログ】Quipper 社内留学体験記

こんにちは。Quipper採用担当の鈴木です。今回の記事は、@masaki925による「Quipper社内留学体験記」です！是非、ご覧ください！

こんにちは、@masaki925 です。

今年の4月からQuipper のデータプロダクト開発グループ(以下、データチーム) にジョインしており、今回が初投稿となります。

今回は、とあるプロジェクトにおいて私が体験した約1ヶ月間の社内留学についてご紹介します。

なお、入社1ヶ月後にすぐ社内留学というややアクロバティックな動きにより、入社の感想と社内留学の感想がやや混ざっていることは予めご了承ください。

もくじ

• はじめに
• 経緯
• 社内留学の枠組み
• 印象に残ったエピソード
• • 初日から渡りに船
  • 思い立ったがペアプロ日和
  • 留学先に貢献できていないモヤモヤ感
  • 領域横断機能の困難を物理で殴る
• 無事リリース
• 改善点は、「時期」と「比重」
• まとめ

はじめに

先にこの話のポイントを挙げておきます。

• 社内留学しなくてもプロジェクトの推進はできたが、やって良かった/悪かったこと とは？
• 社内留学するだけでうまくいくわけではなく、それをドライブする文化とは？

想定読者は、下記です。

• 機能横断性のある組織を作っていきたいが、どう進めていこうか考え中
• Quipper という会社の文化・価値観に興味がある

以下、エピソードを交えて紹介していきます。

経緯

データチームではスタディサプリのデータを活用した機能開発を行っていますが、開発した機能をなかなかプロダクトとしてリリースできない課題がありました。

その要因の1つとして、プロダクト開発チーム (以下、ToC チーム1) は限られたリソースの中で短期的に解決しなければならない課題が多く存在しており、データを活用した機能のように「あったら嬉しい」(重要度は高いが緊急度は低い) ものの優先度が上げられないことがありました。

またこれまでのデータチームの体制は分析基盤の開発運用に寄っていたため、プロダクトのリリースまでは手を伸ばしづらい状況でした。

そこで、プロダクト開発の経験があった私がToC チームに社内留学し、データチームとしてデータ機能のリリースを目指すことになりました。

　　　　　　　　　　　　　　　　　　　　社内留学のissue

社内留学の枠組み

社内留学の目的は、昨年の8月(つまり約10ヶ月前) から進めていた、音声認識を活用した講義動画検索機能のリリースでした。

実はToC チームによって途中まで開発が進んでいましたが、前述の理由などにより継続できない状況になっていました。

そこを引き継ぎ、"ラストワンマイル" を走り切ることが今回のミッションでした。

下記が簡単なシステム構成図です。ここではいくつかコンポーネントが分かれているんだな、くらいでご認識ください。

図の左側がユーザーに近い部分で、「learn」と「api」がToC チーム、「Search API」より右側はデータチームの担当でした。

　　　　　　　　　　　　　　　　　　　簡単なシステム構成図

下記が組織上のイメージです。

前述の通り私はデータチームに籍を置いたままでしたが、デスクをToC チームに移動させてもらい(と言っても歩いて30秒くらいの距離)、ToC チームのスクラムセレモニーにも混ぜてもらうようにしました。

　　　　　　　　　　　　　　　　　　　　組織上のイメージ

それ以外は、「出たとこ勝負」でした。

初日から渡りに船

初めて触るコードベースの理解を進めるにあたって、ローカル環境のセットアップは欠かせません。

前任者のPR などを眺めつつ、README などを参照してセットアップを進めていきます。

Quipper ではありがたいことにDocker Compose が整備されており、コマンド一発で開発環境が立ち上がる。。はずでしたが、環境依存の設定部分がうまくいかず、詰まっていました。

まぁ、そんなうまい話は無いよな、と思っていた矢先、

「何か困ったことないですか？」

と、ToC チームのメンバーの声。

「そこみんな詰まるんですよねー」

なんて言いながら一緒に調査しつつ、動くところまで持っていってもらいました。

物理的に移動して良かったな、と早速社内留学の恩恵を感じつつ無事にセットアップを完了し、順調な滑り出しとなりました。

留学生ということで「なんか知らんけど面倒見てやるか」感を持ってもらえていたのだと思います。

※ 誤解のないよう、通常の新入社員向けにはオンボーディングプロセス があり、そこで開発のいろはを教わります。今回は留学生ということで、その対象からは外れていたのでした。

思い立ったがペアプロ日和

ToCチームでは毎朝デイリーMTG が実施されており、その中で「今困っていること」を相談する時間があります。

ある日おもむろに、実装する部分についてペアプロをしたい、と言ったら、また別のToC メンバーが業務の合間を縫って一緒にペアプロしてくれました。

コードベースの共有に留まらず、純粋な実装方針についてもプロダクト開発者ならではの知見(このときはページネーション実装におけるオフセット方式とカーソル方式) を共有してもらい、これは最高体験だなと思いました。

もちろんチーム外の人とペアプロすることもあるとは思いますが、気軽にできるかどうかはその人との距離感によると思います。

今回は物理的にも心理的にも近くに寄せてもらったことで、こうした動きがシュッと行えたことは大いに助けになりました。

留学先に貢献できていないモヤモヤ感

前述のようなポジティブな面もある一方で、ネガティブに感じることもありました。

基本的にはToCチームと同じMTGに参加しているため、彼らが直面している課題を間近で知ることとなります。

その中には自分がリソースを割けばある程度役に立ちそうなものもありますが、自分は別プロジェクトを抱えているのでそうはいきません。

ToC チームに所属していながら、ToC チームの仕事をしていないことにモヤモヤし始めました。

「みんなどう思ってるんだろう？」

「こいつなんでいるんだ？とか思われてないかな。。」

不安が大きくなりすぎないうちに、前述のデイリーMTG で吐き出すことにしました。(ちなみにデイリーMTG は事前にGoogle Docs に内容を記述するスタイルです。)

すると、ToC メンバーから下記のようなフィードバックをもらいました。

こうしたフィードバックがすぐにもらえること自体にも価値がありますが、私の立場を尊重したうえで「あるべき姿」から意見をいただけたことが何よりうれしかったです。

これで安心して自分のミッションを遂行しよう、と立ち直ることができました。

領域横断機能の困難を物理で殴る

リリースが見えて来た頃、せっかくなので提供する領域を広げたい、という話になりました。

スタディサプリでは一般ユーザー向けのToCチームとは別に、学校向けにサービスを展開するToB チームがあり、ToBチームに話をしたところ乗り気だったのですが、いくつか課題もありました。

ステークホルダーが違う点や想定するUXが異なるため、それに合わせた要件の再確認が必要でした。

ワークアラウンドを見つけたと思ったらそこにまた穴が見つかり、さらにそこにワークアラウンドをして、、という循環に陥ってしまい、デザインやプレスリリースも絡んで、いつ誰が出した案が今の共通認識なのかが曖昧になってしまいました。

後日ふりかえりでの反省点にもなったのですが、こうなったときのまとめ役がこのプロジェクトには明確に存在していませんでした。

メリット、リスク、事業状況、リソース状況、仕様背景、個人の想いの強さ。。

幸い、私の得意とする業務の1つ(パズルを解くイメージ) でもあったので解決へと乗り出したのですが、そのときに助けになったのは「リアルな面識があったこと」でした。

ToC チームが主催していたMTG にToB チームとのやりとりがあったり、席が近いことでたまたまランチに行ったときに面識ができていたり。

面識の無い人であれば躊躇していたと思いますが、調整者全員と面識があったこと(と、物理的に近いこと) でスピーディに対話し、解決することができました。

無事リリース

結局リリース直前に見つかった不具合の修正などで約2週間の遅れはあったものの、無事リリースまでたどり着くことができました。

こうした喜びを分かち合える仲間が増えることも、社内留学の良い点だなと感じました。

(「偉業」emoji をもらえるのはうれしいですね。)

また留学に関係ない点ではありますが、品質にこだわり自信を持って出せるクオリティで出す。という意思決定ができることも素晴らしいなと感じました。

改善点は、「時期」と「比重」

時期に関しては、入社1ヶ月ということもあり、下記の問題がありました。

• キャッチアップする内容が多かった
• ToC チームに還元できる内容が少なかった (逆に、データチームに還元できたことは多々あった)

理想的には、1つの部署である程度の経験を積んでから実施するのが良いでしょう。

比重に関しては、下記が問題でした。

• データチームのMTG や業務(キャッチアップ) も実施していたため、業務範囲が広がった
• 結果、両方に関係するSlack を追ったり背景理解に時間がかかってしまい、手を動かす時間が減った

個人的にはもっとコードをいじったりペアプロしたりする時間がより多く持てるとよかったかなと思います。

時期の話とも関係しますが、理想的には留学先に専念して、リソース配分を全振りするくらいの思い切りのよさがあると良いと思いました。

まとめ

冒頭に挙げたポイントを振り返ると、 結果的に今回のプロジェクトにおいて社内留学は非常に効果的でした。

また、Quipper に根付く文化や価値観がそれを後押ししたとも言えるでしょう。

ToC チームのノウハウ・知見(開発環境のセットアップ・デプロイ方法やスクラムの方法、ツールなど) をデータチームに還元することができたことも良かった点です。

データチームでは今後さらなるデータプロダクトの提供・改善を目指しているので、良い足がかりとすることができたと思います。

私もこうした文化や価値観を絶やすことなく、より良い組織・サービス作りに貢献していきたいと思います。

Quipper では社外からの留学(= 会社見学) も募集しているので、もしご興味を持たれた方は一度応募してみてはいかがでしょうか :)

===== イベントのご案内=====

2019年7月18日(木)に、TECHPLAYにてスタディサプリ/Quipper Product Meetup #3 を開催します。今回のテーマはSREで、以下４つのセッションをお届けする予定です。

• Observability in StudySapuri
• Canary release - フレームワークのアップグレードを安心して進めるためのリリース戦略
• gRPC in スタディサプリ ENGLISH
• CQRS+ESをKinesis,Spark,RDB,S3でやってみた

皆様のご参加をお待ちしております。詳細/お申し込みは https://techplay.jp/event/737389 をご覧ください！

1. Web Developmentチームの中に、ToC向け(個人向け)サービスのチームと、BtoBtoC向け(学校向け)サービスのチームがそれぞれあるイメージです。↩