技術・デザイン

技術的負債の解決のために「プロチャレ制度」で他部署に技術留学してみました

Profile

  • 酒井 小枝
    株式会社ASTROBOX サーバーサイドリーダー
    2012年 サイバーエージェント新卒入社。サーバーサイドエンジニアとして数々のスマートフォンアプリの開発を担当。2017年より、サーバーサイドリーダーとして、「Ameba占い館SATORI」「SATORI電話占い」のサービス開発に従事。

  • 小久保 駿
    メディア統括本部CATS バックエンドエンジニア
    2012年サイバーエージェントに新卒入社。サーバーサイドエンジニアとしてソーシャルゲームの開発、立ち上げに従事。2014年より音楽ストリーミングサービス「AWA」の立ち上げと運用のバックエンド開発に参画。2017年よりCATSにて2つの新規サービスの立ち上げを経て、現在は2020年リリース予定の新規サービス開発に従事している。

事業を伸ばすために、エンジニアが新しい技術を効率的に習得する

―「プロチャレ」とはどういう制度ですか?

酒井:事業戦略上で必要な技術を習得するために、社内の別プロジェクトに技術留学できる制度です。

サイバーエージェントには、会社の経営課題を役員や社員を交えてチームで議論し、会社の方向性を決める「あした会議」というカルチャーがあります。「プロチャレ」はエンジニア版の「あした会議」で私たちのチームから提案しました。

社内には「運用フェーズにはいったプロダクトだと、新しい技術の習得がしづらい」「新しい技術の習得をしたいなら、異動を希望したほうが早い」という課題があり、その解決策をチームで議論しました。

ヒントにしたのは、2016年にサムザップのインフラエンジニアである石原裕之が自社サービスのクラウド移行に必要なノウハウを学ぶため、期間限定で「AbemaTV」に出向したケースです。石原はその経緯を「AbemaTVへ技術留学した」という記事にしていて、当時から話題なっていました。

こういった取り組みをサイバーエージェントグループ全体の制度として導入提案したのが今回の「プロチャレ(プロジェクトチャレンジ)制度」です。

― 酒井さんは、プロチャレ制度の第一号として現プロダクト(Ameba占い館SATORI)から新規プロジェクトに技術留学しました。現プロダクトでの新技術習得にどんな課題を感じていたのですか?

酒井:私が運用に携わっている「Ameba占い館SATORI」(以下 「SATORI」)は、サービスを開始して7年が経過しました。長く続いているサービスの例に漏れず「SATORI」も技術的負債を蓄積したまま運用していました。

その弊害は、開発ミーティングで顕著にあらわれました。ビジネスサイドから「こういう機能を追加したい」という案が出たとしても、エンジニアは「それはシステム仕様上できません」と答える頻度が増えていました。

技術的負債に縛られていることが原因で、小規模な改修しかできないシステムになっていて、開発チーム一同 システム刷新の必要性を痛感していました。

小久保:運用中のプロダクトのシステム刷新は、技術的な観点では必要ですが、ビジネス的には意思決定が非常に難しいですよね。

酒井:そうなんです。2019年中盤は「SATORI」が事業を拡大していくフェーズに入りました。そのタイミングを見計らって事業責任者に相談をしにいきました。

「事業拡大を目指すにあたって、現状のシステムではユーザーが求めるような機能追加はカバーできません。このタイミングでシステム刷新に踏み切らせてほしい」と率直に相談し、GOサインを出してもらいました。

ー システム刷新のために「プロチャレ」をどう活用したのですか?

酒井:システム刷新にあたって、コンテナによる運用を考えて言語の選定から見直しました。社内の色々な方にレビューをしてもらった上でGoを採用することを決めました。

その一方、チーム内にGoの経験者がいないため、実際にGoが使われている開発プロジェクトでメンバーが技術習得する必要がありました。独学で勉強したものと、実際にプロダクトに導入できるレベルには大きな隔たりがあるためです。

そんなある日、「プロチャレ」制度の運用がいよいよ始まり「せっかくだからプロチャレでチャレンジしてみたら?」と運営側から提案してもらったのがきっかけです。

― 留学先はどうやって決めたのですか?

酒井:「SATORI」のシステム刷新のために、Goやコンテナについて自分なりに勉強をして、プロジェクト構成案も考えていました。その構成を音楽ストリーミングサービス「AWA」や競輪のインターネット投票サービス「WinTicket」でGoの導入実績があるCATSの小久保にレビューしてもらっていました。

小久保:CATSは「WinTicket」を始めとして新規事業の立ち上げから運用までを行う開発組織です。複数の新規プロジェクトに携わることで、良かった部分も失敗した部分も含め、PDCAをまわしているのが特徴です。良かった点は次のプロジェクトで取り入れ、悪かったところは直していくということが着実に実践できるのがCATSの良いところです。

事業立ち上げに関する設計と運用の知見がCATSの中で貯まってきていて、ぜひ他の事業にも展開したいと思っていたので、プロチャレの相談がきた時に「ぜひ受け入れたい」と申し出ました。

実際、酒井が見せてくれたシステム構成案をレビューしていると、Goやクリーンアーキテクチャなど出てくるキーワードが「WinTicket」で採用しているものと一致する部分が多かったのが印象的でした。

「持ち帰る」という明確なミッションがあることのメリット

― CATSで酒井さんが携わったのはどんなミッションだったのですか?

小久保:全体のアーキテクチャやGoの書き方を理解してもらうために、マイクロサービスを1つ立ち上げることにチャレンジして もらいました。

他のサービスと、どのように通信をして、どのように1つのマイクロサービスが稼働するのか。デプロイのフロー等も含めた全体の流れを掴んでもらいたいと考えました。

せっかく「プロチャレ」でCATSに技術留学するからには、マイクロサービスの1つを作ることで、技術を網羅的に学んで持ち帰ってもらうことを今回の目標としました。

酒井:といっても、技術的なことはもちろん、事業に関するビジネスロジックもわからないことだらけで、プロジェクトリーダーにはたくさん質問しちゃいました(笑)

― 酒井さんがCATSに来て、小久保さんはどう感じましたか?

小久保:キャリアもあって責任ある立場にいる人なので視野の広さを感じました。例えばオンボーディングのやり方であったり、Readmeの記述の定義や、Pull Requestやコード内のコメントなど。「なるほど、こういう部分が新しく入ってきた人からすると分かりにくいところなんだな」というのが酒井さんの様々な質問から見えるようになりました。

酒井:ドキュメント周りは「オンボーディングは大事だよね」という話を常々しているのと、あとはドキュメントをしっかり書く先輩エンジニアに教わったりしているので、その影響は受けていると思います。

また技術的負債を抱えたサービスにジョインした時にドキュメントがないとすごく大変なので、そういう状態を起こさないようには意識しています。

一方でCATSではUML、システムのシーケンス図などのドキュメントが非常にしっかり作り込まれていて、そこは私がおろそかにしていた部分だったのでしっかり持ち帰りたいと思いました。

ー プロチャレ中、特に意識していたことはなんですか?

酒井:「学んだことを持ち帰らないといけない」というミッションが明確だったので「持ち帰ること」は常に意識していました。少しでも疑問に思ったことは質問しないと、曖昧なままでは帰った時にメンバーに説明できないですから。

小久保:確かに。これが普通の部署異動の場合は、多少疑問はあってもまずは決まりごとを踏襲するというケースが多いかもしれません。期間限定でジョインして持ち帰って展開する、という前提だったからこそ、疑問を疑問のままにしないアプローチができたかもしれないですね。

酒井:「プロチャレ」を通じて、自分1人で勉強していた時には得られなかった知識をたくさん教わることができました。例えば可読性を意識した書き方などについて文献の中では触れられていない部分も多かったので、とても勉強になりました。

小久保:我々も感覚的にやってきた部分があったり、開発の中で話し合って「じゃあこうするべきだね」と決まったものの明文化はされていなかった部分を、質問されることで明確に言語化することができました。

うまく人に説明できなかった部分について改めて考えたことで、自分たち自身のプロジェクトの理解もすごく深まったところはあると思います。これは今後のことを考えても大きかったなと思います。

酒井:あとは課題感になっている部分の話を聞くことで「SATORI」に戻った時にあらかじめその課題に備えた対処ができるようになるのも良かったなと思います。例えばSpannerに繋がないとテストができないという現状を聞いて「それならSATORIの場合はMySQLでやるからローカルで立ち上げてテストができるな」と考えることができました。

小久保:それこそが「プロチャレ」の本質ですよね。

酒井:言語やライブラリーの仕様でこういう時にコンパイルエラーが出てしまうとか、運用していく中でこういう課題が出てくるといったことをあらかじめ教えてもらった上で、「SATORI」ではそのツールを使うべきかどうか決められるというのはありがたいです。

小久保:技術選定に関しては、自分で調べるだけでは分からない部分もあるので使っている人に聞くのも有効ですからね。

酒井:しかも動いているものを触れますから。「マイクロサービスだからこういうCIを入れるとうまく開発できるんだろう。でもうちはマイクロサービスじゃないからこれはちょっとやり過ぎかも」というように使用感を確かめつつ判断できるのは大きいと思います。

―「SATORI」に戻ってからはどんな作業をしているのですか?

酒井:CATSで学んで帰ってきて、刷新の方向性に関してやはり変更を加えたい部分が出てきました。まずはそれをチームに展開しつつ改めて調整しているところです。戻ってこの1ヵ月は主にプロジェクトの構成を整理し直していました。

あとは新しいシステムにgRPCを使う予定で、バランシングにEnvoyを入れようと思っていたのですが、その辺りの設計がやり切れていませんでした。これはCATSでも相談させてもらっていたので、今はそれを設計書に落としてインフラに展開したりしているところです。

個人のスキルアップというよりも、技術による事業課題の解決が目的

― 制度として、プロチャレを運用してみてどう感じましたか?

小久保:技術はどうしても人に依存する部分があります。それをいかに組織ベースで横に展開するか。サイバーエージェントも含めた様々な企業がトライしていると思いますが、なかなか難しい。ならば人を動かすことでスキルを伝播しようというアプローチがプロチャレという制度です。

これまでCATSという組織の中ではうまく展開できてきたと思っていますが、今度はプロチャレという制度を活かすことで、全社レベルで技術を横に展開できればと思います。

― 勉強会などの横軸活動もありますが、それだけでは難しいですか?

小久保:やはり実際に業務で使って見るのが一番早いのではないでしょうか。勉強会で聞いてみて、「なるほど」と思い「じゃあやってみよう」となることは多いと思います。

ただ習得するまでの学習コストもありますし、実際に事業で導入できるかどうか、自信を持って判断ができるレベルまで持っていくにはどうしても時間がかかってしまいます。
習得するまでの時間やコストを考えると、プロジェクトに入って自分で作ってしまうの効率的な手段だと思います。

酒井:例えばあるプロジェクトで今後新しい技術を取り入れようと決まった時、一番手っ取り早いのはその技術を持った人を採用することです。だからといって簡単に「じゃあ採用しましょう」とはならないですよね。リソース的な問題もあるし、ピッタリの人材がタイミングよく見付かるとは限りません。

それが理由で事業がストップしてしまうのはもったいないので、だったら今いる人材にスキルを身に付けさせることができる手段が増えればいいわけです。「プロチャレ」はその1つの手段にできると考えています。

今まで場合によっては技術の導入を諦めてしまうこともあったと思いますが、この制度で選択肢を増やすことができればいいなと思います。

―今後どんな人に「プロチャレ」という制度を活用してもらいたいと思いますか?

酒井:「プロチャレ」というのは「プロジェクトチャレンジ」の略なので、どんな人というよりは、技術的にトライすることに対し習得の課題を抱えているような部署に積極的に活用して欲しいと思います。

「新しい技術を採用する」という視点だけではなく、例えば事業判断として「メンバーのスキルレベルを底上げしたい」といった目的でも良いと思います。

小久保:確かにこの制度は個人ではなく事業やプロジェクト単位で考えるべきものですね。事業として新しい技術習得が必要不可欠という視点から、適任者として酒井さんが選ばれたという今回の経緯は非常に分かりやすいと思います。

酒井:個人のスキルを上げたいのであれば、すでに社内には「キャリチャレ」という制度があります。あちらは留学ではなく完全な異動で、自ら手を挙げて会得したいスキルが身に付くプロジェクトに異動できるという制度です。

「プロチャレ」はあくまでプロジェクトの方針としてやるべきことがある時や、技術的な取り組みをすべきであるという判断をした時に使う制度なので、むしろ事業責任者の方に知ってもらいたい制度です。こういう制度があると知った上で、経営判断の1つの手段として使ってもらえると嬉しいなと思います。

新卒採用のオフィシャルSNSアカウントをフォロー

  • Facebook
  • Twitter
Page Top