ログラスQAのミッション・ビジョン・バリューを刷新しました。ここに込めた思いとは
この記事は 株式会社ログラス Productチーム Advent Calendar 2024 のシリーズ 1、6日目 の記事です。
こんにちは。ログラスのQAをやっているコタツです。以前私はこんな記事を書きましたが、1年半を経てミッション・ビジョン・バリューを刷新しました。
この記事を読んだ方が、弊社COO経由で海苔を段ボール1箱分くださる出来事が発生したのもうれしかったです。
海苔はなんぼあってもいいですからね。会社のみんなと美味しくいただきました！ごちそうさまでした、ありがとうございました！
新QAミッション・ビジョン・バリュー
本題の新ミッション・ビジョン・バリューはこちらです。
新ミッション・ビジョン・バリューは今月の初夏ぐらいにはできていたし上記資料はFindyさんのイベントに登壇させていただいた8月時点のもので、そこでもお披露目はしていたのですが、noteにはちゃんと書いてなかったという流れです。サボりすぎてた……。
なぜミッション・ビジョン・バリューを刷新したのか
主に以下の理由からです。
既に出来ていることをミッション・ビジョン・バリューとして置いておく必要性はない
さらに高い目標を目指すべく、ミッション・ビジョン・バリューを上方修正した
エンジニアの協力もあり、エンジニアとQAは一緒に品質に向き合っていくことが当たり前となりました。そこで、私達QAがエンジニア組織とどう協業していくかを考えるのではなく、プロダクト開発組織をより強くしていくというミッションにアップデートしました。
それではさっそく詳細に解説していきたいと思います！
ミッションについて
今回の新ミッションはこちらです。
プロダクト開発のケイパビリティを高め、組織全体のバリューストリームを最大化する
プロダクト開発組織全体が高い顧客価値を提供できるようにしたい。顧客へ最短でかつ安定的に価値を提供できるためにテストや監視、CICDの技術向上に貢献したい。テストだけではなく開発プロセスの改善でボトルネックとなる要因を取り除きたい。良いプロダクトを提供するために良いプロダクト開発組織を作りたい。
以前のミッションは「開発者と一緒にプロダクトという山を登るシェルパとなる」というものでした。QAが品質の門番ではない・リリース判断をする存在でもないというところは共通点として引き継がれていますが、対象を「開発者」から「プロダクト開発組織全体」へと拡大しました。前のミッションは自分たちのことしかフォーカスしてなかったのですが、今回から、プロダクト開発組織全体へのフォーカスと変更になりました。
ビジョンについて
5つの技術・知識を持つジェネレーター
5つの技術とは：ドメイン理解・テスト技術・自動化技術・プロセス改善技術・コミュニケーション技術
私達のなりたい姿をビジョンに定義しました。一部には未だ手に入れられていない技術・知識もありますが、これから手に入れていけるといいなと思っています。
また、「ジェネレーター」という耳慣れない単語をビジョンに入れています。これは以下のNoteにて紹介されている、ジェネレーター理論というものを素にしています。
ジェネレーターは「ティーチャー」「ファシリテーター」のあり方と以下の点が異なります。
外から働きかけるのではなく、内側から働きかける
ともに面白がり、一緒に学び進む
かつてのビジョンは「急拡大する組織で、『良い開発文化』を強化/維持できるようになる」としていました。こちらも方向性は同じではあるものの、どのように開発文化を強化/維持するのかについてQAとしてのスタンスをより具体的に表した形になります。
バリューについて
顧客志向な品質リーダーシップ。組織の弱さに寄り添う。天真爛漫な探究心と対応力
顧客志向な品質リーダーシップ：プロダクト開発組織で顧客のために品質を高める活動を促進していく
組織の弱さに寄り添う：批判するのではなく、組織の足りない部分を補う行動をする
天真爛漫な探究心と対応力：抽象度を調整しながら、柔軟に学び考え、柔軟に対応する
旧バリューは「顧客志向、アウトカムファースト」でした。ここをベースに、かつジェネレーター理論を基に、さらに要素を追加し、具体的にやっていくべきことを定義した形となっています。
以前わたしのレポートラインであるEMが登壇した資料からの引用なのですが、開発チーム全体に対して、QAのバリューはこのようにマッピングされます（上記）。ただしこれを全部一人でできる人を求めているわけではないので、適切にQAが各々の得意分野がどこかを把握し、ケイパビリティが塗りつぶされている状態になればいいと思っています（下記）。
込めた思い
旧ミッション・ビジョン・バリューを作成して一年ほどですが、その間プロダクト組織を取り巻く環境は、事業拡大やプロダクトの成長、組織の成長など大きく変化してきました。私達は変化に対応し、組織の課題に立ち向かうためにQAの動き方をより拡張する必要性があると考えました。
私達ログラスのQAはプロダクト開発組織から独立したQA組織を持っておらず、プロダクト開発組織付で日々動いています。各QAは別々のチームに所属しているので別々の目標を追っていますが、何個かの会議体とコミュニケーションによってQA同士は常に連携しています。
なぜこのような動き方に至ったのかについては前述の記事でも触れておりますので、ご一読ください。今回、新ミッション・ビジョン・バリューを刷新することで、プロダクト開発チームに入り込み、一緒に歩んでいくというスタンスに対して改めて強い意志込めをしました。
品質とはなにか
そもそもの問いで失礼しますがソフトウェアにおける品質とは何でしょうか。「品質がいい」というのはバグが少ないだけでなく、以下のような状態も含んでいる主観的なものであり、曖昧なものです。
バグや障害が少ない
やりたいことがストレスなくできる（UI/UXやサービスの設計）
バグのような挙動を運営会社に伝えたら即修正される
サポートの対応が信頼できる
上記のような例は一部ですが、このように、プロダクト開発にとどまらず、サービス全体に対して多岐にわたるものが品質です。参考までに、Wikipediaのソフトウェア品質のページにもさまざまな品質が記載されています。
このように多岐にわたる品質のうち「バグの少なさ」のみにQAがフォーカスすることは簡単ですが、私は価値あるものを作りたいと思ってログラスに入社したので、一面的な品質のみを担保するようなQAのあり方は選択肢にありませんでした。
全員で品質を担保するということ
他社で私が以前開発者として関わっていた中長期的なプロジェクトにおいて、QAが出荷可能判断をするような体制で開発を進めていました。QAチームと開発チームが別々にあり、QAチームの9割は業務委託で構成されていました。ここでのQAの役割は明言していませんでしたが「バグの少なさ」を追求する存在となってしまっていて、以下のようなことが起こっていました。
QAが作成実施している機能単位のテストのテスト項目が詳細すぎるため細かなバグが多く、オールパスできずリリースできない
QAが一生懸命テスト仕様書を作りバグを見つけていけばいくほど、何度もリリースが延期される
この状況が長期化し追い込まれていくほど、品質の良いものを作る力学が働かなくなっていきました。あとから考えると、ソフトウェアテスト7原則の一つである「欠陥ゼロ」の落とし穴に見事にハマっている状態でした。
「欠陥ゼロ」の落とし穴
ソフトウェアを検証するだけでシステムを正しく構築できると期待することは誤り（つまり、思い込み）である。例えば、指定された要件すべてを徹底的にテストし、検出した欠陥すべてを修正しても、ユーザーのニーズや期待を満たさないシステム、顧客のビジネスゴールの達成に役立たない、およびその他の競合システムに比べて劣るシステムが構築されることがある。検証に加えて、妥当性確認も実施すべきである（Boehm 1981）
この経験から、QAが品質の門番をすることで「欠陥ゼロ」の落とし穴にハマりやすくなる構造になってしまうのではないかと感じました。
今のログラスの規模の開発組織で、かつログラスのような難易度の高いドメインにおいては、QAが品質の門番をすることでスピード感を落とす上に、本質的にやりたかった品質向上に至れず「欠陥ゼロ」の落とし穴にハマってしまう可能性が高まるのであれば、プロダクト開発組織全員で品質を向上する方針としました。
QAが品質の門番をしないということは、誰も品質の門番をしないというわけではなく、開発チーム全体で品質を保証するということです。エンジニア全員で品質を保証するために私達QAは開発組織の内側からアプローチをするという方法を取っています。
私達のやっていくこと
直近私がしていることについても軽く説明させてください。
今回のミッション・ビジョン・バリュー刷新に伴い、前回のミッション・ビジョン・バリュー記事にも載せたログラスQAの考え方のモデル図である品質富士山も見た目や各層の名前・説明など補足を追加したバージョンに進化しました。
ログラスのQAは多岐にわたる品質に対してアプローチしているように見えますが、この品質の考え方のモデル図にのっとり、「この四半期はこういう事情があるからこの部分のプロダクト品質に注力する」だったり、状況に応じて注力ポイントを柔軟に変えながら業務を進めています。
最近私は何をしているかというと、最近組成したフロントエンドチームと一緒に、フロントエンドの共通モジュールの重要機能のリプレイスのため、フロントエンドチームと一緒にテスト分析・設計を行っていたりします。
フロントエンドモジュールは全画面共通で使われているため小さなコード範囲の変更でも影響範囲が大きくなる傾向にあるため、安全なリリースのためのリリース計画を考える必要があります。また、パラメーターも多くテストパターンも膨大になりがちなため、テスト範囲を絞ったり適切なツールを用いてテスト計画をしなければならず、なかなか骨の折れる領域です。
これはプロダクト品質の向上にもつながるし、共通モジュールの変更容易性の向上により開発者体験の向上にもつながります。フロントエンドチームができたばかりなのもあり、プロセス品質の向上にも還元していけると良いなと思っています。
おわりに
いろいろ書きましたがログラスのQAは今2名しかおらず、ミッション・ビジョン・バリューを実現する土壌は整いつつありますが実務としてまだまだ手が回っていないところばかりです。壮大なことを書いてはいますが、実はこんなこともできていないんです。という話ばかりで恥ずかしいので、実態についてはぜひ直接お話させてください。
ミッション・ビジョン・バリューに共感いただいた方や、ちょっと気になった方、冷やかしも大歓迎です。ぜひよろしくお願いいたします！！！！
もちろんアプリケーションエンジニアを始めとした様々な職種も募集中です。よろしくお願いいたします！