見出し画像

ログラスQAのミッション・ビジョン・バリューを策定しました

こんにちは!ログラスの一人目QAのコタツです。皆さんお元気ですか?私は最近、好きな食べ物のトップに海苔が食い込んでくると気づきました。
前回のnoteからまあまあ時間が空いてしまいましたが、変わらず一人QAをやっております。ちなみに前回のnoteは年末でした。

最近のログラスのQAの現在地

ミッション・ビジョンを発表する前に、ログラスのQA組織の現在地について説明します。

私が1人目QAとして入社して1年が経ちました。

  • 私の入社前はそもそもテストの文化すらなかった開発組織に、この一年で品質の文化をインストールし、アジャイルテストを推進してきました。

  • 実際に不具合混入率も下がったので、1人目QAとしては役割を果たせたのかなと思います。

  • 開発組織の現在地についてはこちらの記事を参照ください!

また、2人目のQAの方を採用することに成功しました。

  • 今後、私が見てきた部分は一部お渡しし、QAはチームとしても動いていきたいと思っています。

  • 今までできていなかった・諦めていたことや、新しいことも、2人でやっていきたいと思って色々仕込んでいく段階です。

なぜミッション・ビジョンが欲しいと思ったのか

2人目の方を採用に携わらせていただくにあたり、今までやってきた指針みたいなものを明確に言語化し、認識を合わせる必要性に迫られました。
また、将来的に仲間になっていただく理想のQA像をすり合わせることが可能になると考えました。

この1年間のQAとしてのチャレンジと失敗

策定したミッション・ビジョンを発表する前にこの1年のQAとしての振り返りをさせてください。主に失敗についてご説明していきます。

失敗①緊急対策PJ

ある機能開発において、大きな観点をテストできておらず、緊急対策PJが発足しました。内容としては、既存機能への集中的なテストを行いました。その中で、過剰なテストをしてしまったという失敗がありました。

  • 観点漏れした箇所の重要度が高く、新規開発を止めて対応する必要があった

  • 入社して3ヶ月程度で、チームに「QAとはなにか」を浸透させきれておらず、QA=テストとなってしまった。またテストを期待されていたこともわかっていたため、その期待に応えたい気持ちが先走ってしまった。

  • 結果、発足経緯に対して対応方針のHowが不釣り合いに大きくなってしまい、テストのパターンが膨大になって、開発チームをいたずらに疲弊させてしまった。

一方で、「品質が悪化すると新機能開発も一時停止することがあるんだ」と、開発チームの品質に対する意識が大きく変わるきっかけになりました。

失敗②開発チームと離れたチームで活動

QAは開発チームと離れた横断チームに配属し動いていくということをやってみた時期がありました。

  • QAと、開発チームやプロダクト自体やお客様との距離が遠くなってしまった

  • 結果として、何していけば良いんだっけという状態になってしまった

  • どんどん取り残されるようになってしまって、2ヶ月程度でこの体制はやめて開発チームに入ることにした

ログラスはプロダクトも、組織方針も変化が大きく、ビジネスの成長速度もチームの成長速度も早いため、最新情報の同期コストが大きいとわかったため、QAは開発チームに身をおいて進めていく方法のほうが良いな、と思いました。

失敗からわかったこと

失敗を通して、ログラスでQAをやることの意味、特徴、ログラスの特殊性について気が付きました。

  • お客様の最重要情報である「経営における計画、実績などの数値」を扱うので、高い品質が求められる

  • 複雑性が高い

    • 経営管理は型がないため、お客様によって使われ方(業務フロー)が全然違う

    • 使っているツールが違う

    • 様々な業務フローに対応するため、プロダクトの柔軟性が高い

    • プロダクトにアクセスする関係者が多く、権限などで複雑化しやすい

  • 簿記を始めとした専門知識を必要

そもそもの経営管理という営み自体の難易度が高いため、ログラスはプロダクトとしての難易度が高くなっています。そのため必然的にQAとしての難易度も高いのです。

ログラスにおけるQAの責務範囲


品質富士山

1年間の経験や失敗を通じて、ログラスのQAの責務を以下のように定義しました。私は品質富士山と呼んでいます。完全独自概念です。
縦は品質の種類、横はカバー範囲と捉え、この富士山に載っている事項は責務範囲と捉えて裾野を広げて富士山自体を高く・大きく・広くしていく活動をQAの活動としています。

もちろん1人でこれらすべてを行っていくのは無理なので、時によってフォーカスする部分を決めて取り組んでいます。

ここまで1人目QAがやってきたことや、これまでの失敗から学んだことを説明していきました。
これからQAがチームとして活動をしていくにあたり、今までの一年間の活動からわかったことを盛り込み、QAチームのミッション・ビジョンを以下のように策定しました。

ミッション・ビジョン・バリュー

Mission:開発者と一緒にプロダクトという山を登るシェルパとなる

私達は品質の門番となるのではなく、ともに歩くことでより良いプロダクトへ導きます。

Vision:急拡大する組織で、「良い開発文化」を強化/維持できるようになる

私達は、素晴らしいプロダクトは良い開発チームから生まれると信じています。
プロダクトの根源であるエンジニア組織に積極的に関与し、エンジニア文化を共に育てていきます。

Value:顧客志向、アウトカムファースト

私達は、QAは究極的にお客様のためにあると考えており、常にそこをスタートラインとします。
お客様にとって意味のあるQAを考え、顧客価値の最大化を追求します。

込めた想い

Mission

私達は開発者とともに歩みます。上にも書きましたが、開発チームとQAは全く別のライフサイクルで動き、バグを見つけ出荷可能かどうか判定するというやり方もありますが、それは採用しません。
また、リリース前のバグを見つけるテストをするというような門番的な役割もしません。将来への自戒を込めて、副文に「ともに歩く」という言葉を入れました。

Vision

ログラスはスタートアップなので、組織が急拡大し続けます。変化が激しい組織の中でQAを行っていく背景も汲んだVisionとしました。また、テストするだけではなく、品質を向上していくためであればなんでも行い、より良い組織を作るところにもコミットするという意思を込めています。

Value

個人的な反省として、細部に集中しているとついつい全体像やお客様への届けられる価値を見失いがちになってしまい、お客様のためにならないものをつい作ってしまっうことがありました。その経験を踏まえて、こちらも自戒を込めています。そして「お客様のためになること」って何??という部分、まだまだ深めていくことも多く、やるべきことが多い部分だと思ってます。

We Are Hiring!

いかがだったでしょうか。同じ志を持った方や、ピンときた方!是非カジュアルにお話させていただければと思います。

過去の記事と、QAの求人もよろしければ参考にしてください。よろしくお願いします!


この記事が気に入ったらサポートをしてみませんか?