はじめに
それは、昨年の瀬のこと。12月24日夕刻。やれ七面鳥だ、やれケーキだ、やれネットスーパーだと世が浮かれている頃、私もご多分に漏れずKFCや波乱万丈のカーネルサンダースの半生に思いを馳せながら、久しぶりにオフィスに出社して仕事のラップアップをしていた。
「・・はい、今目の前にいますよ」右前方の席でWeb会議をしているプロダクトマネージャーのA氏の声が聞こえる。そのときオフィスにいたのは私を含めて3名。私の左斜め後方にはBizDevのエースB氏がWeb会議をしているところだった。
コーポレート部門所属の私を挟んだA→Bの外角高めのスライダーであると判断し、きちんと意識をチキンに戻す。そのとき、スッコココと、Slackの通知が鳴る。代表からの「@udon、今トゥゲザーしましょう*1」というメッセージだった。 QAの人手が足りてないという話と、今目の前にある仕事はいったん棚上げでQAにダイブして欲しいという依頼だった。 QAってQuestion &Answerではないやつですよね.. という愚問はグッと堪えて、「君にしか頼めないんだ」という言葉を胸に、そうかな〜そういうもんかな〜とホイホイ踊り、2つ返事で引き受けたのだった。
以下は、奥深いQAの世界に非エンジニア、元コンサルのコーポレート部門の人間が2か月間ダイブ、コシを入れて取り組んでみて学んだことを徒然に記したものである。
改めて自己紹介
新卒でL.E.K.という欧州系のコンサルでM&A戦略等に関わった後、丸亀製麺を運営するトリドールでうどんの海外展開や米国の海鮮丼チェーンの買収などをやっていました。 店舗のキッチンに立ってオペレーション改善もやりました。その後政府系PEファンドを挟み、昨年10月に10Xに入社しました。 30年uemuraとして生きてきましたが、最近は諸事情によりudonとして生きています。
10Xには、Corporate Strategyという、いわゆるコーポレート部門の経営企画（経企）に近い機能をもつ部署の一人目として入社しました。 エクセル弾いて予実管理や事業計画、ということもやりますが、そもそも事業をきちんと理解していないと血の通った事業計画も戦略も立てられないし、組織に課題が合ったとて常に人的リソースが潤沢にあるわけではないということも重なり、期間を区切ってさまざまな現場に行って問題解決にも取り組む機会に恵まれました。 入社直後に次の記事にあるようなスーパーのバックヤードで箱詰めするところから始まり、その後はCS部門の立ち上げのサポート、そして今回のQAへのダイブと繋がっています。
背景
10Xには、4月から待望の1人目のSET（Software Engineer in Test）のメンバーが入り、 1人目QAエンジニアも6月に入社予定となりました。 それまでは、QA専任のメンバーはおらず、PdM、SWE、BizDev、CSといったさまざまな職種のメンバーが協力しながら取り組んでいる状況でした。
私が関わり始めた当時は、第三者検証会社の方々の協力を頂きながら、QAという機能を独立した活動として定義しましたが、社内で専任の人はいないという状況でした。 品質保証・テストのプロフェッショナルである第三者検証会社の方々の手を借りることはできますが、基本はPdM陣がプロダクト開発と兼任しながらQAの部分も見ていました。
その中で、複数の小売パートナー様のローンチというのが平行して走る中で、本業のプロダクト開発も佳境に入り、いよいよこれは回らないぞ・・！ということで社内で暇そうな、スーパーの現場でプロダクトを使った経験のおかげでキャッチアップが早そうな私に白羽の矢（矢の元は代表）が立ったという状況でした。 結果的にではありますが、最初にスーパーの現場でスタッフ向けアプリを浴びるように使っていたことが役立ったように思います。
取り組んだこと
最初入った時には、QAとかソフトウェアテストというものへの解像度がゼロだったこともあり、「なんかQAやばそう」くらいの認識でしたが、振り返って2か月間で取り組んだことは主に下記です。
- 各パートナー向けのローンチ（計4社）に向けてのQAのスケジュールの管理
- 10X社内の開発チームと第三者検証会社の方々とのコミュニケーションの間をとる
- 自身のQAについての理解向上、及び社内への共有
2か月取り組む中で、自身のQA分野への理解は深まりましたが、（どの分野もそうかもしれませんが..）やればやるほど深いなあという感触で、まだまだ浅いなと感じます。 それでも、スケジュール管理というのは脳内のキャパシティを結構とられるもので、そこを外部化して、概観と基礎の理解をベースに担ったことの意味は一定あったのかなと思います。
苦労した点（非エンジニアからすると何が難しいか）
テストの呼称がさまざまであり、かつ定義にブレがある
ここが一番苦労した点かもしれません。 新しい分野・領域に飛び込む際にまず私がすることが、単語帳を作ることです。 外国語の習得も似たところがありますが、新しい分野だと、そこでは当然のように使われている用語（多くはアルファベットやカタカナ）なのかがわからない。 専門書とか業界記事を読んでて目が進まないのは、多くは自分が知らない単語に対して自身の脳が拒否反応を示していることの累積だと思っています。
QAの分野に入った際も、「QA とは」とググるところから始め、薦められた教科書を読みました。
最初の壁は、「テストレベル」「テストタイプ」という、テストの種別を分類するための2軸でした。 これらのうち、前者は比較的本やネット上の記事での定義が揃っている一方、後者はさまざまな呼称があり、混乱した記憶があります。 たとえば「機能テスト」という言葉は、次にの記事に詳しく書いてありますが、テストレベルでもありテストタイプの話でもあるので、混合して使われると、結構困ります
特にはじめの方は、自分がまだ知らないものと、業界でもやや定義にブレがあるものの差分がよくわからないので、ざっくり理解する→書いてみる→専門家（社内や外部の専門家）に聞いてみるというプロセスを回してました。
スケジュール管理自体は、ある意味、やることをタスクベースで書き出してそれを社内外のリソース鑑みて、あとは日付で追っていけば回るという側面もありますが、社内外の専門家の意見を聞きながら自身の中でQAの全体像と各種テストの立ち位置（たとえば今取り組んでいることはQAのうちの最後の砦のQC（Quality Control）部分であり、その中でも特にシステムテストの中の〇〇テストをやっている）ということがわかってから、スケジュール管理の肝である見通しとか、リスクといった部分が分かるようになってきた感覚があります。
また、同時に、前述のようにテストタイプについては各社によって呼称がバラバラであることもあって、ある意味「決めの問題だ」ということを専門家からも聞くことがあって、社内でQAという用語の使われ方を一定モニタリングした上で（例 Slackで「QA」という単語で自身に通知がいくようにする）、現状10Xで行われているテストはこれがあって、それぞれこのように呼んで、GitHubやNotion上ではこのように命名しましょうといったことを整理していきました。
エンジニア、（第三者検証会社の）品質保証エンジニア、BizDevチームで、QAというふわっという言葉の中で何を指しているかというのは微妙な違いがあることがあり、リリースまで◯日と1日1日を刻んで取り組んでいる日々の中では、その微妙な違いが爆弾となることがあります。そうした差分に気づいた時に、問題提起をするという動きもしていました。
私も毎度ズバッと「XXとYYに違いがあり、これはZZです」といえたらいいけれど、初めはそうもいかないこともあったので、とりあえず自分をダシに、「今ってXXの部分のYYテストのZZの項目についての話で自分の認識合ってます？」と初歩的な質問をすることで、8割の人にとっては「当たり前」かもしれないけど2割の人にとっては怪しかったかもという部分を潰す動きをしていたこともあったように思います。
QAにはじめて取り組む方（特に非エンジニア）へのアドバイス
- 上記でも挙げた教科書はわかりやすかったのでお勧めです
- 言葉の定義でブレがありそうだったら、早いところ仮置で定義してみて、周り（BizDevであれエンジニアであれ）壁打ちをしてて、社内の認識の統一を図っていくのがいいと思います
- 言葉の定義を定めていくにあたって、まずは社内でどのように使われているか？を調査するには、Slackの通知にその用語の登録をしておくのが便利です
プロダクト開発のプロセスがよくわかってない
私はコンサル、事業会社（外食）、PEファンドを経て10Xに入りました。テクノロジーという分野は常々興味ある分野であったし、ガジェットについても結構こだわる派であったので、「IT」というものはむしろ得意と思っていました。
一方、今回QAという、開発に近い領域に関わらせてもらう中で、改めて自分がソフトウェアというものがどうやって作られていて、どう出荷（リリース）されるかの流れについて無知だったなあということをひしひしと感じました。 自分が何気なく使っているアプリの裏側で、サーバーとクライアントという概念があったり、個別の小売パートナーへの開発がプラットフォーム上の他の挙動に影響を及ぼしうるということであったり、「イシュー」という単語がコンサルと開発どちらもよく使われるが用法が違ったり、等々
QAというひとつの切り口ではありますが、次の記事でも書かれているように、QAとは出荷前の最後の砦として存在しているものでなく、本来は開発プロセス全体に関わるものであるのです。
非エンジニアの自分にとっては、こうした機会でその片鱗を見ることができたのは非常に貴重な機会でしたし、本業である事業戦略を作っていくとか、あとは小売パートナーと提携をしていく中で、こういった解像度が高まったのは非常にありがたかったと感じます。
余談ですが、私がいた外食企業でも確かにQA/品質保証という部署はあり、そのカバー範囲は、調理前の原料や提供前の料理の最終チェックということだけでなく、それを未然に防ぐための手洗い励行だったり、調理のプロセスや器具へのフィードバックだったり、広範なものだったなと思います（なお品質保証部長と1週間US出張しての学びは、「手洗いメッチャ大事」）。
非エンジニアで開発について知りたい方へのアドバイス
- 私のように非エンジニアだけど開発について知りたい！と思っている人は、何らかの手段でそのプロセスの一端に関わるのがいいと思います。エンジニアに「開発について教えて！！」と言っても困ってしまうし、そもそも自分としても何が知りたいかワカランというケースも多いと思います
- はいQAやって！というケースも珍しいと思いますが、テストケースの実行の手伝いをするとか、たとえばアプリアップデートのリリース文書いてみるとか。なにか切り口をみつけて実務で関わると、その一端から見えてくる世界があると思います
「どこまでやったらいいか」の判断が難しい
これは、永遠のテーマな気もします。QAの海をすこし回遊していた私が、未経験の人と話すときに初めに伝えるのは、「QA*という活動を経なくてもソフトウェアの出荷自体はできる」ということだったりします。
なんとなく、私を含めビジネスやコーポレート出自の人間の視点では、最後リリースするまでにQAとして「OK」を出してほしい、黒か白か、というイメージを持ちやすいかもしれません。しかし、すべてのパターンをテストしてパスできましたということを証明するのは現実的に無理です。実際には「ほぼ白」というラインを決めて、OKを出していくことになります。 「どこまでやるか」の決定には主観も入りますので、そういう意味では、「良くできているので何もしないでOK」と決めるのであれば、QA*をしなくても出荷（リリース）はできるということになります。
しかし、当然ながら、バグのない完璧なソフトウェアというのは（おそらく）存在しないので、「ほぼ白」がどこなのか？を判断していくことになります。 なので、「QAやります」の言葉の裏には、そこの「ほぼ白」を定義するという、サイエンスよりはアートに近い世界が存在します。社内でも、社外でも、ここの理解度を高めることが、より平和な世界につながる気がします。
お客様と対面する営業や事業開発の視点では、お客様に「品質担保しっかりやってよ」とか「御社として問題ないようにしてほしい」ということをいわれると、「QAというプロセスをきちんと回す」ことが解決策と考えるのは自然なことだと思います。 ただ、その課題解決に向けた社内の過程は、人を＋◯人入れれば良いとか、あと◯シナリオを回す、というサイエンスで切れるものだけでなく、「ほぼ白」のラインを定義するというアートがあります。
ですから、お客様に対して満足のいくプロダクトを出すということは、そうした定義を踏まえた上で、営業や事業開発という、お客様に対面するメンバーが、そうした側面を理解した上で、何を示せば目の前のお客様は納得してくれるか？を因数分解して説明を尽くすということが肝要だと考えます。 特に、10Xは一義的には小売パートナーを相手にするB2B2C企業であり、表側のアプリケーションを作るだけでなくネットスーパーのオペレーションを実現するインフラを提供していますから、完全なるB2C企業と比べても求められる水準も高いと認識しています。
同様の文脈で、「2週間確保していたこのテストを1週間でできないか？」に対する答えはテストする項目や観点を減らせば良いので「できる」ことが多いですが、その分不具合が発生するリスクがあがるということになります。 たいていの場合、スタートアップでは時間に余裕があってテストに時間をかけられる状況より、リリースまであと◯日、と切羽詰まっている状況のほうが多いでしょうから、時間の制約がある中でどれだけ品質担保のレベルを上げられるか？ということが肝になります。
開発の現場に触れはしましたが、実際に開発をしていたわけではないので、この「どこまで良いか？」という判断を私の方でするのは難しく、かつ関わっていたエンジニアやPdMにそこを判断してもらうリソースの制約もあります。 なので、もう少し少ないシナリオ数（＝テスト時間）で同程度の品質を担保できたのでは？と思う場面はありましたが、安全に振って多めにやっていたいなという所感はあり、ここは私としては難しさを感じた点でした。
QAに接点を持つことになったすべての方へのアドバイス
- QAの分野はすべてのパターンをテストする、真っ白を証明するということが難しい一方、締切がある領域だと認識をすること。それゆえ、どこかで線を引かなくてはいけないが、その取組はサイエンスよりアートに近い部分があることを理解した上で、期間を定めて（1−2週間とか）さまざまな人と話すのがいいと思います
- 大上段の方針は経営レイヤーで決めるという前提のもとですが、細かい部分では、プロダクトを開発するエンジニア、お客様と対面している営業/事業開発職のメンバーからなるべくいろいろな意見をヒアリングする。それを通して、どこに理解のギャップがあって、ここで折り合えそうだというポイントをみつけて提案していく。初めから器用には難しいかもしれませんが、提案を通して議論のたたきを作ることができれば、事業を前に進める一助につながるのでないかと思います
QAはなぜ大切か？
社内で、「QAは大切ですか？」という質問に対してNOと答えるメンバーはおそらくいないと思います。 それでも、10Xを含めQAが課題として上がるのは、それが開発スピードと開発費用とのトレードオフとなる場面があるから。 時間とお金というリソースが無限にあれば、どのプロダクトに対しても品質担保ができますが、基本的にはそのどちらにも制約を抱えているスタートアップという世界において、折り合いをつけていくことになります。
これは上述したSETメンバーからの受け売りですが、バグの検出は、要件定義や設計段階での検出と比較して、リリース後の発見では数百倍になるリスクがあります。
私を含めQAの経験がないメンバーからすると、QA＝QC（リリース前の最後の砦）というイメージが強い気がします。 時間とお金というリリースの制約がある上で、いかにリリース前に最適なQAプロセスを作れるかを考えよう、という考えに到れるのはおそらく大きな一歩ですが、QAの本来の役割に立ち返ると、これだけでは不十分です。 実際にはそれを設計やその前の段階から未然に防ぐための仕組みづくりが重要となります。
それが作られると、良きプロダクトを、適正なコストで、早く届けることでき、法人のお客様、及びその先のエンドユーザーがハッピーになる。その実現の鍵がQAだと私は考えています。
2か月やってみたその後
- 無事に4社に向けたプロダクトのリリースができた！
- 1人目のSETメンバーが入り、2人目のメンバーも決まった！（参考: 1人目のSETが話す10XのQAの今と今後）
- 社内のQAの用語とプロセスについての認識の統一が進んだ！
- 分野を横断して色々やってみていいんじゃないかという雰囲気が出た！（気がする）
コンサルとQAの共通項
最後に少しだけ、あえて共通する部分があればということで書いてみました。 結構コンサルの人とか性質としては向いているのかもしれないと個人的には思いました。
なお、「コンサル」と「QA」はともに、その言葉が指すところは広範なのですが、ここでは人ではなく業務の中の要素における相似について、あくまで私の経験を元にした所感を書きます。
言葉の定義が大切
コンサルの人々は結構言葉にうるさい人種だと思います。 それは、必ずしも自分がクライアントほどに詳細を知らない分野において、構造化をして洞察を出していく必要があるためです。 その構造化、そしてロジックを作っていくために、土台がグラつくとあとが積み上がりませんから、ひとつひとつの言葉について定義をしています。 過去に私が働いたアメリカ人の上司は、「How to work with me」というスライドを1枚持っていて、自分が使う言語や性質について定義をしていました（これはtoo much）。
上記に記載したように、現状QAの業務の中で使われるテストの種別であったり、ひとつひとつの業務については、会社によって呼称が違う部分もあります。 なので、そうした言葉の感度を持って、自身のいる組織における最適な定義をしてそれをベースに業務を組み立てていくということの重要性の高さという意味で、共通する点があるなと感じました。
綿密なプロジェクトマネジメント
QA、特に最後の砦のQCにおいて、結構1日1日を刻むプロジェクトマネジメントというか、スケジュール管理が行われているなと感じました。 コンサルは人月商売なので、どの職位の人を何週間（or 何日）張るかでフィーが決まります。そのため、決まった期間（たとえば3か月）においてかなり詳細にスケジュールを組み、稼働を管理します。コンサルの費用は主に人件費なので、そのコントロールのために、やや炎上しかけている案件とかだと、結構週次単位で人が入ったり出たりということもあり、文字通り1日1日を刻んで生きていた記憶があります。
私が関わったQAの業務は主にリリース前のQCのプロセスでしたから、リリース日は決まっており、そこに向けて必要かつ最適な量の品質担保（＝テスト）を実行するのが命題でした。 わからないなりにですが、誰が何をしていて、何日かかりそうで、どのタスクとタスクに因果関係があり、どのタスクは締め切りに柔軟性があるかを把握して1日1日のスケジュールに落としていくというプロセスは、コンサルで1日1日を刻みながらスケジュール組んでいたものと似たものがあるなと感じました。
最後に
私はコンサルで、色々な業界や国に突っ込まれてなんとかキャッチアップして生き抜くということをちょくちょくやってきたので、こうして新しい分野に飛び込むことは好きだし、ある程度慣れがありました*2。
それでも、その分野を理解し説明するだけでなく、自分が担い手になるのは新鮮な経験でした。
QAという分野の概観を理解する前から、重要なパートだろうなという予想はあったので、なにかとヒヤヒヤしましたが、こうした重要なパートを任せてくれるところは10Xの良いところだと思います。「新参者だから」とか「専門家でないから」といって遠慮せず、とりあえず主体的にやってみる（「Take Ownership」）ことが大事だなと感じました。
とはいえ、最初の頃は知らないものは知らないし、わからないことはわからないので沢山質問をしていました。 その点では、10Xはさまざまな専門家が集まってきていて、皆知見や知識のシェアに惜しみがないというか、優しいなと感じます。 今回の2か月の中で、本やネットの記事といった二次情報は大いに参考になりましたが、やはり社内のメンバーに教えてもらったことは大きいです。
それは新しい分野に飛び込む機会が沢山あるということでもあると思いますし、それをサポートする体制というか、マインドの人が10Xには多いと思います。 As One Teamというバリューが浸透しているなと感じた一面です。 「IT系の会社で数年働いたけど、そんなにソフトウェアのことはわからない」というビジネス側の人を何人も見てきたので、BizDevとかSWEとかコーポレートとか、職種の違いはありますが、皆ごっちゃになって一緒にコトに向かっている10Xという環境は面白いなと思います。
QAという分野は勿論、さまざまな職種で仲間を募集しています。ぜひ一緒に働きましょう！
