創業CTOが考える、アーリーステージの開発組織で起きる課題と開発体制の強化戦略

自己紹介

こんにちは、Mithra CTOの板垣亮太です。

94年生まれ神奈川県出身です。

2020年3月に横浜国立大学大学院を卒業し、2020年4月に共同創業でMithraを始めました。代表の工藤とは学部時代からの付き合いで、大学院の所属研究室の同期でもあります。工藤は学部時代から起業を志していて、今のMithraのビジョン(後述)のような考えを持っていました。私は、そんな工藤のビジョンに共感したことや、大きなチャレンジをしたいと思っていたこともあり工藤とともにMithraを立ち上げることを決めました。

大学院在籍中にエストニアでクラウドファンディング活動を行って刺激をもらったことも、起業に至った経緯の一つです。

(エストニア訪問時の様子)

今回の記事ではMithraの開発組織について紹介します。

Mithraの紹介

Mithraのビジョンは「あらゆる人が平等に正しく評価される社会の構築」です。個人の情報を個人が保有・活用することで、一人ひとりの能力がさらに発揮されたり、性格にマッチするような環境に身をおくことなどが今より容易になると思っています。そのように個人の情報を活用することで、一人ひとりがより良い人生を送ることを実現したいと考え、このようなビジョンを掲げています。

現在、上記のビジョンを基にパートナー企業と共同で総合オンライン医療支援プラットフォームの開発・提供を行っています。また、大学、士業業界、アパレル、不動産等多様な業界への大小様々なアプリケーション開発、EC構築、Web制作・提供等も行っています。

Mithraの開発組織について

Mithraには現在、代表の工藤と私以外に3名のエンジニア（東風谷、鈴木、加来）が在籍しています。

東風谷は2021年11月にMithraに参加しました。経験年数は1年ほど、フロントエンド・バックエンド両方に幅広く対応できるオールマイティなエンジニアです。

鈴木は2022年4月に入社しましたが、2020年5月頃からインターン生として参加していました。2年ほどの経験があり、Reactなどのフロントエンドを得意とし、WebGL系にも対応できます。

加来は鈴木と同じく2022年4月入社で、2021年5月頃からインターン活動をしていました。フロントエンドを主に担当しますが、その中でもReactなどのフレームワークのロジカルな部分を得意とします。

現在私は、プロジェクトにおけるチーム編成や技術選定など、開発チーム体制の整備をしています。私自身がプロジェクトに参画することもあり、その際は開発チームのマネジメント・サポートなどもしつつ、自ら開発をしています。また、ここ最近では、チーム向けに技術的な情報の共有や勉強会などを行っています。Zennで外部発信もしています。

Mithraでお客様のプロダクト開発をする際、私たちはお客様の要求に答えることに最大限力を注いでいます。

よく、要件定義に忠実に設計や開発を行った結果、お客様の要求に答えられないプロダクトができてしまうケースがあります。そのような事態を起こさないために、私たちはチームメンバーにお客様の要求を正しく理解し実現するよう求めています。

そのために、プロジェクトチームはなるべく小さく、そして個々人に大きな裁量を与える形を取っています。

プロジェクトの規模によって人数幅がありますが、基本的には前述の通り少数精鋭を意識しています。

例えば、小規模案件であればPM1名とエンジニア1名。大規模になってくると、PM1名とエンジニア3名（うちリーダー1名）というような体制を取ったりします。

また、単なるコーディングのみをするエンジニアは少なく、社内のほとんどのエンジニアは要件定義や設計の部分から関わっています。

このようにエンジニアに大きく裁量権を与えることで、柔軟な対応を可能にしています。

例えば、要件定義・設計時点で実現可能な想定だったものも、いざ開発を行ってみると技術的に実現困難だと判明することもよくあります。期限とスコープ、予算の関係で実現困難なことも多々あります。

そのようなことは現場のエンジニアしかわからないことでもあるので、現場のエンジニアの声に耳を傾け、必要に応じてプロジェクトの方向転換を測ります。

上記のようにチームがプロジェクトの柔軟なハンドリングを可能にするには、チーム内でのコミュニケーションが大事です。そのため、社内ミーティングを頻繁に行い、認識のすり合わせをしています。開発フェーズによりますが、平均的には週に3回はミーティングを行っています。

開発組織の現状の課題は、開発したプロダクトが属人的になってしまうことです。これは、チーム内での個々人の裁量権が大きいことの副作用だと思っています。アサインされたエンジニアが比較的自由に開発をするので、ソースコード等にその人の「癖」が残ったりします。

この癖は「保守性の悪さ」に繋がっています。

そのため、後にエンジニアを追加でアサインすることの妨げになったり、数ヶ月後の修正対応が不必要に難しくなったりしています。

柔軟性を実現するためにメンバー一人ひとりの力を強めた結果、ある側面で柔軟性が弱まってしまったと言えます。

上記の課題を解決し、より柔軟性を高めるために、現在エンジニアリングにおけるルール作りに注力しており、社内のエンジニア全員の会議で内容を決定し、文書に落とし込む作業を日々行っています。具体的な取り組みは開発ルール（命名規則や環境構築方法の整理など）、タスクチケットの切り方など多岐に渡ります。

柔軟性を求めるためにルールを決めることは変な話かもしれませんが、これは「縛るためのルール」ではなく、「導くためのルール」だと思っています。

今までの開発体制では、個人の能力や判断などに依存していましたが、このエンジニアリングルールはそのような依存から脱却させてくれるものです。

このエンジニアルールが完成したら、開発に関わるメンバーが皆、能力水準や判断力に関わらず、一定の品質のプロダクトを作り出せるようなチームに近づけると考えています。

(オフィスでの様子)

これからの目標

Mithraの開発文化の確立が目標です。既に文化はありますが、上記のルールをチームに浸透させることで、今までの文化をより良いものにしていきたいです。

ルールは作って終わりではなく、実際に運用されることが重要なので、作ったルールから即座に取り入れて実行し、チームに馴染ませることに注力しています。

先程も述べた通り、「導くためのルール」と位置付けた以上、新しいルールがメンバーを縛り付けるようなものであっては意味がありません。ルールをルールとして意識せず、「当たり前」のものとしてストレスなく実施できるようなものを作るべきだと思っています。

一旦チームでルールを決めた後、実施してみたら良くないルールだと気づくことも多々あります。一度作ったルールの見直しや変更もよくありますし、これからもあるはずです。そのように、開発フローに対してもPCDAを回し続け、ルールの「定着」と「アップデート」を両方継続させる必要があります。

チームの誰もが一定の品質のプロダクトを作り上げられるようになることが大きな目標ですが、そのためのマイルストーンとして開発文化の確立という小さな目標があります。その小さな目標は、上記のようなルール作りのPDCAを回し続けることで達成したいと思っています。

現在Mithraでは7人目の創業メンバーとして一緒に会社を成長させてくれるエンジニアを募集しています。記事を読んで少しでもご興味をお持ちいただけた方は、Wantedlyの「話を聞いてみたい」よりお気軽にご連絡ください。カジュアルにお話ししましょう！