技術を学び続けたいと思っていても、その熱量を周囲と共有できるとは限らない。

エンジニアとしてキャリアを重ねるなかで、「もっと技術に向き合いたい」と考えてきた山本さん。2022年にアクティアへ入社し、現在は特定のお客様の若手エンジニアを対象とした研修プロジェクトでリーダーを務めるほか、Webアプリケーションの保守も担当しています。 

入社後は開発プロジェクトを経て、現在はエンジニアを育成する研修プロジェクトという新たな領域にも挑戦し、自身の可能性を広げています。アクティアでのやりがいや、研修業務を通じた学び、技術を語り合える仲間の存在、今後のキャリア展望について伺いました。

「もっと技術に向き合いたい」。DDDとの出会いから、アクティアへ

―山本さんのこれまでのキャリアを教えてください。

大学では情報系を専攻し、Javaなどのプログラミングを学んでいました。卒業後はSES企業に入社しましたが、最初に配属されたのは、比較的古い言語や開発環境を扱うプロジェクトでした。

もともとプログラミングが好きで、よりモダンな技術に触れたいという思いがあったものの、希望する環境に移る機会がないまま、経験を重ねていました。その後、勤めていた会社が買収され、より規模の大きなSIerになったことを機に、自分の志向との違いを感じ、別のSES企業へ転職しました。

転職先ではJava開発に携われることを期待していましたが、エンジニアとしての経験年数を重ねていたこともあり、管理寄りの役割を担うことが多かったです。そのため、自分で手を動かす機会は次第に減り、「もっと技術そのものに向き合える環境で働きたい」という思いが強くなっていったんです。

―アクティアを知ったきっかけは何だったのでしょうか？

前職にいた頃、増田亨さんの著書を通じて、DDD（ドメイン駆動設計）に触れたことがきっかけです。その考え方に「これはすごい。自分もやってみたい」と強く惹かれました。

その後、増田さんのオンラインセミナーに参加するなかで、アクティアとCOOの高崎さんの存在を知りました。ちょうどJava開発者の募集を見つけて、「ここならご縁があるかも」と思い、面談を申し込んだのが始まりです。

―入社の決め手を教えてください。

一番大きかったのは、技術に関心を持つ人が多く、設計について深く考えられる環境だと感じたことです。

それまでの職場でも技術への関心は持ち続けていましたが、周囲と共有する機会はあまりありませんでした。アクティアであれば、技術を語り合える人たちと働きながら、自分が追求したい設計や開発に向き合える。そう思えたことが、入社の決め手になりました。

開発業務を経て、研修・保守という新たな役割への挑戦

―入社後は、どのような業務を担当しましたか？

入社後はまず、「CRAFT BLOCKS」の開発に携わりました。業務の内容が日本語で表現されたコードや、独自の設計が印象的でしたね。これまで学んできたDDDの考え方が、実際の開発にどのように生かされているのかを間近で見ることができ、「アクティアに入社したんだ」と実感しました。

―現在の研修業務には、どのような経緯で携わることになったのでしょうか？ 

「CRAFT BLOCKS」の開発プロジェクトに携わった後、現在の研修チームに加わることになりました。これまで開発中心のキャリアだったため、エンジニアを育成する領域は私にとって新たな挑戦でしたね。

現在は、特定のお客様のエンジニアを対象とした研修プロジェクトで、6名のメンバーをまとめるリーダーを務めています。研修は若手向けが中心で、研修全体の約7割を占める新人研修のほか、配属後研修や若手の中途入社者向け研修も担当しています。

また、Webアプリケーションの保守プロジェクトにも一部参画しています。保守の対象は、特定のお客様の社内で利用されるアプリケーションと、一般に公開され、エンドユーザーが利用するアプリケーションですね。

―研修業務では、どのようなやりがいを感じていますか？

新人研修は1年で終わりではなく、その後も2年目、3年目と続いていきます。新人研修を担当した受講者が成長し、今度はトレーナー側として戻ってくることもあるんです。

再会したときに「こんなに成長したんだ」と思うと、情が移ってしまうというか（笑）。その先も見届けたいという気持ちが生まれて、研修チームでの仕事に大きなやりがいを感じています。

―教えることは、山本さん自身の成長にもつながっていますか？

新人研修では、何も知らない状態の受講者に、プログラミングだけでなく「システム開発とは何か」というところから伝えなければなりません。

そのためには、データベースやインフラ、フロントエンド、開発手法、テスト、モデリングなど、システム開発に関わる幅広い知識が必要です。教えるために一つひとつ準備することで、私自身の知識も叩き直されているような感覚があります。

―アクティアで長く働き続けたいと思う理由は何でしょうか？

プログラムを書くことや設計することに対して、これほど高い熱量で取り組んでいる会社はなかなかないと感じているからです。「そうした熱量を持った会社や人に出会える機会は貴重だな」と。

どんな役割であっても、「アクティアの人たちと一緒に働き、刺激を受け続ける」という環境が、自分には合っていると感じています。

技術が好きでも浮かなくていい。語り合える仲間がいる環境

―アクティアに入社して、技術に向き合う文化をどのように感じていますか？

以前の職場では、開発手法やプログラミングについて話しても、周囲にはなかなか伝わりませんでした。勉強や資格取得に取り組んでいても、「どうしてそこまでやるの？」という目で見られることもあったんです。

一方、アクティアでは、技術に強い関心を持っていることが特別ではありません。技術が好きな人たちが集まっているので、自分だけが浮いているような感覚がない。それが、居心地のよさにつながっていると思います。

―技術について語り合う機会も多いのでしょうか？

アクティアのSlackには、社員だけでなくパートナーの方々も参加しています。公開されているチャンネルで技術について話すことも多く、新しい技術の情報や、最近ではAIに関する議論も活発ですね。

「こんな技術が出た」「勉強してみたけれどうまくいかなかった」と投稿すると、誰かしらが反応してくれるんです。技術の話をしても、ドン引きされないのがうれしいですね（笑）。

―携われる技術領域にも、アクティアならではの特徴がありますか？

規模の大きな会社では、開発、インフラ、データベースと、担当が細かく分かれていることも多いと思います。一方、アクティアでは、一人ひとりが幅広い領域に関わる機会があります。

私自身も、これまで所属したチームでAWSの設定やLinuxのコマンド操作などを経験できました。興味がある人にとっては、自分で手を動かしながらさまざまな知識を身につけられる環境だと思います。

もちろん、環境があれば自然にすべてを学べるわけではありません。業務と並行して自分で勉強する時間をつくり、手を動かし続ける必要があります。ただ、私自身はそれを苦に感じていませんし、学び続けることを楽しめる人には、アクティアは合う会社だと思います。

役割にとらわれず、お客様への価値を起点に。システム全体を見渡せるエンジニアを目指して

―一方で、Webアプリケーションの保守では、どのような難しさを感じていますか？

難しいと感じるのは、お客様とのコミュニケーションです。お客様は必ずしも技術に詳しい方ばかりではないので、「なぜこうなっているのか」「どうしてすぐに対応できないのか」といった、利用者としての率直な疑問をいただくことがあります。

開発する側にとっては当たり前だと思っていたことでも、利用する方にとってはそうではありません。お客様の言葉の背景にどのような思いや要望があるのかを理解し、どう説明すれば伝わるのかを考えることに、難しさを感じています。

―現在の仕事に向き合ううえで、意識していることはありますか？

自分から動くことです。特に現在担当しているWebアプリケーションの保守プロジェクトは少人数のチームなので、誰かが動くのを待っていては、仕事が進みません。リーダーとして、まずは自分が動くことを心がけています。

「シニアアプリケーション開発者だから」「リーダーだから」と、役割に追い立てられている感覚はあまりありません。お客様に価値を提供するために、自分にできることをやる。その意識のほうが強いですね。

―研修や保守で得た経験を、今後のキャリアにどうつなげていきたいですか？

研修を通じて身につけている幅広い知識が自分の中でもっと育っていけば、依頼された開発作業に対応するだけでなく、お客様との対話の仕方も変わってくると思っています。

さまざまな技術領域を俯瞰しながらシステム全体を捉え、将来的にはアーキテクチャの設計にも携われるエンジニアを目指していきたいです。

―最後に、アクティアに興味を持っている方へメッセージをお願いします。

今の職場で技術の話ができず、周囲との温度差や疎外感に苦しさを感じている方には、ぜひアクティアを知ってほしいです。

技術について一緒に話したいですし、その方がどのようなことを学び、考えてきたのかも聞かせてもらいたいですね。私自身も、そこからさらに勉強していきたいと思っています。

・・・

技術を深めながら、自分の可能性も広げていきたい。

山本さんの話から見えてきたのは、アクティアには、役割を越えて学び続けられる環境と、技術について遠慮なく語り合える文化があるということです。

仲間と刺激し合いながら、自分らしいキャリアを描いていきたい。そんなエンジニアが前向きに成長できる環境が、アクティアにはあります。

ぜひ一度、あなたとアクティアが交わる未来について話してみませんか？

アクティアでは、顧客と伴走しながら価値を共創する「ラボ型開発」を数多く手掛けています。

ラボ型開発とは、仕様が固まっていない段階から専任チームが顧客に入り込み、要件定義から設計・開発・改善までを継続的に担う開発スタイルです。一般的な受託開発のように「仕様書をもらって作って納品する」のではなく、顧客のビジネス課題そのものと向き合い続けることが特徴です。

今回お話を伺ったのは、 受発注管理プラットフォーム開発を担当するチームのエンジニアリングマネージャーの高崎さん、テクニカルアドバイザーの山崎さん、シニアアプリケーション開発者の小林さんです。

一次請けだからこそ味わえる顧客との距離の近さ、自社チームだからこそ実現できる開発体験、そしてアクティアならではの「プロフェッショナル・ホワイト」の考え方について語っていただきました。

―担当しているプロジェクトについて教えてください。

高崎さん：受発注業務で利用される取引情報連携プラットフォームの開発を行っています。サーバーサイド開発や全体アーキテクチャ、システム基盤の構築まで当社で担っており、私はエンジニアリングマネージャーとして、顧客折衝や要件調整、プロジェクト全体の推進を担当しています。 

山崎さん：私はテクニカルアドバイザーとして、全体アーキテクチャの設計やインフラチームとの連携、技術方針の策定などを担当しています。 

小林さん：私はシニアアプリケーション開発者として、チームリーダーの立場でタスク管理やスケジュール調整、仕様確認などと共に設計、実装やテストを行っています。

ー一次請け・ラボ型開発ならではの面白さは何でしょうか？

高崎さん：やはり顧客から直接フィードバックをいただけることですね。自分たちが提案した内容に対して、その場で反応をもらえるので、開発の手応えがあります。
間に何社も入る環境だと、自分たちの仕事がどう評価されたのか分かりづらいことがありますが、当社の場合は違います。顧客の課題を理解し、一緒に解決策を考えていく。そのプロセス自体に大きな価値を感じています。 

山崎さん：一次請けでない場合、上位会社の判断を経由するため、現場の意見がそのまま届かないこともあります。
一方でアクティアでは、お客様と直接対話できるため、自分たちの提案をその場で議論できます。
顧客との信頼関係ができるほど提案もしやすくなりますし、自分たちが本当に価値を提供できている感覚があります。

小林さん：実際に自分たちのアイデアが採用され、システム構成や設計に反映された時は大きな達成感があります。
トラブル対応の場面でも、お客様から「一緒に解決してほしい」と頼られることが多いんです。
単なる開発ベンダーではなく、同じチームの一員として見てもらえている感覚がありますね。

ー3人の役割はどのように連携しているのでしょうか？

山崎さん：アクティアにはジョブディスクリプション制度があり、それぞれの役割や期待値が明確になっています。そのため、自分が何を担うべきかを全員が理解した状態でプロジェクトに参加できます。私は技術面から全体最適を考える立場なので、特にアーキテクチャやインフラとの整合性を意識しています。 

小林さん：私の役割はチーム全体を円滑に動かすことです。メンバーそれぞれの得意分野や特性を把握しながらタスクを調整しています。誰がどんな強みを持っているかを理解しているからこそ、チーム全体のパフォーマンスを最大化できると思っています。 

高崎さん：このプロジェクトは1年以上継続していることもあって、お互いの役割への理解もしっかり深まっていますね。
メンバー一人ひとりに対して期待していることを定期的に共有しているので、自然と自分の立ち位置や責任範囲も見えてきます。
それぞれが専門性を発揮しながら連携することで、高い成果につながっていると考えています。

ーアクティアらしい文化について教えてください ！

小林さん：このプロジェクトでは、定期的にモブ会という自分が担当した機能や課題、新しい技術調査の内容などを共有する場があります。
そのモブ会では、テーマごとに得意な人がファシリテーションを担当しています。
役職や年次ではなく、そのテーマに詳しい人が中心になる文化があると思いますね。

山崎さん：モブ会などでアウトプットすることで知識が定着しますし、周囲も理解を深められます。結果として、チーム全体の技術レベルや業務理解の底上げにも繋がっていると思います。

高崎さん：モブ会は知識共有はもちろんですが、人を知る場にもなっています。
誰が何に詳しいのか、どんな考え方をするのかが見えてくるので、プロジェクト運営もしやすくなる副次的な効果がありますね。

ープロフェッショナル・ホワイトという働き方はチームにどんな影響を与えていますか？ 

高崎さん：20時以降の原則作業禁止やフレックス制度は単なる福利厚生ではなく、高品質な開発を実現するための仕組みだと考えています。
目の前のタスクに追われ続けている状態では、長期的な視点で仕様や設計を考えることはできませんからね。

小林さん：運用や保守まで見据えて設計できるのは、時間的な余裕があるからです。
もし常に納期ギリギリで動いていたら、モブ会のような知識共有の時間も取れないと思います。結果的に、短期的には早く見えても中長期的には非効率になってしまうのではないでしょうか。

山崎さん：時間の制約があるからこそ計画的に進める文化が根付くという側面もあると思っています。力技で解決するのではなく、本質的な改善を考えるようになるんです。その積み重ねが品質につながっていると思います。 

ーその環境がエンジニアとしての成長に与える影響は大きいですか？ 

山崎さん：大きいですね。
業務に追われていると、新しい技術を調べる余裕がなくなります。アクティアでは仕事が終わった後にもエネルギーが残っているので、気になる技術を深く調べたり、検証したりする時間を確保できます。

小林さん：単に用語を知るだけではなく、「なぜ使われるのか」「どんな場面で有効なのか」まで理解する時間が持てます。その積み重ねが、将来を見据えた設計や提案につながっていると思います。

高崎さん：マネージャーとしては、メンバーが疲弊せず自律的に動ける状態をつくることも仕事のひとつだと思っています。プロフェッショナル・ホワイトはその土台になっていますね。短期的な成果だけではなく、エンジニアとしての成長まで考えた働き方ができるのは大きな魅力だと思います。 

ーアクティアに興味を持っているエンジニアへメッセージをお願いします ！

高崎さん：アクティアでは、それぞれの役割が明確に定義されています。
その基準があるからこそ、自分がどう動くべきかを意識しつつ、自分の強みを発揮しながらチームに貢献できるような環境があります。
個の技術力を伸ばしながらも、組織として連動し、価値を提供していきたい方には打ってつけの会社だと思います。

山崎さん：アクティアのプロジェクトは、顧客と直接向き合うことが多いので責任も大きいですが、その分、自分の意見や提案が反映される面白さがあります。
そういった環境を求めている方にジョイン頂きたいですね。

小林さん：一次請けであるからこそ、単にシステムを作るだけではなく、顧客にとっての最大価値を考え続けることが求められます。楽な仕事ではありませんが、その分だけ成長できますし、大きなやりがいがあります。
顧客のビジネスを理解し、自社チームの仲間と議論を重ねながら価値を創っていきたい――そんなエンジニアにとって、アクティアはきっと面白い環境だと思います。

役割は違えど、3人に共通していたのは「単にシステムを作るのではなく、顧客のビジネスに向き合うプロとしての意識」でした。
それを支えるのが、ラボ型開発という形態であり、プロフェッショナル・ホワイトという働き方です。
仕組みと文化が揃っているからこそ、エンジニアが本来の力を発揮できる――アクティアが大切にしていることのひとつです。 

是非一度、あなたとアクティアが交わる未来についてお話しましょう！ 

マネジメント増加で技術と向き合う時間が減るというエンジニア共通の課題を前に、キャリアの転機を迎えた山崎さん。

エンジニア歴19年の彼が、技術のスペシャリストとしてアクティアを選んだ理由と、現在の組織を支えるやりがいに迫ります。

SES・受託開発の現場で13年。技術選定の裁量を求めたキャリアの転換

――まずはこれまでのキャリアについて教えてください。

エンジニアとしては今年で19年目になります。

前職ではSESや受託開発を中心とした会社で約13年間勤務し、システムエンジニアとしてさまざまな案件に携わってきました。主任職も経験し、開発だけでなくチーム運営やプロジェクト推進にも関わっていました。

転機になったのは35〜36歳頃です。前職の会社が買収される出来事がありました。それから数年が経ち、改めてキャリアを見つめ直す中で、転職を意識するようになりました。

そんなタイミングで、以前から技術コミュニティや勉強会を通じて交流のあった高崎から声をかけてもらい、アクティアについて詳しく話を聞く機会がありました。

――入社の決め手は何だったのでしょうか？

一番大きかったのは、自分たちで技術を選び、設計を考えられる環境があったことです。前職では、上位会社が決めたアーキテクチャやルールに沿って開発を進めることがほとんどでした。

もちろん、その中でも技術力は磨けます。ただ、どれだけ経験を積んでも、自分たちの考えをシステムに反映できる場面は限られていました。その点、アクティアでは顧客と直接向き合いながら、技術選定や設計にも深く関わることができます。

エンジニアとして主体的にものづくりに携われる環境だと感じたことが、入社の大きな決め手でした。

技術で組織を支える。「テクニカルアドバイザー」の役割

――現在の業務内容について教えてください。

プロジェクトマネージャーのように人を管理する立場ではなく、技術面からプロジェクトを支援する役割を担っています。

また、全社で利用する共通ライブラリの開発や技術相談への対応など、組織横断での支援も行っています。

――どのような相談や業務が寄せられるのでしょうか？

具体的には、プロジェクトに配属される形でインフラや技術面のタスクを直接担うこともあれば、個別に相談を受けることもあります。

相談内容は、共通ライブラリの活用方法や、「調査したいが何から手を付けるべきか」といった方向性まで多岐にわたります。

最近は生成AIの活用も進んでいますが、自社のシステム構成や顧客の事情を踏まえた判断については、どうしても「現場のエンジニア」に聞きたいというニーズが根強くあります。AIが提示できるのはあくまで一般論までだからです。

また、全社的な技術発信も重要な役割です。
会社の技術方針や、自社ライブラリに関する情報の共有はもちろん、昨今はAIにより脆弱性が見つかるケースも増えているため、そうした情報を精査・通知し、組織全体の安全性を高めるような動きも行っています。

技術好きにはたまらない。学びがそのまま現場で活きる環境

――仕事の面白さはどこにありますか？

学んだことをすぐに実践できることですね。

新しい技術や設計手法を調査し、「こういう形で活用できるのではないか」と考えたことを、実際のプロジェクトで検証できる環境があります。

その結果、パフォーマンスが改善された、保守性が向上した、開発効率が上がった、といった成果が見えるのは非常に面白いです。

また、そのためには基礎力が欠かせません。
アクティアではDDD（ドメイン駆動設計）をはじめ、設計の本質的な考え方を大切にしています。流行りの技術を追いかけるだけではなく、応用の土台となる基礎を重視する文化がありますね。

元請けだからこそ実現できる「自分たちの思想で創る開発」

――元請け開発ならではの魅力は何でしょうか？

顧客にとって本当に必要なものを、自分たちで考えながら作れることです。与えられた仕様を実装するだけではなく、課題の整理から技術選定まで主体的に関われます。責任も大きくなりますが、その分だけ手応えも大きいですね。

自分たちが選択した技術や設計によってシステムが形になっていく感覚は、一次請けだからこそ味わえるものだと思います。

――チーム開発において特徴的な文化はありますか？

アクティアはリモートワーク中心ですが、コミュニケーションは非常に活発です。

ovice（バーチャルオフィス）を活用していることもあり、「少し相談したい」「この仕様について意見を聞きたい」という時に自然と人が集まります。会議のために集まるというより、議論が必要だから自然と集まる感覚ですね。

顧客理解や業務理解を深める上でも、この文化は非常に大きな価値を持っていると思います。

技術者として成長し続けるための働き方

――20時以降の作業原則禁止という制度についてはどう感じていますか？

技術者にとって非常に良い環境だと思います。 技術者として成長し続けるためには、仕事以外の学習時間も必要です。毎日遅くまで働いていると、新しい技術を学んだり、自分で試したりする時間はなかなか確保できません。

テクニカルアドバイザーという立場上、継続的なインプットは欠かせません。その時間をしっかり確保できることは、技術者として長く成長し続ける上で大きな価値があると感じています。

技術を極めたいエンジニアへ

――最後に、転職を考えているエンジニアへメッセージをお願いします。

アクティアは、自分が納得できる技術的な提案をしっかり発信できる会社です。年次や役職ではなく、提案の中身で評価される文化があります。

ただ、周りもエンジニアなので、中途半端な提案は通りません。
だからこそ、しっかりと深く考える必要があり、それが仕事の面白さでもあります。

また、私が担っているテクニカルアドバイザーというポジションは、マネジメント経験も活かせます。技術的に正しいかどうかだけでなく、プロジェクトの事情を考慮した、現場のリアリティがある提案ができることが重要だからです。

私たちと一緒に、技術を追求する面白さを共有できる仲間との出会いを楽しみにしています。

アクティアには、エンジニアが長く技術と向き合い続けるための仕組みがあります。

技術選定から関われる一次請け開発。 DDDを軸にした設計文化。チームで議論しながら成長できる環境。そして、学び続ける時間を守る働き方。

技術を軸にキャリアを築きたい方にとって、「テクニカルアドバイザー」という選択肢はもちろん、その先のキャリアパスも用意されています。

「技術者として、もう一段高いステージに挑戦したい」

そう考えている方は、ぜひ一度アクティアの話を聞いてみてください。

設計に向き合い、技術を語る環境で、エンジニアの視座はどう変わるのか。

SES・受託開発を経てアクティアに入社した田中さん。

ドメイン駆動設計やチーム開発、そして柔軟な働き方の中で得たリアルな成長を語っていただきました。

受け身の開発から、“背景を考えるエンジニア”へ

ー現在の業務内容と、これまでのキャリアについて教えてください。

現在は、参画しているアプリケーションの保守と、新システムへのデータ移行を担当しています。

これまでのキャリアとしては、最初は二次請け・三次請けが中心のシステム会社で開発をしていました。その後SESの会社に移り、さまざまな現場を経験した後にアクティアへ入社し、現在で8年目になります。

以前は、与えられたタスクをこなすことが中心で、「このシステムがどういう背景で作られているのか」まで深く考える機会はあまりありませんでした。
アクティアに入ってからは、設計や背景を含めて考える機会が増え、その点は大きく変わったと感じています。
アクティアは設計が好きな人が多く集まっているな、と感じることが多いですね。

ーアクティアに入社した決め手は何だったのでしょうか？

当時は子どもが保育園に通っていたこともあり、まずは働き方を重視していました。残業が多い環境だと、長く続けるのが難しいと感じていたためです。

その一方で、「技術力をしっかり伸ばしたい」という思いもありました。
二次請け・三次請けではなく、より上流から関われる環境や、自社プロダクトに関われる会社を探していました。

その両方が実現できそうだと感じたのがアクティアでした。
実際に入社してみて、働きやすさと技術成長のバランスが非常に良い環境だと感じています。

ー実際に働いてみて感じる、アクティアの「技術文化」はありますか？

設計や技術について話すのが好きな人が多いので、自然とそういった会話が日常的にあります。

印象的なのは、あえて「すぐに答えを教えてくれない」ことですね。分からないことを聞いても、「どう思う？」と返されることが多いです。

最初は正直大変でした（笑）。でも、自分で考える時間があるからこそ理解が深まりますし、その上で議論すると納得感も全然違うんです。
また、本当に分からないと感じていることに関しては、嚙み砕いてイチから教えていただけるので勉強になります。

受け身ではなく、自分の頭で設計する、アクティアではそれが当たり前の環境です。

「動くコード」ではなく、「伝わる設計」を追求する。議論と共有が前提の開発環境。

ー開発において、どんなことを大切にしていますか？

アクティアに入って大きく変わったのは、「動けばいい」ではなく「分かりやすいかどうか」を意識するようになったことです。
ドメイン駆動設計（DDD）の考え方も積極的に取り入れながら、保守しやすいか、意図が伝わるか、誰が見ても理解できるか、という視点で設計や実装を考えるようになりました。
「みんなが読んで分かるコード」を目指す、というのはチームとして共通している意識だと思います。最初はDDDの理解も難しかったですが、実務や議論を通して少しずつ身についてきました。

ーお客様との関わり方にはどんな特徴がありますか？

前職と比べて一番違うのは、顧客との距離の近さです。
これまでは、間にいくつかの会社が入っていて、要件もある程度固まった状態で降りてくることが多かったのですが、今はエンドユーザーと直接やり取りする機会もあります。
「なぜその機能が必要なのか」「どんな業務の中で使われるのか」といった背景から理解できるので、ただ作るだけではなく、どう実現するのが最適かを考えるところから関われるようになりました。要望をそのまま形にするだけでなく、「こうした方がより使いやすいのではないか」といった提案もできるので、開発者でありながらサービスづくりに関わっている実感があります。

その分、責任も大きいですが、「自分がこのサービスを作っている」という手応えはすごく強いですね。

実際にリリース後、ユーザーの方から「前より使いやすくなった」「業務が楽になった」といった声を直接いただけることもあって、その瞬間は本当にやっていてよかったと感じます。
単なる“納品”ではなく、価値を届けられている実感があるのは、この環境ならではだと思います。

ーチームでの開発やナレッジ共有について教えてください。

基本的には「気軽に聞ける」環境があります。
ちょっとしたことでも相談しやすいですし、必要であれば時間を取ってしっかり教えてもらえることもあります。
最近はAIもコードのチェックや読みやすさの改善に活用していますが、最終的には人同士のレビューや議論が重要なので、そのバランスがちょうどいいなと感じています。

実装だけで終わらない、“全工程に関わる”手応え

ーアクティアでの成長をどう感じていますか？

急激に何かが変わったというよりは、実務を通して着実に成長できている感覚があります。

以前はコードを書いて渡すだけで終わっていましたが、今はデプロイやリリース、インフラ周りまで自分で関われるようになりました。
「このシステムが動いているのは自分が関わったからだ」という実感が持てるようになったのは、SESの頃とは全然違う感覚です。ドメイン駆動設計も、最初は正直よく分からなかったですが、議論を重ねるうちに少しずつ腑に落ちてきました。

ー田中さんのアクティアでの働き方を教えてください。

現在は長野に住んでおり、フルリモートで働いています。

入社当初は出社していましたが、社内でリモートワークの実績ができたこともあり、移住後もそのまま働き続けることができています。仕事上の不都合はほとんど感じていません。

また、20時以降の作業が許可制となっている点も特徴的です。
長時間労働が前提にならないため、自然と計画的に業務を進める習慣が身につきましたし、自己学習の時間も確保しやすくなっています。

育児と両立している自分にとっても非常にありがたい制度です。

ー最後に、アクティアが気になっている方に向けてメッセージをお願いします！

技術をしっかり深めたい人、設計を突き詰めたい人にはすごく合うと思います。
「これをやりたい」と手を挙げれば任せてもらえますし、 逆に無理せず自分のペースで成長したい人も受け入れてくれる環境です。

働き方に制約があっても、ちゃんと成長できる。そういう環境を探している人には、ぜひ一度アクティアへのジョインを検討してほしいと思います。

技術を深めながら、働き方も大切にしたい。
どちらも諦めずにキャリアを築くことは、決して簡単ではありません。

しかしアクティアには、“考える文化”と“支える仕組み”の両方が揃っています。

自分のペースで、でも確実に前に進みたい。そんなエンジニアにとって、最適な環境がアクティアにはあります。
是非一度、あなたとアクティアが交わる未来についてお話しましょう！

今回は、表計算感覚でアプリケーションを誰でも簡単に開発できるクラウドサービス『CRAFT BLOCKS』の開発に携わる3名に、その現場のリアルを聞きました。

経験は積み重なる――受託で磨いた力が、プロダクトで活きる

ーまずは自己紹介と、現在の役割について教えてください。

横田さん：CRAFT BLOCKSチームでエンジニアリングマネージャーをしています。主にチームマネジメントや、プロダクトオーナーと開発メンバーの間に立って、プロジェクト全体を推進する役割です。アクティアに入社してからは6年ほどになりますね。
単に進捗を見るだけでなく、「どうすればこのプロダクトがより良くなるか」という視点を意識しながら技術・組織の両面から関わっています。

冨田さん：シニアアプリケーション開発者として、要件定義から設計、テスト設計、そして運用保守まで幅広く担当しています。アクティアに入社してからは8年ほどで、これまで様々な案件に携わってきましたが、その経験が今のプロダクト開発にも活きていると感じています。

Aさん：アプリケーション開発者として、主に実装を担当しています。入社して3〜4年ほどで、現在は実装だけでなく、技術調査や設計にも関わらせてもらっています。
以前よりも「なぜこの設計なのか」を考える機会が増えていて、かなり成長実感のあるフェーズですね。

ー受託とプロダクト開発、それぞれの経験はどう活きていますか？

横田さん：正直、本質的にはそこまで大きな違いはないと感じています。どちらも「やりたいことをどう実現するか」を考える仕事なので、あるプロジェクトで得た知見が、別のプロジェクトでそのまま活きることは多いですね。

冨田さん：その中でも、アクティアのプロダクトならではの特徴は「技術検証にしっかり時間を使っていること」だと思っています。
受託案件だとどうしても納期や制約がある中での最適解になりますが、CRAFT BLOCKSでは一歩踏み込んだ技術選定や検証ができることができますからね。
その結果として、「検証→知見化→他PJへ転用」という流れが自然に生まれていて、組織全体の技術力底上げにも繋がっていると感じています。

Aさん：実際に、いろんなパターンを調べたり試したりする機会が多いです。“検証できるプロジェクト”という位置づけになっているので、単なる開発ではなく、技術的な引き出しを増やす場になっていると思います。

「アクティアらしさ」が詰まったプロダクトーー標準を崩すことで、見えてくるもの

ー『CRAFT BLOCKS』はどんなプロジェクトですか？

横田さん：このプロジェクトは「SI企業が作るプロダクト」というより、「アクティアらしさが詰まったプロダクト」だと思っています。
プロダクトオーナー自身が技術に強いこだわりを持っているので、普通の現場ではやらないようなチャレンジも積極的にやります。

冨田さん：社内でこれまでやってきた“標準的なやり方”をあえて崩して、新しい方法を試すことも多いですね。データの持ち方ひとつ取っても、「本当にこれがベストなのか？」を常に問い直している感じです。

Aさん：最初は「なんでここまでやるんだろう？」って思うこともありました（笑）。でも今は、設計の意図や背景まで考える経験ができているので、すごく成長につながっていると感じています。

ー完成がないプロダクト開発の難しさはどこにありますか？

横田さん：やはり「終わりがないこと」そのものですね。
リリースして終わりではなく、そこから改善が続いていくので、技術的負債が積み上がるリスクもありますし、思った通りにいかないことも多いです。
EMとしては、プロダクトオーナーの意図を正しく理解して、それをチームにどう伝えるか。その“翻訳”の難しさはかなり感じています。

冨田さん：継続開発ならではの難しさとしては、知識の蓄積と継承ですね。
プロダクトは時間とともに複雑になっていくので、「誰が何を知っているか」が属人化しやすい。だからこそ、ドキュメントや履歴の管理を最初からしっかり設計しておかないと、後から入る人がかなり苦労することになります。

Aさん：実際に後から入った立場としては、キャッチアップはかなり大変でした（笑）。ただその分、いろんな設計思想や技術に触れられるので、学びの量はすごく多いです。正直に言うと、今は「必死に食らいついている」という感覚です。それくらいレベルの高いことをやっているなと感じています。

ー設計や品質において、妥協したくないポイントは？

冨田さん：一番大きいのは、「アクティアが創るプロダクトである」という点ですね。社長の技術的な知見やこだわりがかなり強く、それがそのままプロダクトに反映されています。
正直、外から見たら「なんでここまでやるの？」と思われるレベルだと思います（笑）。
各プロジェクトに共通するやり方もありつつ、「あえて違うやり方を試す」こともある。
そうやって変化を生み続けているのが、アクティアらしさだと思いますね。

横田さん：最初からかなり先のことまで想定して設計するケースも多いですよね。普通のプロジェクトだとそこまでやらないような領域まで踏み込んでいます。ただ、自社プロダクトだからこそ、何度か作り直す前提でチャレンジできる。
それが結果的に、技術的なレベルの高さに繋がっていると思います。

Aさん：「良い意味で遊び場」という感覚を持つメンバーも多いと思います。
もちろん真剣にやっているんですが、通常のやり方に縛られず、新しいやり方を試せる余白があるからこそ、スタンダードを自分たちで更新していくような感覚があります。

個人の知見が、チームの改善になる。

ー最近の技術的な議論や工夫について教えてください。

冨田さん：ドメインモデルにはかなり強くこだわっています。
最近だと、イベントソーシングと組み合わせた際に、モデルの一貫性をどう担保するかをチームで議論しながら設計しました。最終的にはインターフェース設計まで含めて作り切り、チームに展開しています。

横田さん：テストの部分でも大きな改善がありました。
以前は影響範囲が広くて、テストケースが膨大になってしまっていたんです。そこを、チームで集まったタイミングでホワイトボードに書き出しながら議論し、大幅にスリム化することができました。

Aさん：あの時はメンバーそれぞれから色々な提案が出ましたよね。私も一部提案させていただいたこともありましたが、最終的には冨田さんがそれらのアイデアを一つに集約して、網羅性を担保しつつもパターンを最適化したテスト計画を策定してくれました。

冨田さん：各々の知見を突き合わせた結果、理論ベースでパターンを絞り込めたのは大きかったです。

Aさん：実際にテスト工程の負担がぐっと軽くなったと聞いています。こうした「個人でインプットしたことや知見がきっかけとなり、チーム全体で最適解を導き出していく」サイクルが自然に回っているのは、このチームの面白さだと思います。

ー受託と自社開発、共通する本質は何だと思いますか？

横田さん：やはり「POが実現したいことを形にする」という点に尽きると思います。それがクライアントなのか、自社内にいるのかの違いだけで、本質は変わらないですね。

冨田さん：技術スタックが何かよりも、「どんな課題を解決したいのか」が重要ですよね。
そのためにどんな手段を取るかを考えるのがエンジニアリングだと思います。

Aさん：自社開発の方が自由度は高いですが、その分難しさもある。ただ、やっていることの本質自体は同じだと感じています。

 "ギア"として機能するということ。 距離より大事なのは、チーム設計。

ーチームとしての連携について教えてください

横田さん：最初は正直、うまく回っていなかった部分もありました。自分がPOとメンバーの間に立つ“ギア”として機能しきれていなかったんです。

冨田さん：確かに横田さんが大変そうなタイミングはありましたね。そのシーンでは私が色々と決めていく部分を巻き取れるように意識していました。横田さんが全体の責任を持ってくれているので、自分は技術的な意思決定に集中できていた側面もあったと思っています。

Aさん：自分も冨田さんが手が届いていないところを埋めるような動きを意識していましたね。それぞれが役割を理解して動いているからこそ、お互い自分がどう動くべきかを考えつつ、連携を取っていると思います。

ーリモート環境での開発についてはどうですか？

冨田さん：正直、リモートだから難しいと感じたことは全くないです。もうそれが当たり前なので、特に意識していないですね。

横田さん：コミュニケーションも、ツールを使えばすぐ取れる環境がありますし、全メンバーが困ることはほとんどないと感じていると思います。役割が明確で、やるべきことが整理されているので、リモートでも問題なく回っていますよ。

Aさん：必要なときにすぐ相談できる環境があるので、距離はあまり感じないですね。環境よりも「どういうチーム設計になっているか」の方が大事だと思います。

最後にーー技術を楽しめる場所、アクティア。

ーこの記事を読んでいる方へメッセージをお願いします！

横田さん：アクティアの環境は技術が楽しくて、好奇心が旺盛な人にはたまらない場所だと思いますよ。

冨田さん：技術選定ひとつとっても、「本当にこれがベストか？」を問い続けられる環境です。深く技術に向き合いたい人には、ここは居心地がいいと思いますよ。

Aさん：正直まだ食らいついている最中ですが（笑）、それくらいレベルの高いことをやっている実感があります。試行錯誤を楽しめる人なら、絶対に面白いと思います！

技術を手段として、課題解決の核心へ。
『CRAFT BLOCKS』の開発現場には、「試行錯誤を楽しむ」という純粋なカルチャーがあります。

完成がないからこそ難しく、終わりがないからこそ面白い。
自律した個（ギア）がそれぞれの役割を果たし、チームで連動して価値を生み出す。

「もっと設計の本質に向き合いたい」「技術を使って、本当の課題を解決したい」
そんな想いを持つあなたにとって、ここはきっと心地よい場所になるはずです。
まずはお話から始めませんか？

エンジニアが疲弊することなく、高い生産性を発揮し続けるにはどうすればいいのか。
どのIT企業も直面するそんな問いに対しても、会社自体をシステムとして捉え、そのパフォーマンスを上げることを考え抜いていく。そういった、どこまでも技術屋としての経営を体現しているのがアクティアです。

今回は、CEOの大島とCOOの高崎に、そんな会社の思想から制度設計、そしてプロダクトの未来までを伺いました。

現場・教育・炎上案件…すべての経験が“会社をつくる理由”になった

ーまずはお二人のこれまでのキャリアについて教えてください

大島：新卒では、Javaの教育を行う会社でインストラクターをしていました。その後、実際の開発現場に出たいという思いから転職し、エンジニアとして経験を積みました。

その中で「もっと自分たちの理想とする開発環境をつくりたい」という想いが強くなり、現在の会社を立ち上げました。

高崎：父がエンジニアだったこともあり、幼い頃からPCに触れる環境で育ちました 。キャリアのスタートはSIerでの開発現場です 。

その後、技術をより体系的に学ぶためにインストラクター職を経験しました 。現場を経験してから「教える立場」で学びを深め、その知見を持って再び開発現場へ戻りマネジメントに携わるようになったという経緯があります 。

その中で強く印象に残っている大変な想いをした、いわゆる炎上案件があります。

新しいことに挑戦しようとしたものの、指揮命令系統の問題など、プロジェクトマネジメントの課題が露呈し、チームが疲弊してしまった経験をしました。
「こういう現場をなくしたい」と強く思うようになり、自分の理想とする環境を整えたいと考えるようになりました。

そんな時に、同じような考えを持つ大島と話すきっかけがあり、意気投合したことからアクティアにジョインしました。

“役割を果たす存在＝アクター”という考え方から生まれた社名

ー「アクティア」という社名にはどんな意味が込められているのでしょうか？

大島：アクティアという名前には、「組織・従業員・顧客」という3つの層（Tier）を活性化させるという意味を込めています。

もともと「アクト」という名前でやっていたこともあり、「Actor＝役割を担う存在」という考え方がベースにありますね。

高崎：それぞれの立場で、自分の役割をしっかり果たすことが大事だと考えています。
会社そのものも一つの“システム”として捉えていて、個人に依存しない仕組みをつくることを意識しています。

ーアクティアの組織観について教えてください

高崎：社内ではよく歯車という意味の“ギア”という言葉が使われますが、私たちはそれをポジティブに捉えています。同じ形の歯車ではなく、一人ひとりが異なる形をした“ギア”です。
「役割を明確にすること」を重要視し、感情や属人的な判断ではなく、役割ベースで組織を設計しています。

大島：その不揃いなギアがうまく噛み合うことで、1＋1が3にも4にもなる。
個人の能力に依存するのではなく、組み合わせによって価値を最大化する組織を目指しています。

ージョブディスクリプション制度を採用している理由は何でしょうか？

高崎：従来の評価制度は、どうしても主観が入ってしまうと思っています。
評価する人によって基準が微妙にズレたり、タイミングや関係性によって見え方が変わってしまったりする。そういったブレが、組織運営においては“ノイズ”になると感じることも多々あり…。
特にエンジニアの仕事は短期的な成果だけでは測りきれない部分も多いので、「評価すること」自体が難しいという前提もあると思っています。
理想で言えば、野球の打率のように、誰が見ても納得できる形で成果を可視化できる状態が望ましいんですが、まだそこまでは到達できていません。

だからこそ今は、「評価する」というよりも、「自然と周囲から認められる状態」をつくることを大事にしています。

大島：実際、評価制度を運用していると「評価のための評価」になってしまうケースも多いんですよね。
本来は価値を出すための仕事なのに、評価シートを埋めることが目的になってしまったり、マネージャー側の負担が大きくなってしまったりする。

それであれば、最初から「役割を明確に定義して、その役割を果たしているかどうか」で判断する方がシンプルで合理的だと考えました。報酬についても年齢や年次ではなく、あくまで役割ベースで決めています。

周囲から見て、「この人に任せたい」「このポジションを担ってほしい」と自然に思われる人が、次の役割に上がっていく。トップダウンで評価して引き上げるというよりも、組織の中での納得感や信頼の積み重ねによってポジションが決まっていくイメージですね。

まだ発展途上の仕組みではありますが、できるだけ主観に頼らず、それでいて人の価値がきちんと報われるような組織をつくっていきたいと考えています。

経費も売上もオープンに。“経営もひとつのロール”という考え方

ー従業員との向き合い方で大切にしていることを教えてください。

大島：徹底した透明性ですね。

経費はすべて公開していますし、営業データも基本的にオープンです。誰でも会社の状況を客観的に把握できるようにしています。

高崎：経営陣も一つの“ロール”なので、特別な存在ではありません。従業員のために機能するのが経営の役割だと考えています。

ーアクティアの働き方の特徴について教えてください。

高崎：リモートワークやフレックスは、かなり早い段階から導入していました。きっかけは、遠方に住むメンバーが帰省する際などの、精神的な負担を減らしたかったからです。

例えば実家が遠い場合、移動だけで往復の休日が終わってしまい、リフレッシュどころか逆に疲弊して戻ってくるようなケースがあります。それでは本末転倒ですよね。「場所に縛られずに働ける状態」があれば、余裕を持って大切な時間を過ごせますし、それが結果的に、仕事に向き合う際のパフォーマンスの最大化につながる。そんな考え方がスタートでした。

大島：実際に運用してみると、移動時間の削減だけでなく、働き方そのものの質が大きく変わったと感じています。通勤がなくなることで、時間の使い方に余裕が生まれますし、それがそのまま生産性の向上にもつながっている。
加えて、それぞれが自分にとって最適な環境で働けるようになったことで、パフォーマンスの安定性も上がった印象がありますね。

現在はフルリモートに近い働き方をしているメンバーもいますが 、私たちはコミュニケーションの質を非常に重視しています。オンラインの効率性は活かしつつも、チームの一体感やプロジェクトの状況に応じて、オフライン（出社）での対面コミュニケーションを柔軟に使い分ける方針です。

「どこで働くか」は手段であり、目的はあくまでチームとしての成果を最大化すること。ですから、対面での議論が必要な局面ではしっかりと集まるなど、状況に合わせた最適なワークスタイルを選択することを大切にしています。

ー20時以降の作業制限の意図は？

高崎：一番の目的は、無駄な残業をなくすことです。
時間に制約があることで、「どうすれば限られた時間の中で成果を出せるか」を自然と考えるようになるんですよね。逆に、時間が無制限だと、どこかで“時間で解決する”思考になってしまうことも多いと感じています。

このルールは、単に労働時間を減らすためのものではなくて、生産性の高い働き方にシフトするための仕組みだと考えています。
20時以降の作業を許可制にしているのもポイントで、「本当にその作業は今やる必要があるのか？」「明日に回せないのか？」と、一度立ち止まって考えるプロセスを入れています。

マネージャー側としても、承認を通じてチームの状態を把握できるので、無理がかかっている箇所やボトルネックに気づきやすくなるんですよね。

大島：もう一つ大きいのは、「構造的な問題を可視化する」という意味合いです。
例えば、優秀な人が残業しないとプロジェクトが回らない状態って、個人の努力でなんとかしているだけで、本質的には健全ではないですよね。
そういう状況を放置せずに、
  ・そもそもタスク量が適切なのか
  ・進め方に無駄がないか
  ・役割分担に偏りがないか
  といった部分を見直すきっかけにしています。

あとは、エンジニアの成長という観点でも、この制度は重要だと思っています。
仕事の時間だけでスキルが伸びるわけではないので、学習やインプットに使える時間をしっかり確保することも、長期的なパフォーマンスには欠かせません。“長く働くこと”ではなく、“価値を出し続けられる状態をつくること”が大事だと考えています。

Javaという核と、CRAFT BLOCKSが描く次の成長曲線

ーアクティアがJavaにこだわる理由について教えてください。

高崎：シンプルに言うと、「自分たちが一番理解している技術」だからです。

私自身が、エンジニアとして分からないものを提供することに強い違和感を感じています。技術選定の段階から、きちんと判断できること。何か問題が起きたときに、自分たちで責任を持って解決できること。そこをすごく大事にしています。
その点で、Javaは長く向き合ってきた言語でもありますし、チーム全体としても知見が蓄積されています。だからこそ、品質にも責任を持てると考えています。

大島：もう一つは、組織としての戦い方ですね。技術を広げすぎると、一人ひとりの強みは分散してしまいますし、ナレッジも分断されてしまいます。
一方で、技術をある程度統一していれば、チーム内で知見を共有しやすくなりますし、教育の効率も上がる。結果として、組織全体の生産性が高まります。

アクティアとしては、「何でもできる会社」ではなく、「この領域なら確実に価値を出せる会社」でありたい。その“技術の核”が、今はJavaだという位置づけです。

特に、私たちが取り組んでいるモデル駆動開発との相性も大きいですね。設計からプログラムを自動生成していくようなアプローチでは、構造の明確さが重要になります。その点で、静的型付け言語であるJavaは、バグの検知や品質担保の面でも優れていると考えています。

ー自社プロダクト「CRAFT BLOCKS」の今後の展望を聞かせて下さい。

大島：CRAFT BLOCKSは、モデル駆動開発の延長線上にあるローコードプラットフォームです。
これまでのシステム開発は、似たような機能でも毎回ゼロから作り直しているケースが多いんですよね。それを「部品」として切り出して、組み合わせることで、より効率的にシステムを構築できるようにしたいと考えています。

イメージとしては、“ソフトウェアを手組みできる状態”をつくること。開発の生産性を上げるだけでなく、設計の再現性や品質の均一化にもつながると考えています。

また、CRAFT BLOCKSは経営戦略としての位置づけも大きいです。
これまでの受託開発だけだと、どうしても労働集約的になりやすい側面がありました。プロダクトを持つことでストック型の収益をつくり、会社としての基盤を強くしていきたいと考えています。その基盤があることで、新しい技術への投資や採用・育成にもより踏み込めるようになる。CRAFT BLOCKSは、単なるプロダクトではなく、アクティアの未来を支える中核だと捉えています。

高崎：プロダクトの発想の背景にあるのは、「業務とシステムの距離を縮めたい」という想いです。特に中小企業では、今でもExcelやAccessで業務を回しているケースが多い一方で、フルスクラッチのシステム開発にはコストがかかりすぎるという課題があります。

そのギャップを埋める存在として、CRAFT BLOCKSを位置づけています。現実的なコストで、業務にフィットしたシステムを作れる選択肢を提供したいですね。

ーこれから加わるかもしれない、未来の仲間へメッセージをお願いします！

高崎：「炎上案件をなくしたい」という想いは、ずっと変わっていません。現場で実際に経験してきたからこそ分かるのですが、炎上って個人のスキルや努力だけが原因ではなくて、構造や進め方、設計の甘さなど、さまざまな要因が積み重なって起きてしまうものなんですよね。

だからこそ、気合いや根性で乗り切るのではなく、仕組みや技術で未然に防げる状態をつくりたいと考えています。
同じように、「もっと良い開発のあり方があるはずだ」と感じている方や、再現性のある開発・品質の高いものづくりにこだわりたい方とは、ぜひ一緒に挑戦していきたいですね。

大島：アクティアでは、一人ひとりが「役割」を持って組織に関わっています。

その役割を理解し、自分がどんな価値を発揮できるのかを考えながら動くことで、チームとしての力が最大化されていく。そんな組織を目指しています。
私たちがよく使う“ギア”という言葉も、まさにその考え方を表しています。一つひとつのギアは形も強みも違うけれど、それぞれが噛み合うことで、大きな力を生み出すことができる。

だからこそ、「自分の役割を果たすこと」にやりがいを感じられる方や、チームで価値を生み出すことに面白さを感じられる方と、一緒に会社をつくっていきたいと思っています。

まだまだこれからの組織だからこそ、関わり方の自由度も大きいですし、自分の意思次第でいくらでもチャレンジできる環境です。
ぜひ一緒に、より良い開発のあり方と組織をつくっていきましょう。

炎上案件をなくしたい。
その想いは決して理想論ではなく、技術選定や開発手法、制度設計、働き方のすべてに一貫して落とし込まれています。

だからこそ、ここで求められるのは「ただ与えられた役割をこなす人」ではなく、自分の役割を理解し、より良くするために考え続けられる人。

不揃いなギアが噛み合い、大きな価値を生み出していく組織の中で、自分自身の可能性も広げていきたい——そんな想いを持つ方にとって、アクティアはきっと面白い場所になるはずです。

少しでも気になった方は、ぜひ一度お話ししてみませんか？

大手SIerからスマホアプリ開発、そしてWEB開発へ——。常に「ユーザーに近い場所」を求めてキャリアを積んできた横田さん。現在はアクティアのEM（エンジニアリングマネージャー）として、技術とマネジメントの両立を実践しています。本記事では、その本音を伺いました。

「ユーザーに近い仕事がしたい」——その想いで選び続けたキャリア

ー横田さんのこれまでのキャリアを教えてください。

新卒で大手SIerに入社し、金融系のネットワークミドルウェア開発に携わっていました。
技術的にはやりがいのある領域でしたが、プロジェクトを重ねる中で「ユーザーとの距離」を強く感じるようになりました。自分が作っているものが誰にどう使われているのかが見えにくいと感じ、「もっとユーザーに近い場所で価値を届けたい」という想いが強くなっていきました。

その後、スマートフォンアプリ開発に転向し、ユーザーに近づいた実感はあったものの、キャリアが進むにつれて管理や見積もりといった業務が増えました。徐々に“ものづくり”から離れていく感覚があったことを強く覚えています。

そこで改めて「自分はどんなエンジニアでありたいのか」を考え、Web開発への挑戦を決意し、アクティアに入社しました。

ー現在の役割について教えてください。

入社当初はWeb開発の経験がなかったため、まずはいちエンジニアとしてキャッチアップするところからスタートしました。

そこから経験を積む中で、現在はエンジニアリングマネージャーとして複数のプロジェクトを担当しています。前職でもマネジメント業務を担当していたものの、複数のプロジェクトを担当するのは初めての経験だったので、プレッシャーを感じることもありましたが、期待してもらえているとやる気にもつながりました。

現在の業務はマネジメントが中心にはなりますが、技術との距離が遠くなった感覚はありませんね。むしろ「どの技術をどう使うか」「どう設計すれば成功するか」といった判断が求められる場面が多く、技術的な視点はこれまで以上に重要だと感じています。

ーマネジメントと技術のバランスはどう取っていますか？

マネジメントにも“技術”があると思っています。

細かい実装はメンバーに任せることも多いですが、アルゴリズムや設計の基礎理解があれば、全体の方向性を判断することは可能です。

そのうえで、プロジェクトとして最適な意思決定をすることが、自分の役割だと考えています。

ープロジェクト成功において大切にしていることは何ですか？

最も重要視しているのは、「設計の根本を外さないこと」です。

プロジェクトの初期段階で方向性を誤ってしまうと、その後どれだけ優れた実装を積み重ねても、結果はズレてしまいます。エンジニアとしては技術的に面白い方向に寄りがちですが、
マネージャーとしては一段上のレイヤーから「お客様にとって本当に価値があるか」を基準に判断する必要があります。

そのため、場合によっては最新技術ではなく、あえてシンプルな構成を選ぶこともあります。
重要なのは技術そのものではなく、「それによって何が実現できるか」だと思っています。

チームがチームであるために、リモート・フレックスだからこそ、コミュニケーションの質に拘る。

ーチームマネジメントで意識していることはありますか？

メンバーの自律性をどう引き出すか、という点を特に意識しています。

手を出しすぎると成長機会を奪ってしまう一方で、任せすぎると丸投げになってしまう。そのバランスを取るのはとても難しいと感じています。

その人のレベルや状況に応じて、「どう考えればいいか」「どこに向かうべきか」を示しながら、本人が自分の課題として捉えられるように関わることを大切にしています。
また、リモート環境でのコミュニケーションが多いため、メンバーの状態変化に気づきにくい側面もあります。だからこそ、日常的なコミュニケーションの“質”をより意識しながら、細かな変化も拾えるようにしています。

ーチームマネジメントにおいて、手応えを感じた瞬間はありますか？

印象的だったのは、自分がどうしても忙しくなり、プロジェクトに十分関われなかったときのことです。

本来であれば、私がマネージャーとしてフォローすべき場面でも、メンバーそれぞれが「誰がどの領域を得意としているか」を理解していて、自然と役割を補い合いながら問題を解決していました。気づいたときには、自分が不在でもプロジェクトがしっかり前に進んでいて、その光景を見て、「チームとして機能している」と強く実感しました。

ただ、本当の理想はピンチのときだけではなく、日常的にその状態が生まれることだと思っています。それぞれが自分の得意領域を理解し、主体的に動き、必要なところを自然に拾ってカバーし合う。そうした意識を持ったメンバーが揃っていること自体が、このチームの強みですし、その力をより日常的に発揮できる組織にしていきたいと考えています。

ー「20時以降の稼働の事前申請制」というルールは、マネージャーとしてチームの生産性を高める上でどう機能していますか？

この制度のメリットとして、まず大きいのは「ダラダラと仕事をしなくなる」という点です。時間に区切りがあることで、自然と集中力が高まり、生産性も上がると感じています。

また、際限なく働き続ける状態は、どうしても人を疲弊させてしまいます。そうした働き方を会社として是としていない、というメッセージが明確にあるのは大きいですね。ただ、この制度は単なる“制限”ではなく、プロとしての意識を問われる仕組みでもあると思っています。限られた時間の中で成果を出すために、自分で考えて動く必要があるからです。

かといって、何が何でも20時で強制終了されるような無機質なルールではありません。状況に応じて柔軟に判断できる余地もあり、「働きすぎを防ぎつつ、成果にも向き合う」というバランスが取れている制度だと感じています。

ー今後組織が拡大していく中でも拘り続けたいことは？

組織が大きくなっても、「作るものへのこだわり」と「技術を楽しむ文化」は失いたくないです。

ただ動けばいい、ではなく、より良いものを追求する姿勢があるからこそ、エンジニアとしての面白さがあると思っています。むしろ組織が拡大することで余裕が生まれ、新しい挑戦やアイデアが生まれやすくなる環境を作れたら良いなと思っています。

ー最後にメッセージをお願いします！

マネジメントに進むことに対して、「技術から離れてしまうのではないか」と不安を感じる方もいると思います。

ただ、今後は特に技術を“どう使うか”を判断する力は、より重要になります。

自分の技術力を使ってチーム全体の力を引き上げ、プロジェクトを成功に導く。
そのプロセスに面白さを感じられる方にとって、EMという役割は非常にやりがいのあるものだと思います。
技術も、マネジメントも、両方を楽しめるキャリアが叶う環境です。

誰にでも「初めて」があります。
その「初めて」をサポートする環境とチャレンジできる場がアクティアにはあります。
是非一度、あなたとアクティアが交わる未来についてお話しましょう！