vocho’s blog

2015年4月、30代で組み込み開発をやってる企業へ転職しました

XP祭り関西2015

XP祭り関西2015に行ってきました。以下メモです。

2015/04/11 XP祭り関西2015

10:30   「メンバーの成長を促進する組織マネジメント」
        細谷泰夫さん 三菱電機
        
        XP祭り関西2006 ワッハ上方
        
        勝手題「新人が多く、入れ替わりの激しい環境で、実践した、新人を成長させる開発手法(アジャイル)」
        
        人工衛星や通信関係の開発
            ソフト設計部門とソフト開発部門がある、開発部門は製造部門でもある
            ハード部門の新人もソフト部門で1~2年新人教育を行う
                ミッションは事業に貢献する人材を輩出すること
                すぐに貢献することが難しくても、最初の一歩を手助けしたり確率を上げることを目指す
                価値ある成果を生む経験を積むことでデキル実感を生んで、その後を歩んでもらう
                
                開発課は20人中15人は新人で、毎年10人が卒業していく
                
                通常の2倍の効率、かなりの高品質であることを目標とする
                
                失敗している余裕はない
                最初のプロジェクトで急激な成長が必要→実際にほぼ達成されている
                
                短期間での繰り返しとフィードバック
                
                新人の良いところは固定概念がないのでTDDでもなんでもそういうもんだと受け入れる
                
                効率と高品質を実現する方法
                    メタプログラミング DSLでコードジェネレート
                    テスト自動化
                    サーバー構成自動化
                
                依頼する側の不安→依頼する仕事の質→メンバーの成長→?(メモし忘れ)→戻る
                
                Fearless Journey
                
                改善のスコープを小さくする
                
                情報収集、手段の収集
                こういうのは、こういうことに役立つ手段なんだな
                課題と手段のマッチング
                
                チャレンジすることにコミットメントしてもらう
                
                ツール
                    スクラム、XDDP
                    TDD
                    TFS, Test Manager
                    Sphinx
                    xtest
                    Friendly
                    Specflow
                    Cegtest
                    Chef, Vagrant, Docker
                
11:20   「アジャイル導入の本当の価値」
        谷口光さん @tanigon フリュー株式会社(プリクラの機械やアニメの製作)
        
        マネジメントバイアウト
        
        勝手題「チームの自己組織化を促すマネジメントの心構え」
        
        なぜアジャイルを導入する?
            ビジネスを成功させたいから
        今うまくいってないと思っていて、うまくいくようにしたいと思っている、改善
        
        プラクティスから導入するとろくなことにならない
        
        アジャイルは「価値・原則」だけ、テンプレがXP、スクラム
        
        自己組織的なチーム
            自分で考えて自分で動くチーム
        
        自己組織的なチームを許している会社か?
        
        マネジメントは自己組織的なチームが動けるように「支援」しよう
        
        マネージャーがすべきこと、させるべきことは、
        「ふりかえり」PDSA(Plan Do Study Action)
            フィードバックが大事
            KPTがおススメ
                Keep (続けたいこと、良かったことが大事、審美眼を養う)
                Problem
                Try
        
12:10   休憩

13:20   「アジャイルなソフトウェア開発 50分で総ざらい」
        津田義史さん    Citrix
        
        タイムボックス(別名:バケツ)
        
        タイムボクシング
            時間のかかることを全部タイムボックスに詰める
            丁寧にやる
        入らないとき
            1.無理やり(品質)
            2.大きい箱へ(延期し続けると終わらない)(納期)
            3.全部入れることを諦める(範囲)正解:◎
        マイルストーン
        スプリント1か月
        イテレーション数日~数週間
        
        品質
            用語
                デリバー
                    価値あるものをこの世に生み出す
                デリバラブル
                    成果物
                出口条件
                    数値目標、ゴール、バグの数を0にする、Xms以内に動作するようにする
            スプリントは品質を上げるために繰り返すのではない
            スプリント毎に高品質なものを出す
        納期
            用語
                ケイデンス
                    小さい方がいいよね
                バックログ
                    残りの作業
                    在庫
                    滞空中の未処理分(ブロッカーがいて、着陸できない)
                バーンダウンチャート
                    フライトパス実際
                    グライドパス理想
                ZBB(Zero Bug Bounce)
                    バグを意図的にゼロへ減らす日
                ブランチの戦略
                    ペイロード
                        積荷
                時刻表のメタファ
                    定刻の列車へ積荷を載せるのが難しければ次の列車に載せる
            
            全スプリントの長さは一定でなくてもいい
                決めたら変えない
            
            パント
                バグをトリアージして、スプリントバグは直して、プロダクトバグは次のスプリントへパントする
            ストレッチゴール
                見積もり時に便利
            スタック・ランク
                詳細な優先度
        タイムボックスの本質
            入れるものと入れないものの2つにわける
            スプリントバックログ
                いれる
            プロダクトバックログ
                いれない
            2つに分けよう
                タスク
                フィーチャー
                    機能
            バグ
                トリアージ(フランスの農場で傷んだものを捨てた判断のこと)
                    深刻度と優先度は別
        ZTB(Zero Ticket Bounce)
            チケットを意図的にゼロへする日
        
        
        アジャイル
            グッドプラクティスをあつめたもの
                継続的インテグレーション、デイリービルド
                リファクタリング
                テストファースト
                チケットファースト
                ふりかえり
        アジャイルの功績
            名前を与えて形式知へ認知した

14:20   企業セッション
        川端光義さん    アジャイルウェア
        
        予算を小さくするには
            お客さんにテストを負担してもらう
        顧客満足度を向上
            リリースを前倒しするだけで信頼を得られる
            即、バグ対応し、即リリース
        GitフローからGithubフローへ
            レビューせずに、後で出たバグを修正するよりも
            結局、プルリクエスト後にレビューを挟む方が効率がいいし、気分が良い事が分かった
        
15:00   発表者全員でパネルディスカッション
        司会:西丈善さん
        
        戦略と戦術
        
        戦術ありきでとれる戦略もある
        
        想定外の状況が起こるとテンパるので、選択する際の方針を決めておくと良い
            例えば、透明性が高い方を常に選ぶ
        
        見積もりのバッファが多重になると機会損失につながりそう
        
        マネジメントの仕事はゴメンナサイをすること
            賛成してもらわなくてもいいので納得してもらう
            下への説明で上のせいにしない
            上への説明で下のせいにしない
        
        ゴールは達成評価できるものにする
        
        質問
            経験以外から学べることは?
                本→本を買ってね
                ない
                    練習の質を高める、少しレベルの高い練習をする
                    練習してみる、練習したことを意識しないで身に付くレベルになる
                ほかの分野の人と話す
                妄想力
            撤退の判断が難しいのですけどアドバイスを下さい
                撤退しやすい時に撤退する
                    組織でまだ迷っているときに撤退する
                    組織的に投資され始めると撤退しにくくなる
                実際に撤退した際の判断
                    埋没コストとこれからの運用コストを比べる
                    シビアに天秤計算する
                    赤字になりそうならやめる
                好きか嫌いかで決める
                    会社の文化ってあるよね
                    好きなら、利益が少なくても続ける
                全速力で走っている最中に撤退したことはない
                うまくいかなかったとき
                    ゴールを変更できるなら変更する
                    真面目に始末書を書く
                        真っ当な理由をかけるようにしておく