Embed Size (px)
Citation preview
俺のエンジニアリングE N G I N E E R I N G
及部敬雄 @TAKAKING22
2014.11.8 プレイバックDevLOVE現場甲子園
- エンジニアリングにチームビルディングは必要なのか -
@TAKAKING22● WEBサービス開発● 唄って踊れるエンジニア ● 野生のアジャイラー ● 邪道スクラムマスター ● チェンジエージェント ● チームファシリテーター
及部 敬雄
AFTERBEFORE
超サイヤ人 超サイヤ人ゴッド
初勉強会＆初発表http://kokucheese.com/event/index/21611/
現場も発表もナマモノ
エンジニアリングに チームビルディング は必要なのか
正直わからんっ!!
高度化する技術 高速化するサービス開発
天才じゃない
わかっていること
Big Data
Devicehttp://goo.gl/6eCpP8
Cloud
Automation
Machine Learning
Testing
Web & APP
高度化する技術
http://goo.gl/Ufyt96
天才じゃない
エンジニアリングに チームビルディング は必要なのか
正直わからんっ!!
だけど、 私にはチームが必要!!
いい現場は 最初からそこに あったわけではない
誰かがいい現場を つくったストーリー がそこにはある
仕事サービスを保守運用
しながら新規開発を行う
役割Product Owner
Engineers
開発の流れ要求 分析 計画 開発 テスト リリース
開発の流れ要求 分析 計画 開発 テスト リリース
要求 分析 計画 開発 テスト リリース
要求 分析 計画 開発 テスト リリース
保守・運用
!チームに一体感がない !お互いがやってることが見えない !PRJが終わるかわからなくて不安 !リリースに時間がかかる !テストコードがない !トラブルが多い …
チームが抱えていた問題
なんだこいつ感
ひとりカンバン
聴いてくれる感
1on1ランチ 聞くのではなく聴く
未来・問題を見てもらう
ヒアリング
「どんなチーム？」ではなく、 「理想のチームと今との差分は？」
ヒアリング
「なにか問題ある？」ではなく、 「何を変えたらもっとハッピーになる？」
「なにがやりたい？」ではなく、 「1つ変えられるなら何を変える？」
!チームに一体感がない !お互いがやってることが見えない !PRJが終わるかわからなくて不安 !リリースに時間がかかる !テストコードがない !トラブルが多い …
ヒアリングの結果まとめ
みんな気づいてる!!
!チームに一体感がない !お互いがやってることが見えない !PRJが終わるかわからなくて不安 !リリースに時間がかかる !テストコードがない !トラブルが多い …
ヒアリングの結果まとめ
なぜ変わらないのか
よくある間違いプロセス導入 ツール導入 ≠ 改善
なんでこんなこともできてないの？ こうやってやればいいのに 普通こうじゃないの？ 一般的には…
教科書にこう書いてあるよ
禁句
人は変化を好むが、 他人に変化させられる ことを好まない
By Henrik
やることを減らす 変えるのはそれから
忙しい
変化を嫌うやらされる→自分たちがやる 成果が出てることが見える変化できる状況をつくる!!
最初のアプローチ
チェンジインセプションデッキ
チェンジインセプションデッキ
!なぜここにいるのか !パッケージデザイン !夜も眠れない問題 !優先順位 !ステークホルダー
チェンジインセプションデッキ
“みんなにヒアリングした 内容をまとめただけです”
マジックワード1
チェンジロードマップ
チェンジロードマップ
“●●さんが教えてくれたんですが”
マジックワード2
現状を共通認識にする “自分たちの問題”にする 過去ではなく未来を見る やれそうだ！感をつくる
同じ方向を見る
見える化
ワークフローの可視化
かんばん設計
かんばん
ふりかえり ＆
メトリクス
ふりかえり＆メトリクス!ふりかえりとメトリクスはセット !Tryの仮説検証・効果検証に必要なメトリクスを考える
!メトリクスにもWIP制限 !メトリクス自体もふりかえる
ふりかえり（KPT）
メトリクス
メトリクス定点観測のメトリクス
検証のメトリクス
継続観測してチームの変化を知る。 気づくことができるようにする。
新たに導入するTryや問題解決の 検証のために一時的に観測するもの。
ex) ベロシティ、Done率、Bug率…
とるだけのメトリクスは 猛毒よりもタチが悪い
By The Hero※脚色です、ごめんなさいw
例Problem 朝礼で宣言した内容が、 計画とおり進んでいるかわかりにくい
仮説 朝礼でいったことを忘れてしまう
メトリクス 前日の計画との差分を計測
例Try
例Tryプロジェクト見取り図
Featuring Ito Naoyaさん
有用だと思ったらすぐパクる!!
一目で朝会の情報が見えるように
http://goo.gl/kXHy7n
例Result 前日の計画との差分を計測
avg 3.2 avg 1.7Before After
なかなか変わらない 繰り返して身につける
大事なこと
ムダだったらすぐ捨てる
http://goo.gl/bDhLo9
http://goo.gl/bDhLo9
捨てる判断ポイントふりかえりの結果 メトリクスの結果
チームで判断して捨てる
ふりかえりの積み重ね
!90回のふりかえり !224個のTry
約2年間で、
Sprint Burnup レビュー可視化
Sprint Milestone
プライオリティ
サーバー状況 可視化
番長 可視化
ふりかえりの積み重ね
最後にがんばる
安定してがんばる
仕事の進め方
安定して進める
リリース成功率
Before After
×1.5
トラブル発生
Before After
-90%
Bug率
Before After
-50%
計画にあわせて変化した
さいきょうがふつうのチーム
さいきょうのふつうのチーム
PERFECTを狙うのではなく BETTERをBESTにしていく
アプローチ
エンジニアリングに チームビルディング は必要なのか
!Unit Test導入 !CIサーバー導入 !ViewTemplate再編 !設計思想の見直し !キャッシュ再設計 !継続的リファクタリング
この間のエンジニアリング改善
!ペアプロ導入 !デザインもGit管理 ! Grunt導入 !Vagrant & Chef !サーバーレポート !運用自動化
そこそこ変わった？
この間のエンジニアリング改善
チームビルディングによって…
●新しい技術への挑戦やシステム改善 に使える時間が増えた ●チームのスキルが向上して学び合う 文化ができてきたエンジニアリングの選択肢が拡がった
コードレビュー勉強会
コードレビュー勉強会
“コードレビューも コミュニケーションだよね”
“結局はヒト!!”
なんかチームっぽい
“チームのコンセンサス”
エンジニアの仕事
つくる
だれがつくる？ なにをつくる？ どこでつくる？ いつつくる？ なぜつくる？
どうやってつくる？
エンジニアリングに チームビルディングが 必要かどうかはわからない
だけど、“つくる”ために 必要だったら
なんでもやればいい
“プログラム”だけが エンジニアリングじゃない
http://goo.gl/2iuL0p
要求分析
チームビルディング
システムアーキテクトモデリング
テストスキルプログラミングスキル
ビジネスプロセスマーケティング
開発プロセス
戦略
プロジェクトマネジメント
やらない理由をつくるのはやめた
プログラミングでも インフラでも アジャイルでも スクラムでも リーンでも アウトソーシングでも チームビルディングでも なんだっていい
やってやる!!
それが俺のエンジニアリングだ!!
次回作にご期待ください!!
