2017-03-18 Productivity Engineering − Forkwell Meetup #4

https://forkwell.connpass.com/event/51332/

いつものごとくですが、雑なmemo。

～～～～～～～～～～～～～～～

■クックパッドにおけるモバイルアプリ開発の工夫　クックパッド @ichiko_revjune

リリース間隔　2週間から1ヶ月
関わるエンジニア　10名程度
リリース間隔の最初にキックオフを実施

朝会をSlack上に移動
　（会社がフルフレックスになったこともある）
　観察に得られる情報がなくなる（順調か、疲労はなど）

■Effective Retrospective　アトラクタ @ryuzee

Retrospective　＝　ふりかえり
有名なのはKPT
目的
　・もっとうまくできるように
　・強制的に仕事を停止する
　　　忙しいときほど止まれないが止まらないと事故が起こる
　　　強制的にとまって冷静に考える時間を作る

ふりかえりにおける大前提＝心理的安全性
　立場の上下関係、人事評価の恐怖があると本当の問題にたどり着かない
　まずはその場を安全にすること
　「あなたvsわたし」を「問題vsわたしたち」にする

「アジャイルレトロスペクティブス」
　１）場を設定する
　　会議の冒頭に全員に口を開いてもらうと主体的参加度が上がる傾向
　　進め方を説明
　２）データを収集する
　　意見だけを元にすると解決策が危うくなる
　３）アイデアを出す
　４）何をすべきかを決定する
　　誰がいつまでにやるのかをはっきりする
　　「拳から5本指」
　５）終了する
　　記録を残す

失敗例と対策
　KPTばかりではなく、やり方を変える（タイムライン）
　　KPTは断片になりがちなので、ときには全体をみる
　場所を変える

いい話を若干大げさに褒め称える
早めの時間にやる

■自己言及的なチームをつくる　GMOペパボ @june29

自分たちに自覚的である、会話している
自分たちの問題を解決できるのは自分たちの行動だけ
自力で前進できると意識することも重要
いちばん難しいのは無関心
「加点方式」でチームを捉える　信頼貯金をためる
　「減点方式」チームはトラブルを隠す

自分たちの日々を自分たちでデザインする

言葉を尽くす、行動で示す
　チームにとっての良さを言葉にする
　褒める
　率先して行動する

個の価値観の押しつけはチームの価値観を壊す

Google Spreadsheet as Cron（はてな）

「思考停止するな」

■最速で価値を提供する　ネクスト @masamichi

狩野モデル
　魅力的品質
　性能品質
　当たり前品質

ISO/IEC25010
品質の仕様化
　言語化されない品質は作られない
「品質は誰かにとっての価値である」（Weinberg）

トレードオフではなくANDの発想（ビジョナリー・カンパニー）

■ペアプログラミングの使いどころ　タワーズ・クエスト @t_wada

ペアプログラミングのやりかた（大事なこと）
　喋る
　　（考えを声に出す、時にはホワイトボードなどに書く）
　喜ぶ、
　交代する（例：テストを書く人と実装の人をわける）
　でかいディスプレイお勧め
　
いつ、誰とやるか
　チームに新しいメンバーが入ってきたとき
　不具合修正
　新機能作成
　日ｏｒ週に一回決まった時間に

なぜやるか？
　稼働率よりスループット
　ペアプロは常にレビューを回すプロセス
　書き終えた後の指摘より書いている最中の指摘のほうが受け入れやすい
　スキル伝授にペアプロ最速
　　コードを書く瞬間の思考にアドバイスを貰えるから

FAQ
　コストが倍になるのでは？
　　エラーを超初期に直せる。将来の時間が省かれた形でやってくる
　　現実として、コストは1倍と2倍のあいだ
　開発環境がバラバラ
　　「お前のこのみとチームの成功とで大事なのはどっちだ？」（Kent Beck）
　揮発性が高い
　　（2人の間だけで、チームの共有にならない）
　　→モブプログラミングというやり方
　上級者にメリットあるの？
　　「教えることが一番の学び」教えることで知識が整理される（きのこ80）
　プレッシャーが強いから苦手
　　心理的安全性が一番大事
　　個人を尊重する
　　　全員ができるものではない

ソロプロはOSS活動に費やす

「食わず嫌いはもったいない」（塹壕からのScrumとXP）

質疑応答
　経営層への説得方法は？
　→「許可を求めるな、謝罪せよ」
　　リファクタリングも
　　また、短時間だけ導入するのもあり
　　不具合修正はペアプロで、とかも説得しやすい
　　　（不具合修正はチーム成長のチャンス）