第一世代のQAエンジニア(4)「ミツバチ」としてのQAエンジニア

1. はじめに

ソフトウェアのQAの役割の一つに「ミツバチ」が挙げられることがあります¹²³。

SQA担当の役割は，各プロジェクトに対してプロジェクト進捗がスムーズに行くようにさまざまな支援を行うことである（表6.4）．

役割名	役割内容
ミツバチ	各プロジェクトで経験したことを全社的に水平展開する．
アラーム	過去の実績データを参照し問題が大きくなる前に警告する．
ペースメーカー	プロジェクト計画通り進捗しているか検査し遵守させる．
ブレーキ	「開発手順・品質管理」標準から外れた活動に忠告する．
コンサルタント	プロジェクトのさまざまな問題に対して相談や指導を行う．

（出典：中国オフショア開発－ソフトウェア品質保証と事業OEM（河合清博, 2014）, p.92）

「ミツバチ」はQAの水平展開の役割をミツバチと顕花植物の相互作用に例えたものですが花粉や花蜜を集めるのは稼働中の採餌蜂です。未稼働の採餌蜂に注目するともう一つのQAの大事な役割が見えてきます。

2. 開拓者としてのミツバチ

ミツバチといえば「8の字ダンス」が知られていますがQAの役割の一つにミツバチが挙げられているのを見て筆者が思い出したのは電気学会誌の巻頭言のこちらの一節です。

ところが，すべての外勤可能な個体がこのダンスを正しく学習理解するとは限らない。統計的にみても 10％以下の個体はこのダンスの内容を正しく理解できず，指示されている蜜源には到達できない。しかし，彼女達はその強力な飛翔力によって自由奔放に飛び交う内に，指定外の新たな蜜源を発見し，そこから花蜜を持ち帰る。不思議なことに，彼女達は学習理解能力においては無能に近いが，ダンスによる教授伝達能力には遜色は無く，彼女達が発見した新しい蜜源を仲間に正しく伝達することができる。だから，彼女達が新しい蜜源の開拓者になるのである。
（出典：山下興亜, "ミツバチに学ぶ集団知の魅力", 電気学会誌, 2009 年 129 巻 12 号 p. 785 ）

「学習理解能力においては無能に近い」とはひどい言われようですが改めてミツバチについて「ミツバチの知恵（トーマス・D・シーリー 著、長野敬、松香光夫 訳、1998年）」を読んだところ次のようです。

1. 採餌蜂は「稼働中の採餌蜂」と「未稼働の採餌蜂」に分かれる
2. 稼働中の採餌蜂は餌場の状況が悪化して放棄するまで仲間のダンスを無視する
3. 未稼働の採餌蜂は「初めて採餌活動に従事する新参蜂」および「採餌経験はあるが餌場を放棄して新しい採餌場所を見つける必要に迫られた蜂」
4. 未稼働の採餌蜂は大半が仲間のダンスに追従し、一部が自力で新地開拓する探索蜂になる
5. Lindauer氏の1952年の報告によると新参蜂のうちまったくダンス情報に頼らなかったのは6%
6. Seeley氏の1983年の報告およびSeeley氏とVisscher氏の1988年の報告によると採餌経験のある未稼働の採餌蜂のうち探索蜂になるのは資源状況にもよるが平均10%前後（資源状況が良い時で5%、悪い時で24%～36%）
7. 個々の追従蜂は基本的に無作為に選ばれたただ一つのダンスに追従し、ミツバチコロニー全体で見るとある程度収益性のある餌場のすべてに採餌蜂が分布する（特定の餌場に集中しない）

3. 開拓者としてのQAエンジニア

資源状況が良い時でも未稼働の採餌蜂のうち数%は探索蜂として働いています。エンジニアの資源はヒト、モノ、カネ、知識、スキルなどが挙げられ、週の稼働時間を40時間とすると5%は2時間に相当します。

3.1 知識の開拓

知識の開拓でいえば会社で定期購読している雑誌や専門誌に目を通したりカンファレンスの資料やQiitaなどのテックブログの新着記事で気になったものを読んだりするのは始めやすいと思います。業務や事業に関係しそうなトピックスを見つけたら先行して調査し必要に応じて関係者へフラグをあげます。

かつて設計部門でインプロセスQAをしていたとき隣接分野の開発者向けカンファレンスを見つけて受講したのですが今も古巣の開発者が予算を付けてそのカンファレンスに毎年参加しているのは嬉しいところです。

3.2 スキルの開拓

JSTQB Foundation Levelシラバス(2018V3.1.J03)によるとツールはすでに誰かが作っている（世の中にある）前提でその中から選択して導入するものという説明ですが、実機の操作やケーブルの抜き差しがともなう組み込み系のシステムテストを自動化しようとしたらツールを作るところからになります。

こちらは筆者がプログラマだった頃、電源のオンオフやテスト信号の切り替えを含むテストの省力化とソフトウェア開発の自習を兼ねて個人的に製作した治具で、メカ（ケース設計、ケース加工）、エレキ(回路設計、実装）、ソフトウェア（ファームウェア設計、実装）を組み合わせてできています。ソフトウェアのQAエンジニアはソフトウェアのエンジニアといっても周辺領域を組み合わせられると品質技術の幅が広がります。

また、電源のオンオフを今時の技術でアップデートしてスマートプラグと100行程度のPythonのスクリプトでできるようにしました⁴が、Pythonでプログラムを書けるようになっておいて良かったと思います。

まだ世の中にないものをエンジニアリングで実現するという点でQAエンジニアもまた開発者ですがプログラマがプログラミングを深く掘ってゆくのと比べるとQAエンジニアは横に広く、専門分野を極めるI型というより使える技術は何でも投入して解決するT型、π型、フルスタックという感じです。個人的に身につけたスキルがすぐに組織で役立つとは限らないもののスキルと経験の掛け合わせが日々寄せられるソフトウェア開発のよろず相談に役立っていたりもするので得意分野にプラスして広く浅く押さえるのがお勧めです。

4. おわりに

組織内でうまく行った方法の「水平展開」は成功の再現性を高める大事な取り組みですがその方法がうまく行ったのはその時の組織内外のコンテキスト（状況）と合っていたためという考え方もできます。

コンテキストの変化に対応し続けられるよう知識やスキルをふだんから「開拓」して品質保証の兵站（技術ロジスティクス）⁵や組織の開発能力を高め、持続的成功の実現を図るのもQAエンジニアの大事な役割になります。

1. SQAの活用（清水吉男, 2006） ↩

2. 中国オフショア開発－ソフトウェア品質保証と事業OEM（河合清博, 2014） ↩

3. 「SQAの５つの役割」について考える ↩

4. 電源をオンオフするテスト手順を自動化する ↩

5. 思考実験：AQUAフレームワークの品質保証兵站への応用 X. 付録：品質保証兵站 ↩