学校が嫌いだった。ファイナルファンタジーが好きで、将来やりたいことは特になかった。高校3年生のとき、友人に「自衛隊の試験を受けようぜ」と誘われ、進路も決まっていなかったので軽い気持ちで受けた。試験には受かった。
担任に報告すると、意外な言葉が返ってきた。
「え？ 小野さんって卒業する気あったの？」
どうやら単位が足りなかったらしい。冬休みはなくなったが、なんとか卒業して自衛隊に入った。あれからずいぶん遠回りをしてきた。自衛隊、建築、営業、現場管理、テクニカルサポート、IT、品質保証。振り返ってみると、僕の仕事はいつも「作ること」と「確かめること」の間にあった。
小野礁洋。BEETLE合同会社の代表で、48歳のQAエンジニアだ。ここまでの遠回りを、少しだけ聞いてほしい。
自衛隊から、建築の営業へ
自衛隊では任期制隊員として勤務した。正社員への昇任試験は約50人に1人、しかも年に2回しかなかった。6年目、次の更新では正社員になれると言われていたが、それでも辞めた。試験前になると自主外出禁止になり、先の見えない生活に疲れていたのだと思う。
退職後は建築会社の営業になった。初めて取った契約は、先輩がお客様の前でひと芝居打ってくれて取れたものだった。契約はうれしかったが、自分の力で取った感じがしなかった。外面がよかったのか、その後は営業としてそれなりに仕事ができた。入札でよく顔を合わせる会社から声をかけられて転職し、そこで約5年、営業と現場管理を経験した。
1万円のパソコンから、ものづくりが始まった
建築会社で働いていたころ、姉の夫が「1万円くらいでパソコンを作れるよ」と言った。驚いた。パソコンは買うものだと思っていたからだ。自分で作れるということを、そのとき初めて知った。
もともと、ものづくりは好きだった。パソコンを組み立て、CADを覚え、小さなリフォームの図面を描くようになった。営業で仕事が取れることよりも、自分で引いた図面にお金が発生することのほうがうれしかった。自分の手で何かを作り、それが仕事になる。そこに初めてロマンを感じた。
35歳で、プログラマーコースに入った
勤めていた建築会社の経営が傾き始め、給与を取りっぱぐれる前にと早めに退職した。次に就いたのはパソコン系のテクニカルサポートだったが、そのころには電話の問い合わせ自体が減り始めていた。このままではまずいと思い、市の就職セミナーに応募したら、割り当てられたのはプログラマーコースだった。35歳だった。
新しいことを覚えられる自信はなかった。自分の人生そのものを、同じ場所を回り続けるFORループのように感じていた。それでも、営業で培った面接だけは得意だった。なんとかIT会社でのOJTが決まり、そこで現場管理の経験が役に立った。コードを書く技術では若い人にかなわない。でも、作業を整理し、人をまとめ、問題を見つけることはできた。契約社員から正社員になり、38歳でグループリーダーになった。
作る人にはなれなかった。でも、確かめる人にはなれた
35歳からプログラマーとして第一線を目指すのは簡単ではなく、自分でシステムを作る道はいったん諦めた。その代わり、別の強みが見つかった。画面を見ると、使いにくい場所が気になる。操作すると、想定されていない動きが気になる。仕様書どおりに作られていても、それで利用者が困るなら納得できない。
それでも現場では、こう言われることがある。
「仕様書には書いていません」
僕はこの言葉が苦手だった。仕様書に書かれていないことと、利用者が困らないことは別の話だ。自分はプログラマーよりも、作られたものを疑い、確かめる仕事に向いている。そう気づいてから、品質保証の仕事が面白くなった。
ITにも、土木工事のような働き方があった
ITの現場では、開発が遅れている間、検証担当者は待たされる。何週間も待ったあとに完成した画面が一気に渡され、納期直前に徹夜で確認する。待って、待って、最後に人を大量投入する。建築現場で見た光景とよく似ていて、僕は勝手に「IT土木」と呼んでいた。
問題が起きることを前提に、最後に人の体力で帳尻を合わせる。これでは、作る人も確かめる人も疲弊する。もっと早い段階から品質について考えられないだろうか。仕様書が完成していなくても、画面を見ながら一緒に考えられないだろうか。そう考えて独立した。ちょうどそのころ、開発現場で一緒だった会社から仕事をいただいた。本当にありがたい話だった。
BEETLEがやっていること
BEETLE合同会社では、大きく分けて二つのことをやっている。
ひとつはQA支援。Webシステムやアプリの品質を確かめる仕事で、テスト項目書の作成、テストの実施、バグの調査と起票を行っている。ただ、仕様書に書かれた項目を確認するだけではない。実際に使う人が迷わないか。別の操作をしたときに壊れないか。ひとつ直したことで、ほかの機能に影響していないか。「作った側の正しさ」だけでなく、「使う側の困りごと」からシステムを見る。仕様書やテストケースが十分にそろっていないスタートアップや小規模な開発チームの支援を得意としていて、きれいな資料が完成するまで品質保証を待つ必要はないと思っている。
もうひとつは、学校や家庭で使える小さなツールを作ること。漢字にふりがなをふる「ルビメーカー」、学級だよりを作る「学級通信メーカー」、子どもに英単語の発音を聞かれた親を助ける発音アプリ。どれも始まりは、家庭の中にある小さな困りごとだった。「この漢字、なんてよむの？」「この英語、どう発音するの？」。ひとつひとつは大きな社会課題ではないかもしれないが、毎日の中で何度も発生する。そうした小さな面倒を少しだけ軽くするのも、ものづくりの役割だと思っている。
AIが、もう一度ものづくりをさせてくれた
一度は、自分で作ることを諦めた。ところが生成AIが登場して、コードを書けなくても、対話しながらアプリを形にできるようになった。上に書いたツールも、全部AIと一緒に作ったものだ。
もちろん、AIが作ったものはそのままでは信用できない。画面は動いていても、裏ではデータを消しているかもしれない。入力チェックが、見える場所にしか実装されていないかもしれない。修正した機能とは別の場所が、壊れているかもしれない。実際、僕は何度もやられている。だから、AI時代にはQAが必要になる。作れる人が増えたからこそ、確かめられる人が必要になる。
僕にとってAIは、仕事を奪う存在ではなかった。35歳で諦めたものづくりを、もう一度始めさせてくれた相棒だった。
48歳で、noteをはじめた
いまは毎日、noteに記事を書いている。AIにコードを書かせて、QAの目で確かめて、そこで起きたことを記事にする。「今日もAIがコードを書いたのでQAを始めます」という連載で、AIがやらかした話と、現場で見てきたバグの話を出している。相棒のClaude Codeを「クロードさん」と呼んで、その付き合い方のシリーズまで書き始めた。
48でnoteをはじめるのは、遅いのかもしれない。でも、35歳でプログラマーコースに入ったときも同じことを思っていた。遅いかどうかは、あとにならないと分からない。
どこにロマンを持つか
自衛隊にも、営業にも、建築にも、ITにも、それぞれの面白さがあった。でも、僕が一番長く追いかけてきたのは、ものづくりだった。パソコンを組み立てる。CADで図面を引く。システムを確かめる。AIとコードを書く。誰かの困りごとを、小さなツールに変える。
ものづくりは、完成したものだけを指すのではないと思う。壊れていないか確かめること。使う人が困らない形に整えること。必要な人へ届けること。そこまで含めて、ものづくりだ。
ようはあれだ。
どこにロマンを持つか。
あなたのロマンは、どこにありますか。