この記事は、CYBOZU SUMMER BLOG FES ’25 の記事です。
こんにちは！サイボウズでQAエンジニアをしている tagashira です！
kintone システム管理/外部連携チームの機能開発のQAを担当しています。
「ソフトウェアの品質と開発生産性を向上させるために、QAには何ができるだろうか？」を模索する日々です。
この記事では、普段QAエンジニア（以下QA）をしている私が、ソフトウェアエンジニア（以下SWE）の業務体験をさせていただいた話について書こうと思います。
SWEの業務体験を考えるようになったきっかけ
コンフォートゾーン
私が所属するシステム管理/外部連携チームでは、SWE5名・QA2名の計7名で開発を手がけています。
私の周りにはフロントエンド・バックエンド・QA等の各領域に対して造詣の深いメンバーが集まっていて、それぞれ専門性を活かしつつ積極的にコミュニケーションを取り、円滑にチームで開発ができている実感がありました。
そんなメンバー達に手厚くサポートしてもらいながら、自分はQA3年目に突入し、業務にほんの少しではありますが慣れてきた感覚がありました。一方で、自分にとって新しい知識・スキルを習得するための挑戦はあまり出来ておらず、いわゆるコンフォートゾーンに入っている実感がありました。
この現状から脱却してさらに成長するために、これからどのようなことに取り組んでいくとよさそうか、今後のQAとしてのキャリアの方向性を探っていました。
先輩QAが声をかけてくれた
QA同士で集まってテストの相談を行う会を週2回設けているのですが、そこでいつも通り先輩QAとお話していたある時のことです。
今後の業務やキャリアについて壁打ち的に相談させていただいていたところ、「現状、チーム状況的にも余裕がある状態なので、このタイミングでSWEの体験に行ってみて、これまで担当したことのない領域の知見を深めてみるのはどうですか？」とお話がありました。
実はその先輩QAの方も、今の自分と同じQA3年目のタイミングでSWEの体験を始められており、これまでのご自身の経験と、私のキャリアの志向を踏まえてご提案いただいた次第でした。
この提案を受けて、正直はじめは「いくら体験とはいえ、果たして自分に何か出来ることはあるのか？」という考えが頭をよぎりました。
しかし、スキルセット観点では、テスト改善のプロジェクト*1で普段から自動テストを実装していたことでコードベースにアクセスするハードルが下がっていたことや、「失敗するなら早い方がよい」という考えも後押しし、チャレンジしてみようという気持ちになりました。
業務体験の検討から受け入れまで
どうやって始める？そもそも始められるのか？
当然のことですが、業務体験の受け入れには相応のコストがかかるため、まず受け入れ側の状況を確認する必要がありました。そこでまずは、所属チームのEM（Engineering Manager）に相談を持ちかけました。
幸いなことに、チームのリソースが逼迫している状態ではなかったこともあり、チームの中でSWEの体験をさせていただける運びになりました。
体験の進め方
体験内容としては、QAとして日々の業務を行ったり、後述するkintone SWE向けのオンボーディングコンテンツに取り組んだりしつつ、比較的複雑度が低く着手しやすそうなタスクが来たタイミングで、開発業務に参加してみる形で進めていくことになりました。
期間としては、ざっくり1~2ヶ月と定めました。これは着手しやすそうなタスクがどのタイミングで来るのかの予測が難しいため、ミニマムで1ヶ月とし、+αである程度幅を持たせた期間としました。
kintone開発のオンボーディングコンテンツって？
kintoneでは様々なSWE向けのオンボーディングコンテンツが用意されています。
今回は「Modern Frontend Training」というコンテンツで、kintoneにReactで1から画面を作る方法や、フロントエンド開発に関わるバックエンドの知識等を学ぶことができました。
詳しくはオンボーディングコンテンツを作成いただいた弊社メンバーの記事をぜひご参照ください。
blog.cybozu.io
職能の垣根を超えるには
今回の業務体験を通して、自分の中で深掘ってみたいテーマがありました。それは「今後QAがSWEと同様に実装にも関わりつつ、ソフトウェアテストの専門性を活かしてプロダクトの成長に貢献するロールだと定義された場合に、QAとしてチームにどのような関わり方ができるだろうか？」というものです。
現状のSWE/QAの関わり方
まずは前提として、私の所属するチームの現状のSWE/QAの関わり方について説明させてください。
（ざっくりとした開発の流れになるので、一部省略している部分がありますがご容赦ください。）
- リファインメント：PdM/SWE/QA
- プランニング：SWE/QA
- 仕様書修正：SWE/QA
- 回帰試験設計：SWE/QA
- 機能実装（単体テスト実装も含む）：SWE
- 機能試験設計：QA
- 回帰試験実装：SWE
- 受け入れ確認：PdM
- 機能試験実施：QA
- 機能試験結果確認：SWE/QA
- マージ：SWE
仮に上述の通りロールが再定義されるとした場合、上記の流れの中でQAとしては、現状SWEだけに担当していただいている「機能実装」と「回帰試験実装」についても、知識と経験を身につけていけるとよさそうです。
現状の機能実装・回帰試験実装の進め方
私の所属するチームでは、基本的にはソロプログラミング（以下ソロプロ）で実装を進めつつ、影響範囲が広い等の理由で複数のメンバーで相談しつつ進めたい場合にはモブプログラミング（以下モブプロ）で機能実装を進めています。
また、機能追加の度に自動化された回帰試験を追加しており、SWE/QAで回帰試験で担保したい観点や適切な実装レイヤーについて相談したうえで、QAがテストケースの起票を行い、SWEが実装を進めるという分業体制になっています。
業務体験での機能実装・回帰試験実装の進め方
そこで今回の業務体験では、以下のタスクの進め方を体験で行いたいと考えました。
-
Case1: ソロプロで機能実装を行う
-
Case2: モブプロで機能実装を行う
-
Case3: SWEが機能実装を、QAが回帰試験実装を行う
いざ！業務体験へ！
Case1: ソロプロで機能実装を行う
kintoneには、Excel/CSVファイルを読み込んで、業務アプリを作成する機能があります。Excel/CSVファイルを読み込む際の処理方式について、これまではファイル読み込み中にエラーを発生させるファイルの行が1行でもあった場合に読み込みが実行できない従来の読み込み方式を利用する形になっていたため、フロントエンド基盤の刷新後の新しい画面で、エラーを発生させる行があった場合にそれらの行をスキップして読み込みを継続できる新しい読み込み方式を利用する形に修正する実装タスクをソロプロで担当させていただきました。
ソロプロでの実装を行うことになった理由は以下の通りです。
ファイル読み込みの機能の仕様の考慮が十分でなかった点があり、受け入れ確認のタイミングで追加で検討事項が発生したのですが、チームメンバーの手厚いフォローのおかげでタスクを完了まで持っていくことができました。ソロプロでは何か詰まったときに一人で悩む時間が多かったですが、そこで苦しんだ末に解決した経験が成長への近道になるのかもしれないと感じました。
Case2: モブプロで機能実装を行う
kintoneには、作成済みのアプリにExcel/CSVファイルからデータを読み込んで、新しいレコードの追加や、登録済みのレコードへの更新ができる機能があります。この機能を提供する画面で利用する、独自のコンポーネントの実装タスクをモブプロで担当させていただきました。
モブプロでは、基本的に自分がドライバーを担当し、2名のSWEにナビゲータを務めていただきました。
これまで自動テストの実装など、実装は全てソロプロで行ってきたので、モブプロでの開発は自分にとってとても新鮮なものでした。
実際にやってみて、以下のようなメリットがあると感じました。
-
SWEがどのようなことを考えながら実装していくのか、思考過程がわかる
-
実装していく中で仕様について悩んだときに、その場ですぐに相談できる
-
ショートカットや開発環境周りのトラブルシューティングなどのTipsをたくさん知れる
Case3: SWEが機能実装を、QAが回帰試験実装を行う
SWEが他のタスクで少し手が空いていないところでちょうど自分が手が空いていたタイミングがあり、バックエンドの回帰試験の実装を担当させていただきました。
現状回帰試験の設計についてはSWE/QA共同で行い、実装についてはSWEにお願いする形で進めていましたが、QAが回帰試験実装を行う経験を通じて、状況に応じてQAが実装を行いSWEにレビュワーとして入っていただくような進め方もできるということが実感できました。
一方で、テストを実装する上では当然ですがテスト対象のプロダクトコードを把握しておく必要があるため、プロダクトコードの実装を担当したSWE自身がテスト実装まで行う方がコードのキャッチアップの部分をショートカットでき、速度の観点では現在の分業体制の方がスムーズであるといえるかもしれません。このあたりの進め方についてはチームで相談して、最適解を探っていきたいと思いました。
体験を通じて伝えたいこと
初めてSWEの業務体験を行ってみて、これからSWEの業務体験を行ってみたいと考える方・業務体験を受け入れる方向けに以下のことをお伝えしたいです。あくまで一例として参考になれば幸いです。
まずはモブプロのドライバーをやってみる
これから初めてSWEの体験をされる方にとっては、当然ではありますが開発業務の進め方の「型」が存在しません。
そこでまずは、モブプロでドライバーを担当して、ナビゲータの方に先導していただきながら、SWEの思考過程をトレースするイメージで実装を始めてみるのが入り方としてはよさそうです。
モブで作業することによって、途中で詰まってしまい時間をかけても中々解決できずにタスクを抱えてしまう、ということがないので、初学者の精神衛生的な面でもハードルが低いと思います。
そして、モブプロで身につけた型をベースにして、ソロプロに挑戦してみて、そこで一人で悩む過程の中で成長していくというのが、自分としては理想的なSWEの業務体験の登り方になりそうと感じました。
チーム内で「ゆるく」始めてみる
「SWEの業務体験に行ってみたいけど、現状抱えている業務を体験のために一定期間手放すのも中々難しい…」という方も多いのではないでしょうか。
そこで、もし所属している開発チームの状況的に余力があればの話になってしまうのですが、チーム内で「ゆるく」業務体験を始めてみるのをおすすめしたいです。
ここでいう「ゆるく」体験を始めるとは、「業務体験に稼働時間の100%を割かない」ということを指しています。
仮に稼働の100%を業務体験に回す場合、以下の対応が必要になります。
-
体験する側は、現状抱えている業務をすべて他のメンバーに委託する必要がある
-
受け入れ側は、業務体験中に体験する方の時間が空かないように調整する必要がある
もちろん、双方の準備が整っていれば、業務体験にフルコミットすることで体験期間の学びを最大化できるはずです。
しかし、体験のハードルが上がってしまって踏み出せなかったり、体験側・受け入れ側ともに負担が大きく業務体験が持続可能でないことによる機会損失もあるはずです。そこで「ゆるく」始めることも一つの選択肢として持っておくとよさそうと思いました。
おわりに
今回はQAが実際にSWEの業務体験をやってみた話についてご紹介しました。
正直なところ、1ヶ月業務体験を行っただけでは、SWEの仕事の難しさの一端を垣間見ることしかできなかったと感じました。今後も状況を見ながら、よりステップアップした内容の業務体験に挑戦できればと考えております。
読んでいただいたみなさんにとって何か少しでも参考になる箇所があれば幸いです。
次回の CYBOZU SUMMER BLOG FES ’25 の記事もお楽しみに！
コメント