QAに求められるビジネス思考力
こんにちは。@regina_t_rexです。
小中学生向けのAI型教材開発を行う事業会社で1人目QAとして2年弱の活動後、現在は採用／採用広報に軸足を移して活動しています。
この記事では、QAとして活動する中で自身が経験した失敗から、「結果を出せるQA」であるために習得が必須であると感じた「ビジネス思考力」について書いてみようと思います。
はじめに
QAの皆さんは新しい現場に入るとき、まずどのアクションから始めますか？
A．システムテストの実施を開発チームから巻き取る
B．各フェーズの「テスト」の定義を行う
C．開発プロセスの改善に着手する
実は上記全てはQAが最初に「最初に着手するアクション」としては必ずしも適切ではありません。
現場、ドメイン、プロダクトによって「最も起きてはいけない不具合」は何か？何が課題なのか？目指すべき理想の品質の状態は？の答えは違います。
上記3つの例はHOW(どのように)のアクションになりますので、解決するべき課題を見極める前に具体的な手段からのスタートになってしまっています。
この記事では、QAがプロダクト・組織が抱えるの品質課題を解決する際に最も重要なのは「ビジネス思考力」なのではないかという考えについて、自身の失敗も含め、書いていきたいと思います。
ビジネス思考力とは
まず、「ビジネス思考力」の定義についてです。
ビジネス思考力とは
ビジネスで必要な「情報」や「知識」を「知恵」に変換できる力
思考法一覧｜ビジネスに必須のビジネス思考力【10種類】を解説より
ビジネス思考力は様々な種類がありますが、ここではQAが最初に現場に参画した際に必要となってくる「論点思考」「問題解決思考」をピックアップしていきます。
論点思考とは
白黒つける価値がある重要な問題（＝イシュー）を見極める思考法
思考法一覧｜ビジネスに必須のビジネス思考力【10種類】を解説より
問題解決思考とは
「理想の姿」を実現するために「現実とのギャップ」を埋める思考プロセス。
問題解決思考のプロセスは、大きく8つのプロセスに分けることができる。
問題を発見する
真の問題を見極める
問題の発生源を特定する
問題の原因を特定する
原因に対する解決策を立案する
解決策を実行する
解決策を評価する
新たな問題を発見する
思考法一覧｜ビジネスに必須のビジネス思考力【10種類】を解説より
論点思考については名著である下記の書籍も大変参考になります。
現状把握から仮説設定～課題抽出・施策検討までの問題解決の具体的なプロセスについては下記の書籍が大変参考になりました。
これらは開発現場ではなく、ビジネスサイドで必要になる力なのでは？と今まで考えていたのですが、次のきっかけでQAにとって最も求められる力なのではと考えが変わっています。
ビジネス思考力が必要と感じたきっかけ
QAとして活動する中での失敗
1人目のQAとして現場に参画し、活動をする中で、下記の失敗がありました。
１．解決するべきイシューを見誤った(プロダクト品質において何を解決するべきか？をステークホルダーときちんと設定できていなかった)
２．目の前で発生している事象に囚われて「このアクションだ！」「次はこれだ！」と本来解決するべきイシューの解決に紐づかないアクションを手当たり次第にとってしまった
３．QAの施策を「手段」から思考してしまった
その結果、着手した施策はたくさんあるものの明確なプロダクト品質向上になかなかつなげることができなかった、という過去の失敗経験から、私は下記の教訓を皆さんにお伝え出来ないかと考えています。
本来やるべきであったこと
明確に現場で品質に関する課題感が最初から認識されていれば良いのですが、QAが初めて入る現場では、「何を解決しなければいけないのか？」「目指している品質は？」の分析・定義から実施する必要があることがほとんどかと思います。
1人目QAとして入る際は「QAエンジニア」としての動き・「QAマネージャー」としての動きが両方求められますが、最も初期段階では「QAコンサルタント」としての動きが特に期待されているのではと考えています。
ソフトウェア品質の専門家としてまずやるべきは、下記であったというのを失敗を経た今では強く感じているところです。
１．「何を解決しなければいけないのか？」をまずはじめに見極めること
→ テストを開発から巻き取る、テストベンダーへの外注体制を整える、といったQA参画直後にやる動きはあくまで「手段」であり、本質的な解決策ではない
２．まずはミニマムで開始し、効果を出していくこと
→ 数値目標を小さく立てて継続的に施策の効果をモニタリング、目標達成にこだわること
３．リソースやコストを鑑みた優先度付け、課題にフォーカスした施策決定を行うこと
→ 自動化を導入しよう、プロセスを改善しよう、といった開発現場で実施可能な「HOW」の内容に人は思考がどうしても行きがち
また、参画時にはじめにQAが立てるべき問いとしては下記が挙げられます。
１．そもそも何を解決しなければいけないのか？何が問題になっているか？
２．初めに設定した課題の解決に紐づいたアクションをとれているか？
３．目の前の事象に囚われて「イシューずれ」を起こしていないか？
４．数値でQA効果を可視化できる状態になっているか？
この問いがはじめに立てられていれば、「今何をするべきか」を見失うことはありません。
初心者に限らず、慣れた人でも陥りがちなこの状態は常に注意していく必要があると思います。
QAが参画初期にやるべきこと
私たちがQAエンジニアとして現場に参画した際、下記の順で進めていくのが良いのではとビジネス思考力を学び始めた今では考えています。
現状把握
まずは、システム・現場はどのような状態であるか？の現状を把握し、どこで問題が集中しているか？の認識から始めます。
具体例）
・過去発生した不具合情報を集め、どこで致命度の高い不具合が多発しているか確認する
・今開発チームで実施している品質活動の調査
・開発チーム・マネージャー層・経営層へ課題感のヒアリングを行う 等
理想像の定義
次に目指すべき姿の定義です。ここはQA/開発現場だけでなく組織全体を巻き込んで定義を行っていきましょう。定性的な目標に加え、KGI(最終の数値目標)についても検討します。
具体例）
・現状の調査結果の報告
・会社のミッション・ビジョン・バリューや事業の方向性、取り巻く環境の把握
・開発チーム・マネージャー層・経営層とのディスカッションによる、その組織が本当に求める品質の定義 等
課題の抽出
次に「解決するべき課題」を設定します
具体例）
・「抱える問題はこのような原因で発生しているのではないか」という仮説のもと情報収集を行う
・過去不具合やユーザーのサービス解約率等に関する原因分析
・開発プロセスのボトルネックと考えられる部分の実際の工数・体制 等
・ステークホルダーそれぞれからのヒアリング
・集めた情報を整理し、それらの情報から総合的に課題を抽出する
・発生した不具合分類の集計結果やヒアリング結果により、仕様に関するドキュメントのレビューが不足しており、仕様バグ・設計バグが多発したことが判明。上流工程以降の全工程で誤った実装・テストがされてしまっている。 等
施策の検討
課題がはっきりしたら、次は問題を解決し理想像とのギャップを埋めるための施策の検討です。
具体例）
・QA施策として上流からのドキュメントレビューを行う、レビュー観点整備を開始することを優先度高で実施
・開発のボトルネックとならないよう、リソース調整を行う 等
ここまでのアクションについては、「ビジネス思考力とは？」でご紹介したこちらの書籍のフレームワークがとても助けになりました。
実施する施策については、一般的に必要とされている手段や自身が得意とする手段がどうしても先に出てきてしまうので、このようにしっかりと課題を認識したうえで、効果的な施策を検討し優先度をつけてアクションの取捨選択をしていくことが重要です。
KPI設定
課題に紐づく施策を検討出来たら、実際に施策を実行していくうえでの、KPI(中間の数値目標)を立てていきます。
具体例）
・新規機能に対する市場流出不具合件数
・サービスのチャーンレート
・開発プロセス・欠陥種別ごとの指摘起票件数 等
KPIを追うことは目標達成に有用ですが、いくつか注意点もあります。
KPI設定時に陥りやすい点については下記の記事を参考にしています。
モニタリングの仕組みづくり
最後に、設定したKPIの達成状況を細かくウォッチし、仮説の検証や軌道修正を行っていくためのモニタリングの仕組みづくりを行います。
具体例）
・分析ツールやスプレッドシートを利用したダッシュボードの構築
・日次、週次、月次毎の集計・振り返り・FBのスケジューリング 等
参画直後にここまでの動きをステークホルダーと合意形成しながら進められれば、大変良いスタートが切れたといえるのではないでしょうか。
おわりに
QAに求められるビジネス思考力、というテーマで記事を書いてみました。
今回は「論点思考」にフォーカスしましたが、「クリティカルシンキング」「抽象化思考」「分析思考」など、QAの業務の中で必要とされるビジネス思考力は多岐にわたります。
QAが普段実施する活動とそれぞれの思考法一つ一つについて本来は深堀ができるテーマであると考えています。
クリティカルシンキング(批判的思考)・ラテラルシンキング(水平思考)：
対象や前提条件を疑い、致命的な不具合を検出するためのテストを抜けもれなく実施する際に必要
抽象化思考：
具体的なユースケース⇔ハイレベルなテストケースを行き来し、多角的な視点でのテスト戦略・アプローチ方法を検討する際に必要
分析思考：
テスト結果や過去不具合などの事実から、今発生している問題との関係性を整理し、正しい意思決定や具体的アクションに結びつける。
etc…
QAこそ、プロダクト・組織の「欠陥」という問題に直に向き合う、開発現場のどのロールよりも高いビジネス思考力が求められるロールなのではと今では考えています。
来たるAI時代、知識ではなく、「いかに適切な問いを立てられるか」が重要になってきますが、QAの「Q」は「Quality」であると同時に「Question」でもあるのでは。
適切な問いを立てることの重要性については下記の書籍もおすすめです。
ビジネス思考力は現在自分が担当している採用活動という未経験の新しい領域も含め、あらゆる対象に活用していける力と感じます。
どんなプロダクト・組織の品質課題も見極め、解決に導いていけるような次世代QAの理想像を今後も描き続け、チーム全体で近づいていければと考えています。
この記事が気に入ったらサポートをしてみませんか？