「分かりました、作ります」で、終わってほしくない。

いま社内で強化したいのは、ここです。技術と開発の力はあります。足りていないのは、顧客との会話から、背景と目的と事業上の意図を引き出して、社内に持ち帰るところ。

顧客から「この機能を作ってほしい」と言われたとき、そこで止まらずに聞いてほしいことがあります。

• なぜ、その機能が必要なのか
• いま、どんな問題が起きているのか
• 誰が使うのか
• その機能で、何を改善したいのか
• なぜ、いまやる必要があるのか
• この先、どこまで発展させたいのか
• その要望の先に、どんな事業構想があるのか

たとえば、ある取引先で、いくつもの会社や店舗にシステムを入れることが決まったとします。大事なのは、決まったという結果ではありません。なぜ、その会社が入れようと思ったのか。そこまで分かって、はじめて次が考えられます。

この背景が社内に届けば、経営の側も次の商品開発や提案を先回りできます。逆に、要望だけが伝票のように流れてくると、いつまでも受け身のままです。

まず、この3つから。

1. 大手自動車企業向けシステムの開発。要件定義から設計、進行管理、基幹システムとのAPI連携まで
2. 当社特許取得サービスである輸送マッチング（eeeezy.com・eeeezy board）の保守、アップデート開発。既存システムの引き継ぎ・機能向上・改修と障害対応を自社で回せる状態にします
3. 物流SaaSの、納品後の改修対応。2027年初旬に納品予定の陸送会社向けの基幹システムです

まず既存のものを自分の手に馴染ませていただき、その先の話は、様子を見ながら順番を相談させてください。

そこから、どう広がるか

初期段階から、設計・詳細設計には入って頂きます。あわせて、上記の業務に慣れていただくことと、開発パートナーとの進行管理もお願いしたい。ただし、入って早々にすべてをお任せするのは、環境も分からないうちでは現実的ではありません。し、そこで無理をしていただくつもりはありません。

慣れてきたら、新規開発案件の要件定義と設計をお任せしていきます。物流SaaSを納品後にサブスクとして育てていく段階、そして新しくご依頼いただく開発案件については、ご経験とスキルに応じて、設計も技術選定もお任せします。既存のものを引き継ぐのと、これから形にしていくのとでは、話が違うからです。

新しく生まれるものは、自分の子供を育てるように、楽しんで開発していただきたい。そういう関わり方をしていただけたらと思っています。

業務を通じて、身につけて頂きたいこと

• サブスクリプション型SaaSの機能企画、要件定義、設計、リリース
• 顧客の要望を、標準機能にするか個別対応にするかの切り分け
• 社外取引先のシステム企画・設計、ITコンサルティング、プロジェクト管理
• 外部の開発会社との共同開発、進行管理
• 設計工程を社内で持てる比率を、少しずつ上げていくこと
• 開発のルール、プロセス、ドキュメントを、使える形に整えていくこと
• （その先）プロダクト戦略、IT投資計画、ベンダー選定、開発組織の構築

担っていただく範囲は、ご経験の伸びと事業の進み方に応じて変わります。広がることもあれば、絞ることもあります。そこは都度ご相談させてください。

※業務の変更範囲：会社の定める業務全般への変更の可能性があります。

出社を月8回お願いしている理由

当社はオフィス勤務とリモートワークの併用となり、出社は月8回程度（週2回が目安）。

フルリモートにしない理由を、正直に書いておきます。

当社の武器は「自動車業界の知識や苦労がわかるシステム会社」であること。

そこを目指している以上、共に働くあなたにも、

その知識を身につけたSIerになって頂く必要があります。

ヤードで何が起きているのか。陸送会社が何に困っているのか。

こうしたことは、資料を読んで身につくものではありません。

代表や現場が電話で話している内容、打ち合わせの帰りに交わす雑談、

「そういえば昨日あの現場でね」という何気ないひとこと。

業界の勘どころは、そういう些細な会話から入ってきます。

リモートだけで進めると、そこが抜け落ちます。

教える側も伝えきれないし、何よりご本人にとって、身につくものが少なくなってしまう。

会社の都合というより、そこを心配しています。

だからこそ、出社と、そこで生まれるコミュニケーションを大事にしています。

顔を合わせて話すからこそ渡せるものがある、という考えです。

自動車業界の知識 × システム開発 = 当社の価値

当社の価値 = 一緒に働く仲間の価値

こちらを大事にしています。

いまの体制と、変えたいこと

いまの開発工程

上記を2社の協力ベンダーと進めていますが、プロジェクトが多くなってきているため、設計・詳細設計の工程に、追加であなたにお願いしたいと考えています。要件も、はじめは社内スタッフと一緒に。慣れてきたら主担当として勤めて頂きます。

一緒につくるチーム

オフショア開発ベンダーを含めたチーム開発となります。

• PHP系とFlutter系は、PM3名とオフショアの開発チーム。ブリッジSEを挟んで進めています
• 社内外あわせて、常時10名ほどが当社の開発に関わっています
• コードをすべてご自身で書き切る仕事ではありません。何をどう作ってもらうかを決め、上がってきたものを見て判断する。そこが中心です
• 急ぎの改修や障害対応など、ご自身の手が早い場面では直接手を入れて頂きます
• ゆくゆくは、このチーム全体のまとめ役としても機能して頂けるよう、視野に入れて頂けると嬉しいです。

変えたいこと

整った環境をご用意してお迎えするのではなく、整えるところから握って頂くことになります。まずは既存の案件に馴染んで頂くのが先で、そのうえで少しずつ、というイメージです。

チームの考え方

• 社外に出している開発を引き上げる話ではありません。長くお付き合い頂いている各社とは、これからも一緒に事業を伸ばしていきます。当社側に設計を判断できる人が立つことで、先方のご担当者の負担も軽くなると考えています
• 相談する相手はいます。当社のシステムを見ているエンジニアもおり、技術に明るいパートナー各社にも聞ける関係です。いきなり一人で背負う状況にはなりません

開発責任者候補として、一緒に育っていければと思っています。ゆくゆくはCTOとして、というのも当然あり得ます。ただ、それは肩書きの話です。いま大事なのは、一緒に手を動かして事業を伸ばすことだと思っています。

経営の側にも、入っていただきます。

この仕事で、経験できること

一般的な開発職より、関わる範囲がかなり広くなります。

身につく事

• プロダクトを形にする速さ。使い手はヤードの管理担当者、配車担当者、ドライバー。仕様の確認も反応の回収も現場に直接できるため、迷いと手戻りが少ない
• 物流テックで通用する経歴。在庫・ロケーション管理（WMS領域）とマッチングプラットフォームの両方を、プロダクトとして育てた実績が残る
• 狭くて深い業務知識。AIがコードを書く時代に、自動車流通の業務がわかる人の価値は下がらない
• 自社SaaSと受託開発の両方。片方だけの会社では見えないことが見える
• 最後まで見届けられる。要件定義からリリース、その後の改善まで、途中で誰かに渡さない
• 経営との距離が近い。投資の判断や優先順位づけに最初から入れる
• 進め方を自分で決められる。この役割は社内にまだない