転職サービス「doda」が保有する国内最大規模のデータベースから求める人材を探し出し、直接アプローチできるダイレクトソーシングサービス、「doda Recruiters」。このサービスが急成長を遂げる裏側では、ベンダーへの外注から開発を一部内製化にシフトしたり、スクラム開発の導入など、体制づくりが進められてきました。
しかし、スピードを優先するあまり、品質を担保するためのレビューや知見蓄積で属人化が進み、不具合が発生しやすい状況に。そこで今回、これらの課題を解決すべく行われたのが開発プロセスの標準化です。どのような思いでこの取り組みが進められ、なぜ成功を収めることができたのか。取り組みを主導した佐川に話を聞きました。
- 誰が開発・チェックを行っても変わらぬ品質を守れる仕組みづくり
- 仕組みは与えられて従うものではなく、“皆で作り上げるもの”
- “意識せずとも品質が守られ、標準化が当たり前に” さらなる改善を目指し、取り組みは続く
※撮影時のみマスクを外しています。
誰が開発・チェックを行っても変わらぬ品質を守れる仕組みづくり
――まずは、今回開発プロセス標準を作成することになった背景から教えてください。
佐川：きっかけになったのは、2020年下期に新機能をリリースするタイミングで不具合が複数発生してしまったことです。
私はその期間ちょうど育休中で復帰後に状況を知ったのですが、振り返りミーティングに出席して原因分析を進めていく中で、開発プロセスの標準化が必要だという話が持ち上がるようになりました。
――起きてしまっていた要因は、何だったのでしょうか。
佐川：大きな要因は、開発工程の一部作業が属人化してしまっていたことです。内製化を進める中でスクラム開発も導入し、作業的な意味合いでは“誰かが抜けてしまっても開発を進められる”状況が作れていました。一方で、「このテストケースや調査結果でリリースして良いか」などレビューにおける判断については、担当歴の長いメンバーの知見でのみ担保されていました。
また一般的なシステム開発におけるレビュー観点の他に「doda Recruiters」特有の事情も加味したチェックを行う必要がありますが、そういったチェックすべき項目が可視化されておらず、やはり同様に長年携わってきた人にしか判断ができない状況になっていました。
そうした中、長年「doda Recruiters」を担当してきたメンバーの異動や退職など入れ替わりが同時期に発生して……。開発プロセスやレビューの仕組みが整理されないままに本プロダクトの経験が浅いメンバーで進める体制になったことから、人で担保していた品質を守れなくなり、結果として不具合につながったのだと捉えています。
――課題をもとに、今回の取り組みはどのように進められたのでしょうか。
佐川：求められるのは、開発プロセスとレビューの観点、リリース判定基準の3つを整理し、明確に可視化することです。そこでまずは私の方で設計〜開発～テスト～リリース～振り返りの一連の流れと各工程で行うべきことを定義し、そこに振り返りミーティングで得られた観点を加えながら、土台となるものを作成しました。
その後はレビューの場を複数回設け、パートナーさんも含めリーダー層のエンジニアたちから指摘をもらいながら、改善を繰り返して作成を進めていきました。
仕組みは与えられて従うものではなく、“皆で作り上げるもの”
――開発プロセス標準の作成にあたって工夫されたことや意識されたことがあれば教えてください。
佐川：特に意識したのは、理想だけを追い求めて運用することが現実的でないものを作り上げてしまわないように、「doda Recruiters」の開発現場の実態もしっかり加味することです。
前職がSIerで、お客様への説明責任を果たすためにも非常に厳しい標準を設けて開発を行っていました。そこでの経験が取り組みのベースとしてありつつも、それをそのまま「doda Recruiters」に当てはめると“堅すぎる”、”やりすぎな”部分もありました。理想論だけを詰め込むのではなく現場の開発状況を見ながら、バランスよくアレンジしていくことは意識したと思います。
――標準化がなされることは、捉え方によっては“自由でなくなること”でもあるかと思いますが、現場で受け入れられるものにするために工夫されたことはありますか？
佐川：もちろん「そこまで本当にやるのか」という声も一定ありましたが、結局はそれをやらなければ品質を担保できないので、作業ボリュームが増えて大変になってしまうのは承知で、一旦はやらせてほしいとお願いして進めました。
ただ同時に、私が今回作成して展開するものはあくまで“初版”でしかなく、ここから必要に応じて削ったり加えたりしながら、皆で作り上げていきたいという話も前提として伝えていたんです。柔軟に対応していきたいし、だからこそ意見が欲しいという考えをベースに進めたので、導入はしやすかった印象です。
私としても前職でたくさんのチェックリストを使いながら開発を進めていたので、正直億劫だなという気持ちもわかるんですよね。ただ中にはやらなければいけないこともある。そこをふまえて、皆さんと対話しながらすり合わせを進めるようにしました。
――開発プロセス標準を導入してから、効果を実感される場面はありましたか？
佐川：施策を行う前後で比較して、不具合の件数は大幅に削減できました。もちろん全てが今回の施策の効果かというとそれだけではないと思いますが、一定の効果は出たと捉えています。
またリリース案件数はほとんど変わらず、むしろ微増していました。作業ボリュームが増えた反面、手戻りが減るなどの効果が生まれたことで、長い目で見ればスピード感のある開発という「doda Recruiters」ならではの良さを失わずに進められているのかなと思います。
――短期間ですでにしっかりと効果があらわれているのですね。導入後の皆さんの反応としてはいかがですか。
佐川：振り返りとして皆さんから意見をもらいましたが、「テストのパターンのチェックがしやすくなった」「作業ボリュームは増えたけれど、リリースに向けての準備が明確になってやりやすい」など効果を実感する声を多くいただけています。
また判断すべき事項とプロセスが定められ、それを守った上でなければリリースできないルールを設けたことで、エンジニアもディレクターも判断に自信を持ちやすくなったように感じます。
とはいえ軽微な不具合が発生してしまうこともまだありますが、振り返りの中で再発防止策を立てる際に「開発標準にこれを組み込むのはどうか」「チェックリストをこう改善しよう」などの案が出てくるようになりました。
ベースとなるものを作ったことで議論がしやすくなり、皆の意見をもとに修正を重ねる中で、より開発プロセス標準が現場の実態に合ったものに変化していく……そんな良い循環を作っていけるのではないかと手応えを感じています。
“意識せずとも品質が守られ、標準化が当たり前に” さらなる改善を目指し、取り組みは続く
――育休復帰直後の時期、ご自身の通常業務もある中で、この取り組みを先頭に立って推進された原動力はどこから生まれていたのでしょうか？
佐川：育休から復帰して開発状況を聞いた時に、このままではマズイと強く思ったんですよね。
「doda Recruiters」では企業様により良いサービスをご提供するために、スピード感を持った新機能開発に積極的に取り組んでいます。しかし売りであるスピード感が、反対にご迷惑をおかけしまっている――「プロセスを見直さなくては」という危機感が、取り組みを進めた背景にありました。
――今回の施策が成功した要因をどのように振り返られますか？
佐川：やはり事前に多くの方々に協力を求め、力や知恵をもらって進められたことが大きかったと思います。エンジニアとしてこのサービスの開発に携わっていたとはいえ、自分だけでは足りないところが当然出てきますから。数人を集めてのレビューの場だけでなく、個別でも詳細に話を聞きながら改善を重ねたことで、ある程度整った状態で展開できました。
また「この危機をなんとかしなければ」という思いは皆が共通して持っていたものだったからこそ、快く力を貸してもらえたのかなと振り返ります。
――ありがとうございます。それでは最後に、今後この取り組みをどのように進めていきたいか、展望をお聞かせください。
佐川：今回開発プロセス標準を作って、改善を進められていますが、現状はチェックリストの項目がかなり多い状態であり、また一部チェックを行うタイミングなどで運用が根付いていない部分もあります。
今後は自動テストのさらなる推進を進めたり、運用ルールを改善したりと、引き続きあるべき姿を考えながらブラッシュアップを続けて、最終的には、意識せずとも標準化がなされ品質を守れるような仕組みを作っていきたいと思っています。
さらに長期的な視点では、現在はシステムの状態を可視化し切れていない部分があるため、監視の仕組みの改善をベースに、不具合を未然に防ぐための取り組みも進めていけたらと思います。
――ありがとうございました！
（取材＝伊藤秋廣（エーアイプロダクション）／文＝永田遥奈／撮影 = 小野綾子）
佐川 真吾 Shingo Sagawa
ダイレクトソーシング事業開発本部 プロダクト開発部 doda Recruitersエンジニアリンググループ エンジニア
SIerでPL/PMを中心とした業務を経験し、2019年2月にパーソルキャリアに入社。開発ディレクションを中心とした業務を行ってきたが、開発エンジニアリングの部門に異動。現在はdoda Recruitersの開発チームに所属。
※2021年12月現在の情報です。
