Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

弁護士ドットコム

November 02, 2016
Tweet

More Decks by 弁護士ドットコム

Other Decks in Technology

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