開発組織を整える

この記事は2025 ZAICO アドベントカレンダーの18日目の記事です。

はじめに

はじめまして
ZAICOでVPoEをやっている安中です
ZAICOのミッションと可能性に、とてもワクワクして2025年の夏頃にJOINしました

鹿児島県に住んでまして、天気の良い日は桜島見ながら仕事してたりします
こちらインタビューなのでお時間ある方は是非

この記事では、
ZAICOの開発部の現状、取り組んでいる施策、今後の展望などを紹介させていただきます

VPoEとは

最初にVPoEという役割を少し説明させて下さい

一般的にはVPoEはエンジニアリング組織のマネジメント責任者と言われていますが
個人的には、
全エンジニアが迷わず、気持ちよく、全力で走れるように道を整備する役割と解釈しています

具体的には以下を担います

• エンジニアチームの採用・育成・評価
• 開発プロセスの最適化と生産性向上
• チーム間の連携とコミュニケーション促進
• エンジニアのキャリア開発支援
• 組織文化の醸成

エンジニアリング組織といえばCTOが有名です
CTOとの違いはこのように認識しています

役職	主な焦点
CTO	技術戦略・アーキテクチャ・技術的意思決定（技術そのもの）
VPoE	エンジニア組織のマネジメント・人材育成（人と組織）

CTOとはお互いの得意分野を活かして、背中合わせで戦っているイメージです

ZAICOの現在地

次にZAICOの開発部の現在地を見てみましょう

デファクトスタンダードな定義がある訳ではないのですが
スタートアップ企業の開発部の状態をステージ別に分けると
大体こんな感じかなと思います

スタートアップ開発部門のステージ別一覧

項目	シード期	アーリー期	グロース期	スケール期
チーム規模	1〜5名	5〜15名	15〜50名	50名以上
組織構造	フラット、兼務多数	役割分担が始まる	複数チーム体制	部門・事業部制
意思決定	創業者が即断	リーダに委譲開始	ミドル層が判断	階層的・ガバナンス重視
開発スタイル	スピード最優先	プロセス整備開始	標準化・自動化	プラットフォーム化
技術的負債	許容・蓄積	顕在化し始める	返済が急務に	計画的に管理
採用課題	人脈頼み	採用基準の策定	中途オンボーディング	新卒採用・育成体制
主な課題	PMF探索、属人化	暗黙知の形式化、役割曖昧	チーム分割、リード不足、品質と速度の両立	技術戦略、キャリアパス、内部統制
必要な専門職	なし（全員兼務）	インフラ担当	SRE、QA、セキュリティ	DX、プラットフォーム、CISO
ドキュメント	ほぼなし	最低限整備	体系化が必要	継続的メンテナンス
評価制度	なし	簡易的	等級・評価制度導入	複線型キャリアパス

ZAICOの開発部のメンバー数は20名程度
人数的にはアーリー期からグロース期へ転換を図っているフェーズ

個の集まりから、組織へと変化を遂げるタイミングと捉えています

これまで取り組んで来た事

次にこれまでの取り組みをご紹介します

情報収集

最初は一次情報に触れて解像度を上げることに務めました
具体的にはエンジニア全員と1on1をしました
みんなのこれまでのキャリア、Will、Can、現在の業務などを聞かせてもらいました
各チームミッション、現状もヒアリングして、定例MTGなどにも参加しました

これにより現状の大枠を捉える事ができ、改善に手を付けるメドが立ちました

暗黙知の言語化

これは少ない人数でやっている時には無くても成り立ちますが
人が増え、歴史を知らないメンバーが増えると齟齬が生まれるため、グロース期では必須です

以下は言語化した一例です

施策	内容
職務定義と行動指針	ZAICOにおける理想のエンジニアとはどのような姿なのか、 何をしたら理想のエンジニアになったと言えるのかを定義
権限管理	誰が、何を実行して良いのかの見える化
1on1の再定義	FB1on1、メンター1on1の目的をそれぞれ明文化
見積もりの定義	詳細・概算・超概算など、期待値と実施内容の乖離防止を目的に定義
その他にも細かい曖昧ルールの言語化	リリース時の品質定義、モバイルアプリのOSサポート更新における判断、外部セミナー参加時の勤怠扱いなど

これらのドキュメントの目的は全員が同じマインド、理解になることです
メンバー間で共通言語を持つことで業務上の様々な齟齬を減らしたり、行動に一貫性が生まれます
ドキュメント作成する際のポイントは、良い意味で読み手に解釈の余地を残さないことです
分からないと言った声や同じ質問を聞く機会は減ったように思います

ZAICOにおけるスタートアップマインドの言語化

直近ではEM合宿を行い
スタートアップ企業であるZAICOでエンジニアが働く上で共通で持つべきマインドの定義も行いました

マインドセット	説明
何でもやる（仕事にこだわらない）	職責や領域にこだわらず、必要なことは何でもやる精神を持つ
変化に柔軟である	状況が頻繁に変わるスタートアップの環境において、変化を楽しみ、柔軟に対応できる
ミッション/プロダクト共感し、情熱を持っている	自分が信じたミッション・プロダクトだからこそ、困難な局面でも踏ん張り、乗り越える力になる
声を上げる	リモートワークでは「言わなければ伝わらない」。疑問・意見・提案は遠慮せず発信する
責任感を持つ	任されたからには、最後まで責任を持つ

このマインドが全員で持ち続け、高い成果を上げたいと考えています
今後は採用基準などに適用を検討しており、標準化の推進していきます

組織構造、働き方の見直し

定義作成以外でこれまで取り組んだ施策の一部です

施策	課題	対応
既存リーダー職の職務見直し	担務範囲が広大になり、実現難易度が高くなりすぎていた	TechLead（技術）と Engineering Manager（マネジメント）を 新設し、分割委譲
チーム体制の見直し	多くのチームが組成され、兼務や少人数チームが多く作業量が分散していた	現状の優先度から判断し統廃合を実施
エンジニア可処分時間の増加	様々な業務がありメイン開発にかけられる時間が少なかった	開発部主導の施策を1つ1つ見直し停止・継続を判断、ワークフロー整備で再現性向上
メンター制度の導入	MTG以外で話す機会が少ない、悩みを相談できる人がいない	顧問の関口さんに担当いただき運用中
マネジメント研修	マネジメント力の強化	スタートアップ企業特化した形でのマネジメント研修の実施
バーチャルオフィス導入	気軽に相談できる場が少ない、チーム感が希薄	チーム単位で島を作って座り仲間意識を作り、リアルオフィスと同じように気軽に話しかける環境作り

効果について

• 役割毎に期待値を明文化した事で積極的に動ける人が現れました
  • TL中心に積極的に勉強会を開催
  • EMでマネジメントに関する発言が増えるなど
• 権限管理のおかげで各自が迷わず動けるようになりました
  • 新たに入社したメンバーへの説明コストも下がっています
• マネジメント研修でEM間に共通言語が生まれ、時間短縮、マネジメントの再現性が担保
• 部外への広がり
  • 開発部から始めたマネジメント研修は他部署も巻き込んで実施しています
  • バーチャルオフィスも全社導入

改善はまだまだ道半ばです
効果が出ている施策もあれば、まだ効果が十分ではない施策もあります

しっかりと効果を測り、より良い組織構造や働き方になるよう努めて行きます

これから目指したい世界について

最後にこれから目指したい開発部の未来を話したいと思います

究極的には「安中がいなくても回る開発部」を作りたいと思っています

それは全エンジニアが迷わず、気持ちよく、全力で走れる状態を指します
そのためにはまだまだ沢山の改善ポイントがあると思っています

• ルールが明確化されている
• 必要な情報が適切なタイミング届いている
• 適切なマインドを持つための機構がある
• 成長機会が与えられている
• 適切な評価が成されている
• 仕事にやりがいを感じられている
• これらをキープする能力と自浄作用を個人ではなく組織自体が持ち得ている
  などなど

これらを全部整える事ができ、
全エンジニアが迷わず、気持ちよく、全力で走れる状態になった時に
「あれ、安中最近何もしてないんじゃない？」「もういなくても大丈夫じゃない？」
という開発部になるのが私の夢です

その世界が来たら私が言うセリフは決まっています
「すいません！ 私にもコード書かせて下さい！ 開発チームに混ぜてください！！」

このセリフが早く言えるように、
より良い開発部へ進化させる事に尽力したいと思います

---

次回の担当は私の頼れる相方、CTOのfukataさんです。ぜひお楽しみに。