株式会社ホロラボに入社しました。 - 最初の2週間でやったこと

株式会社ホロラボに入社しました。アギレルゴコンサルティング株式会社は退社するわけではなく、引き続き研修中心に仕事を行っていきます。

ホロラボとのご縁

ホロラボは、Kinect とか HoloLens をやっているコミュニティのエンジニアを中心に2018年のHoloLens 日本向け正式販売開始を契機に設立されました。私は当時楽天株式会社で Rakuten Technology Conference というのを実行委員の一員として運営していて、そこで、ARとVRに関する展示をしてもらおう、という回があり、その際に、ホロラボ設立直前のCo-Founder、中村薫さんと伊藤武仙さんに出展をしていただいたのがご縁の発端になります。中村さんについては、さらにさかのぼること10年くらい、Shibuya Trac とか すくすくスクラムといった勉強会からのご縁になります。遠巻きにKinectやHoloLensでの活躍を眺めていたのですが、2019年末にホロラボの拡大に伴って組織コンサルのご依頼をいただいたところあたりから、RSGTで話してくれたり、たまにお邪魔してピザを食べたり、などという交流があったのですが、今回、組織拡大に伴って起きてきそうな様々な課題を一緒に考えていきながら、エンジニアの人たちが明るく暮らせるような組織づくりに寄与できたらうれしいな、ということで入社させていただくことにしました。

f:id:wayaguchi:20210817082852p:plain

ホロラボの組織

ホロラボはまだそれほど大きくない組織です。学校で言えばひと学級分くらいの規模感なので、組織階層はかなりフラットです。いくつかのチームに分かれています。2019年にコンサルしたときには、ちょうどこのチームを作ろうか、というあたりだったのですが、そこから1年半ちょっとが立って、おおまかには企業向けにソリューションを展開するチームと、プロダクトのチームに分かれています。軽量ですが本部機能や総務の人たちもいます。

もともと企業向けに個人として受託をやっていた人たちが会社を設立した、というのが源流ということもあり、企業としてPOC(概念実証)や先行研究としてVR(仮想現実)やMixed Realityを取り組んでいく際の技術的なパートナーとして多く採用されています。一人一人が実現力のあるエンジニアで、顧客の要望に合わせて、というだけでなく、相談にのりながら、現時点で技術的に実現可能な部分を見極めて、比較的短期間で成立させていく、というのが現在の主流のビジネスになります。

プロダクトとしては、もともと様々な企業向け案件での実績の蓄積から、共通化されたワークフローや、煩雑なデータ変換(ETL)などを、プロダクトとして切り出したものがあります。

https://hololab.co.jp/service/

f:id:wayaguchi:20210817083237p:plainf:id:wayaguchi:20210817083255p:plain

f:id:wayaguchi:20210817083330p:plainf:id:wayaguchi:20210817083354p:plain

f:id:wayaguchi:20210817083528p:plainf:id:wayaguchi:20210817083552p:plain

最初の二週間でやったこと

まずは、企業向けにソリューションを提供しているチームの人たちと面談をすることにしました。本当はもう少し手っ取り早く、ワークショップで課題や方向性を、というイメージで相談されたのですが、任天堂の故岩田聡さんが、前職であるHAL研究所の社長を引き受けた際に全員との面談をしたというエピソードを思い出しました。
f:id:wayaguchi:20210817080529p:plain

しかし、岩田さんと違って、私はこの組織についても人々についても、技術についてすら全くの素人であることもあり、まずは皆さんがどんな仕事をしているのか?なぜホロラボに入ったのか、など、個人的に興味のある範囲の話をざっくばらんに教えてもらいました。これは本当に楽しい時間で、特色のある多彩なエンジニアが集まっている会社であることを、改めてはっきりと認識できました。

まさに、岩田さんが言っていることを、その片鱗だけですが、追体験できたような気がします。

いろんな人に面談すればするほど、
わたしはいろんなことがわかりまして、
そのなかから
どういうふうに
組織を作りなおして、
どういう運営をしたらよくて、
なにがみんなのやる気を
ひきだすことに役にたっていて、
なにがみんなの
やる気を阻害しているのかとか……

すべて見えてくるんですね。

半分正しいことを避ける

今回、組織について考えていくということもあり、改めてボブ・サットンさんが話していたことについて読み直したりしています。「半分正しいこと」を避けながら、一歩一歩みんなで考えて、社内だけでなく、お客さんやユーザーさん、もちろん家族や地域社会の人たちを含め、いろんな人が幸せに楽しくやっていけそうな組織を目指していければな、などということを考えています。

kawaguti.hateblo.jp

今後とも、ご指導ご鞭撻のほどをよろしくお願いいたします。

 

エンタープライズアジャイル勉強会 - マネージャー向けのマネジメントセミナーやります (5月12日)

エンタープライズアジャイル勉強会という団体の実行委員として、創立時からお手伝いさせていただいております。エンタープライズアジャイルが特定の方法論や、既存のエンタープライズXXの焼き直しにならないように、ちゃんと大組織の人がアジャイルをやる場合の手助けになるような勉強会にすることを目指して、お手伝いを続けてきました。

で、主要メンバーの方々との議論の結果、いま大きな課題になっているのが、アジャイルにピンときて乗ってきた「以外の」「普通の」マネージャーの方々への啓発や教育やサポートであろう、ということになりまして、そうした方々向けの「セミナー」(サミットとかカンファレンスとか勉強会って言わない)を開催しよう、という運びになりました。ですのでこれはセミナーです。怖くないし、平日ですし、無償なので、安心して周囲のマネージャーさんを誘ってください。決して「はげちゃびん」とか言わないように。

タイトルにデジタルトランスフォーメーションを冠したのは、「デジタルトランスフォーメーションって言ってる人ってマジはげちゃびん率高いよね」ということでは決してなく、DXが意味するのは「全員がちゃんと学んで近代化していくこと」であろう、本気でやっていかないとやばい、ということです。マネジメントが正しく、現場の観察や、学習科学、チームマネジメント、サーバントリーダーシップリーンスタートアップなどのアイデアを学び、各現場なりの取り組みをサポートして学び続ける組織ができたならば、現在のように割と同度でもいいツールや仕組みやしがらみに追いかけられて本業が解決すべき顧客課題に時間をさけないなんて、子供のような言い訳をしなくてもよくなるに違いない、という思いがあります。

ということで、普通にマネジメントセミナーとしてよい構成にしたつもりですので、安心して周囲のマネージャーの皆様や人事・教育研修担当様へのお声掛けをお願いいたします。オンライン開催です。 5月12日は平日です。

申し込みはこちらからです。

エンタープライズアジャイル勉強会

f:id:wayaguchi:20210408150241p:plain

f:id:wayaguchi:20210408150259p:plain



新幹線お掃除の天使たち 「世界一の現場力」はどう生まれたか?

新幹線お掃除の天使たち 「世界一の現場力」はどう生まれたか?

  • 作者:遠藤 功
  • 発売日: 2012/08/28
  • メディア: 単行本(ソフトカバー)
 
見える化―強い企業をつくる「見える」仕組み
 
コロナ後に生き残る会社 食える仕事 稼げる働き方

コロナ後に生き残る会社 食える仕事 稼げる働き方

  • 作者:遠藤 功
  • 発売日: 2020/07/18
  • メディア: 単行本(ソフトカバー)
 
サーバント・リーダーシップ入門

サーバント・リーダーシップ入門

 
教育心理学概論 (放送大学教材)

教育心理学概論 (放送大学教材)

 
教育心理学特論 (放送大学大学院教材)

教育心理学特論 (放送大学大学院教材)

 
Fearless Change

Fearless Change

 

 

This is DevOps : 4/15-16 DevOpsDays Tokyo 2021 を開催します。

もう来週にせまってきたのですが、DevOpsDays Tokyo 2021をオンライン/オンサイトのハイブリッドイベントとして行います。場所はいつもの大崎ブライトコアホールです。感染対策に注意を払いながら、オンラインとオンサイトの垣根をできる限り作らない運営を心掛けていきます。4/15-16です。

昨年4月のカンファレンスはコロナウィルスの緊迫感が高まる中、まだオンライン開催のノウハウもなく、やむなく中止といたしました(DevOpsDays Tokyo 2020 中止の経緯 - kawaguti’s diary) 本年は、コミュニティやホール関係者の皆様の継続的な努力の賜物で、オンライン開催もよく行われるようになりましたし、1月のRSGT2021ではハイブリッド開催にトライして成功を収めましたので、DevOpsDays も、ハイブリッド開催にトライしております。実費負担の公平性の観点で、オンラインのほうが価格を安く設定しております。オンサイトチケットの方もオンラインで鑑賞いただけますので、それぞれご都合の良い方法でご参加ください。

 

f:id:wayaguchi:20210406100217p:plain

今回もなかなかほかのカンファレンスにないラインアップとなっておりますので、ぜひぜひご検討ください。

 

いくつかのセッションを紹介します。

 

モブプログラミングとDevOps、テスト自動化

モブプログラミング発祥の地、Hunter Industries のソフトウェア開発部門の、現在の代表者、Chris Lucian さんのセッションです。

f:id:wayaguchi:20210406100805p:plain

一昨年私も2週間ほどお邪魔しまして、モブで継続的デリバリーをずっと行っているワークスタイルや技術への探求、お互いに学びあう組織の実際の姿に感動しました。最新版のレポートを現地から、していただきます。通訳もあるし、正直これだけでたぶん元が取れるんじゃないかと思います(サンディエゴまで見学に行くことを考えれば)。

confengine.com

Hunter Industries からの最初の経験レポートを翻訳しました。著者のWoodyさんは当時のIT部門の代表者です。CEOに招聘されて、旧来型の運営をしていた部門を大きく改善しました。最初の一歩は「見積もりはしない、リリースタイミングは開発部門が決める、半年はこのやり方に任せる」というのをCEOと握ったそうです。ストーリーカードをベースにXPのプラクティスに従い、技術的卓越性とビジネスサイドとのコミュニケーションを常に行って、一年半の間、不具合が出ないことで、信頼を勝ち得たそうです。

kawaguti.hateblo.jp

この先で、コロナ禍の現在、同社がどのように仕事をしているのか、どんなチャレンジをしているのか、すごく気になりますよね。

 

育児的ソフトウェア開発

シリコンバレーから日本のソフトウェア開発文化を見つめ続ける、バリバリのエンジニア川口耕介さんによるセッションはこちらです。従来の狭義のDevOpsから視野を広げ、雇用形態からソフトウェア組織に至るまで言及していくそうです。これはエンジニアだけでなく、さまざまな職種の方に参考になりそうです。

confengine.com

このセッションだけでも元が取れる感じがします。いやほんとに。

f:id:wayaguchi:20210406101912p:plain

 

 

日本企業の現在進行形、文化的負債との戦い

「いやいや米国の事例はええねん。日本でどうするかや。」とお思いのみなさま、もちろん日本の企業での実践事例もたくさんお伝えします。最初の一つはウイングアーク1stの皆さん。品質保証部門の改革から始め、8年にわたって技術的負債と組織的に向き合ってきた皆さんのセッションです。もちろん、経営陣が全員エンジニアのようなラッキーな会社さんではありません。ビジネスと向き合い、組織と、人と向き合って、どのようにトライを重ねてきたのか、とても気になります。

confengine.com

正直このセッションだけで、元が取れる人も多いんじゃないでしょうか。いやマジで。

f:id:wayaguchi:20210406102941p:plain

 

ほかにも日本企業の現在進行形がたくさん

これ以外にも、多くの日本企業の現在進行形の取り組みをご紹介いただきます。ここまでのセッションでもう元を取っていると思いますので、なんて贅沢なご褒美でしょうか。ほんとにほんとに。

 

 

海外からも多くご登壇いただきます(通訳付き)

さらに多くの海外講演者もいます。米国大手小売業(ショッピングセンター)のTarget社のDX/DevOpsを支えるTarget Dojoのミグスさん。

中国テンセントのJihai Zhouさん

 

機械学習(ML)時代のDevOps

機械学習の時代を迎え、大規模なデータをどうやって運用・テストしていくか、先進企業のお話もいただきます。

もちろん初めの一歩もカバーしてますよ!ありがとうございます。

 

今回はテストやインフラのコミュニティのレジェンドの皆様も

DevOpsの時代には、どんどん複雑化、高頻度リリースをすることになり、どうやって品質を作りこんでいくかが、これまで以上に課題になってきます。テストのモダナイズなしにDevOpsはありえません。テストコミュニティのレジェンドの皆様の知見もいかんなくご紹介いただきます。え、こんなにそろってしまっていいの?

 


基調講演はDevOpsDays 創始者のPatrick Deboisさんと、マイクロサービスアーキテクチャのSam Newmanさん

ダメ押しになってしまいますが、今回は欧州からお二人のキーノートをいただきます。

Patrick Deboisさんは、DevOpsDaysカンファレンスの創始者です。もともとはシステム管理者のカンファレンスを考えていたそうなのですが、そこで2009年のDevOpsという用語の誕生に立ち合い、DevOpsDaysを立ち上げるにいたりました。2019年にはベルギーのヘント市で10周年のミートアップが開催されました。現在は欧州、北米、アジア、南米、アフリカと、全世界に広がっています。
Sam Newmanさんは、名著「マイクロサービス・アーキテクチャ」、そしてさらに近著「モノリスからマイクロサービスへ」を通じて、安易なマイクロサービスの導入に警鐘を鳴らし、分析から移行までを詳細に紹介しています。

f:id:wayaguchi:20210406110456p:plainf:id:wayaguchi:20210406110510p:plain

基調講演だけでも貴重すぎて、これだけでお釣りが来ますね。

 

エンジニアリングプラクティスの現在と組織的移行の未来を

このほかにも数多くのセッションと、スポンサーセッションがあります。スポンサーの皆さんも、なんといいますか、ぜんぜん売り込む感じではなく、あくまで実践者としての知見を共有していただきます。ぜひともDevOpsの現在を感じてください。これ以上はちょっと考えられないラインアップになっております。ぜひご参加をご検討ください。

https://confengine.com/conferences/devopsdays-tokyo-2021/schedule/rich

f:id:wayaguchi:20210406102057p:plain

f:id:wayaguchi:20210406100529p:plain

モブプログラミング-チーム全体のアプローチ by Woody Zuill

This is a translated article. You can access the original here:
Mob Programming – A Whole Team Approach by Woody Zuill

モブプログラミング-チーム全体のアプローチ by Woody Zuill

Translated by Yasunobu Kawaguchi, Ikuo Suyama and Ken Matsumoto

1. はじめに

alt_text

モブプログラミングとは、チーム全体が同じものを、同じ時間に、同じ空間で、同じコンピュータで作業するソフトウェア開発のアプローチです。これはペアプログラミング[PAIR]に似ています。ペアプログラミングは、2人の人が同じコンピュータの前に座り、同時に同じコードを共同作業するというものです。モブプログラミングでは、1台のコンピュータを使ってコードを書きながら、チームの全員にコラボレーションの範囲を広げています。

ソフトウェアのコーディングに加えて、ストーリーの定義、設計、テスト、ソフトウェアのデプロイ、顧客との作業など、一般的なソフトウェア開発チームが取り組むほぼすべての作業をチームで行います(私たちの環境では、プロダクトオーナーと似たような役割の社内の顧客のことを「パートナー」と呼んでいます)。ほとんどすべての作業は「ワーキングミーティング」や「ワークショップ」として行われ、パートナーを含めソフトウェアの作成に関わるすべての人がチームメンバーと考えられています。多かれ少なかれ、一日中毎日このように仕事をしています。

言い換えれば、ペアプログラミングというエクストリームプログラミング[EXT]の概念を超えた進化の一歩です。私たちは、いくつかの例を挙げれば、同席かつ対面のコミュニケーション、チームの連携、コラボレーション、チーム全体の関与、継続的なコードレビュー、「自己組織化チーム」などの概念を強調し、増幅させるように努めています。

この体験レポートでは、なぜこのような働き方をしているのか、基本的なセットアップ、モブプログラミングから得られたメリット、そして「ドライバー/ナビゲーター」チームワークモデルなどの、「チーム全体」として一日中働くために重要ないくつかのプラクティスを説明します。

2. どのようにして始めたか

私たちは、新しい働き方を発明しようとしたわけでも、ペアプログラミングのアイデアを拡張しようとしたわけでもありません。私たちは単に、私たちにとってうまく機能していることに気付き、それを拡張しただけです。

モブプログラミングを発見し、一般的なワークスタイルとして採用する前は、頻繁にふりかえりを行い、より良いものを作るために継続的に取り組むことを実践していました。ペアプログラミングテスト駆動開発[TDD]を学んだり、コーディング道場[DOJO]を使った練習会(全員が1台のパソコンとプロジェクターを使い、キーボードを回して練習する)を行ったりしていました。チームメンバーの何人かは、TDDとペアプログラミングをはじめ、他の新しいスキルも含めて、日々の仕事の中である程度使い始めていました。

ある時、以前開発中だったものの、他のクリティカルな作業のため数ヶ月間「保留」にされていたプロジェクトを再開する準備をする必要がありました。私たちはよくある会議室に集まり、このプロジェクトを見て、どのように仕事を引き受けるかを決めました。チームメンバーの数名と契約社員はこのプロジェクトに携わったことがありましたが、それ以外のメンバーはありませんでした。

最初のミーティングでは、プロジェクトに慣れようとしました。私たちは、いくつかのコード、データベースのテーブル、ドキュメント、プロジェクトの他のいくつかの詳細を見ることから始めました。このレビュー/リフレッシュミーティングでは、いくつかのアイデアを試してみたり、テストを書いてみたり、コードを変更してみたり、今後の進め方について話し合ったりしました。ここ数ヶ月間、ペアプログラミングを学び、練習してきたので、キーボードを渡しながら作業をするのはとても自然なことでした。

数時間後、別のグループが私たちが使用していた会議室を使用することになったので、私たちは急いで荷物をまとめ、空いている会議室を探しに向かいました。その日の最後に「ミニ・レトロスペクティブ」[RETR]を行いましたが、全員がとても充実した経験になったと感じていました。そこで、翌日も同じように集まって活動できるように、会議室を手配することにしました。

それから2週間、私たちは、会議室から会議室へと移動しながら一緒に仕事をするという基本的なパターンを踏襲しました。毎日、その日の様子を振り返り、「チームとして」仕事を続けたい、ということを決めました。私たちは、上手にコミュニケーションをとり、知識を増やし、より良い解決策を見つける能力が急速に向上していると感じました。私たちは、プロジェクトとそれに関わる技術について、深く、共通の理解を得ることができました。この頃、私たちは自分たちがやっていることを "モブプログラミング "と呼ぶことに決めました。

私たちの最大の問題は、部屋から部屋への移動に伴う中断、一部の会議室でのネットワーク接続の問題、コンピュータやプロジェクターの品質や使い勝手の違いなどの、運営や設備の問題でした。また、姿勢の悪さから腰や首が痛くなったり、テーブルや椅子の向きがテーブルの端に投影されたスクリーンとの関係が悪かったりと、人間工学的な問題を抱えていることもわかりました。また、低解像度や質の悪いプロジェクタでコンピュータの画面を目を細めて見ると、頭痛がすることもありました。

3~4週目には、数ヶ月間毎日使える「常設」の作業場を見つけることができ、仕事のやり方もある程度固まり始めていました。人間工学的な問題にも対処する方法を発見していましたが、それは次のセクションで紹介します。

私たちは、「モブプログラミング」を始めてから3年間、多くのプロジェクトや機能拡張を成功させてきました。今では常設の作業スペースを確保し、仕事の進め方を少しずつ改善してきましたが、チーム全体で1台のコンピュータで作業をするという基本的なパターンを守り続けてきました。

3. なぜこのような働き方をするのか

チームがこの方法で仕事をしようと決めたからこそ、私たちはこの方法で仕事をしているのです。これは私たちにとって重要な概念です。仕事をしているチームは、その仕事をどのように行うかを最もうまく決めることができます。私たちは、このように働けと言われたわけではありません。私たちには、どのように仕事をしたいかを決める自由と責任があるのです。毎日、一日中一緒に仕事をし、協力し合うことがうまくいっていることがわかったので、それを続けることは自然なことでした。私たちは何がうまくいっているかに注意を払い続け、必要に応じて頻繁に「調整とチューニング」を行っています。私たちの合言葉は、「常に、よりよく」です[TURN]。

4. 基本的なセットアップ

基本的なセットアップは複雑ではありませんが、一般的な作業スペース(キュービクル)の配置とは大きく異なります。別々の作業スペースで一人で作業する場合は、身体的な快適さや個人的な好みを考慮するのは簡単ですが、仕事のほとんどをグループワークエリアで一緒に長時間座って行う場合は、ちょっとした課題になります。お互いに比較的近くで作業し、共有のモニター、キーボード、コンピュータのセットアップ、プログラミングツールを使用している場合は、身体的に快適であることが非常に重要であることがわかりました。キーボード、コーディングスタイル、ワークスタイル、ツールなどの個人的な好みを考慮する必要があります。

基本的な間取り図は、図1を参照してください。私たちのメインの作業エリアは、標準的なキュービクルのパーティションを使用して構成されており、約16ft x 18ft(4.9m x 5.5m)の大きさです。チームメンバー全員がコードを書く際に使用するコンピュータが1台あります。2台のプロジェクターで「デュアルモニター」を壁に投影し、2台のキーボードでチームメンバーの好みに合わせて選択できるようにしています。壁の周りには、数台のローリングホワイトボードとフリップチャート用のエリアがあります。コーディングをしていない時やチームのメインコンピュータを使用していない時には、個別の机や他のコンピュータを使用することができます。

alt_text

図1 - 恒久的な作業エリアができた後の初期のホワイトボード図面

4.1 コンピュータ

プログラミングに使用されているコンピュータは1台だけです。コードベースに入るコードはすべてこの1台のコンピュータを介して入力されます。このコンピュータは、チームメールや設計、テストなどチーム全体を巻き込んだ活動にも使われています。

他にも、デスクトップパソコンやノートパソコンを利用して、調査をしたり、独自にデータベースを見たり、何かを試してみたり、個人的なメールを書いたり、プログラミングと並行して他のことを行っています。何らかの問題や新しい技術についての情報を探している人が複数人いることもよくあります。私たちは皆で一緒にいて、私たちが学んでいることについて継続的にコミュニケーションをとります。

4.2 プロジェクター

alt_text

図2 - デュアルプロジェクションモニター

プロジェクターは2台あり、デュアルモニターとして使用しています。私たちは、この目的のためにうまく機能する特別なプロジェクター用のスクリーンペイントでペイントした壁に投影します。高さ、距離、明るさ、周囲の部屋の照明、壁の塗料、および他の設定を実験し、チームのみんなにとってうまく動作するように調整しました。一般的な会議室のプロジェクターよりも壁の高さを低くして投影することで、首が痛くならないようにしています。2台のプロジェクターは同じモデルで高品質です。私たちの目標は、スクリーンの大きさ、位置、解像度、明るさをほぼ同じにして、一日中快適に作業できるようにすることです。

4.3 キーボード/マウス

キーボードとマウスが2つあるので、誰もが自分に合ったものを選ぶことができます。4、5種類のキーボードを試してみた結果、「普通の」キーボードと「人間工学に基づいた自然な」キーボードの2種類に落ち着きました。後述するように、一度に「キーボードを使う」開発者は一人しかいません。開発者が QwertyDvorak のような全く異なるキーボードレイアウトを好む場合、私たちは設定を素早く切り替える方法を見つけます。左利きと右利きのプログラマートラックボールと伝統的なマウスなど、個人的な好みはたくさんあります。チームメンバーの一人が別の人とは異なる作業をする必要があるセットアップの問題は、各人がキーボードを使う際に素早くスムーズに切り替える方法を見つける限り、問題ではありません。

4.4 椅子とテーブル

各チームのメンバーはそれぞれ自分の椅子を持っていて、それぞれの役割(ドライバーやナビゲーター)に応じて移動します。このようにして、常に椅子を再調整する必要がなく、各人が可能な限り快適に過ごせるようになっています。私たちの椅子は高品質で快適なものを使用しており、人間工学的な評価を受けた上でチームメンバーのために個別に選択されます。私たちの作業台は、2組の座り心地の良いテーブルです。コンピュータ、キーボード/マウス、プロジェクター、電話、スピーカー、手指消毒剤、その他の身近に置いておきたいものがテーブルの上に置かれています。

重要な要素の1つは、1日を通して投影されたスクリーンに対してどのように向き合っているかということです。一般的な会議室では、プロジェクターのスクリーンはテーブルの端にあるため、ほとんどの人がスクリーンを見るために頭を回転させなければなりません。短時間の会議であれば問題ありませんが、数時間、1日中このように作業していると、非常に不快な気分になります。私たちのレイアウトでは、テーブルとスクリーンが平行に配置されているので、一日中快適でストレスのない方法でスクリーンと向き合うことができます。

一般的なタスクボードに似た仕事の記録に使用している回転式のマグネットホワイトボード、他にもいくつかのホワイトボードやイーゼル、ファイルキャビネットや小さなデスクもあります。

4.5 個人用の作業エリア

一人で仕事をしたい人がいつでも利用できるように、個人用の作業エリアもあります。私たちは、メインのチームエリアとは別の場所に、小さなデスクエリアを持っています。各人の好みに応じて、座るか立つかのどちらかのワークステーションとして構成されており、各チームメンバーはそれぞれのコンピュータ、デュアルモニター、引き出し、電話などを持っています。プライベートエリアにいても、メインの「モビング」エリアの音を聞いたり、注意を払ったりすることもできるし、ヘッドフォンをして他の人達がやっていることを「締め出す」こともできます。

5. 作業に関するいくつかの重要なプラクティス

モブプログラミングでは、誰もが他の誰とでも常にコミュニケーションをとりつづけます。これは多くの価値をもたらしますが、ソフトウェア開発をしている多くの人にとっては比較的異質な働き方でもあります。私たちは、一日を通して集中し、うまく協調するために、いくつかのシンプルな原則とプラクティスが必要であることに気付きました。私たちの目標は、誰もがチームと自分自身の両方にとって最も有用であると感じるレベルで貢献したり、学習したりすることができるようになることです。私たちは、学習はチームへの貢献の一種であると考えています。

免責事項: 私たちが発見し、使用している原則やプラクティスは、私たちにとってはうまく機能していますが、私たちは常に改善を求めています。私たちはまた、他のグループやチームが、私たちのアプローチが自分たちの状況では通用しないことに気づくかもしれないことも理解しています。私たちは実験と革新を歓迎し、自分たちの環境でうまく機能する新しい方法や異なる方法を発見した他の人の意見を聞きたいと思っています。

5.1 優しさ、思いやり、尊敬をもってお互いに接するという原則

私たちの仕事では、人と人との間には何十、何百もの相互作用が毎日発生します。2人だけの会話ではなく、5~6人、時にはそれ以上の人との会話になると、その数は急速に増えていきます。私たちは一日中、アイデアを表現し、問題を議論し、可能な解決策を探り、考えを共有します。貢献できることがある人全員から話を聞く機会を得て、理解を深めるために堂々巡りな議論をするまでは、ほとんどのことがらにおいて意見が一致することはめったにありません。

このような高いレベルのコミュニケーションを一日を通して行うために、私たちは、常に親切、思いやり、尊敬の念を持ってお互いに接することを原則としています。これは簡単なことのように思えますが、この原則の重要性を明確に認めることは、私たちの日々の交流の基盤になると感じています。私のように親切、思いやり、尊敬の心を持って接することが苦手な人は、誰もがこの原則で生活することに専念すると、すぐに上手になります。

5.2 プログラミングのドライバー/ナビゲーターパターン

私たちは、Llewellyn Falco 氏の「強い」ペア・プログラミング・スタイルから発展した ドライバー/ナビゲーター [DRVR]パターンを使用しています。基本的なルールはこうです:「アイデアが頭からコンピュータに入力されるためには、他の誰かの手を通さなければならない」。

これには2つの役割があります:ドライバーとナビゲーターです。ドライバーはキーボードの前に座り、コードを入力します。ナビゲーターは、これからコードになるアイデアを議論し、ドライバーをガイドしてコードを作成します。これは、ドライバーがソロでコーディングする場合よりもはるかに機械的な仕事をしていることを意味します。ドライバーはナビゲーターの話に耳を傾け、ナビゲーターを信頼しなければなりません。ドライバーはタイピング/コーディングに集中しています。ナビゲーターは、ゆっくりとしたペースでドライバーに自分たちのアイデアを伝えているので、ドライバーはいつでも次のタイピングに集中することができます。

これらのことをドライバーに声に出して表現すると同時に、チームの他の人にも表現しています。口頭やホワイトボードで可能性を議論し、考えることで、全員がアイデアを完全に理解することができます。これにより、ナビゲーターとチーム全体の集合知が生まれます。

私たちは時間制のローテーションを採用しており、各チームメンバーが短時間(通常10分から15分)ドライバーとしてキーボードの前で作業します。タイマーを使用して、現在のドライバーが自分の番が終わると次のドライバーにキーボードを渡します(5.3項で説明します)。

ナビゲーターは、ドライバー(および他のチームのメンバー)がその時点で理解できる最高レベルの抽象度で話すことが重要です。ドライバーがコード化すべきコンセプトを理解していて、詳細な指示がなくても進めることができる場合には、非常に高いレベルであることもあります。また、必要に応じてキー操作の指示が必要な場合には、非常に細かいレベルになることもあります。これは人によっても変わってきますし、同じ人でも取り組んでいるアイデアによって、またドライバーの指示を理解する能力によっても変わってきます。

私は、ドライバー/ナビゲーターのアプローチが非常に強力であることを発見しました。このアプローチに従うためには、コードベースの一部になる前に、それぞれのアイデアを別の人とコミュニケーションを取り、議論することが得意にならなければなりません。問題や、解決策の設計、またコード自体についての継続的な議論とレビューが自動的に行われます。誰もが参加し、情報を得ることができます。

5.3 タイマによるドライバーのローテーション

私たちは15分ごとにドライバーを交代するので、誰も長時間キーボードにかじりついていません。その日の作業者のランダムなリストを使って、「ローテーション」します。15分ごとに現在のドライバーがキーボードから離れてナビゲーターと合流し、リストの次の人がキーボードに移動してタイピングを開始します。時間が経つにつれ、リストの一番下に到達したら、一番上から再開します。私たちは、これを代行してくれる小さなタイマーアプリケーションを作りました。ドライバーの時間が終わると、画面をブランクにします。私たちは通常15分ローテーションを使っており、時々この時間を短くしたりしますが、モブプログラミングを初めたばかりの人はもう少し短く設定したほうが良いかもしれません。私たちが最初に始めたときは4~5分間のタイマーを使っていましたが、私たちのスキルとこのプラクティスの快適さのレベルが成熟していくにつれて、時間を増やしていきました。

5.4 電話とEメール

チーム関連の電話やメールでのやりとりはすべてチームで行います。メールには「開発チーム」と署名し、グループのメールアドレスを使用します。チームで電話をかけたり、電話に出たりするときは、スピーカーフォンで通話中であることを相手に伝えます。「やあ、メアリー、ウッディです。スピーカーフォンで他のチームメンバーと一緒に聞いています。」

私たちがこのプラクティスを使う理由の一つは、チーム内の全員が、チーム外の人との(チーム関連の)やりとりについて、すべて把握できるようにするためです。これにより、一般的にサイロで起こる問題の一つ、単一の連絡先問題が解決できます。担当が不在の間、当人が戻るまでコミュニケーションが切れてしまう問題です。しかも、勘違いも少なくなります。他の人が見落としていたことをチームメンバーがキャッチするからです。

6. レトロスペクティブ[RETR]の重要性と、行動を起こすこと

これはアジャイル原則の一つです。「チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。」[APRN] 私たちはこれを心に留めており、私たちに多くの価値をもたらしてくれることがわかりました。私たちは頻繁に、何がうまくいっているのか、私たちが抱えているかもしれない問題は何か、どのように物事を改善することができるかを評価します。この原則の重要な部分は、「調整とチューニング」することです。シンプルに注意を払い、「調整とチューニング」することによって、私たちは途方もない改善と私たちのモブプログラミングのスタイル自体の発見につながった行動を選択することができました。

私たちが開催するレトロスペクティブのほとんどは、典型的なレトロスペクティブのパターンに従っています。30分から1時間ほどの時間を設けて、ここ1、2週間の振り返りをします。このセッションでは、付箋紙に情報を集め、類似のものをまとめたり、ドット投票をしたり、観察したことや試してみたいことについて会話をしたりします[RETR]。いくつかのテクニックを使いましたが、最も一般的なのは、「何がうまくいっているか」「何が助けを必要としているか」「何が足りないか」のパターンのいくつかのバージョンを行い、それぞれの見出しについてのアイデアを集め、チームにとって最も意味のあることを探ります。

私たちは「アクションアイテム」を常に探しています。アクションアイテムは自分たちのプロセスを「調整とチューニング」するものですが、私たちは行うアクションアイテムを1つか2つだけに絞っています。私たちは、1つまたは2つを超えるアクションアイテムを持つと、ほとんど常に逆効果になることに気が付きました。私たちは「ベイビーステップ」を採用しています。つまり、私たちが有用であると思う変更を試してみて、その後反映し、調整し、チューニングしていることを確認しながら進めます。

6.1 ジャストインタイムのアドホックなレトロスペクティブも頻繁に行う

定期的なふりかえり以外にも、私たちはいつでもふりかえりを行い、それが役に立つと感じたらいつでもふりかえりを行います。チームの誰もが、私たちが反省すべきだと思う何かに気付いたら、経験がフレッシュなうちに素直に振り返ります。たいていは一つの事柄に焦点をあてた、短いものになります。重要なのは、常に「修正する」ことではありません。

問題点に気づくだけでなく、誰かが何か良いことに気づいたり、私たちが面白いと思ったことに気づく可能性もあります。何か行動を起こすべきだと思う項目があれば、ノートカードを作り、他のアクションアイテムと一緒にボードに貼っています。

6.2 リーンコーヒー (Lean Coffee ™) [LCOF]

私たちは、ふりかえりでリーンコーヒー(Lean Coffee™)の手法をよく使います。リーンコーヒーは、議論のポイントを維持し、迅速に進めるための簡単な方法です。大前提として、会議の開始時に出席者が議題を決定し、議論される各トピックは5分程度の時間枠に収まるようにします。これにより、私たちは集中力を維持し、会話が延々と続くことを防ぐことができます。限られた時間の中で多くのトピックをカバーするには、これが非常に効果的なアプローチであることがわかりました。Lean Coffee™のセッションでは、通常45分を費やし、さらに行動を起こす必要があると感じた話題については、アクションアイテムを見つけるように努めています。親切、思いやり、敬意を持ってお互いに接するという原則を適用することで、リーンコーヒーのセッションは私たちにとって常に有意義なものとなっています。

6.3 「常に、よりよく」(Turn Up the Good) [TURN]

私たちは、うまくいっていることを認識すること、またさらに良くする方法を探すことによって、多くの価値を得ることができると発見しました。私たちはこれを「いいこと探し(Turn Up the Good)」と呼んでいます。問題を特定し、それを解決しようとすることは有用ですが、うまくいっていることを増やす方法を見つけることで、さらに多くの価値を得ることができることがわかりました。

6.4 行動を起こす

ふりかえりやレトロスペクティブから真の価値を得るためには、行動を起こす必要があります。私たちは常に可能性のあるアクションアイテムを話し合い、いくつかを選択して、進めるようにしています。アクションアイテムの中には、良い結果が得られるものもあれば、そうでないものもあります。私たちは、これらの結果に注意を払い、反省し、時間をかけて調整し、適応していきます。

7. 問題のフェードアウト [FADE]

しばらくモブプログラミングをやっていると、以前に直面していた問題の多くが、もはや自分たちに影響を与えていないことに気がつきました。これらの問題を直接解決しようとしたわけではありませんでしたが、私たちはそれらの問題が消えていくことに気がつきました。

これらの「自然消滅した問題」を一つ一つ挙げていくと、私たちが以前に抱えていた具体的な問題の長いリストになりましたが、それらはもはや私たちに影響を与えなくなったか、あるいは小さな問題になっていました。具体的な問題は会社によって異なるでしょうが、これらの問題はいくつかのカテゴリーに分類できることがわかりました。主なカテゴリーのいくつかは、逆効果なコミュニケーション、意思決定の機能不全、「かろうじて足りる」こと以上を行うことのムダ、技術的負債による衰弱、そして重厚なマネジメントテクニック(見積もり、優先順位付け、スケジューリング、キューイング、パフォーマンスレビューなど)の負担とそれに関連するムダです。他の問題のカテゴリーには、不必要なタスクの切り替えや中断によるプログラマーのバタつきによって引き起こされる集中力と有効性の喪失、社内政治の有害な側面、意思決定と知識創造を本質的に分離する「ミーティングによるマネジメント」の弊害などがあります。問題のカテゴリーは他にもあると思いますが、私たちが気づいたこの類のもののイメージをお伝えました。

アジャイルソフトウェア開発はこうしたよくある問題のすべてに対応し、モブプログラミングは、より高度なアジャイルワークスタイルを奨励し強化します。私たちは、アジャイルマニフェスト[AM]の哲学(価値と原則)とリーンシンキング[LEAN]の概念の両方を使って、自分たちが使っている、あるいは試してみたいプラクティスやテクニックを評価しています。これは、チーム全体で協力して仕事をすることの「いいこと探し」だけで、ほぼ自動的に起こります。例えば、顔を合わせて(そしてサイド・バイ・サイドで)コミュニケーションや意思決定をすることは、一日中一緒に座っていると自然に起こります。さらに、効果的な意思決定を妨げる恐怖や「分析麻痺(Analysis paralysis / 分析ばかりして行動できないこと)」は、すべてが透明で、迅速なフィードバックがある環境で意思決定を行うことで、軽減されたり、排除されたりします。

私たちが見てきた改善点は、私たちのワークスタイルの継続的なコラボレーションとコミュニケーション、「限定的なWIP」と一個流しのワークスタイルの自動適用、ソフトウェアを頻繁に届けて使ってもらうこと、それがもたらす迅速なフィードバック、そして意味のあるレトロスペクティブを頻繁に開催していったことに起因していると私たちは考えています。これらの自然消滅した問題の詳細については、最近のブログ記事[FADE]に詳しく書いています。

8. 生産性

モブプログラミングについて最初に聞かれる質問の一つに、こんなものがあります。"5、6人の開発者がこのような作業をしながら、どうやって生産性を上げることができるのか?違うことに取り組んでもらったほうが、より生産的ではないのか?”

このやり方で仕事をしていると生産性が格段に上がったと感じていますが、それがモブプログラミングだけのおかげだとは簡単に証明できません。アジャイル宣言の原則である「動くソフトウェアこそが進捗の最も重要な尺度です」ということを肝に銘じるならば、モブプログラミングを発見する前の1年間と、モブプログラミングを導入した後の1年間のプロジェクトの納品数を比較することで、生産性を判断できるかもしれません。納入プロジェクト数は約10倍に増えています。この測定には、プロジェクトの規模や機能の数など、考慮していない要素がたくさんあります。この一般的な比較は、社内ではこれらのプロジェクトの作業内容を知っているので意味のあるものになりますが、他の方々にとっては意味のないものかもしません。

生産性の向上を強く感じたとしても、これが他の環境でも再現性があるとは断言できません。様々な要因が絡んでいました。例えば、モブプログラミング以前のこのグループの開発手法は、従来の段階的なウォーターフォールモデルでした。開発者は個別に別々のプロジェクトに取り組んでいました。その既存の開発手法からアジャイルベースのアプローチに移行するだけでも、大きな改善につながる可能性がありました。

生産性は重要ですが、正しいことに取り組むこと以上に重要なことはありません。アイデアと結果を検証し、価値を見出し、取り組んでいることについてしっかりとコミュニケーションをとることで、価値ある結果が得られる可能性が高まります。シンプルさにフォーカスし、「かろうじて足りる」ソリューションを見つけ、やらない仕事の量を最大化することで、無駄を省くことができます。行った仕事の質が悪くてメンテナンスができなかったり、使用目的に合わなかったり、使用目的自体がエンドユーザーにとって価値がないのであれば、単に多くの仕事をこなしたとしても価値はありません。

9. ハピネス・ファクター

私たちのワークスタイルのもう一つの特徴は、毎日元気に出勤し、一緒に仕事をしていることにわくわくしていることです。「仕事をするために生きている」という人は少ないでしょうが、チームとして一緒に仕事をすることで人生が大きく豊かになることを実感しています。私たちはこれを「幸福度」と呼んでいます。私たちは、仕事に興味を持ち続けるために、非常に持続可能なアプローチをとっています。私たちは、心身の健康に注意を払い、誰もが仕事に秀で、自分の人生に秀でられる環境を提供するように努めています。このことは、私たちが最高の思考をし、私たちが創造することのできる最高のソリューションを作り出すのに役立ちます。私たちは皆、自分のスキルと能力を学び、拡大することでキャリアを常に前進させています。私たちは普通に幸福感と充実感をもって仕事をしています。

10. 継続的な学習、意図的な学習/実践、経験

モブプログラミングでは、継続的な学習が行われる環境が整っています。典型的なプログラミングスキルは、お互いのコーディングを見ているうちに簡単に明らかになり、学ぶことができます。キーボードショートカットやプログラミング言語の機能から、デザインパターンやビジネスコンセプトまで、すべてのことがチーム内で公開され、共有されます。興味深い副作用として、私たちは皆、質問をしたり答えたりするのが上手になり、より良い生徒や教師になるための学習をしています。一人一人の経験のレベルに関係なく、私たち一人一人が自分自身の向上のために意味のあることを発見し、学ぶ機会は無限にあります。

協調性の高い仕事をすることで自然と学習が増幅されるだけでなく、1日の最初の1時間をグループ学習に費やすことで、毎日「ノコギリを研ぎ直す」[S&R]時間を取っています。さらに、毎週金曜日には延長勉強会を行い、2~3時間の集中的な勉強を行っています。毎日の学習では、自分が苦手だと思うプログラミングの分野を選び、1時間かけて勉強しています。私たちは普段、ワークショップとして勉強をしていますが、それを私たちのMobプログラミングスタイルに似たコーディング道場として運営しています。例えば、コードの型を使ったり、オンラインのビデオトレーニングを見たり、本を勉強したり、面白いアルゴリズムや新しい技術に取り組んだりするなど、役に立つテクニックは何でも使います。

私たちは1日か2日という短い期間で仕事をしているので、何かをする色々な方法を簡単に試すことができます。私たちは、仕事のあらゆる側面から自動化や簡略化できそうなものを探し出し、うまくいきそうなアプローチを試しています。これには、プログラミングとプロセスに関連するアイデアの両方が含まれます。例えば、ある問題を解決するためのアイデアはいくつかあるものの、チーム全体で明確にこれというものがない場合、それぞれの解決策の最小バージョンを試してみて、どれがより良いかを確認します。実験を行うためのコストは比較的低く、私たちにとっての見返りは多くの場合、投資した時間の何倍にもなります。

面白いことに、新しいメンバーをチームに加えると、新しいアイデアやコーディングスキルをチームにもたらして、すぐに貢献者になってくれることがあります。逆に言えば、彼らは私たちが取り組んでいるプロジェクトの性質をすぐに学びます。「稼いだ分だけ学ぶ」ということです。新しい開発者は、私たちが開発しているビジネスロジックの入出力を学びながら価値を提供しています。これは、訪問者を一日チームに参加させた場合にも表れています。チームに参加してから10分も経たないうちにコーディングや技術的なアイデアを提供してくれるようになったというケースも多々あります。

11. いくつか気をつけること

モブとして働くということは、自分たちの弱点がすべて露呈しているということです。自分たちの行動はすべてチームのみんなの目に触れることになります。これを不快に思う人もいるかもしれません。しかし、そこにたどり着くまでに時間はかかりましたが、現在のチームの全員が、この絶え間ない精査と露出に適応することができました。私たちは皆、お互いに優しさ、思いやり、敬意を持って接することを約束していると理解しているので、当初思えたほど脆弱ではありません。他の人よりもスキルや能力が高い人もいますが、私たちは皆完璧ではなく、他人にさらけ出すことに自信が持てない何かを持ってもいます。

これが誰にとっても楽に行えるようにするために、相手が快適に感じられない場合、私たちが参加を強要することはありません。誰もが自分ができる最善の方法で貢献することを期待されていますが、座ってチームで作業することを誰も強制されません。それは個人の選択です。すべての人が参加するように招待されていますが、もしそうしたければ、一人で自由に仕事をすることもできます。

12. 健康と人間工学

私たちは、他の人と密接に仕事をすることで、細菌を共有したり、病気にかかったりする可能性が高くなることを認識しています。全員が同時に病気になる可能性を減らすために、全員がお互いにくしゃみや咳をしないように、十分に離れた場所に座るために十分なスペースを確保しています。また、キーボードでドライバーを交換するときに使えるように、テーブルの上に手指消毒液を置いておきます。私たちの誰かが病気の時は、その人が家にいるように勧めます。彼らが仕事をしたい場合は、チームに細菌を広げるよりも、自宅で仕事をしてもらうさせるようにしています。

人間工学的な要素に注意を払うことが大切です。私たちは、ストレスのない快適な職場環境を実現するために、その妨げとなる問題点を特定し、対処することに努めています。例えば、反復運動過多損傷(RSI)に対処したり、それぞれの方の好みに合わせるため、キーボードは様々なものを用意しています。反復性ストレスや頭痛、眼精疲労などが起きないように配慮し、必要に応じて調整しています。ローテーションはキーボードやマウスを使用する時間を制限するのに役立っています。私たちは、立って仕事ができるように整っており設定されており、頻繁に立つ位置体勢を変えています。前にも述べたように、私たちはそれぞれが自分に合わせた椅子を持っています。自分がドライバーの番になると、キーボードに向かって椅子を転がしていく回していくので、再調整することなく快適な姿勢を保てるようになっています。

13. チームの理想的なサイズは?

これはよくある質問ですが、回答するためには情報が不足しています。私たちは現在、6人のチームで活動しています。これまでに3人から12人までが「モブ」として一緒に仕事をしたことがありますが、生産的になれることがわかりました。しかし、「どのくらいの人数では多すぎるのか」という問いに関しては、ヒューリスティックな手法を用いています。それぞれの人が、貢献していない、学べていないと感じた場合は、サインと捉えます。少しの間一人で作業をしたり、ペアや数人に分かれて、新しいモブを開始するとよいタイミングかもしれません。

14. あなたはモブプログラミングを勧めますか?

モブプログラミングを勧めますかとよく聞かれます。私たちはそれが私たちにはうまく機能することを発見しましたし、あなたにも使えるかもしれません。しかし、私たちはそれを推奨しているのではなく、単に私たちの経験を共有しているに過ぎません。モブプログラミングのコンセプトを調査し、自分にとってうまくいく部分があるかどうか確認していきます。そのやり方に価値があると私たちは信じています。あなたのチームで最終的にうまくいくと、誰が分かるのでしょうか?

世界中でモブプログラミングを試しているチームがいくつもかありますが、こうした私たちが聞いたチームの中には、日常的に、あるいは週に数回このスタイルで仕事をしているチームもあると聞きます。緊急だったり、特に難しい問題が発生したときにモブスタイルで仕事をするという人たちの話もよく聞きます。他の方の経験が書かれた記事へのリンクを添付しておきます。[LINKS]

私が重要だと感じているコンセプトの一つは、それが自分たちにとって適切かどうかをチームが判断しなければならないということです。誰もがこのように働かなければならないということを強制するのは、おそらく適切ではないでしょう。

モブプログラミングに挑戦したい人には、ペアプログラミング、一個流し、テスト駆動開発、継続的デリバリー/デプロイメント、レトロスペクティブ、コーディング道場、クリーンコード、その他のアジャイルやリーンの概念についての知識と経験があると役に立つと思います。しかし、親切、思いやり、敬意を持ってお互いに接することに専念していれば、必要なことは何でも途中で学ぶことができます。

私たちは誰もが有意義なレトロスペクティブを開催することを奨励しています。自分にとってうまく行っているのために機能しているものに注意を払い、「良さを高める」方法を試してみてください。 "良いものを上げる "方法を 試してみてください もしあなたがモブプログラミングをやってみようと思うなら、やってみた経験をお伝えいただけると嬉しいです。聞かせていただけたら嬉しいです。もしあなたがモブプログラミングをやってみようと思ったら、あなたの経験をぜひ聞いてみたいと思います。また、もし何か助けが必要であれば、私に知らせてください。何かできることがあれば嬉しいです。

15. 謝辞

何よりもまず第一に、私たちが最初にモブプログラミングを発見したときにチームで働いていたメンバーに感謝したいと思います。Dexter Baga、Gordon Pu、Chris Lucian、そして DanYeung Wong です。彼らの献身的な努力がなければ、何が機能しているかに注意を払い、常に「より良く」する活動なしに、この素晴らしい働き方を見つけることはできなかったでしょう。また、「意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。」[APRN]というアジャイル原則の力を認識する知恵と先見性を持った上司の Marc Kase にも感謝したいと思います。私たちがモブプログラミングを始めてからチームに加わってくれた、偉大な貢献者でありチームメンバーである Aaron Griffith と Jason Kerney にも感謝します。

Llewellyn Falco には大変お世話になりました。彼の発見したすべての良いことの無欲な共有に、多くの良いものを発見する能力に、他人を助ける方法を常に探している飽くなき習慣に。私は彼からドライバー/ナビゲーターのモデルとなった「強い」スタイルのペアプロや、コーディング道場のコンセプトを学びました。また、ペアプログラミングテスト駆動開発、レガシーコードの扱い方、受け入れテスト[APPR]、ソフトウェア開発全般についても、Llewellyn から多くのことを学びました。

この論文で私の査読者となってくれた Joseph Yoder [YODER] には大変感謝しています。彼の助けと指示がなければ、私のごちゃごちゃしたアイデアを実際の論文にすることはできなかったでしょう。誰もが Joe と一緒に仕事をする機会を持つべきですー彼は本物のプロです。

参考文献

[PAIR] Pair Programming: Extreme Programming Explained: Embrace Change, 2nd Edition, Kent Beck

[EXT] Extreme Programming: Extreme Programming Explained: Embrace Change, 2nd Edition, Kent Beck

[TDD] test driven development: Test Driven Development: By Example, Kent Beck

[TURN] “Turn Up The Good” comes from the idea of “I would turn all the knobs up to 10 and see what happened” from Kent Beck: [EXT]

[DOJO] Coding Dojo – I was introduced to the Coding Dojo via Llewellyn Falco, who learned the concept from Laurent Bossavit, who introduce the idea with Emmanuel Gaillot. Emily Bache has written a book on the subject available from LeanPub: https://leanpub.com/codingdojohandbook

[RETR] Retrospectives: Agile Retrospectives: Making Good Teams Great, Authors: Esther Derby, Diana Larsen

[DRVR] Llewellyn Falco have written a bit on the subject here: http://llewellynfalco.blogspot.com/2014/06/llewellyns-­‐strong-­‐style-­‐pairing.html

[AM] The Agile Manifesto: http://agilemanifesto.org/

[APRN] Agile Principles: The Principles Behind the Agile Manifesto, http://agilemanifesto.org/principles.html [LCOF] Lean Coffee: Jim Benson and Jeremy Lightsmith, http://leancoffee.org/

[FADE] Fading Problems, on the Mob Programming Blog: http://mobprogramming.org/fading-­‐problems/ [LEAN] Lean Software Development, Authors Tom and Mary Poppendieck, http://www.poppendieck.com/

[S&R] Nobody Ever Gets Credit for Fixing Problems that Never Happened: Creating and Sustaining Process Improvement. Repenning, N. and J. Sterman (2001): http://web.mit.edu/nelsonr/www/Repenning=Sterman_CMR_su01_.pdf

[APPR] ApprovalTests are a library that extends unit test in many programming languages : http://blog.approvaltests.com/ [YODER] Joseph Yoder: http://www.joeyoder.com/

[LINKS] Here are some links to articles or video about experiences with Mob Programming Our team blog: http://mobprogramming.org/

Time lapse of a day of work: https://www.youtube.com/watch?v=p_pvslS4gEI

AppFolio Engineering Blog: http://engineering.appfolio.com/2014/03/17/my-­‐experience-­‐with-­‐mob-­‐programming/ Tagged: http://blog.tagged.com/2014/05/mobbing-­‐tagged/#more-­‐2520

Agical: https://www.youtube.com/watch?v=goAMu-­‐XqJts

Per Jansson: http://pichdude.wordpress.com/category/agile/

Marcus Hammarberg: http://codebetter.com/marcushammarberg/2013/08/06/mob-­‐programming/

Kevin Rutherford http://java.dzone.com/articles/reflections-­‐day-­‐mob

Amy Lightholder: http://www.light-­‐holder.com/mob-­‐programming-­‐at-­‐shesgeeky/

Mob refactoring: http://blog.codeclimate.com/blog/2014/01/30/mob-­‐refactoring/

Agila Sverige, Tobias Anderberg and Ville Svärd: https://agilasverige.solidtango.com/video/2013-­‐05-­‐20-­‐agila-­‐sverige-­‐torget-­‐d2p02 

Richard P. Gabriel at the ACM Conference on Object-­‐Oriented Programming, Systems, Languages, and Applications on October 19, 2000, in Minneapolis, Minnesota, USA on a related concept: http://www.dreamsongs.com/MobSoftware.html

About the Author 

Woody Zuill

Experience Report

Author:

  1. Woody Zuill

July 2014, Agile2014 Conference

※本文書は著者であるWoody Zuill氏の許諾を得て行いました。

※本文書はこちらでバージョン管理をしています。おかしな点などありましたらご指摘お願いします。GitHub - kawaguti/mobprogramming-woodyzuill-ja

妄想: スクラムフェス大阪のセッションドラフト会議がとても楽しかった。

今年もスクラムフェス大阪(スクフェス大阪)を6月に開催します。昨年と同じオンラインです。

www.scrumosaka.org

スクラムフェス大阪は、大阪がホストなんですけど、全国のアジャイルコミュニティに集まってもらってワイワイする「フェス」です。

昨年、緊急事態宣言の時に、おそらく全国各地のコミュニティの人が困ってそうだなー、ということで企画して、19のコミュニティが集まるイベントになりました。本年も様々なコミュニティやスポンサーの皆様がトラックを持っていただけるようにしたいと考えております。 

今では定番になった、Discord+Zoom のカンファレンス開催方式を大規模に試したのもこの場所でした。準備の進め方からDiscordにオープンにし、私たち自身が実験し、学ぶために、最大限この場所を利用させていただきました。

昨年は急遽オンラインに変えたため、各地方コミュニティに希望していただければ、大阪(オフライン)で採択されたセッションを各地方トラックでやっていただく、ということをやりましたが、今年はあらかじめわかっているので、公平に、ドラフト会議でセッション採択を行う方式で行きたいと考えております。

どうなるのかわからないのでレポートを妄想して書いてみる

問題はどんなエクスペリエンスのなるのか想像もつかないってことです。ドラフト会議はわかるけど、何がどうなるのか?ドラフト会議は観たことあるけど参加したことないし。そこで、参加者の人がどう感じたのかを体験レポートする姿を想像してブログを書いてみようと思いました。 

ここからは完全に妄想です。

こんにちは品川アジャイルです

みなさんこんにちは、スクフェス品川実行委員のかわぐちです。コロナがなければスクフェス品川を始めるつもりだったんですが、残念ながら開催を見送ったところで、大阪が参加コミュニティを 募ってくれたので、品川として参加しました。今回の参加は二回目です。普段は品川アジャイルとして毎晩Fortniteしたり、毎週バーチャルに集まって作業したり、品川アジャイルトークスを録ったりしています。

open.spotify.com

あと、RSGT2021では配信班をみんなでやりました。機材を選んだり、実験したりしてとても楽しかったです。プロの配信のみなさんの苦労がちょっと分かった気がします。

DevOpsDays でも配信班として参加する予定です!

www.devopsdaystokyo.org

 

スクフェス大阪サイト公開!ドラフト会議?

スクフェス大阪のDiscordで、ドラフト会議について説明がありました。

f:id:wayaguchi:20210226125031p:plain

相変わらず説明が少なくてわけがわかりませんが、なんか楽しそうなことは伝わってきました。セッションの採択を各コミュニティでするってことかな?とりあえず12球団に品川が選ばれてるらしいことは認識しました。よし!いいくじ引くぞー。
去年の参加コミュニティ一覧からスクフェス/地方コミュニティを引っ張り出すとこんなラインナップになるみたいです。

大阪 札幌 三河 広島 福岡 品川 仙台
四国 栃木 京都 ベトナム 新潟 鳥取

数えると国内が12個で、海外が一つですね。

ドラフト会議に向けての準備

ConfEngine にセッションプロポーザルが投稿されるようになったので眺めていました。でも、なんか数が少ないし、13球団で取り合ったらうちのトラック全然埋まらないのでは?

confengine.com

これは、まず自分たちでセッション出すとか、品川でやってもらいたい人に声掛けしないと、セッションが埋まらないぞ....と不安になってきます。幸いなことに、品川アジャイルのTommyさんがすでにプロポーザル出してくれてるんですけど、

Scrum Fest Osaka 2021 - アジャイル開発の学び方 | ConfEngine - Conference Platform

あれ、ドラフトで複数球団に指名されて、くじ運で持っていかれる展開なのでは?! 逆指名ってどうやって登録するんだろう。タグに品川とかつけとけばいいのかなぁ....。

とにかく、話してくれそうな人にお願いしてプロポーザル増やさないと....。

プロポーザルをみていく

ドラフト会議までにプロポーザル見とかないと指名できないので、ガンガン見ていきます。

(去年の例) 

Scrum Fest Osaka 2020 - 139 Invited, Accepted and Proposed Submissions | ConfEngine - Conference Platform

すごくたくさんあって、内容もさまざま。これは選ぶの大変だわ。とりあえず気になるテーマにLikeを付けていきました。ちなみにLikeを付けたりプロポーザルを投稿するにはアカウントをConfEngineに登録してログインしないといけません。

海外のセッションの日本語版とかもあるけど、これはきっと新潟が指名するんだろうな...。 

Scrum Fest Osaka 2020 - 付録A:書籍『Agile Testing』を書いてから起きたこと by Janet & Lisa(動画放映) | ConfEngine - Conference Platform

いちばんたくさんLikeがついてるのこれかー。しかし競争率が高そうなのでちゃんと地に足のついたセッションを選んでいかないと...。

Scrum Fest Osaka 2020 - Agile Wars − アジャイルチームの夜明け − | ConfEngine - Conference Platform

 自分たちで出したのはこれ。45分セッションはこれで埋まるので、あと、45分x2かー。20分セッションでもいいな。

Scrum Fest Osaka 2020 - 実践 Visual Studio Codespaces!息がとまるくらいオンラインでモブ・リファクタリング | ConfEngine - Conference Platform

運命のドラフト会議

そうこうしているうちに当日を迎えました。運命のドラフト会議!結局あんまセッション増やせなかったので、頑張っていいセッションを引き当てないと!

Zoomに参加すると、早速一位指名から始めるみたい。各コミュニティでDiscordのチャンネルがあるので、そこで相談しながら指名していきました。

f:id:wayaguchi:20210226131419p:plain

まずは一位指名。競合が多そうだけど、鉄板のセッションを指名してみた!!! (写真は実際の野球のドラフト会議にはめ込んだコラ画像ですすみません。)

f:id:wayaguchi:20210227115623p:plain



本物のドラフト会議さながらのアナウンスがあって超楽しかったです!

逆指名もたくさんあったので、1位から4位くらいでだいたいセッションが埋まったみたい。

今回初めてお願いするスピーカーさんなので、ここでできるつながりも楽しみ。いずれリアルでカンファレンスするときには品川に来て話してほしいなー。

本番は6月25-26日

さて、品川トラックのセッションも決まったので、あとは本番を待つのみ。プロポーザルの加筆などもお願いして、本番を楽しみたいです!

 

 

…いかがでしたでしょうか。だいぶ解像度が粗いことはよくわかりました。よーし解像度上げてくぞー。

 

エンタープライズアジャイル勉強会 NTTCom 岩瀬さん と リクルートテクノロジーズ黒田さん

昨日、長らくお手伝いさせていただいているエンタープライズアジャイル勉強会がありまして、今回は横道稔さんのホスト会で、NTTCom 岩瀬さん と リクルートテクノロジーズ黒田さん にお願いすることになりました。

実際に日本の大企業で仕事をやっていくうえで、一エンジニアやプロダクトマネージャーから一歩踏み出していくための、かなり解像度の高いヒントが得られるのではないかと思います。10数年前に、私がちゃんとスクラムをやり始めたきっかけは、当時初参加のデブサミで聞いた関将俊さんの講演だったのですが、同じようなきっかけや具体的なヒントを数多く得られる講演だったのではないかと思います。

っていうか、お二人の話を聞いていると、どんどん言い訳を失っていくんですよね。開発者の立場でも、マネジメントの立場でも、まだまだやれることがある感じがしてきます。大変だと思いますけどね。でもちゃんと成果を出していくために、必要なことをやっていこうと。つまりはそういうことにすぎないわけです(解像度最低)。

 岩瀬さんの資料

いくつかピックアップします。

f:id:wayaguchi:20201015164400p:plain

うまくいったアジャイルチームが定期異動で分散してしまったり、大きな会社のなかで様々なチームで取り組みが始まっているようなときに、結果的に既存の仕組みに各個撃破されてしまうリスクがあります。それが起きたときにおこることは、コアになったエンジニアが辞める、もしくは活動がチーム以下に縮小して個人活動になる、という感じでしょうか。それ、起こしちゃって本当に大丈夫ですかね?会社。と思うのですが、そういっていても伝わらないので、様々な活動をやっていく必要がありますね。とりあえずうまくいっている状況を守るための、チーム外へのアプローチが必要になってきます。講演でも触れていただきましたが、SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップでも中心になっているテーマがこれです。
f:id:wayaguchi:20201015164017p:plain

そして、多くの経営書で語られていますが、非公式組織、組織図に出てこない人々のつながりが大きく影響します。部署を超えた、人のつながりです。大きな会社で定期の人事異動をしたり、一括採用で同期のつながりを作ったり、ということは半分はこのため(半分は癒着の会避)だと思いますが、うまく活かす人が多数というわけではなさそうだなと思います。しかし、多くのイノベーション研究で語られているのは、非公式組織です。みんながやらなくてもいいけど、できる人はやればよくて。一部の人がやれば、論理的にはスケールフリーネットワークが実現できます(組織はツリーではない - Jim Coplien さんのスケールフリーネットワーク論 - kawaguti’s diary

f:id:wayaguchi:20201015164049p:plain

意図的に人事(HR)にキャリアチェンジして、現在のトライが続いているそうです。いいですね。

f:id:wayaguchi:20201015164116p:plain

f:id:wayaguchi:20201015164155p:plain

 そして内製化問題を取り上げていく。内製化というと「それだけが答えじゃない」「そうはいっても人がいない」というような反応をいただきがちですが、そうした問題に一つ一つ、いい感じに会社のリソースを使いながら、答えを出していく。そうすることで、見えないところで多くの開発者やビジネスの人たちが、間接的にやりやすくなっていく。灯台の灯をともし続けて、組織全体として戻れないところまで、ちゃんと変化を定着させるの、すごく大変だと思いますが、そういう人を、組織の人たちはなんとなく手助けしていくのではないかと思っています。(足を引っ張る人のほうがだいたい先にいなくなりがち。)

頑張ってください。応援してます。

 

黒田さんの資料

いくつかピックアップします。

f:id:wayaguchi:20201015170538p:plain

アジャイルにならなければ、といっても、すでに動いている事業体の場合、現在のやり方を全部取り換える、という話にはなりえません。現在うまくいっていないわけでもないし、そうやってビジネスは回ってきて、だから人が雇えている。急になにかにかぶれて一気にいじるのは、足元を突き崩すようなものです。ということで、システム全体を、向き不向きで分けていきます。これは組織ごとに持っているコンテキストが違うでしょう。

f:id:wayaguchi:20201015170825p:plain

そして、各個別の機能は、できる限り短いリードタイム(≒コスト)で、届けてコストを回収したい。一番右の if (isBooked) がTrueになったところで課金が発生するので、そこまでのステップをなるべく短くする方が、ROIが高い、ということになります。このあたりを、プログラミングの用語とビジネスの用語の両方でちゃんと理解しておく必要があると思います。

f:id:wayaguchi:20201015171137p:plain
そして、アジャイルで(DevOpsやマイクロサービスを援用して)やっていくことでリードタイムを縮小していくことが、一つ一つの施策のレベルで重要です。最後に一気にやっても作れるのですが、リスクは上がってしまう。もちろん施策が当たるとは限らないので、途中でさらに収益機会は変わっていきます。その途中の情報が早く得られることも重要です。

f:id:wayaguchi:20201015171318p:plain

強い売上目標を課してしまうことで、結果的に開発部隊のマインドがディフェンシブになってしまって、バッファを積んでROIを下げてしまった事例があったそうです。一見正しそうな経営陣のオーダーも、実際に何が現場で起きているのかを理解していないと、思わぬ副作用を呼んでしまう、ということです。

 

続きは RSGT2021 で!

お二人の話を聞き逃しちゃったー、直接質問したかったわー、という方は、きっとRSGT2021 に参加していただければ、聞けるのではないかと思います!

XP祭り2020に、一般社団法人スクラムギャザリング東京実行委員会、スクラムフェス大阪として書籍プレゼントに協賛します。

XP祭り2020 に、出版者様から見本誌のご提供をいただいておりますが、併せて一般社団法人スクラムギャザリング東京実行委員会として、書籍を提供いたします。原資にはスクラムフェス大阪の収益金も活用させていただきます。

 

アジャイルをこれからやろうとしている皆様、さらに組織やプロダクトに貢献しようと努力されているみなさまのお役に立てれば幸いです。ご自身で活用されるだけでなく、感想や内容をお近くの方と話し合って、より理解を深めてください。

www.scrumgatheringtokyo.org

www.scrumosaka.org

 

提供書籍リスト

先日行いましたアンケート結果を踏まえ、さらに追加を行いまして、ただ即日手に入らないものは削除し、以下の本のリストといたしました。初心者が多いXP祭りですので、XPに絡むものは、一部いだだいた見本誌と重複しているものがあります。

テスト駆動開発

テスト駆動開発

 
新装版 達人プログラマー 職人から名匠への道

新装版 達人プログラマー 職人から名匠への道

 
Clean Code アジャイルソフトウェア達人の技

Clean Code アジャイルソフトウェア達人の技

 
レガシーコード改善ガイド
 
ジョイ・インク 役職も部署もない全員主役のマネジメント

ジョイ・インク 役職も部署もない全員主役のマネジメント

 
アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

  • 作者:Jonathan Rasmusson
  • 発売日: 2011/07/16
  • メディア: 単行本(ソフトカバー)
 
ユーザーストーリーマッピング

ユーザーストーリーマッピング

  • 作者:Jeff Patton
  • 発売日: 2015/07/25
  • メディア: 単行本(ソフトカバー)
 
スクラム 仕事が4倍速くなる“世界標準”のチーム戦術

スクラム 仕事が4倍速くなる“世界標準”のチーム戦術

 
エッセンシャル スクラム

エッセンシャル スクラム

 
スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

  • 作者:Mitch Lacey
  • 発売日: 2016/02/27
  • メディア: 単行本(ソフトカバー)
 
リーン開発の現場 カンバンによる大規模プロジェクトの運営

リーン開発の現場 カンバンによる大規模プロジェクトの運営

  • 作者:Henrik Kniberg
  • 発売日: 2013/10/26
  • メディア: 単行本(ソフトカバー)
 
組織パターン

組織パターン

 
Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

 
知識ゼロから学ぶソフトウェアテスト 【改訂版】

知識ゼロから学ぶソフトウェアテスト 【改訂版】

  • 作者:高橋 寿一
  • 発売日: 2013/12/10
  • メディア: 単行本(ソフトカバー)
 
大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法
 
トヨタ生産方式――脱規模の経営をめざして

トヨタ生産方式――脱規模の経営をめざして

  • 作者:大野 耐一
  • 発売日: 1978/05/01
  • メディア: 単行本