はじめに

即戦力人材と企業をつなぐ転職サイト「ビズリーチ」の採用企業様向け管理画面の開発を行っている岡﨑と申します。

早速ですが、みなさんは、プロダクト開発において以下のような経験がありますか？

この記事では、私が所属するチームが上記のような「悩み」や「課題」を持ちつつ、 「高い内部品質が速いスピードを生む」状況を実現するために取り組んだ開発プロセスについて、@t_wadaさんを講師としてお招きした「質とスピード」の社内研修をきっかけに改善に取り組んでいることや今後取り組もうとしていることをご紹介します。

「保守性」に対するチーム内の課題感

私たちが運用しているビズリーチシステムはサービスのリリース以来10年以上稼働しており、 現在は古くなってしまっているアーキテクチャの刷新を行っている真っ最中です。

アーキテクチャの刷新を進める中で、時間経過と共に新しいシステムにおいても、技術的負債の芽となる保守性が低くなってしまう要素が出始めてきました。

「保守性」に対する個人的な経験

ここで、私が過去在籍していた企業で体験した 失敗談 / 成功談 を振り返ります。

前者は期日も迫っていたことから、「リリースに間に合わせるため」に行なっていました。

前者と後者で異なる点としては、後々の「修正コスト」が挙げられます。 後者であれば、一箇所の修正・テストで済みますが、前者の場合であれば、複数箇所の修正・テスト を行わないといけません。

案の定、前者では横断的な処理を後日追加する必要が出た際に、想定よりも リリースまでに時間がかかってしまいました。

私は、これらの経験から「高い内部品質が速いスピードを生む」を生むということを実感していました。

「質とスピード」研修の受講

ある時社内にて、テスト駆動開発の日本での第一人者として知られる@t_wadaさんこと和田卓人さんの「質とスピード」研修の案内があり、受講しました。 私は、@t_wadaさんの研修で、「内部品質」を高めるための学びを得たいと考えていました。

研修は、エンジニアに限らず、プロダクト開発を共に進める以下の職能の仲間も参加し、200名以上が受講しました。

研修はオンラインの受講で、 事前に用意された実況用のSlackも大盛り上がりでした。

研修終了後、私のチームでは感想戦という形で、Scrapbox上で今後取り組むべき課題について意見を出しあいました。 取り組むタスクを洗い出し、チーム内で合意することで、今までの自分たちを振り返るとても良いきっかけになりました。

研修で印象に残ったこと

@t_wadaさんから得た学びの中で、個人的に特に印象に残った内容について羅列します。

スライド
印象に残ったスライド

私は、内部品質を犠牲にする選択肢を取るのは「チーム内で調整が済むから」という部分にとても腹落ちしていました。 リリースが優先だから仕方がないと諦めていた部分もあったからです。

しかし、「内部品質」を妥協する事で、スライドにあるループが回らなくなってしまう事に気づかされました。

研修からの気づき

私たちのチームは、研修から 「高い内部品質が速いスピードを生む」ために 現状において、できていること/できていないことを再認識できました。

また、継続的に「内部品質」を向上させるためには「コードの品質」だけではないことや、 前提として、「効果的な開発プロセス」による「内部品質を継続的に上げるための体制づくり」が必要だと考えました。

※ 実線は、「できていること」です ※ 波線は、「できていないこと」です

スライド

「できていないこと」については、「将来的に取り組みたい事」の項目で お伝えします。

「できていること」については、研修を踏まえた「実践」の項目で ピックアップしてお伝えします。

研修を踏まえた「実践」

これまで紹介した背景や研修で得た学びを踏まえて、実践している事をお伝えします。

現在は以下のようなプロセスを組み込む事で、「高い内部品質が速いスピードを生む」ようにしています。

計画的なプロジェクト進行の為の「土壌」を作る

私たちの組織では、全体的にビジネスロードマップが作られており、 リリース目標となるマイルストーンがざっくり設定されます。

エンジニアが詳細な工数を出してマイルストーンを出していくようなアプローチではなく ビジネス上求められているロードマップを先に引いた上で作業計画を立てていきます。

私たちのチームでは、上記のロードマップから逆算し、フェーズを設計しています。

とはいえロードマップ上では、ざっくり期日が設定されているだけなので、詳細な見積もりを通してより解像度が高い見積もりと計画を作成していき、ロードマップ上のスケジュールを調整していきます。

フェーズが作成できたら、それを以下図の開発プロセスに載せて開発を進めていきます。 基本的には、リファインメントやスプリントプランニングなどセレモニー自体に依存関係があるので、 曜日毎にセレモニーを設定し、進めることをします。これによって、開発におけるリズムを作ります。

また、各種セレモニー毎にPDCAサイクルが回るようにオーナーを立てて、継続的に改善していく事がとても重要です。

質の高い優先順位の付け方やプランニングが「高い内部品質が速いスピードを生む」ための土壌を形成すると考えています。

開発プロセス
開発プロセス

図について補足です。 モブワークは、主に開発エンジニア全員で作業を行う時間を指しています。モブプログラミングやテスト設計をエンジニア全員で行い、フロー効率を向上することに繋げます。

効率的なバックログ管理で「取り組むべき」事に集中できるようにする

以前の私たちは、どの種別のPBIも一つのバックログ上で取り扱っていました。

しかし、無数の有象無象なバックログアイテムが多くなり、優先順位付けが難しくなったり、 経緯不明で作られたバックログアイテムが多くなり、時間を要するようになっていました。

そのため「取り扱うバックログアイテム」を少なくするというアプローチに辿り着きました。 すなわち「メインで取り扱うバックログアイテム」と「それ以外」を分けるというアプローチです。

バックログ
バックログの振り分け

分けるというアプローチに加えて、どのバックログも基本的には、「User Story」ベースで起票します。 例えば、「開発者はxxxができる」/「ユーザーはxxxができる」というような形式です。 「User Story」ベースのチケットに対して、サブタスクで「実装のPBI」が紐づく形になります。 よって、基本的な粒度としては、「User Story」をベースで取り扱います。

技術課題のリファインメントで取り組むべき「内部品質向上」タスクに集中できるようにする

私たちのチームでは、技術的な課題について、 定期的にリファインメントを行なっています。

今取り扱っている設計・技術がどんどん陳腐化すると考えて、 定期的に改善サイクルを回す事が大事だと思っています。

step2の課題のルートツリーに対応する「テーマのルートツリー」を付箋で貼って、整理していきます。

課題の整理が完了したものについては、上記の「Kaizen Backlog」のプロダクトバックログアイテムとして、「User Story」 ベースの形で起票していきます。

失敗のコントロールによる「内部品質」を向上させるチャンスを見失わない

上記では、User Story ベースの場合をお伝えしてきました。 以下は、User Story を束ねた「フェーズ」自体の開発期間がそれなりに 長い場合の話です。

最初は、beforeの方で開発・テスト・受け入れを行うことを考えていました。 しかし、チーム内で会話するうち、beforeをリバランスした方が良いという 結論に至りました。

リバランス

理由は、開発しながら不確実性を徐々に潰していき、作業コントロールするのが難しいのでは？という仮説を立てたためです。

「マイルストーン」通りに進捗し、「内部品質」を上げるためには、作業をコントロールできるようにする必要があると考えています。

プロジェクトの最後の方で重めのものを着手する場合、実装が進みすぎているため、仕様を変更して改修を行うというのがかなり難しいレベルになったり、内部品質を妥協して実装を進めるという状況になりがちです。

そのため、最初から完璧を目指して、「深く狭く」機能実装をするのではなく、 「MVP」で機能実装を「浅く広く」行なっていき、不確実性を下げながら 開発する事が大事だと感じています。

早めのテスト設計で「内部品質」に力を入れる箇所を見える化する

テスト分析・テスト設計による早期なリスクの発見・回避は 内部品質を上げるためには欠かせないと感じています。 早めに策が講じられれば、「内部品質」にかけられる時間も取れるようになります。

以下のように、テストベースを集めた上で、分析・設計を行います。 複雑な条件の組み合わせがあり、組み合わせの整理の 必要等があれば、ディシジョンテーブルなどのテスト技法をmiro上で紐づけるのも良いと思っています。このように最初から図解をしておくと属人性も防げますし、 このテスト設計したものをドメインエキスパートの方にレビューしていただくなどする事で、「Unknown Unknowns」を炙り出せるなどのメリットが多いです。

テストベース
テスト分析・設計

テスト駆動開発で「内部品質」を向上する

上記のテスト分析・テスト設計ができたら、実際にテスト駆動開発を行なっていきます。 例えば、以下は、バックエンドのテストコードの例です。 「RED、GREEN、REFACTOR」の原理・原則に従います。

ドメイン層のテストの例

1
2
3
4
5
6
7
8
9

  @Test
  fun `fromがtoと同じ日付になることを許可する`() {
      // given
      ...
      // when
      ...
      // then
      assertEquals(expected, actual)
  }

全体最適なシステム設計による「内部品質」を向上する

私たちの組織では、 組織が定めたあるべき姿に則って、現在モノリシックになりAgilityが低下している領域をマイクロサービスに切り出し、アプリケーション及びDBを分割していく事を行なっています。基本的には、ストラングラーフィグパターンを利用した、間にProxyを挟み、徐々に変えていく方式をとっています。

そのため、私たちがリアーキテクチャしている間に並行して、逆コンウェイの法則を用いてアサインされているチームがリアーキテクチャを行います。

そのため、どこの業務領域が、どの、システム/チームでオーナーシップを持つべきか？の境界線がわからなくなります。

最適なシステム・モジュールでの分割は、「内部品質」に直結すると考えています。 そのため、業務フローの見える化による「分析モデル」の構築及び「解決モデル」の構築が必要になります。

そこで、イベントストーミングを実施しました。 ※まだ先日開催したばかりのため、Software Design による集約の特定等は実施していません。

このイベントストーミングによって、業務プロセスと関連システムについて見える化する事ができました。

イベントストーミング

※以下のように、事前配布資料として、イベントストーミングのワーク自体の内容を展開したりもしました。

イベントストーミング
イベントストーミング

将来的に取り組みたい事

将来的に行おうとしている内容は、上記の開発プロセスに加えて、以下です。 これらは、@t_wadaさんの「質とスピード研修」を受けた上で、チームで合意を行なった内容です。

おわりに

「ビズリーチ」では、これまでご紹介したように、プロダクト開発を進める上でボトムアップで提案して推進していく事ができます。 新しい事に挑戦する事に対して賞賛される文化があるので、エンジニアとしてもキャリアアップの機会が多くあります。

少しでも興味をお持ちいただいた方は、ぜひご連絡ください！

岡﨑拓哉
岡﨑拓哉

2022年中途入社。ビズリーチのB側のプロダクトの開発を行なっています。