この記事について
2018/07/19に開催されたAgile Japan 2018
参加して私が感じたことをまとめます。
自分の中のキーワードは「チーム」と「人」
私が思うに、アジャイルのプラクティスはチームにフォーカスを当てている印象があります。
チームのあり方、強いチーム、というテーマのセッションがいくつもありました。
チームの中の人がどれだけ成長し、成果を挙げられるチームを作っていけるか、ということも重要だと感じています。
チームの観点から見たモブプログラミング
基調講演のWoody Zuillさんの講演
印象に残った言葉は、Question Queue Time、Flow of the workです。
Question Queue Time
キューがたまると、必ずマルチタスクになってしまう
質問の待ち時間に別の作業を行うことになるため
チーム全員で作業を行えば、Questionの回答はすぐに得られる（はず）のでQueueがない
これによって、チームが進める仕事のフローが１本できれいにながれるようになる
Flow of the work
とすると、その１本をいかに速く流せるか、というのがポイントになりそうで、そこで登場するのがフロー状態
フロー状態は心理学者のミハイ・チクセントミハイが提唱したもの。
https://ja.wikipedia.org/wiki/%E3%83%95%E3%83%AD%E3%83%BC_(%E5%BF%83%E7%90%86%E5%AD%A6)
個人のフロー状態は、スポーツ選手の例などで最近良く耳にしますね。
チームのフロー状態という考え方が、私にとっては新鮮だでしたが、けど、その事例にロックバンドを出されたときに、ストンと腹に落ちました。
互いに作業しあって協同で作業を進めていく。この「流れ」を「フロー状態」にしていこう、というのがモブプログラミングの効果なのかな、という理解をしました。
人月見積りが阻害要因ではないか？
モブプログラミングの話をするときによくある質問は「みんなで同じことをすることで生産性は落ちるのではないか？」ということだそうです。
確かに、効率重視で考えると、作業分担してチーム内で並行作業するほうが効率が良いように感じます。SIerの私からすると、その点でモブプログラミングに疑問が浮かぶのは確かです。
その違和感を引き起こす原因は、「人月での見積り」なのではないか、と思いました。
人月見積りだと、一人当たりの時間当たり成果物量で考えるので、並行に作業して一気に片付けていくことが基本形になります。工場で一日あたりに製造できる製品の量、というのが人月見積りのモデルになっていると思っているのですが、ソフトウェアは毎回やることが異なるので、そうそう数字どおりにはいかないですよね。
効率よりも効果
モブプログラミングは、効率というよりは効果を求めていくものなのかな、と感じました。
・チーム全員参加で知識を共有する
・感動を共有する
・チームとして、達成できる成果が大きくなっていく
・もちろんQueueも発生しない点での効率の良さもある
効果的なアウトプットをタイムリーに出せるチームというのがアジャイルなチームだと思うので、その達成の方法としてモブプログラミングは効果的だと感じました。
おわりに
やはり、チームや人をちゃんと見たプラクティスになっているな、という印象で、自分の中のキーワードに戻ったところで、この記事を締めくくります。
あくまで主観なので、ご意見などもいただけると幸いです。
Agile Japan 2018についてはこちらを参照。
https://www.agilejapan.org/index.html