アジャイルと縁がない大学生が「Agile Japan 2018 北陸(富山)サテライト」に参加して学んだこと
はじめに
どうも、最近朝が寒くてベッドから出られない僕です。
早速ですが皆さんは「アジャイル」という言葉をご存知ですか？
はじめて聞いた方のために簡単に説明すると、ソフトウェア開発をより効率的に行う手法のことです。
大変有名なものらしいのですが、僕にはつい最近まで馴染みがないワードでした。
知るキッカケになったのは、しばしば話題になっている「カイゼン・ジャーニー」という本です。
この本では、さまざまなアジャイル開発のプラクティスや運用の例が紹介されています。
とても素晴らしい本だったので、影響されやすい僕は読み終わるとアジャイルに興味津々でした。
というわけで、近隣でアジャイル関係のイベントがあると聞きつけて参加してきました。
ここからは、そのイベントでの学びや所感をまとめていきますよ！
基調講演1 モブプログラミングと”フロー”の力
最初のスピーカーは、30年以上プログラマーを経験して現在はアジャイルコーチをしているWoody Zuill 氏でした。
タイトルにあるように話のメインはモブプログラミングです。
モブプログラミング（Mob Programing）
開発に必要なスキルや知識を持っている人を集めて、同じことを、同じ場所で、同じときに、同じコンピューターで行うプログラミングのこと。 メンバーはドライバー（操作する人）とナビゲーター（指示を出す人）に分かれて一定時間ごとに交代する。
講演の内容を振り返って、以下の2点について自分なりに噛み砕いて紹介します。
- モブプログラミング
- フロー
モブプログラミング
Woddy 氏はモブプログラミングを紹介するときに、いつも同じ質問をされるらしいです。
"How can we be productive with 5 people at one computer?"
訳：「1つのコンピューターに5人が集まっていてどうやって生産的になれるのか？」
この質問が浮かぶのは当然でしょう。
単純計算すると人手が1/5になるので、私も本当に生産性が向上するのか懐疑的になってしまいます。
残念なことにその質問には答えられないが、どうやらモブプグラミングによって生まれる相互作用のおかげでうまくいくらしい。
そこで、W・エドワーズ・デミングの「正しい質問をしなければ、あなたは何も見つけることが出来ない」という言葉の通りに、さきほどの質問を正しいものに変えましょう。
「1つのコンピューターに5人が集まっているのに、どうやって効果的になれるのか？」
さらに、その質問を反対から捉えて
「一緒に働くべき人たちが分かれて別々に仕事をする場合に、効果的になるにはどうすればよいのか？」
と考えます。
調査すると「分かれて仕事をすることで効果的でなくなる要因」はいくつも挙げられましたようです。
しかし、モブプログラミングならその問題のほとんどを解消できます。
今回は、モブプログラミングの効果をわかりやすく解説するために「バリューストリームマップ」が紹介されました。
バリューストリームマップ（Value Stream Map）
仕事の流れを見える化するプラクティス。 プロセスタイム（プロセスを実行している作業時間）、リードタイム（次のプロセスに移行するまでの所要時間）の2つを分けて書き出すことで、ムダを発見して業務の改善案を導き出すことができる。
言葉だけでは伝わりづらいので、実際に使われた資料をお見せします。
ここでは「1時間に1つの問題が起きるとして、質問への返答を待つ時間がどれだけあるか」を例にしています。
緑線がスムーズに仕事をできている時間で赤線が待ち時間（Question Queue Time）です。
- 待ち時間が2分ならば1日に16分
- 待ち時間が10分ならば1日に70分
- 待ち時間が1時間ならば1日に4時間
- 待ち時間が1日ならば丸1日
わずかな時間でも積み重なると結構な時間になるのがわかります。
待ち時間を他の作業で埋めればムダな時間を過ごすことはなくなりますが、根本的な解決にはなっていません。
この問題をいとも簡単に解決するのがモブプログラミングです。
開発に関わる人が1か所に集まれば、当然待ち時間は0になりますよね？
これで開発のフローからリードタイムがなくなり、より効果的に仕事を進められます。
フロー
ここで2つ目のキーワードのフローが出てきました。
フローには「心理的フロー」と「リーンフロー」の2つがあります。
心理的フロー（Psychological Flow）
人間がそのときしていることに、完全に浸り、精力的に集中している感覚に特徴づけられ、完全にのめり込んでいて、その過程が活発さにおいて成功しているような活動における、精神的な状態をいう。ゾーン、ピークエクスペリエンス、無我の境地、忘我状態とも呼ばれる。（Wikipedia）
人はフロー状態になることでパフォーマンスを高めることができます。
さて、この心理的フローはチームでも作ることができるのでしょうか？答えは Yes です。
Jef van den Hout 氏の Team Flow: From Concept to Application（無料公開）が参考になるらしい。
また、個人のフローとチームのフローは両立することができる。
リーンフロー（Lean Flow）
製造業における作業の始めから終わりまでの流れ。
イメージしやすいのは先ほど紹介したバリューストリームマップです。
プロセスタイムを増やしてリーンタイムを減らすことが大切。
ここまでに紹介した3つのフローは以下の3つを達成することで実現します。
- 個人のフロー：参加者が安全に彼らの意見を言うことができる場
- チームフロー：チームで一緒にうまくやること
- リーンフロー：待ち時間をなくす
皆さんはお気づきかもしれませんが、モブプログラミングを導入することでこれらを簡単に達成できます。
最後にこんな言葉が紹介されました。
"The object isn't to make art, it's to be in that wonderful state which makes art inevitable."
訳：「大切なことはアートをつくることではく、自然にアートをつくることができるような素晴らしい状態になることだ」
基調講演2 JapanTaxiの挑戦
次のスピーカーは、日本交通株式会社の３代目である川鍋 一朗 氏でした。
講演を拝聴していて大変興味深い内容だったのですが、諸事情で公開されていないので詳細は控えます。
少しだけ言わせていただくと、話し方が上手くてメモを取れないほど引き込まれてしまいました。
出身がエンジニアではない方だったので、他とは違う目線のお話をされていたのも興味深かったです。
実践！モブプログラミング
2つの講演と現地に行かれた方のレポートを聞き終わると、参加者全員でモブプログラミングを体験する時間がありました。
はじめる前にルールを設定して、その後に言語とお題や必要なタスクについて話し合いました。
ルール & 決めたこと
- ドライバーとナビゲーターに分かれて行う
- 3分間でドライバーを交代する
- ドライバーの順番が次の人はすぐ交代できる位置に移動する
- 30分ごとに休憩する
- タスクが完了すると全員でバンザイをする
- 言語は Lua を使用する
- お題は「ポーカー」
必要なタスク（もっと細かったはず）
- 番号を表示する
- トランプ52枚を用意する
- トランプを1枚表示する
- トランプを5枚表示する
- 表示するトランプを被らないようにする
こんな感じだったはずです。
スムーズにいけばよかったのですが、いくつか問題が発生しました。
- 使用したマシンが MacBook だったので Windows 勢は基本操作さえ怪しい（最初はトラックパッドを切った Linux を使うという話もあった）
- そもそも Lua を知っている人がほとんどいない
というわちゃわちゃ状態でしたが、そのお陰か一体感が生まれて全員で楽しくプログラミングをすることができました。
その中でいくつか学びもありました。
まず、ドライバーはとにかく大変でした。
周りから色んな意見が出てくるので、何をすればよいのかわからなくなることがあります。
ナビゲーターはドライバーがわかりやすく発言するように心がけましょう。
次に、ナビゲーターはドライバーのマシンの操作に注目しましょう。
インデントに tab と space のどちらを使うかという些細な話から、エディターの使いこなし方まで人によってさまざまです。
もしあなたが初心者プログラマーなら、きっと熟練者の動きを見て学ぶことが多いでしょう。
もしあなたが熟練者プログラマーなら、きっと初心者にアドバイスをできるでしょう。
僕自身も学ぶことが多くて、このブログを書いている今も実践しています。
最後にモブプログラミングで使用した便利なサービスとツールを紹介します。
codingground
Java や Python といったメジャーな言語から、名前を聞いたことがないようなマイナー言語まで幅広くカバーしている Online IDE サービス。
モブプログラミングに関係がなくても、興味のある言語にサクッと触れるのが魅力的です。
mobster
GitHub で公開されているモブプログラミングをアシストするツール。
参加者、1人あたりの操作時間、休憩時間を入力すると画面を切り替えていい感じにタイムキーパーの役割を果たしてくれます。
まとめ
モブプログラミングはいいぞ、まだの人はすぐ試そう。
