スケールする会社を支える開発組織のマネジメント2016/11/02
View Slide
自己紹介● 市橋@技術部部長 CTO● 略歴○ コンサルティング会社で5年○ 共同創業した会社で3年○ 弁護士ドットコムで3年
入社時@2014年頭● 社員数○ 約20名● エンジニア○ 約5名
課題: カウボーイスタイル開発優先度付けの不在● 依頼開発がエンジニア個人に飛び交う● 全てのタスクが最優先開発ルールの不在● masterにcommitしてpush● RedmineやJenkinsはあれど使っていない貧弱な開発環境● テストサーバー1台を皆で共有● 画像の表示確認・DB変更で死ぬ
対策: 開発プロセスの整備開発ルールの不在優先度付けの不在貧弱な開発環境開発ルール策定全社での優先度付けローカル開発環境の整備● スプリント毎に全社的にタスクを優先度判断● スクラム開発の本格導入● Redmine/Gitブランチルール/Jenkins運用整備● Vagrant/Ansibleの整備
上場後@2015年頭● 社員数○ 約40名● エンジニア○ 約10名
課題: 人数増加にともなう混乱チーム肥大化と設計の混乱● ピザ2枚ではまかなえない人数で一体感が薄れる● 属人的な設計方針の違いで品質にも影響評価制度のミスマッチ● 目標を立ててもビジネス要件で事後修正の嵐● 「何が評価されるのか」も曖昧に顔と名前の不一致● 入社ペースが加速して月に5〜6名入社● 他部署が中で何をやっているかも見えにくく
対策: スケールする組織へ行動指針/評価制度チーム分割/Tech Leadシャッフルランチ/BeerBash● max8名程度にチームを分割● Tech Leadを置いて設計面での品質を担保● 「エンジニア行動指針」を策定し、それに基づく評価制度に● 4人組をランダムに作ってランチ代支援● オフィスで軽い飲み会評価制度のミスマッチチーム肥大化と設計の混乱顔と名前の不一致
最近@2016年● 社員数○ 約100名● エンジニア○ 約15名
課題: はざまに落ちるボール責任所在が不明確● 良く言えば臨機応変、悪く言えば現場任せ● ビジネス/開発側でお見合いするケースもプロダクトの担当数増加● 上場後も新規事業を続々と展開● 弁コムをやりつつ片手間には見れない規模に技術的負債の蓄積● 独自の「20%ルール」で対応していた● 大規模なものは対応し切れず障害も
対策: チーム役割分担の明確化チームの再編成プロダクトオーナーチームSREチーム強化● ビジネス・エンジニア・デザイナーの3人1チームで責任を持つ● 規模を踏まえ1プロダクト = 1チームに近い形に● プロダクトとは1歩離れて、基盤整備に専念プロダクトの担当数増加責任所在が不明確技術的負債の蓄積
いろいろあったけど、結局スケールする会社を支える開発組織のマネジメントってなんだ?
開発組織のマネジメント対象領域with 社外 with 経営層with 他部署プロダクトアーキテクチャ開発プロセス人材/組織技術広報・ブランディング予算・採用・スケジュールの説明責任エンジニア的文化の相互理解コアバリュー・ロードマップ・カスタマージャーニーマップ開発言語・フレームワーク・ミドルウェア・XaaSの技術選定Redmine・GitHub・Jenkins・Slack・ChatOps採用・教育・評価組織体制開発組織外とのコミュニケーション プロダクト・サービス開発
領域の重みはライフサイクルによって変わるhttp://www.slideshare.net/HayatoKiriyama/aws-startup-security-talks-aws
重点領域例 (実際は会社/プロダクトにより異なる)http://www.slideshare.net/HayatoKiriyama/aws-startup-security-talks-awswith 社外 with 経営層 with 他部署プロダクトアーキテクチャ開発プロセス人材/組織
大事なこと1: 解決しない● 課題はあるのか?存在しない課題を解決してはいないか?● 本当に課題なのか?誰にとっての・どれ程の課題か?● 今やるべき課題なのか?「やった方がいい」程度でないか?
大事なこと2: アンテナを張る● 課題が大きい程、認識→対策→解決には時間がかかる● 兆候にアンテナを張って、「ノイズ」か「シグナル」かを見極めよう● 3回起きたら偶然ではない・倍になったらどうなるか
大事なこと3: 引き出しを増やす● 課題は会社によって千差万別、他社の事例がそのまま使えるわけではない● でも事例を知っておくと、見通しや対策が立てやすい● ということでこの後の懇親会で色々お話しましょう