業務委託、人気サービスにアサインされる。

初めまして。hayateと申します。
standbesidethewind04というユーザーIDです。
颯という本名を切り分けて英語にしてみました。04をつけると足が速そうに見えて良いですよね。

私はラクスパートナーズという企業に勤めているQAエンジニアです。
※弊社はいわゆるITエンジニアの派遣・常駐支援を行っている会社で、様々な企業様へとアサインし、開発やQAを支援しております。
（企業ページ良ければ見てね）

　新卒で入った小売業の企業体質が合わず、調子を崩してしまい、逃げるように転職活動~入社して今に至ります。
面接を受けるまでQAという職種を知らなかったのですが、なんだかんだこの職種を気に入ってます。

　およそ2年前に参画した、個人にとって2社目となる企業様で、内製化チーム樹立に向けたQA支援のお話をいただき、その時の経験が今の私の血肉となっているので、そのことを振り返りながら記事を書こうと思います。

プロダクトの骨組みがない。

　そんな参画した現場ですが、とあるAVODサービスで、皆さんももしかしたらご利用されたことがあるのではないかなと思ってます。喫茶店でお茶しているときも、サービスの名前を耳にするくらいには世間に浸透している気がします。
　私もいちユーザーとして、楽しく利用していましたが、参画してふたを開けてみたとき、こんなことを思いました。

「こいつ、骨がないのにマッチョすぎて成り立ってやがる...」

そう、サービスが流布している割に中の土台がなく、仕様書などがまるでない状態でした。

そのサービスは開発を長いこと外注していたり、企業内でも出向社員の方が多いため、メンバーの新陳代謝が激しく、レガシーを残す文化が醸成されていなかったのです。

※これは骨なしチキン。お前だけは許されるが、サービスには許されないんだ。

私が入ったときにはプロパーのQAの方が上司として迎え入れてくださいましたが、その方も入社２か月目のフレッシュな方だったので、とりあえずQAとして何をするべきなのかを一緒に考えていくことにしました。

内製化ってなんだろう？

　一口に内製化といっても駆け出しの私にはどんなことをやればよいかわからない。何をやればよいんだろう？
このことを考えて参画2日目で高熱を出しました
いきなり体調を崩したのでものすごくご心配いただいたことを覚えていますｗ

結局内製化っていうのは
「外部に頼っていたものを自分たちでまきとること」です。
今あるルールと、これからのルールを自分の裁量で整えられるということです。

　アサインいただいた当時、現場経験が１年に満たなかったのですが、「ある程度自由なんだな」と、気軽な暗示をかけられたおかげでスムーズに事を運ばせるマインドセットになりました。マッチョイズムが浸透したのかもしれないです()

　QAとしてテスト仕様書のお作法や、当たり前品質の策定、不具合の優先度基準などを策定してきましたが、特に思い入れのあることをピックしてお話ししようかなと思います。

書いたこともない人間が、画面仕様書の記載を任される。

　じゃあ今ある仕様を整えていきましょう。という話から画面仕様書をつくることになりました。

ワイ「画面仕様書って、PMさんや要件定義をした人が作るものなんじゃないんですか？」

上司「うちにPMさんあんまりいないのと、忙しくて作れなさそうやねん。QAでつくれるんちゃうん？って言われたんよ。hayateさん前の現場でツールの説明とかコンフルまとめまくってたって話だからいけるっしょ」

ワイ「う、うぇ～」

画面仕様書をどのように書くのかなんて誰にも教えられていなかったので、正直困りました。ただ、マッチョになった私のマインドある程度の自由を持っています。どのようにすれば見やすい項目になるかを考えながら手を動かしました。

　わからないなりに進めていた結果、ざっくり4つ課題が見つかりました。

課題	対策
どういう情報があればよいか	画像、デザインページ、実装リンク、要素の概要とイベント、API取得元、遷移元、関連資料
画面名はどうしたら伝わりやすいか	チームごとに微妙に呼称が異なっていたので、管轄することの多いチームの意見を中心に、その名前や折衷案を提示し策定
情報が溢れないようにするにはどうすればよいか	画面仕様書内にそもそも書ききらないようにする
そもそもわからない仕様はどのようにキャッチアップすべきか	とりあえず実機触る。ロジックが曖昧ならPMやディレクターに質問しまくる
Web/iOS/Androidで挙動が異なる場合があったぞ	実装者とディレクターに別途資料を作成し共有。仕様としてそのままGoするか、それとも起票するかなど対応方針を決めた

　特に３つ目には頭を悩ませましたが、大学のレポート作成のときに、書くのがちょっと面倒だなと思ったときに引用しまくったことを思い出して
「あ、ここに全部書かなくていいじゃん。『困ったらここ見てね』の導線を作ればすっきりするじゃん」と思い、どこか良い場所ないかなと思ったところで、あの言葉が脳裏にわたりました。

上司「前の現場でツールの説明とかコンフルまとめまくってたって話だからいけるっしょ」

コンフル使って、ログインフローや、ライブステータスなどの複雑な処理を丁寧にまとめて、画面仕様書に「ペンっ」と貼り付ければすっきりするやん！

　当たり前かもですが、情報設計上の見易さを追求するための大事なポイントに出逢えました。
まとめ方褒められたので、その日のご飯がおいしかったのを覚えてます。

画面仕様書作成

　レビューもMTGで同期的に行い、何とか完成。
　
現在はマニュアルで更新するのが大変なので、AIにコードを読み込ませてマークダウンで作らせるプロジェクトが始まっているので、この仕事はなくなりました。
しかし、元となる資料として私の成果物を参照していただいているので、形は変わっても、確かに今までなかった「レガシー」を作ることができました。

内製化は怖いが自由である

今あるルールと、これからのルールを自分の裁量で整えられるということ。

これが内製化の面白いところだと思います。

　自分なんかがルールを作ってよいのか？と正直怖かったです。
　ですが、正解のない問題の正解を少しずつ定義していき、サービスを推進していく支えを考えることは、必ず外部に委託している状態よりも品質を上げられると今でも信じています。

　普通のプロダクトであれば、経験のある1人目QAをプロパーとして採用し、内製化を進めていくと思いますが、現場経験1年に満たない状態で意見を形にできたことは、ほとんどテスター業務にとどまっていた私のブレイクスルーになる経験でした。