「品質」は重要だと言われることは多いですが、「品質とは何か？」「品質を確保する/向上させていくために何をすれば良いのか分からない」ということは多いのではないでしょうか？ 会社の組織規模が大きくなると、それに伴い新たに問題が発生することもあります。
「品質を確保する/向上する」方法については状況によるところが多く、完璧な正解はないと思っています。
株式会社ビズリーチの品質改善グループでは、プロダクト開発の品質をより良くするためのプロセス改善活動を行っており、BizDevOpsを円滑にする品質改善開発プロセスモデルを定義しました。 この記事では、プロセスモデルを定義するための株式会社ビズリーチの状況を踏まえた私たちの考え方や、定義したプロセスモデルの実践について、「コンセプト編」と「実践編」に分けて紹介します。
本記事は前編にあたるコンセプト編になります。
品質改善グループについて
Visionalグループの従業員は約1800人おり（2022年7月末現在）、セールス、企画、マーケティング、法務、知財、開発、セキュリティなど様々な職種が存在する中、エンジニアを含むプロダクト職と呼ばれる職種は約3割です。
株式会社ビズリーチは「ビズリーチ」、「HRMOS（ハーモス）シリーズ」、「ビズリーチ・キャンパス」、の複数のプロダクトを開発しサービスを提供しており、それぞれのプロダクト開発に携わるメンバーは各事業に紐づくプロダクト本部に所属しております。
私たちのグループが所属するプロセス改善部は、全社横断組織としてプロダクト開発のプロセス改善をミッションに、SODA構想 （SODA : Software Outcome Delivery Architecture）を掲げ活動をしています。今回ご紹介する品質改善グループの活動については、SODA構想の中では以下の位置付けになります。
私たちが定義した品質改善開発プロセスモデルについての詳細は後半でお伝えしますが、前半ではそれを定義するにあたって背景にある考え方（コンセプト）を紹介します。
早い仮説検証を行う
「品質」と一言で言っても、人によって定義はさまざまあります。 書籍「ソフトウェア品質保証の考え方と実際」にて、著者の保田勝道氏は「品質は、ユーザにとっての価値である」と定義しています。
「価値」とは「満足度」であり、「品質は、ユーザの満足度である」とも定義していますが、顧客の要求は日々変化するとも述べています。 この書籍が発行されたのは1995年ですので、現在においてはより要求や、技術の変化するスピードが早くなっている状態です。
我々もサービスを開発していく上で、お客様に「価値」を提供していきたいと考えています。ただし、この日々変化する「価値」を提供し続けられるという状態は難しく、お客様へ価値を提供出来ているかどうかは、新しい機能を提供しただけでは判断が出来ません。
新しい機能などを提供した結果、想定したユーザがどういう反応を示すのかを把握する必要があります。 そのため、事前にどういうユーザからどういう反応が返ってくるのかの仮説を持って新しい機能などをリリースし、そのリリースした結果どうだったか、という検証を繰り返していく必要があります。
この仮説と検証をセットで検討しないと、「新しい機能を早く作ってリリースしているけれど、ユーザの満足度が上がらない」ということになり得ます。 また、具体的な仮説を設定しない場合、「ユーザから欲しいという要望があった機能を作っているけれど、ユーザへの本質的な価値にはなっていない」というような事があり得ます。
そこで私たちが参考にしたものが、BizDevOpsというモデルになります。
このモデルでは、ビジネス（Biz）、開発（Dev）、オペレーション（Ops）、の人たちがスムーズな連携を行い開発を行っていくことを示しています。私たちはBizDevOpsのモデルを参考にして、どういったユーザにどういった反応があるのかという仮説を持って新規機能をリリースし、リリースを検証して、それらの結果から次の開発に活かしていくというスムーズな流れを作っていきたいと考えています。
ビジネス、開発、オペレーションの人たちがスムーズに連携を行うためには、この組織間の連携でボトルネックを作らないことが重要になります。作業が滞ってしまうボトルネックが存在するということは、そこで無駄な待ち状態が発生してしまうことを意味します。 待ち状態が存在する場合、仮説検証のスピードが落ちることになりますので、ボトルネックは可能な限り取り除いていく必要があります。 また、新しい施策を導入する際にも、その施策がボトルネックになることがないようにすることが重要になってきます。
そこで、プロセスを検討する際には、リソース効率とフロー効率に着目します。 リソース効率が高い状態というのは、人の稼働率が高く、空き時間が少ない状態です。 一方、フロー効率が高い状態というのは、価値を作り出す時間が多い状態です。
価値を作り出す時間を多くするには、プロセス全体で価値を生み出さない時間（ボトルネック）を短くすることを目指します。このフロー効率を上げることは人の稼働率を上げることと同一ではありません。 リソース効率とフロー効率の詳細については、書籍「This is Lean 「リソース」にとらわれずチームを変える新時代のリーン・マネジメント」を参照してください。この文章でご紹介しているリソース効率やフロー効率の定義もこの書籍を参考にしています。
私たちは、このリソース効率とフロー効率のどちらも高い状態を目指していきたいと考えています。
開発速度を落とさずに品質を上げていく
品質を上げる際に良く取られる手段として、テストケース数を増やすというアプローチがあります。 確かにテストケース数を多くするとバグが多く見つかることもあるかもしれませんが、バグを見つけても品質は良くなりません。 もし、想定外の動作をするバグを見つけた場合、それを修正することにより想定外の動作をすることの数を下げる事ができます。 ただし、それは本質的に品質が上がっているということではないと考えています。
状況によっては、テストケース数をむやみに増やすというのは無駄なテストを行っている可能性もあり得ます。 私たちはテストに関して、論理的に納得感のある必要十分なテストを実施できることを目指していきたいと考えています。
またリリース時の承認者を増やす、承認フローを新規に設けるというアプローチも手段としてはあるかと思います。 リリース時の承認者を増やす、会議を通ったらリリースできるようにする、というようなことを闇雲に実施するとその施策によりボトルネックが発生し、無駄な時間が発生してしまう可能性があります。
承認と品質の関係については、書籍「LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する」では以下のように紹介されています。
「必ずチーム外の人や組織の承認を得なければならない」というプラクティスと安定性との間に相関があるか否かを対象チームについて調べてみた。すると、このプラクティスと「リードタイム」「デプロイ頻度」「サービス復旧までの所要時間」との間には負の相関があり、「変更失敗率」との間には相関がないとの結果が出た。 引用：（著）ニコール フォースグレン, ジェズ ハンブル, ジーン キム（2018年）『LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する』
私たちはこのようなボトルネックとなる活動を極力排除しつつ、品質を改善させる施策を実施していくことで、より品質の高いものを、最適化されたスピードで提供できるようになると考えています。
そこで初手として、BizDevOpsの中のDev、つまり開発チームに近い部分の改善から着手を行っています。
そして、先程ご紹介したリリース時のボトルネックなどを作らないように、Biz→Dev、Dev→Ops間の連携をスムーズにする改善をしていきたいと考えています。
初手として着手しているDev（開発チーム）のプロセスについてはフィードバックループを意識してプロセスを設計します。 以下の図は、アジャイルの一つの考え方である、XP(eXtream Programming)のフィードバックを示したものです。
開発における作業のフィードバックというのは、秒単位で取得できるもの、分単位で取得できるものなどさまざまあります。 重要なことは、可能な限り行った作業について早くフィードバックを得られるようにプロセスを設計をするということです。
ただし、本番環境で動作させた場合のフィードバックを早く得たいからといって、急いで機能をリリースして致命的な問題を発生させてしまっては意味がありません。 冒頭でも述べたとおり、株式会社ビズリーチ内にはさまざまな組織や役割を持った方が在籍しています。
リリースしなくても社内から得られるフィードバックというのはたくさんありますので、リリース前にまず社内の適切な人たちからフィードバックを得られるという状況を目指します。
その際、社内の誰に相談するべきかということを都度チーム外へ問い合わせていると、その聞く手間や、返答までの待ち時間がボトルネックになってしまう可能性があります。そのため、社内の誰に相談するべきかということを開発チームが自発的に判断して、相談などをしていける状態を目指していきます。
こういった早期のフィードバックを適切な人たちから受けるようにすることにより、総合的な手戻りコストの削減や、社内で気がつくことができた不具合を社外に出さないような本質的な品質を上げる仕組み作りをしていきます。
まとめ
私たち品質改善グループの施策としては、これまで紹介したコンセプトを元に以下を行っていきたいと考えています。
- どういったユーザにどういった「価値」を届けたいのかという具体化した仮説を持ち、その結果を検証し、次の「価値」検討に活かすという流れをスムーズにしていく
- 開発チームがさまざまな適切な人、適切な観点で早期のフィードバックを得られ、手戻りコストや社外での事前に防げたであろう不具合の発生を防ぐ
次の実践編では上記を実現するために行っている具体的な施策内容についてご紹介します。
