OKIPPA開発を内製化!!Yperの77日間戦争
Yper株式会社でインフラ・サーバサイドエンジニアをやってます石川です。
入社してから早いもので9ヶ月が経ちました。
その間のできごとをいろいろなあれで振り返ってみたザザッとした記事はこちら↓
この記事を書いてみたのは、まあ実働5人くらいのチームで3.5億円を調達するという裏側で何やったっけ、結局当たり前のことをワイワイやってただけだよねっていう振り返りをしてみたかったからでした。
企業個人を問わずお世話になった皆様に「いやいや、普段ふざけてるように見えて実際ふざけてますけど仕事は結構ちゃんとやってまっせ」というポージングでもあります。
「スタートアップの仕事」っていうのが少しでも伝わって多くの人に「働いてみたい！」って思ってもらえたら良いな、とも思っています。
で、実際にはそんなに感動のストーリーばっかりではないわけです。会社全体の振り返りとして濃度を均一にするために敢えて私の職能である「エンジニア」という部分は薄めて書きました。泥臭い部分もたくさんありました。
そんな泥臭い中で特に私が入社した8月16日から10月31日まで、指折り数えてみるとなんとキリの良い77日間で、Yperの開発チームは「オフショアで始めた開発を内製化する」という激戦を繰り広げました。
今回はその77日間戦争を振り返ってみようと思います。
開戦時の状況
2018年8月16日、奇しくも日本の終戦の日の翌日ですが、神宮前のYperオフィスでプロダクトと開発チームの内情を把握した私は開発内製化へ向けた独立戦争を仕掛けることをCTOの島添、チーフエンジニアの遠峰、フリーランスで入った森とともに決意します。
【当時の状況】
■アプリ側
・ ReactNative製で、一応アプリとしてリリースされている(iOS/Android)
・頻繁にクラッシュする
・クラッシュレポート等は取得できていない
・無駄なライブラリの読み込みが多数あり動作が遅すぎる
・ビルドやリリースのフローが整備されていない
・環境構築手順がない
・画像サイズやデザインルールなどが全く統一されていない
■サーバ側
・大量の使われてない書きかけのAPI
・コーディング規約が存在しない
・そもそもソースコードのレベルが低く、Controllerのメソットすべてがpublicとかザラにある
・DBにはindexが皆無でフルスキャン連発
・手動リリースのため障害が頻発
・AWSのインスタンスが何故かアメリカリージョンにある
・セキュリティザルすぎ
■チーム体制
・海の向こうのオフショア先が開発の実権を掌握しており、やりたいことが一向に進まない
・開発のハンドリングができない
・「動けばいい」という思想が蔓延して自動化やテストは考えない
・でも動かないのでリリース延期
・コードレビューが機能していない
・雰囲気最悪
一例です。もっとあります。飲みに行ったら朝まで話せます。興味ある人はぜひ行きましょう。
特にセキュリティに関わることは詳しく書きたいんですが、まあ書けませんよね。怖い。
そんな状況を目の当たりにして、思うわけですよ。
「あれ？このくらいのプロダクトだったらアプリ1人、サーバサイド1人、インフラ1人で足りるよな？？？？」
Yperの開発チームはなんの意味もない「開発するための無駄なコスト」を払い続けている状況でした。
コードレビューしないからバグ出まくり→修正にコスト
リリースとか自動化しないから障害→対応にコスト
でもこの開発を進めるしか事業を前進させられないから続けるしか無いんです。案の定CTOは火消しのためにベトナムに長期滞在したりしてました。この時期CTOはストレスで太ってた気がするぞ。今は痩せたけど。
そんな中で目標を立てました。
10月末までにオフショア開発を終了し、開発を完全内製化する
そのためには結構ガツッと変えないといけないこと、作業しないといけないこともあると覚悟しました。でもこれをやらないと『開発の成果/開発のコスト』が低すぎて会社が無くなる、という危機感を抱くレベルだったので、絶対にやりきるつもりで開発の主導権を取り戻す戦いを挑むことになりました。
内製化に向けた戦略
Yperはスタートアップです。
事業の停滞は即座に死が見えてくる、そんな環境の中で開発を内製化しさらに開発スピードをアップさせなければなりません。
つまり、新規機能の開発は内製化の作業を行っている間にも進めなければならず、しかもどこにも仕様書や運用マニュアルがない状態から3ヶ月間で引き継ぎを行わなければいけないということです。
こういう状況でジョインしたエンジニアは銀の弾丸を見つけたとはしゃぐ子供のように「1から作り直そう！絶対そのほうがいい！俺がやれば早い！」みたいなことを言い出します。ダメです。死にます。世の中にそんな天才はあんまりいない。
まず内製化後のチーム状況を考え、どのような状態なら継続して開発を進めていけるのかを明確にすることが必要です。
・エンジニアはどんなスキル、レベルの人が何人いる予定なのか
・ざっくりどのくらいのペースでどんな機能が必要になるのか
大枠はこれです。
Yperの場合に当てはめてみると
・アプリエンジニア 1人
・サーバサイドエンジニア 1人
・インフラエンジニア 1人
・営業サイドの動きが早いため、2週に1回は割と大きめのリリースがありそう
・バグ取りは毎日でもリリースがありそう
という状態がイメージできました。
その上でYperの開発チームは以下のような流れで一つずつ状態を整えていけば内製化に持っていけるだろうと戦略を立てました。
1. 顧客の安全を確保すること
2. 開発に秩序をもたらすこと
3. 本質でない作業を減らすこと
4. メンバーに権限を移譲すること
一つずつ、実際にやった作業を含めて書いていこうと思います。
1. 顧客の安全を確保すること
度重なるピボットや外注先の初期メンバーの入れ替え、そういうことでプロダクトはメチャクチャになっていました。
が、当たり前の話として顧客はプログラムがJavaで書かれていようがRubyで書かれていようがなんの興味もないです。
スムーズに、安全に動けばいいんです。
スムーズに、はレベルがあります。レスポンスが100msに間に合えばOK？120msはアウト？そこらへんは判断基準が難しいと思います。
そもそもまともに動いてませんでしたが。
じゃあそんな中で何を大事にすればいいのかといえば安全です。
エンジニアが創業当初から開発のハンドリングをできていない場合は特に、ここが大事です。
DBに平文で重要情報を格納していようが
サーバへのSSHがパスワード認証でアクセス元制限がかかってなかろうが
HTTPで個人情報をPOSTしてようが
gitにsecret keyがベタ書きでcommitされていようが
営業出身のCEOに見つけることはできません。
わーこわい。あーこわい。
サービス停止ならまだいいんです。売上が0になるだけなので。
個人情報の漏洩事故でも起こればその会社は終わりです。
Yperについてもまー、やばいものがたくさんあったのでまず見やすい部分からインフラ->アプリケーションの順番でチェックしました。
なぜかというとアプリケーションは大量のスパゲッティコードが鎮座していたため、ざっと見るだけでもかなりの時間がかかるからです。
とにかく最速でインフラ側のセキュリティリスクになりかねない部分を塞ぎました。
まあ、セキュリティは開発当初の要求にしっかりしたものがなかったんで仕方ないかなって気もします。普通こんな実装やらんよな、っていうクソコード・クソインフラもたくさんありましたけどね。
と、まあここでオフショアの開発チームから反撃があるわけです。
「こんなにセキュリティをガチガチにしたら開発メンバーが動けない」
「必要のないレベルまで上げすぎ」
「そんな作業をやるなんて聞いてない」
うるさい。知らん。我々は君たちのために仕事をしているのではなく、新しい価値を顧客に提供するために仕事をしている。
従わないと何もできないようにすべての権限を切り分け、必要な手順を踏まないと動けないようにしました。ﾋｬｯﾊｰ。
セキュリティリスクってうっかりもありますが、大体が「めんどくさいから」で発生するものです。1人が守らないと意味がなくなる。「千丈の堤も蟻の穴より崩れる」。
このタイミングで強行できないと主導権を握れなくなるので徹底させました。
だいたい9月の半ばでインフラの移行を完了し、一部のアーキテクチャの再設計に取り掛かるまでになりました。
2. 開発に秩序をもたらすこと
そもそも、オフショア開発に限らず外注している仕事というのは目標や判断基準の共有が徹底されていない場合はだいたい失敗します。
これは開発以外にもデザインなどでもそうで、ゴールにある程度のテンプレがなくて明確化しづらい場合には死ぬことが多いのかなと。
その点では法務や労務、経理といった業務よりも開発やデザインは外注で失敗しやすいと言えると思います。
私が見てきた中でオフショア開発で失敗するパターンは大体これです。
秩序がない、つまり全員の目標と判断基準がブレブレになっている状態です。
逆に有能なPMは目標と判断基準(=納品の際のはっきりとした要件と開発ルール)を定めていたな、と思います。
この時点でのYperのオフショア先に対する達成して欲しいゴールは「いくつかある案件を期日までにリリース可能な状態に持っていくこと」と「障害を発生させないこと」でした。
実はどちらも達成することはできませんでしたが...。
やったことはすべて当たり前のことです。
・コードレビューの徹底
・リリースフローの策定
・環境やブランチの使い方の明文化とルール遵守
・チケット管理の徹底
・etc....
なんかやったことが本当に普通のことなんですが、これですら守ってくれないわけです。
「こんなにルールをガチガチにしたら開発メンバーが動けない」
「必要のない工程を増やしすぎ」
「そんな作業をやるなんて聞いてない」
さっきと一緒ですね。全体的にレベルが低すぎるので聞く耳は持ちません。10人以上のチームで障害頻発させてバグだらけのアプリ作ってこんな言い訳は聞きません。
頑なに抵抗する人も多いと想定していたので、この時点でバグ改修をどんどんYper側で巻取り、オフショア先の切り離しを進めていくことになります。
9月末までにはいろいろな症状が噴出し始めました。
3. 本質でない作業を減らすこと
無理やりに新しい状態・ルールを導入するとある種のショック反応が生じます。
これは想定内の出来事で、人間として当然のことです。
ただし我々はそんな痛みを伴ってでも作り出さなければいけない状態があり、そうしなければそもそも会社は倒産してしまいます。お金が無限にあるならのんびりやってもいいんですがそうは言っていられません。
新しいやり方にうまくアジャストできない人はどんどんと開発効率が下がっていき、その間にもバグが大量に発生しています。
しかしながらオフショア先にはアサインできるメンバーがいないのでYper側で巻き取ることになります。しかし一日は24時間しかありません。
つまり、なんとかして「今より少ない人数でたくさんの仕事を進める->開発の効率化」を行う必要が出てきました。
9月も後半になるとある程度自分の工数に余裕が生まれてきたため、サーバへのデプロイなどをCircleCIを使って自動化し始めました。
それ以外にも監視・アラート用のツールを入れたり、環境構築や作業の手順書・ナレッジを蓄積したりしてエンジニアの開発以外の工数をなるべく減らそうと動きました。
実はCIツールを導入するまでは本番を手動でデプロイしたりアプリをリリースしたりしてまあ障害の多いこと...。
検品環境だと思ってたら本番だったとか、間違えてマージしてリリースしてエラー頻発とか、厳しくしたはずのルールをなんとか掻い潜って「俺が一番目立つぜ！」っていうノリで障害を起こしに来てるんじゃないと思うレベルの状態でした。なんなの。敵なの？
そんなのも自動化によって差し込む隙がなくなったので消滅しました。わーい。運用障害はその後も極稀に発生するのみで今日に至っています。
10月に入る頃にはほぼYperのみで開発が回り始めました。特になにかしたわけじゃなくて「ショートケーキにわさび醤油かけないでね」くらいの当たり前を徹底したら幸せになれました。エネルギーめっちゃ使いますけど。
10月に入ればラストスパートです。
4. メンバーに権限を移譲すること
ここまでで開発自体はすべてYperでまかなえるようになってきました。
一時期は30人近いオフショア開発チームが必要になっていたのが3人でどうにかなるようになったのです。すごい。
しかもGAFA出身とかコンピュータサイエンスで博士号とってるとか未踏に採択されたとかそういうエンジニア1人もいません。普通のエンジニアチームです。
次にやるべきことは内製化したあとのスピードをもっと上げるために、チームが大きくなっても大丈夫なように権限を移譲していくことです。
アプリ、API、インフラの3つに担当領域を割り振り、リリースも含めてすべての業務を基本的には本人の良識を信頼して任せるようになりました。
そのために必要な手段として自動化やナレッジの共有は引き続き進めています。
Yperのエンジニアチームは普段中学生みたいなトークばかりしてますが意外と常識があるようで、特に何もせずにも「こういう場合は相談必要だよね」って動けたので苦労が一番なかったです。
とはいえけっこう大変だったのが「それぞれが完全に別領域の業務を担当しているので次に何やるかわからない」っていうことでした。
これに関してはslackをとっとと有料化して分報の運用を率先してやる、チケットを切ってから開発することで何をやっているかを明確化する、といったことでゆるーい相互チェック体制を作って対応しました。
今後人数が増えるに従って変えていかないといけないところです。
そして終戦
2018年10月31日、ひとまず開発の内製化は完了しました。
その後は開発スピードが体感で数倍になり、バグもだいぶ減ってきています。まだ残っていますけども...。
77日間でやったことは「当たり前の基準を引き上げる」ことだったかなと思います。
でもそれは誰かの当たり前を壊すということなので、めちゃめちゃコストが掛かります。そのためにはしっかりと理由とリターンを説明しながら自分が率先して動くしか無いのかなと思っています。
これはすごくエネルギーが要ると同時にストレスがかかることです。
担当者は総出で反撃にあうので、飛び交う銃弾の中に突っ込んでいかないといけません。ここで担当者の心が折れてしまうと自軍の中には次の突撃をしたい人なんていなくなります。
なので、もし自分の周りで必要だと思う孤独な戦いを仕掛けるメンバーがいたらそっとバックアップしてあげてください。
Yperでは全体に闘志が灯っていたので特に問題ありませんでした。っていうか全員で雄叫び上げて突っ込んでた。アイアムアスパルタどころじゃなくウィーアースパルタンズ。強い。
外注開発について思うこと
オフショア先をボロクソ書いた形になりましたが、個人的には発注時のYperの体制が一番のダメポイントだったかなと思います。
ゴールの共有やルールの徹底など、そこまで手が回らないまま大きなチームに発注してしまい、言語の壁もあったことでコミュニケーション不全...上手く行かないに決まっています。
とはいえ現実は非情なもので、お金を払って発注している以上アウトプットの品質には厳しくなければいけません。今回のケースではオフショア先の開発チームを立て直すよりも内製化したほうがランニングコストが低く、十分な実現可能性があったためドラスティックな手段を選択したというだけのことです。
オフショア含めた外注による開発が悪というわけではなく、すべての手段はなにかのトレードオフなのでそのタイミングや状況で良い手段を選択しなければいけないと思っています(そもそも私も開発会社の出身です)。
これから
で、つらつらと書きましたが外注という企業間だけではなく雇用関係にも同じことが言えるのかなーと。
なのでメンバーがアウトプットを最大化できる環境を作る、というのは非情に大事な姿勢で、個々人の能力が高いのは最高ですけどそんなことばっかり期待してると人材採れないんですよね。実際。
「顧客の安全を確保しながら、秩序を維持しつつ、本質に向き合える環境で、メンバーに権限を移譲した開発」を実現できるチームを作れるように今後もいろいろとやっていこうと思います。
そんな中で「普段中学生みたいなトークばかりしながら権限委譲されて働きたい！」っていう方がいらっしゃれば hr@yper.co.jp までご連絡いただくか
こちらからご応募ください。
それから、主にスタートアップで
「開発内製化したい！」
「こういうときどんな動き方がいいと思う？」
「いいエンジニア紹介してくれねーか？」
「肉とか寿司とか食べる？」
っていう方がいらっしゃいましたら rintaro.ishikawa@yper.co.jp までぜひご連絡ください。
Yperとしては副業OKですし(すでにもう1社掛け持ってます)、スタートアップ界隈では結構面白い助け合いが発生してるので、何かのご縁が生まれたらいいなと思います。
これからもYperとOKIPPAを宜しくお願いいたします。
この記事が気に入ったらサポートをしてみませんか？