スライド
カンファレンス
- カンファレンスは発表者に直接聞けるのが売り
現地
- 真ん中の写真は従業員ボード
- 自分ができること、出来ないことを書いている
- 付箋には、他者からのコメントが書いている
- 右側の写真は技術について、TDDとかBDDとかカンバン、リファクタリングとか
Hunter社のモブプログラミング
- 社内に6つぐらいモブが存在する
- 川口さんが現地に行った時には8つぐらいになってた
- 1つのモブに付き3〜5人
- 隣のモブは全く別の技術領域
- CDの話
- UIの話
- サーバーサイド
- 製品の制御系
- Android
- 常にモブプログラミングをしている
- この時間はモブプログラミング、というような働き方ではない
環境
- 大きいモニタ2枚と、長机
- 楽天では、ディスプレイ2枚とPC
- エンジニアは1日中タイピングしていることが無くて、だいたい調べているはず
作業内容
- 分担を決めてやると、他作業者の同期の時間がかかる
- モブの場合、常に同期をしている状態
- お客様のところへ行くと、人事の人がほしいと行っているものに、発注者と利用者が違うので、欲しいというものに違いがある
- モブプログラミングでは作る量に限りがあるので。
- 業務担当者から要望が出ない
- 業務担当者はソフトウェア開発をしているわけではないので、時間がない
- バグ＝思いもよらない挙動なので、予想できない
- コードの量に比例してバグの量が増える
- 一番良いのは作らないこと
- やり方を直すようにしている
- 打ち合わせの後に、伝言ゲームを使ってクレームが来た
- クレームがくるのは良い。伝言ゲームを辞めろ
10年ぐらい出てから気付いたこと
- お客様は成果物の想像が出来ない
- 引き継ぎは問題の強調解決しないとできない
- 2週間や1ヶ月では、業務手順は引き継げるがスキルは引き継げない
- 問題が出てきた時点で、どうやって解決するか話し合う必要がある
- 人は忘れやすい生き物なので、備忘録は必要
- 手順を書くだけでなく、どうしてその手順が必要なのか書く
- 情報ラジエータとして壁に貼る
- モブプログラミングはコード・情報・情報ラジエータ・ヒトが必要
取り組んでいること
- 全員で客先に行く
- 「来週は何がほしいですか？」と聞く
質問
- 誰もいなくなっちゃう場合には怒らないのか？
- モブプログラミングは評価と紐付いている。誰もいないところに参加するだけで、評価が上がる
- リーダーはいるか？
- それっぽいヒトはいたが、明確に決めているかどうかは分からない
