Posted at

Sansan tech meetup #4 アジャイルなチームづくり in Osaka 編

More than 1 year has passed since last update.


はじめに

日時:2017/03/21(火) 19:30 〜 22:00

場所:Sansan株式会社 関西支店

詳細:https://sansan.connpass.com/event/52316/


① プロダクトマネージャーとエンジニアで行う改善の仕組み

@ErikoObe


改善サイクル3つのP


Product

MVP…最小の機能にしながらユーザーに価値を提供するのがPMの役割


Process



  • 3つの見積もりタイミング


    • ロードマップ時

    • リリース計画時

    • 開発前




  • 2回のPJ振り返りタイミング


    • 開発前

    • 開発後



  • バリューストリームマッピング



Person


  • 組織の取組み


    • 捨てる
      例)振り返り毎週2時間


      • 聞くだけのメンバーを減らす

      • 空いた時間で全員で改善について話をする



    • Realtime board


      • 大阪、東京間でボードを共有



    • 目線をあわせる


      • 目的・方針・背景を説明する…迷わせない
        例)エンジニアはHOWが豊富
        ⇒WHYとWHATが迷わないようにする



    • 知識を改善する


      • ランチ勉強会

      • エッセンシャルスクラム

      • 改善マインドを持ち続ける






Q&A

Qランチ勉強会の参加ルール

⇒任意


②働き方を革新する?!リモートで結果を出すチームビルディング術

@mmmmao0530


変化の激しいビジネス環境


  • 既存の知識やスキルだけでは時代に取り残される

  • プロセスを少しずつ進化させていく


個人ではなくチーム


  • メンバーの強み・経験・知識を融合させることが重要

  • 気兼ねなく安心して発現行動できるチーム


  • 心理的安全性 はチームの生産性を高める (by Google)


複数の役割でチーム構成


  • お互いの価値観を知る(役割が変わると価値観が変わる)

  • 本音で意見を言える関係性

  • 信頼関係が重要(役割を超えるとブラックボックスなので)

ギャップがある

⇒ギャップを埋めるためのチームビルディング


成果と成長

チームの成果と個人・チームの成長


モダンアジャイル

4つの原則


  • 人々を最高に輝かせる

  • 高速に実験&学習する

  • 安全を必須条件にする

  • 価値を継続的に届ける

⇒チームビルディング前提の原則

※参考:モダンアジャイル


実践


ワークショップ・打ち合わせの重要ポイント


  • メンバーひとりひとりの積極的な参加

  • 自由に意見を出し合える環境や雰囲気


ツール

⇒意見が出しやすい

(あんまり考えていないメンバーにはつらいがつらいなりにも意見が出る)

リモート環境で使うツール

Realtime Boad


タックマンモデル


  • 形成期

  • 混乱期

  • 統一期

  • 機能期


形成期


  • ドラッカー風エクササイズ

  • バリューストリームマッピング


    • 役割を超えたプロセスの見える化

    • 課題の共有

    • プロセス改善




混乱期



  • 理想的なチーム像(プロダクトのミッションなどは自分たちでは手が届きにくい)


    • 共通のゴールを持つ

    • 本気で意見をぶつけ合う

    • 自律的に考え動き成果を出すチーム

    • 多様性を認め意見をまじ合わせるチーム

    • 学びを共有できるチーム




  • 西洋文化インストール


    • Wa-gailからの脱却(MS牛尾さん)




  • 働き方を変えて生産性を高めるための8つの習慣


    • 世界基準の働き方を理解

    • 気づきのディスカッション

    • 新たな働き方の実験




  • 朝会の司会から関心事を共有


    • 学習する習慣づくり

    • 継続的な価値観共有



※何かを喋るためのインプット情報がないとできない


  • ニコニコカレンダー


    • 夕方アイコンを共有

    • 夕会で共有

    • 意外と悩み・困りごとの共有が多い




統一期・機能機

ここまでくればチームとしては大丈夫


Q&A


Qチームビルディングにどれくらい時間を割いているか


  • チームで時間…週1時間〜2時間

  • コンテンツ(取り組むための内容)を考える時間は30分〜1時間


Qアジャイルを取り組むうえで一番大変なこと


  • Be Lazy


    • 何かやりたいことの2割を実践すると8割分の価値が出る

    • 日本人はそうならない



例)カンファレンスに出て報告

- アメリカは30分ぐらいで報告完了

- 日本はプレゼンなどで共有⇒時間かかる


Qリモートでの開発ツール


  • Slack(音声共有)

  • Zoom

  • タスク管理…trello⇒変えようとしている


Q社内の他のチームもアジャイルしている?


  • 組織的にはスクラム

  • 各チームで判断⇒発表者のチームはアジャイル


③早く帰るとMVP(MLP)になる

@distkloc


MVP


  • 最小限のプロダクトを実現する

  • 最小限を考えるMVPが遠回りになることもある


MLP


  • 感情に訴えるプロダクトを最小限の労力で実現する


どうやって実践するか


  • 目的を明確にするとやらなくていいことが明確になる

  • やらないと決める⇒Be Lazy


時間的な制約をつくる


  • 強制的に定時で帰る


    • 日々やっている中で不要なことを真剣に考えるようになる



  • 仕事以外の予定を平日の夜に作る


    • やらなくてもいいことを捨てられる




Q&A


Q.定時で帰ることで得られたこと

朝起きたらその日やることを真剣に考える


Q.NLPの成果


  • 仕様を削ることができた

  • プロダクトオーナーが決めたものの中から話し合って不要な仕様を削る


④ LT枠

@okeicalm


「モノキュン!」の開発の話



  • アジャイル開発オフショア で実施

  • SES契約で実施(発注側が責任を持つ)

  • Scrumを選択


体制


  • プロダクトオーナー⇒発表者

  • スクラムマスター⇒ベンダー

  • 開発チーム⇒ベンダー、オフショア


ツール


  • Redmine(backlog)

  • slack

  • zoom⇒テレビ会議…帯域狭くてもいける


Sprint実行


Sprint1

1カ月でベロシティ0

⇒2週間に変更


Sprint2


  • 中国人がドキュメントを見ない

  • テストしない


Sprint3


  • 開発範囲を絞って全ストーリー完了


Sprint4


  • 不具合積み重なる


Sprint5


  • やっとなれてきた


Sprint6

不具合改修⇒βテストへ


メトリクス


  • ベロシティ…50〜60

  • 不具合…残バグ100


振り返り


  • ユニットテストを書くことを先延ばし⇒結局やらなかった

  • 短いサイクルで振り返りできるのでプロセス改善が容易

  • TDDで品質を作り込む必要性


その他

飛び入りで @atsukanrock さんの『C++のtemplate特殊化的なことをC#でやった話』も面白かったけど勉強会のテーマとは違う話だったので割愛(すみません)