Successfully reported this slideshow.
Your SlideShare is downloading. ×

Developer Infrastructure in Devlove Kansai

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 52 Ad
Advertisement

More Related Content

Viewers also liked (10)

Recently uploaded (20)

Advertisement

Developer Infrastructure in Devlove Kansai

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

×