「品質」は重要だと言われることは多いですが、「品質とは何か？」「品質を確保する/向上させていくために何をすれば良いのか分からない」ということは多いのではないでしょうか？ 会社の組織規模が大きくなると、それに伴い新たに問題が発生することもあります。
「品質を確保する/向上する」方法については状況によるところが多く、完璧な正解はないと思っています。
株式会社ビズリーチの品質改善グループでは、プロダクト開発の品質をより良くするためのプロセス改善活動を行っており、BizDevOpsを円滑にする品質改善開発プロセスモデルを定義しました。この記事では、プロセスモデルを定義するための株式会社ビズリーチの状況を踏まえた私たちの考え方や、定義したプロセスモデルの実践について、「コンセプト編」と「実践編」に分けて紹介します。
本記事は後編にあたる実践編になります。まだコンセプト編をご覧になっていない方は前編記事をご覧ください。
プロセスモデルを定義
私たち品質改善グループでは、前編でご紹介したコンセプトを軸に代表的なプロセスモデルと、各プロセスで行ったほうが良いアクティビティを定義しました。
コンセプト編でも述べたように株式会社ビズリーチにはさまざまなプロダクトが存在します。最適な開発プロセスやアクティビティというのはプロダクト毎やチーム毎、状況により異なると考えています。 そのため、私たちは必要なプロセスやアクティビティを最適な形で、プロダクトやチームに適用していきたいと考えています。
私たちが検討したプロセスやアクティビティを示すプロセスモデル図が以下になります。
このモデルは、私たちの中で理想とするプロセスやアクティビティを定義し、初手として行った方が良いものを抜き出してモデル化したものになります。
そのため、このモデル通りのプロセスやアクティビティを行えばコンセプト編に述べたことが十分実施できるということではありません。 また、前述したように最適な開発プロセスやアクティビティというのは、プロダクトやチーム毎によって異なると考えていますので、このモデルで示したすべてのアクティビティを実施した方が良いかどうかはプロダクトやチーム毎に異なると考えています。
以下では、定義したプロセスやアクティビティについて簡単にご紹介します。
開発プロセスの形について
私たちは開発した大きな機能をリリースする際に一度に検証して、一度にリリースするという形を推奨しません。 イテレーティブやインクリメンタルに細かく開発し、検証していく方法を推奨したいと考えています。 細かい単位でフィードバックを貰い、改善していくことで、手戻りなどのコストを減らす事ができ、欠陥数も減らすことができます。
プロジェクト計画時のアクティビティ
プロジェクト計画時に行うアクティビティについて紹介します。
リスクマネジメント
プロジェクト計画時にはリスクの検討を行います。リスクマネジメントはプロジェクト全体を通して行っていきます。特に、プロダクトリスクについては社内の有識者に相談できるようにチェックリストを用いてチェックしていきます。
リスクチェックリストの詳細については後述しますが、プロジェクト計画時にさまざまなリスクを把握しておくことで、想定外のリスクによる手戻りを最小限にし、リスクを回避・軽減する施策を実装できるようにしていきます。
そうすることで、フェーズゲートなどを設けて関係者が集まって色々なことを判断するのではなく、開発チームが自律的に相談先等を認識し、判断できるようになり、ボトルネックを作らない開発を目指せると考えています。
リリース計画
リリース計画は細かくリリースするための仕組みや方法を検討していきます。 ここで指しているリリースとは社外へのリリースのみを指しておらず、社内へのリリースも含みます。どう細かくリリースして、社内/社外で検証できるようにするかをプロジェクト計画時に検討するようにします。
うまくリリースするためには、フィーチャーフラグやカナリアリリース、ブルーグリーンデプロイメントなどのリリースする仕組みも検討する必要があります。 反復的な開発を行うことで計画時の不確実性を下げ、開発した成果物に対してより早いフィードバックを取り込みながら改善することでより完成度の高い成果物にすることを目指します。
プロセス設計
品質を確保するためにどういった開発プロセスで開発していくかを検討します。 レビューの方法や、タイミング、テスト検討の方法など品質を確保していくためにプロセスとしてどのように担保していくのかを設計します。
一定のプロセスのルールをプロジェクト計画時に検討することにより、後述するコードレビューやテスト設計レビュー等、確実にレビューがされる仕組みを構築します。 これにより、手戻りを最小限にしながら開発することを目指します。
内部品質基準設計
内部品質の基準について、プロジェクト計画時に検討します。 ここで示している内部品質は主にアーキテクチャやソースコードの品質になります。 例としては、複雑度や静的解析への対応方針、疎結合なアーキテクチャの検討などが該当します。 内部品質の基準設計によって、保守性などの観点から負債のない開発を行い、将来の機能追加に対しても変更コストが増加していかないことを目指します。
計画時のアクティビティ
細かいリリーススコープでの計画時に行うアクティビティについて紹介します。
リリーススコープでのプロダクトリスクの検討
直近リリースする変更についてのプロダクトリスクの識別や評価を行います。 リリース時のリスクを洗い出し、リスクの検出方法や、対応方針などをリリースまでの間で継続して検討していきます。
ここでのプロダクトリスクの検討の仕方についての詳細は後述します。 リスクに対して準備しておくことで、もし問題が発生した場合の対応などがスムーズに行える状況を目指していきます。
設計・開発・テスト時のアクティビティ
設計・開発・テスト時に行うアクティビティについて紹介します。
自動化
CI(Continuous Integration)上で、コードカバレッジ、静的解析、複雑度の確認を行っていきます。 それらの結果をもとに開発したものに対して、開発者が適切なフィードバックを得られる仕組みを検討します。
コードカバレッジについては数値に基準を設けるのではなく、テストするべき部分がしっかりテストされている状態が重要だと考えるため、コードレビューの際に材料として活用できるようにします。 コードカバレッジ、静的解析、複雑度の値などがプルリクエスト上など、早期に開発者へフィードバックされることで、より品質の高いソースコードが作成でき、修正も素早くできる仕組みを構築できることを目指します。
コードレビュー
コードレビューは形だけの承認とならないようにレビューを行い、間違ったコミットや変更、予期せぬ変更を行わないようにしていきます。 コードレビューやユニットテストといった仕組みで実装間違いのようなバグを確実に検出できることを目指します。 ここで言及しているコードレビューの方法は、非同期的なもの（プルリクエストでのレビュー）や同期的なもの（ペアプログラミングやモブプログラミング）などがありますが、手法に関してどれを採用するか、どれを組み合わせるかはチームにより最適な方法を採用していきます。
勘違いや間違いは誰もが起こす可能性がありますので、複数人の目が入らずに変更がリリースされていくことがないようにします。 そうすることで、手戻りなどを削減できることを目指します。
テスト設計レビュー
テスト設計レビューでは、テスト観点を一覧できる構造化されたモデル等を作成し、テスト観点をレビューする形をとり、論理的かつ必要十分なテストを実施できるようにしていきます。 足りないテストがある場合は不具合の原因に繋がりますし、重複したテストは意味のないテストを実施している可能性があります。 必要十分なテストを実施していくことで、最適な期間でテストを実施できることを目指していきます。
品質状況確認時のアクティビティ
リリース前後で行うアクティビティについて紹介します。
自己品質評価、ふりかえり
リリース前には、作成した機能がリリースして問題ない基準に達しているかをチェックします。 品質評価はプロセス品質、プロダクトの内部品質、プロダクトの外部品質の3つの視点から評価していきます。
この3つの軸で評価することにより、プロジェクト計画時に決めた品質が想定通り達成できているかをふりかえり、それぞれについて改善できる状態を目指していきます。
残バグ対応の確認
発見されたバグや、対応しきれなかったバグについての確認を行います。 バグチケットが溜まり続ける状態というのはプロダクトとして健全な状態ではないと考えるため、バグが溜まり続けない仕組みとして、ゼロバグポリシーの適用を行います。
ゼロバグポリシーの詳細については後述します。 このポリシーを導入することにより、溜まったバグに対して対応可否を判断する手間がなくなるなど、色々な作業をなくすことができると考えています。
プロジェクト終了時のアクティビティ
プロジェクトが完了した際のアクティビティについて紹介します。
プロジェクトふりかえり
プロジェクトの終了時には、あらためて品質面からプロジェクト全体のふりかえりを行い、次のプロジェクトへ活かすように情報を整理します。 プロジェクトの経験は色々な知見を得ることができますので、次のプロジェクトへ活かしたり、他のチームへ展開できるようにしていきます。
具体的な施策の紹介
上で述べた内容から次の3つについて、より詳細に施策の内容をご紹介します。
- リスクチェックリストを用いた自律的な関係部署の連携
- リリーススコープに対してのプロダクトリスクアセスメント
- 残バグへの対応の確認
リスクチェックリストを用いた自律的な関係部署の連携
社内にはさまざまな組織があり、さまざまな役割の人が在籍しています。 そのため、開発チームが自発的に各部署等にリスクを相談できる仕組みを作成していきたいと考えています。 ここでのリスクというのは特に経営リスクが高いもの、例えば、法律、セキュリティ、レピュテーションリスクなどが該当します。
これらについて必要なタイミングで適切な人に相談し、対応方針等を相談できたり、チェックをお願いできるように誘導できる簡単なチェックリストを作成していきます。 開発の適切な段階で必要な社内確認をすることでリリース後の予期せぬ問題の発生を防止します。また、開発チームが自発的に行動を起こせるようにすることで、レビューのタイミングで問題が発覚するということを極力少なくし、無駄な時間が発生しないようにしていきます。
リリーススコープに対してのプロダクトリスクアセスメント
社外へリリースする前には、リリース時にどういった影響が発生し得るのかということを検討しておくことが必要になります。 そういったプロダクトリスクをリリース前に適切に検討していけるようにします。
プロダクトリスクの検討方法については、FMEA(Failure Mode and Effects Analysis)/FMECA(Failure Mode, Effects and Criticality Analysis)をベースとした考え方を活用します。 FMEAやFMECAは主にハードウェアのリスク識別に用いられる手法で、故障モードに着目し、どういった場所で、どういう故障が発生した場合に、どういうことが発生するのかを検討する手法になります。
ソフトウェアでは故障モードの統一が難しいため、この手法をそのまま活用するのは難しいですが、どういった箇所で、どういったことが発生すると、どういう事象が起こり得るか、ということを検討する際にはこの考え方を活用することができます。
特に、最近の開発では大きなモノリシックなものを開発することは少なく、さまざまなサービスやモジュールを連携させるものを開発することが多くなっています。そのような開発では自分たちが作成していないサービスや、モジュールでの不具合も想定してリスクを検討し、自分たちが関わっていない部分で問題が発生してもシステム全体として問題とならないようにしていく必要があります。 このプロダクトリスク検討手法で作成したテンプレートが以下になります。
リスクと合わせて、リスク顕在化時の対応基準や検知方法も検討します。 リスク顕在化時の対応は、どれくらいのユーザに影響があった場合にソフトウェアをリバートするかや、どういった温度感で対応するのかなどの基準をステークホルダーと事前に合意しておきます。
検知方法については、モニタリングツールを活用する方法もあれば、モニタリングする仕組みをあらかじめ実装しておくようなことも必要になるかもしれません。 そのような仕組みを事前に検討して、実装しておくことも重要になります。 このようにリリース前にリスクを検討しておくことで、リスクを軽減し、もしリリース後に問題が発生しても確実に検知・対応できるように準備することが出来ます。
残バグへの対応の確認
リリース前には修正出来なかったバグや、検出された新規バグについてどう対応するのかを判断していきます。
プロダクトの開発を長く行っていると、優先度や影響度の低い、修正されないバグチケットが溜まっていきます。 バグは定期的に優先度の見直しを行い、対応するのか、しないのかの判断を行う必要がありますが、バグの数が多くなってくると判断する工数が膨大になり、対応できなくなることもあります。
そのような状況にならないようにゼロバグポリシーの適用も検討します。 ゼロバグポリシーというのは、検出したバグは基本的にすべて修正してからリリースするというポリシーです。 もし、バグが修正出来ないという場合でも、対応時期などを検討してバグが溜まり続けないように開発を行っていきます。
例として以下のフローチャートに従ってバグの対応可否を判断していきます。
このゼロバグポリシーを適用することにより、以下のようなメリットがあると考えています。
- 見つけられる範囲でのバグが存在しないサービスとなり、負債のないプロダクトとなる
- 作成した機能をリリースして良いかの判断が容易になる
- バックログにバグチケットが貯まり続けるのを防止することができる
- バックログを棚卸しする必要がなくなる
- スプリント内タスクのバグチケットがなくなり、すべて新規開発タスクとなることで、ベロシティ、機能開発スケジュールの見積もり精度が向上する
- オペレーションチームに制限事項（直されないバグ情報）などを周知する必要がなくなる
- インシデント発生時に既知バグかどうかを判断する手間がなくなる
ただし、プロジェクトによっては軽微なバグ修正よりも、デリバリー日を守る方が優先ということは存在します。 そのようなプロジェクトでも、バグが溜まり続けないように一定時期までに対応を判断するなどの仕組みを検討していきます。
まとめ
本記事では品質改善グループの施策の一つで定義したプロセスモデルとアクティビティについてご紹介しました。 文章量的に一つ一つは概要的な説明となっていますが、実際に適用する場合には記載されていない色々な制約や条件などを考慮する必要があります。
現在はこのプロセスモデルを一つのプロジェクトに適用し、プロジェクトの改善と施策のブラッシュアップを行っています。 プロジェクトの改善は、状況のアセスメントを行い、施策の適用の余地があるところを特定し、施策を適用するという流れで行っています。
他の施策も同時並行しているため、この施策単体での評価というのは難しいのですが、品質について納得感のある開発が出来ており、バグ数も溜まり続けていないという状態でプロジェクトを進める事ができていると考えています。
今後はこの考え方を他のプロジェクトにも展開していくことを予定しています。 前編となるコンセプト編で述べたような考えを達成でき、プロジェクトの最適な形を考えながら適用を検討していきたいと考えています。
