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