ユニラボの事業は、基幹サービスである「アイミツ」をはじめとして、「アイミツSaaS」「アイミツCLOUD」など様々な受発注のニーズにあわせて多角化しています。その中で、お客様への最速の価値提供を行うためにはビジネスサイドとエンジニアサイドの連携が欠かせません。

ビジネスサイドのメンバーがお客様と関わり、プロダクトの改善案を考え、それをエンジニアに伝える。――そんな「社内受託」のような状態では、同じプロダクトを作り、ビジョン達成のために共に力を発揮するチームとしては不十分だとユニラボは考えます。

今回は、ユニラボエンジニアチームの佐藤さんに、ユニラボのエンジニア組織の課題と理想、今後についてインタビューしました。

課題に向き合い、見えてきたエンジニアチームの理想像

――組織のスピード感を向上させ、さらなる価値提供を行うため、ユニラボの組織は常に変化と進化を続けています。ユニラボのエンジニア組織が、より深くビジネス・プロダクトに入り込んでいくため、エンジニア組織の形態を変化させていく理由を教えて下さい。

プロダクトを中心とした組織・チーム体制を組むことで、よりお客様に最速で価値を届けられるようにするためです。

そもそも、一つのプロダクトを作っていく会社の中で、「エンジニア側」「ビジネス側」という言い方はおかしいんじゃないか、という疑問がありました。職能別の壁にとらわれること無く、プロダクトのことを一緒に考えてやっていく一つのチームになっていくことが必要だと思っています。

職能別組織で社内受発注のような関係の開発体制では、「エンジニアだから……ビジネスサイドだから……」という意識が生まれ、お互いに壁を作りがちになります。同じプロダクトを同じビジョンに向かって作っている仲間だと意識することで、これは自分の仕事ではない、という考えや無駄なやり取りをなくしていきたいと考えています。

――どのようなマインドのエンジニアがいると、理想に近づけるのですか？

「エンジニアだから開発しかしない」という考えをなくしていきたいんです。プロダクトを作っているメンバーとして、その中で開発のスキルがあるから開発をする、という考え方を全員がもて
るのが理想ですね。

ユニラボのエンジニアは、そもそも積極的に事業に関わっていくことに対してポジティブな人が多いと思っています。SIerやSESでお客様の定義したプロダクトを作ってきた経験を発展させ、事業会社の中でプロダクトの成長を一緒に考えて開発していきたい、という志向性を持った人は何人もいます。

ただ、「ビジネス側が決めたことを開発する」社内受発注の関係ではなく、一緒にプロダクトを作っていくということに意味があると考えているんです。

――既存のエンジニア組織の課題はどんなところにあったのでしょうか？

まず、ビジネスサイドからの要望があり、それをエンジニアサイドが実装していく、というスタイル自体に問題があったと考えています。

コンシェルジュチームなどの要望は、チケットでの管理を行っています。雑多に作られたチケットをエンジニアがチェックをして、事業部と優先順位をすり合わせながら開発をしていく、というスタイルです。ユニラボには現在WEBディレクターのようなポジションの方がいないので、チケットの内容をエンジニアが噛み砕いて実装していくのですが、それはただの「受託」。その改修を行うべき深い理由を話し合わずに着手するので、ビジネスサイドとエンジニアサイドの認識がずれてしまうことがありました。それによって、開発の質と量、クオリティが担保できないのが大きな問題でした。

現在は、各プロダクトにエンジニアが所属し、エンジニア同士もシステム部として連携と情報共有を行うことによって、「なぜその機能改修が必要なのか」、「本当に優先度が高いのはどれか」など、より根本の部分からエンジニアが入り込める状態を目指しています。

――開発だけでなく、事業をどう伸ばしていくか・プロダクトをどう改善していくかが大切になってくるんですね。ユニラボでは、事業視点を持ったエンジニアの育成に当たってどのような取り組みを行っていますか？

徐々にスクラムの導入を進めていますが、今後は本格的に移行していきたいと思っています。スクラムによって、以下のようなことを実現していきたいです。

・プロダクトバックログの見える化→プロダクトの開発優先度が見えることによってエンジニアであってもプロダクトの方向性を認識する
・プロダクトバックログで「誰の何を解決するために、なぜ作るのか」をフォーマット化することで、チームで共通認識を作る
・なぜ作るのかをエンジニアが理解することで、壮大な要件定義書は不要になる
・プロダクトバックログで仮説検証を回すことで、自分の開発しているプロダクトの結果を理解できるようになり、さらに次への改善ができるようになる。
・仮説検証で効果を測定するためには最低限の機能（MVP）をリリースすればよくて、なんでも開発してしまう「ビルドトラップ」を回避していくことができる

スクラムで開発を行うことで、「なぜこれを作るのか」をエンジニアが理解して進めていくことが大切なんです。ただ開発を行うだけでなく、事業視点を持っていないと開発が出来ない、持たざるを得ないという形が理想形です。エンジニアだから仕様を決めてくれたら作ります、というスタンスではなく、実際に開発して形にしなくてもできる仮説検証は行って、無駄な開発を省くという意図も在ります。

また、エンジニアそれぞれが事業を理解するために、コンシェルジュ業務を体験したり、営業の打ち合わせ同行なども行っています。

――スクラムの取り組みで、既に社内で始めていることがあれば教えて下さい。

アイミツのシステムリプレイスの中ではスクラムを行っています。アイミツは創業時からスピードを意識して開発を繰り返してきたので、まだ裏側でツギハギになりわかりにくい箇所が多くあります。それによって、機能追加をしたくてもなかなかスピード感を持って進められないという問題がありました。まずそこを整理して、シンプルな形に作り変えることによって開発速度を上げるためのプロジェクトです。そのプロジェクトの中では、すでにスクラムが始まっています。

今までもユニラボの中でスクラムを行おうという取り組みはあったようですが、上手くやりきれずはまらなかったこともあったようです。私は前職で経験があったので、その知見を取り入れつつスクラムにシフトしています。

開発の体制はまさに変わっていく、変わっていく最中です。いまのユニラボは、その変化の過程に主体性を持って携わることができる貴重な環境だと思います。

ビジョン達成のため、エンジニアができること

――体制が変わり、より「プロダクトを作る」意識を高めていくユニラボのエンジニア。これからどのような役割を担っていくのでしょうか。

これからはさらに、エンジニアだから……のように、職能に囚われた固定観念を捨てていく必要があります。受発注のインフラを作るために何ができるのか、同じバスに乗っている仲間として役割を超えた行動が求められていきます。

ユニラボのメンバーは、受発注のインフラを作るという会社のビジョンを達成するために集まった仲間です。エンジニアとして、開発ができるから開発をやることにはなります。しかし、言われた仕事をやるだけでなく、エンジニア一人ひとりがビジョン達成に向けて何ができるのか能動的に考えていけることが重要です。

アイミツ・アイミツCLOUD・アイミツSaaSの各プロダクトに横串で関わることで価値を発揮していく一方、エンジニアとしての技術を向上させていくために、社内エンジニア同士の連携は迚も重要です。プロダクトの目標と、エンジニアとしてどう成長していくかというキャリアビジョンを両方達成していくための組織づくりです。

――今後のユニラボのエンジニアが持つべきマインドについて教えて下さい。

プロダクトごとの横串の開発になることによって、「なぜこれを作るのか」に向き合う機会が増えるのは先程もお伝えしたとおりです。さらに、開発してリリースして終わり、ではなく、リリースしたあとの効果検証や結果を受けて次の開発につなげることを常に意識する必要が在ります。

アイミツSaaSにおいては、開発後の効果検証を行う取り組みを始めていますが、まだ会社全体に浸透はしていません。エンジニアであってもプロダクトの目標KPIを管理して、その中で開発を行っていくことでよりプロダクト志向の開発ができるように成っていきます。

先程スクラムのお話もしましたが、スクラムはあくまでも手段です。目的は社内受発注感の解消であり、エンジニアがプロダクトを意識して開発を行っていくことです。一つのプロダクトを作るチームとして組むことで、最終的には「顧客に最短で価値あるプロダクトを届けること」「会社のビジョンを最短で達成すること」が目的です。

現在、ユニラボの「テックコンパス」を鋭意製作中です。ビジョンを達成するために、エンジニアはどのようなことを考えて行動していくのかというのを具体的に行動例として落とし込んでいます。

――テックコンパスについてもう少し詳しく教えて下さい。どのように活用されていくものなのですか？

ユニラボでは、「まっすぐ」というコンパス（バリュー）がとても大切にされています。顧客にまっすぐ向き合う、チーム全員にまっすぐ向き合う、なすべきことにまっすぐ向き合う。この価値観をユニラボで働くエンジニアが体現できるよう具体的に言語化したものです。

テックコンパスは、今後エンジニアの採用基準や、評価基準として活用されていきます。ユニラボの存在理由は「受発注を変革するインフラを創る」というビジョンの達成です。ユニラボで働くに当たって、ビジョン達成に最短ルートとなる方法を取ることがすべての判断の基準であるはずです。そのために必要なことを、具体的な行動例にまで落とし込んでいます。

――今後の方向性を踏まえて、いまユニラボに必要なエンジニアはどのようなスキルと志向性を持った方なのでしょうか。

スキルが高い人はもちろん重要です。ただ、スキルだけが高く、技術だけをやりたいという人は今のユニラボのフェーズには合わないと思います。今まさに組織をより良くするための変化が起きているタイミング、だからこそ、ビジョンやミッションにちゃんと共感できる人が必要です。

なによりも、ビジョンに共感し、その上でプロダクトに向き合っていけるかどうか。これから作られていくよりよいエンジニア組織のために、まっすぐ考えられる人と一緒に働いていきたいです。

アイミツのシステムリプレイスが完了したあとは、より一層プロダクトを中心とした組織になっていきます。アイミツ・アイミツCLOUD・アイミツSaaSの3プロダクト間で連携を強化し、様々な角度から受発注の体験を変えるサービスを作り上げるため、エンジニア組織もアップデートを続けていきたいです。