サービス成長とリファクタリングの関連性(後編)~質疑応答で語る、組織の取るべき方向性~

2019年8月8日開催CTO meetup「サービス成長とリファクタリングの関連性」のイベントレポート後編記事です。

各企業のLTの前編記事はこちらからご覧ください。>>

【ご登壇者】

Chatwork株式会社 執行役員 兼 開発本部長 春日 重俊さん

C Channel株式会社 執行役員CTO開発部長 小野 邦智(Tonny)さん

日本マイクロソフト株式会社
Azure ビジネス本部 シニア Azure Product Marketing Manager 太田 寛さん

株式会社リクルートライフスタイル
ネットビジネス本部 データエンジニアリングユニット 山田 雄さん

イベント後半は、会場に参加された方からの質問をご登壇者の皆様に回答していただきました。

サービス成長とリファクタリングの関連性

リファクタリングを「しない」選択肢の裏側にあるもの

春日:では、ここからは会場からの質問を中心にパネルディスカッションを進められれば思います。
まずは「リファクタリングをあえて制限するという点について、エピソードがあれば聞かせてください」という質問がありました。恐らく、リファクタリングを「しない」という決断に対してはエンジニアサイドの疑問も生まれてしまうところなので、その点についてTonnyさんいかがでしょうか。

Tonny:リファクタリングをしないという決断をするのは、やるならちゃんと測ってからやりましょうというスタンスを意識する前提であります。前編で述べたとおり社内の人数が足りていないという要素も非常に大きいです。エンジニアを大勢抱えて、一人ひとりが自分の専門分野を深堀りしながらプロダクトをチューニングしてくという体制を夢見てはいるのですが、実際には採用の問題があったり、サービスの成長を優先した結果、「とりあえずやらない」という決断をすることが多いです。
例えば、うちのアプリをダウンロードして開いてみると、起動はさほど速くありません。本当は1秒以内に収めたいのですが、できていない。現在起動時に読み込んでいるAPIが複数個ある状態なので、これをどう束ねてスピードアップするのかさまざま検討はした上で、一旦今の速度のままでいくことにしています。
ただ、この間トラブルが発生して、起動時間が普段の倍以上かかるようになってしまいました。というのも、Apple審査で「ユーザー自身のコンテンツに関しては必ずミュート機能を実装しなければならない」というリクエストがあり、アプリがリジェクトされてしまったのです。ミュート機能は非常にパーソナライズされたデータで、ミュートするデータを探し出して取り除くという挙動はかなり重い。そうなると、さすがにこれは時間を割いてリファクタリングしなければならないだろうということになりました。

Tonnyさん C Channel株式会社 執行役員CTO開発部長 小野 邦智(Tonny)さん
NEC中国子会社に2年勤務した後、2007年に日本語喋れないまま単身日本へ。2008年2月からiOS開発に携わり始め、VOYAGE GROUP、楽天などを経た後にフリーランスアプリエンジニアへ転身。SmartNews, Frilに参加した後にEC事業の失敗を経験しました。その後、C Channelに参加。2019年1月からC ChannelのCTOに就任。最近の興味は、5G時代のビデオサービスのあり方を模索しています。

必要性に反して、リファクタリングしたくてもできないケースを体験する各社

春日:リファクタリングはサービスを継続的に成長させていくには非常に重要なテーマですし、悩みの多いところです。太田さんは多くの企業を支援されていますが、各社ではリファクタリングにどう取り組んでいるのでしょうか?

太田:基本的に日本のお客さんは「変えたくない」という心理が大きいのですが、困っていることがあればやはりリファクタリングが議題になりますね。ただ、本来的には作り直したほうが将来的に新しいサービスを入れ込むのが簡単になるし、運用コストも下がるとわかっていても、政治的な理由で進まないケースが非常に多い印象です。 また、極稀にではありますが、一部の技術屋さんなどがあるサービスを使いたいがためにリファクタリングするというような話もあります。これは危険ですね。よくよく要望を聞いてみると、リファクタリングすべきではないというパターンも存在します。

春日:基本的にソフトウェアは作った瞬間から陳腐化していくので、やはりリファクタリングは一定割合必要です。ただ、前編のお話にもあったとおりやれば事業インパクトがあるわけではないので、限りなくその割合は減らしていきたいものなんですよね。 その点でChatworkがメンバーに方針として伝えているのは、開発とリファクタリングを目安として7:3にしていこうということです。気持ちとしては8:2、9:1くらいにしたいのですが、プラットフォームがどんどん拡大している状況の中では、一定のリファクタリングはあって良いとしています。

春日さん Chatwork株式会社 執行役員 兼 開発本部長 春日重俊さん
明治大学経営学部を卒業後、電通国際情報サービスに入社、大手企業の基幹会計システム導入の経験を積む。その後リクルートに入社、新規事業の業務に従事し、組織マネジメント・サービス企画・BPRなどに携わり、2016年1月にChatworkに開発本部長として入社。2019年3月に執行役員兼開発本部長に就任。

エンジニア組織をモノリスにするメリット・デメリット

春日:では次の質問です。「Chatworkさんは組織を部署で区切りはじめたのはいつ頃でしょうか?6人の会社でどのタイミングで区切るか悩んでいます」ということなので、Chatworkについてあくまでケーススタディでお話します。
まず、10人前後の組織であれば部署を分ける必要はありません。ご存知の方も多いと思いますが、「ピザ2枚ルール」にあるように、大体一人のマネージャーが管理できる限界は8~10人程だからです。
実際、Chatworkは現在エンジニアが40~45名規模で、一度意図的に一つの部署にエンジニアを偏らせるというチャレンジをしてみたことがあります。その結果、1on1に追われすぎてマネージャーが立ち行かなくなった。1つの部署が大きくなりすぎると、モノリスで動きが遅くなってしまうんです。
ですから、私の実体験でいえば8~10人規模の単位で部署を割っていくのが良いのではないでしょうか。Tonnyさんは20名ほどの組織ですがいかがですか?

Tonny:うちは今、あえて束ねていこうとしています。というのも、C Channelのサービス本体と、mystaというサービスがあるのですが、以前はエンジニアが完全に分かれていました、私が両方見ているという状況でした。その中では、ノウハウの共有が遅いという問題が生じていたんです。一つのサークルの中であれば一言でみんなに伝わるようなことができず、結局それぞれの組織で同じ問題が起きてしまっていた。そこで最近あえてこの2つの開発チームを合体させて、1on1も同じタイミングでやるといった取り組みをしています。
小さなオフィスでも20~30人くらいなら収まるので風通しもいいですし、質問者の方の例で言えば6人ですから、分ける必要は全く無いと思います。

CTOmeetupリファクタリング

大胆な組織開発・運用の変革を実行するための会社風土

春日:次の質問は太田さん宛てですね。「Microsoftさんは運用8割、開発2割から開発8割、運用2割に変革したと聞いたことがありますが、変革がどうなされたのかエピソードがあれば教えてください」ということです。

太田:Microsoftはリファクタリングをするかしないかを非常に合理的に判断します。どれくらいの利益を見込めて、人件費などのコストはどのくらいかかって、企画はどうなっているのか、論理的にきっちりしていれば実行するということです。ですから、変革についても合理的なビジネス判断があればやるという風土が背景の一つにあります。
また、WindowsにしろAzureにしろOfficeにしろ、すべてVisual Studioで作っていますし、Visual StudioもVisual Studioで作っています。つまり、Microsoftはみなさんに提供しているサービスのユーザーでもあるのです。それを踏まえてリファクタリングすることもありますし、合理的に考えて利益が投資を上回るのであれば、1から作り直すということも平気でやります。そのあたりの思い切りの良さもあってできた変革なのかなと個人的には思っています。

太田さん 日本マイクロソフト株式会社 Azure ビジネス本部 シニア Azure Product Marketing Manager 太田 寛さん
OA機器メーカーで、プリンターや複写機の制御ソフトウェア開発に携わりながら、ソフトウェア開発手法・プロセスを極める。 その後、縁あって、2006年に日本マイクロソフトに入社。 組込み制御に関する技術・製品の普及啓発を担当するエバンジェリストとして活動。 組込み側から、クラウドに対応領域を広げ、現在は、IoT、AI、Big Dataを主領域として、多数の実案件支援、各種イベントでの登壇、コミュニティ活動に従事。 より多くの開発者にMicrosoft Azureが提供する様々なサービス・テクノロジーを使ってもらえるよう、日々悪戦苦闘中。

いかにして組織の技術的負債を溜め込まないエンジニアを採用するか

春日:採用まわりについては「立ち上がり時期のエンジニア採用をどのように進めれば良いか苦労しています。各社の採用ノウハウでお話しいただけるものがあれば知りたいです」との質問が来ています。
当社の場合で言うと、私が入社してから1年間は巨大プロジェクトがありすぎて、それを回していくことに必死でした。針の穴を通すような採用をしなければならなかったので、基本的にはスカウトと信頼できるエージェント経由の二本柱でしたね。エージェントは玉石混交なので、当初は10社ほどにお願いしていたのを最終的に1社に絞り込んだことで成功したのだと思います。
スカウトについては、恐らく企業のフェーズによってどういう人材を採用したいのか、はっきりと定義した上でないと組織設計に失敗します。当社の場合注力したテーマが安定運用だったので、SRE部隊も作った上で、そこにジョインしてもらう人材をひたすら1年かけて口説きました。採用した最初の1人が現在のSREのトップです。

Tonny:うちは個人の力に非常に頼っていますね。優秀なエンジニアで、なおかつ技術的負債についてよく理解している人がいれば、後々の負荷そのものが減っていくからです。例えば採用時は年俸が50万円か100万円かといった違いしかなくても、2~3年後に負債を減らしてくれているのか、それともプロダクトに爆弾を埋め込んでいるのか、そういう視点で人材を見抜けるかどうかがとても重要です。

春日:山田さんの視点で見ると、大きな組織であるからこそキラーエンジニアを立てるのは大変だと思うのですが、どのように組織づくりをしているのでしょうか。

山田:「合わない人は合わない」という視点を重視してきたような気がします。技術的に特化した優秀な人材がいても、カルチャー文化がフィットしなかった場合は仕事を楽しめなくなってしまうからです。その結果、なかなか採用するのが難しい状況にはなっているのですが、悪影響を与えてしまう人を入れるよりはマシだという考えはあるかもしれません。
先日はSmartHRさんで60億資金調達して30億は採用に充てるといった話もありましたし、そのくらい採用は大変なのだと思います。

山田さん 株式会社リクルートライフスタイル ネットビジネス本部 データエンジニアリングユニット 山田 雄さん
SIerにて主に組込み系の開発に従事したのち、フリーランスとして独立。 フリーランスの間に、シミュレーションシステムの開発や、大手ECサイトのメールマーケティング用分析基盤の構築を経験。 2015年リクルートライフスタイルへ転職。リクルートライフスタイルの共通分析基盤を構築する傍ら、 chatbotの開発や、メールマーケティングにも関わる。 2019年からはリクルートグループ横断での基盤立ち上げを行っている。

サービスごとに安定運用の定義によってリファクタリングの方向性を定める

春日:では最後に「サービスとなると安定運用が大事になると思いますが、どんなタイミング、どんな箇所のリファクタリングを行っていますか?」という質問です。これはサービスの特性によって異なると思っていて、そもそもそのサービスにとっての安定運用とは何かを決めるのが重要です。当社の場合はチャットですが、チャットが送られて反映するまで数秒かかるのは嫌ですよね。ですからサービスをリリースして10ms、20ms遅れると全体のパフォーマンスがすぐに詰まってしまうような仕組みになっているんです。そこはかなりシビアに運用しています。
山田さんが扱うビッグデータはユーザーがどう扱うのかという視点になるかと思いますが、安定運用の観点についてはいかがですか?

山田:基盤を見ているエンジニアが今は少ないこともあって、SLOを設けずに負荷なく運用することで乗り切っています。1日落ちたら売上が下がるような部分についてはきっちり守るのですが、どれを守ってどれを守らないのかは、裏で動いている施策も含めて守るものを決定しています。

イベント終了後は、懇親会が行われました。
CTOmeetup ご登壇者の皆様、有難うございました!!

次回のCTOmeetup告知

イベント告知【CTOmeetup】JavaScript ~進化し続けるフロントエンドエンジニア~

CTOmeetup
2019年10月3日(木)開催、JavaScript(Angular,React,Vue)のフロントエンド技術の需要が高まる昨今、 技術選定の背景、技術の強み、フロントエンドの課題、 今更聞けない質問や開発に苦労した話等、開発しているエンジニア目線からトークを予定しています。
詳細は、こちらのページをご覧ください。


この記事を書いた人
flexy編集部
flexy編集部
ハイスキルIT人材への案件紹介サービス
サーキュレーションが運営するフリーランスのエンジニアを中心としたIT人材の案件紹介サービスflexy。エンジニアに役立つコンテンツも提供しています。【flexyのサービス詳細】★求人を募集している法人様向けお仕事をしたいご登録希望の個人様向け

週1日~/リモートの案件に興味はありませんか?

週1日~/リモートの関わり方で、「開発案件」や「企業のIT化や設計のアドバザリーなどの技術顧問案件」を受けてみませんか?副業をしたい、独立して個人で仕事を受けたエンジニア・デザイナー・PM・技術顧問の皆様のお仕事探し支援サービスがあります。

flexyでご案内できる業務委託案件

業務委託契約・開発案件(JavaScriptメイン)

テーマ flexy登録画面から案件詳細の確認と直接応募が可能です
勤務日数 2-3日/週
報酬 4万円/日
必要スキル JavaScript・React
勤務地 東京都内/リモート含む
リモート

外部CTO、技術顧問

テーマ 技術アドバイザリーとして知見と経験を生かす
勤務日数 1日/週
報酬 10万円/日
必要スキル エンジニア組織立ち上げや統括のご経験、コードレビュー経験、技術的なアドバイスが出来る方
勤務地 東京
リモート 相談可

業務委託契約・インフラエンジニア

テーマ flexy登録画面から案件詳細の確認と直接応募が可能です
勤務日数 2-3日/週
報酬 5万円/日
必要スキル それぞれの案件により異なります
勤務地 東京
リモート 相談可

業務委託・フロントエンドエンジニア

テーマ flexy登録画面から案件詳細の確認と直接応募が可能です
勤務日数 週1日〜
報酬 5万/日
必要スキル それぞれの案件により異なります
勤務地 東京
リモート リモートと常駐のMIXなど

人材紹介のCTO案件(非公開求人)

テーマ CTO、技術顧問案件はflexyに登録後、案件をコンサルタントからご紹介します
勤務日数 業務委託から人材紹介への移行
報酬 年収800万以上
必要スキル CTOとして活躍可能な方、エンジニア組織のマネージメント経験
勤務地 東京
リモート 最初は業務委託契約で週3日などご要望に合わせます

業務委託契約・サーバサイドエンジニア

テーマ flexy登録画面から案件詳細の確認と直接応募が可能です
勤務日数 週2-3日
報酬 案件により異なります
必要スキル 案件により異なります
勤務地 東京都内
リモート 相談可能
個人登録

お仕事をお探しの方(無料登録)
法人の方(IT課題の相談)