1. はじめに
2018年6月27日に開催されたLINE Developer Meetup in Tokyo #39の「イマドキのソフトウェアのテストやQAの考え方」で電気通信大学の西さんよりAQUAフレームワークがお披露目されました。
残念ながらMeetupには参加できなかったのですがAQUAフレームワークは品質保証戦略の立案だけでなく品質保証兵站の計画立案にも応用できそうと思いました。そこで思考実験として架空の牛丼屋さんを例にAQUAフレームワークの力を借りながら品質保証兵站の一つである品質保証技術の開発計画をちょっとだけ立ててみます。
2. AQUAフレームワーク
AQUAフレームワークを筆者なりに読み解くと「A(Accelerating project)、Q(Qualifying value)、U(Unveiling weakness)、A(Accumulating knowledge)という4段階のコンテキスト(プロダクトやプロセス、組織の成熟度、あるいは環境などから構成される背景)を提示し、コンテキストにマッチするように、かつ、知のスケールアウトを促すように品質保証戦略を立案することを目的としたフレームワーク」です。資料の25ページ目に「コンテキストは常に変化し移行するものであり、複合して発生し、先読みも必要」とあるようにAQUAフレームワークが着目するコンテキストは目先のものだけではなく将来のものも含んでいます。
ここで「先読み」を拡大解釈した筆者は、ありたい姿や計画、見通しなどから将来の品質コンセプトパッケージを描いてバックキャスティングで品質保証戦略を立てられるようになるかもという期待を持ちました。
また、品質保証戦略を語る夕べで商品のライフサイクル(導入期、成長期、成熟期、衰退期の曲線)が紹介されましたが、実際のプロジェクトに適用する際に5つ目のコンテキストとして衰退期のコンテキスト(リソースは投下できないが品質問題を起こすわけにはいかない状況)を加えるといったアレンジをAQUAフレームワークに加えても良いように思いました。
3. 牛丼屋さんの品質コンセプトと品質保証技術
本稿で着目する牛丼屋さんの品質コンセプトを、1. 早い、2. うまい、3. 安い、とします。
- 牛丼屋さんは 1.早さ、2.うまさ、3.安さ、を保証する仕組みを作り、品質基準を満たしていることを確認し、それをもって品質を保証します。
- ソフトウェアの品質は定量的に測れるものばかりではありませんが本稿に登場する牛丼屋さんは品質を満たしているかを判断するためメトリクスとその目標値を決め、メトリクスを測る手段(技術)を用意し、測定を行うとします。
- 早い・うまい・安いという結果的側面に限らず、食材の安全性、店舗のきれいさ、立地、従業員対応、労働環境なども品質コンセプトの一つと考えられますがここでは割愛します。
3.1 早い
早さをはかるメトリクスとして例えば以下のようなものがあります。
- 注文してから提供されるまでの時間
- 店員さんに声をかけて会計をお願いしてから完了するまでの時間
- 混んでいるときの待ち時間
いずれもストップウォッチで計測が可能で、目標を決めて実際の時間を測ることで品質を満足しているかを判断できます。
3.2 うまい
ここではうまさの秘訣を「食塩の量を肉の量の3%にキープすること」とします。規模や工程によって食塩の量の測定方法は異なります。
- 調理前の肉1kgに対して食塩30gを測るなら大さじ2杯
- 調理前の肉10kgに対して食塩300gを測るならキッチンスケール
- 調理後の「牛丼の具」で測るなら塩分計
3.3 安い
- 安さを競合より常に安くすることとするとそもそも競合を牛丼・牛めし屋にするのかファーストフードも含めるのかコンビニ弁当と戦うのかといったビジネスエッセンスの定義がまず必要になります。
- 牛丼一つで創業してもメニューを拡充することで定食屋が競合になるかもしれません。あるいは新たな競合が出現するかもしれません。
- そのうえで競合の値段の変化をいち早く捕まえる技術を導入します。
品質保証戦略やそのもととなるビジネスエッセンス、品質コンセプトはいちど作ったらおしまいではなくコンテキストの変化に合わせて見直しが発生します。ビジネスエッセンスや品質コンセプトは変えずに品質保証戦略を見直すケースと、ビジネスエッセンスや品質コンセプトを見直すケースの両方とも考えられます。
3.4 ソフトウェアの品質保証技術の開発に置き換えると
ストップウォッチや計量スプーン、キッチンスケール、塩分計は既製品がありますが品質保証のツールはしばしば新規に開発したり改修したりする必要があります。
開発する技術が複数あり難易度も様々となるとロードマップが欲しくなりますね。また、ヒトモノカネといったリソースの話もあります。
変化を受動的に受け入れて都度都度対応していくのも一つの方法ですがこれだと後手に回る感があり、できるなら変化を見越して先手を打っていきたいです。例えば今期の予算は先期立てたものですがコンテキストの変化に合わせて新たなQA活動をしようとしても予算を積んでいなかったのでできない(来期に予算を積んで延期する)なんてのは避けたいわけです。
品質保証技術の開発は兵站に属するQA活動の一つで品質保証戦略やそのもととなるビジネスエッセンス、品質コンセプトパッケージはいつ何を開発するかを決めるガイドとなります。コンテキストの変化に対してその都度フォアキャスティングで品質保証戦略を立てる(メンテナンスする)だけでなく、AQUAフレームワークでありたい姿や計画、見通しなどから将来の品質コンセプトパッケージを描いてバックキャスティングで品質保証戦略を立てることで例えば技術開発のロードマップ作製や来期の予算立案がやりやすくなるのではと考えています。
4. もし牛丼屋さんがAQUAフレームワークを使ったら
この牛丼屋さんは注文すると商品がすぐ出てくることで話題になっています。また、「牛丼への依存度を下げリスクを分散する」という経営戦略のもと、経営作戦の一つとして「5年以内に牛丼以外の飲食店を開く」という作戦を立てています。品質保証戦略や品質保証兵站はこれら上位の戦略、作戦と整合性が取れている必要があります。
4.1 コンテキスト
早さに関するコンテキストを例示します(うまい、安いは本稿では割愛します)。
| 年度 | 一年目 | 二年目 | 三年目 |
|---|---|---|---|
| 目的 | お客様を増やす | リピータを増やす | お客様を流出させない |
| コンテキスト | Accelerating project | Qualifying value | Unveiling weakness |
| フォーカス | 商品提供の圧倒的な速さで話題になる | 会計で待たせない | 混んでいても待たせない |
| 取組み | 調理の工数削減 | 会計の待ち時間の削減 | 下膳の工数削減1 |
メトリクスとその目標を以下に示します。2
| 品質の切り口 | 品質コンセプト | メトリクス | 一年目 | 二年目 | 三年目 |
|---|---|---|---|---|---|
| 結果的側面 | 早い | 注文してから提供されるまでの時間 | 40秒 | 30秒 | 20秒 |
| 結果的側面 | 早い | 店員さんに会計をお願いしてから完了するまでの時間 | 30秒 | 25秒 | 20秒 |
| 結果的側面 | 早い | お客様が席を離れてから下膳作業が完了するまでの時間 | 30秒 | 25秒 | 20秒 |
| 結果的側面 | うまい | (割愛) | |||
| 結果的側面 | 安い | (割愛) |
4.2 品質保証技術の開発計画
労働のスケールアップで早さを実現しようとすると猛練習した店員さんが高速でおたまを振ったりレジを打ったりすることになると思いますが、そうではなく、5年以内に牛丼以外の飲食店を開くといったコンテキストとの整合性をとりつつ知のスケールアウトを促すようなシナリオをバックキャスティングで描きます。以下にその例を示します。
- (目標)5年以内に牛丼以外の飲食店に進出する(Accumlating knowledge)
- (そのためには)牛丼以外の商品をお店に投入できるようになる
- (そのためには)牛丼以外の商品が開発されている
- (そのためには)どの店員さんも新しい商品が増えてもさばける(知のスケールアップをした店員さんをたくさん抱えている；知のスケールアウト)
- (そのためには)牛丼以外のメニューも店員さんがこなせるようになる(個々の店員さんの知のスケールアップ)
- (そのためには)自動化可能な作業を自動化し店員さんの余裕を作る
自動化の例としてボタンを押すと規定量のごはんが丼に入る機械や、お客様の注文を音声認識して調理を開始する機械、現金や紙のクーポン券を使わずスマホアプリで決済やクーポンの取得、消費する仕組みといったものが考えられます。下膳については例えば深圳の無人食堂の実験の様子がツイートされていましたが本格的に導入するにはもうちょっとイノベーションが必要そうです。
技術開発の対象を1.調理、2.会計、3.下膳に分解し、品質保証戦略に則って初年度は「調理の作業にフォーカスし自動化の効果が高く、かつ、難易度の低いものから開発を行う」「難易度の高い技術開発も着手し二年目の末までに提供時間30秒をクリアする」、「会計や下膳はリサーチを行い二年目の開発費に反映させる」といった方針を立て、ロードマップに「ボタンを押すと規定量のごはんが丼に入る機械」や「音声認識して調理を開始する機械」、「スマホアプリ」、「下膳装置」を配置します。
4.3 その他
本稿では組織的側面の品質コンセプトは割愛しましたが店員さんはおたまを高速で振る必要がなく余裕をもって仕事ができることから定着率が高くお店としてもスキルを身に着けた(知のスケールアップをした)店員さんを流出させずに済むといったメリットがあるかもしれません。
5. おわりに
経営戦略－品質保証戦略－品質保証兵站が互いに整合性を持ってつながり、かつ、目先だけでなく将来もスコープに含めた計画を立てられるかもという期待感が伝わるとよいなあと思う一方で、架空の牛丼屋さんの架空の技術開発計画ではピンとこないかもとも思います。モヤっとされたら現実のQMSに置き換えていただけますようお願いします。
6. 参考
- 品質保証戦略、ビジネスエッセンス、品質コンセプト：ソフトウェアの品質保証の基礎とこれから
- 品質保証兵站：QAアーキテクチャの設計による説明責任の高いテスト・品質保証 ※技術ロジスティックスという呼び方をされています
- GQM(Goal Question Metric)：JaSST'17 Tokyo招待講演「品質保証活動の本質」の講演資料
- AQUAフレームワーク：イマドキのソフトウェアのテストやQAの考え方
- 品質保証戦略を語る夕べ（8/21）(togetter)
- 深圳の無人食堂の実験の様子(shao (Sho SAWADA)さんのツイート)
X. 付録：品質保証兵站
品質保証戦略があるなら品質保証作戦や品質保証戦術、品質保証兵站があっても良さそうですよね。
筆者のググり方がイマイチなのか品質保証兵站でググってもドンピシャなものは見つからないのですが、「ここは苦しいところですが、どうか一つ、QAアーキテクチャを。」というQA勉強会に参加したときの西さんのスライド「QAアーキテクチャの設計による説明責任の高いテスト・品質保証」に技術ロジスティックスという呼び方で品質保証兵站が登場します。
技術ロジスティックスは技術を供給するための仕組みや経路のことを指し、以下のような解説をされています。
- アシュアランスパイプラインを支える技術ロジスティックスにもQAは大きく関わらなくてはならない
- a)手順だけでなく技法や方法論、ツールも含むプロセスのポジティブナレッジ、ネガティブナレッジをテックシェルフ(技術の棚)に適切に蓄積すること、b)テックシェルフからプロセスに技術を供給すること、のどちらも重要
- 技術ロジスティックスが構築・改善されてない組織は競争力を向上できない
ところで兵站には技術的なものもあればあまり技術的でないものもありそのどちらも大事な役割と筆者は考えています。以下に筆者の考える品質保証兵站を示します。
X.1 兵站
X.1.1 概要
兵站は「へいたん」と読み、後方支援と呼ばれることもあります。もともとはLogisticsという軍事用語です。
一般に兵站はなじみの薄い単語で、かつ、「戦略→作戦→戦術→兵站」というピラミッド構造の最下層という位置づけのようです。図解するとこんな感じ。
ともすると兵站は雑用と思われがちですがこれは雑用レベルの兵站しか知らないためと思います。Logisticsをアメリカ陸軍野戦教範で調べると "the process of planning and executing the movement and sustainment of forces in the execution of military operations."(U.S. Army Field Manual 100-5 Operations Glossary-5) とありGoogle翻訳すると兵站は「軍事作戦の実行における軍の移動と維持を計画し実行するプロセス」です。
軍事用語の説明なので物騒な感じがしますが、例えば「ソフトウェアテスト293の鉄則」の鉄則278にある「段取り」は原著の「Logistics」を訳したものというのがソフトウェア・テストPRESS Vol.5の「特集1 [入門]テスト計画の立て方、書き方、進め方」で紹介されているように段取りを組むのも兵站の役割の一つです。テストの段取りとして、人員の確保や教育、テスト環境の調達や準備、コミュニケーション、テスト結果を伝える手段が挙げられています。
X.1.2 兵站の役割
軍事における兵站の役割を一言で表すと「継戦能力の維持、向上」で、戦闘部隊の戦闘力の維持向上に必要な人員、武器、物資など「必要なものを」「必要な時に」「必要な量を」「必要な場所に」供給することです。前出の野戦教範では兵站に含むものとして以下を挙げています。
Logistics includes the design, development, acquisition, storage, movement, distribution, maintenance, evacuation, and disposition of materiel; the acquisition, preparation, maintenance, equipping, movement, and health service support of personnel; the acquisition or furnishing of services; and the acquisition, construction, maintenance, operation, and disposition of facilities.
(Google翻訳：ロジスティクスには、設計、開発、取得、保管、移動、流通、保守、避難、物資の処分が含まれます。人員の獲得、準備、保守、装備、移動、保健サービスのサポート;サービスの取得または提供。設備の取得、建設、保守、運用、処分を含む。)
ソフトウェア開発で言えばソフトウェアを継続的に設計、実装、テストしリリースするためのソフトウェア開発能力の維持、向上がその役割です。一例として開発やテストに投入する機材の供給を挙げます。
- 目的：機材が必要になったときの待ち時間を減らす
- 作戦兵站：機材の選定・リストアップ、予算立案、購入ルートの確立
- 戦術兵站：需要に応じて機材の購入やキッティング、消耗品のストック
X.1.3 兵站の階層性
上で挙げたように兵站には階層がありますがピラミッド構造の最下層に兵站でひとくくりにしてしまうと階層が見えないため筆者は以下のようなモデルを作っています。
このモデルを組織に当てはめると以下のようになります。
X.2 品質保証兵站
品質保証兵站の役割の一例を以下に示します。
- 品質保証技術の開発、改修
- テックシェルフ(知識、ノウハウの蓄積と展開)
- 機材の予算立案、発注、検収、配布、維持、廃棄
X.2.1 品質保証技術の開発、改修
- メトリクス集計ツール、設計・デバッグツール、テストツールなど
- QAエンジニアやQA-SETと呼ばれたり
- ツールを作って手作業を自動化したり
- テスト自動化に限らない
- 規模や工程、レベル(単体レベル、結合レベル、システムレベル)によって適した技術が変わる
- 食塩の測り方：計量スプーン、キッチンスケール、塩分計
- ソフトウェアのQAが開発するものはソフトウェアだけとは限らない
- 例：ArduinoとオシロスコープをExcelで制御して測定する(2) シャッタースピードの自動測定(筆者が趣味で作った、メカ、電子回路、ファームウェア、Excelを組み合わせた自動テストシステム)
- 題材に使ったカメラは機械式でプログラムは入っていませんがシャッター制御プログラムの回帰テストや性能テストをシステムテストレベルで自動化するのを想定しながら読んでいただけると良いかと…
- 難易度や納期によってメンバーのアサインも関係してくる(一人で順番に開発して間に合う or 複数人で並行して開発する必要がある)
- コンテキストの変化によって品質保証戦略や品質コンセプトパッケージが変わり品質保証に必要な技術が変わる可能性がある
X.2.2 テックシェルフ(知識、ノウハウの蓄積と展開)
ソフトウェアの継続的な開発のため、開発に必要な知識やノウハウを蓄積し、必要な時に取り出し、スキルとして身に着け、アップデートしていくためのテックシェルフ(技術の棚)の役割です。知のスケールアップやスケールアウトと関わってきます。
X.2.2.1 戦略立案
テックシェルフを兵站自身で応用する例として戦略立案があります。
- 品質保証戦略を立案する
- 品質保証KPIを決める
- KPIを測定する手段(技術)を開発する
- KPIを測定する
- 結果を報告する
といった一連の活動を示します。
この図において品質保証戦略は1～2を、品質保証兵站は3を、品質保証戦術は4～5を受け持つように見えるかもしれません。もちろん間違いではないのですが、戦略を立案する知識やノウハウ、スキルがない場合はそれらの獲得からスタートし、獲得した知識、ノウハウ、スキルを兵站自身で用いて戦略を立案し承認を得る方法もあります。これを「兵站駆動型戦略」と筆者は呼んでいます。
- 兵站：本を読んだりセミナーやシンポジウム、カンファレンスへ参加して知見を得る
- 戦略：得た知見を用いて品質保証戦略を立案、更新する
- 作戦：作戦を立案する
- 戦術：戦術を実行する
- 兵站：兵站活動を行う
- 1に戻る
X.2.3 機材の予算立案、発注、検収、配布、維持、廃棄
- X.1.2で記述したようにソフトウェア開発に支障をきたさないように機材面での支援を行います。
- 機材やツール投入による自動化・工数圧縮は経費節約だけでなく浮いた工数でほかのことができるというメリットをもたらします。
X.3 参考
- 新任マネジャーは「戦略」「作戦」「戦術」の違いを図解で理解しよう
- ソフトウェア・テスト PRESS Vol.5
- 兵站(Wikipedia)
- 兵站(ニコニコ大百科)
- U.S. Army Field Manual 100-5 Operations(アメリカ陸軍野外教範 100-5 Operation)
- QAエンジニアってどんな仕事？～ゲーム開発におけるテストの世界～