「総務部付」から「事業部」へ 〜組織規模と人事、予算、KPI〜

「ぼっち開発」から「アジャイルチーム」に。規模と役割が変わると組織や予算はどう変わる？　筆者の経験をまとめた。

[林田幸一，あしたのチーム]

本コラムは2018年7月25日に掲載した「『総務部付』から『事業部』へ　〜組織規模と人事、予算、KPI〜」を再編集したものです。

　前回は私たちのチームがアジャイルな組織を目指して実施してきたことのうち、環境や道具の話を中心に紹介しました。今回は組織としての変革を中心に紹介していきます。

　3〜6年前、当時の社員は50人ほどで、そのうち開発メンバーは1〜3人ほどでした。組織としては、CTO兼開発リーダー1人と開発メンバー2人の3人体制で開発を行いました。ただし、50人以上のメンバーが集う組織の中のサービス開発チーム2〜3人となると、まだ部門としては独立しておらず、総務部や社長室など「毛色が違う部署」に所属することになります。

手探りの組織、内製化初期の「混乱期」

　これを、現場の技術者の目線で説明すると、「代表電話がじゃんじゃん鳴って落ち着かない席で黙々と開発を行う」という、集中力の鍛錬にはもってこいの環境で仕事をするという意味になります。そして、プログラミングなどの業務に関わらない人たちの近くにいることから、開発の利便性のために利用しているだけの「MacBook」を、物珍しそうに見られるという面白い現象も起こりました。

　さて、それではマネジメントはどうだったかというと、開発予算管理は通年予算ではなく「プロジェクト予算」扱いでした。もともとのプロジェクトに掛けられる予算が固定しているため、途中からの追加開発や急なトラブル対応などに対応する資金はほとんど持てませんでした。また、途中で新たに予算を確保すべく動いたとしても時間がかかってしまうことがほとんどです。

　このころの人事制度は決してエンジニア向けの評価制度ではなく、所属部署や管理系職種と同じ評価軸しかありませんでした。一部門として独立する前の状況では仕方がないことではありますが、勤務体系も全社一律のルールに準拠するため「スーツ着用」という、最近のWebサービス提供企業のエンジニアとしてはなかなか「刺激的」な環境だったわけです。

　少人数の良い点はというと、案外とエンジニアであることそのものに由来するものだったりします。社内では「エンジニア＝珍しい人種」として尊敬され、必要とされていることを実感できる機会が多かったように思います。もちろん、サービス開発に自分が持つ技術を投入するわけですから、「創業」に近い感覚も持ちます。このとき感じる一体感は長年消えることはありません。

組織が増え、予算が変わり、評価が変わるまで

　とはいえシステム開発の完全な内製化を目指していたため、開発メンバーは徐々に増えていきました。人員が5〜20人になると、さすがにきちんとしたマネジメントが必要になります。

　組織としては、チームを4つに分け、CTO以外にマネジャーを4人立てることで役割分担をしながら開発ができるようになります。さらに事業部として独立できるようになると、今後は「事業計画」を作るようになります。

　開発予算も通年の予算に代わり、開発も「請負型」だけでなく、委託・アジャイル型のものが増えていきました。こうなると、「お願いした分」という「ながら開発」が可能になります。予算承認も「ながら承認」が許容されるため、このころからはむしろKPIの設定が非常に重要になりました。

　予算承認の説明を「ながら」で行うことは難しく、どのタイミングで費用対効果を確認しても納得できるKPIを設定しないとプロジェクトが途中で頓挫してしまい、大変なことになります。

　当初は、うまくKPIを設定できず「リリースする機能数」「バグ収束率」の2軸を用意するのが精いっぱいでした。当初は費用対効果を判定するための指標を全く測定できていなかったのです。

KPIを正しく収益と結び付ける

　この状況を改善するには、どうにかしてセールスデータと連動しなければなりません。現在はこの反省を生かし、セールスデータと連動してプロジェクトを評価するのはもちろん、「効率化できる工数」をサポート部隊の勤怠データから取得することで「工数削減効果」「売り上げインパクト」「解約率・継続率」から判断することもできるようになりました。

　人事評価制度は、こちらは弊社の商品である「あした式　ゼッタイ！評価」を、入ってくるメンバーに合わせるように制度自体を「自社プロダクト内製組織の人事評価」に進化させています。

　例えば、エンジニアやデザイナーのスキルマップを作成し、スキル手当として手当式に変え、目標を明確にして教育にも生かしています。

　このように、自社プロダクトをアジャイルな組織で内製できるようにチームを変化させるため、人数に応じて、マネジメント、組織、予算、評価を随時見直して行く必要がありました。

著者紹介：林田幸一

官公庁システムの開発やスタートアップ企業の技術コンサルティングに従事。自身もスタートアップ企業のCTOを経験した後、Rubyに特化したシステム開発会社を起業。大手企業に事業売却の後、あしたのチームにCTOとして参画。現在、同社執行役員 クリエイティブ事業本部長。