Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Dveloper Infrastracture in Devlove2015

2,809 views

Published on

Wantedlyの文化、インフラチームの文化について発表しました:)

Published in: Internet
  • Hey guys! Who wants to chat with me? More photos with me here 👉 http://www.bit.ly/katekoxx
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Dveloper Infrastracture in Devlove2015

  1. 1. Developer Infrastructure Wantedly,Inc. Kodai Sakabe @koudaiii
  2. 2. About me • Kodai Sakabe@koudaiii • インフラチーム • 2015 - Wantedly • 2010 - 2015 TIS
  3. 3. http://qiita.com/advent-calendar/2015/wantedly
  4. 4. http://qiita.com/koudaiii/items/bc89368e1279649f2498
  5. 5. 本日お話する内容 「現場のDiff = 文化の違い」 Wantedlyの文化 インフラチームの文化
  6. 6. Wantedly とは
  7. 7. 自分の寿命が縮むことを願 う人々
  8. 8. 働くを面白くする ビジネスSNS 月間 60万 ユーザ
  9. 9. Wantedlyの提供するサービス • プロフェッショナル・プロフィール • 多面的に魅力の伝わるプロフィール • 会社訪問・インターン探し • 会社とのマッチング • ビジョンや人を重視したコンテンツ • ビジネス用の人脈管理 • ソーシャルグラフ・プロフィール検索 • グループメッセンジSync←New! • 社内外のプロジェクトで効率的にコラボレーション • Wantedlyアカウントでご利用いただけます
  10. 10. https://www.wantedly.com/users/310906 プロフェッショナル・プロフィール
  11. 11. (= )
  12. 12. Sync
  13. 13. 3 @
  14. 14. 利用社数約 10000 社以上
  15. 15. http://jp.techcrunch.com/2015/11/09/wantedly-open-api/ http://japan.cnet.com/news/service/35073141/
  16. 16. Wantedly OpenAPI https://www.wantedly.com/developers/
  17. 17. • for Engineer
  18. 18. • for Engineer
  19. 19. •  60 –  •  – Visit ( ) – Sync (SNS ) – Corporate ( ) •  – Ruby on Rails –  GitHub pull request
  20. 20. 「現場のDiff = 文化の違い」
  21. 21. Wantedly Value
  22. 22. Wantedly value • OwnerShip • LeaderShip • Wantedly Way
  23. 23. コップに水を貯めよう • 失敗は成功の母 • 空のコップがひとつあったとして、何かに失敗して、PDCAサイクルを 一度回すと、失敗から学んだ分コップに水が溜まっていくのイメージ • 最終的に水があふれる時が成功 • その人の姿勢で水の入り具合は変わる • 年齢や経験値が高まると、コップも大きくなるし、水の量も変わる • 誰もがOwnerShipとLeaderShipを発揮していこうとする文化 OwnerShip Leadership
  24. 24. Wantedly Way
  25. 25. Wantedly Way • Code Wins Arguments • User First • Simple is Not Easy
  26. 26. Code Wins Arguments • チームで1時間MTGするならcodeを書いて検証しよう • エンジニアの場合 • 限られた情報で決断をして、前に進んでいるか • 仮説をあれこれ考えるより、まずプロトタイプを作って早く学習しているか • 爆速で動けているか • 営業の場合 • 自分で良い機能が浮かんだからエンジニアに頼むのではなく • 企画書を書いて会社を回って、5社程度を確約して、これなら行けると思ったらエ ンジニアに頼むことが出来るか
  27. 27. User First • 「もっと速い馬車がほしい」というユーザの声を聞 き続けるのではなく、「速く移動したい」というユー ザの本質的な欲求に応える行為 • 「言葉 < 行動」 • ユーザーテストで3人間違えるようだったりまごつい たりしたら改善して、もう一回試してもらって違う 人にも試してもらう
  28. 28. Bad(例: ユーザテスト) • どうやって●●(機能名)探しますか?? • どうやって改善にしたらいいですか? • 仮説がなくて、意見をひたすら聞きまくる
  29. 29. Good(例: ユーザテスト) • まずは実際に操作している状況をイメージさせる • シチュエーション・シナリオを描く • goalを明確に伝える • 答え合わせポイントを明確に • 今考えていることを聞く • 考えてることを口に出してもらう • 答えをいわない • 困惑した部分をメモる • 挙動が不自然だった場合をメモる
  30. 30. Simple is Not Easy • 作る側が使う側の事を徹底的に考え抜いているか • 足すよりも引いてフォーカスをしているか • 上限10%も改善しないような施策をしない(KPIが取りに くいのと、その掛けた工数分でもっと有効な改善はなかっ たのか?) • 仮説をたてて、その仮説のコアとなる部分だけにフォー カスできているか
  31. 31. Wantedlyのインフラチーム 仕事の考え方と進め方
  32. 32. インフラチームが目指していること
  33. 33. WHY: 自動化/セルフサービス化 • 数年前までエンジニアが少なかった頃 開発チーム インフラ タスク依頼 作業開発
  34. 34. WHY: 自動化/セルフサービス化 • エンジニアの増加、サービスの増加。。 開発チーム インフラチーム タスク依頼 作業開発
  35. 35. WHY: 自動化/セルフサービス化 • 依頼のタスクが増加 • 新たなサービスローンチ • サービスの分割 • 気づいたらインフラチームの作業待ちがボトルネック に。。。 • インフラチームも日々追われる仕事ばかり自分たちのプロ ジェクトが進められない
  36. 36. どうするか? • 一つは開発チームみたいに人を増やす • もう一つはインフラチームの力をあげること • 一人あたりどれくらいのサーバ、どれくらいの種類のアプリ、どれくらいのユー ザ数を支えているか • 例: 1万台のサーバを一万人で見ていたら結局1人1台の力しかない • 1台のサーバー1人で見ていたものを、100台見れると力上がった • 2011 年の時点で Facebook のインフラチームはわずか 5 人ほどで 10 万台を超える サーバを管理 • Wantedlyは後者を目指す
  37. 37. WHAT:何を実現するか? • Code wins Arguments を可能にするインフラ • 既存のアプリでも新規アプリでもどんどんデプロイでき るように = 変化に強いインフラ • 変化を避けるインフラではなく、むしろ変更を前提と したインフラ • 議論や権力ではなく、まず出してみて結果を見る文化を 可能にする
  38. 38. WHAT:何を実現するか? • 「スピード感ある組織にしていくために必要 なものは何か」 • ”「文化とインフラだと思う。どんどん前に進 もうとする文化と、それを可能にするインフ ラに投資をすること」” Mark Zuckerberg
  39. 39. HOW:どう実現するか? • 自動化 • セルフサービス化
  40. 40. HOW:自動化/セルフサービス化 • インフラの自動化(Code化) 開発チーム インフラチーム Pull request開発 開発 インフラを操作できる APIやcode
  41. 41. HOW:自動化/セルフサービス化 • インフラを操作出来るAPIやCodeにする • 開発チームが自分たちだけで進められる • インフラチームも開発チームも自分たちの自 分たちの仕事に集中出来る
  42. 42. 計測方法 • deploy(変更)回数 / 日 • Container数 + ホスト数 + AWS Resources数 / インフラチーム • 要件を満たしつつインフラコストを下げる
  43. 43. 仕事の進め方 • 情熱プロジェクトと痛み分けタスク • GitHub Issue Driven • GitHub Flow
  44. 44. 情熱プロジェクトと痛み分けタ スク • インフラチームのタスクは大きく 2 種類 • やりたいと思っているプロジェクト • 障害対応や開発チームからの依頼などアド ホックに生まれるタスク
  45. 45. Issue Driven • Issueタイトルは直感的なもの • 説明には必ず「WHY」と「WHAT」を書く
  46. 46. なぜWHYとWHAT • 自分以外の人とのコミュニケーションに用いているので他人が理解できなかっ たら Issue を立てる意味がないし、3ヶ月後の自分は他人。 • 集中して作業している同僚への配慮(非同期コミュニケーション+情報共有) • コメントは粒度の細かい「報告」とも考えられる = マイクロマネジメネントも 避けられる • 突然別のタスクをすることになって、あとでその issue に戻ってきても思い出 せる => 「なぜそうしたのか?」 意思決定を忘れずに書いておこう • チームメンバー間で Issue のバトンタッチが可能になる
  47. 47. GitHub Flowとは • masterブランチのものは何であれデプロイ可能である • 新しい何かに取り組む際は、説明的な名前のブランチをmasterから作成 • (例: new-oauth2-scopes) • 作成したブランチにローカルでコミットし、サーバー上の同じ名前のブランチにも定期的に作業内 容をpushする • フィードバックや助言が欲しい時、ブランチをマージしてもよいと思ったときは、 プルリクエスト を作成する • 他の誰かがレビューをして機能にOKを出してくれたら、あなたはコードをmasterへマージするこ とができる • マージをしてmasterへpushしたら、直ちにデプロイをする
  48. 48. GitHub Flow • シンプルで制約のあるプロセスは、完璧だけど複雑なプ ロセスに勝る • RailsだけじゃなくてNginxの設定でも topic branch -> PR -> merge -> deploy で進める • 資料作成も基本的にこの方法に従う • プロジェクトが別でも同じ開発フローなら join しやすい
  49. 49. Github Flow ShellScript
  50. 50. インフラチームの指針 • 「情熱的に働く手助けをする」という理念は自分たち自身も例 外ではありません。 • 自分たちが情熱的に働いてなければ周りの人の力になれるはず もありません。 • インフラチームでは、各自情熱的に取り組めるプロジェクトを 必ず 1 つ持つ • 同時に、事業に貢献する必要もあるため、そのプロジェクトは 会社としてやるべきことと、やりたいことが重なる領域を選ぶ
  51. 51. インフラチームの指針 • インフラチームはより多くのユーザーに価値を届けられるよう挑戦 しています。 • Infrastructure as codeが世の中に定着していますが、そのほとんど が既にあるツールの利用したものが多いと感じています。 • Wantedlyのインフラチームでは、自分たちにとって必要なツールは 何か?を考え、必要であればツールの開発行うことをしています。 • ツールの開発ができる現場はそう多くはなく、Wantedlyならではの 体験です
  52. 52. インフラチーム募集中 https://www.wantedly.com/projects/33465
  53. 53. ご静聴ありがとうございました

×