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