🔖

知識不足に「ゲンナリ」したとき、私が「But We Go」の精神で決めた3つのこと

に公開

こんにちは。およそ半年ほど前に、ログラスにQAとして入社したテラです。

アドベントカレンダーの記事、何を書こうか悩みました。
実はここ最近ずっと、自分の知識不足にゲンナリすることが続いていて、華やかな技術記事なんて書ける気がしなかったのです。

ですが、そのモヤモヤこそ、今の私が一番伝えたいことだと気づきました。この記事は、知識の奔流に打ちのめされながらも、前に進もうともがく私の正直な思考ログだと思って読んでいただけると嬉しいです。


QAの壁:テスト実行から設計議論へ、私は何が足りていなかったのか

前職では、私は主に「テスト設計と実行」のプロフェッショナルとして働いてきました。

仕様書とテストケースを突き合わせ、リリース前の品質を担保する日々。ルールやシステムの「抜け穴」や「考慮漏れ」を見つける作業は、筋金入りのゲーム好きな私にとって、まるでゲームのようで天職だと感じていました。

しかし、頭では分かっていたことですが、ログラスのQAとして求められる役割は、それだけではありません。
開発サイクルのかなり早い段階、「設計」や「要件定義」の議論にまで踏み込み、潜在的な課題を未然に防ぐことが強く求められます。
https://note.com/k_kotatsu1992/n/n8fbdec5d5043

この環境に身を置いて、私は痛感しました。

「仕様書に書いていない『意図』や、設計者の『前提』に対して、自分はまともに指摘できていない」と。

私は何も分からないまま、雰囲気でQAをやっていたと言っても過言ではないと。

私の持つ視野や嗅覚は、目の前のコードや仕様の「バグ」を見つけるためには役立っても、その上流にある「設計思想の欠陥」や「プロセス上のボトルネック」を見抜くには、あまりに射程が短すぎたのです。

趣味での失敗と、プロの視野:私を打ちのめした「設計者の思い込み」

そういった課題感に苛まれる中、プライベートでちょっとした失敗を犯しました。自己研鑽の一環としてゲーム開発の仕様設計を経験させてもらったのですが、そこで「設計思想の欠陥」とも言えるミスをしてしまったのです。その経験が、私により決定的な教訓を与えてくれました。

そのゲームは、コントローラーでのステージエディット機能を実現しようとしていました。そこでの私の設計時の「思い込み」はこうです。

「操作に使用するボタンの数は少ない方が、洗練されていて美しい。その方が最終的には高速で操作できるようになるはずだ」

この思想に基づき、私は「ボタンの同時押し」や「特定のボタンを押しながら入力」などでの操作を採用しました。

  • 「L+Rでテストプレイ開始」
  • 「Lを押しながらスティック操作でアイテム選択」
  • 「Rを押しながら上下でアンドゥ/リドゥ」

ユーザーは操作に慣れるほど、爆速コントロールが可能になっていく。そんな体験を目指したのです。

はたして結果はどうだったでしょう。実装後、周りの方に触ってもらって明らかになったのは、慣れるどころか、操作を覚える最初の段階で戸惑い、投げ出してしまうという現実でした。私が追求した「習熟後の高速操作」というメリットは、初期の「高い学習コスト」という致命的な欠陥によって、完全に打ち消されていたのです。

これは単なる「バグ」ではありません。設計者が「ユーザー初期体験の軽視」という、大きな判断ミスを犯した結果でした。

知識の多さに「ゲンナリ」した日:プロとして学ぶべきことの巨大さ

自分がQAとして見ていた視野が、いかに狭かったか。

これまでの私は、

  • 「仕様目線」:仕様書に書いてある通りに動いているか?
  • 「技術者目線」:コードの処理にエラーはないか?
  • 「設計意図目線」:仕様書に設計者の意図や前提が正しく反映されているか?

というフィルターを通してしか、プロダクトを見ていなかったのです。

しかし、本当に必要なのは、 「ユーザーが実際にその機能に初めて触れたとき、設計者の意図通りに迷わず使えるか?」 という、ユーザー体験全体を俯瞰する視点でした。

私はこの失敗を通じて、「使うボタンは少なければ少ない方がいい」という自分の思い込みに気づくことすらできなかった、という現実を突きつけられました。
そして、この気づきをきっかけに、私は設計の上流を見るために必要な知識のインプットを始めました。

しかし、目の前に広がったのは、あまりにも巨大な知識の奔流でした。正直に言って、今の私を最も打ちのめしているのは、個別の知識ではありません。 問題は、プロとして議論の土台になるべき「概念そのものが世の中に存在していること」を、私はそこまで深く知らずにいたという点です。

  • 複雑な B2B SaaS のドメイン知識
  • 効果的なUX/UIデザインの原則
  • システムアーキテクチャの基本的なパターンという概念
  • アジャイル開発における最適なプロセス設計

正直に言って、これらの膨大な概念と知識を前に、私はだいぶ「ゲンナリ」しています。会議で専門用語が飛び交うたびに思考が止まる事なんてざらですし、そのたびに「自分は本当にログラスの品質を支えられるのか」と自問自答してしまいます。

新しい知識を学ぶこと自体に抵抗はありませんが、その「学ぶべきことの多さと深さ」に圧倒され、自分の立ち位置を見失いそうになる日が続きました。

「ゲンナリ」しても、前に進む:ログラスを支えるバリューと覚悟

私の「ゲンナリ」という感情は、裏を返せば、自分が成長できる余地がまだまだいくらでもあるということでもあります。

知識不足で、会議中に頭が真っ白になる日もある。正直、ログラスの品質を担うプロとして「カッコ悪い」自分から逃げたい気持ちもあります。そんな自分を自覚するたび、これもまたいちいちゲンナリします。

でも、立ち止まって「ゲンナリ」している時間こそ、一番無駄です。ログラスには「But We Go」というバリューがあります。困難があっても、それでも前に進もうとする覚悟を賞賛する、というものです。

思い返してみれば、私はいつも「何も分からない」から始めてきました。音大へ行こうと決めて、入試の3週間前から習い始めたピアノ。電源の入れ方も分かっていないところから始めた、PC専門店の店員。Excelも使えないのに始めた、テスト技術者としてのキャリア。

全て私です。覚悟を決めて、泥臭く前に進むしかありません。

  1. 「わからない」を隠さない: 理解できない概念や用語があれば、その場ですぐに聞く。議論の場を学びの場に変えます。
  2. 「ユーザーの初期体験」の代弁者となる: 「初めて触るユーザーにとって、本当に分かりやすいか?」を、設計レビューの中心に据えます。
  3. 知識不足を今日から埋める: 書籍やドキュメントを読み込み、設計者の意図や背景を理解する努力を続けます。

「知識の奔流」に流されるのではなく、それを自らの成長の原動力に変える。それこそが、今の私にできる最大の貢献であり、ログラスの品質と真剣に向き合う覚悟です。

そして、ログラスでは「わからない」と言ったとき、誰も笑わない。むしろ、一緒に考えてくれる。そんな文化があるからこそ、私は安心して「何も分からない」から始められる。この環境に、心から感謝しています。

おわりに

この記事を読んでくださった皆様の中にも、新しい分野に挑戦し、自分の知識の限界に直面している方がいるかもしれません。

知識の多さに打ちのめされ「ゲンナリ」するのは、誰しも当然の反応だと思います。しかし、その感情を「諦め」ではなく「燃料」に変えられるかどうかが、きっとプロフェッショナルとの分水嶺なのでしょう。

私は、プロフェッショナルでありたい。

今後ともよろしくお願いいたします。

株式会社ログラス テックブログ

Discussion