自律型エンジニア組織の作り方、「ロール」を定めて意思決定は一任

AIとクローリング技術で解析したWeb上の公開情報を基に、エンジニアのプロフィールを自動生成できるサービスを提供するLAPRAS。

ティール組織のフレームワークの1つとされる「ホラクラシー」をベースにした組織運営を行う同社が、エンジニア組織のマネジメントとコミュニケーションで心掛けているポイントを同社執行役員 CTOの興梠敬典氏に聞いた。

• LAPRAS 執行役員 CTO 興梠敬典氏

目指すのはチームが助け合い、一丸となれる環境

--組織のマネジメント方針を教えてください

興梠氏：当社では「ホラクラシー憲法」という組織運営上のルールを策定し、それに従ってマネジメントを行っています。「ホラクラシー」とは、個々のメンバーに意思決定権を委ねて目的達成を目指す「ティール組織」のフレームワークの1つです。

事業運営に必要な役割を「ロール」として切り出して、各ロールに人をアサインしていく点が特徴です。ホラクラシーでは、ロールの目的や責務とともに、ロールの担当者が有する権限も明文化します。

私は適切なロールを作り、そこにアサインするメンバーを決めます。CTOなのでプロダクトの技術面における最終責任を負っていますが、開発や運用、技術選定などにおける実際の意思決定は、ロールにアサインされた担当者に一任しています。

--わざわざ、ホラクラシーを採用する理由は？

興梠氏：理由は2つあります。1つはチームメンバーが同じ目標に向けて動きやすくするため、もう1つがチームをリードする人が目的を示しやすくするためです。

当社のようなスタートアップに限らず、自社でサービスやプロダクトを提供する企業にはやりたいことや課題がたくさんあります。例えば、ユーザーを増やす、運用上のエラーに対処する、顧客の疑問を解消できる仕組みを作る、運用しながら次の開発に備えるなどです。

エンジニア組織をマネジメントする立場としては、そうしたことをエンジニア自らに考えてほしいし、チーム一丸となって取り組んでほしい。しかし、チームで仕事をしていたとしても、課題や改善案がバラバラの状態で持ち込まれると結局は個人作業に陥ってしまい、お互いが助け合い、1つの目的のために動けません。

当社のホラクラシー組織では、1つのロールに複数人をアサインしたり、1人が複数のロールを担ったりします。そして、いくつかのロールを束ねたものをサークルと呼び、同じサークルに属す人たちが共通の目的を持って仕事に当たれるような環境を作っています。

• 「ホラクラシー組織」のロールとサークルの関係図。濃いブルーの円がロールで、薄いブルーがサークルとなり、サークルを内包するサークルもある。出所:LAPRASのホームページより抜粋

権限移譲が役割とミッションの説得力を増す

--部や課、チームやユニットなどに所属する、従来の組織運営と何が異なるのでしょう？

興梠氏：権限移譲がしっかりと行われることが大きな違いだと思います。例えば、エンジニアのパフォーマンスを高めるために良い給与制度を設計する「給与制度設定ロール」があるとしたら、「給与制度の最終決定権を有する」と明文化したうえで、「上司が口出しや変更を指示してはならない」と規定して、ロールの担当者が実際に決定を下せる環境を担保します。

そうすることで、ロールへのアサインは「あなたが達成すべきミッションはこれだ」というメッセージになり、同時にロールやサークルという区切りの説得力が増すので、メンバーは同じ方向を向きやすく、かつチームのリーダーは目的を示しやすくなります。

--ホラクラシー組織の実践は難しくないですか？　権限を委譲されるほうもプレッシャーが大きそうです

興梠氏：給与制度の例で言えば、「良い給与制度を作って、●●な状態をもたらしてくれ」とマネジメントが抽象的になるので、マネジメント層や経営陣にとっての合う・合わないはあると思います。

また、メンバーに自律性が求められる組織体系ですが、マネージャーからロールが勝手にアサインされて、そのロールを絶対にやらなければいけない、というわけではありません。当社では、任せたいロールとその先にある期待が重いようであれば調整します。「そのロールはやりたくない」「そのロールをやるなら、今まで担当していた●●のロールからは外れます」など、メンバーの意見を聞き、合意形成をしていきます。

--CTOとして、具体的にはどのようなことをしていますか？

興梠氏：適切なロール作りと、それぞれのロールを担う人が集中できる状態を作るための組織マネジメントやプロセスの最適化、ベースとなる体制構築を担っています。

ロールを作るうえでは、チームメンバーの自律や振り返りと学びを通じたスキルアップ、それらを通じたチームの自己組織化を促せる役割となるよう意識しています。具体的には、フロントエンド設計アーキテクト、データベースアーキテクト、スクラムマスターなどのロールがあり、技術選定や改善案作成、チームマネジメントなどはロールを持つ担当者に任せています。

CTOのとしてのミッションは、「自社の技術的優位性の構築」と捉えています。当社のプロダクトはまだ発展途上なので、技術的課題の解決やユーザーに直接価値を生む機能開発の優先度が高く、そのためのリソースの配分もCTOの仕事です。

例えば、１カ月先にある機能をリリースするために動いていたメンバーに、作業を一時停止して別のシステム改修に参加するよう指示することがあります。この時、業務の進捗が滞ってしまうのですが、「いまは●●に集中するため、この機能は一時的に諦める」とCTOとして宣言することで、作業を中断したメンバーの心理的安全性を担保するようにしています。

• 「他社にない特異な技術が利用されていることはもちろん、同じものを低コストでより良いクオリティで出せる。また、方向転換の必要があるときに素早く対応できるといった、エンジニアチームのケイパビリティも技術的優位性だと考えます」(興梠氏)

「背中の悪口」は言わず、自分ごと化する

--組織運営で大事にしていることはありますか？

興梠氏：個人的には、「背中の悪口を言わない」を心がけて仕事をしています。背中とは、所属チームの方を向いているときの後ろ側、つまり別チームやビジネスサイド、クライアントなどです。

エンジニアに限らず、「●●チームが無理言ってきてさ、しょうがないけど頼むよ」「クライアントが全然わかってなくて。納得してないんだけど、やらなきゃいけないからよろしく」など、外部への不満を交えつつ、自分のチームに仕事を依頼することは多々あると思います。しかし、そのようなコミュニケーションを取ってしまうと、チームメンバーは先入観を持って他のチームの行動を疑ったり、クライアントに不信感を抱えたりした状態で仕事をすることになり、組織全体のパフォーマンスの低下につながりかねません。

自分が所属する組織の外からの要望や依頼だとしても、自分の意思決定のつもりで仕事を依頼したり、情報を伝えたりすることが、組織全体の信頼の総量を増やすことにつながり、組織の円滑な運営につながると考えます。

--エンジニアの採用活動のポイントは？

興梠氏：応募者の方々への敬意を形で示すことは大事だと思います。貴重な時間を割いて面接や選考課題に取り組んでくれているので、当社の選考を通じて何かを得てほしいと考えており、採用・不採用に関わらず選考後は応募者の方々にフィードバックを行っています。

また、カジュアル面談や課題、グループインタビューなどを行う際に、評価ポイントや見るべき観点は明文化し、採用担当者全員で共有しています。

私はエンジニア採用のロールを担っていて、年間の採用数などの数値目標も課せられているうえ、CTOとして良い人材を採用したいという欲もあります。加えて、体調や心理的なコンディションも影響し、判断能力がブレることは常にあり得るので、ミスマッチ防止につながるような採用基準と判断のプロセスを明確にしています。

--今後、CTOとしてどのようなことに挑戦しようと考えていますか？

興梠氏：プロダクト開発の仮説検証に、エンジニアが関われる体制を作っていきたいです。

仮説検証は専門的な業務で、エンジニアリングの「正しいものを正しく作る」行為とは見るポイントや考え方も異なります。でも、だからといって完全に分業にしていたら、社内で開発していても受諾開発と大差なくなってしまう。

当社が提供するのはエンジニア向けのサービスなので、企画や検証後のアウトプットにもエンジニアの思考を持った人たちの知見を取り入れられるような、共創を実現したいです。そのためにも、メンバーの自律性と目標の共有は欠かせず、今後もより良いエンジニア組織の在り方を模索していきます。