More Related Content
Similar to 信頼されるチームの生成過程 (20)
More from Takeshi Fukasawa
More from Takeshi Fukasawa (6)
Editor's Notes
- 普段は何をどういう順番で達成したら価値が出せるだろうという仕事をしてますが、今回はチーム活動の話しを多くします
- 話
- B2B2C。店舗を持ってる顧客が多くオムニチャネルの一端をになう
会社の中では普通に開発をしてる部署になる
受託による開発と製品を混ぜて提供している
- AWS/サーバーアプリ/Webアプリ/iOS/Android/デザイン…
30人くらい
- 比較的短い期間にアプリに携わるので飽きにくい
- AWSインフラ/サーバー/アプリ/データ分析基盤
- 3,4年前はWF＋気合いで、プロジェクトが終わったら解散であまり学習しないチームでした。2,3ヶ月の作りきりアプリだからよかった。
開発が旺盛なプロダクトはスクラム
オンデマンドな要求の多い保守メインのプロダクトはカンバン+振り返り
また顧客によってはウォータフォールで行っています
最近の開発スピードと要求のや顧客が情シス部門以外になってきてること、それにスッキリ感や納得感が得られやすいと感じているのでここ数年でアジャイル開発にシフトしています
- 生活するためももちろんそうなんですが
- 一人の喜び
- チームが達成する
- 顧客が満足できるものが作れた
- 例えばアプリ使う人も
- 自分たちが何かしら動いた事によって価値がもたらされる、いい感じのアーキテクチャでメンテ不要、全てが自動化、ビジネスとしてお客さんと10倍成長してAppStoreの評価が☆5で自分の給与が3倍に。さらにそのアプリが世界の貧困を10%削減する役目があったら。だいたいの人はやっててよかったって思うんじゃないかなと思います。
- 試して上手くいってる例が多いです
- 試して上手くいってる例が多いです
- スクラムやっててスプリントという単位で計画するのですが、数回ずっと終わらない。
- 例えば1週間のスプリントや初期開発してて3ヶ月後のリリースもそう。
もちろん途中でしょうもないものだと気付いた時とかは例外。
- 部長が〜コンピテンシーとるからエビデンス用意してインタビュー受けてとか
- 差し込みが必要な時間ならその分も差し引いてして計画する、可能なら改修や交渉で差込み時間自体を減らす。
チームのパフォーマンスや使える時間を考慮した実直に計画する（それでも外れる時もある）
- タスクボードに乗らないものが明らかになると、例えば社内で交渉する材料になる。
誰がn時間使ってるからスプリント終わらないんだけどとかね。
- 人間だから忘れますね
忘れる前提で考えないといけない
- ２パターンあります。
忘れる事もあるんですが、挨拶に組み込む事で誰かが気づきます。
- 誰かが気付くからOK オススメ
- リモートチームで、張り出す場所がないのでチャットを壁代わりにつかってる
Slack使ってる？リマインダ機能しってる？
自分は最近しりました。
- 東京と大阪でやってる時もそうんなんですが、これは結構致命的
- もういいやってなる
- リモートワーク始めた初期に行った。
機材に投資しても会社にかかるコストは減るはず
- リモートワーク始めた初期に行った。
機材に投資しても会社にかかるコストは減るはず
- 人が増えると共に状況悪化
基本ノートパソコンWifiでこの仕事なので生命線
会社に相談したら色々調査して結果、Wifiルーターと回線をセットで変えた Wifiはずーっと改善してますね Nuro
- ビデオ会議はリモートチームの生命線なので、環境で解決出来るなら投資スべき所
- せっかく気になったり、助けて欲しいこととかを共有するばなのに雰囲気が硬いと出てこない
機能しない朝会になってしまう
- 例えば、二次元の彼氏にうん全円つかったとか、子供が入学して寂しいとか
- 新規プロジェクトで最初に立てる計画ってどうしてますか？
何の実績もなく伝えて失敗した事があるんですが‥死にました新規プロダクトの寄せ集めのメンバーではすごく難しい
- 本当は終わった時に終わるよって言いたい。
縦軸のポイントが固定なのでストーリーやポイントが増えた場合にチームの速度が測れない。バーンアップがいい？
- お互いにとって良い情報とは何か今の予測と精度を正確に伝える。リスクを伝える。
その上でスコープの調整なりする。請負の場合はxxx
- 遊びを入れて 楽しくやろうぜ
- 1. それがチームの自信と信頼ビジネスの貢献につながる
2. ビジネスとして成立しないと継続出来ない
