「分からない」を一人で抱えない。若手4人がチームで築いた、成長の1年間〜①〜

ビジネスホテル向け自動精算機「ADX-MarkⅠ」の品質を入社1年目から支えた、若手エンジニア4人の座談会

ホテルを訪れたお客様が、スタッフのサポートを介さず、チェックインから精算までをスムーズに行う。そんな宿泊体験を支えているのが、USEN-ALMEXの自動精算機です。

今回話を聞いたのは、現在入社2年目の今回話を聞いたのは、現在入社2年目の十河(そごう) 雅樹(まさき)さん、陳(ちぇん) 柏翰(ぼはん)さん、洪(ほん) 毓蓮(ゆーりぃぇん)さん、楊(やん) 宇翔(ゆしあん)さん。4人は入社後間もない時期から、ビジネスホテル向け自動精算機「ADX-MarkⅠ」の結合テストを担当し、製品の品質を支えてきました。

プロジェクトに加わった当初は、仕様書やログを見ても分からないことばかりだったという4人。それでも、不具合が発生すれば一緒にログを確認し、疑問があれば相談する。誰かが得た知識はチームで共有する。そんなコミュニケーションを日々重ねながら、製品への理解を深めてきました。

前編では、4人が担当した「結合テスト」の仕事や、プロジェクトに参加した当初の率直な気持ち、分からないことに直面したときにどのように支え合ってきたのかを聞きました。

若手4人が担った、製品の品質を支える「結合テスト」

まず、皆さんが携わった「ADX-MarkⅠ」について教えてください

十河さん：ADX-MarkⅠは、ビジネスホテル向けの自動精算機です。既存のホテル向けKIOSKから、今後のカスタマイズも見据えて一新した製品です。

楊さん ：お客様自身でチェックイン・チェックアウトの精算や、ルームカードの受け取りといった一連の流れを完結できるシステムです。内部では複数のハードウェアとマイクロサービスが連携しているため、システムの構造は参画前に考えていたより非常に複雑でした。

そこで、皆さんが担当したのが「結合テスト」ですね

陳さん：はい。結合テストでは、個別に開発されたプログラム同士の連携や通信が、組み合わせた状態でも意図した通りに動作するかを確認します。

十河さん：それぞれの開発者が行う単体テストでは見つけにくい不具合もあります。例えば、開発者同士で仕様の認識にずれがあったり、想定した値が正しく受け渡されていなかったり。実際につないで動かすことで、初めて見えてくる問題があります。

洪さん：そうした問題を結合テストで見つけることで、後続のシステムテストやシナリオテストで不具合が発生することを未然に防ぎます。製品の品質を保証するためにも重要な工程だと思います。

楊さん ：特にADX-MarkⅠは多くのハードウェアとサービスが組み合わさっているので、個々の機能だけでなく、それらを統合した状態で正常に動くことを確認する必要があります。

不具合を見つければ、それで終わりというわけではありません。

ログを調査して原因を絞り込み、デバイス、UI、各サービスの開発担当者やPMと情報を共有し、修正へとつなげていく。製品全体を横断しながら、多くのエンジニアとコミュニケーションを取ることも、結合テストチームの大切な役割でした。

「まず何をすればいい？」から始まった

結合テストを任された当初は、どのような気持ちでしたか？

十河さん：以前、別の業務でシステムテストを経験していたので、テスト自体のイメージはありました。ただ、結合テストとの違いは言葉では説明できても、実際に何をするのかまでは分かっていなくて。「まず何をすればいいのだろう」という状態でした。

洪さん：私は、「自分にこの役割が務まるだろうか」「予定されている期限までにやり遂げられるだろうか」という不安がありました。一方で、大きな仕事を任せてもらえることへのやりがいも感じていました。

陳さん：私はエンジニアとしてのキャリアを歩むために、テスト業務から何を学べるだろうかと少し戸惑いもありました。

楊さん ：私も最初は緊張しました。ただ、テストを通じて製品全体を把握できるので、会社の主力製品のシステムについて深く理解する良い機会だと前向きに捉えていました。

実際に業務が始まってから、特に苦労したことは？

十河さん：私は大学時代、プログラミングも経験したことがなく、システム開発に関する知識がありませんでした。そのためプロジェクトにアサインされて初めの頃は、精算機の仕様を理解することが一番大変でした。最初は仕様書やログなどに何が書かれているかも分からず……といった状態でした。

陳さん：私も同じでした。当時は説明資料がGitHubのリポジトリーやタスク管理のRedmineに分かれて保存されている中で、まず「どこを確認すればよいのか」を探すことにも苦労しました。

製品の仕様や必要な情報が分からない中で、どのように理解を深めていったのでしょうか

十河さん：まずはチーム内で相談し、それでも分からなければ、詳しい開発担当者の方に教えてもらっていました。精算機の仕組みに詳しい先輩方は丁寧に教えてくださり、また私たちの成長を考えてアドバイスをくださいました。

陳さん：十河さんは4人の中で一番長くプロジェクトに参加していたので、私も分からないことがあるとよく相談していました。とても頼りになる存在でした。

十河さん：私自身も開発担当者の方に教えてもらうことが多かったので、そこで得た知識をチームに共有していました。そうしたことを繰り返すうちに、少しずつ各システムのつながりや、精算機全体の動きを理解できるようになりました。

仕様の理解に苦労したとのことですが、実際に不具合を調査する中では、どのような難しさがありましたか？

洪さん：私は特にログの調査に苦労しました。最初は膨大なログの中から不具合に関連する箇所の見当をつけることが難しく、すべてに目を通していたので、かなり時間がかかっていました。

楊さん ：マニュアルや過去の知見だけでは解決できない事象もありました。答えがない中で、試行錯誤を繰り返しながら原因を特定していくことは大変でしたね。

そうした難しい不具合に直面したときは、どのように解決していたのでしょうか

洪さん：一人で調査するのではなく、4人でログを確認することもありました。また、ログに詳しい先輩方にもよく質問していました。AIエージェントも活用しながら、少しずつログの読み方やデータの流れを理解していきました。

楊さん ：各自に担当はありましたが、システム全体の仕様を共有していたので、必要なときには互いにフォローしていました。それぞれが持っている知識を出し合いながら、原因を絞り込んでいくことも多かったですね。原因判明後は今後同じことの繰り返しとならないよう、しっかりと資料に残しています。答えがない中での試行錯誤の経験は、今後の問題解決の力として生かされてくると感じているので、貴重な経験として自分の糧になっています。

分からないことを一人で抱え込まず、まずはチームで相談する。それでも分からなければ、経験豊富な先輩や開発担当者にも聞いてみる。そして、そこで得た知識を再びチームへ共有する。

プロジェクトに参加した当初は、それぞれに不安や戸惑いを抱えていた4人。しかし、こうしたやり取りを日々重ねながら、一つずつ「分からない」を「分かる」に変えていきました。

そうして4人が結合テストチームとして経験を積み、製品への理解を深めていったことは、プロジェクトを円滑に進めていく上でも大きな力となりました。一人ひとりの成長がチームの力となり、そのチームの力が、プロジェクトの成功につながっていったのです。

そして、4人のチームワークがより発揮されたのが、実際のホテルで行われたフィールドテストでした。

「分からない」を一人で抱えない。若手4人がチームで築いた、成長の1年間〜②〜では、ホテルとオフィスに分かれて不具合の解決に取り組んだ4人の連携や、自分たちで仕事の進め方を改善した経験、そして1年間を通じてそれぞれが感じた成長について聞きます。

※記載内容は2026年9月時点のものです