はじめに
2026年9月から1か月間、ソフトウェアエンジニアのインターンとしてクインクエに参加しました。インドからリモートで、神戸のチームと一緒に開発を進めました。担当したのは、倉庫の受付管理システム「ラピロジ」です。
ラピロジは、荷物の積み込みや荷下ろしのためにトラックが倉庫に着いてからの流れを管理するシステムです。ドライバーはタブレットで受付をします。倉庫スタッフは、リアルタイムで更新される待機リストを確認します。順番が来ると、システムがドライバーを呼び出します。
このプロジェクトでは、別々に存在していた2つのバージョンを、1つのコードベースにまとめようとしています。会社ごとの違いは、コードを分けるのではなく設定で吸収します。会社ごとに分かれたコードをなくすこの「フォーク解消」の考え方が、インターン期間中の多くの作業の軸になりました。
私は主に、運用管理コンソールの構築と、日本ロジテム株式会社の導入作業を担当しました。
プロジェクトの概要
ラピロジは、Go、React、TypeScript、PostgreSQL、React Nativeで作られたフルスタックのアプリケーションです。倉庫スタッフ向け、ドライバー向け、そして導入企業や設定を管理する運用チーム向けの画面があります。
開発の進め方で特徴的だったのは、「コントラクトファースト」（スキーマ駆動開発とも呼ばれます）を採用していることです。APIの仕様は1つのOpenAPIファイルで管理されています。クライアントのコードなどは、このファイルから自動生成されます。そのため、どんな変更もまずAPI仕様の修正から始め、その後に実装へ進みます。
私が参加した時点で、テナントの初期セットアップを行うAPI、認証、既存の倉庫業務の機能など、中核部分の多くはすでに動いていました。私の役割は、その土台を広げ、運用管理コンソールを作ることでした。
なお、この記事の「テナント」は、ラピロジを利用する企業1社ごとの単位を指します。「プロビジョニング」は、新しいテナントを使える状態にするための初期セットアップ処理です。
第1週：コードを書く前に読む
最初のタスクは、2社目の企業をラピロジで使えるようにすることでした。条件は、その会社専用のコードを書かず、設定だけで対応することです。
まず、プロビジョニングの設計書を読み、既存のテナントの実装を調べました。その途中で、当初のタスクには含まれていなかった問題に気づきました。
プロビジョニングでは、あるフィーチャーフラグ（機能のオン・オフを切り替える設定）が有効なときにしか、倉庫の建物のデータが作られていませんでした。ところが2社目では、ドライバーが受付で建物を選ばないにもかかわらず、建物のデータが必要でした。データがないと、処理の途中で参照先の建物が見つからず、エラーになる可能性がありました。
これは、コードが1行足りないだけの問題ではありませんでした。「このフラグは、本来何を切り替えるためのものなのか」という設計上の問いにつながっていました。
そこで、2社目のための特別な分岐は入れませんでした。代わりに、テナント設定のひな形（プリセット）に、フラグとは独立した「Buildings」という項目を追加しました。これで、プロビジョニングの際に、プリセットに書かれた建物を作成できるようになりました。
あわせて、この動作を確認するテストも追加しました。
これが、私にとって初めてマージされたプルリクエストです。実装の前に設計を理解することの大切さを、身をもって学びました。
第2週：運用管理コンソールを作る
2つ目の大きなタスクは、運用管理コンソールの開発でした。導入企業とその設定を管理するためのツールです。
コンソールには、テナント一覧、テナント詳細、設定、端末管理、ユーザー管理、監査ログの6つの画面があります。
作業はフロントエンドからバックエンドまで全体にわたりました。API仕様の定義から始め、データベースのマイグレーションとクエリ、GoでのAPI処理、Reactの画面へと順に進めました。
運用担当者向けの、多要素認証つきログイン画面も作りました。倉庫の業務パターンごとの設定画面もあります。
複数の層にまたがる変更をそろえて進める必要があり、インターン期間中で最も難しい作業の1つでした。
このタスクでは、コードレビューに大きく助けられました。指摘を受けて、2つの問題に気づきました。1つは、監査ログで「誰の操作として記録するか」の扱いです。もう1つは、拠点ごとに範囲を限ったユーザー権限の扱いです。どちらも目に見えるエラーは出ていませんでしたが、正しさとセキュリティの面で重要な問題でした。
指摘を反映して実装を直し、プルリクエストはマージされました。
第3週：初期セットアップの信頼性を高める
次のタスクは、テナントの設定に不足がないかを、初期セットアップ時と有効化時にチェックする仕組みを作ることでした。
それまでは、一見正しく設定されていても、運用に必要な設定が抜けているテナントを作れてしまいました。その抜けは、後で業務の途中で処理が止まって、初めて分かる可能性がありました。
そこで、必要な設定を確認するチェック処理を追加しました。不足があれば、どの設定が足りないのかを項目ごとに示すエラーを返します。
特に面白かったのは、チェックをどこまで厳しくするかの判断です。
たとえば、有効化の前にすべての拠点で電話関連の設定を必須にすると、本来問題のない運用まで止めてしまいます。そこで、最低限必要な設定がそろっていれば先に進めるルールにしました。
良いチェックとは、すべてを確認することではないと学びました。本当に必要な条件と、システムを不必要に縛る条件を見分けることが大切です。
この変更も、レビューを経てマージされました。
第4週：不具合修正とデモの準備
最後の期間は、不具合の修正と、社内での動作確認やデモに向けた準備に取り組みました。
アプリケーション全体で、次のような改善を行いました。
- APIのエラーレスポンスの形式をそろえる
- 再セットアップしても、各社がカスタマイズしたステータス名が消えないようにする
- リアルタイム通信が切れたときの再接続を改善する（待ち時間を少しずつ延ばし、上限を設ける指数バックオフを導入）
- 受付用タブレットの完了画面の動作を修正する
- 受付票ページの開発環境向けの設定を改善する
- ブラウザでしか使えない処理を参照していたため、React Native環境で起きていた問題を修正する
また、日本語で2つのドキュメントを作りました。デモの手順書と、社内での動作確認用チェックリストです。
ドキュメントには、環境の準備、業務の流れ、確認手順、現時点での制約をまとめました。日本語で書くのは英語より時間がかかりましたが、とても良い経験になりました。
目的は、私がいなくても、ほかのメンバーがシステムを動かして動作を確かめられるようにすることでした。
これらの修正とデモ準備は、プルリクエスト#138としてマージされました。
予想していなかった学び
1. 読むこともエンジニアリングの一部
最初は、ドキュメントや既存のコードを読む時間が、作業を遅らせているように感じていました。
しかし、その準備があったからこそ、実装を始める前にプロビジョニングの問題に気づけました。システムを理解することは、コードを書くことと同じくらい価値がある。そう実感しました。
2. 1つのバグが設計の問題を映し出すことがある
2社目の問題は、データが1件足りないだけに見えました。しかし実際には、「設定がアプリケーションの動きをどう決めるのか」という問いを含んでいました。
設計の根本から考えたことで、特定の会社向けの分岐を足すよりも、ほかの会社にも使える解決策にたどり着けました。
3. コードレビューは学びの場
テストは通っていたのに、レビューでは重要な問題が見つかりました。
この経験から、テストとレビューは役割が違うと分かりました。テストは、想定どおりに動くかを確かめるものです。レビューでは、人がそもそもの前提を問い直し、自動チェックでは見つからない問題に気づけます。
4. コード生成で考え方が変わる
API仕様から始めてコードを自動生成する開発の進め方は、私にとって初めてでした。
APIのすべてを手で書くのではなく、まず仕様を定義し、対応するコードはツールで生成します。この流れを理解してからは、システムの各部分の食い違いを防ぐのにどう役立つのかが見えてきました。
5. ドキュメントもソフトウェアを届けることの一部
デモ用と動作確認用のドキュメントを作ったことで、「自分のコードが動くか」の先まで考えるようになりました。
動かし方、確かめ方、制約がほかの人にも分かる機能は、保守しやすくなります。ドキュメントは開発と別物ではなく、タスクを終わらせることの一部だと考えるようになりました。
チームについて
私はプロジェクトリーダーのもとで働き、成果物のレビューを受けました。システムの別の部分を担当する、もう1人のインターンとも一緒に働きました。
特に印象に残ったのは、文書がしっかり整っていたことです。どのドキュメントに従えばよいか、どの情報が古いか、どの動作を必ず守るべきかが、はっきり書かれていました。
短期間で初めてのコードベースに入る立場として、これはとても心強いものでした。おかげでシステムを早く理解でき、自信を持って作業できました。
また、1人で抱え込まず、具体的に質問することも学びました。質問するときは、背景や自分で調べて分かったことも添え、チームが答えやすいように心がけました。
時差のある環境で、主に日本語で話すチームとリモートで働いたことで、技術的なメッセージの書き方も上達しました。誤解があると作業が遅れてしまいます。だからこそ、それだけ読めば伝わる、明確な文章が大切でした。
マイルストーン
- 第1週：オンボーディングと設計書の読み込み。2社目の初期セットアップの改善とテストの追加。プルリクエスト#122マージ。
- 第2週：API仕様、データベース、Goのバックエンド、Reactの画面にわたって運用管理コンソールを構築。プルリクエスト#129マージ。
- 第3週：初期セットアップ時の設定チェックを追加し、設定の扱いを改善。プルリクエスト#134マージ。
- 第4週：不具合の修正、リアルタイム通信の再接続の改善、デモ用・動作確認用ドキュメントの作成。プルリクエスト#138マージ。
これから
このインターンでは、API仕様やデータベースの変更から、バックエンドの処理、フロントエンドの画面まで、実際に使われるシステムの幅広い層に関わることができました。
同時に、これから伸ばしたい点も見えました。既存のシステムの中で作業することには慣れてきました。今後は、自分で解決策を設計し、アーキテクチャの判断をすることに、もっと自信を持てるようになりたいです。
これからも、バックエンドのスキルを磨き、システム設計への理解を深めていきます。そして、信頼性が高く、保守しやすく、ほかの人にも扱いやすいソフトウェアを作れるエンジニアを目指します。
おわりに
1か月は短い期間です。最初は、小さく切り分けられたタスクを担当するのだろうと思っていました。
しかし実際には、本物のプロダクトの開発に加わり、任されたタスクの外にある問題を見つけ、フルスタックの機能を作り、丁寧なコードレビューから多くを学びました。
いちばん大きな学びは、ソフトウェアエンジニアリングはコードを書くことだけではない、ということです。システムを理解し、前提を問い直し、明確に伝え、丁寧にテストし、後でそのコードを引き継ぐ人のことまで考える。そのすべてが必要だと知りました。
クインクエのチームの皆さまには、学びながら貢献し、チームでソフトウェアを前に進めていく経験をさせていただきました。心から感謝しています。
このインターンを通じて、自分がなりたいエンジニア像と、これから伸ばしたいスキルがはっきりしました。
以下、原文。
One Month on a Warehouse Reception System: My Autumn Internship at Quin Que
In September 2026, I joined Quin Que as a software engineering intern for one month, working remotely from India with the team in Kobe, Japan. I was assigned to Rapilogi, a warehouse reception management system.
Rapilogi manages what happens when a truck arrives at a warehouse to load or unload cargo. Drivers check in at a tablet, warehouse staff monitor a live waiting list, and when it is a driver's turn, the system calls them.
The project aims to bring two existing versions of the system into a single codebase, with differences between companies handled through configuration rather than separate implementations. This approach, known as fork elimination, was central to much of my work throughout the internship.
My main responsibilities were building the operations console and helping bring a second company onto the platform.
Project Overview
Rapilogi is a full-stack application built with Go, React, TypeScript, PostgreSQL, and React Native. It includes interfaces for warehouse staff, drivers, and the team responsible for managing tenants and system configuration.
One aspect that shaped how I worked was the project's contract-first development process. The API contract is maintained in a single OpenAPI file, and client code and other generated artifacts are produced from it. Changes therefore begin with the contract before moving into implementation.
When I joined, several core parts of the system were already in place, including the provisioning API, authentication, and the existing warehouse workflows. My work focused on extending these foundations and building the operations console.
Week 1: Reading Before Coding
My first task was to bring a second company onto the platform using configuration rather than tenant-specific code.
Before writing anything, I read the provisioning design documents and explored the existing tenant implementation. During this process, I discovered a problem that had not been part of the original task.
The provisioning process created a building record only when a particular feature flag was enabled. However, the second tenant's workflow required a building to exist even though drivers did not select one during check-in. Without that record, calls could fail because the required location was missing.
The issue was not simply a missing line of code. It raised a deeper question: what should the feature flag actually control?
Instead of adding a special case for one tenant, I introduced a separate Buildings field in the tenant preset, independent of the feature flag. Provisioning could then create the locations specified by the preset.
I also added tests to verify the behavior.
This became my first merged pull request, and it taught me how much value there can be in understanding the design before starting implementation.
Week 2: Building the Operations Console
My second major task was developing the operations console, a tool for managing tenants and their configurations.
The console included six main areas covering tenant lists, tenant details, configuration, devices, users, and audit logs.
I worked across the stack, starting with the API contract, followed by database migrations and queries, Go backend handlers, and the React frontend.
The console also included an operator login screen with multi-factor authentication and configuration editors for different warehouse workflows.
This was one of the most challenging parts of the internship because it required coordinating changes across multiple layers of the application.
Code review was particularly valuable during this task. Feedback helped me identify issues involving audit log attribution and site-scoped user permissions. These were not obvious failures, but they mattered for correctness and security.
I incorporated the feedback and improved the implementation before the pull request was merged.
Week 3: Making Provisioning More Reliable
My next task focused on validating tenant configuration during provisioning and activation.
Previously, it was possible to create a tenant that appeared to be configured correctly but was missing settings required for normal operation. The problem might only become visible later, when a workflow failed.
I added validation to check required settings and return structured errors that identify exactly what is missing.
One of the most interesting parts was deciding how strict the validation should be.
For example, requiring every site to have all its telephony settings before activation would have blocked a legitimate workflow. Instead, I worked on a validation rule that allowed the tenant to proceed once the necessary minimum configuration was present.
This taught me that good validation is not simply about checking everything. It is about understanding which conditions are genuinely necessary and which ones would unnecessarily restrict the system.
The changes were reviewed and merged.
Week 4: Bug Fixes and Demo Preparation
The final stretch of the internship focused on bug fixes and preparing the system for internal verification and demonstration.
This work involved several improvements across the application:
• Standardizing API error responses
• Preserving customized status names during re-provisioning
• Improving real-time connection recovery with capped exponential backoff
• Fixing behavior on the kiosk completion screen
• Improving the development configuration for the receipt page
• Fixing a browser-specific reference that caused problems in the React Native environment
I also prepared two documents in Japanese: a demo procedure and an internal verification checklist.
The documents covered setup, workflows, verification steps, and known limitations. Writing them in Japanese took more time than writing in English, but it was an important learning experience.
The goal was to make it easier for other team members to run the system and verify its behavior without depending on me being present.
The bug fixes and demo preparation work were included in PR #138, which was merged.
Unexpected Learnings
1. Reading Is Part of Engineering
I initially felt that spending time reading documentation and existing code was slowing me down.
However, that preparation helped me discover the provisioning issue before implementation began. I learned that understanding the system can be just as valuable as writing code.
2. A Bug Can Reveal a Design Problem
The second-tenant issue looked like a simple missing record. In reality, it exposed a question about the relationship between configuration and application behavior.
Thinking about the underlying design led to a more reusable solution than adding a tenant-specific condition.
3. Code Review Is a Learning Opportunity
My tests passed, but review still identified important issues.
The experience helped me understand that testing and code review serve different purposes. Tests verify expected behavior, while a reviewer can question assumptions and identify problems that automated checks may not catch.
4. Generated Code Changes How You Think
Working with a contract-first workflow was new to me.
Instead of directly writing every part of an API, I had to define the contract and let the project tooling generate the corresponding code. Once I understood the workflow, I could see how it helped keep different parts of the system consistent.
5. Documentation Is Part of Delivering Software
Preparing the demo and verification documents made me think beyond whether my code worked.
A feature is easier to maintain when another person can understand how to run it, test it, and identify its limitations. I came to appreciate documentation as part of completing a task rather than something separate from development.
About the Team
I worked under a project leader who reviewed my contributions and alongside another intern working on a different part of the system.
One thing that stood out was the importance of written documentation. The project had clear guidance about which documents to follow, which information was outdated, and which behaviors were especially important to preserve.
As someone joining an unfamiliar codebase for a short internship, this made it much easier to understand the system and contribute with confidence.
I also learned to ask specific questions rather than struggling alone. I tried to bring the context and findings behind a question so that the team could respond more efficiently.
Working remotely across a time difference with a team communicating primarily in Japanese also improved the way I write technical messages. Clear, self-contained communication became especially important because misunderstandings could delay progress.
Milestones
Week 1: Onboarding, design-document study, and second-tenant provisioning improvements with tests. PR #122 merged.
Week 2: Built the operations console across the API contract, database, Go backend, and React frontend. PR #129 merged.
Week 3: Added provisioning validation and improved configuration handling. PR #134 merged.
Week 4: Fixed application issues, improved real-time recovery, and prepared demo and verification documentation. PR #138 merged.
Looking Ahead
This internship gave me an opportunity to work on a real software system across several layers, from API contracts and database changes to backend logic and frontend interfaces.
It also showed me areas where I want to improve. I became more comfortable navigating an existing system, but I want to become more confident in designing solutions independently and making architectural decisions.
Going forward, I want to continue strengthening my backend engineering skills, improve my understanding of system design, and become better at building software that is reliable, maintainable, and easy for others to work with.
Closing
A month is short, and I initially expected to spend the internship working on small, isolated tasks.
Instead, I contributed to a real product, discovered a problem outside my original task, built a full-stack feature, and learned from detailed code reviews.
The most valuable lesson for me was that software engineering involves much more than writing code. It requires understanding the system, questioning assumptions, communicating clearly, testing carefully, and thinking about the people who will maintain the work afterward.
I am grateful to the Quin Que team for the opportunity to learn, contribute, and experience how a software project moves forward through collaboration.
This internship has given me a clearer idea of the engineer I want to become and the skills I want to keep developing.
