スケールする会社を支える開発組織のマネジメント

Transcript

1. スケールする会社を支える
   開発組織のマネジメント
   2016/11/02
   

   View Slide

2. 自己紹介
   ● 市橋@技術部部長 CTO
   ● 略歴
   ○ コンサルティング会社で5年
   ○ 共同創業した会社で3年
   ○ 弁護士ドットコムで3年
   

   View Slide

3. 入社時@2014年頭
   ● 社員数
   ○ 約20名
   ● エンジニア
   ○ 約5名
   

   View Slide

4. 課題: カウボーイスタイル開発
   優先度付け
   の不在
   ● 依頼開発がエンジニア個人に飛び交う
   ● 全てのタスクが最優先
   開発ルール
   の不在
   ● masterにcommitしてpush
   ● RedmineやJenkinsはあれど使っていない
   貧弱な
   開発環境
   ● テストサーバー1台を皆で共有
   ● 画像の表示確認・DB変更で死ぬ
   

   View Slide

5. 対策: 開発プロセスの整備
   開発ルール
   の不在
   優先度付け
   の不在
   貧弱な
   開発環境
   開発ルール
   策定
   全社での
   優先度付け
   ローカル開発
   環境の整備
   ● スプリント毎に全社的にタスク
   を優先度判断
   ● スクラム開発の本格導入
   ● Redmine/Gitブランチルール
   /Jenkins運用整備
   ● Vagrant/Ansibleの整備
   

   View Slide

6. 上場後@2015年頭
   ● 社員数
   ○ 約40名
   ● エンジニア
   ○ 約10名
   

   View Slide

7. 課題: 人数増加にともなう混乱
   チーム肥大化
   と設計の混乱
   ● ピザ2枚ではまかなえない人数で一体感が薄れる
   ● 属人的な設計方針の違いで品質にも影響
   評価制度の
   ミスマッチ
   ● 目標を立ててもビジネス要件で事後修正の嵐
   ● 「何が評価されるのか」も曖昧に
   顔と名前の
   不一致
   ● 入社ペースが加速して月に5〜6名入社
   ● 他部署が中で何をやっているかも見えにくく
   

   View Slide

8. 対策: スケールする組織へ
   行動指針/
   評価制度
   チーム分割/
   Tech Lead
   シャッフル
   ランチ
   /BeerBash
   ● max8名程度にチームを分割
   ● Tech Leadを置いて設計面で
   の品質を担保
   ● 「エンジニア行動指針」を策定
   し、それに基づく評価制度に
   ● 4人組をランダムに作ってラン
   チ代支援
   ● オフィスで軽い飲み会
   評価制度の
   ミスマッチ
   チーム肥大化
   と設計の混乱
   顔と名前の
   不一致
   

   View Slide

9. 最近@2016年
   ● 社員数
   ○ 約100名
   ● エンジニア
   ○ 約15名
   

   View Slide

10. 課題: はざまに落ちるボール
    責任所在が
    不明確
    ● 良く言えば臨機応変、悪く言えば現場任せ
    ● ビジネス/開発側でお見合いするケースも
    プロダクトの
    担当数増加
    ● 上場後も新規事業を続々と展開
    ● 弁コムをやりつつ片手間には見れない規模に
    技術的負債の
    蓄積
    ● 独自の「20%ルール」で対応していた
    ● 大規模なものは対応し切れず障害も
    

    View Slide

11. 対策: チーム役割分担の明確化
    チームの
    再編成
    プロダクト
    オーナー
    チーム
    SREチーム
    強化
    ● ビジネス・エンジニア・デザイ
    ナーの3人1チームで責任を持
    つ
    ● 規模を踏まえ1プロダクト = 1
    チームに近い形に
    ● プロダクトとは1歩離れて、基
    盤整備に専念
    プロダクトの
    担当数増加
    責任所在が
    不明確
    技術的負債の
    蓄積
    

    View Slide

12. いろいろあったけど、結局
    スケールする会社を支える
    開発組織のマネジメント
    ってなんだ?
    

    View Slide

13. 開発組織のマネジメント対象領域
    with 社外　
    with 経営層
    with 他部署
    プロダクト
    アーキ
    テクチャ
    開発
    プロセス
    人材/組織
    技術広報・ブランディン
    グ
    予算・採用・スケジュー
    ルの説明責任
    エンジニア的文化の
    相互理解
    コアバリュー・ロードマッ
    プ・カスタマージャーニー
    マップ
    開発言語・フレームワー
    ク・ミドルウェア・XaaSの
    技術選定
    Redmine・GitHub・Jenki
    ns・Slack・ChatOps
    採用・教育・評価
    組織体制
    開発組織外とのコミュニケーション プロダクト・サービス開発
    

    View Slide

14. 領域の重みはライフサイクルによって変わる
    http://www.slideshare.net/HayatoKiriyama/aws-startup-security-talks-aws
    

    View Slide

15. 重点領域例 (実際は会社/プロダクトにより異なる)
    http://www.slideshare.net/HayatoKiriyama/aws-startup-security-talks-aws
    with 社外　
    with 経営層 with 他部署
    プロダクト
    アーキ
    テクチャ
    開発
    プロセス
    人材/組織
    

    View Slide

16. 大事なこと1: 解決しない
    ● 課題はあるのか?
    存在しない課題を解決してはいないか?
    ● 本当に課題なのか?
    誰にとっての・どれ程の課題か?
    ● 今やるべき課題なのか?
    「やった方がいい」程度でないか?
    

    View Slide

17. 大事なこと2: アンテナを張る
    ● 課題が大きい程、認識→対策→解決には
    時間がかかる
    ● 兆候にアンテナを張って、「ノイズ」か「シグ
    ナル」かを見極めよう
    ● 3回起きたら偶然ではない・倍になったらど
    うなるか
    

    View Slide

18. 大事なこと3: 引き出しを増やす
    ● 課題は会社によって千差万別、他社の事
    例がそのまま使えるわけではない
    ● でも事例を知っておくと、見通しや対策が
    立てやすい
    ● ということでこの後の懇親会で色々お話し
    ましょう
    

    View Slide