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

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

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

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

 岩瀬さんの資料

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

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

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

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

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

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

 

黒田さんの資料

大企業アジャイルの勘所 #devlovex #devlovexd from Itsuki Kuroda

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

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

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

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

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

続きは RSGT2021 で！

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

• Regional Scrum Gathering Tokyo 2021 - Remote Work Native な働き方を志向した結果、Agileな状態に爆進しているとあるHRチームの話 - 組織全体への波及を添えて | ConfEngine - Conference Platform

• Regional Scrum Gathering Tokyo 2021 - プロダクトチームの育て方 : MVPの先にある組織づくりの話 | ConfEngine - Conference Platform

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

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

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

www.scrumgatheringtokyo.org

www.scrumosaka.org

提供書籍リスト

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

エクストリームプログラミング

テスト駆動開発

リファクタリング 既存のコードを安全に改善する（第2版）

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

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

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

レガシーコード改善ガイド

アジャイルコーチング

アジャイルプラクティス　達人プログラマに学ぶ現場開発者の習慣

アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

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

小さなチーム、大きな仕事　働き方の新しいスタンダード (ハヤカワ文庫NF)

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

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

正しいものを正しくつくる　プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について

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

エッセンシャル スクラム

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

スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)

アジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と技法～

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

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

組織パターン

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

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

いちばんやさしいアジャイル開発の教本　人気講師が教えるDXを支える開発手法 「いちばんやさしい教本」シリーズ

The DevOps　逆転だ！究極の継続的デリバリー

The DevOps ハンドブック 理論・原則・実践のすべて

LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する (impress top gear)

テストから見えてくる グーグルのソフトウェア開発

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

大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法

アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)

情熱プログラマー ソフトウェア開発者の幸せな生き方

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

モダン・ソフトウェアエンジニアリング

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

岩田さん: 岩田聡はこんなことを話していた。 (ほぼ日ブックス)

1兆ドルコーチ――シリコンバレーのレジェンド　ビル・キャンベルの成功の教え

皆さんの推薦書 ～ みんなで選ぶ！今読むべきアジャイル本・技術書

XP祭りに関連して、「みんなで選ぶ！今読むべきアジャイル本・技術書」というアンケートをしております。

kawaguti.hateblo.jp

アンケートでご推薦いただいた本

およせいただいた推薦書を、併せていただいたコメントとともに、貼っていきます。

エクストリームプログラミング

古典になりつつありますが、あえて今読むべきと推薦します。思想や考え方の根底はここに書かれているので、チームや組織で解釈を共有しあうことで、次の一手につながるのではないでしょうか。

いちばんやさしいアジャイル開発の教本　人気講師が教えるDXを支える開発手法 「いちばんやさしい教本」シリーズ

自分の著作なので手前味噌で恐縮ですが、 「なぜアジャイル開発なのか」を非エンジニアでもわかる地点から丁寧に読みといた、DX時代にフィットする良書だと自負しています

Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち

インターネットに関わる仕事をしている人なら、どのエピソードを読んでも 「わかる！！」 「あーーー・・・(遠い目)」 「な、なるほど、、、これをやったのか、、、すげえ、、、俺らもやるしかないのかなー、、、」 みたいになると思います。

モダン・ソフトウェアエンジニアリング

MSAをはじめ現代のソフトウェア　エンジニアリングの"当たり前"が体系的に分かるため

トヨタ生産方式

Lean, KANBAN, Agileのルーツ(の一部)がここに！ 先の見えない低成長時代・無成長時代でも利益を確保し、生き残るには、変化する顧客-市場の要望に対応しながらも(多品種少量生産)、原価低減のために徹底的に無駄を省くこと。 そのためにはニンベンのついた自働化(個々の専門能力を高め、幅を広げ、多能工を実現する)とやらなくていいことをチームワークで最大限排除して"ジャスト"インタイムを追求する2本柱によるトヨタ生産方式。 米国のFordやスーパーの在庫管理からの学びをもとに、カンバン、平準化、カイゼン、5Whys(なぜを5回繰り返す)などの創意工夫の歴史など、著者の伝えたい事が母国語で読めます。日本人で良かった。 大野さんも自分たちの知恵がソフトウェア開発者に活用されて、Agileというかたちで幅広くプロジェクト管理や経営に活かされる事になるとは想像してなかったのでは。

みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた

組織運営において陥りがちな3つの重力は、会社全体でアジャイルを考える必要があることを痛烈に感じさせてくれます。また、３つの重力に対して、組織が良い方向に進んでいるのか？、悪い方向に進んでいるのか？、を判断できる組織の兆候が記されていることにより、自身が所属している組織の状態を、明確に知ることができ、組織の指針となる本になっています。

アジャイル戦略論 「チーム作りの巻」 ～ わたしの場合

RSGT2021にプロポーザルを出しました。３人で自分の言葉でチーム作りを語ってみようという話になりまして、まず私の分の概要を書いてみました。

Regional Scrum Gathering Tokyo 2021 - アジャイル戦略論 「チーム作りの巻」～すべての基礎はチーム作りにあり。 | ConfEngine - Conference Platform

まずはさっと脳内をダンプするというレベルなので、みなさんのご意見をいただければ幸いです。10行くらいの概要と、本番スライドが作れるといいなぁと、差し当たって考えております。

ここから原稿です。

1. 一人目の仲間を作る

デレク・シヴァーズが有名なTEDトークで語った通り、何かの社会的な活動を起こす際に、一人目のフォロワーが鍵となる。何かを始める時には、まず先行者を探し、フォロワーになれないか考えてみるのがよい。適切な先行者がおらず、リーダーにならざるを得ないときは、一人目フォロワーを見つける必要がある。
https://www.ted.com/talks/derek_sivers_how_to_start_a_movement?language=ja

一部の方の期待を裏切ってしまうかもしれないが、アジャイル戦略論は、アジャイルという武器を使ってあなたをリーダーにする話ではない。アジャイルという企業活動上の新しい必然を、企業の中に定着させるためにどうすればいいか、ということだ。だから、あなたに権力があればそれを適切に使い、ないなら権力を持った人とうまくふるまうことによって、目的を達成しよういう立場をとる。それゆえ、まずビジョンを共有し、自分の持っていないものを補完してくれる仲間が必要なのだ。

2. 話し合いながらアウトプットする

未来は決まっていない。アジャイルな考え方とやり方を、組織の人々がどのように体現するようになるかは、全く予想もつかない。しかし、現在のような激しい競争環境のなかで、かつ技術人材も潤沢とはいえないあなたの環境で、実のある成果をどのように、文字通り「ひねり出して」いくかを考えないといけない。発想だけでなく、なるべくコストも期間も使わずに最初の成果(Low Hanging Fruits)を手に入れるために、何ができそうか、二人で考える必要がある。今使えるリソースは何で、どうであれば成果といえるのか。足りないものはなにか。多少のはったりは必要かもしれないが、基本的には大きなリスクを会社や上司にとらせないで最初の勝利を得るには何ができるか。(ちなみにここで大きな借りを作ってしまうと、要求水準が高まって、無理な成果を求められたり、叱責されることになるので、できれば大きな借り物をせず、バットを短く持って振りぬきたい。借りるにしても少人数からとしよう。踏み倒しても許してくれるような信頼関係のある相手=パトロンがいれば最適だ)。

Software in 30 Days でスクラム共同創設者の二人は「パイロットプロジェクト」の選び方として、2つ選ぶように推奨している。失敗してもリスクの小さい新規事業のようなものと、社内で重要な機関となるプロジェクトだ。もし、上級の管理職の指示やサポートの上で行うならば、そうした戦略がよいだろう。もしそれほど支援を得ていないのであれば、もっと軽量に始めるほうがよいように思う。組織を一切いじらず、既存のチームである程度始められるならそれが一番良い。

3. ものの置き場を確保する

仲間と初期の目標を決めたなら、まず大事なのが、ものの置き場を確保することだ。そんなことあとでいいと思う人もいるかもしれないが、トヨタ生産方式でも、道具の位置を決めることはとても重要と考えられているという(要出典)。企画はどういうフォルダに置くのか、ソースコードや成果物はどこに置き、誰に見てもらえるようにするのか。デリバリー先のサーバやハードウェアはどこか？ネットワークは用意できているか？実は多くのアジャイルコーチングの現場で最初に問うのがこの点だ。遅いプロジェクトは、だいたいここができていないか、複雑すぎるか、後回しで考えていない。アジャイル最大の敵が、堅牢というか、昔ながらすぎる会社のITインフラだったり、そうした人々の無知だったりするのっではなかろうか。まずそうした部門への味方づくりが必要という場合も少なくない。

社内の根回し、というと大げさだが、あなたがもし「相手が何者かもわからない人から特別対応を求められた」としたら、どうするか考えてみてほしい。上司と相談のうえで、正式に断る理由を考えるのではないだろうか。こちらも忙しいのだ。特に何かをなそうとしている人であればあるほど、忙しいので、関係ないことに巻き込んでほしくないものだ。社内で最初に成果を出すためには、ここは避けて通れない。同意してくれない相手でも、戦わないですむような線引きをしておくことが重要だ。しばらくはお目こぼしをお願いして、その間に成果を出せばよい、かもしれない。

4. 成果をアピールする

成果がでるかどうかは、進め方次第だろうが、忘れてはいけないのは、アピールすることだ。人は、やらせてほしいときにお願いすることは熱心だが、やり終わった後の宣伝は面倒くさがる。しかし、やったことをアピールすることはとても重要だ。組織にとってもあなたにとっても。アピールによって、次のステップに向けての理解を醸成することができる。逆にアピールできないとしたら、目標が間違っていたということかもしれない。アピールの仕方も求められるものも組織文化によってまちまちだ。誰も聞いてくれなさそうな時は、社外コミュニティで発表するのがよいかもしれない。もし社内が社外発表を許容しないような文化なら、コミュニティの先達に相談してみるだけでも、自分の立ち位置が明確になるはずだ。

5. やったことをふりかえる

自分たちでやったことをふりかえる時間をとることも極めて重要だ。まず、ノーム・カースの最優先指令「どんな道をだどったにせよ、当時の知識・技術・能力・利用可能なリソース・状況の中で、みんなができる限り最高の仕事をしたはずです。それを心から信じます。」を肝に銘じよう。そして、自分たちがやってきたこと、できていることを認識する。そのうえで、次の実験をどうするか、考えてみるのだ。

kawaguti.hateblo.jp

6. 技術的負債を解消する

ソフトウェアシステムというのは、おそらく、いつか破綻する構造物だ。一度書いたものが永遠に動き続けると考えるのは幻想にすぎない。しかも現代のソフトウェアのほとんどは他社が作ったライブラリにそのほとんどを依存しており、自分が書くコードなどはほんの一部、多くても1%にも届かないだろう。既存の優れたライブラリや仕組みを使って、自分たちのしたいことを組み上げるのがソフトウェア開発というものだ。常に陳腐化するし、常に不確実性というものが存在する。すでに書いて動いエイルコードでも、不断の注意をもって学び続けなければ、容易に操作不可能になる。様々な階層のテストを書く、リファクタリングを行ってコードを改善する、などは自分たちのコードをチームで再学習することにもつながる。中身がわからないのに、次の一歩を効率的に進めることはできない。アジャイルの要諦は、迅速に作れるチームを作ることだ。自分たちの作ったいるものに徹底的に慣れる必要がある。

スクラムマスターに関する翻訳書が出ます - ScrumMaster the Book

スクラムのコミュニティの皆さんと訳したスクラムマスターに関する本が出ます。開発チームの支援にとどまらず、組織全体でのスクラムマスターの働き方について、幅広く言及した本です。 

SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ

SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意ーーメタスキル、学習、心理、リーダーシップ [ Zuzana Sochova ]

 

そのコンセプト「スクラムマスター道 ScrumMasterWay」はこちらのサイトに手短にまとまっています。

scrummasterway.com

このサイトの翻訳は永瀬美穂さん。本書では日本語版序文をお願いしました。

ちなみにもう一人日本語版序文をお願いしていまして、ロッシェル・カップさん。原著でお読みいただいて、ご推薦をいただきました。

【7日目】『The Great ScrumMaster: #ScrumMasterWay』（Zuzana Sochova著）https://t.co/bg8sRLEVVB

これは一番最近読んだ本です。この本は友達が今日本語版を用意しています。私は序文の寄稿が依頼され、とても光栄です。
／１ pic.twitter.com/BokbVxGcDV

— ロッシェル・カップ (@JICRochelle) May 12, 2020

この本の面白いところ 

この本のどこがおもしろいのか、といえば、ちょうどさっきFacebookにこんなことを書きました。

スクラムマスターの本なのに、まるで組織そのものの隠れたプロダクトオーナーのようなビジョンを持ってるところですこれをエグゼクティブ向けに書いてないあたりは、いかにもスクラムだと思う。傾聴や促し、コーチングなどの知識は深くて果てしないものなので、あえてそこに深く立ち入るのではなく、ポインタと簡潔な説明で済ませ、組織全体に目を向けさせようとする。開発チームやスクラムマスターが初期の成功のあとで、しばしば内向きになってしまうことを戒めている。プロダクトオーナーであれば、ビジネス的な結果が出ないことで間違いを否応なく知ることになるが、開発チームやスクラムマスターは、自ら目線を上げない限り、Us and them (あいつらわかってない)になりがちなのかもしれない。少なくともスクラムマスターは、長期的なチームの成功を目指して、様々なリスクを顕在化し、一つ一つ潰していく手助けをしないといけないのだろうと思う。テストはこけるし、UIはいけてないし、コードは腐っていく。人は痛みに慣れる。いつのまにか、焦燥は当たり前にとって変わり、安定は慢心に変わって足元を脅かす。改善し続けないといけない。コストを下げ、当たり前をアップデートする。目に見える戦いが始まる前に、勝っておかないといけない。オペレーショナルエクセレンスを実現するために、今日何をするのか。ヒントをちりばめ、調べやすく整理してくれている。

翻訳作業の過程も面白いので、これは折に触れて訳者陣から発表されていくものと思います。同じく自分のFacebookより。

しかし訳者陣が一人として同じ組織にいないのが面白い。コミュニティで集まって訳した、というのがバッチリ当てはまる。たまにZoom集まって、くだらない話をしながら、淡々とリモートモブプロで訳をみていく。コロナがきたことで期せずして当たり前になったこの働き方を、昨年からずっと探求してきました。リモートワークでも全然変わらず働けているのは、この翻訳作業によるところも結構あります。楽しかったです。ありがとうございました。

原著はこちら

アジャイルではおなじみ、Mike Cohn Signature Series です。

Great ScrumMaster, The: #ScrumMasterWay (Addison-Wesley Signature Series (Cohn)) (English Edition)

Great ScrumMaster, The#ScrumMasterWay【電子書籍】[ Zuzana Sochova ]

 
書いたのは Zuzana Shocova (ズザナ・ショコバ) さん。チェコにおられる認定スクラムトレーナーです。チェコのアジャイルコミュニティイベントを立ち上げた人でもあるそうです。カンファレンスで何度かお会いしていて、「あなたはどこにでもいるね」と言われております。

RSGT2021で基調講演していただきます

この出版のタイミングもあり、Regional Scrum Gathering Tokyo 2021 では基調講演をお願いすることになりました。左上の赤髪の女性がズザナさん。

2021.scrumgatheringtokyo.org

おたのしみに！

XP祭り2020 にご協力いただいた見本誌・寄贈本を随時公開していきます。

XP祭り2020は9/19(土)にオンラインで開催されます。オンラインでは場所は特にありませんが、アギレルゴコンサルティングの新宿のオフィス Agilergo Dojo としてご協力しております。

jp.agilergo.com

 

アジャイルコミュニティへの入り口。XP祭りもオンラインへ

XP祭りは初めて開催されて以来ずっと、週末に無償で行われてきたイベントです。初心者/入門者の比率が高いのが特徴です。かくいう私も初めて参加したアジャイルコミュニティイベントはXP祭りでした。

ここ数年はずっと鷲崎先生のご協力で、早稲田大学さんをお借りしてきたのですが、残念ながら今年はコロナということでオンサイト開催は行わず、オンラインで開催されます。オンラインのZoomなどのアカウントに関しては、スクラムフェス大阪が支援しています。

お寄せいただきました見本誌・寄贈本を公開します

XP祭りでは例年、出版者さまや有志のご協力のもと、見本誌や寄贈本をいただきまして、当日陳列しております。新しいかたが、自分にあった様々な良書に出会うチャンスになっているのではないかと思います。

日本のアジャイルは英語圏に比べるとやはり翻訳書によって知識がいきわたっている面が大きいと思いますので、この活動が20年近く続いているのはすばらしいことだと思います。ありがとうございます。

昨年のリストはこちらです。今年もいずれ本編にマージしたいです。
http://xpjug.com/xp2019-sponsor-presentation/#more-4736

SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発

SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ

Python2年生 データ分析のしくみ 体験してわかる! 会話でまなべる!

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

アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き

エクストリームプログラミング

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

情熱プログラマー ソフトウェア開発者の幸せな生き方

アジャイル・ユーザビリティ ―ユーザエクスペリエンスのためのDIYテスティング―

リファクタリング 既存のコードを安全に改善する（第2版）

アジャイルコーチング

実践 反復型ソフトウェア開発

テスト駆動開発

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

Gitによるバージョン管理

プログラミングElixir

ゴール&ストラテジ入門: 残念なシステムの無くし方

現場のプロが伝える前処理技術 ~基礎から実践まで学ぶ テーブルデータ/自然言語/画像データの前処理

つくりながら学ぶ! Pythonによる因果分析 (Compass Booksシリーズ)

リバースエンジニアリングツールGhidra実践ガイド (Compass Booksシリーズ)

Webサイト高速化のための　静的サイトジェネレーター活用入門 (Compass Booksシリーズ)

Pythonハッカーガイドブック (Compass Booksシリーズ)

誰でもつくれる！UIデザイン入門

Scaling Teams 開発チーム 組織と人の成長戦略 (Compass Booksシリーズ)

ビッグデータ分析・活用のためのSQLレシピ

現場のプロから学ぶ　SEO技術バイブル

プログラマーのためのVisual Studio Codeの教科書

ソフトウェアテスト技法練習帳 ～知識を経験に変える40問～

人工知能のアーキテクトたち ―AIを築き上げた人々が語るその真実

みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた

動かして学ぶ量子コンピュータプログラミング ―シミュレータとサンプルコードで理解する基本アルゴリズム

Effective Python 第2版 ―Pythonプログラムを改良する90項目

WEB+DB PRESS Vol.118

オブジェクト指向UIデザイン──使いやすいソフトウェアの原理 WEB+DB PRESS plus

[増補改訂第3版]Swift実践入門 ── 直感的な文法と安全性を兼ね備えた言語 (WEB+DB PRESS plusシリーズ)

[新版 zsh&bash対応]macOS×コマンド入門 ──ターミナルとコマンドライン、基本の力 (WEB+DB PRESS plusシリーズ)

Python実践入門 ── 言語の力を引き出し、開発効率を高める WEB+DB PRESS plus

リモートモブプロの原則

コロナ前からですが、リモートでモブ作業をすることがすっかり当たり前になりました。会議を含むリモート作業がうまくいくための条件はいくつか思い当たるのですが、こちらのサイトでシンプルにまとまっていたので、紹介したいと思います。

Remote Mob Programming | How we do Remote Mob Programming.

紹介されている原則は以下の15個です。

1. Remote Everybody (全員リモート)

2. Camera Always On (カメラは常時オン)

3. Regular On-Site Meetings (定期的に対面で会う)

4. Small Team (小さなチーム)

5. Same Time (同じ時間)

6. Typist and the Rest of the Mob (一人は入力者、残りはモブ)

7. Screen Sharing (画面共有)

8. 10 Minute Intervals (10分インターバル)

9. Git Handover (Gitで引き継ぐ)

10. Group Decisions (グループで決定)

11. Constant Momentum (常に前進する)

12. Learn from the Team (チームでお互いに学ぶ)

13. Trust (信頼)

14. Save the Planet (地球環境に優しい)

15. Dine with your Family (家族と夕食を)

とにかく信頼が大事で、他のメンバーがどんな人かがわかっていれば、結構気にならないことが多いです(3と13)。そのためにはチームが小さいことも重要で、見えない人がいるとちょっと気になりだします。特に時間が迫って焦っているようなときはひどくなりがち(5)。人数が多いとファシリテーションも必要になってしまいますしね。「均等に、順番に話す」みたいなファシリテーションをしてしまうと、話しているんだけど、チーム全体の成果に向かって進んでいるのかがわからなくなることがよくある気がします。

進め方については、常に成果物を中心において(8)、一人が代表して入力し、コンピュータの延長の拡張入力装置(Hunter)のように、基本的にはモブからガイドしてもらって進みます(7)。全員がサポートしたり、意思決定します(11)。入力者は定期的に交代します(9)。

家から移動しないので地球環境に優しく(15)、移動時間もないので家族と夕食を取るのもやりやすい(16)といったあたりもリモートの大きなポイントですね。

やっている人にとってはほぼ説明不要で、共感することばかりだと思います。

以上、リモート作業をうまくやるシンプルなルールとして、"Remote Mob Programming"のサイトを紹介しました。