はじめに
※この記事は (レポート)Developers Summit 2018(1日目) の続きです。
2018/02/15(木)～02/16(金) に開催された Developers Summit 2018 のうち、2日目のレポートを記載します。
参加した講演
16-C-1 実況パワフルモブプログラミング - Rakuten Super Englishにおけるモブプログラミングという働き方 -
「実況！パワフルプロ〇球！」にもじったSEから始まりました。
楽天の開発グループによる、モブプロの様子を見ることのできる講演です。
及部さん、川口さんの実況により、モブプロのやりかたや意図をつかむこともできました。
「雅叙園で普通に仕事をしにきたのは我々が初」という、ぶっ飛んだ発想も素晴らしい。
この講演では、3人の開発者が「学習者用のwebページに学習時間の総計のグラフを表示させること」をゴールにモブプロを進めていきました。大まかな流れは以下のとおりです。
1. 打ち合わせ開始
「今日やることの確認」から始まりました。モブプロでは全員が同じ作業をやっているので、デイリースクラムや朝会のような「昨日やったことの確認」は不要とのこと。非常にスピーディにやることの話し合いがされていきました。話し合いでは画面設計のイメージや仕様をnu-boardに描いてサクッと決定。その後、作業を細かいサイズに分割し、皆で合意します。1作業5分程度の作業です。スクラムでいうスプリントプランニングをここで行うイメージです。ここまでなんと約1分です。
2. モブプロスタート
1名のドライバーと2名のナビゲーターに分かれて作業がスタートします。今回は計3名での作業でしたが、モブプロをするなら4～6名が上限、とのこと。PCを操作するドライバーは考えややろうとしていることを口に出して、ナビゲーターに意思を伝えたうえで作業を行います（ここはペアプロと同じですね。）
「言葉にすることによって、コードにする前に間違っていることに気付ける可能性が高くなる」とのこと。考えや行動を慣れが必要ですが、不毛な時間を割かなくてよいのは成程確かに。
3. やったー！
1つのタスクが終わると、全員で万歳して「やったー！」の声が生まれました（視聴者も一緒に）。こうすることでモチベーションupにも繋がりますし、みんなで作り上げた感・達成感が出てとてもいいですね。
4. ドライバーの交代
前のドライバーが疲れたり、一仕事終えたりするとドライバーが交代します。最初は時間を決めたり、区切りを決めて交代するとよいと思います。今回モブプロをやっていたメンバーは「俺に替われ方式」で、ドライバーをやりたい人が「ちょっとPC貸せよ」といって交代する方式でした。チーム間の信頼関係が出来上がっているのが見えてとてもよかったです。
5. 調査・スパイク
不明点が発生すると、みんなで手分けして調べます。こうすることで調べるスピードは格段に上がります。調べた内容はchatで共有され、情報がすぐに溜まっていきます。ペアプロであれば、調べる手順や検索の仕方などを学ぶために、調べるのも一緒のPCでやるという考え方もありますので、熟練度やスキルセットによって使い分けるとよさそうです。
今回はグラフを表示するためのライブラリを調べて、コピペするところまでを調査していました。
6. 相談
変数や関数の命名も相談しながら行います。そのため、変な名前になることはありません。
7. 即時フィードバック
タイプミスやエラーを起こしても、ナビゲーターが複眼チェックをしているので、すぐに気付きます。そのため、基本的な品質は高い状態に保たれます。
8. 2度目のやったー！
そんなこんなで二度目のやったー！が生まれます。
先ほど表示させたグラフに、サンプルの値を入れて表示させてみる、というところまで完成。ここまで15分ほどです。次に、実際に取ってきた値をグラフに表示するところまでを実装します。ドライバーもここで交代です。
9. 必要に応じて仕様の相談
次にどうするか、は必要に応じて皆で相談します。最初の相談のときと同様、nu-boardを使って相談が始まりました。方針もすぐに決まって作業へ。
10. エラーへの対応
更新したソースコードが誤っており、エラーが発生します。このときにもメンバーはどこが悪いのか、というのをエラーメッセージやソースコードを頼りに進めていきます。エラーの対処法自体は普段の1人での開発と何ら変わりはありませんが、複眼での確認ですので、ほんの十数秒でエラー箇所を特定。修正に入りました。エラーに対するスピード感もモブプロの利点かもしれません。
11. 3度めのやったー！
エラーの対応もすぐに終わり、実装完了です。聴講者がwebサイトに入れていたデータの集計値がグラフに表示されました。これで、元々想定していた作業が全ておわりました。やったー！
12. 次の新しい仕事へ
ここまで20分ほどですが、時間が多少余っていたので更に先に進みます。グラフに表示されたものの、1日のデータ数が大きすぎてグラフが見づらい、という結果に。それをどうするか皆で相談です。このように、予定していた作業が終わったら、どんどん次に何をするのか、というのを相談し、決めながら先へ先へと進んでいくのがモブの凄いところです。ただ、この問題結局解消せず、時間切れ。
13. 1日のふりかえり
今日やった内容をみんなでふりかえり、明日はどこからやるかを相談します。1日ごとにふりかえりをすることで、次の日に「前日何をやったか」の確認をする必要もありませんし、高速でカイゼンのループが回っていいですね。
講演の中では「ウォーターフォールでは作業を分解・計画して分担し、その後マージする。モブプロでは分担が必要ないから作業分解・計画自体も軽微で済む」という旨の話をされていました。確かに、常にモブプロするチームであれば、分担のための分担は必要なさそうです。
1点だけ気になったのは、例としてカンバンも不要！と述べられていましたこと。恐らく、週単位での細かなカンバンは不要になるかもしれません。ただ、1日／週の作業のマイルストンとしてのカンバンはあった方がチームのマネージャー(PO)やステークホルダーへの説明もしやすいでしょうし、チームのゴールを見失わないためにあったほうがいいのかな、と。モブプロの中でも作業分割をしてタスクの書き出しはしていたので、粒度は細かくなるのでしょうが、カンバン自体は強力なツールであることには変わりはなさそうだと感じました。
45分間という非常に短い時間でしたが、「これぞモブプロ！」というものを見ることのできた素晴らしいセッションでした。1ステップずつ動くものを作り上げていく様、そして皆で「やったー！」といって成果をかみ締めながらどんどん進んでいく様をリアルで見ることで、「私もモブプロいっぱいやりたい！」という気持ちになりました。モブプロするぞー！
[16-D-2 NRIの働き方改革 - 開発スタイルから文化まで変えた軌跡 -] (http://event.shoeisha.jp/devsumi/20180215/session/1675/)
資料は未公開のようです。
NRIがアトラシアン製品群(Jira, Hipchat, Confluence, BitBucket)を導入し、業務改善を行った、という話です。中川さんから導入にあたっての苦労や障壁などを聞くことができました。
アトラシアン製品群の話。私も使っています。導入の裏側に色々あったんだなぁ。（マッチポンプ）#devsumiD pic.twitter.com/3UCME6Iw3t
— びば（森のフレンズ） (@viva_tweet_x) 2018年2月16日
苦労した点は、以下の3点とのこと。
1. 反対勢力
ツールを導入しようとすると、「どうせすぐ新しいツールが出てきて、そちらを薦められて、今のツールは使わなくなるんでしょう？」「導入実績がないからダメだ」という反対勢力が現れます。これはプロジェクト内でもよくあることですが、全社的に導入するとなると反発はさらに大きそうです。反対勢力に対応するには「トップダウンでの導入」と「大規模プロジェクトでの導入実績を作る」ことを実施したとのこと。後者は地道な営業が功を奏した結果だと思いますので、血の滲む努力が垣間見れました。
2. 使い方が分からない、という問い合わせ
こちらもツールあるある。今までexcel管理／メール至上主義の文化だったところに先進的なツールを導入するわけですから、確実に不満や疑問は溜まっていきます。その対応としては、「ライトなツールから使ってもらう」ということ。チャットツール「HipChat」は使い方も簡単で、UIもシンプルなアプリケーションですので、HipChat→Confluence→Jiraの順に導入していくことで導入に関する心理的障壁を下げていった、というお話をされていました。確かに、弊社社内でもIP Messengerというツールはよく使われていたので、導入への心理的負荷はほぼなかったと思われます。細かい工夫ですが、ツールを使ってもらうためには必要な一工夫だと思います。
3. 現行保証
SIerでよく聞くアレです。現場ではexcelで管理しているから、excelで管理しているものをそのままJiraでも使えるようにしたい、といった要望が実際にあったようです。ツールを導入するときには、新しい業務フローを考えたうえで、うまくツールをカスタマイズして文化に合わせて導入していくのが大事だと私は考えています。中川さんが取った戦略もほぼ同じで、新しい業務フローを提案しつつ、必要に応じて専用プラグインを作っていった、とのこと。excel入力するとJira化できるツールも作ったようです…。こうした「誰もが嫌」と思えるツール作成すら、労力を惜しまず作っていったことが、社内での導入障壁を下げていくことにつながったのだと思います。
こうした壁を乗り越えていくことで、社内では8500人近くの方がJira / Confluence / Hipchatを使うようになった、とのこと。私もその恩恵に預かり、ツール群を使っている一人です。講演でも述べられていましたが、ツール導入前と後を比較してみると、確実にメールの量は減っています。また、excel管理時代に比べれば劇的に情報の管理は楽に・詳細にできるようになってきたと感じています。この恩恵を8500人が受けることになれば、途方もない時間分の生産性向上が出来たのではないでしょうか。
私も過去にexcel管理のプロジェクトをRedmine管理に移行した経験もありますが、反対勢力で心が折れそうになることもありました。ただ、この講演のように、ポリシーやビジョンをもって続けてきたことが実った、という事実が、同じ状況にある人たちに勇気を与えてくれると思います。
16-E-L 大規模ログ集約実現のためのアーキテクチャ～誰でも美少女になれるVRシステム「VR Live Studio」からお届け
資料は未公開のようです。
VR上にカメラ、モニタ、アバターを設置して会議ができるシステム「VR Live Studio」を使って、ログ集約のアーキテクチャの話をされていました。
VR Live Studioの様子はこんな感じ。
お、出て来た#devsumiE pic.twitter.com/374f8uBxIJ
— びば（森のフレンズ） (@viva_tweet_x) 2018年2月16日
twitterで#devsumi_gumi とハッシュタグを入れてつぶやくと、VR上に文字が降ってくる、という仕様。アイコンまで降ってくるほか、文字やアイコンはアバターがつかんで投げたり消したりできる。
VR Live Studioのインパクトが大きすぎて、最初の10分間は説明が頭に入ってきませんでした(笑)
Kinesisを使って大規模ログを処理しているようなのですが、中の人がアーキテクチャの処理パターンを教えてくれました。
fluent -> kinesis -> lambda(Go) -> BigQuery です。#devsumi_gumi
— cooldaemon (@cooldaemon) 2018年2月16日
ログを収集するサーバがログの分析や処理をするのではなく、ログを拾ってくるサービスを作って、「ログを収集だけするサーバ」と「処理をするサービス群」で分けることで、ログ収集サーバの「仕事し過ぎ問題」を解決する、というものでした。
中々興味深い話だったはずなのですが、なにせタイトルが美少女VR（中の人は隣でゴーグルつけて動いている）。その名前にホイホイ釣られていった人もきっと数知れず。私も「美少女VR」と、高柳師匠がファシリテーションするという内容だけ見て行ったクチですので、セッションが始まるまで「ログの話」というのを1mmも知りませんでした（清水さんごめんなさい）。美少女VRの破壊力と集客力恐るべし。
VR Live Studioはコチラから色々見れます。マスコットキャラクターの「あいえるたん」がかわいいです。
16-A-3 エンタープライズアジャイル
川口さんより「アジャイルエンタープライズ」の話。
エンタープライズの中でアジャイルをやるのではなく、アジャイルの中でエンタープライズをやろう、という主張がされていました。エンタープライズが立派なビルに、アジャイルがゴジラに例えられ、絵本形式でスライドが進んでいきます。その中で、アジャイルが成長した（第四形態）ときに、エンタープライズの中でアジャイルをしようとして、エンタープライズ（ビル）もアジャイル（ゴジラ）も共倒れになってしまいます。
今、必要とされているのはエンタープライズにアジャイルを適用しようとするのではなく、アジャイルの価値原則プラクティスのなかで、エンタープライズビジネスを適用させること。ちょっとした見方の違いですが、私には自然としっくりきました。エンタープライズの中でアジャイルを適用しようとすると、体制・組織とアジャイルな動きがアンマッチだったり、一部でアジャイルがどうしても適用できないチームがあったりと、数々の綻びが出てきて失敗するビジョンは容易に想像できます。逆に、アジャイルの中でエンタープライズをやっていこうと最初から決めていれば、アジャイルの考えに沿ってプロジェクト自身も成長していく姿を想像することができます（失敗はいっぱいするでしょうけどね）。
我々SIerも、アジャイルエンタープライズを目指すべきなのかもしれないな、と考えさせられる発表でした。
最後は堂々と販促。さすが川口さん。
3/19発売です。
[残業ゼロで開発スピードが10倍に！もう元の開発体制には戻れないデンソー流のアジャイル開発]
デンソーでのアジャイル（というよりスクラム）事例の話。残業ゼロの手法が知りたくて行ったのですが、中身はスクラムを忠実に基本どおりに回していった、という話でした。@ryuzee さんが週2でコーチをしているとのことで、節々に@ryuzee さんのスライドで見たなぁという言い回しがあり、コーチによって教え子にも色が出てくるのがわかって面白かったです。デンソーではスクラムチームに一つの部屋を与えて作業をしており、かつカンバンも利用しているということで、非常に働きやすそうな環境が整っていると感じました。
デンソー、IT始めるってよ
— びば（森のフレンズ） (@viva_tweet_x) 2018年2月16日
#devsumiE pic.twitter.com/PTjHJ5rr9P
このキャッチコピーも目を惹くものがあります。「ウォーターフォールには戻れない充実感」と最後に記載もありますが、こちらも共感です。基本に忠実かつエクストリームにスクラムを実践されているので、他社事例としても大変ためになりました。
おわりに
2日間、アジャイル・スクラム・DevOps関連のセッションに行ってきました。多くの知り合いの方にも会えて情報交換も出来たほか、それぞれ特色のあるセッションも多く、濃密な時間を過ごし、得るものも大きかった二日間でした。スピーカーの方達もイキイキとしていて、来年は是非スピーカー側で混じることができれば、と思います。また来年のデブサミを楽しみにしております！