創業テックリード ｜ 業務内容
決める人を、社内に置きます。
この席には、まだ誰もいません。
何を最初にお願いするのか。開発体制はどうなっているのか。AIをどう使っているのか。
入ってからの景色が想像できるように、順に書いていきます。
「分かりました、作ります」で、終わってほしくない。
いま社内で強化したいのは、ここです。技術と開発の力はあります。足りていないのは、顧客との会話から、背景と目的と事業上の意図を引き出して、社内に持ち帰るところ。
顧客から「この機能を作ってほしい」と言われたとき、そこで止まらずに聞いてほしいことがあります。
- なぜ、その機能が必要なのか
- いま、どんな問題が起きているのか
- 誰が使うのか
- その機能で、何を改善したいのか
- なぜ、いまやる必要があるのか
- この先、どこまで発展させたいのか
- その要望の先に、どんな事業構想があるのか
たとえば、ある取引先で、いくつもの会社や店舗にシステムを入れることが決まったとします。大事なのは、決まったという結果ではありません。なぜ、その会社が入れようと思ったのか。そこまで分かって、はじめて次が考えられます。
この背景が社内に届けば、経営の側も次の商品開発や提案を先回りできます。逆に、要望だけが伝票のように流れてくると、いつまでも受け身のままです。
顧客 → 技術 → 事業 → 経営。この4つを繋げられる方を探しています。技術力そのものよりも、ここを一緒に考えられるかを重視しています！
まず、この3つから。
- 大手自動車企業向けシステムの開発。要件定義から設計、進行管理、基幹システムとのAPI連携まで
- 当社特許取得サービスである輸送マッチング（eeeezy.com・eeeezy board）の保守、アップデート開発。既存システムの引き継ぎ・機能向上・改修と障害対応を自社で回せる状態にします
- 物流SaaSの、納品後の改修対応。2027年初旬に納品予定の陸送会社向けの基幹システムです
まず既存のものを自分の手に馴染ませていただき、その先の話は、様子を見ながら順番を相談させてください。
そこから、どう広がるか
初期段階から、設計・詳細設計には入って頂きます。あわせて、上記の業務に慣れていただくことと、開発パートナーとの進行管理もお願いしたい。ただし、入って早々にすべてをお任せするのは、環境も分からないうちでは現実的ではありません。し、そこで無理をしていただくつもりはありません。
慣れてきたら、新規開発案件の要件定義と設計をお任せしていきます。物流SaaSを納品後にサブスクとして育てていく段階、そして新しくご依頼いただく開発案件については、ご経験とスキルに応じて、設計も技術選定もお任せします。既存のものを引き継ぐのと、これから形にしていくのとでは、話が違うからです。
新しく生まれるものは、自分の子供を育てるように、楽しんで開発していただきたい。そういう関わり方をしていただけたらと思っています。
業務を通じて、身につけて頂きたいこと
- サブスクリプション型SaaSの機能企画、要件定義、設計、リリース
- 顧客の要望を、標準機能にするか個別対応にするかの切り分け
- 社外取引先のシステム企画・設計、ITコンサルティング、プロジェクト管理
- 外部の開発会社との共同開発、進行管理
- 設計工程を社内で持てる比率を、少しずつ上げていくこと
- 開発のルール、プロセス、ドキュメントを、使える形に整えていくこと
- （その先）プロダクト戦略、IT投資計画、ベンダー選定、開発組織の構築
担っていただく範囲は、ご経験の伸びと事業の進み方に応じて変わります。広がることもあれば、絞ることもあります。そこは都度ご相談させてください。
※業務の変更範囲：会社の定める業務全般への変更の可能性があります。
AIの使い方について
当社ではAIエージェントツールを営業、マーケティング、コーディングなどにおいて積極的に活用しています（2026年9月時点では Claude Codeを利用）。少人数で事業規模の拡大が可能となった理由は、その為だと考えています。
システム開発において主な利用方法としては、
- 既存システムの解析
- モックの作成
- 一部コーディング
- 仕様書の作成
- テスト工程
となっております。ただし、内容については必ず人的チェックと判断を取り入れております。AIが出してくるものに、血の通った熱量を込めることも必要です。
応募の時点で Claude Code を使えている必要はございませんが、入社までには一度触って頂き、概要程度は把握して頂けると助かります。入社前に触って頂く分には無料プランで構いません。
当社ではエージェント系のAIは、必須利用となります。入社後はもちろん会社負担でご利用をして頂きます。
出社を月8回お願いしている理由
当社はオフィス勤務とリモートワークの併用となり、出社は月8回程度（週2回が目安）。
フルリモートにしない理由を、正直に書いておきます。
当社の武器は「自動車業界の知識や苦労がわかるシステム会社」であること。
そこを目指している以上、共に働くあなたにも、
その知識を身につけたSIerになって頂く必要があります。
ヤードで何が起きているのか。陸送会社が何に困っているのか。
こうしたことは、資料を読んで身につくものではありません。
代表や現場が電話で話している内容、打ち合わせの帰りに交わす雑談、
「そういえば昨日あの現場でね」という何気ないひとこと。
業界の勘どころは、そういう些細な会話から入ってきます。
リモートだけで進めると、そこが抜け落ちます。
教える側も伝えきれないし、何よりご本人にとって、身につくものが少なくなってしまう。会社の都合というより、そこを心配しています。
だからこそ、出社と、そこで生まれるコミュニケーションを大事にしています。
顔を合わせて話すからこそ渡せるものがある、という考えです。
自動車業界の知識 × システム開発 = 当社の価値
当社の価値 = 一緒に働く仲間の価値
こちらを大事にしています。
いまの体制と、変えたいこと
いまの開発工程
| 要件 | 社内／自動車業界に詳しいスタッフが、取引先と一緒に固めます |
|---|---|
| 要件・設計・詳細設計 | 社外ベンダー |
| 実装 | 社外ベンダー |
| システム全体の面倒 | 社外ベンダー |
上記を2社の協力ベンダーと進めていますが、プロジェクトが多くなってきているため、設計・詳細設計の工程に、追加であなたにお願いしたいと考えています。要件も、はじめは社内スタッフと一緒に。慣れてきたら主担当として勤めて頂きます。
一緒につくるチーム
オフショア開発ベンダーを含めたチーム開発となります。
| インフラ系 | サーバー・AWSの保守／1チーム |
|---|---|
| PHP系 | ヤード管理・車両管理システムの開発と既存システムの保守／1〜3チーム |
| Flutter系 | ドライバー向け・ヤード現場向けモバイルアプリの開発と改修／1チーム |
- PHP系とFlutter系は、PM3名とオフショアの開発チーム。ブリッジSEを挟んで進めています
- 社内外あわせて、常時10名ほどが当社の開発に関わっています
- コードをすべてご自身で書き切る仕事ではありません。何をどう作ってもらうかを決め、上がってきたものを見て判断する。そこが中心です
- 急ぎの改修や障害対応など、ご自身の手が早い場面では直接手を入れて頂きます
- ゆくゆくは、このチーム全体のまとめ役としても機能して頂けるよう、視野に入れて頂けると嬉しいです。
変えたいこと
| いま | これから |
|---|---|
| 設計から先を社外に預けているため、判断のたびに社外を経由する。決めるだけで時間がかかる | 設計工程を社内で持てる比率を、少しずつ上げていく |
| 開発ルールもまだまだ弱い。 | 会社の統制も強化したい |
整った環境をご用意してお迎えするのではなく、整えるところから握って頂くことになります。まずは既存の案件に馴染んで頂くのが先で、そのうえで少しずつ、というイメージです。
チームの考え方
- 社外に出している開発を引き上げる話ではありません。長くお付き合い頂いている各社とは、これからも一緒に事業を伸ばしていきます。当社側に設計を判断できる人が立つことで、先方のご担当者の負担も軽くなると考えています
- 相談する相手はいます。当社のシステムを見ているエンジニアもおり、技術に明るいパートナー各社にも聞ける関係です。いきなり一人で背負う状況にはなりません
開発責任者候補として、一緒に育っていければと思っています。ゆくゆくはCTOとして、というのも当然あり得ます。ただ、それは肩書きの話です。いま大事なのは、一緒に手を動かして事業を伸ばすことだと思っています。
経営の側にも、入っていただきます。
技術の判断だけを切り出してお願いするつもりはありません。何を作るかは、事業をどうしたいかと切り離せないからです。
- 経営会議に参加していただきます。投資の判断や優先順位づけに、最初から入っていただきます
- 新しいサービスの企画を、ご自身から出していただいて構いません。むしろ、そうしていただきたいと思っています
まだ役割がきれいに分かれていない会社です。
裏を返せば、口を出せる範囲が広いということでもあります。
この仕事で、経験できること
一般的な開発職より、関わる範囲がかなり広くなります。
身につく事
- プロダクトを形にする速さ。使い手はヤードの管理担当者、配車担当者、ドライバー。仕様の確認も反応の回収も現場に直接できるため、迷いと手戻りが少ない
- 物流テックで通用する経歴。在庫・ロケーション管理（WMS領域）とマッチングプラットフォームの両方を、プロダクトとして育てた実績が残る
- 狭くて深い業務知識。AIがコードを書く時代に、自動車流通の業務がわかる人の価値は下がらない
- 自社SaaSと受託開発の両方。片方だけの会社では見えないことが見える
- 最後まで見届けられる。要件定義からリリース、その後の改善まで、途中で誰かに渡さない
- 経営との距離が近い。投資の判断や優先順位づけに最初から入れる
- 進め方を自分で決められる。この役割は社内にまだない