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を位置づけています。現実的なコストで、業務にフィットしたシステムを作れる選択肢を提供したいですね。

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

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

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

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

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

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

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