はじめに
サービスとともに開発組織の規模も拡大するとどうしても、プロダクトの複雑性とリスクが増加していくこととなります。
ここでは、品質とリスクマネジメントについてこれまでの経験と事例を踏まえながら整理してみたいとおもいます。
現状認識
まず、なにごとも現状認識が重要です。
障害が起きた場合には、その真因分析を行うことは基本ですが、組織的な課題を解決するうえでは個別の振り返りだけではなく、チームを跨いだ形で複数の障害の連続性や頻度、共通点を把握することが重要です。
依存関係が増え複雑性、不確実性が増すようになると
「これだけやればまぁ安心だよね」という十分な確信が得られない
ということはどうしても起こりやすくなります。
これは障害を起こした誰が悪いという話ではなく、 精度の高い影響分析が単一チームの視点では困難になっている という状態です。
事業サイドも含めて同時に複数のチームがプロダクト開発に従事するようになると
そんな機能あったの？
そんな運用あったの？
そんな画面あったの？
その機能、そんな使い方をしていたの？
ということは珍しくはありません。
いくら整理をして理解したつもりでも、すぐにまた新たに変わってしまっていたりもします。
仮にリリース時点には問題がなくても、複雑な仕様を積み上げていってしまうと、仕様継承は困難になり時を経て大きな問題を引き起こす時限爆弾にもなったりします。
まさに、バタフライエフェクト状態。
小石だと思って動かしたら要石だった。
下手をすればマザーグースの童謡になってしまう。そのくらいに思っていたほうがいいのかも。
釘が無い
釘が無いので蹄鉄が無い。
蹄鉄が無いので、馬が失われる。
馬が無いので、騎士を失う。
騎士が乗れないので、戦いに敗れる。
戦いに敗れて、国が滅びた
すべては蹄鉄の釘がなかったため。
「スコープは絞っても個別最適はしないようにすること」
プロダクトマネジメントを行う上で、私が気をつけていることの一つです
「アジャイル」であれるのか？
アジャイル開発という言葉は昨今のプロダクト開発ではかなり一般化されています。
ときに金科玉条のごとく扱われていますが、どのような「手法」や「プロセス」であっても決して、 銀の弾丸 ではないということを理解して組織やプロダクトのステージにあうアプローチを選ぶ必要があると思います。
「Be Agile」
という言葉が示す通り、アジャイルであるというのは「状態」です。
「アジャイル開発を採用しよう」と決めることと
アジャイルな状態であれるということは全く別の話です。
参考：品質重視のアジャイル開発
アジャイル開発もそれを対比されるウォーターフォール開発もいずれにも向き不向きはあり、成功させるための前提条件があることを忘れてはいけません。
採用するプロセスやモデルを決める際には、開発チームやメンバー個人の指向性だけではなく、事業側メンバーを含めた組織全体の現状や関係性などプロジェクトを取り巻くさまざまな制約を鑑みて判断することが必要です。
「アジャイル」に抱いている根本的な違和感がわかった（「」な点に注意）。「ウォーターフォール」とされる手法が、人間の計画立案能力や未来予測能力に関して高すぎる理想をもっていたように、「アジャイル」は人間のコミュニケーション能力について高過ぎる理想を抱いているように思う。
— Kota Mizushima (on a diet) (@kmizu) December 21, 2021
品質を高めるために
では、品質を高めるために何ができるのか。
まず想起されるのは「テスト」や「QA」の改善ですが、その具体的なアクションは品質低下の真因として分析したものが何か？によって変わります。
あらゆる「エラー」や「不足の事態」へのアプローチは
現状認識と、リスク評価の精度 に収斂されます。
これはプロダクト開発だけでなく、製造業、建築業、災害対策、さらに国家安全保障に至るまで共通する考え方です。（私の過去の建築業、自衛隊の経験からも強く感じるところです）
テストも、どんなリスクをカバーするのか？を意識しなければ、必要十分で適切なテスト技法を選定し、計画策定することはできません。
テストについてもう一度考える
テストの目的はなにか？
改めて、JSTQBのシラバスから考えてみます
すべてのプロジェクトで、テストの目的は以下を含む。
• 要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価することによって欠陥を防ぐ。
• 明確にしたすべての要件を満たしていることを検証する。
• テスト対象が完成したことを確認し、ユーザーやその他ステークホルダーの期待通りの動作内容であることの妥当性確認をする。
• テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることを確証する。
• 欠陥や故障を発見し、ソフトウェアの品質が不適切になるリスクレベルを軽減する。
• ステークホルダーが意志決定できる、特にテスト対象の品質レベルについての十分な情報を提供する。
• 契約上、法律上、または規制上の要件や標準を遵守
テストと一口に言っても、確認する内容は様々な異なる視点が必要なように見えます。
適切なタイミングはいつ？適切なテスターはだれ？テスト観点はなにか？テスト項目とその合否基準はなにか？など、明らかにすべき点は多くあります。
例えば、複数のテストプロセスの中で、重複するような記述式テストを何度も繰り返しても品質が上がるわけでも、バグを効率的に見つけられるということではないでしょう。
記述式テストは、再現性が高く項目書さえあれば誰でもテスターになれますが、仕様理解が前提となり、変更前後の仕様やスコープを見誤っていればその意義を果たせません。
一方で、探索的テストは、記述式テストにおけるロジックの盲点を補完することができますが、この精度もテスターの知見に強く依存することになります。
また、一度の探索で見つけた結果から、さらに追加でどこまでのテストを行うかのジャッジも必要になります。
どんな手法であれ、「そのテストでカバーする範囲」と「うまくいくための前提条件」があることに注意する必要があります。
プロジェクトのリスク対策レベルのチューニング
次にテストフェーズから時間を遡り、抽象度を一段階あげてリスク管理について考えてみましょう。
どのようなテストが適切であるのか？の判断を行う上でも、そのプロジェクト全体としてリスクを早期に評価することが円滑に計画を立てる上では重要です。
私はプロジェクトにおけるリスクを概ねつぎのように分類して、評価しています。
これは、プロジェクトの公式な場で確認する情報だけではなく、メンバーや関係者との会話の端々などから、それぞれの深刻度や可能性を感じとりながら干渉、チェックをいれる頻度やレベルのチューニングをしていくものです。
悲観的すぎるかもしれない
楽観的すぎるかもしれない
メンバーを信頼するのと同時に客観的な批判的思考で管理のレベルをチューニングしていきます。
考えられるリスクを洗い出して、そこから杞憂と言えるものを除外し、絶対に避けなければならないことを探し出します。
前職で私が担当したDisaster Recoveryサイトのプロジェクトのリスク管理表には
「テロ、暴動、伝染病、洪水、火災」などの項目も並びました。
協業先のPMやエンジニアに対して 「あぶなっかしい」 と感じたら、リマインド回数は増え、WBSの粒度は細かくなりました。
報告されるテスト結果でも「バグはゼロでした」と言われれば、テストスコープや、カバレッジの妥当性を確認する事でリリース前に重大な欠陥に気づくことができたこともありました。
プロジェクト特性や状況によって、合格とできる条件も、適切なチェックレベルも異なるものです。
これさえやれば安心！ということはありません。
所属する組織で定義されたプロセスは遵守することは前提としても、それだけではリスクをコントロールできません。
経験からまたは歴史から、例外や想定外に対する想像力を育むことが肝要だと思います。
おわりに
品質向上やリスクマネジメントの方法論も様々ありますが、何につけても 「銀の弾丸」 はありません。
ただ、先人が積み上げてきた失敗という歴史は多くのことを教えてくれると思います。
誰かが完璧なプロセスやルールを作ってくれるのを待つのではなく、それぞれがふと立ち止まって何ができるのか？なぜインシデントが起きてしまうのか？なぜ様々な手法が生まれ続けているのか？をあらためて考え続けることが大切なのだと思います。
人間は不完全なので、どんなに素晴らしい手順やルールがあっても間違え、手を抜き、読み飛ばしたりもします。
私もお腹が空いていたりするだけでも、判断能力は30％くらい低下していると思います。
形式的な理論の習得と、経験を重ねて危険予知の嗅覚の両輪を磨いていくことがポイントだと思います。
それが、継続的に全体的なレベルをあげていく組織をつくるのだとおもっています。