Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

STAC 2015 自動家は見た ~自動化の現場の真実~ SIDE:マネージャ

33,419 views

Published on

システムテスト自動化カンファレンス2015の茶番に対する補足スライドです。

Published in: Technology
  • Be the first to comment

STAC 2015 自動家は見た ~自動化の現場の真実~ SIDE:マネージャ

  1. 1. 自動家は見た ~自動化の現場の真実~ SIDE:マネージャ .reviewrc -> おいしが 水野 昇幸 (@NoriyukiMizuno) STAC2015
  2. 2. 自己紹介 •.reviewrc(⇒おいしが)とは •大阪・兵庫・滋賀・京都近辺で、Web/組み 込み何でも良いのでネタを持ち込んであーだ こーだ言っている集まり。 •@NoriyukiMizuno(みずのり) •システム開発・マネジメント・テスト •皆に嫌われるSEさん
  3. 3. 2014/6/28 Asian Automation Aliance 本発表は みうみう氏(@kazuhito_m)の STAC2015発表の 補足となります。 そちらの資料と セットで確認して 貰った方が良いです。
  4. 4. テスト自動化パターン紹介 • パターン名:うるさい人がいなくなる • 文脈: 自動化が動いている状況においてうるさく言 う推進者が去る。 • 問題:自動化環境が継続できず、 [アンチ自動化]や [験担ぎ] で形骸化や消滅に向かう可能性がある。 • フォース:自動化の環境を継続するには、ある程度 リソース確保⇒現場メンバー/管理者の理解が必要。 • 解決: [ダッシュボード]などで改善効果を明らかに するなど、現場担当者と管理者側で価値共有を行う。 • 結果: 自動化継続の判断が必要。 [アンチ自動化] [原住民蜂起]に繋がり消滅するor立て直せるか?
  5. 5. マネージャの車窓から マネージャ側のロジックと心理面から考えられる背景
  6. 6. ビジネスとマネージャの背景 ・ビジネスとしては成果物を顧客に届けて、 お金を儲ける必要がある。 ・組織は成果物と引き換えに顧客から対価を 得る(場合が多い) ・定期アウトプット(例:週のバックログ完了数等)が マネージャの評価基準やノルマとなる ・マネージャはメンバーの作業を決める リソース配分≒「投資」を行う ・「投資」の結果で継続の判断をする
  7. 7. ビジネスとマネージャの背景 開発 チーム 開発 ① 開発 開発 開発 リソース アウトプット 開発 マネージャ リソース 割り当て マネージャは チームメンバーを 作業に割り当てる ⇒「投資する」と考える
  8. 8. ビジネスとマネージャの背景 開発 チーム 開発 ① 開発 開発 開発 リソース アウトプット 開発 マネージャ チームの定期アウトプット ⇒スループットが マネージャ評価となる (ことが多い)
  9. 9. ビジネスとマネージャの背景 顧客 成果物 対価 開発 チーム 開発 ① 開発 開発 開発 リソース アウトプット 開発 マネージャ 開発 ② 開発 ③ まとまった成果物を 顧客へ届け、その分の 対価をもらう
  10. 10. ビジネスとマネージャの背景 顧客対価 開発 チーム 開発 ① 開発 開発 開発 リソース アウトプット 開発 マネージャ 開発 ② アウトプット 増やして 出世だ! 成果物 チームの定期アウトプット ⇒スループットが増えると 同一期間で組織が 獲得できる対価が増える。 ⇒マネージャの評価は定期 のチームアウトプット(が多い)
  11. 11. チームとマネージャの対立 顧客対価 開発 チーム 開発 開発 開発 自動化 リソース アウトプット 開発 開発 開発 リソース アウトプット 開発 マネージャ 自動化大事 なんです! 成果物
  12. 12. チームとマネージャの対立 顧客対価 開発 チーム 開発 開発 開発 自動化 リソース アウトプット 開発 開発 開発 リソース アウトプット 開発 マネージャ 自動化やめたら その分アウトプット 増えるんじゃね? 成果物
  13. 13. マネージャの頭の中 マネージャ 全員が開発に専念すれば納期に間に合う 毎日の進捗チェックを強化しないと テストまだ終わって無いのか… 今週の報告、スケジュール遅れてるなぁ テスト 進捗管理 報告 自動化
  14. 14. マネージャの頭の中 マネージャ 全員が開発に専念すれば納期に間に合う 毎日の進捗チェックをやらないと テストまだ終わって無いのかな… 今週の報告にはアウトプット足りないかも テスト 進捗管理 報告 自動化 コンフォートゾーン:自分の経験や知識があり、 因果関係を予想することのできる範囲 この外の部分は簡単には理解されづらい 現在は自動化が範囲外と なることが多い
  15. 15. マネージャの頭の中 エンジェル マネージャ テスト 進捗管理 自動化 こんな人 めったにいない デプロイで毎回同じ作業。無駄だし大変。 余計な作業を減らして開発時間を増やそう! たまに改修でXX機能のふるまいが変わる? ⇒自動化で救うことが出来れば! メンバーの 無駄作業 削減
  16. 16. 抵抗の6階層 問題 ソリュー ション 解決策 実現 1.問題の存在に合意しない 2.ソリューションの方向性に合意しない 3.ソリューションが問題を解決できると思わない 4.ソリューションの実行でマイナス影響が発生 5.ソリューションの実行を妨げる障害がある 6.その結果起こる未知のことへの恐怖 マネージャは自動化が無い状態で どんな問題があるか認識していたか? 現場は自動化にて 開発状況が改善した と感じていたか?
  17. 17. 本当に価値があれば ・現場メンバーが感覚的及び数値的に自動化 継続にかける時間以上の効果を感じていれば、 マネージャに逆らってでも使い続ける。 ・本当に効果が数値的に見えている条件下で マネージャは文句を言うことは出来ない。 やりたい活動をする、チームを守るためにも 数値なりでの説得材料を持つことが大事
  18. 18. 参考 儲け:大 儲け:小 効果得るまで 長期 効果得るまで 短期 マネージャは(任期内に)儲かり、 そのロジックが明らかで 数値の根拠もあれば受け入れる。 現場では効果が得るまで短期で 実感できるものを好む (数値でなく定性的で良い場合もある) マネージャ 現場
  19. 19. 自動家は見た ~自動化の現場の真実~ SIDE:マネージャ その2 .reviewrc -> おいしが 水野 昇幸 (@NoriyukiMizuno)
  20. 20. 2014/6/28 Asian Automation Aliance 自動化の 価値は 人によって 変わる 本当?
  21. 21. ビジネスとマネージャの背景 顧客対価 開発 チーム 開発 ① 開発 開発 開発 リソース アウトプット 開発 マネージャ 開発 ② アウトプット 増やして 出世だ! 成果物 おさらい
  22. 22. ビジネスとマネージャの背景 顧客対価 開発 チーム 開発 ① 開発 開発 開発 リソース アウトプット 開発 マネージャ 開発 ② アウトプット 増やして 出世だ! 成果物 (組織にとって評価基準は異なるが) 最終的に確実に儲かるコトが 分かって否定する人はいない
  23. 23. ロジック検討 組織でお金が儲かる 支出 収入 自動化 XX構築 XX作業削減 アウトプットXX倍 投資に対するペイバック 顧客 成果物 対価開発 ① 開発 ② 開発 ③ < 顧客対価 開発 ① 開発 ② 成果物 自動 化 Before After
  24. 24. 顧客対価 開発 ① 開発 ② 成果物 自動 化 ロジック検討 組織でお金が儲かる 支出 収入 自動化 XX構築 XX作業削減 アウトプットXX倍 投資に対するペイバック 顧客 成果物 対価開発 ① 開発 ② 開発 ③ 3回のイテレーションで成果物を 出していた状況が 2回のイテレーションに変わると、 (理論上)同一期間で 1.5倍の対価を獲得できる。 そのための初期投資、保守費用 は払っても良いのでは? < Before After
  25. 25. こちらなら? 顧客対価 開発 チーム 開発 開発 開発 自動化 リソース アウトプット 開発 開発 開発 リソース アウトプット 開発 マネージャ とりあえず 続けてみるか 成果物 自動化があるために XXXという作業時間が減って 現在のアウトプットが 出ているんです! このように数値にも出てます
  26. 26. まとめ ・「組織が儲かる」ことからロジックを整理 することで、人によって変わらない客観的な 説得材料を構築することが出来る。 ・実施する活動から効果までのロジックを 構築して数値的に説明まである条件では、 心理的な拒否があっても断ることが出来ない。 ※コンフォートゾーンや抵抗の6階層、マフィアオファー といった概念も役立つかも コンフォートゾーン外の 人の説得は大変
  27. 27. 理解を得るためのベース作り 自動化でより良くなる事例がたくさんあるならば マネージャ側にも効果を伝えやすくなる。 多くの人が紹介する自動化での事例を活用することで、 現場からマネージャへの数値的な説明も出来るように! 自動化の価値が沢山示されれば、より事例が増えれば わざわざ説明のためのコストが減る ⇒自動化の事例をカンファレンスでたくさん紹介しよう!
  28. 28. たとえば「テスト設計」 昔は「テストなんか設計する必要があるのか?」 という状況が変わってきている。 「自動化」に関しても同じ方向になるといいね! テスト設計? なにそれ? 意味あるの? 10年前 テスト設計 大事だね 現在
  29. 29. ありがとうございました! みんなの失敗した話も共有できるとイイね!
  30. 30. 参考文献 •関西風テスト自動化パターン https://github.com/KenColle/AutomationPatternLanguage http://www.slideshare.net/Posaune/ss-36420230 •抵抗の6階層 http://www.goal-consulting.com/solution/t-process.html •ザ・チョイス (コンフォートゾーンの説明)

×