nashcft's blog

時々何か書く。

eureka Meetup 04 -チーム開発ナイト- memo

6月末の

Pairsにおいて大事にしたいユーザ体験やプロダクトで大事にしている価値

  • テーマ: UX -> チームの作り方
  • 大事にするUX
    • 出会えること:
      • マッチングUU, メッセージUU
      • 誰でも迷わず使える
    • 安心・安全である: 24x365 監視体制

価値観

  • ユーザに対して真摯
    • don't be evil
    • ちょっとした不具合や触り心地の悪さを許さない
    • monetize < UX
    • マーケットリーダー: オンラインデーティングに対する印象に対する影響
  • 機能追加≠価値追加
    • 機能 < 提供価値
    • 仕様ないではなく課題への解決方法を考えるという文化
  • たくさん機能が欲しいわけではない
    • 減らす、磨く
    • 価値は何か?
    • 数字・ユーザが使う様子を見せる
  • 規律よりも規範
    • チーム数の増加: 10~12人超えたくらいでチームを分ける
    • 「語れる人」を各チームに必ず含める
      • 語れる人を増やす必要 -> 考えていることがバラバラに
    • 局所最適化した動き・考えに傾きがち
    • ビジョン・理念の浸透スピード < 人の増加
      • 意思統一の難しさ
    • やってること
      • 最初はチームリーダーを通していた
      • PMとしてチーム全体に投げかける
      • 全社会
      • 社内SNSで発信、お気持ち課題の提起、同じことを何回も言い続ける
      • 張り紙、意外と効果がある
      • 良いことはどんどん褒める
      • エモい話をぶっ込む
    • recap
      • プロダクトの芯をぶらさず伝える
      • 発信者が実践者としてやっていく

自己組織化された開発チームの作り方

  • 何かを始める時のポイント
    • 変えることを目的にしてはいけない。何故を伝える
    • 「何故」 -> 強いチームが必要 という流れのポエムを投稿
      • 熱量は大事
    • 自ら考え、小さく実践、フィードバックする
    • 自己組織化したチームを目指したい -> 会社の理念に合致するね
    • 小さく、正しく始める (問題点の見える化、フィードバック)
  • 全社を動かす時のポイント
    • 2人目のフォロワーが重要
      • すでにチームになっている
    • 経営課題にリンクさせる
    • 解決されると得られる基準にCXOを常に会話する
      • 価値を提供するための手段
    • 短期での結果を求めず中長期で課題を解決させる大局的な視座が必要
    • 会社のステージに応じて作戦を考える -> 画像の出典: elastic leadership
      • サバイバルモード
      • 学習モード
      • 自己組織化モード
    • 透明性大事: 十分な情報があれば自律的に動ける
      • みんなが見えるところで発信 (フィードバックとか) -> お互いで学び合うことができる
    • なんか楽しい・良さそう感を出していくことが大事
    • 外部の専門家を巻き込む
      • 全部自分でやらなくて良い
      • WHYを伝える努力、思いの代弁

スクラムマスター、プロダクトオーナーを両方経験して分かったこ

  • 何故チーム開発なの?
    • 一人でできることは小さい
  • scrumの具体的なお話
    • daily scrum
      • warmup (openingテーマ)
      • burndwon chartを見る: 単なる目安であって正確にやってはいない
        • 見積もりは1~2時間幅
      • 各自が話す (いつもの3つ)
        • 問題解決: みんなで
      • 5 finger: ゴールに全員で達成できそうかを評価 (1,2がでたら解決するためのアクションを話す)
      • あるある失敗談
        • 困ってるけどなんとかします (気合い): next actionは? 助けられることはない?
        • JIRAに乗ってないことをやった: 透明性を壊している. POへの確認は?
        • BCが落ちてない -> もう少し様子を見ましょう: 理由や状況をきちんと把握しよう
      • リファインメント
        • ?
        • ?
        • ストーリーポイントで素早く道もる
        • (次のスプリントなどで)開発できる状態に
      • その場で疑問が解消しなかったら即持ち帰り課題にして次の日までに調べてやり直し
      • 毎日にしてよかった点
        • PO <-> 開発チームの会話を毎日モテている
        • プランニングの時に慌てることがなくなった
      • 失敗談
        • ユーザへ価値を届けるための他の手段を議論できていない。価値にフォーカスして手段を議論する
        • POの要望がでかい -> 会話しながら小さく分割していく。本当に価値を届けられるものを最も小さい規模で MVP
      • SMで大事にしていること
        • 推測より会話 (齟齬の原因は推測)
  • Q&A
    • 24x365の監視体制: 開発じゃなくてカスタマーケアのチーム
      • チーム分けると顧客フィードバックに関する学びが薄くなるのでは?
      • 改善のためのチームを作ってとか体制を作ってる
    • 開発チーム内のロールだったりとか
      • ios x 2, android x 1 server x 3
      • インフラ? -> 専用チームがいて、開発チームと連携して活動したり

新チームで初スクラムして感じたチームの成長に大切なこと

  • 大切なこと
    • why and value
      • メンバー全員で議論して、回答を作り上げる -> インセプションデッキ
      • 認識統一
      • POから繰り返し伝えること
    • 選択と集中
      • 手広くやろうとすると崩壊
      • やってることを増やしすぎず着実に終わらせる
      • あるべき、 ありたい vs 現状
      • KPT -> Tryたくさん出てくる -> priorityをつける -> 重要なのから着実に終わらせる
        • 着実にやって成功体験をきちんと積む
  • Q&A
    • やっぱTry溜まっちゃうよね
      • Tryを推進するための責任を持つパーソンが必要では? 誰かがやってる、or 他のやり方
      • 推進はSMが行っているがどうするか考えるのは開発チームでやってる
    • why and valueを実践、定着させるためのワークショップ・お話など