製造業の生産技術の人がソフトウェア開発チームのQAになった話

はじめに

みなさんこんにちは。atama plus でQAをしている澤野井です。

atama plus Advent Calendar 202312日目です。
おでんと一緒にのんびり呑むビールが美味しい時期になってきました。

最初に私の経歴を書いておきます。

• 2018年、新卒でとあるメーカーに入社し、4年半、主力商品を製造する工場の生産技術スタッフとして勤務。それっぽい資格も持っております。
  • 品質管理検定（QC検定）2級
  • 危険物取扱者（甲種）
  • 公害防止管理者（水質3種）
  • etc…
• 2022年にatama plusに転職し、QAとして新たなキャリアをスタートし、現在2年目。

今日は「製造業の生産技術の人がソフトウェア開発チームのQAになった話」というタイトルで、異業種間の転職について私の経験と学びを記事にしたためました。

製造業勤務で、ソフトウェア開発に興味ある方、異業種からなんか学びないかなあと思っているQAの方、QA経験者の採用うまくいかんな～～という企業の方、そして、愛すべきatama plusの開発メンバーの皆様、目を通していただけますと幸いです！

構成は以下のようになっています。

1. 生産技術とQAの共通点と相違点
2. 実際どうだった？
   • 生産技術で得た知識・スキルはQAとして活かせているか
   • QAとして新たに必要なことにはどうキャッチアップしたか
3. 結びに

では、本文に入っていきましょう！

製造業に関する用語については、基本全てしっかり受かる!QC検定2級テキスト&問題集から引用しております。前職の社内用語等は一切ありません。
私の経験に基づく部分が多々あるため、すべての生産技術職およびQA職で当てはまるわけではありません。

生産技術とatama plus的QAの共通点と相違点

まず、そもそも異業種だとモノ作りのイメージがつきにくいと思うので、プロダクトがユーザーに届くまでのイメージ図を書いてみました。

メーカー

有形のモノを機械や人が加工→検査→後工程に出荷→…を繰り返し、最終製品としてユーザーに届けられます。検査の結果、問題ないものだけが後工程に出荷されます。似た図はそこかしこで見ると思いますが、製造業においてはいずれも有形のモノ（ハード）であることが特徴かなと思います。

atama plus

会社紹介スライドや以前弊社の河口さんが書かれた記事が参考になりそうなので、こちらをご参照ください。

デバイス上で操作される「無形」のモノ（ソフト）として、開発チームが機能を開発し、ユーザーに届けます。メーカーほど明確に「工程」などが区分されてはいません。

次に、業務内容を比較してみます。

共通点

ベースとなる考え方や責務などが共通点として当てはまります。

• 業務内容・責務
  • 「プロダクトの品質管理・向上」、「プロセスの改善」という広義では同じ。
  • 自工程・自チームの成果物に責任を持つ。
• 品質への考え方
  • 必要な検査・テストを小さく実施しながら、上流で品質を作りこんでいくということ。
  • 最後にどかっと検査すればいいってもんじゃない。製造業でもシフトレフトに似た考えを使っている、というイメージ。

相違点

対象とするプロダクト（ハードかソフトか）・プロセス（製造か開発か）の違いに起因するものが多くなっています。

• 生産技術の場合
  • 「製造プロセス」なので、「何を作るか」に対する不確実性が少ない。
  • 代用特性値などの品質管理基準は決まっていて、それを満たすものをいかにQCDの観点で効率的に作り、後工程に渡すか、を考える。
  • モノの手配や設備能力上の問題など、製造においてモノに関わる制約条件が多い。モノが無いと始まらない。
  • 品質規格が決まっている・製造設備に「理論上の能力」がある等の前提条件をベースに、ベストな状態とのギャップを数字で表現しやすい。
• QAの場合
  • 「開発プロセス」なので、「何を作るか」から不確実性が大きい。
  • 「ユーザーに取って品質が高い状態とは？」という検討から、仕様に落として、テスト・リリースまで関わる。
  • モノの手配等が必要なく、開発におけるハード的な制約条件は少ない。自由度が高いので、自分たち次第。
  • 前提条件の制約が少ないため、あるべきプロダクト・プロセスとのギャップを数字で表現しづらい。

もう少し具体的に、かつQCDSの観点でもまとめてみたので、お時間ある方はどうぞ。

	生産技術（メーカー）	QA（atama plus）
業務内容	・有形のモノとその製造プロセスに対し、QCDの管理・改善を行う ・自工程のOUTPUTに責任を持つ ・代用特性値などの品質管理基準は決まっていて、それを満たすものをいかにQCDの観点で効率的に作り、後工程に渡すか、を考える。	・無形のモノ（ソフトウェア）とその開発プロセスに対し、QCDの管理・改善を行う ・自チームで開発したものに責任を持つ ・「ユーザーに取って品質が高い状態とは？」という検討から、仕様に落として、テスト・リリースまで関わる。
Q 品質	・各品質特性を表現する代用特性が数字等様々な形で決まっている ・関連法規（PL法等）によっては厳格な品質基準が必要 ・工程ごとにできばえを検査・FBし品質を作りこんでいく	・要求品質を定義するところから検討 ・deliverまでの各段階でテストをしながら品質を作りこんでいく
C コスト	・原材料費・人工・ある商品を1個作るのにかかる費用（製造原価）など、お金で表現される。 ・売値と製造原価で、売上とコストの比較がしやすい	・機能の実装にかかる工数（期間など）などで表現される ・届けた価値が計測しづらく、売上と開発コストの比較がしづらい
D 納期 ※納品までの期間	・設備のMAX製造能力や稼働率を使って数字で表される ・設備の能力そのものを上げるには設備投資しかない。 ・なんでもいいから今すぐ作れ！ができない。モノが無いんだもの。	・ある機能や価値を検討し始めてからユーザーに届くまで、2,3週間～数か月。 ・「仕様として保証されている理論上の製造能力」が無い。自分たち次第で、いくらでも上へも下へも。 ・なんでもいいなら即時リリースできちゃうぐらい、モノの制約は無い。
おまけ：S	Safety。「ご安全に！」	Service・Scopeなど。

※一般的な製造業でも、「S」はServiceを兼ねることがあるようです。ただ、QC検定ではQCDの大前提としてSafetyが言及されていることから、この記事ではSafetyを採用しています。実際前職の工場でも最優先は安全だったこともあり、これを省略するわけにはいきませんでした。

実際どうだった？

なんとなく業務内容の違いがイメージできたでしょうか。

ここからは、実際異業種に転職してみて、前職で得た知識やスキルはどれぐらい活かせたか？新たに必要なことをどうキャッチアップしたか？という、私個人の振り返りを話していきます。

生産技術で得た知識・スキルでQAとして活かせていること

考え方・マインドセットは特に活かせていると思います。
先ほど共通点で挙げた「品質への考え方」以外にも、「後工程はお客様」、「三現主義（現場・現物・現実）」 等はベースとして活きているなと感じます。
「後工程はお客様」については、前職と違い、リリースしたら即お客様なので、前職よりさらに緊張感は上がりました。

また、スキルや経験面でいうと、前職のときに行っていた新しい商品・設備等の導入におけるスケジュール管理・リスクマネジメントも十分に活かせています。
「新商品、こういう特性があるから、この工程でリスク高いよね。だからここだけ早めに、この辺のスケジュール感で試験しておくか」 みたいな会話とか、
ソフトウェア開発でもなんとなく耳にしたことありますよね？

製造業もソフトウェア開発も、品質の考え方について元をたどれば同じところ（トヨタ）にたどり着くということがわかりますね。

ソフトウェア開発で新たに学ぶ必要があったこと・どうキャッチアップしたか

新たに学ぶ必要があったのは、大きく分けると以下の3つです。

• 用語（社内用語・一般的な技術用語）
• 開発対象（atama＋の特徴・仕様、システム構造など）　※atama＋は弊社のプロダクト名です。
• 開発プロセス（アジャイル開発ってなに、QAって何するの、自動化ってどういうこと・なにするの）

用語は、「サーバー」ってあの飲食店にあるビールサーバーのことですか？から始まってるぐらいなので、ベースの考え方以外はほぼ全部やないかいって感じですね。

ではどうキャッチアップしたか？atama plusのオンボーディングが充実していた、という面も多いにあると思いますが、自分なりに工夫していたことも含め、主にこれが大きかったかな？と思うことを書いてみました。
※ちなみに用語の理解は、開発対象やプロセスを理解することで自然と必要な理解が進んでいきました。

まず、開発対象の理解に対して。

• プロダクトを触る。
  • まず、ユーザーのつもりで。入社前も毎日触る時間を決めてやってました。
  • 次に、既存のテストケースに沿って。どの機能を重要視しているかがなんとなくわかります。
  • 触る中で、知らない仕様があったら、まず自分で推測してみる（リバースエンジニアリング的な）。
  • で、わからんことはとにかく調べる。聞く。atama plusは教育に熱心な方が多いので、丁寧に色々教えてくださいます。

つぎに、開発プロセスの理解に対して。

• めっちゃインプットする。
  • 素人なので、課題図書や社内のお勧め本がまず中心でした。
• 自分ごととして、実践する。で、わからんことは～～以下略。
  • 実際にQAとしてスクラムイベントに参加しつつ、自分ごととして、これはこの方が良いんじゃないか？ということはやってみる。
  • レトロ（振り返りの場）などを最大限活用して、できてること・できてないこと・不安なことを自己アピールし、周囲に伝える。
  • 自動テストは、当時QA組織で進めていた取り組みにそのまま参画させてもらい、あとは多少無理にでも手を動かすようにした。
    • 未経験でも書けるか？のモデルケース（もとい人柱）として、去年の今ぐらいの時期に書き始めました。1年経った今は、開発プロセスの中で一定の基準に沿ってしっかりテストを書いております。

まとめると、新しいことにキャッチアップするときはいつもですが、インプットとアウトプットを意識的に繰り返すことが重要だったかなと思います。
実際に開発に入っていくと、「ソフトウェアって、設備じゃなくて人が作ってるんだな～～」 感をとても感じましたね。

製造業で得た考え方・スキルのうち、まだ活かせていないこと

定量指標に基づいた改善活動はまだ実践しきれていないなあと思っています。

前職では、計測した指標に対し、課題を見つける→仮説を立てる→対策を打つ→効果検証するを繰り返して、QCDの向上を進めていました。

一方、現職に入社した当時の私は、「作るプロダクトの品質指標って決まってるもんじゃないんだ」とか、「プロセスの良し悪しってどう判断すればいいんだ、定性的にはなんとなくこっちの方が良さそうなんだけどわからん」など、「あるべきの指標」が明確には無いことに違和感を持ちつつ、なんとかキャッチアップを進めていた、という状況でした。
プロダクトとプロセスを理解していくにつれ、先ほど相違点の章でお話した通り、そもそも要求品質を定義するところからが「開発プロセス」であり、製造業と比べて「あるべき状態」を数値で表現するのは難しいということを学んでいきました。

そして直近、定量指標に基づいた改善活動を進められるよう、QA組織としても取り組みを進めています！これもいつか別で書けるといいかもですね。

結びに

広く「モノ作り」という観点で、生産技術とQAは、おそらく皆さんが思っているより、親和性が高いと思っています。

また、異なる部分として、「決められた品質指標のものをいかにばらつきなく作るか」という生産技術と違って、QAは、「ユーザーにとって品質が高い状態とはどんな状態か」から考えていく必要があるということも学びました。1→100の「製造」ではなく0→100の「開発～ユーザーへの価値提供」まで関われるやりがいがあります。
未経験でも目にとめてくださったatama plusのQA組織に感謝しまくりです。

また、年の瀬、改めて自分のオリジンを振り返り、それを活かした自分なりの価値を発揮しきれているのかを考える良い機会になりました。今後とも励んでいきたいと思います。

アドベントカレンダーはいいぞ。

明日はkiraさんの「Makefileを使った手順書レスな開発環境構築」です、明日もぜひご覧くださいー！