内製で開発できる組織を作るため、現状の問題点とは
「建設業界では、職人さんなどの人材を確保するのがすごく難しくなっています。私たちは、この課題をITで解決しようと、職人さんと工事会社さんのマッチングを中心にサービスを提供しています」
自社のサービスについて月澤氏はこのように説明した。
「当社のCEOは建設業界の出身で、創業当初からエンジニアが社内に潤沢ではありませんでした。出資いただいた資金でオフショアのベトナムに依頼して開発してもらっていました」
当初の開発は、ベトナム側の開発力は問題なかったが、こちら側も試行錯誤していたり、動くものを最速で世に出すことを最優先していたため、結果としては不具合が多く、開発のリードタイムも長くなっており、仕様決めやテストにも時間が取られてデプロイ頻度が少なくなっていた。ユーザーに実際に使ってもらっても、リードタイムが長いため要望に応えるのに時間がかかってしまうという課題を抱えていたのだ。
この他に、ロードマップがない問題もあった。エンジニア一人ひとりが事業ドメインを理解して、この先こういうモノがあるから今こういう設計にしておこう、といった先を見すえた開発が難しくなっていたのだ。
「私が入社したころは、既にこのような課題を抱えていました。そのため、ユーザーの要望や課題を最速で解決できるよう、内製で開発できる開発組織を作ってくれとオーダーされました」
「助太刀が目指すサービスは、建設業の人と人の繋がりを軸にして、建設業の抱えるさまざまな課題を多角的に解決していくワンストッププラットフォームというものです。こうした新しいものは、ユーザーさんに直接聞かないと分からないことがすごくたくさんあります。私たちと全然違う業界にいる使う人たちが実際に使ってくれないと意味がないので、ちゃんと聞いて、その要望をより早く取り入れて改善していくことが重要です」
そこで、できるだけ短い間隔で改善し続けたい、同じ期間における課題解決数を最大化したい、より品質の高いプロダクトを出していきたいと考えた。つまり、開発の生産性を最大化して、プロダクト品質を上げてリリースを早くしていくことを目指したのだ。そのために、作業量・品質・改善速度という3つの観点で、すべてを高い状態にするにはどうすればいいのか考えて、改善を繰り返してきたと説明した。
開発組織の発展を4つの段階に分け解説
では、どのように開発組織が発展していったのだろうか。月澤氏は、黎明期・内製化の初期・中期・後期と大きく4つの段階に分けて、その具体的な様子を解説した。
「開発部の黎明期には、本当に社内に人がいませんでした。最初なので、アイデアを形にして、実際にユーザーさんに使ってもらって、受け入れられるか必要なものか検証することに注力していました」
開発プロセスは、ほとんどウォータフォールに近い形だった。社内で仕様書をちゃんと書いてデザインもやって、それをベトナムのオフショア開発会社で30名くらいで開発してもらった。最終的に、自社で手動で動作確認して、ちゃんと動けばリリースする形でやっていたという。
「最初の小さなアイデアを形にするところは、ウォータフォールはそんなに悪くないんじゃないか、むしろウォータフォールでも良いんじゃないかと私は思っています。ユーザーもプロダクトもない段階で0からアジャイルを回すのは結構難しいので」
この頃、代表が自分でプロダクトオーナーをやっていたような形だった。建設業界で培った知識やアイデアを元にプロダクトに落とし込んでいって、要件検討から仕様書作成・開発・テストまで半年くらいかけてリリースしていたのだ。
「この頃は、リリースするのが最優先でした。そのためベトナムのエンジニアの誰がどのくらいで開発しているのか、作業の定量化や品質の定量化はできていませんでした。デプロイまでのリードタイムも不安定で、リリースまでは数ヶ月スパンになっていました」
開発の内製化に着手し、初めて社内エンジニアでプロダクトを改善
こうして世の中にアプリとしてリリースしたので、ここからは実際のユーザーである日本の建設業界の人たちの意見を聞いて、細かな改善をすばやく出していきたいと考えていた。「私が参加したのは、内製化初期の中間か後半ぐらいだったと思います。メインの人材マッチングアプリは世の中にもう出ていて、それ以外にB2B向けのサービスや正社員採用のサービスなど新しい機能をリリースしていた時期でした」
この時期は、開発は相変わらずオフショアがメインになっていて、バグ修正や小さな改修などの一部を社内メンバーで対応している状況だった。そのため、大型の新規開発などはウォーターフォールで、細かいUI改善などはアジャイルで開発するというハイブリッド開発になっていた。アジャイルでは、Backlogでチケットを管理して、一応スプリントを区切って開発していた。
「営業やカスタマーサクセスなどの社内から改善案が上がってくるほか、職人さんや工事会社の人にインタビューして集めた要望をスプレッドシートに集約して優先度を付けて、それをチケットにして社内のエンジニアが2週間のスプリントで開発するといった形になっていて、それ以前の数か月に比べると改善速度は早くなっていました」
ただし、スプリントと言っても、2週間で見積もっていたのに実際には3週間かかりそうとなったときに、「じゃあ3週間にしよう」と全部できたらリリースするといった感じでスパンは安定していなかった。
「リリース頻度が多くなり、世に出る機能やサービスが増えたこともあり、品質の面では低下していました。今までと同じように手動でテストして、ちょっと動いたらオッケーみたいな感じでリリースしていたので、最終的にはバグがめっちゃ多くなるみたいな感じになっていました」
ストーリーポイント導入とQAチームの強化で作業量と品質を改善
「内製化の中期には、採用を進めて社員も増えてきたので、バックエンドを皮切りにオフショアから社内にちょっとずつ開発を切り替えていきました。」
この時期に、各チケットの工数見積にストーリーポイントを導入して効果を発揮した。それ以前は、アサインされた人が自分なりに「5時間かな、8時間かな」と見積りしてスプリントに利用していた。これを属人的にやるのではなく、タスクの大きさをチームで考えていくようにしたのだ。
同じバックグラウンドを持ったエンジニア同士で「自分だったら3ポイント」「いや8ポイント」といった会話をすると、8ポイントの人は3ポイントの人に「なんでそんな短くできるの？」といった具合にディスカッションになり、そこで認識合わせができるのだ。結果として見積りの精度が上がり、レビュー工数や開発工数も下げることができた。
「スト―リーポイントを導入するといった改善のおかげで、開発スピードが早くなり、リリースする量も増えていきました。一方で、サービスが増えていたにも関わらず品質については手が回っていなかったため、どんどんバグが増えていました。2020年の終わりごろ本当にバグが頻発して、社内の組織同士の関係性も悪化していました」
そこでQA専門チームを結成して、2週間のスプリントの後に品質を確認する体制をとった。すると、「これはバグです」といったフィードバックが多くなり、修正工数も増加して、2週間で開発したものがQAと修正を含めて1か月後にリリースといったスパンになってしまった。
このように、作業量と品質は改善したが、改善速度は低下していたのだ。
作業量・品質を維持したまま改善速度を増加させた方法
「内製化の後期では、開発できる量も増えて品質も安定してきたので、これを維持したまま改善速度の増加に取り組むことになりました」
この時期は、さらにメンバーが増えて、ほぼ完全に内部で開発できるようになっていた。オフショアはあくまで何かあった時のヘルプの位置付けだ。
開発手法も、デイリースクラムやスプリントプランニング・レトロスペクティブのように、ちゃんとスクラムに合わせたイベントを実施するようにした。開発者が主体のイベントなので、エンジニアがちゃんと参加してエンジニア同士で会話するのだ。そのおかげで、自分のタスクだけでなく周りが何をやっているかも分かるようになった。また、エンジニア一人ひとりの事業ドメインへの理解も進んだ。
「さらに、QAチームを増強して、さまざまなテストを実施できるようにしました。新機能テストだけじゃなく、リリース前にリグレッションテストを全部回すとか。マスターテストケースとかもある程度作っていますし、サービス稼働率も計算して、SLOとかSLAも測定できるようにしています」
昨年からは、バックエンドを中心にユニットテストをちゃんと書くという取り組みを進めている。テストコードをちゃんと書くことで、コードを書いている時点である程度バグのリスクを削減できる。そのおかげで、QAチームからのフィードバックも減って、次のスプリントにスムーズに入れるようになった。QAチームの強化とユニットテストを書くことで品質を担保しているのだ。
「現在、25名ぐらいの開発チームのなかでQAチームが5名くらいいます。5人にひとりがQAチームになっています。開発チームのなかにデザイナーもいて、開発時に円滑にコミュニケーションできるようになっています」
現在の開発プロセスは、次図のようになっている。
「開発組織の人数が倍々で増えると、いろいろなところが柔軟に動けなくなることがありますが、私たちは採用にも恵まれたおかげで、開発プロセスも結構いろいろと変えていって、開発できる課題数やチケット数も倍増できましたし、品質もSLOで99.9％以上を守れるようになってきています。リリース頻度も、2週間に一度のペースになっています」
こうした成果を得られたのには、いくつかのポイントがあったと月澤氏は説明した。
まずはストーリーポイントで、エンジニア同士で事前にディスカッションできるようになったこと。レビュー工数や開発工数の低減につながっている。またスクラムイベントでエンジニアの参加が進んで、他のメンバーのタスクへの理解だけでなく、事業やプロダクトに関する理解が進み、それが作業量やベロシティにつながっていると述べた。品質に関しても、ユニットテストの定着とQAチームの戦力化が効果を発揮している。さらに、スクラムにQAフェーズを合わせて、リリースまでのサイクルを最適化したことで、作業量と品質を担保したうえで安定したリリースが可能になったと説明した。
「組織フェーズや、そこにいる人たちにも寄ると思いますが、開発プロセスの課題は、1つ上げたら1つ下がるというトレードオフの形になりがちです。組織の成長に合わせて、組織の生産性を客観的に見て、どこが足りないのか、どうしたら上げられるのか、そうした課題を1つずつ解消していくことが大事だと思っています。我々の話を参考にして頂いたり、反面教師にして頂くなりして、何か役立てて頂けたらと思います」と語って、セッションを締めくくった。
