M.D.

大学の頃、私は個人的にプログラミングを学び始めました。知識として理解するより、手を動かして何かが動く瞬間のほうが面白くて、自然と没頭していった感覚があります。

その延長で、まずは個人でやってみて、自分の力がどこまで通用するのか確かめたいと思いました。大学院卒業後は知人の事業に携わる形でキャリアをスタートし、個人事業主として学習プラットフォームの構築に関わりました。画面の挙動が変わったり、使い勝手が良くなったりするたびに、自分の手で前に進められる手触りがありました。

その後、私は正社員としてECサイト運用に関わる会社に入り、フロントエンド開発から担当しました。マーケティングやセールス施策を形にするLP制作、既存機能の改善、営業向けのBtoBシステム開発など、扱う領域は幅広かったです。個人で動いていた頃に比べてシステム規模が大きく、関わる人も増える分、やりがいはありました。

一方で、簡単なリリースでも準備や調整が必要になり、スピード感が一気に重くなる瞬間もありました。実装だけで完結せず、前提を揃え、段取りを組み、関係者と認識を合わせながら進める必要がある。正社員として働く中で、そうした“進め方”も含めて身につけていきました。

前職は、手を挙げればチャレンジを任せてもらえる環境でした。その中で私は、日々の定型作業を仕組みで解決していきたいという思いを強くしていきました。「誰でもできる仕事」を減らして、人がより価値のある仕事に向かえるようにしたい——その思いがずっとありました。

頑張って手を動かしても、仕組みが変わらない限り、同じ場所に戻ってしまう感覚があったんです。だから、効率化の体制が整っていて、改善が当たり前に進む環境を探し始めました。

AICEを知ったきっかけは、知人からの紹介でした。ちょうど転職だけでなく、副業として関われる場も含めて探していたタイミングです。

前職では、顧客の声を開発側が直接拾える体制ではなく、他部門が集めた意見が開発に流れてくる形でした。私は、顧客の声を自分の手で拾い、自ら改善につなげるという距離感で仕事がしたいと思っていました。AICEの話を聞いたとき、「一度関わってみたい」という興味がはっきりしたのは、その違いが分かりやすかったからだと思います。

業務委託として、副業の範囲でAICEの仕事に関わっていました。限られた稼働のなかでも、「ここなら続けられる」という手応えは早くからありました。

裁量が大きく、UIの改善や裏側の処理の効率化など、必要だと思った手をすぐに打てる。さらに、相談したことが“置き去り”にならずに、どんどん前に進んでいくテンポ感がありました。やりたいことが形になっていく速度が、求めていたものと重なっていたのだと思います。

大きかったのは、社風が自分に合っていると感じたことです。人が優しく、相談や議論が前に進む空気がありました。加えて、改善のための提案が現場で止まらず、実現に向けて動かせる裁量がありました。

最後は、同じプロジェクトで一緒に働いていたPMから「一緒に働きたい」と強く勧められたことが背中を押しました。自分の仕事への向き合い方がチームの中で伝わっていたと実感できたのは、素直に嬉しかったです。

若い会社に正社員として入ることへの迷いはありましたが、社内のメンバーに相談する中で、ここで成長に向き合うイメージが固まりました。業務委託ではなく当事者として中に入り、改善を進める側に立つ決断が、そこで現実味を帯びました。

現在は、公共性の高い領域のプロジェクトと、保険・金融領域のチャットボット開発に関わっています。案件によっては、社外の関係者と週次で打ち合わせを行い、進捗の報告や質問への対応を担う場面もあります。

私の役割は、アプリケーションを作る実装だけではありません。仕様を整理して仕様書に落とし、関係者の認識を揃えるところまで含まれます。プロジェクトの性質上、曖昧さを残したまま進めると手戻りが起こりやすい。だから私は、仕様を言語化して揃える工程を大事にしています。実装が走れる状態に整えるために、迷いを減らすのが私の役割です。

最近まで関わっていた大手製造業の案件は、データを整理して可視化し、そこから改善点を見つける仕事が中心でした。難しかったのは、技術そのものよりも、専門領域が違う人たちと「同じ言葉を同じ意味で使う」ことです。

たとえば、エンジニアとして当たり前に使うツールや手順が、データ系の人にはまったく馴染みがないことがあります。そこで私は、相手の前提に合わせて説明の粒度を変え、前提を揃えることに時間を使いました。逆に、相手が当たり前にしている考え方はチームに持ち帰って共有し、自分の理解も更新していきました。衝突を避けるというより、前提を揃える作業を先にやったほうが、結果的に進みが速くなると実感しました。

私が意識しているのは、単位時間あたりのアウトプットを増やすことです。完璧に整えてから出すより、まずは7割でも叩き台を出してみる。分からない点があれば抱え込まず、早めに質問して前提を揃えます。

このやり方は「雑に出す」という意味ではありません。叩き台を早く出して、前に進む材料をつくるためのものです。動かしながら精度を上げたほうが、関係者の認識も揃いやすく、改善も回りやすい。私はその進め方で、仕事を前に押し出しています。

入社してまず驚いたのは、想像以上にみんなが楽しそうに働いていたことです。入社前はリモート中心の環境だと、どうしても温度感が見えにくく、淡々とタスクをこなしている雰囲気なのかなと思っていました。

でも実際は、開発や改善の話題が自然に飛び交い、前向きな空気がありました。仕事の面白さが、そのまま表情や会話のトーンに出ている。皆が心から仕事を楽しんでいるように見えて、私はそのギャップに良い意味で拍子抜けしました。

AICEらしさを感じるのは、技術的な議論が日常的に動いていて、発言が流れないことです。Slackのチャンネル内でも技術的な議論が常に動いていて、私が投げた一言に反応がすぐ返ってくる。そのスピード感が、まず大きいと感じます。

また、勉強会が多く、学ぶことが特別なイベントではなく仕事と地続きになっているのも特徴です。勉強会で出た話題がそのままチャンネルで議論になり、実務の改善案として転がっていくこともあります。そうした積み重ねが、結果として仕事の質を底上げしている実感があります。

採用プロセスも印象的でした。私はコーディングテストなどを想定して準備していましたが、実際は雑談ベースの面談が中心で、短い時間の中でも安心感がありました。そこで感じた風通しの良さは、入社後のコミュニケーションの速さや、相談のしやすさにもつながっていると思います。

これから目指したいのは、技術を積み上げるだけではなく、顧客の課題解決にフォーカスできるエンジニアです。課題の整理から実装までが分断されると、どうしても改善の速度が落ちてしまいます。私は、現場に近い場所で状況を掴み、必要な打ち手をその場で組み立てて動かす。そこまで含めて価値を出せる人になりたいと思っています。

イメージは、お客様の現場に深く入り込んで伴走するコンサルティングに近いスタイルです。作ること自体を目的にせず、解決まで責任を持って動けるエンジニアでありたいと思っています。

AICEの中では、「この人に任せたら実装が早い」と思われる存在になりたいです。ここでいう早さは、雑に進めることではなく、前提を揃え、迷いを減らし、必要なものを最短で形にする力だと捉えています。

また、特定の業界に固定するよりも、新しい領域でもすぐキャッチアップして立ち上がれる対応力を磨きたい。任せた仕事が前に進む安心感を、チームの中で増やしていきたいです。

もし今の仕事に、少しでも「このままでいいのかな」という引っかかりがあるなら、そこから目を逸らさないほうがいいと思います。理由は、人間関係でも、お金でも、働き方でも何でも。大事なのは、現状を受け入れるのではなく、更新したいと思えるかどうかです。

高橋さんの言葉を借りるなら、「目に熱がこもっている」人。熱量を持って、自分で状況を動かそうとする人は、環境の使い方がうまいし、伸びるのも早い。

もう一つ、一緒に働きたいのはコミュニケーションを大切にできる人です。オンラインだと目的の会話だけで終わりがちですが、ミーティングの中で少し雑談ができる余白があると、信頼も意思決定も前に進む。

「変えたい」を持っているなら、次にやることはシンプルで、動くことだけです。