はじめに
こんにちは！ 株式会社BuySell Technologiesテクノロジー統括本部所属、26卒エンジニアの前土井です。
バイセルでは、毎年入社後にエンジニア研修を実施しています。バイセルのエンジニア研修は一般的な座学形式の研修ではなく、新卒エンジニアが実際に手を動かしてプロダクトを開発する実践的な研修プログラムとなっており、毎年異なった内容で実施されています。
本記事では、26卒のエンジニア研修の概要と、研修プログラムの中で学んだ現場理解の重要性、研修内の開発プロセスの変化を共有します。
- はじめに
- 26卒エンジニア研修の概要
- 現場の課題：ISマネージャー陣が毎月時間を取られていた勤怠チェック
- つまずき：「どう作るか」から考え始めてしまった
- 前提に立ち返り、業務を理解する
- 使ってもらいながら、改善のサイクルを回す
- 研修と実運用を通じた学び
- 配属後の実務で意識していること
- 最後に
26卒エンジニア研修の概要
26卒のエンジニア研修は、「問い」から始めるAI型の課題解決エンジニアリングをコンセプトに、以下の3つのミッションで構成されていました。
- 1stミッション: 振り返りAgent開発
- 自身が振り返りをするためのAIエージェントを開発する
- 2ndミッション: プロダクト開発研修
- チームで現場の課題を解決する
- 3rdミッション: BuySell未来サービス開発
- バイセルの事業に沿った未来のサービスを考えて開発する
どれも充実した学びのある研修でしたが、この記事では私の中で最も印象に残っている「2ndミッション: プロダクト開発研修」を紹介します。
プロダクト開発研修は、「現場の一次情報から課題を発見・解決し、事業部に貢献する」ことを目的とした研修です。新卒エンジニア3人1組のチームで担当の事業部を受け持ち、課題の特定から開発、運用、検証までを5日間で行います。
5日間の日程は、1日目の夕方に経過報告会、2日目に現場エンジニアの方からのサポートタイム、最終日に成果発表がありましたが、それ以外の時間の使い方は各チームの裁量に任されていました。また、課題解決の手段も、Webアプリ、GAS、Slackワークフローなどの制限はなく、各チームに委ねられていました。
私たちのチームは、インサイドセールス（以下、IS）の業務の課題解決に取り組みました。
現場の課題：ISマネージャー陣が毎月時間を取られていた勤怠チェック
私たちのチーム担当であるISのマネージャーにヒアリングを行ったところ、毎月末の勤怠チェックに時間を取られていることが課題であるとわかりました。
具体的には、バイセルでは社内全体で勤怠管理SaaSを導入しているものの、ISでは勤務形態やチェック項目が複雑であり、別途確認用のスプレッドシートを用意して手作業でチェック作業を行っているとのことでした。
結果的に、マネージャー18人がそれぞれ月に1時間ほどチェック作業に費やしており、さらに目視＋手作業でのチェックが主体のため抜け漏れの懸念もあり、特に気を遣う作業となっていました。
そこで、私たちのチームはISの月末勤怠チェックをこれまでよりも素早く確実に行えるようにすることを目標として研修に取り組みました。
つまずき：「どう作るか」から考え始めてしまった
課題を把握した私たちが最初に取りかかったのは、「どのような手段で勤怠チェックを自動化するか」の検討でした。勤怠管理SaaSのWeb拡張機能を開発する案や、新たなWebアプリを開発する案、GoogleスプレッドシートとGASでシステムを構築する案などを比較しました。私たちは、実装・運用コストなどを踏まえ、スプレッドシートとGASを用いた開発に決めました。
手段が定まり、開発に着手しましたが、ここからがなかなか進みませんでした。最初は手作業のフローをそのまま自動化すれば良いと考えていたのですが、その手作業でのフローの全体像を掴めておらず、また、自動化することで勤怠チェック作業がどのように変化するのかの想像もできていませんでした。
結局、研修1日目は現場の理解が曖昧なまま過ぎていきました。経過報告会では、他チームが動くPoCを作成していた中、自分たちのチームはシステムの構想を発表するにとどまりました。
その後、PoCを作成して現場のマネージャーに見てもらいましたが、業務フローや要件の整理不足によって細かい処理が未実装で、導入後の作業イメージのすり合わせまでには至りませんでした。
前提に立ち返り、業務を理解する
そんな中、2日目の現場エンジニアの方からのサポートタイムを迎えました。先輩社員に相談したところ、「そもそも勤怠チェックの業務フローや勤怠管理SaaSの設定を見直すことで、新たにシステムを開発しなくても今回の課題を解決できるのではないか？」「前提から立ち返って考えてみては？」というアドバイスをいただきました。
ここに来て私たちは、「なぜマネージャーは月末に勤怠チェックを行っているのか」「何を確認できたら勤怠チェックができたと言えるのか」が曖昧なまま、システムを作ることばかり考えていたことに気づきました。
そこで、現場のマネージャーの方と改めてMTGを行い、実際の作業フローを目の前で見せてもらいました。その後、チーム内で作業フローの整理、現場でも明文化されていなかった作業項目の言語化を行い、勤怠チェックの要件を洗い出しました。
整理した結果、既存の作業フローを変えたり勤怠管理SaaSの設定を見直すだけでは今回の課題解決は難しいことが分かり、新たなシステムの開発が必要であるという結論に至りました。開発する内容は、勤怠管理SaaSが提供しているAPIで勤怠の転記作業を自動化し、勤怠データから管理者が確認したい項目を自動的に洗い出すという方針になり、実現すると日次の勤怠チェックまで簡素化できると判明しました。また、研修1日目に決定したスプレッドシートをベースとする実装方法の選択にも、ISの方が使い慣れており導入ハードルを下げられる、という現場理解に基づく確信を持てるようになりました。
方針が定まってからの開発は、AIを活用することでスピード感を持って進めることができました。振り返ると、要件が曖昧だった序盤は、AIを使っても何を作らせればよいかを指示できない状態でした。実装自体はAIで高速化できるからこそ、その前段である現場理解こそが今回の開発のボトルネックだったのだと実感しました。
使ってもらいながら、改善のサイクルを回す
最終的に、5日間の研修期間内で、実際に使ってもらえる一歩手前の段階までシステムを作り上げることができました。研修終了後も細かい修正や開発を続け、月末の勤怠チェックのタイミングで、ISの4グループのうち1グループに試用してもらいました。実際に使っていただいたマネージャーからは、「目視の漏れが減り、月末の勤怠締めに対する安心感が出た」「システムを今後本格的に導入することで確実に勤怠チェックの工数削減が見込めそう」といった声をいただきました。
一方で、使ってもらって初めて、考慮できていなかった仕様に気づいたり、現場からバグの報告をいただいたりしました。要件を丁寧に整理したつもりでも、実際の運用の中でしか見つからない課題があるとわかりました。そこで、修正を重ねると同時に、事業部の方とスムーズに連携できるよう専用のSlackチャンネルを整備し、質問や不具合の報告をその場で受け取れる体制を整えました。
翌月、4グループに拡大して使ってもらうと、今度は機能ではなく運用そのものに課題が見つかりました。グループごと・月ごとにスプレッドシートを複製する運用が複雑で、運用ミスの温床になりかねなかったのです。そこで、Slackチャンネルで受け取ったフィードバックに対応しながら、月ごとのシート運用の見直し、UI/UXの改善、コードのリファクタリングを進めました。
このように、フィードバックと改善のサイクルを繰り返した結果、導入から4ヶ月ほど経った現在では、ISの4グループ全体で安定して使ってもらえる状態になりました。
研修と実運用を通じた学び
今回の新卒研修を通して、現場の課題を解決するにはチーム全体で現場のドメイン知識を理解し、開発と改善のサイクルを繰り返すことが重要であるということを学びました。
特に大きな学びは、次の2つです。
1つ目は、着手前に現場を理解することです。振り返ると、研修初日の私たちの進め方は課題を聞く → 手段を決める → 実装するというもので、現場の理解を深めるフェーズが欠けていました。先輩社員のフィードバックを受けて、一度前提に立ち返り、実装前に業務を観察して言語化する → 作らない案も含めて手段を決めるというフェーズを挟んだことで、ようやくISの方と同じ目線ですり合わせを進められるようになりました。実装はAIで高速化できるからこそ、「なぜこの業務を行っているのか」「普段どのように業務を行なっているのか」「何が課題なのか」という問いに答えられるだけの現場理解が欠かせないのだと実感しました。
2つ目は、リリース後もフィードバックと改善のサイクルを回し続けることです。開発して終わりではなく、実際に使ってもらって初めて見える課題は多くありました。フィードバックが届く場を整え、改善を繰り返すことで、システムは現場に定着していくのだとわかりました。
配属後の実務で意識していること
この2つの学びは、配属後の実務でもそのまま活きています。
1つ目の学びから、細かい要件を整理する際はまず、事業部の方が今どのような運用をしていて、どのような課題があるのかを聞くようにしています。特に、私が開発に携わっているシステムは複数の部署の方が使用している部分があり、その場合はそれぞれの部署でどのような課題を抱えているのかをヒアリングすることを意識しています。
2つ目の学びから、実務ではフィードバックをより早い段階から得て、改善サイクルをより多く回すことを意識しています。たとえばフロントエンドの変更では、先にUIだけを簡易実装して共有し、導入後の作業がどう変わるかを早い段階ですり合わせるようにしています。その結果、認識のずれが少ない状態で実装を進められています。リリースした際には、事業部の方がスタンプやコメントで感謝を伝えてくださるので、とても嬉しいです。
もちろん、実務ではまだ課題も多くあります。最終的な意思決定が遅れたり、要件が膨らみ過ぎたり、考慮できていなかった点が後から出てきたりすることもあります。今後も事業部の業務理解を深め、リリースまでのサイクルを速めることで、チームや事業部の方に貢献していきたいです。
最後に
今回の研修では、チームで壁にぶつかり、なかなか前に進めない時間も多くありました。しかし、メンターや先輩社員の方々に相談した際、快くアドバイスをしてくださったおかげで、前に進むことができました。改めて感謝申し上げます。
今後も、研修で学んだことを実務で活かして業務を進めていきます。
去年の研修の記事も公開されています！ ぜひこちらからご覧ください。
バイセルでは、一緒に働くエンジニアを募集しています。興味がある方は、以下よりご応募ください。
