リモートモブプロの原則

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

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"のサイトを紹介しました。

アジャイルテストの世界 - Agile Testing Condensed と実例マッピング

リサとジャネットの Agile Testing Condensed という短い書籍があるんですけど、これの翻訳をお手伝いしました。権利周りの調整のお手伝いと、翻訳レビューです。

leanpub.com

アジャイルテスティングという、日本ではそんなに盛り上がっていない分野がありまして。アジャイル時代にどのように品質を担保するのか、QAやテスターはどのように関わっていくのか、非常に大事なんですけど、なぜか日本ではTDD(テスト駆動開発)やテスト自動化についての注目に比べても、今ひとつ盛り上がっていない感じがします。惜しいことです。

Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example is used to capture examples of desired and undesired behavior and guide coding.

アジャイルテストは、アジャイルソフトウェア開発の原則に従ったソフトウェアテストの実践です。アジャイルテストは、顧客が望むビジネス価値を頻繁に提供することを確実にするために、テスターが提供する特別な専門知識を含め、職能横断的なアジャイルチームのすべてのメンバーが関与し、持続的なペースで作業します。例示による仕様(Specification by Example)は、望ましい動作と望ましくない動作の例を捕捉し、コーディングのガイドとするために使用されます。

Agile testing - Wikipedia

ジャネットとリサの本は最初が2009年です。これは同年のうちに当時IBMの榊原さん監訳で、IBMのQAの人たちが翻訳されたと聞いています。

Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley Signature Series (Cohn)) (English Edition)

 日本語訳はこちら。

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects' Archiveソフトウェア開発の実践)

で、この本の白眉は第５部です。

これは出版後しばらくして、私が個人的にジャネットを知り合って、読書会に参加するようになって知りました。世の中で受け入れられていたのは第４部以前の部分。テスト自動化の方法の分類や、アジャイルテスティング四象限の話でした。

第５部はストーリー仕立てになっていて、どのようにPOと開発者とテスト技術者がイテレーション(反復)を回していくかという部分で、実際にインデックスカードがバンバンでてきて、どのタイミングでどういった粒度で話し合うのかが克明に表現されていました。(ちょっと訳は難しかったようで、ちょいちょい誤訳を見つけましたので正誤表を翔泳社さんに載せていただきました。)

実はこの本のジャネットと、アジャイルサムライのジョナサンにはカナダで深い関わりがあり、双方の本に名前が出てきます。XP/TDDのコーチであったジョナサンがプロジェクトに呼ばれたときに、POがジャネットで、ジャネットはQA出身でした。そこで、ジョナサンがジャネットに言ったのが「XPでやるからQAいらないよ」。いやそんなことはないはず、というジャネットの思いから(リサと一緒に)アジャイルテスティングコミュニティが生まれ、アジャイルテスティングの本につながっていきます。 

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

その後、ジョナサンはSpotifyで初期はアジャイルコーチ、そのあとエンジニアとして働くことになるのですが、その間にWebでのテストについての入門書を書いています。

初めての自動テスト ―Webシステムのための自動テスト基礎

ジャネット来日に合わせてトークショーも行いました。 

codezine.jp

その後、続編である More Agile Testing が出版されました。BDDや Specification by Exampleなど、さまざまな技法がコミュニティでは開発されてきたので、そのあたりをフォローアップした本になっています。この本はまた読書会で読み進めています。 

More Agile Testing: Learning Journeys for the Whole Team (Addison-Wesley Signature Series (Cohn)) (English Edition)

で、２冊となると重いので、名刺代わりに配るにはちょっとかさばる。ということで、薄い本を作った、というのが最初に触れた Agile Testing Condenced です。薄いからといって網羅性は落ちてなくて、むしろ具体的なところは別の資料であたるわ、っていう人には必要十分かもしれません。

この本の中で言及されているのですが、BDDの人たちがやっている、カードを使ってテストを洗い出す技法が Example Mapping です。これも風間さんが訳してくれてますので、こちらをご覧ください。この記事のレビューもお手伝いしております。

nihonbuson.hatenadiary.jp

商業的なソフトウェアではもちろんテストが重要です。価値に直結します。ですので、こうした議論を適切にアップデートしていく必要があると思います。....頑張りましょう。

DevOpsDays Tokyo 2020 中止の経緯

DevOpsDays Tokyo 2020 は実施・オンライン配信・延期・中止を検討の結果、中止ということになりました。関係する皆様、ご支援いただいている企業様には大変ご迷惑をおかけしまして恐縮ですが、何卒ご理解をいただきまして、今後も引き続きご支援いただければ幸いです。

www.devopsdaystokyo.org

実行委員会での議論はどのように進んだか？

実行委員会での議論の経緯は以下のような感じでした。

まず中止の場合のコストを検討しました。会場費、キャンセルできない渡航費、通訳、あたりはかかってしまうけど、返金はしたいので前年からの繰越金を手当てしても、資金不足になることはほぼ確定しました。しかし、今後関係者に支援をお願いする可能性がありますが、なんとかなりそうという感触を得ました(ここ大事)。

海外スピーカーのほとんどは来日してくれる姿勢でしたので、そのまま開催する案を検討しました。ギリギリまで開催する方向で動いて、1-2週前に最終判断する案です。オンライン配信も準備して最悪無観客開催する案です。ありがたいことにオンライン配信のサポートをご提案もいただきました。この案は一見凄くいいのですが、スタッフの作業と判断の負荷が高いのが問題という話になりました。皆さんボランティアですし本業もあります。本業もカンファレンスも今後どういった対応が迫られるか不明な状態で続けるのはしんどい。また、パーティや懇親会は実施が難しいとなると交流できないのがつらい。「交流できないならやる意味がない」という委員もいて、そうだよねー、と思いました。

そのあと3ヶ月延期案が出ました。ちょうど同じ会場を使わせてもらえる可能性があったためです。これはよいのではないかということで、海外スピーカーがどう考えるかは保留として散会しました。その後、やはり海外スピーカーは旅程の組み直しなので難しいだろうという意見が出ました。

これまでの議論を踏まえて、仕切り直して来年に向けて頑張りましょう、と決まりました。

以上が決定に至る議論のおおよその経緯です。今後の安定したカンファレンス開催に活かせればと考えております。こういうことも検討したほうが良かったのではないか、などのご意見いただければ幸いです。

(2020/3/9 追記) 会場オーナーの品川区の決定で予約金が全額返金に

大崎ブライトコアホールのオーナーである品川区が今回のコロナウイルスの影響でキャンセルとなった場合の対応として、払い込んだ予約金が全額返金となりました。DevOpsDays Tokyoは、一ヶ月以上前に支払っている費用のほとんどが「会場の予約金」ですので、大変ありがたいことです。

協議の結果、2/20-5/31の期間でご利用予定だったお客様の

新型コロナウイルスの影響によるキャンセルの場合に対して

「ご予約金を全額返金」の対応が決まりました。

来年もぜひ大崎ブライトコアホールで行いたいと考えております。ビバ品川区。

西島カーブ - 戦艦大和を作った西島技術大佐

先週末はオープンセミナー広島さんにお邪魔してお話させていただきました。資料は下のものです。資料冒頭で「西島カーブ」の話をしました。

osh-web.github.io

speakerdeck.com

前日に観光に行った呉市の大和ミュージアムで、呉の海軍工廠の成り立ちから戦闘艦を国内生産する話を勉強しまして。そこで科学的管理法が連呼されてて、なんだろうと思って調べたわけです。

yamato-museum.com

そうしたら、西島技術大佐の「西島カーブ」というのにたどり着きまして。

http://hesaka.sakura.ne.jp/nishizima.html

もう10数年前に前間孝則の「戦艦大和誕生」を読んでいた時、主人公であるところの西島亮二が呉工廠で工程管理を行うために生み出された「西島カーブ」なるものが出てきた。しかしこの工程管理手法についての説明は概略のみであり、また造船所勤めと言え設計部所属で、工作や工程管理についての知識が無かった為に理解することができなかった。またネットで調べても当時は何も引っかからず、詳細については判らず仕舞いだった。

これむっちゃバーンダウンチャートなんです。実績をみて、将来を予想する。昨日の天気。大和の建造は、同型の戦艦武蔵の半分の工期でできたそうです。やばい。

戦艦大和誕生はこちらです。軍艦の製造に電気溶接を初めて導入したり、すごい話がたくさん出てきます。西島カーブのくだりはこちら

海軍では従来から、工事ごとにかかった工数の集計値は常に記録していた。しかし、こうしたやり方に対し、西島はこう言いきっている。

「最終点(最終の集計工数)の資料に非常に重点が置かれているが、これは一顧の価値もない」

その根拠として、西島ならではの次のような分析があった。

事前に見積もった予想される総工数(最終点)と工事スタートのゼロ地点を直線で結び、この右肩上がりのグラフ線に先の能率曲線が重なってうまく一致すれば、仕事は理想的に一定のペースで進行していることになる。途中で両グラフの傾斜がバラついて離れてくれば、なにか問題が起きて作業の能率を落としていることを意味する。その場合、造船官らはただちに原因を突き止め、早めに対策を打つことで、後続の作業への影響を最小限に抑えることができる。

それまでの海軍のやり方では、予算(見積もり額)と実績が最終的に一致するかどうかが問題だった。西島に言わせれば、これは責任上のつじつま合わせのための集計にすぎないという。

これでは、どこの職区、どこの職種で、どの程度の能率が悪かったのか(あるいは良かったのか)がつかめない。これがつかめなければ、次の鑑定建造の見積もり時に、工数をどのくらいに設定すべきかもわからないまま、同じことを繰り返すことになる。

次の建造工事の際に、あらかじめ前の工事で起きた問題点を潰しておけば、問題が起きなかったときの順調な能率曲線を設定しても差し支えないことになる。

能率曲線を刻々と描き、そのデータを感染の建造ごとに蓄積していけば、そpの後、新しく船を建造するときの有益な参考資料となる。人員の適正配分や予算の正確な見積もりにも利用できる。

造船の工事があまりにも複雑多岐にわたっているために、従来は、職区別、職種別ごとに、しかも刻々変化する能率を把握してきめ細かく管理していくのは無理だと考えられていた。その意味では、西島は造船の世界に能率の考え方をはじめて持ち込んだともいえる。

読み終わったらまたなにか書くかもしれません。

文庫 戦艦大和誕生(上): 西島技術大佐の未公開記録 (草思社文庫)

文庫 戦艦大和誕生(下): 「生産大国日本」の源流 (草思社文庫)

３月にDavid Bernstein さんの 認定スクラムデベロッパー研修を行います

 アギレルゴコンサルティングでは、Scrum Alliance 認定 の スクラム研修を数多く行ってきました。私たちが実際に海外で知り合った選りすぐりの講師陣にお願いしています。

次は、「レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス」の著者、David Bernsteinさんによる認定スクラムデベロッパー研修です。

勢い余ってやや宣伝っぽいのですが、ちょっと主催者の想いを聞いてください。

スクラムの基礎から健全なコードをメンテし続ける技術まで学ぶ

５日間をかけて、スクラムの基礎もカバーしながら、ペアプログラミングやリファクタリングを行いながら、チームとともに長生きするコードを生み出すための技術をしっかりと身につけるカリキュラムになっています。

開発技術を学ぶ機会の少ない日本

スクラムはやってみたけど、継続してプロダクトのリリースができていない。最初は良かったけどコードベースが大きくなって遅くなってきた。

おそらく課題は開発技術にあります。スクラムをやったとしても、開発技術を学ぶことができていなければ、高速にゴミをす生み出してしまいかねません。開発チームは継続してソースコードをメンテナンスできるように、技を磨き、アーキテクチャを手直ししていく必要があります。

実際に長く日本のソフトウェア業界にいる人間からみると、ソフトウェア開発技術自体を学ぶ機会が少ないと感じます。プロジェクトマネジメントや、製品企画については学ぶ機会がだいぶ増えてきたのですが、一方で足元の開発技術は、ツールの紹介ばかりで、本質を学ぶ機会があまりありません。昨年、アジャイル開発に携わる大小いくつかの北米の企業を訪問してきましたが、どの企業も技術や、技術の伝承、学ぶ時間をとることを重視していました。

熟練の技術者であり、技術者指導者としても熟練の講師

講師のDavidさんは、「レガシーコードからの脱却」の著者であり、長年IBMなどで実際にメンテナンスできなくなってしまったソフトウェアから脱却するための技術者指導に携わって来られました。1万人以上を指導してきたそうです。

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

技術者不足が深刻になってきた

IT部門やシステムインテグレーターさんで、実は一番多い問題が「しっかりとソフトウェアをメンテナンスし続けられる技術者がいない」であろうかと思います。数が少ない、ではなく「いない」という会社さんも多いのではないかと思います。しっかりと教育機会を作る必要があります。私見ですが、日本のソフトウェア開発の問題の一つは、上級者へのしっかりとした教育機会がほとんどないことだと思います。

北米の企業であれば、社内に80年代のデータベースシステムやOSの発明者がいたり、世界的なオープンソースプロジェクトの創始者やメンテナが闊歩しているのは珍しくないと聞きます。皆さんの環境はどうでしょうか？

技術力を持ったリーダーが必要な時代

米Microsoft に行かれた牛尾剛さんから聞いて驚いたのは、いま北米・欧州の企業では、マネジメント層も多くがソフトウェア開発の本質を理解している、ということです。「はげちゃびんがいない」という刺激的な言葉を使っていますが、実際に牛尾さん自身も自分がはげちゃびんであると感じて渡米したそうです。私たち日本人は、もっともっと技術力を高める投資を、やっていく必要があるのだと強く感じました。

Agile Japan 2019 応援メッセージ 未編集版

kawaguti.hateblo.jp

技術は常に新しくなり、私たちは継続的に学び続ける

私が知る限り、ソフトウェアの世界は常に新しい技術が生まれている世界で、これはこの先も変わらないのでしょう。継続的に学ぶ必要があり、学んでいると、学ぶのが幾分やりやすいという特性があります。

新しいものを学ぶことに慣れてくると、学ぶ困難が減っていき、より楽しめるようになります。新しいことを学んでいるなら活発な精神でいられますが、筋肉と同じように、脳も使わなければその力は衰えます。年を取ると、ソフトウェアを書くのは外国語を学ぶようなものです。神経活動を刺激し、心をシャープで機敏に保ちます。
しかし、ソフトウェア開発者というものは、仕事としてソフトウェアの生産が期待されているせいで、継続的に学ぶことが難しくなることがあります。その結果、しばしば業務時間外にも勉強しなければなりません。

達人たちは、学ぶことにも積極的で、持続的で、うまいと感じます。

kawaguti.hateblo.jp

達人から直接指導を受けるチャンス

ペアプロ中にハマって、先生に見てもらうんですけど、15秒くらい眺めてから、次に来る回答が神回答で。

前回の研修では多く参加者の方から非常に高い評価を頂きました。実は私もちょっとびっくりしました。この人本物だなと。本物の達人から直接指導を受ける、数少ないこの機会を、ぜひ活かしてください。

ww.jp.agilergo.com

カンファレンスの雰囲気作りについて

RSGT2020今年もつつがなく開催できました。お陰さまですごく楽しかったという声を多くお聞きしてほっとしてます。スタッフのみなさんおつかれさまでした。スピーカーの皆さんも高いプレッシャーの中、出来る限りのものをぶつけていただいて、本当に感謝していますし、すごいなーと思います。尊敬します。

すごく雰囲気が良かったというご評価をいただくことが多くて、大変ありがたく感じております。雰囲気作りについて、ちょっと思ったことをFacebookに書いたら長くなったのでブログに転記しました。

カンファレンス会場の雰囲気なんて参加者の人たちが作ってるものなので実行委員はなにもしてません。なるべく会話を邪魔しないで済むように空間を考えたり、大きく声を出して指示しなくても自然と必要な場所に流れるのがベスト。そのために例えば受付では変な人が入ってこないようにリスクを摘み取ってたり、場を壊してしまいそうなリスクをどんどん排除してる。

企画側のエゴで盛り上げたいとは思ってません。基調講演は実行委員で決めさせてもらってるけど、純粋に自分たちが聞きたい話を呼んでるだけで。去年うまくいってそうなことは基本そのまま。検査と適応の繰り返し。出来るだけ手抜きする。他の誰かに呪いを押し付けるくらいなら、やらない。無理しない。だれかが無理するようにもしたくない。

「自分が関わる以上もっと貢献してよくしなければ」とか思ってる人がいるとしたら、そんなんいいから、ちゃんと朝きて、元気に帰ってもらうことが大事。事故なく怪我なく終われば楽しい。今年風邪ひいたら来年頑張って。

ハコの大きさを無理せず、チケットが売れてるなら資金的には気にしなくていいので(入手困難ごめんなさい)、必要なところはお金で解決する。でもアウトソースすると必要な情報揃える事に忙殺されるので、必要なとこだけ継続的にお付き合いしたい。去年と大体同じです。わかりました。で発注したい。

これをやったらいいと思う！そうだね！誰がやる？いないね。じゃあやめとこう。で結構いろんなことを廃案にしてます。やれるならやったらいいし、うまくいったら続けていきたいけど、無理しない。正しい無理などない。

実行委員もボランティアも2/3以上の人が熟練なので、いつもの感じで自律的に対応できる。たぶん参加者もスポンサーさんもそう。そこに画期的な新企画なんていらないのでやらない。基本去年と同じ。ご飯があって椅子と机があって仲間がいれば楽しい。話し合えれば学びが最大化する。また来年も来ようと思う。同僚も連れてきたいと思う。知り合いにも紹介しよう。楽しくて、やりたいことができて、学びがある。ディズニーランドみたいなもの。キャストとゲストがいるだけ。そこに一方的にサービスされるお客さんはいないんです。

ということでうまくいっているとしたら偶然なので、もっとこうしたい、みたいなご提案はありがたいですけど、やるとなると現状維持を優先したいです。収容人数を倍にしろ1000人いけるとか言われても、場所探しからファイナンスから動線からスタッフ配置から諸々、やったことないことが増えれば増えるだけ、チームや場が不安定になるのは、スクラム から学んでることじゃないですか。

規模を大きくするにしても30%くらいまでにしたいのは、常に2/3は去年と同じにしたいから。同じような会場、トラック構成、スポンサー規模、飲み食い、参加者やスタッフ。「30%は人工的な数字」って言われたけど、割と根拠あると思ってます。2/3を経験者にする。Succeeding with Agile に書いてあったように、文化は多数決なので。

初めての時って興奮して新しいものを足したくなるんですけど、Less is more で、ROI高くしないと、自分が楽しめないと思うんですよね。スタッフが一番楽しみたくてやってるのに滅私奉公だと続かない。スタッフが続かないと引継ぎ負荷が上がってROIが下がる。

スクラムも知られてなくて、チケットも売れなかった時代を経験してる人たちがいなくなると、またちょっと変わっていくのかもしてないけど、今はなるべく現状維持で、来る人の認知負荷が低い状態を維持したいです。馴染みの銭湯が毎回模様替えしてたら居心地悪いので(なんのこっちゃ)。

パックマンルールでぼっち対策

昨年初参加した、Agile Testing Days のぼっち対策のポスターが秀逸だと思いました。

パックマンルールを常に心がけよう。

Keep the Pac-Man rule, always in mind!

初参加の人や初対面の人が話の輪に入りやすくなるよう、必ず入り口を開けておきましょう、パックマンの口があいているように。

究極の対策でもなんでもないんですけど、このちょっとした心がけを普及させれば、「入れてあげるようにしよう」「入っていいのかも」という気持ちが少しだけ高まる気がします。

パクりたい。