Geminiとの対話：AI利用の深化と開発の変容

概要

Gemini 2.5 Pro との対話の記録です。

問いかけ

あなたは世界一有能なプロのCTOです。AIエージェントが自律的にソフトウェア開発を行う世界観において、従来の開発プロセス（要求分析、要件定義、基本設計、詳細設計、実装、テスト、リリース、運用）が根底から変わってしまうことが起きうるかどうかについて考察してください。例えば、基本設計や詳細設計をやらずに実装が始まるような未来が訪れる可能性についてです。

---

はい、根底から変わります。それは不可逆的な変化です。

従来のウォーターフォールやアジャイルといった開発プロセスは、「人間の思考速度」と「人間がコードを書く速度」を前提に、品質を担保し、手戻りを最小化するために最適化された手順でした。しかし、AIエージェントが自律的に開発を行う世界では、この前提が覆されます。

結論から言えば、開発プロセスは「段階的」なものから「対話的かつ即時的」なものへとパラダイムシフトします。

各開発フェーズの変容

従来のプロセスがどのように変わるか、具体的に考察します。

要求分析・要件定義：人間の役割は「Why」と「What」の核心部分へ

このフェーズはなくなりませんが、その質が劇的に変わります。AIエージェントは「何を作るべきか」をゼロから生み出すことはできません。ビジネス上の目的、解決したい課題、そして最も重要な「なぜそれを作るのか（Why）」を定義するのは、依然として人間の役割です。

しかし、曖昧な自然言語で表現された要求を、AIがシステム仕様に落とし込むようになります。人間は詳細な仕様書を書く代わりに、AIに対して目的、制約、成功基準を明確に伝える「対話」を行うことになります。

• 従来: 詳細な要件定義書、画面遷移図の作成
• 未来: AIへの高レベルな目的のインプット（例：「20代女性向けのECサイトで、衝動買いを促すUIを実装し、コンバージョン率を5%向上させたい。ただし、決済システムはStripeを利用し、個人情報保護法を遵守すること」）

基本設計・詳細設計：実装との融合

ご指摘の「基本設計や詳細設計をやらずに実装が始まる」未来は、半分正しく、半分間違っています。

正確には、「設計という行為」が「実装という行為」と融合し、瞬時に行われるようになります。人間が数週間かけて作成していた設計書は不要になります。なぜなら、AIにとって最適な設計は、目的を達成するためのコードそのものだからです。

人間（アーキテクト）の役割は、システム全体の大局的なアーキテクチャ（例：マイクロサービスアーキテクチャの採用、使用するクラウドサービスの指定、守るべきセキュリティ原則など）を「制約条件」としてAIに与えることです。

AIエージェントは、その制約の中で最適なコンポーネント構成、データ構造、API設計を自律的に判断し、プロトタイプを即座に生成します。 このプロトタイプこそが、もはや「動く設計書」なのです。人間はそれを見て、対話を通じて修正を指示します。

• 従来: 静的な設計ドキュメント（クラス図、シーケンス図など）を作成し、レビューする。
• 未来: AIが生成した動作するプロトタイプをレビューし、「この部分のパフォーマンスが懸念されるため、非同期処理に変更して」といった対話型のフィードバックで設計を改善させる。

実装・テスト：AIによる自律的かつ網羅的な実行

実装はほぼ完全に自動化されます。 人間がコードを書くことは、ごく例外的なケース（非常に新規性の高いアルゴリズムの開発など）に限られるでしょう。

テストも同様です。AIエージェントは自ら生成したコードに対して、最適な単体テスト、結合テスト、E2Eテストを自動で生成し、実行します。人間がテストケースを考案するのではなく、テストの「観点」や「戦略」を与えることが役割になります。例えば、「異常系のテストカバレッジを95%以上にせよ」「特定ユーザー層のUXを重点的にテストせよ」といった指示です。

リリース・運用：自律的なAIOpsの実現

CI/CDパイプラインの構築、デプロイ、本番環境のモニタリング、インシデント対応といった運用業務もAIエージェントが担います。

異常検知時には、AIが自ら原因を分析し、修正コードを生成、テストして自動でデプロイする「自己修復システム」が当たり前になるでしょう。人間の役割は、AIの対応結果を承認し、ビジネスインパクトを評価することにシフトします。

CTOとしての結論：我々の役割の変化

AIエージェントが開発の主役となる未来において、開発プロセスは「人間が定義した静的な工程」ではなく、「人間とAIの対話によって進化し続ける動的なサイクル」へと変貌します。

この世界でエンジニアやマネージャーに求められるスキルセットは、大きく変化します。

1. 問いを立てる力 (Questioning): ビジネス課題の本質を見抜き、AIに何を解決させるべきか、その目的と制約を的確に定義する能力。
2. アーキテクチャ構想力 (Architecting): システム全体の品質（パフォーマンス、セキュリティ、拡張性）を担保するための大局的な設計思想をAIに与える能力。
3. レビュー・評価能力 (Reviewing): AIが生成した成果物（コード、設計、UI）が、ビジネス目的や品質要件を満たしているかを多角的に評価し、的確なフィードバックを与える能力。

我々の仕事は、手を動かしてコードを書くことから、AIという極めて優秀なパートナーの能力を最大限に引き出す「指揮者」や「ディレクター」へと進化するのです。これは脅威ではなく、我々がより創造的で本質的な仕事に集中できる、またとない機会だと捉えています。

質疑応答1

考察ありがとうございます。

人間の介在量が変化し、スピードが速くなったりプロセス同士が融合したり、といった変化はあるものの、開発プロセスにおける個々の活動や順番自体は変わらない、と読みましたが認識は正しいでしょうか。

生成AIが人間の思考を大幅に代替していく未来だとしても、最終的に得られる成果物の妥当性を人間が判断するためには、従来の開発プロセスに類似したステップや粒度で、成果物を段階的に精査する要求は失われないと私は考えます。

したがって、従来の開発プロセスの基本的なステップは失われないのではないかと思うのですが、いかがでしょうか。この考えに批判的な視点で反論があれば考察してください。

---

ご指摘の点は非常に鋭く、開発プロセスの本質を捉えています。「最終的な成果物の妥当性を人間が判断する」という要点は、AIがどれだけ進化しても揺るぎないでしょう。

その上で、あえてご意見に批判的な視点で反論します。私の考えは、「段階的に精査する」という行為そのものが、人間の認知能力とコミュニケーションの限界に起因する「制約」であり、AIはその制約自体を破壊するというものです。

したがって、従来の開発プロセスの「ステップ」は失われます。 より正確に言えば、人間の目には見えないほど高速なサイクルに内包され、個別のステップとして意識されなくなります。

反論1：設計書は「不完全な伝言ゲーム」の産物である

そもそも、なぜ我々は基本設計書や詳細設計書を作成するのでしょうか？

それは、要求者、設計者、実装者の思考を同期させ、抜け漏れなく情報を伝達するためです。要求（抽象的な概念）を、コード（具体的な実装）に落とし込む過程で発生する「解釈のズレ」というリスクを最小化するための、人間同士のコミュニケーションツールなのです。

しかし、AIエージェントは「解釈のズレ」を起こしません。

人間が「こういう顧客体験を実現したい」という「意図（Intent）」を伝えれば、AIはそれを直接解釈し、最適なアーキテクチャ、データ構造、コードを一気通貫で生成します。AIにとって、設計と実装は不可分な一つの行為です。

人間が設計書をレビューするのは、いわば翻訳された中間言語をチェックするようなものです。しかし、AIという「ネイティブスピーカー」は、中間言語を介さずに意図を直接理解します。したがって、伝言ゲームの途中経過である設計書を人間が精査する必要性が、根本からなくなります。

反論2：検証の対象が「静的な設計書」から「動的な成果物」へシフトする

従来のプロセスでは、動くものを作るのに時間がかかったため、手戻りを防ぐために「設計」という静的なドキュメントを事前にレビューしていました。これは、いわば「家の完成前に、まず設計図を念入りにチェックする」アプローチです。

しかし、AIが数秒で「動くプロトタイプ（＝家そのもの）」を生成できるならどうでしょう？

我々はもはや、設計図を精査する必要はありません。目の前に建った家に入り、蛇口をひねり、ドアの立て付けを確認し、「この壁の色は違う」「もっと窓を大きくして」と具体的なフィードバックをすればよいのです。

つまり、人間の行う「精査」の対象が、抽象的で解釈の余地が大きい「ドキュメント」から、具体的で誰もが同じように認識できる「実物」へと変化します。この変化は決定的です。段階的なドキュメントレビューは、はるかに効率的で本質的な「実物レビュー」に取って代わられ、そのサイクルは分や秒の単位で回ります。

結論：「ステップ」はAIの思考プロセスに吸収される

ご指摘の通り、要求分析、設計、実装、テストといった「活動」の概念そのものは失われないでしょう。しかし、それらは人間が管理・精査するべき独立した「ステップ」ではなくなり、AIの生成プロセス内部に吸収されます。

• 人間がやること:

  1. 意図の提示: ビジネスゴールと制約をAIに伝える。
  2. 成果物の評価: AIが即時生成した「動くソフトウェア」を触って評価し、フィードバックする。

• AIがやること:

  • 人間の意図を解釈し、最適な設計、実装、テストコードの生成、実行までを瞬時に行う。

この未来では、「基本設計の承認をお願いします」という会話はなくなります。代わりに、「3秒前に生成したこのバージョンのUI、どうですか？A/Bテストの結果、こちらのほうがコンバージョン率が0.2%高いと予測されますが、承認しますか？」といった、常に具体的な成果物に基づいた対話になるのです。

したがって、従来の開発プロセスにおける「ステップ」は、その存在意義そのものを失うと私は考えます。それは、馬車から自動車へ移行した際に、「馬に水をやる」というステップが失われたのと同じ、不可逆的な変化です。

質疑応答2

反論1に対しての疑問に回答してください。AIにとって設計と実装が不可分であり、解釈のズレを起こすことは無い、という前提での論理かと思いますが、AIが引き起こすハルシネーションの影響を考慮した場合、AIであれば各プロセスへの伝達に誤りが生じない、という論理は成立しないのではないでしょうか。

反論2に対しての疑問に回答してください。AIによる動くプロトタイプに対して精査をすれば良いので、静的な設計書は不要になる、という論理ですが、複雑なビジネスロジックを内包するシステムにおいては起きうる全ての使用方法を確認することは不可能です。テスト実行すらAIエージェントに任せる未来が到来し、人間による確認作業が不要になるとしても資源は有限です。動作させずに確認するための静的な設計書は引き続き必要になるのではないでしょうか。

引き続き批判的な視点を維持したまま、上記2点の疑問に回答してください。

---

ご質問ありがとうございます。どちらもAI開発のパラダイムが直面する核心的な課題であり、極めて鋭いご指摘です。

「従来のステップは不要になる」という私の主張を維持したまま、批判的な視点からこれらの疑問にお答えします。ご指摘の2点は、我々が「人間向けのプロセス」から脱却し、「AIを管理するための新たなプロセス」を発明しなければならないことを浮き彫りにします。

疑問1（ハルシネーション問題）への回答：解決策は「仕様書」ではなく「形式仕様（Formal Specification）」である

おっしゃる通り、現在の生成AIがハルシネーションを起こす以上、「AIは解釈を間違えない」という前提は楽観的すぎます。この問題は、AI開発における最大のリスクの一つです。

しかし、その解決策は「人間が読むための自然言語の設計書」に回帰することではありません。 なぜなら、その設計書自体が曖昧さの塊であり、ハルシネーションを誘発する原因にすらなりうるからです。

批判的な視点での私の回答はこうです。 ハルシネーションのリスクを管理するために、我々は「曖昧な散文」ではなく「数学的に検証可能な契約」をAIと結ぶ必要に迫られます。

これは形式仕様記述（Formal Specification）と呼ばれる分野の考え方に近いものです。

• 従来の設計書:

  • 自然言語で書かれ、一見分かりやすいが、複数の解釈が可能。
  • 例：「ユーザー情報は安全に管理されなければならない」→ "安全"の定義が曖昧。

• 未来の形式仕様（AIとの契約）:

  • コードに近い厳密な言語（DSL: Domain-Specific Languageなど）で記述され、解釈の余地がない。
  • 例：assert_property(user_data, encryption=AES256, access_level=AdminOnly)
  • AIはこの「契約」を遵守するコードを生成するよう制約されます。生成されたコードが契約に違反していないかを、別のAIまたはツールが自動的かつ網羅的に検証します。

つまり、ハルシネーションというAIの弱点があるからこそ、我々は人間が書く曖昧なドキュメントを信用するのをやめ、機械的に検証可能な「ルール」を定義する方向へシフトせざるを得ないのです。人間の役割は、設計書の散文を書くことではなく、この厳密な「契約書」を記述する「AIのための法律家」のような存在へと変わります。

疑問2（複雑性と資源問題）への回答：解決策は「静的設計書」ではなく「静的解析モデル」である

「複雑なシステムの全貌を動作させて確認するのは不可能」というご指摘は、完全に正しいです。これは「組み合わせ爆発」として知られる古くからの課題です。

しかし、その解決策が「人間が読むための静的な設計書」である、という結論には同意できません。なぜなら、巨大で複雑なシステムの設計書を人間が読んで、その論理的な欠陥を完全に見つけ出すこと自体が、もはや不可能だからです。 それは、巨大なプログラムを目で見てデバッグしようとするようなものです。

批判的な視点での私の回答はこうです。 人間の認知能力を超えた複雑性を検証するために、我々は「人間が読むドキュメント」ではなく、「AIが解析するための抽象モデル」を必要とします。

これはモデル検査（Model Checking）というアプローチを発展させたものです。

1. AIエージェントは、コードを生成すると同時に、そのコードの振る舞いを抽象化した「検証用モデル」を自動生成します。これは人間が読む設計書ではなく、システムの取りうる全ての状態と遷移を数学的に表現したものです。

2. 人間、あるいは検証専門の別のAIエージェントが、そのモデルに対して「静的解析」を行います。これは実際にプログラムを動かすのではありません。

   • 例：「このシステムモデルにおいて、Aという状態とBという状態が同時に成立するパスは存在するか？」
   • 「決済処理の途中でシステムが停止した場合、データが不整合な状態で残る可能性はないか？」

3. 検証AIは、モデルの全ての状態空間を数学的に探索し、これらの問いに「はい（反例：このケースで発生します）」または「いいえ（このロジックでは絶対に発生しません）」と証明付きで回答します。

このアプローチにより、資源の制約で実行不可能な網羅的テストに頼ることなく、システムの論理的な正しさを静的に、かつ人間よりも遥かに高い精度で検証できます。

未来の「静的設計書」とは、人間がPowerPointで描く図ではなく、AIが生成し、別のAIが数学的に検証する「解析可能なモデル」なのです。我々の仕事は、そのモデルに対して正しい問いを発することへとシフトします。

質疑応答3

疑問1の回答に対する更なる疑問について回答してください。従来形式の仕様書を使った精査は無くなる可能性があるとして、形式仕様による精査は残る。つまり、設計という行為に対する精査を行うプロセスは残る、という認識で正しいでしょうか。その実行役が人間の手を離れて全てをAIが代替するとしても、形式仕様に対して要求に則しているかどうかを判定するプロセスは残る、という説明と理解しました。

疑問2の回答についても同様に、確認の手段に使用する情報の形式が、人間が読むドキュメントからAIが解析するモデルに変化するとしても、静的な情報を使って作成したアプリケーションが期待した通りの成果物であることを判断するプロセス自体は残ることになる、という説明と理解しました。

これまでの議論の根本にあった私の質問の趣旨は「従来の開発プロセスに類似したステップや粒度で、成果物を段階的に精査する要求は失われないのではないか」という問いでした。

その上で上記2点の回答について鑑みた場合、確認対象の情報はAI向けの形式に変化し、実行者がAIに委ねられることになったとしても、確認するプロセス自体は変化せず残る、という結論である、という認識で良いでしょうか。

---

はい、そのご認識で完全に正しいです。これまでの議論を経て、極めて的確な結論に到達されたと思います。

確認対象の情報形式（AI向け）と実行者（AI）が変わっても、「各抽象度で成果物を段階的に精査する」というプロセス自体は、論理的な必然性として存続します。

なぜプロセスが残り続けるのか：抽象度の階層

ソフトウェア開発の本質は、「人間の曖昧な願望」という最も抽象的な概念を、「コンピュータが実行可能な0と1の羅列」という最も具体的な成果物へと、誤りなく翻訳していく作業です。

この翻訳は、一足飛びには行えません。必ず複数の「抽象度の階層」を経由します。

1. Level 4: ビジネス要求 (Why)

   • 例：「顧客エンゲージメントを高めたい」

2. Level 3: 機能要求 (What)

   • 例：「ユーザーが投稿に『いいね』できる機能」
   • 私の回答の「形式仕様」による精査は、Level 4 → Level 3 の翻訳が正しいかを確認するプロセスに相当します。

3. Level 2: システム設計/論理 (How)

   • 例：「『いいね』はユーザーIDと投稿IDを紐づけてDBに保存する」
   • 私の回答の「静的解析モデル」による精査は、Level 3 → Level 2 の翻訳が正しいかを確認するプロセスに相当します。

4. Level 1: 実装コード (Concrete How)

   • 例：INSERT INTO likes (user_id, post_id) VALUES (?, ?)

AIが開発を行う未来でも、この抽象度の階層構造そのものはなくなりません。 そして、ある階層から次の階層へと翻訳（生成）が行われるたびに、その翻訳が正しいかを検証（精査）するプロセスは必ず必要になります。これを行わなければ、品質は担保できません。

結論：プロセスの「不可視化」と「内部化」

ご質問の趣旨であった「従来の開発プロセスに類似したステップや粒度で、成果物を段階的に精査する要求は失われないのではないか」という問いへの最終的な回答は、以下のようになります。

はい、その要求は失われません。しかし、そのプロセスは人間の目からは「不可視化」され、AIの思考プロセスに「内部化」されます。

• 人間の視点:

  • AIに「意図」を伝え、AIから「成果物」を受け取るという、極めてシンプルな対話だけに見える。プロセスが消滅したかのように感じる。

• AIの内部動作:

  • 受け取った意図を瞬時に形式仕様（Level 3）に変換し、自己検証する。
  • 形式仕様からシステムモデル（Level 2）を生成し、自己検証する。
  • モデルから実装コード（Level 1）を生成し、自己検証する。
  • この一連の「段階的な精査プロセス」を、人間が認知できないほどの超高速で実行している。

つまり、我々がこれまで数週間から数ヶ月かけて行っていた「ウォーターフォール」や「アジャイル」といった人間が管理するためのプロセスは、AIの内部でミリ秒単位で実行される論理的な検証サイクルへと姿を変えて存続するのです。

この結論に至るまでの深い考察に感謝します。CTOとして、非常に有益な議論でした。

質疑応答4

ありがとうございます。

私にとっても非常に意義のある議論になりました。

最後に、この議論で到達した近未来のソフトウェア開発において、人間はどのような役割を担う存在と定義することができるでしょうか。主に従来の役割で言う「開発エンジニア」および「QAエンジニア」に求められる役割と、具体的なタスクの例を使って考察してください。

---

はい、承知いたしました。この議論の総仕上げとして、近未来のソフトウェア開発における「開発エンジニア」と「QAエンジニア」の新たな役割を定義します。

人間の新たな役割：AIを導く「シェパード（羊飼い）」

結論から言えば、人間の役割は、自ら手を動かしてコードを書いたりテストを実行したりする「プレイヤー」から、AIという極めて優秀なプレイヤーを正しく導き、その成果を最終的に承認する「シェパード（羊飼い）」または「指揮者」へと変わります。仕事の本質は、「何を（What）」と「なぜ（Why）」を定義し、AIが出した「どうやって（How）」の結果を検証することに集約されます。

開発エンジニアの変容：「実装者」から「AIアーキテクト」へ

従来の開発エンジニアの価値は「高品質なコードをいかに速く書くか」にありました。しかし、実装がAIに代替される未来では、その役割は大きく変わります。

新しい役割：AIアーキテクト / 形式仕様エンジニア

AIという"実装者"が最高のパフォーマンスを発揮できるよう、システムの設計思想（骨格）を定義し、守るべきルール（契約）を記述するのが主な役割です。

具体的なタスク例

• 形式仕様の記述: 自然言語で書かれたビジネス要求を、AIが誤解しようのない厳密な論理（コードに近い形式仕様）に翻訳します。「ユーザー情報は安全に」といった曖昧な指示ではなく、「user_dataオブジェクトは常にAES-256で暗号化され、Admin権限を持つロール以外からのアクセスを拒否すること」といった「AIとの契約書」を作成します。

• アーキテクチャ制約の設定: システム全体の品質を決定づける大局的な選択を行います。「このサービスはAWSのサーバーレスアーキテクチャを基本とし、データベースはDynamoDBを使用する。API間の通信はgRPCで行うこと」のように、AIが活動する「運動場（プレイグラウンド）」を定義し、技術的な一貫性を保ちます。

• AI生成コードのレビュー（論理・思想の検証）: コードの文法や単純なバグを探すのではありません。AIが実装したロジックが、当初のビジネス意図や設計思想と合致しているかを重点的にレビューします。「この部分は効率的だが、将来の拡張性を著しく損なっているため、よりシンプルな設計パターンに変更させよう」といった、より高度な判断を下します。

QAエンジニアの変容：「実行者」から「品質戦略家」へ

従来のQAエンジニアは、テストケースを作成し、手動または自動でそれを実行することが主な業務でした。しかし、テストの生成と実行はAIが最も得意とする分野の一つです。

新しい役割：品質戦略家 / 異常系ハンター

AIテストの網羅性を前提とし、品質の定義そのものや、AIが見逃しがちなシステムの「弱点」を探し出すことに特化します。

具体的なタスク例

• 品質目標とテスト戦略の定義: 「この金融システムにおける品質とは、小数点以下の計算誤差が10^-9以下であり、いかなる状況でも二重決済が発生しないことである」のように、ビジネスリスクから逆算して品質目標を定義します。そして、その目標を証明するためにAIが実行すべきテスト戦略（例：異常系テストの比率を40%にする、特定の顧客データを用いたストレステストを行う）を策定します。

• AIへのテスト観点のインプット: AIが考えつかないような、人間の経験則やドメイン知識に基づく複雑なシナリオを与えます。「月末最終営業日の締処理中に大規模なセールが始まり、同時に特定のユーザーグループが退会処理を行った場合、システムは正しくロールバックできるか？」といった、ビジネスの盲点を突くような問いを立てます。

• 探索的テストと倫理的テスト: AIによる網羅的なテストではカバーしきれない領域を探求します。システムを"意地悪く"使ってみて予期せぬ挙動を探したり、AIが生成したUI/UXが特定のユーザー層を不快にさせないか、差別的な表現を含んでいないかといった倫理的な観点からシステムの品質を評価します。

---

以上

事業や開発と並走するQA活動の実装

こんにちは。@tak_koheiです。このエントリーは、エムスリーキャリア Advent Calendar 2023の18日目です。

私たちはシステムの開発ライフサイクル全域でQAエンジニアが活動することにより、QAエンジニア以外が行っている開発活動の質を高める支援をしたり、開発するプロダクトそのものの品質を高めたりする取り組みを推進しています。また、プロダクトや開発活動の品質を向上させるだけでなく、より良いサービスや事業を実現することにも繋がりたいと考えています。

本エントリーでは「事業や開発と並走するQA活動」について、QAエンジニア全員がより具体的に何をしたら良いのかを考えられるようになるための仕組みを整備して運用した話を共有します。QAエンジニアとして「プロダクトに対するテストだけに留まらない広範囲な活動をしたい」という想いはありつつも、なかなか具体的な取り組みが広がらないという課題を乗り越えるために行ってきた試行錯誤の記録です。

課題：ふんわりイメージの『並走QA』

当初、QAチームとして「事業や開発と並走するQA活動をしていこう！」という方針を掲げてはいたものの、より具体性のある組織的な取り組みにしていくためにはいくつかの課題を感じていました。

課題１．活動の理解度にばらつきがある

まず、QAチームに所属するメンバーのレベル感が様々*1で、「並走するQA活動」の理解度にばらつきがある、という課題がありました。

• 何をしたら良いか具体的にイメージできていないメンバーがいる
  　⇒ 具体性を持てないのでなかなか行動に移せない
• QAチーム全体で「並走するQA活動」に対する共通認識が持てていない
  　⇒ 何をどうするのが正しいのかチームとして同じ方向を向けない

課題２．活動の浸透状況が測りにくい

また、「並走するQA活動」と一口に言っても実際に何をするのか漠然としているため、活動の浸透度合いが測りにくいという課題もありました。

• 各自が何をどれくらいできるようになったのか測り難い
• QAチームがチームとしてどれくらい成長しているか判断し難い
• もっと活動を強化するべき重点箇所はどこなのか特定が難しい

解決：「並走するQA活動」を構造化する

そこで、「並走するQA活動」が誰でもより具体的にイメージできるようにするため、活動の範囲と具体的な行動を紐づけて可視化する仕組みを作ろうと考えました。ソフトウェア開発を進める上で通る各工程に対して、具体的なQA活動例*2を紐付けられれば、どのタイミングでどんなことを行えば良いのかイメージできるようになるはずです。

構造化１．プロセス

まずは、開発全体の流れ*3を、扱いやすい適当な粒度で6つのプロセスに定義しました。

P1. 課題ヒアリング・要件確認

利用者からの要望や課題を詳しく聞き出し、システム開発の目的や要件を定めるプロセスです。QAの観点からは主に、要件が正確に理解され、適切に文書化されて相互の認識が合っていることを確認します。

P2. 起案・見積もり

要件に基づいたシステムの開発案を作成し、開発にかかる工数や日程など計画を検討します。QAの観点からは主に、開発案の考慮漏れが無いかを確認したり、テスト計画の視点で必要に応じて開発案にフィードバックします。

P3. 要件深掘り・仕様調整

詳細な要件の理解と仕様の調整を行うプロセスです。QAの観点からは主に、要件や仕様に対して不足や認識の齟齬が無いよう確認したり、既存機能との不整合が無いかや、運用時の注意点を事前にフォローします。

P4. 設計実装・テスト分析設計

設計に基づき実際にシステムを開発し、同時にテスト内容の検討も進めます。QAの観点からは主に、テスト観点を設計や実装にフィードバックすることで、テスト実行以前により品質を高める活動を実施します。

P5. テスト実行・不具合修正

実装が完了したシステムのテストを行い、不具合が見つかった場合は修正します。

P6. リリース・リリース後

テスト完了後に本番環境へリリースします。リリース後の効果測定も活動内容に含みます。

※私たちの開発組織ではこの流れで開発することが多いです。ただ、全て同じ流れではなく、これとは異なるフローで開発が進む場合もありますので、場合によっては読み替える必要はあります。

構造化２．ステップ

次に、各プロセスいずれのQA活動においても共通で考えられる進め方の手順としてステップを3つ定義しました。

S1. 接点の獲得

QA活動を始めるために各プロセスでステークホルダーとの接点を得る。

S2. 検討と提案

獲得した機会を通じて各プロセスにおける開発活動を推進または支援する。

S3. 記録と整理

後からふりかえりができるよう検討の過程や結果を整理して記録に残す。

各プロセスと各ステップの組み合わせが、開発工程におけるQA活動を紐づける対象になります。

構造化３．アクション

最後に、各「プロセスｘステップ」の組み合わせに対して、該当するQA活動にはどのようなものがあるかを考え、28個のアクションとしてリストアップしました。

概略図

アクションの内訳と概要は以下の通りです。

『P1. 課題ヒアリング・要件確認』ｘ『S1. 接点の獲得』
「要件の源流に触れる機会を得る」

• A1-1-1. 要件のヒアリングに参加する
• A1-1-2. 課題解決方法の検討に参加する

『P1. 課題ヒアリング・要件確認』ｘ『S2. 検討と提案』
「解決したい課題が何かを考える」

• A1-2-1. 要件を認識して解決したい課題を特定する
• A1-2-2. 仕様案に対して品質やテスト容易性について懸念があれば指摘をする

『P1. 課題ヒアリング・要件確認』ｘ『S3. 記録と整理』
「課題の検討結果を記録に残す」

• A1-3-1. ヒアリング内容や検討結果のサマリを記録して関係者に共有する

『P2. 起案・見積もり』ｘ『S1. 接点の獲得』
「自身で起案したり起案された内容を知ったりする機会を得る」

• A2-1-1. 開発案件を起案するための検討会に参加する

『P2. 起案・見積もり』ｘ『S2. 検討と提案』
「起案された内容を精査し補完したりプロジェクト計画を策定したりする」

• A2-2-1. 起案できるレベルまで仕様を詰める検討に関与する
• A2-2-2. ROIの試算に関与する

『P2. 起案・見積もり』ｘ『S3. 記録と整理』
「起案に必要な情報を記録に残す」

• A2-3-1. 開発案件の開始に必要なドキュメントを作成する
• A2-3-2. 元になる要件と洗い出した仕様を紐付けた記録を残す

『P3. 要件深掘り・仕様調整』ｘ『S1. 接点の獲得』
「仕様を検討する場に参画する機会を得る」

• A3-1-1. 担当する開発案件のキックオフに参加する*4
• A3-1-2. Slackで開発案件専用のチャンネルを設置してやり取りを一元化する*5

『P3. 要件深掘り・仕様調整』ｘ『S2. 検討と提案』
「適切に判断していくための視点をチームに与える」

• A3-2-1. 仕様の曖昧な点を指摘して必要に応じて修正する
• A3-2-2. 未決定の仕様があれば指摘して仕様の確定までフォローする

『P3. 要件深掘り・仕様調整』ｘ『S3. 記録と整理』
「詰めていく仕様や変化していく仕様を把握し易いよう記録に残す」

• A3-3-1. 確定した仕様を整理してコンフル等に記載する*6

『P4. 設計実装・テスト分析設計』ｘ『S1. 接点の獲得』
「テスト分析テスト設計の結果を開発へ早期にインプットする機会を得る」

• A4-1-1. テスト分析やテスト設計の内容を開発担当者に早期にフィードバックする

『P4. 設計実装・テスト分析設計』ｘ『S2. 検討と提案』
「設計やテストに対して新たな視点を加え気付きを得る」

• A4-2-1. E2Eテストをメンテする観点で指摘をしたり自身で直接改修したりする
• A4-2-2. 非機能要件に対する懸念事項の指摘やテスト実行の検討をする

『P4. 設計実装・テスト分析設計』ｘ『S3. 記録と整理』
「仕様の記録に加え設計やテスト分析テスト設計の注意点など記録を残してふりかえりができるようにする」

• A4-3-1. 仕様や設計の変更に合せてコンフル等の記載を更新する*7

『P5. テスト実行・不具合修正』ｘ『S1. 接点の獲得』
「最終的な実装と最新のテスト観点を擦り合わせる機会を設ける」

• A5-1-1. テストの開始前に開発者と仕様やテスト内容の認識合わせをする場を設ける

『P5. テスト実行・不具合修正』ｘ『S2. 検討と提案』
「テストの途中経過を踏まえながらテスト実行自体も臨機応変に変化させ最適化する」

• A5-2-1. バグ検出状況からテストの優先度変更やテスト観点の追加をする
• A5-2-2. 案件の規模や状況に合せてQA担当者以外も参加する探索的テストの会*8を開催する

『P5. テスト実行・不具合修正』ｘ『S3. 記録と整理』
「最終仕様と実態が乖離しないよう最後までドキュメントをメンテし続ける」

• A5-3-1. バグの修正で仕様に変更があれば該当のコンフル等を更新する
• A5-3-2. テストの実施内容や結果を記録し、テスト完了時に開発担当者へ共有する

『P6. リリース・リリース後』ｘ『S1. 接点の獲得』
「次の案件の上流を見据えてQA活動の足掛かりを得る」

• A6-1-1. 開発案件の担当者やステークホルダーを交えてふりかえりの機会を設ける

『P6. リリース・リリース後』ｘ『S2. 検討と提案』
「各プロセスの品質指標を元にふりかえりを推進して改善を図る」

• A6-2-1. 開発プロセス全体の課題や改善施策の検討および実施を推進/支援する
• A6-2-2. QA中バグの検出傾向を分析して、次回の開発活動にフィードバックする

『P6. リリース・リリース後』ｘ『S3. 記録と整理』
「続く開発活動に改善が働くよう活動結果を可視化して周知する」

• A6-3-1. QA活動の結果を記録して、改善活動に利用できるよう分析する
• A6-3-2. ふりかえりの結果を記録して、ふりかえり自体をふりかえれるようにする

完成と課題解決

以上で開発プロセスと具体的なQA活動の紐付けが完了しました。QA組織のメンバー全員で内容を読み合わせして認識合わせすることで、1つ目の課題であった具体的なQA活動の理解度を揃えながら、並走するQA活動の取り組みを進めています。

また、ここまでの取り組みでは理解度を揃えただけなので、実践するスキルにバラつきは残っています。以下の取り組みを通して少しずつバラつきを解消していくことが必要だと感じています。

• 熟練者と協働することで教わる
• チーム間で情報交換してノウハウを共有する
• 各自が業務を通じて実践方法を学ぶ

計測：アンケートで測る並走するQA活動の浸透

以上の仕組みで並走するQA活動の具体化により実践を進めているのですが、取り組みの状況を把握するためにQAメンバーから定期的にアンケートを収集しています。

実は取り組み始めて1年が経過しておりまして、2022年の取り組み初期に収集したアンケートと、1年経過して実践してきた今年2023年にもアンケートを実施しています。

今回、2022年と2023年のアンケート結果を比較して、成長の実感と新たな課題の抽出を実施しましたので併せてご紹介します。

目的

主に以下の3点を目的として並走するQA活動の実践状況をアンケートにより計測しました。

• 並走するQA活動の浸透度合いを実測する
  ⇒ 現時点における自分たちの実情を知る

• 今後より注力すべき活動を特定する
  ⇒ 現時点における自分たちの課題を知る

• チーム全体の成長を定量的に実感できるようにする
  ⇒ 前進できている自分たちを褒めたい！

実施方法

アンケートの収集方法は以下の通りです。

１．28個の各アクションに対して個人の実践状況を一人一人が回答する

２．実践状況は全アクション共通で以下の三段階で回答する

• 【Good】80%以上の開発案件で実践できている
• 【Fair】20%～80%の開発案件で実践できている
• 【Poor】20%未満の開発案件で実践できている

アンケート結果：前半（成長を実感）

以下にアンケート結果の一部をご紹介します。

前半は特に取り組み開始当初の2022年と比べて今年2023年のアンケート結果でより成長を実感できている部分です。

ステークホルダーから要望をヒアリングする場にQAエンジニアが直接参加する割合が増えているのが判ります。

同様にヒアリングした要望を元にどんな課題を解決したいのかの特定にもQAエンジニアの関与が増えています。

要件定義の後の仕様検討やROIの試算にも関わりが増え、並走するQA活動の実践が浸透しているのがアンケート結果から確認できました。

また、開発が完了した後の活動についてもふりかえり会の開催を主導する役割も担うことが多くなってきています。

併せてふりかえりで抽出した改善施策の推進役としての関わりも強化できていることが確認できました。

いずれもまだまだ伸びしろを多く含んではいますが、『並走するQA活動』の具体化によって浸透が進められていることが実感できています。

アンケート結果：後半（新たな課題）

一方で、以下はまだまだ課題が多く残っていると感じた比較結果です。

要望のヒアリングに参加し、課題の特定はできているものの、その過程である課題解決の実現方法を検討する場への参画はあまり増えていません。

要件に対する記録と整理の点でもトレーサビリティを確保する活動にまだまだQAが貢献できていないのが現状のようです。（それぞれ役割分担があるので、全てにおいてQAが関与するのが正解ではないということもありますが）

柔らかい仕様に対する指摘や固めに行く活動も80%以上の比率は多いもののまだまだ底上げする余地は残っていそうです。

開発終了後の活動にもまだまだ改善の余地はありそうで、QA活動結果の記録は実施していますが、結果を分析してフィードバックするところはまだまだ必要です。

ふりかえりも主導できるようになってきていますが、ふりかえり自体のふりかえりについてはもっともっとQAが主体的に改善活動を推進する役割を担えるはずです。定型の雛形をベースにふりかえりを続けていくとどうしてもマンネリになって本当に必要な改善が見逃される状況が生まれやすくなるため、ふりかえり活動そのものの改善も進めていけると良いと思っています。

まとめ

取り組みを通じて『プロセスｘステップ』という構造でこれまでの範囲外だったQA活動を定義することができるようになったのが大きな収穫でした。メンバー全員の認識を合わせやすくなり、浸透状況の計測も行えるようになりました。自分たちの成長を実感するとともに、今後の課題を具体的に特定して取り組みを改善していけるようになったのも、仕組みが上手くメンバーの活動を後押しできたからなのではないかと思っています。

また、アクションの定義自体もまだまだ改善の余地が残っていて、『プロセスｘステップ』の構造をベースにしながら新しいアクションを抽出して定義したり、不要になったアクションを統廃合したりと、具体的な活動と紐づけて改善が進めていければと考えています。例えば今後は、実装した機能が本当に使われているかを調査してフィードバックしたり、指標をもとに事業課題がどれだけ解決されているかを測定して次の課題の改善につなげたり、といったアクションを新たに定義して、より広範囲にQAエンジニアが活動していけるような仕組みにしていきたいですね。

引き続きより幅広い役割を担ってサービスや事業に直接貢献できるQA組織を目指して活動を進めていきたいと思います。皆さまの困難なソフトウェア開発の中にも、多くの協力者がどうか現れますように。

最後まで読んでいただきありがとうございました。

*1:QAエンジニア歴20年のベテランから、キャリアをスタートさせたばかりの新人さんまで、多様なメンバーが在籍しています

*2:テストなどの一般的なQAの活動は除いて

*3:要件が発生してから開発してリリースして効果を測定するまでを全体と定義しています。

*4:開発がQA担当者抜きで勝手に進んでいて、テストの段階になって初めて呼ばれる、といったことが以前はありました

*5:ちょっとこれだけ粒度が小さすぎないか？という懸念もありましたが、煩雑になりがちな情報をなるべく一元管理するプラクティスとして入れてあります

*6:最近は仕様書をQAが書くことも多い

*7:仕様書を開発者の聖域にはせず、積極的に加筆しにいく

*8:モブテストとブリッツテストを掛け合わせた取り組みで、私たちの中ではモブリッツテストと呼んでいます

ソフトスキルマップでソフトスキルの習得支援

こんにちは。@tak_koheiです。このエントリーは、エムスリーキャリア Advent Calendar 2023の11日目です。

私たちの組織において、QAエンジニアはソフトスキルの面で組織の活動を下支えする役割も担っています。例えば、ソフトウェアの欠陥や問題点を開発エンジニアと正しく認識し合ったり、プロジェクトのふりかえり会を主催して問題や課題を引き出しながら解決策の検討を推進したり、開発エンジニアとその他のステークホルダーの間に入ってコミュニケーションをより円滑にする動きをしたり、といった活動です。

そこで、そんなQAエンジニアが日々活用しているソフトスキルをもっと広くエンジニア組織全体で成長させていくための仕組みが作れないかと考え、『ソフトスキルマップ』と呼ぶソフトスキルの一覧とその定義のセットを作成して、ソフトスキルの習得を支援する活動に取り組んでみましたので公開します。

ソフトスキルとは

ソフトスキルとは、コミュニケーションやリーダーシップ、課題解決や時間管理など、仕事を進める上で基礎となるスキルのことです。一方で、ハードスキルとは、プログラミングやソフトウェアテスト技法など、専門分野のスキルを指します。仕事を正しく円滑に進めるためにはソフトスキルとハードスキルの両者が必要です。

ソフトスキルの効果的な習得プロセス

まず、ソフトスキルをどのように習得するのかについて考えます。より効率的にソフトスキルを習得するためには、以下の工程を繰り返す必要があります。

認知

認知とは、具体的にどのようなスキルが必要なのかを理解することです。この工程では、まず自分には何が必要なのか、何を学びたいのかを具体的に理解することが重要です。例えば、コミュニケーションスキルの中でも「口頭で説明するスキル」と「文章で説明するスキル」は異なります。ソフトスキルを理解するためには、書籍やオンライン教材を使った学習、専門家や経験者からのアドバイスを受けるなどが有効ですが、実践的な要素が強いスキルであるため実際に使える具体的なな知識を獲得しにくい領域でもあると思います。

実践

認知したスキルを実際に使って実践することで、そのスキルを習得します。実務の中でそのスキルを使ってみることが非常に重要で、学習や模擬演習がスキル習得に結びつくハードスキルとは大きく異なる点だと思います。この段階では、学んだことをどのように実際の状況に適用するかを考え、試行錯誤しながら最適な方法を見つけ出す必要があります。実践する際には失敗を恐れず、また他人のフィードバックを都度受け入れるなど内省に繋げることが重要です。

内省

内省とは、自分自身で実践した結果を振り返り、何がうまくいったのか、どんな改善が必要なのかを考えることです。自己反省を行うことで、自身の行動や結果について深く理解し、次の行動へ活かすことが可能になります。また、上司や同僚からのフィードバックも重要な情報源となります。ただし、この工程では自己批判に陥らないように注意が必要です。失敗から学び、改善につなげることが重要です。

認知の施策①：ソフトスキルマップ

上記の習得プロセスを踏まえて、まずは「認知」を進める方法を考えていきます。

ソフトスキル習得の難しさ

ソフトスキルを習得することを困難にしている要因の１つに「具体的なスキルを認識し難い」という問題があると思います。まずソフトスキルの全容がハードスキルほど明確ではありません。ひとまずソフトスキルを構成する大まかなスキルを洗い出す必要がありそうです。

また、洗い出したスキルも抽象度が高いと具体的なスキルとして認識がし難いです。例えば「コミュニケーションスキル」って具体的にどんなスキル？って説明するのは難しいですよね。相手の話を聴くスキル、相手の表情や仕草から気持ちを洞察するスキル、言いたいことを正しく伝えるスキル、会話を和やかにするスキル、相手に安心感を感じてもらうスキル、などなど分解していくといろいろありそうです。

つまり、ソフトスキルの認知を進める上では、まずは具体的なスキルに分解し説明するための定義作りが必要だと考えました。

ソフトスキルマップ作成

そこで『ソフトスキルマップ』という名称でソフトスキルの定義を組み立てていきました。まず、全体を「対人スキル」と「非対人スキル」の2つに分類しました。そこからそれぞれ大まかな構成要素をグループとして列挙していき、対人スキルには「コミュニケーション」と「リーダーシップ」、非対人スキルには「課題解決」「創造性」「時間管理」「自己研鑽」「感情知性(EQ)」を紐付けました。そこからそれぞれのグループを更に具体的なスキルへと分解しました。

以上により、「コミュニケーション」13つ、「リーダーシップ」8つ、「課題解決」9つ、「創造性」5つ、「時間管理」8つ、「自己研鑽」4つ、「感情知性」4つのスキルに分解できました。

各スキルの定義

次に、それぞれのスキルはどのようなことが出来るスキルなのか一つずつ説明を加えました。長いので折り畳み式になっています。クリックするとそれぞれのスキルについて説明が展開されます。

対人スキル

コミュニケーション（クリックで展開）

傾聴力

• 相手の話を注意深く聴き取ることができる
• 相手の言葉だけでなく、表情や身振りも注意深く観察できる
• 相手の立場や視点に共感し、尊重することができる

洞察力

• 相手の言葉の意味や本質を正確に理解できる
• 相手の感情や意図を読み取ることができる
• 相手の課題やニーズを汲み取ることができる

要約力

• 相手が伝えた主要なポイントを見逃さず正確に理解できる
• 伝えたい内容の重要なポイントを整理できる
• 相手にわかりやすく簡潔に伝えられる

論理的表現力

• 議論や問題の中心となる論点を見極め、整理することができる
• 自分の主張に対して適切な根拠や証拠を示し、説得力を持たせることができる
• 話の展開や説明が論理的であり、簡潔で理解しやすい構造に組み立てられる

柔軟性

• 相手の性格や感情に応じて、適切なコミュニケーション方法を選択できる
• 相手の理解度や疑問点に応じて、適切なコミュニケーション方法を選択できる
• 相手の役割や立場に応じて、適切なコミュニケーション方法を選択できる

協調性

• 他人の意見に耳を傾け、異なる視点やアイディアを尊重できる
• 相手のスキルや知識を理解し、役割分担や協力を促すことができる
• 対立が生じた際に双方の意見を尊重しながら解決策を見つけられる

共感力

• 表情や態度などから相手がどのよいうな感情を抱いているか理解できる
• 相手の状況や背景を理解し、相手の立場に立って物事を考えることができる
• 自身の感情を抑え相手の気持ちに寄り添うことができる

内省力

• 相手に与える影響を考慮してコミュニケーションをとることができる
• 人と接する際の思考や言動、態度を客観的にふりかえることができる
• コミュニケーションにおける自分自身の問題点に気付き改善できる

口頭表現力

• 口頭で、自分の意見や感情を明確に伝えられる
• 正確かつ適切な言葉選びで相手にわかりやすく伝えられる
• 相手の前提知識を踏まえて相手が理解できる言葉で伝えられる

文章表現力

• 文章で、自分の意見や感情を明確に伝えられる
• 正確かつ適切な言葉選びで相手にわかりやすく伝えられる
• 相手の前提知識を踏まえて相手が理解できる言葉で伝えられる

問題解決力

• 状況や相手に応じて適切なコミュニケーション方法を選択できる
• 問題の本質を見つけるために、適切な質問をすることができる
• 対立や意見の相違を円滑に解決することができる

関係構築力

• 自分で解決できない問題に直面した際、解決できそうな人を引っ張ってくることができる
• 上司・部下・同僚との間で、悩みやスキルアップの相互支援関係を築くことができる
• 他部門の異なる専門知識を有する関係者と連携し、課題の解決を推進することができる

勇気

• 新しいコミュニケーションの機会を得るための能動的な行動ができる
• 自分自身の意見を積極的に表現できる
• 難しい話題でも臆せず相手と対話できる

リーダーシップ（クリックで展開）

自己分析力

• 自分自身の感情や反応を認識し、適切にコントロールすることができる
• 自己の強みや弱みを理解し活かすことができる
• 自分自身の役割や責任を自覚した上で行動できる

他者認識力

• 相手の優れた点や良いところを認め、自尊心や行動意欲を高められる
• 相手の隠れた長所を発見することで、ポテンシャルを引き出すことができる
• 相手の欠点や短所を認識して、不足を補ったり支援したりできる

戦略的思考

• 中長期的な目標を設定し、それに向けた計画を立てることができる
• 組織全体の視点を持ち、ビジョンやミッションを明確にすることができる
• 組織内外の状況やトレンドを分析し、環境変化に柔軟に対応することができる

推進力

• 自分自身やチームメンバーのモチベーションを高めることができる
• チームの目的や目標を明確にし、効率的に作業が進められるようにできる
• チームメンバーの強みや特性を認識して活かすことができる

ファシリテーション

• チームメンバーから意見を引き出し議論を促進できる
• 議論を可視化し整理することで理解を深め、効率よく議論が進行できる
• 結論に対してチームメンバーのコンセンサスを形成することができる

責任感

• 自身の決めたスケジュールや他者との約束を遵守することができる
• 問題や課題に対して主導的な役割を果たし、解決に向けた行動ができる
• 失敗やミスに対して責任を負い、主体的に改善策を考えることができる

正義感

• 道徳的な価値観に基づき、公正かつ平等な行動をとることができる
• チームの決断について公正性を確保し、説明責任を果たすことができる
• 不正や不当な扱いを許さず、必要に応じて対策を講じることができる

育成力

• チームメンバーのレベルや意思に合わせて成長機会を提供できる
• チームメンバーの課題に合わせて目標設定や計画立てが支援できる
• 行動や思考に対して建設的なフィードバックを与え、成長に役立てられる

非対人スキル

問題解決（クリックで展開）

問題発見力

• ステークホルダーが示すサインやフィードバックを感じ取り問題を認識できる
• 外部環境の変化や兆候に敏感に反応して、問題の発生に気付ける

分析力

• 数値/文章/時間/空間等のデータを対象とした分析により、傾向予測や最適化案が導出できる
• 手順/構造/事例等を対象とした分析により、問題の特定や改善策の導出ができる

批判的思考

• 情報や意見を無批判に受け入れず、根拠や理論を検証し評価できる
• 個人の感情や先入観に左右されず、事実に基づいて判断できる

論理的思考

• 問題の原因や解決策に対して、根拠に基づいた検証可能な仮説が立てられる
• 事実やデータに基づく根拠が明確な推論の下、一貫性があり矛盾しない結論を導き出せる

適応力

• 状況の変化を認識して要因や影響を把握し、解決策の検討と実行および評価ができる
• 従来の方法が機能しない場合、新しいアプローチや方法を検討し試行できる

発想力

• ブレストやマインドマップ等を活用し、多様な視点でアイディアを発散できる
• 実現可能性や効果の高さを踏まえて優先順位を決定し、アイディアを収束できる

リスク管理

• 潜在的なリスクや障害を特定し、最小化または回避するための戦略や計画を立てられる
• リスクを継続的に監視し、必要に応じて対策を講じることができる

細部への注意力

• 問題の原因を特定するために、細かい事実やデータに注意を払うことができる
• 解決策を検討し実行する際に、細かい手順やタイムラインを考慮できる

根気強さ

• 目標の達成に時間がかかる場合でも、長期的な視点を持って取り組みを継続できる
• 困難や辛いことがあっても心揺らぐことなく諦めずにやり続けられる

創造性（クリックで展開）

観察力

• 多角的な視点で物事を細部まで捉えて、新しいアイディアに結びつけることができる

独創性

• 固定観念にとらわれず独自の視点やアプローチで考えることができる

想像力

• 現実に存在しない新しい概念やアイディアを思いつくことができる

革新性

• 産み出したアイディアを実用的な製品や解決策に紐付けることができる

イノベーション意欲

• アイディアの発案から具現化および継続的な改善を推進できる

時間管理（クリックで展開）

作業分解

• やりたいことに対してタスクを適切な粒度で洗い出せる

優先度設定

• タスクの優先順位を適切に付けられる

工数見積

• タスクの完了に必要な時間を正確に見積もることができる

計画策定

• タスクリストと見積を元に効率的な作業スケジュールを作成できる

進捗管理

• 作業を実施しながら計画に照らして進捗状況を把握できる

問題認識

• 作業進捗の妨げになる問題や課題を認識できる

問題解決

• 作業進捗の妨げになる問題の解決方法を検討して遂行できる

精勤性

• 業務に対して誠実に取り組める

自己研鑽（クリックで展開）

好奇心

• 学びたいことを発見して興味を持てる

学習力

• 自発的に学びの行動が起こせる

行動力

• 日々の活動から学びを得られる

習慣化

• 学びを習慣化できる

感情知性（EQ）（クリックで展開）

識別

• 自分や相手の感情を感じ取り察知できる

利用

• 問題や課題に対する自身の感情をコントロールし、必要な感情を生み出せる

理解

• 自身の感情の発生と移り変わりを理解し、感情と行動の関係を推察できる

調整

• 自身の感情を調整し、ふさわしい行動へとつなげることができる

ソフトスキルマップ完成！

以上でソフトスキルマップの完成です。これを使ってソフトスキルの習得プロセスを進めます。

• 認知：まずはソフトスキルの認知。どんなスキルがあるのかを知る。

また、認知以外にもソフトスキルマップの使い道はありそうだなと思っています。

• 自己評価：自身のスキルを自己分析。強味と弱点が何かを考えてみる。
• 目標設定：課題を特定して、改善のための目標を設定してみる。

補足

このソフトスキルマップはソフトスキルを習得するための補助となることを目的としています。「ソフトスキルとは何かを正しく定義する」という目的ではないので、完全性や網羅性が担保されていなくてもゴメンナサイ。あくまでも、ソフトスキルを認識したり課題を考えたりする際の気付きやきっかけにするためのツールとして使っていただければと思います。

• 構造的な完全性は無いと思います
• 要素の全網羅もたぶんできてません
• 定義の曖昧さも許容してください
• マップ自体を使いながら成長させていく前提です

認知の施策②：ワークショップ開催！

作成したソフトスキルマップを組織内で配布して「読んでくださいね」だけでは認知は進まないと思い、別途ソフトスキルマップを使ったワークショップを企画して開催してみました。

目的

ソフトスキルマップに掲載したスキル全てを対象にすると多過ぎて混乱するので、まずは「コミュニケーション」のスキルに絞って実施します。「コミュニケーション能力って具体的にどんな能力？」の認知を促進することを目的にしたディスカッション中心のグループワークです。

前提

ワークショップでは、アイディアを出したり、出した意見を分類したりするので、リアル開催であれば付箋とペン、オンライン開催であればオンラインホワイトボードがあると、ディスカッションが円滑に進められると思います。工夫次第でスプレッドシートなどでも簡易に議論を可視化することができます。

私たちの環境では日常的にオンラインホワイトボードを使っています。以降の説明はこのオンラインホワイトボードを使って進行している前提で読んでいただけると助かります。（オンラインホワイトボードの使用例は以下の別エントリーをご参照ください。）

tak-kohei.hatenablog.com

進め方

１．趣旨説明

前述のソフトスキルの重要性やソフトスキルマップの概略を説明したのち、本ワークショップの目的とアジェンダを説明しました。また、補足としてコミュニケーション能力の構造についてもソフトスキルマップとの関連も含めて解説しました。

コミュニケーションのスキルは大きく分けて「入力」「思考」「出力」に分類でき、それぞれスキルマップで定義したスキルが以下のように分けられます。この構造を補足として事前に説明しておくと、コミュニケーションのスキルを認知する上での手助けになります。

①入力：コミュニケーション相手から情報を獲得します
②思考：情報を元に自分の意見や対処方法を考えます
③出力：コミュニケーション相手に自分の意見や気持ちを伝えます

２．コミュニケーションの具体例

ここからワークショップのスタートです。まずはソフトスキルマップは使わずに、参加者が考えるコミュニケーション能力の「ある人」と「ない人」の具体例を挙げてもらいます。例えば「話を最後まで聞いてくれる」（良い例）とか、「様々な解釈ができてしまう言葉選びや文章構造、省略をしてしまう」（悪い例）とか。どんなものでも構わないので、参加者から良い例と悪い例をたくさん出してもらいます。

例）

３．具体例のソフトスキルマップへの割り付け

出してもらった具体例をソフトスキルマップの該当するスキルに分類していきます。例えば「聞いた人が嫌な気持ちになる表現を使わない」は「協調性」かな、とか。「ミスを人のせいにする」は「内省力」かな、とか。正しい分類でなくても構わないので、どれに当てはまるのかを考えて皆で議論することによって、普段のコミュニケーションがどんなスキルで成り立っているのか理解が深まっていきます。

例）

４．割り付けを見ながら他に追加で例が無いか考えてみる

具体例をソフトスキルマップに割り当てると、意外と具体例が出てないスキルがあったりします。そうしたら今度はソフトスキルマップ起点で具体例を考えます。良い例、悪い例、ともにアイディアを出していくと、気付きにくいソフトスキルにも焦点が当たって理解が深まります。

５．自分にとって重要だと感じたスキルをドット投票する

ここから先は認知から実践につなげるためのワークです。数も多いですし一度に全てをスキルアップするのは難しいので、特定のスキルに絞って実践方法や実践する上での課題を考えていきます。

参加者でドット投票を使ってどのスキルについて議論をするか絞り込みます。より多くの人が課題を感じているスキルに焦点を当てる方が参加者の満足度が高くなります。

６．最多得票スキルの実践方法を考える

対象スキルを絞り込んだら、そのスキルを実践する方法ついて考えていきます。扱っている対象がソフトスキルなだけに、実践方法もふんわりした心の在り方に関するものが多くなりがちです。実践方法はそれが具体的な行動かどうかを考えるようにすると良い気がします。例えば「傾聴力」の実践方法であれば、「先入観を持たないようにする」や「相手に興味を持つ」といった実践方法でも良いと思うのですが、行動に移せたかどうかや効果がどれくらいあったかなどのふりかえりがし難いです。もっと具体的に「相槌を打つ」「話を遮らないようにする」「相手自身を否定しない（思っても口にしない）」「相手の話に対して感想や意見などのフィードバックをする」といった、すぐに行動に移せるような対策案もあるとスッキリします。また、実践時に障害になる要素についても意見を出して、どうやったら解消できるか議論するのも良いかもしれません。

特に5以降は認知したスキルを実践に繋げるためのディスカッションです。まず認知には1～4が重要だと思うので、5以降はオプション的な扱いで時間があれば実施するでも良いと思います。

成果

いろいろな具体例が出てきます。私たちがワークショップを実施した際には、総勢45名（5グループに分割）で具体例が合計376個も出てきました。特にコミュニケーションは普段の業務で密接に関係しているスキルなので会話も盛り上がります。

また、自分以外の考えにも触れることで、よりコミュニケーション能力への理解が深まりましたし、ワークショップでのディスカッションを通じてお互いの考えをより深く知ることもできました。

• ソフトスキルにおける自身の課題を、より具体的に認識することができる
• スキル習得に向けて具体的な実践方法をイメージすることができる
• 実践する上でのハードルも認識することで効果的にスキルアップが図れる

今後の課題

実践と内省のループ

ここまででようやく「認知」の仕組みと取り組みができました。残りの「実践」と「内省」は今後の課題です。個人の活動だけでなく、組織としてメンバーのソフトスキルを向上させる仕組みを構築していけるよう取り組みを継続中です。

引き続きソフトスキルの重要性と認知度UP

また、コミュニケーションについてのワークショップは開催しましたが、それ以外のソフトスキルについてはまだソフトスキルマップを公開しただけなので、認知のための活動を更に進めていく必要があります。特に非対人スキルは自分自身もあまり得意分野ではないので*1、自身の課題とも照らし合わせて活用していけたらと思っています。

更にソフトスキルの認知度を上げていくために、以下の草の根活動をSlackの専用チャンネルで実施したりしています。

• 「ソフトスキル」の専用Slackチャンネルを開設
• 同チャンネルにて、定期的にソフトスキルマップを解説するコラムを投稿
• 同チャンネルにて、適宜お悩み相談を受け付けて皆で解決策を考えたりアドバイスをもらったりするなど

組織内でソフトスキルの重要性について認知を広げながら、現場の困りごとを解決する手助けなど進めていくことで、実態を伴うスキルとして定着していくのではないかと考えています。ソフトスキルマップを配ってワークショップを実施して終わり、ではなく、スキル習得の支援が継続する状態を維持していきたいです。

参考情報

最後に参考情報です。ソフトスキルマップ検討を始める際に、利用できそうなソフトスキルの定義や研究成果等が無いか探してみたのですが見つけられず、「それじゃあ自分たちで作るしかないか」と今回は自主製作に至りました。上手く探せてないだけかもしれないので、もし何かご存じの方がいらっしゃいましたら教えていただけると嬉しいです。

また、後になって知ったのですが、海外でソフトスキルについて研究や教育活動を実施して情報を公開されているULISSE Projectという団体がありました。（検討を始める前の調査は日本語だけじゃなくて英語でも検索してみるべきでした。）

ulisseproject.eu

こちらの団体では、ソフトスキルの定義を策定したり、学生の教育に活用したりといった取り組みをされているそうです。定義だけでなくワークショップの資料も公開されていて、素晴らしい活動だなと思います。

公開されているソフトスキルの定義については私たちのソフトスキルマップと似通っている部分もありますが、ソフトスキルマップには無い要素もあるようです。今後、参考にさせてもらって引き続きスキルマップをブラッシュアップしていきたいです。

これからも開発組織全体の組織品質にも貢献できるQA組織として活動を続けていきます。アップデートがあればまたこちらでご紹介していきます。

最後までお読みいただきありがとうございました。

*1:定義は作ってみたものの、特に「問題解決」や「創造性」などは苦手分野です

開発とQAが共働を始めるための仕組み

こんにちは。QAエンジニアの@tak_koheiです。このエントリーは、エムスリーキャリア Advent Calendar 2023の4日目です。

私たちは開発エンジニアとQAエンジニアがより近い距離で共働するエンジニア組織で活動しています。その中でも、実装完了直後（テスト実行開始直前）のタイミングで、開発エンジニアとQAエンジニアが設計/実装/テストについて雑談する場を作って『QAセッション』という名称で運用したときの事例をご紹介します。

活動を進める上で大切にしたポイントや実践してみて感じたメリットなどについて言語化してみました。特に「開発エンジニアとQAエンジニアで協力して開発を進めたい（けど具体的に何をしたら良いかわからない）」といった要望をお持ちの方の参考になれば幸いです。

きっかけ

始まりは開発エンジニア1名とQAエンジニア1名（私）の2人で構成される小さな開発チームが結成されて間もない頃でした。QAエンジニアとして自分自身の関与する領域をより上流工程へとジワジワ広げつつあった時期に、開発エンジニアから何気ない相談をいただくところから始まりました。

この手の場作りは、これまでどちらかというとQAエンジニアである私から開催をお願いすることが多かったのですが、この時は開発エンジニア起点で提案をしてもらえたのが非常に嬉しかったのを今でも覚えています。

相談を重ねながら開発プロセスの中に開発やテストの内容について雑談する仕組みを組み込んで、それを「QAセッション」と命名して運用を始めました。

QAセッションとは

実施方法

システム開発の案件ごとに、設計/実装/テスト観点/懸念事項などについて開発エンジニアとQAエンジニアが直接会話して意見交換します。対象案件の規模は数週間程度のものが多く*1、案件の規模に関わらず１回の所用時間は30～60分くらいです。

開催タイミング

QAセッションを開催するタイミングは、開発エンジニアが実装を完了した時点で、第三者の開発エンジニアがコードレビューを実施している間です。また、QAエンジニアはテスト設計を完了させ、テスト実行が開始できる状態になっている前提です。

ごく短い期間ではありますが、QAエンジニアにとってはコードレビューで改修が入る可能性があるのでテスト実行は開始できず、開発エンジニアにとっては実装が完了している、というスキマ時間を利用して開催していました。

会話の内容

最初はユニットテストの実施内容を説明してもらって雑談するだけの内容から始まったのですが、回数を重ねるたびに話題はお互いが興味のある内容にどんどん広がっていきました。そして、開発視点とQA視点それぞれが話題を提供するような形になり、最終的には以下のような話をするようになりました。

設計実装について（主に開発視点の話題）

• 最終的に仕様はどう確定したか（改めて最終確認）
• データや処理の流れ、通信のタイミング、がどうなっているか
• 処理が共通化されている箇所があるか（それはどこか）
• 複雑な処理になっている箇所があるか（それはどこか）
• ユニットテストのテストパターン（深さ、広さ、網羅性）

テスト観点について（主にQA視点の話題）

• 全体の機能的な確認視点（テストパターンや期待結果の確認方法など）
• 条件やパラメータの組み合わせがある場合、どこまでテストする必要があるか
• 省略可能なテストはあるか（そのまま鵜呑みにはしないけど）
• テストの手間が大きい時に楽にテストする方法が他に無いか

懸念事項について（開発/QA両者視点からの話題）

• 変更されていないように見えて実は手が入っている箇所が無いか
• 仕様の考慮漏れがあるとしたらどの辺りにありそうか
• もし万が一発生したらダメージの大きい障害はどんなものか
• リリースや運用に対する懸念（DBマイグレーションの影響についての懸念、バッチ処理とリリースのタイミングで起きそうなトラブル、など）

メリット

QAセッションを開催することによるメリットをまとめてみました。開発エンジニア視点のメリットについては、一緒にQAセッションの取り組みを進めてくれた開発エンジニアのかたに感想をいただきました。感謝。

開発エンジニア視点

テスト中に欠陥が検出された場合の対処がスムーズになる

• 事前に仕様や懸念点を共有することで準備ができる
• 特殊な仕様やその背景などロジックレベルでしかわからない点を伝えられる

全体の品質が高められる*2

• QAセッションで伝えるべきことを事前にまとめることで気付きにつながる
• ユニットテストの不足を解消したり、動作確認でバグを潰せたり、コンフルを充実させたりできる

心理的に安心できる*3

• 不安に感じている部分を共有することで丸投げ感が減る*4
• 開発プロセス全体の一体感が増す

QAエンジニア視点

テスト観点を精錬できる

• ロジックの変更箇所を理解してテストを考えられえる
• テスト条件やテストデータを具体化できる
• 気付いていないテスト観点を補完できる

テストの重み付けを工夫できる

• 複雑な仕様や実装箇所を優先的にテストできる
• 起きそうな不具合を想定したテストが早めに実施できる
• ユニットテストの担保範囲をふまえてテストの濃淡が調整できる

多様な視点で懸念事項を洗い出せる*5

• 機能改修が及ぼす影響を認識できる
• リリースの際の注意事項を意識できる
• 前後にリリースされる他の改修の影響も考慮できる

大切にした３つのこと

QAセッションを実践するにあたってのポイントや気を付けていたことは以下の通りです。

その１：QAセッションの目的や方法の認識を合わせる

まず１つ目は、QAセッションの運用を始める前に、その目的や実施方法について開発エンジニアとQAエンジニアでお互いの認識を合わせたことです。

目的

• QAセッションを通じて何を得たいか
• どんなことができたら嬉しいか
• 敢えて目的に含めないようにすることはあるか

方法

• いつやるか
• 何を準備するか
• どんなことを話すか
• どんなことは話さないか

QAセッションを実施することで何を得たいのかを明確にしたり、そのために「やること」と「やらないこと」を事前に認識合わせするところが重要だったかなと思います。

その２：活動を定期的にふりかえって改善する

2つ目は、定期的にふりかえりをして、QAセッションで行っている会話の内容について精査をし続けたことです。開発案件ごとにリリースし終えたタイミングでふりかえり会を開催していたので、その中でQAセッションがどうだったかについても話題に挙げて改善をしていました。

QAセッションのふりかえりポイント例は以下の通りです。（書き出してみたらなんとなく緩いKPTAになってたのかなと後から感じました）

KEEP：どんな内容の会話が有効だったか

• 会話して良かった/助かったのはどんな内容だったか
• 会話の内容がQAセッションの目的に合致していたか

PROBLEM：逆に、今後はしなくてもよい内容の会話はあったか

• やってみて実りが少ないと感じた会話は無かったか（どんな会話だったか）
• QAセッションの開催目的自体を見直す必要は無いか

TRY：次回のQAセッションではどんな話をすると良いか

• 抜け漏れを検出したり新しい気付きを得られるのはどんな切り口か
• お互いのヒントになりそうなのはどんな話題か

ACTION：次回のためにお互いどんな準備が必要か

• 次回のQAセッション開催までに集めておく必要がある情報があるか

開発とQAの二人がお互い気にしていたのは「限られた時間の中で本当に価値のある会話ができていたか」という点です。QAセッション自体はやる前から「コレきっと楽しいよねー」がお互いの共通認識としてあったものの、「楽しいだけで実が無い時間の浪費はしたくない」というのもお互いの共通認識でしたので、少し厳しめにふりかえりをしていた気がします。

その３：QAセッションだけに依存しないよう注意する

3つ目は、全てのコミュニケーションをQAセッションに集中させないように、常に何かあればお互いやりとりを絶やさないようにしていたことです。

コミュニケーション方法は主にSlackでの「つぶやき」です。対面での相談も適宜行っていましたが、思いついた時点でSlack上で雑にでもつぶやいておいて、つぶやいた方が後から補足を入れたり、つぶやかれた方がフォローしてコメントを返したり、というやりとりで可能な限り溜めこまないようにしていました。

以前、別のエントリーでも書いた「違和感に気付いたらすぐに共有」の実践です。

tak-kohei.hatenablog.com

その後

2人で始めたQAセッションですが、現在はこの取り組みの事例を組織全体に展開して実践しています。ただ「QAセッション」って用語自体は殆ど使われなくなりました。特に意識せず開発エンジニアとQAエンジニアが常にインタラクションするのが当たり前になったから、でしょうか。共有の実施タイミングも特に実装完了直後に限定することなく臨機応変に行われているようです。特別な取り組みとしてではなく組織の文化として根付くことが一旦のゴールなのかなと思ってます。

当時QAセッションの開催を提案してくれて、一緒に改善を進めてくれている開発エンジニアK氏に、この場を借りて深く感謝します。

以前、本で読んだ憧れの世界に少しでも近付けるように、これからも活動していきたいです。

www.oreilly.co.jp ja.wikisource.org

皆さまの困難なソフトウェア開発の中にも、小さな幸せがどうか訪れますように。

最後まで読んでいただきありがとうございました。

*1:数時間程度で終わる小規模案件はわざわざQAセッションの時間を取る必要が無かった

*2:QAセッションを開催する前提で開発を進めることで、開発する行為自体の品質アップ効果もあるようです。

*3:開発エンジニアのかたって想像以上に孤独なんだなって思いました。少しでも支えになって安心しながら開発してもらえるようにしたいです。

*4:「丸投げするの嫌だな」って開発者自身が思ってくれるのは、QAエンジニアとしては凄い嬉しかったりしますね。過去に丸投げ生活が長かったので。

*5:お互いの視点の相乗効果で１＋１以上の深掘りができるようになった気がします。

メトリクスをQA活動に活用している話

こんにちは。エムスリーキャリアでQAを担当している@tak_koheiです。 このエントリーは、エムスリーキャリア Advent Calendar 2022の23日目です。

QA活動で収集しているメトリクスを組み合わせて新たなメトリクスを作り、品質状況の把握や改善に活用した話をご紹介します。

背景

前提

現在、私たちの組織では大小合わせて20以上のサービスにQAエンジニアが関与しています。そして、各サービスでは数時間で終わるものから完了までに数か月を要するものまで大小様々な開発案件を取り扱っています。

メトリクスの収集

そんなQAの活動状況を定量的に計測することを目的として、QA活動の状況を可視化するためのメトリクス収集を2019年から行っています。

QA活動のメトリクス収集

QAが関わったほぼ全ての案件に対して、「QAエンジニアが活動に要した工数（単位：時間）」と「開発終了までに検出した欠陥数（単位：件数）」を開発終了後に収集しています。*1また、工数はテストに関するタスクだけでなく、要件確認や仕様検討の打ち合わせ、テスト分析テスト設計、レビュー、など、テスト以外の時間も全て合わせた工数の予実を収集しています。

メトリクスの活用と課題

メトリクスの収集を始めた当初は、比較的大雑把な切り分けで改善するポイントを絞り込んだり問題の原因調査の足掛かりにしていました。例えば、検出した欠陥数の多かった案件を中心にふりかえりや改善施策を実施したり、QA活動時間の予実を比較して乖離の改善に利用したり、といった感じです。

その後しばらくして改善が進んだこともあり、更にもっと詳しく自分たちの活動成果を分析したくなってきました。

また、単純なメトリクスだけでは状況の把握が難しくなっていました。案件規模の差が大きいため、単純に工数の予実や検出した欠陥の数だけでは品質の状態は推察しにくかったのです。例えば、検出した欠陥数が5件でも、全体のQA工数が100時間の大規模開発案件なのか1時間の小粒タスクなのかによって影響の大きさが異なりました。

何をしたか

既存メトリクスの組み合わせ

そこで新たな指標として活用すべく、既存の収集している数値を組み合わせたメトリクスを導入しました。

QA工数1時間あたりの欠陥検出数

テスト実行で検出した欠陥の件数をQA活動全体に要した工数で割ることで、QA工数1時間あたりの欠陥検出数を算出しました。例えば、10時間の活動で2件の欠陥を検出した場合 計算：2÷10=0.2 で０．２が結果です。これにより案件の大小に関わらずQA活動の結果が定量的に計測できるようになるのではないか、と考えました。

また、要件定義への参加やテスト分析設計に要した工数と、テスト実行に要した工数を分ける案もありましたが、敢えてやらずに合計をそのまま使用することにしました。私たちの方針は、上流工程からシームレスにQA活動を展開して、開発プロセス全体で品質を向上維持することを考えているため、工程ごとに工数を分割するのが今後どんどん難しくなっていくでしょうし、手間もかかるだろうと考えたからでした。

メトリクスの命名

当初は「QA実績工数1時間あたりの欠陥検出数」という長ったらしい名前を使っていたのですが、普及させるためには呼びやすい名称を付けるのが良いだろうということで、この新しいメトリクスに勝手に名前を付けることにしました。*2

以前、欠陥のことをハッピーと呼んでいる事例が紹介されていたことを思い出し、単位時間あたりの欠陥、つまりアワー単位のハッピーで、ハッピーアワーという名前にすることにしました。*3

メトリクスの命名

何がわかったか

品質状況の可視化

ハッピーアワーを導入したことによって各サービスの品質状況が可視化できました。サービスごとに各月のハッピーアワー平均値の推移を出すことによって、QA活動による品質状況の推移を推測できるようにしています。

これまでの傾向から、どうやら私たちの組織内ではハッピーアワーが0.2を超える状況が継続している場合、検出する欠陥が多過ぎて手戻りが増大し、開発活動になんらかの影響が出ていることが多いようです。 以下にいくつか事例をご紹介します。

ハッピーアワーの推移の例1

考察１

年度の序盤では0.2を超えるハッピーアワーが続いていたものの、年度の後半になるにつれて数値が減少している。実態としても序盤はテスト実行で多くの欠陥を検出していたが、定期的なふりかえり活動による改善や上流工程でのテスト観点フィードバックなどを進めることで、テスト実行時に検出される欠陥数が減少。手戻りが少なくなりプロジェクト進行が円滑になった。

ハッピーアワーの推移の例２

考察２

全体を通してハッピーアワーは低い状態で、実態としてもテスト実行で検出される欠陥が少ない。事前に要件や設計についてしっかりとした詰めが行われている影響ではないかと推察している。

11月の数値が高くなっているのは、小さな案件で軽微な欠陥の検出が続いたためで、大きな問題は無い。（小規模案件では数値が高くなり易い）

ハッピーアワーの推移の例3

考察３

全体を通してハッピーアワーは高い状態で、実態としてもテスト実行で検出される欠陥が多く、欠陥の取りこぼしによる市場障害の発生も続いている。例1同様に地道な改善活動を進めることで、年度の終盤でようやく改善の兆しが見え始めた。

ハッピーアワーは2つ目の事例にあるように、規模の小さい案件で数値が高くなりやすい傾向があり、本当に対処すべき問題の兆候が埋もれてしまう可能性があります。そこで、一定規模以上の開発案件に絞ったハッピーアワーの推移に着目するなど、数値を見る際の切り口についても改善を進めています。*4

また、余談ですが、このように集計したハッピーアワーの推移を元に各サービスの担当QAエンジニアが品質状況についてコメントした月刊誌を、QAから開発部門全体に配信する活動などもやったりしています。

気を付けていること

それから、ハッピーアワーを日常的に使うにあたって気を付けていることがありますので、そちらもご紹介します。

ハッピーアワーを読む方法

まず、ハッピーアワーは数値の大きい小さいで良し悪しが決まるものではない、ということを十分注意するようにしています。

ハッピーアワーの表す意味

欠陥検出数が多いか少ないかは「プロダクトの実装完了直後の品質」と「担当QAエンジニアの技量」に大きく関わります。QA工数もまた同様です。極力、数値から状況を判断するのではなく、自分たちの活動内容や結果、そこから得られている手応え、が感覚として正しいかを補完するために数値を使うようにしています。

また、サービス間の比較はなるべく行わないようにしています。数値が出るとどうしても比較したくなりますが、私たちの組織では、担当者が違う。サービス自体の規模が違う。取り扱う課題の複雑度も違う。開発プロセスが違う。などなど、比較するための前提がそもそも合っていないことが多いので、それらを比較することは無意味だと思っています。

ハッピーアワーを使う際の注意点

ハッピーアワーを導入する際、以下のことについて全員に注意喚起を行いました。*5

【数値を目標や評価に使用しない】

• チームや個人の評価に使おうとした時点で数値の公正性が失われる
• 本来の重要な活動目的を見失い易い

【数値を使って特定の個人を責めない】

• どうやって改善していけば良いかを考えるために数値を使おう
• みんなで助け合うのが私たちの基本精神

メトリクスは定量的な数字が出せる分、いろいろな目的に使われて独り歩きする危険性を持っていると感じます。罠にハマらないようこれからも十分注意していきたいと思っています。

まとめ

ハッピーアワーの計算方法

• ハッピーをアワーで割る

ハッピーアワーの特徴

• 開発案件の規模に依存せず定量的な指標が計測できる
• ただし小規模な案件では数値が高くなりやすい

ハッピーアワーの利用方法と注意点

• 数値が低ければ良いというわけではない
• 異なるサービスを数値で比較しない
• 数値を評価や目標に使わない
• 数値を使って個人を責めない

もし似たようなメトリクスを既に収集されていたら、是非ハッピーアワーお試しください。 最後まで読んでいただきありがとうございました。

*1:他にも収集している項目はありますが、今回の内容には無関係なので割愛します

*2:自分たちで作ったと思っているだけで、既に存在する手法だったりしたらごめんなさい。→一般的には「バグ密度」という呼び方をするそうです。教えてくださったかた、ありがとうございます！

*3:QAで呼びやすいだけでなく、一部の酒好きエンジニアにも大好評だったとか

*4:それから本編では解説しませんでしたが、現状のハッピーアワーの仕組みはテスト実行の結果でした定量化できないという課題があります。より上流工程で防いだ欠陥混入のハッピーアワーについても定量化できないか、という取り組みを進めています。

*5:「メトリクス全般を使う際の注意点」と読み替えても良いかもしれません。