一番重視していたのは「実際に手を動かして開発できる環境かどうか」でした。

前職は金融系の開発を請け負うSES企業で、アプリ開発のチームに所属していましたが、実際にコードを書く時間よりも、表計算ソフトで仕様書やテスト証跡をまとめる時間の方が圧倒的に長かったのです。
テストを実施した証拠をひたすら細かく記録していくような業務が中心で、気づけば「コードを書くエンジニア」というよりも、表計算ソフトを方眼紙のように使いこなす職人のようになっていました。

そうした状況に課題を感じていたタイミングで、転職エージェントを通じてスパイダープラスを紹介されました。
選考の過程で、在籍しているエンジニアの方々と面接する機会があり、そこで自分の経験やポテンシャルを丁寧に見出してもらえたことが、入社を決める大きなきっかけになりました。

決め手は大きく3つありました。

まず、面接をしてくださった方々の関係性の良さです。
やり取りの中から自然と良い雰囲気が伝わってきて、シンプルに「楽しそうな会社だ」と感じました。

次に、技術的な面白さです。
図面を取り込んで手書きの線を書き込んだり、アイコンを配置したりできる仕組みは、自分自身にとってどこか珍しいものでした。
当時は、世の中に出回っていたアプリの多くは画像をそこまで大量かつ多様に扱うものは多くなく、その点で6年半前の時点ですでに尖った挑戦をしている組織のように映りました。

最後に、開発速度の速さにも魅力を感じました。
前職は金融系のSES企業で、一つの修正に対してもクライアント向けの説明資料やチェックリストなど、大量のドキュメントを整えたうえで、いくつもの承認プロセスを経る必要がありました。実際にリリースされるまでには数ヶ月から半年ほどかかるのが当たり前という環境でした。

それに比べて、スパイダープラスでは意思決定が社内で完結しており、毎月何かしらのリリースが行われている状況でした。
この違いは、私にとって大きな魅力に映りました。

面接を担当してくださった方から「開発のスピード感がだいぶ違いますが、うちのスピードについていけますか?」と聞かれて、その問いかけ自体に、ワクワクしたことをよく覚えています。

スパイダープラスは今でこそ、入社すると職種を問わずに建設業界の実情レクチャーなど、詳しいオンボーディングが行われます。
私の入社当初を振り返ると、座学で業界知識を体系的に学ぶよりも先に、不具合修正といった実際の業務からスタートした記憶があります。
もともと工事業から始まった会社であることもあり、現場を知ることは職種を問わず大きな差別化要素になるという考え方が根底にあり、まずは手を動かしながら実務の中で学んでいく進め方だったのだと思います。
建設業界に対する意識は、当初はそれほど高くありませんでしたが、既存の開発コードを読み解きながらシステムの構造を理解していく作業自体は純粋に楽しいと感じていました。

入社した翌週には、ほぼ全社的にリモートワークへ移行することになり、パンデミックの影響を早い段階で実感しました。

その後、2年目、3年目と徐々にメンバーが増え、本社移転などの動きもあり、その頃からオンボーディングの体制が整理されていきました。
建設業界に関する勉強会も始まり、ドメイン知識を本格的に身につけていく機会が増えました。
それに伴い、それまで自分が担当してきた業務の意味を改めて理解できるようになりました。

建設現場に足を運ぶ機会もあり、配筋作業（コンクリートの芯となる鉄筋を配置する工程）が行われている現場の様子を実際に目にしました。
コンクリートを打つ前の足場や床に穴が空いている状態や、現場では電波がつながらないことなども、実際に見て初めて理解できたことです。
こうした環境の中で紙やペン、カメラを持ちながら作業を進めることがいかに大変かを、身をもって実感しました。

その上で、SPIDER+というプロダクトの存在がいかに現場の在り方を変える革命的なものであるかを、改めて実感することになりました。

実を言うと、キャリアについて明確な理想像は当初あまり持っていませんでした。
唯一意識していたのは、入社前の表計算ソフトで「方眼紙職人」のような状態にあった自分から脱却することでした。

そんな折、当時のマネージャーたちに導かれるように、プロジェクトマネジメントやEM(エンジニアリングマネージャー)を経験させてもらう機会を得ました。
実際にさまざまな役割を経験してみたことで、プロジェクト運営から部下のマネジメントや評価まで、ある程度は何でも対応できるという実感を持てるようになりました。

昨年、キャリアや自身の適性を改めて見つめ直し、プレイヤーとして現場で価値を発揮する選択をしたことをきっかけにEMの役割を離れ、プロダクトチームからモバイルチームへ異動し、再びエンジニアとしての立場に戻りました。
直近まではFlutter化プロジェクト（※2011年以来続いてきたSPIDER+のアプリを根本的にシステム刷新するための取り組み）でエンジニアリングとマネジメントを兼務していましたが、世の中ではAI駆動開発が急速に広がっており、社内でも取り入れながらFlutter化を推進してきました。

ただ、最近になって、正直なところ少し物足りなさを感じ始めています。
なぜそう感じるのか改めて振り返ると、自分自身はプログラムを書くこと自体が好きなのだと気づきました。
洗濯を今さら洗濯板でやらないのと同じで、開発によって利益を生み出すためには、時代に合った道具を使うべきだという考えも理解しています。
それでも、コードを書く時間そのものに自分の価値を感じている部分があります。
そんな悩みを抱えていた時に、同じプロジェクトを率いる仲間から「仕組みづくりに楽しさを見出していくとよいのでは」というアドバイスをもらいました。
そこから、プロジェクトマネージャーという役割そのものにこだわるのではなく、物事を整理し、仕組みとして機能させていく役割を担う方向に意識を移しています。
組織としてもキャリア形成としても、まだ固まりきったフェーズではないからこそ、自分次第でさまざまな挑戦ができる柔軟性があると感じています。

プロジェクトマネジメントについては、自分自身もプロジェクトに参加しながら見てきた経験があったため、何をすべきかはある程度イメージが持てていました。
一方で、少し時間をさかのぼりますが、EMを担うことになった当初は事情が異なりました。
「EMとは何をする役割なのか」ということをゼロから知るところから始まりました。
ちょうど良いロールモデルがいなかったこともあり、ほぼ白紙の状態で、手探りしながらスタートしていきました。

そこで、自分なりに振り返り、「ただ勤怠管理をするだけの人」で終わるのか、そうではないのかという差分を埋めていくことを意識するようにしました。
メンバー一人ひとりをきちんと見ているということが伝わるよう、具体的な行動で示すことを心がけました。
たとえば、勤怠の締めのタイミングで、メンバーや業務委託の方々にメッセージを送る際、承認のコメント欄に労いの言葉や具体的な業務へのフィードバックを添え、あわせて自分自身も改善に向けて取り組む姿勢を伝えるようにしていました。
日々のミーティングの持ち方なども含め、試行錯誤を重ねていきました。

そうした積み重ねを通じて、少しずつ手応えを感じるようになりました。
最初は控えめだったメンバーが自分から話してくれるようになったり、技術面の関心が業界ドメイン知識への興味を常に上回っていたメンバーが現場見学の際に積極的に質問してくれるようになったりと、行動の変化を実際に目にすることができました。

その後プロジェクトマネージャーとしてFlutterプロジェクトに関わるようになってからも、会社の上層部から降りてくる情報をメンバーにどう伝えるかは、マネージャーとして重要な役割だと考えるようになりました。
情報を伝えるにも材料が必要ですし、不明点があれば自分がまず解消しておく必要があります。
メンバーから受けた質問に答えるための準備も、マネージャーとしての大切な仕事の一つでした。

Slackの反応の早さについては、意識的に取り組んできたことです。

在宅勤務が中心になると、姿が見えない分、組織の中で存在が薄くなりがちです。
だからこそ、区切りの良いタイミングでSlackに目を通し、必要な情報はすぐにメンバーへ共有することを心がけていました。

プログラムを書く時間が減った分、自分の時間を何に使うべきかを考えたときに行き着いたのが、メンバーやチームの状況に目を配ることでした。
反応の速さは単なる習慣というより、開発を止めないための判断や情報を、必要なタイミングでメンバーに届けるための手段だったと思います。

一般的な技術選定の場面では、Flutter化プロジェクトを率いているメンバーが中心になって進めてくれることが多くありました。
採用技術に関する提案が出た際は、必ず一度疑問を持つようにしていました。

スパイダープラスのバリューにもあることですが、「前提を疑う」ことを意識的に行い、具体的なアプリの要件と照らし合わせながら実現可能性を確認したり、懸念点を一つひとつ解消したりする作業を積み重ねていきました。
ただし、否定をするだけで終わらせないことを大切にしていました。
疑問を投げかけたところで議論を止めるのではなく、より目的に合った方法を一緒に探っていけるよう、議論の幅やコミュニケーションの機会を広げるようにしていました。

開発フェーズが一段落し、プロダクトが安定期に入ると業務が静まり返ってしまう、という状況はよく聞きます。
対応領域が軽微な修正や不具合対応に留まると、次第に面白さを見出しにくくなるケースは少なくありません。

スパイダープラスでは、そうした状況にはなりません。
常に新たな課題が生まれ続けている組織なので、やるべきことは常に盛りだくさんで、飽きる要素がないというのが率直な実感です。
変化やそのスピードを楽しめる方にこそ、より力を発揮していただける環境だと思います。

組織構成の面では、事業方針の変化に合わせて、それを実現できる体制へと変わっていく部分があります。
開発組織のあり方自体も、状況に応じて柔軟に変化してきました。
一方でプロダクトのあり方そのものが変わり、組織や体制がどれだけ変化しても、やるべきことの本質は変わらないと考えています。
経営が示す方針を実現するために「なんとかしなければならない」という姿勢は、これまでも、これからも同じです。
開発組織として、事業を前に進めるための武器をつくり続けることが自分たちの本分であることは変わりません。

この段階においても、新たな課題を解決し続けるという姿勢そのものは変わりません。
建設業界のデジタル化についても、これといった正解や決まった型が存在しているわけではなく、まだまだ未知の領域が多く残されている分野です。だからこそ、プロダクト開発においても解決すべき課題は尽きることがありません。

定常業務を安定してこなすフェーズに落ち着くというよりも、これから先もしばらくは、常に課題と向き合いながら前に進んでいく状態が続いていくと考えています。

利用者にとってプロダクトが安定して使えることは大前提です。
一方で、それを支える仕組みや事業のあり方そのものは、常に変化し続けるものだと考えています。
もし、その裏側までもが「安定した」と感じられるようになったとすれば、それは事業が終わりに近づいている時なのかもしれません。

建設業界は、現場一つひとつがまったく異なる環境にあります。
一度システムを作り上げて安定させたとしても、現場そのものが抱える課題は尽きることがありません。
FlutterやRustといった技術を積極的に取り入れているのも、この業界自体がまだまだ安定していないからこそだと捉えています。

もう一つ、技術界隈全体で大きく変わってきていると感じるのが、AIの登場です。
これまでは、人がコードを書くことに力を注ぎ、その中で得られた知見をカンファレンスやブログを通じて共有するという流れが、エンジニアリングの文化の中心にありました。
しかし、AIの登場によって、その意味合いは少しずつ変わってきていると感じます。
自分で一つひとつ情報収集をしなくても、AIに一次情報の整理を任せられるようになってきており、情報収集や共有のあり方そのものが、これから変化していくのではないかと考えています。

手でコードを書くことよりも、AIに書かせることが主流になっていくと、今後はより「何を作るか」という部分にフォーカスが移っていくはずです。
現在は言語やフレームワークごとに細分化されたコミュニティが多く存在していますが、AIの浸透にともなって、エンジニアに求められるものやコミュニティのあり方も、これからは違った形に変化していくのではないかという感覚があります。
実際、iOSDCの今年の発表応募を見ても、AIに関するテーマが目立って増えていました。
これからのエンジニアにとっては、「何を作るのか」という視点そのものが、これまで以上に重要になっていくはずです。

iOSDC Japan 2026 ウェブサイト
https://iosdc.jp/2026/

現状では、何を作るかという方針決めにおいて、企画担当がさまざまな調査を行いながら方向性を固めていくケースがまだ多くを占めています。
今後は、エンジニアと企画がより一体となって協力しながらプロダクトを作っていく体制を築いていきたいと考えています。

これまでは、担当する人によって品質にばらつきが出てしまう、という状況が少なからずありました。
今後は、誰が担当してもAIを活用しながら一定の品質を安定して担保できるような仕組みをつくっていくことに挑戦していきたいと考えています。

現状の課題、人、プロダクトという3つを、それぞれきちんと見ることができる人にぜひ来ていただきたいと思っています。
このうちどれか一つでも欠けてしまうと、組織はうまく回っていきません。

プロダクトが見えていなければ、何によって利益が生まれているのかを理解することもできません。
人を見ることができなければ、周囲からの信用を失うことにもつながります。
お互いに信頼し合いながら仕事を進め、事業として形にしていくためにも、この3つの視点はどれも欠かせないものだと考えています。