グルーワークとQAエンジニア

1. はじめに

スタッフエンジニアの道 ―優れた技術専門職になるためのガイド（Tanya Reilly 著、島田浩二 訳）を読んでいてQAとも関係が深い「グルーワークを引き受ける（p.264）」が目に留まりました。

本書によればグルーワークは「この種の仕事なしにプロジェクトがうまくいくことはない」もので次のような業務が挙げられています。

キャリアラダーのどこにもないけれどチームを成功させるために必要なリーダーシップや管理のタスク（略）ブロッカーの除去、オンボーディング、リマインダー、メンタリング、スケジューリングなどです。

また、次のような注意もあります。

問題なのは、若手が事務的な仕事やリーダー的な仕事をしすぎて、技術的な仕事をあまりしないと、技術的なスキルを学ぶための最良の技術習得期間を、技術的なスキルを学ぶことのない方法で過ごしてしまうことにあります。それは長期的にはキャリアを阻害することになります。

Tanya Reilly氏のBeing Glueも併せて読むと理解が深まると思います。

2. グルーワークを引き受ける

開発者のグルーワークとQAの管理技術¹はものづくりやマネジメントをうまくやるための取り組みという共通点があり、開発者のグルーワークのなかにはQAエンジニアやQA部門で引き受けるのが好適なものもあります。

• 開発経験者が引き受けることで現役開発者の支援になるもの
• QAが巻き取って手順などを確立し、その後開発者へ戻すことで組織能力向上となるもの
• 技術ロジスティクス構築のもととなるもの

2.1 例（1）法令対応

「社会的価値への関わり方に現れるインプロセスQAとスプリットQAの違い」で法令対応を開発者からインプロセスQAが巻き取る話を書きましたが、法務の専門家ではない開発者にとって法令対応をそつなくこなすこと（開発部門と法令対応部門の間に入って首尾よく法令対応をまとめること）はグルーワークといえます²。

2.2 例（2）デバッグの効率改善

「＜図解＞基本からよくわかる品質管理と品質改善のしくみ（西村仁 著）」p.210に治具化・自動化と品質改善と題して「人手作業」「治具化」「半自動化」「全自動化」が登場し自動化の効果として「工法条件の安定性」「不良の自動検出」が述べられています。

この考え方はソフトウェア開発にも応用でき、例えば組込みシステムの実機操作がともなう長時間動作テストは全自動化でなくても操作をツールで半自動化するだけでも効果があります。ただ、情報量でいえばたった1bitの0/1に過ぎない「押しボタンスイッチのオンオフ」というごく簡単な操作でも自動化しようとすると次のようなメカ、エレキ、ソフトウェアの合わせ技になります。

1. 試作品の回路図を探す
2. 試作品のふたを開けて基板へアクセスできるようにする
3. 回路図と基板を見比べながら線材を引き出す場所や引き回し方法を検討する
4. ワイヤーストリッパーで線材を皮むきする
5. 鉛フリーはんだで基板に線材をはんだ付けする
6. マイコン制御の自動化ツールを用意する
7. 線材を自動化ツールに配線する
8. 自動化ツールの自動テストスクリプトを作成する

組込みシステムの実機操作がともなう低頻度バグのデバッグを手動で行うのが大変といった問題に対して、長時間動作テストのツールをさまざまな機種のデバッグに横展開できるようにアレンジして技術ロジスティクスを構築し、開発者へ提供してデバッグを効率化するのはQAエンジニアならではのグルーワークの巻き取りです。

マイコン制御の自動化ツールは「リモートワークでテストを行うためのヒント」をご覧ください。SwitchBotボットのようなサーボでスイッチを押すと線出しが不要になりますがサーボのレイアウトや誤操作対策といったメカ的な検討要素が増えます。JaSST'24 Tokyo 「「組込み開発用テスト自動化環境」作製のウラ話～はじめやすくて、つづけやすくて、ひろげやすい自動テストってなんだろう？～」の資料は雰囲気をつかむのに役立つと思います。

3. グルーワークの注意点

スタッフエンジニアのグルーワークの注意点はQAエンジニアにも当てはまります。

3.1 QAエンジニア個人

開発者からQAエンジニアにスイッチすると評価されるポイントが変わります。開発者がプロダクトのコードを書くとそれは商品になり評価されますがQAエンジニアがツールのコードを書いても開発者のようには評価されません。管理技術としてはツールで成果を得ることが大事で、デバッグツールでいえばデバッグがはかどってバグが摘出されることが大事です。

筆者はふだんはスプリットQAですが開発者から相談が来たときは一時的にスプリットPE³も兼ねて、デバッグや再テストが進まない期間を最小化するため優先度を上げてツールを作っていち早く使ってもらうようにしています。ツールの投入が1日早まればそのぶん早くデバッグが進みそれだけ納期の余裕が生まれます。JSTQB FLのシラバスでエラーが発生する要因の一つに納期のプレッシャー⁴や時間的なプレッシャー⁵が挙げられていますが納期の余裕の確保は品質向上に役立ちます。

開発者はよく使うコードを自分用にまとめたりデバッグツールを作ったりすると思いますがスプリットPEの土台はそういった開発者としてのスキルや経験です。QAエンジニアにスイッチするとツール実装のスキルはそう頻繫には出番がなく評価もされづらいうえにいざ実装するとなると最短最速が求められるため開発者のうちになるべく身に着けておくのがおススメです。

3.2 QA部門

開発者のグルーワークをQAエンジニアやQA部門が引き受けるか組織能力を高めて開発者自身ができるようにするかはケースバイケースですが、少なくともQAファンネルで「QAプロモーターがきちんと組織的な戦略を立てて、QAファンネル（QA内のロール）のバランスを取る⁶」とあるように組織的な戦略を立ててそれにのっとっていることが望ましいです。

組込みシステムはメカ、エレキ、ソフトのフルスタックということもあってQA部門はソフトウェア開発だけでなくさまざまなスキルや経験の組み合わせが活かせます。一方でQAエンジニアのスキル獲得は開発部門とQA部門にまたがるため「組織的な戦略」は採用や異動、人材育成の面ではQA内にとどまらず開発部門も含むことになります。例えばシニアレベルのQAエンジニアのツール実装スキルをPEコーチやPEコンサルタント／サービスでミドルレベルの開発者に移転するには開発部門に人材がいないと成立しません。

さまざまな業務にAIが進出している昨今、回路図やCADのデータをAIに渡すとAIがいい感じに試作品のふたを開けて基板に線材をはんだ付けしてついでに治具に配線までしてくれるととってもありがたいのですがフィジカルがからむものはなかなかAIが仕事を奪ってくれないようです。部品の小型化、基板実装の高密度化や、年齢とともに部品の印字や基板のシルクを読んだり細かい箇所へはんだ付けしたりがだんだん難しくなるというのもあり、若手エンジニアへ計画的にスキトラ・ナレトラを行ってチームを育てる⁷のも大事です。

4. おわりに

開発者のグルーワークとQAの管理技術はものづくりやマネジメントをうまくやるための取り組みという共通点があり、開発者のグルーワークを引き受けて開発プロセス（≒品質マネジメントシステム、QMS）がよりよく回るようにするのはQAの役割の一つです。また、開発者のキャリアにスタッフエンジニアに加えてQAエンジニアもあるのを知っていると選択肢が広がるでしょう。

1. 管理技術の重要性は「基礎から学ぶQMSの本質　第8回　技術と管理のどちらが重要か(2016-3-14)」が参考になります。 ↩

2. QAエンジニアとしては社会的価値の実現をグルーワークと呼ぶのは気が引けるものの、開発者の主たる役割は顧客価値の実現のためあえてグルーワークとしています。 ↩

3. QMファンネルで「開発とは別組織で自動化・デジタル化してスピーディで効率的な業務を行う」メンバーです。詳しくは「品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話（3D版）」や「QAファンネル・QMファンネルを読み解く」をご参照ください。 ↩

4. 出典：JSTQB FLシラバス Version 2018V3.1.J03 p.17 ↩

5. 出典：JSTQB FLシラバス Version 2023V4.0.J02 p.18 ↩

6. 出典：JaSST東海2020基調講演・Re-collection of embedded software qa in the last decade p.40 ↩

7. スタッフエンジニアの道 「7.5.4 未来のリーダーを育てる」に通じる話でもあります。 ↩