行きました。JavaプログラマのコミュニティにJavaなんか触ったことないのに参加するっていう。ビビりながらの勉強会でしたが、JavaJavaせずに終えたし、新しい発見も得られて大変有意義なお時間でした。
モブプログラミング
モブプログラミングとは「複数人（5人とか）で1台のコンピュータを使ってプログラミングをする」開発手法。
Agile Japan 2018の基調講演モブプログラミングと”フロー”の力の公演動画を視聴した。
メモったこと。
- Driverが1人、Navigatorが4人、この体制でアイディアを共有。お互いに伝える努力、理解するための努力が必要になるはずで、そのためにコミュニケーション量が増えるし、インタラクティブな仕事の進め方に繋がるっている。気がする。
- チームメンバの多様性でアウトプットが出せる。
-
question queue time質問の在庫をかかえると非効率。待ち時間中に別の仕事するのは表面的なものに過ぎない（現象の解決のみ）。→プロダクトオーナーが常にいれば、在庫を持たずに済む。そういう体制で。
- Why?が大事。本質を問うべし。より良い質問に価値がある。「正しい答えを出すこと」では変革は起きない。
スクラム開発
メモったこと。
- ”チーム”は”グループ”ではない。
- チームは共通の思いや方針のもとに動く。
- チームワークが良い→自己組織化されている。フリーライダーがいない。自己犠牲。
- よくある科学的管理法（テイラー主義）。
- X理論とY理論
- 働き方に対する2つの見解。
- X理論
- 人間は仕事嫌い。できることならしたくない。
- 管理、命令されないと十分に働かない。
- Y理論
- 目標達成のために努力する。
- 自己管理。自己統制。責任感。
- 良いチームは「問題解決能力」が高い。
- 複雑系、不確定な課題にアプローチできる。
- フィードバックの繰り返し。
- チームの発達段階。
- フォーミング（形成期）
- ストーミング（混乱期）
- ノーミング（標準期）
- トランスフォーミング（達成期）
- ストーミングをビビっちゃダメ。
- トランスフォーミングの段階に達したチームは維持すべき。なるべく解体しない。
個別最適≠全体最適
個人的に一番インパクトがあったのが「コイン渡しゲーム」のワークショップ。 "スループットの最適化"が顧客へのデリバリー速度を短縮する、開発者個々の最適化（工数短縮）とはイコールではない、を体験できた。
- 4人1グループで実施。
- 役割分担：顧客、作業者A、作業者B、作業者C。
- 20枚のコインを準備。
- 顧客 → 作業者A → 作業者B → 作業者C → 顧客、という流れでコインを渡していく。 作業者は、渡されたコインを裏返しにして次の作業者（最後は顧客）に渡す。
- コインを渡す単位を変える。①20枚（練習も兼ねて）、②5枚、③1枚、の3パターンを試す。
- ストップウォッチで以下の時間を計測する。
- 顧客がコインを渡し始めて、「最初」のコインが戻ってくるまでの時間
- 顧客がコインを渡し始めて、「全て」のコインが戻ってくるまでの時間
- 作業者A、B、Cが、それぞれコインを処理していた時間
計測時間は以下を表します。
- 顧客に対して機能（一部）をデリバリーするのにかかった時間
- 顧客に対して全ての機能をデリバリーするまでにかかった時間
- 開発にかかった工数
で、結果は以下。面白い。
| コインを渡す単位 | （練習）20枚いっきに | A:5枚ずつ | B:1枚ずつ |
| 作業者Aの作業時間 | 20秒 | 20秒 | 26秒 |
| 作業者Bの作業時間 | 23.1秒 | 29.8秒 | 32秒 |
| 作業者Cの作業時間 | 24秒 | 21.6秒 | 34秒 |
| 作業者Dの作業時間 | 19.8秒 | 22.5秒 | 36秒 |
| 最初のコインが 顧客に返るまでの時間 | 90.2秒 | 20.4秒 | 7.3秒 |
| 全てのコインが 顧客に返るまでの時間 | 90.2秒 | 49.9秒 | 32.7秒 |
- 各作業者の作業時間（工数）は5枚ずつのときの方が短い。
※20枚ずつのときの方が短い作業者もいるが、この時は趣旨を理解できていなくて競争と勘違いしていた。明らかに作業時のテンションが違った。
- いわゆる個別最適、な状態。
- 次の作業者にコインを渡した時点で、まだ前の作業者からコインが回ってこずに"待ち"が発生していた。
- 1枚ずつ渡す方が、顧客へ最初の価値をデリバリーするまでの時間、全てをデリバリーするまでの時間が短い。
- 最初に価値をデリバリーするまでの時間は1/12、全てをデリバリーするまでの時間は1/3になった。
- コイン（タスク）が滞ることなく次の人に流れていく。慌ただしい。
他のグループも同様の傾向となったので、たまたまではなく法則性があるものだと思います。
チームとして「仕事」を最速で遂行するならフロー最適化を目指すべし。 ヒトの稼働率ではなく、仕事（タスク）が得られるリソース（ヒト）の時間を最大化する。停滞させない。
以下も参考になりました。
www.slideshare.net
思ったこと
アジャイルを知れば知るほど思うのが、特定のマインドセットを持ったヒトでないと取り組めない（アジャイルの考え方を採用できないだろうな）、ということです。 向いているのはY理論なヒト。「指示を出してくれないと動けない」、「質問したら正解を答えてくれないと」、みたいな考え方で仕事をするヒトでは無理。（そして、そういうヒトの仕事はAIに取って代わられる。）
で、マインドセットって後から開発するのが難しい。最初から備わっているヒトを採用するか、新人研修時に徹底的にマインドセットを叩き込む（刷り込み、洗脳とも言う？）しかないのではないかと。 そういう意味で、人事部って重要な部門なんだなーと再認識しました。そして人事部に優秀（必ずしも成績優秀とイコールではない。自己犠牲的な動きは業績として認められづらい。）な人材を配置する必要がある。頑張れ人事部。超頑張れ。
