The Phoenix Project : 自社の情報システムの開発・運営を体験するワークショップ

ITプレナーズさんで主催しているDevOpsの体験型研修がありまして、見学させていただきました。

この研修はオランダに本拠をおく GamingWorks 社が開発したワークショップをITプレナーズさんが日本語化(のお手伝い)をしたものです。GamingWorks 社はAgileやプロマネ向けのゲーム形式研修を手がけているようなので、今後の拡充が期待されます。

https://www.gamingworks.nl/business-simulations/the-phoenix-project/

継続的デリバリーの先の世界

ここでいう DevOpsについては、Phoenix Project を参考にしていただくとよいかと思います。当初の DevOps の定義はインフラやデプロイの自動化を中心に考えられたものですが、サイロ化が進行した会社が本当に変化のスピードを上げるためには、組織間の連携や会社全体のプロセス見直しが必要、ということになり、こちらを取り扱う本が多くなっています。

The DevOps 逆転だ!

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

改善すると次の壁が見えてくる

アジャイル開発の現場では、チーム開発をはじめてしばらくやっていると、だんだんデプロイが問題なくなり、次は開発や品質がボトルネックになり、そこも改善していくと、次はプロダクトオーナーが問題になる(バックログがジリ貧)、というのが黄金パターンのように感じます。得意なところ、手の届くところから初めていくと、だんだんその先にボトルネックが移動していくんですね。

以下の例は私が一時期やっていた流れなのですが、このパターンは多いかなと思います。

1. バージョン管理や開発環境を整備して、常時結合をする。
2. インフラを整備し、デプロイを自動化し、開発環境と本番環境の差異を縮める。
3. 開発の人員安定化とスキル習熟が進み、品質が安定化する。
4. プロダクトバックログの洗練が進む。不要なものを積み込む習慣がなくなる。新たな要望に即応できるようになる。
5. 新しいビジネス施策に人員追加なしで対応できるようになる。イノベーションに継続的に対応できるようになる。

自分のチームがうまくいったあとにぶつかる壁

後半で特に大事になってくるのが組織内の連携です。連携というと「みんなでやる」感じに聞こえるかもしれませんが、実際のところは全員にお願いして「気持ちよく動いてもらうように計らう」動きが必要になります。相手を尊敬・理解して、こちらを信じてもらって、自律的に動いてもらう。この部分は、なかなか外部のコーチには難しくて、社内の人の信頼貯金を試されるところかなと思います。

もし自分自身や仲間が十分な信頼貯金を持っていれば、バリューストリームマップのワークショップをしてデプロイや運用のムダをみんなで省くように改善を進めていく、とか選択肢が見えてくるのですが、信頼貯金がないとなかなかうまく始めにくいです。

業務ITシステムを題材に

人事システム、給与システムやPOSシステムなど、実際によくある業務ITシステムを題材に、全社のプロジェクトを進めるのがワークショップの本線です。

さまざまな役割の人と一緒に体験する

ワークショップのいいところは、自分だけでなく、他の人も一緒に参加できるところです。一人だけ研修を受けて他の人に全部伝えるのはかなり無理ゲーですので、関係者と一緒に参加して、やりながら実際の打ち手を考えていくことができれば、高速にトライアンドエラーを繰り返すことができるようになります。組織の課題は組織ごとに違いますので、それぞれで試行するしかありません。

共犯関係を作る

実践的なワークショップを一緒に体験し、議論したり苦労したりすると、共犯関係ができます。同じ場所で同じことを学んで、語り合った仲というのは、その人が会社にいる限り、宝になるでしょう。私たち vs あの人たち、ではなく、問題 vs 私たちの関係になりやすくなります。

お金のことを考える

あと、これは日本の開発コミュニティの特徴なのかなと思いますが、お金の流れを把握していない時があります。マネジメントですら企業会計がわかってない人も結構いるので、なかなか難しいところなのですが、売上とコストは連動しているものなので、感覚を掴んで、施策を人任せ(またはブラックボックス)にせず、一緒に考えていける組織文化を育めれば、より健全に経営できるようになるのではないかと思います。

役割に分かれて実際にITプロジェクトを進行していく

CFOの視点としてどうしていくか？必要な情報システムの予算配分や、当面のプロジェクト進行をどうしていくのか。みんなの意見がどうか。役割分担を変えるとどのように次のイテレーションでのアウトプットが変化するか、優先順位を変えるべきか、各役割に分かれて議論しながら進めていきます。

タイムボックス: 計画とふりかえりの力

ワークショップでは定期的に計画とふりかえりを入れていきます。次にどのような優先順位で進めるのか、前のイテレーションの結果を受けてもっとよくできるところはどこか。

まや、最後に全体のふりかえりを通じて、今日何を学んだのか、持って帰れるものはなにかを話し合います。

緊急の問題に対処し、計画に反映する

プロジェクトが無風で進むことはほとんどありません。問題が起きた時こそ、組織の力が試されるともいえます。緊急の作業を、計画していた作業とどうバランスするのか。どのように意思決定していくのか、練習していきます。しかも障害というのは重なるもので...。時間は刻々と過ぎていき、議論する時間も、対応する時間を削っていきます。なにを諦め、なにを守るのか....。

「ooとxxはやめることになりました」「えっ？なになに？じゃあ、aa は？」「それは残るみたいです」「わっ、残り5分」「はーい、まとめまーす。aaとbbは残します」「えっと、それでも溢れてます」「おっと、どうしようか」

とにかく歩き回る、とにかく声をかける

一つの部屋でワークショップで、部署間のコミュニケーションをシミュレートします。

情報は足で集める...というのは昔から言われることですが、リアルタイムで起きている課題に複数の担当間で調整しながら対応するには、歩き回って情報を見回し、声をかけて情報を確認するのが一番早く、必然的に歩き回って話し合いながら進みます。

全体ふりかえりで学びを確認する

最後に全体ふりかえりで今日の学びを確認をします。見学した回では、以下のような意見が出ていました。

• 「ふりかえりはやっていたが、ファシリテートや質問で深掘りすることができていなかったことに気づいた」
• 「他の担当に対して、上から目線でなく、相手の立場に立ってコミュニケーションすることの重要性を再認識した。」
• 「監査対応や標準化の意味がわかった」
• 「システム投資にビジネス側の視点を入れることが重要だと思った」
• 「3回目のイテレーションで、進め方を見直して改善を考えることができた」
• 「IT部門に勤務しているが、ユーザー部門に参加してほしい」
• 「ビジネス部門、IT部門、管理部門でどのように同期を取るのかがわかった」
• 「仕事を進めるのが楽しいって思えた。これが働き方改革なのでは」

いつも一緒に仕事していない他部門の人と話し合うきっかけとしてもいいでしょう。意外と議論やファシリテートが上手い同僚を発見することになるかもしれません。

技術的負債の根源にある相互無理解をつぶす

技術的負債が多くなるのは、開発者以上に、マネジメントが無理解であることが原因だということが多いのではないかと思います。解消するためのコストを取りにくい、評価されにくい、理解されない。その結果、次の手が打ちにくくなってしまうのですが、その領域に詳しくない人にはぱっと見、わからないものです(基礎的理解がない人に、わかるように説明することも難しいものです)。その辺りをちゃんと見抜く眼力や、他の専門家たちとの人間関係を築いていくことが重要になってきます。

さまざまな視点で組織を見直そう

一歩引いたところから、いくつかの視点を取り入れて、自分たちの現状を見つめ直すために、こうした研修やワークショップに参加する機会をぜひ利用していただければと思います。

おまけ : 組織で新しいことを進めたい方へ

組織内でさまざまな人を巻き込んでいくなら、この本がバイブルだと思っています。モブプロの聖地 Hunter Industries で学んだこと - kawaguti’s diary の Chris Lucian さんもオススメしてました！

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

電子版が出てました！

Fearless Changeアジャイルに効く〜アイデアを組織に広めるための48のパターン【電子書籍】[ Mary Lynn Manns ]

なお、研修の問い合わせ先はこちらだそうです。

講師育成含めた研修受講にご興味がある方

株式会社ITプレナーズジャパン・アジアパシフィック

https://www.itpreneurs.co.jp/contact-us/

純粋な研修受講にご興味がある方

クリエーションライン株式会社

https://www.creationline.com/contact

Azure DevOps の パイプラインで静的Webサイトを GitHub からデプロイ

Azure DevOps を使って、GitHub に置いてある静的なWebサイトをクラウドにデプロイしてみたので、そのやり方をメモしておきます。

やりたいこと : Webサイトにファイルをごそっとおきたい

長らく放置していた静的Webサイトの引越しをやるにあたって、ついでに自動デプロイの練習をすることにしました。

結果として、masterにpushすると、自動的にサイトに配置されるようになりました。

初心者がやるタスクとしては最高にシンプルなやつだと思ったのですが、あまりに簡単すぎるのか、ちょうどいい記事が見当たらなくて、ちょっと調べながら進めることになりました。

Azure DevOps とは

Azure DevOps はSam Guckenheimer さんたちが作っているクラウドサービスで、もともとはVisual Studio Team Services とか Team Foundation Server とか言っていたものです。もともと DVDに入れてインストール型で売っていたアジャイル支援ツールを、クラウドに移行しました。プロダクトバックログ管理、デプロイパイプライン、アラート管理などが統合されています(バラバラでも使えますので今回はパイプラインだけ)。

azure.microsoft.com

ビルドを作る

今回やりたいのはGitHubからコピーするだけの作業ですが、それを行う「ビルド」を作ります。

[Pipelines]-[Builds] -> [+ New]-[New build pipeline]

https://dev.azure.com/

更新元のファイルはGithub.comにあるのでGitHubを選択。

プロジェクトにGithubを連携してあると、自分のリポジトリを検索できます。

プロジェクトのGitHub連携は左下の project settings から GitHub Connections で [ + New Connection]でアカウントに紐づけて、連携対象のリポジトリを指定します。

GitHubのリポジトリ直下に azure-pipelines.yml があると自動的に読み込むみたいです。

設定ファイル azure-pipeline.yml の内容

今回の azure-pipeline.yml の内容はこれです。

masterブランチの更新をトリガーにして、WindowsのVM上で AzureFileCopyコマンドを実行し、SourcePath (規定値では作業ディレクトリ直下 = 対象リポジトリをクローンしたルートディレクトリ)　から、ディレクトリの内容をごっそり対象のBlobストレージにコピーします。

trigger:
- master

pool:
  vmImage: 'windows-2019'

steps:
- task: AzureFileCopy@3
  inputs:
    SourcePath: 
    azureSubscription: 'Free Trial (3372c....)'
    Destination: 'AzureBlob'
    storage: 'innov......'
    ContainerName: '$web'

 Azure DevOps上で設定を変更すると、このファイルに保存され、GithubリポジトリにPushされます。ここで master ブランチが更新されるため、すぐにこのビルドジョブがキックされて実行されます。

pool: vmImageは、Linuxや、低いバージョンのWindowsでは動かないようです。AzureFileCopyの制約かと思います。

The Microsoft-hosted agent pool provides 7 virtual machine images to choose from:

• Visual Studio 2019 Preview on Windows Server 2019 (windows-2019)
• Visual Studio 2017 on Windows Server 2016 (vs2017-win2016)
• Visual Studio 2015 on Windows Server 2012R2 (vs2015-win2012r2)
• Windows Server 1803 (win1803) - for running Windows containers
• macOS X Mojave 10.14 (macOS-10.14)
• macOS X High Sierra 10.13 (macOS-10.13)
• Ubuntu 16.04 (ubuntu-16.04)

Microsoft-hosted agents for Azure Pipelines - Azure Pipelines | Microsoft Docs

task: AzureFileCopy が今回の処理のキモです。いつくかパラメータがあります。

azureSubscriptionと storage は、あらかじめ Azure上で作成したBlobストレージの情報を書き込みます。

sourceはちょっとハマったのですが、全部消すとビルドのローカルパスになると気づいて、消したらうまくいったのでそのままにしています。

ドキュメントによると $(Build.Repository.LocalPath)¥hogehoge とかやると Github 上のサブディレクトリが指定できそうです。

Source

Required. The source of the files to copy. Pre-defined system variables such as $(Build.Repository.LocalPath) can be used. Names containing wildcards such as *.zip are not supported.

Azure File Copy task - Azure Pipelines | Microsoft Docs

さて実行

右上の [Run] を押すと実行されます。GitHub で masterになにか push しても実行されます。私の場合は、azure-pipeline.yml でエラーになったので何度か書き換えたらそのつど実行されて解析が楽でした。

まずAzureのクラウド内にある待機中のエージェント(VM)がアサインされます。

リポジトリからチェックアウト(ダウンロード)して...

AzureFileCopyコマンドが実行されます。

黄色い文字で警告(Warning)が出ていますがこれは後で調べるとして...

下の白い文字「Uploading files from ...」 の行でコピーができたことがわかります。

エラーの場合はここが赤文字になってエラー内容が表示されます。

ジョブ終了。前述の２個の警告は気になりますが、ジョブは全て成功です。

Azure Storage の Blob にファイルがコピーされていることを確認！

https://portal.azure.com/

今回の作業にどれくらいかかったか

ちなみにいろいろ調べながら、10回くらいで成功したみたいです。エラーの原因はVMが Linux だったこと、パス指定が違っていたことでした(消したらすんなりいった)。更新予定のないサイトですが、いつでも直せるのは気持ちいいし、引っ越しも簡単(と思いたい)。

(備忘録) 試しに作ったビルドを消すとき

ビルドを消すときは、ビルドの名前を全部入力します。(1) の入力どうするんだろ、ってドギマギしたのですが、kawagutiの部分を入力していないことに気づきました。

余談:  Sam Guckenheimer さんの Agile2014の基調講演

余談ですが、Sam Guckenheimer さんの「マイクロソフトがいかにしてクラウド時代にシフトしたか」というAgile2014の基調講演は、私の中でもピカイチに衝撃を受けたスピーチでした。

devblogs.microsoft.com

27インチディスプレイで簡易モブ環境

借りているオフィスの応接フロアでミーティングをすることがちょくちょくあるんですけど、モニタもホワイトボードも壁もないので話しながら迷子になることがしばしば。そこで、オフィスとミーティングスペースを行き来できるくらいのサイズのディスプレイを買ってみました。

USB-Cでつながるディスプレイ

一年半前の機種ということで、最新の4KとかHDRだとかはないのですが、USB-Cの給電かつディスプレイポートになるドッキングステーションがついていまして、きっとケーブルがすっきりして持ち運びやすいのではないかと。

BenQ USB-TypeCドッキングステーション付きsRGB100%モニターPD2710QC 27インチ/ノングレア/IPS/WQHD/昇降/4辺フレームレス

買ってみると、ディスプレイとドッキングステーションの電源ケーブルが別で、かつドッキングステーションはでかい外部アダプタになっていて、置いておくには良いのだけど、今回の持ち運びたいというニーズにはちょっといまいちでした。いったん、マジックテープでグルグル巻きにしていますが、いずれ電源ケーブルの余長も含め、整理したいところです。

しかし、USB-Cを挿すだけでディスプレイが繋がって電源が給電されるのは未来感ありますね。それ Nintendo Switch でできる？そうですかすごいですね。あ、こんどSwitchもつないでみなきゃ。

Bluetoothキーボードとマウス

で、作業のために無線のキーボードとマウスを購入しました。キーボードの質より確実につながることを優先して、安定のロジクールのモバイルキーボードです。WindowsとMac二両対応している日本語Bluetoothキーボード。マウスも同様のものを。 

Logicool ロジクール K380BK Bluetooth ワイヤレス キーボード マルチOS:Windows Mac iOS Android Chrome OS対応

ロジクール M590 Multi-Device Silent サイレントワイヤレスマウス（グラファイトトーン）Logicool M590 MULTI-DEVICE SILENT Mouse M590GT

 作業してみると、二人だと一台のキーボードで交代しやすいのですが、四人だとちょっと回すのが面倒。ということで、もう1セット追加購入しました。これで資料作成だろうとコーディングだろうとモブでスイスイできるはずです。念のため、２セットとも一台のMacにBluetooth接続してみましたが、軽く試したレベルでは問題なさそうです。次の実戦の機会が楽しみです。 

このキーボードは、iOSにも対応していて、ボタン一つで接続先を切り替えられるので、持ち歩いても面白いかなと思います。電車の中とかで猛烈にメール打ちたくなった時とか便利そう。

一人作業の時もつかってみる

モブタイマーをポモドーロタイマーに使えるというアイデアをもらったので、使って書いてます。

mobster.cc

あと、ビデオ視聴も捗りますね(ダメパターン)。

大雨なのでリモートモビングをやってみた

コミュニティである本を翻訳しようということになって、経験者もそれほどいないので、まあ、とにかく最初から訳してみようということになりました。

進めるにあたって、集まって相談したところ、まあとにかくモブで始めてみましょうということになり、今回は三回目。(私は前回欠席したので二回目。)

しかし、今夜は大雨の日。

news.yahoo.co.jp

全員がリモート参加を試してみることになりました。

基本のモビング環境

まず前回、人が集まった時のモブ環境を説明しておきます。まあ、特筆すべきことはないのですが、大きなディスプレイ一台、代表の人がPCをつないで表示、適当に交代しながら作業しました。

もともとリモートの人が1－2名いたりするので、Zoomを使ってリモート接続はしていました。Google Docsを大写しにして、それをスクリーン共有するのと、並行して全員でGoogle Docsにもアクセスしてコメントや、いろいろ調べられるようにしておきました。

席を外してコンビニに行くときにもZoomの音声はつなげっぱなしにできるので、心置きなく移動できました。あと、コンビニの注文も受けられます。

チャットは特につかっていません。音を聞きながらGoogle Docs共有しているので、ほかの画面を開く余裕がないという感じもします。

リモートモビング環境

まず、5分ごとの交代を基本ルールに入れてみました。Mobsterタイマーを使って5分ごとに通知が来るようにします。全員回ったら簡単にレトロスペクティブをして10分休憩を入れました。

mobster.cc

モビングの注意点

5分に一回ドライバーを交代し、ドライバーは「考えながら話す(Thinking Aloud)」を心掛け、周りの人はどんどん話してアイデアを出していきます。基本的には目の前にある作業対象についての議論を進めます。

気になったところはGoole Docsのコメント機能でメモを残したりしました。Google Docsはちゃんとアカウント指定で共有しているので、誰のカーソルかとか、コメントかとかがわかるので、スムーズだった気がします。

とはいっても、ドライバーしか基本的には編集しないので、ほかの人は声で提案をするか、議論を聞いています。ドライバーは「こういうかんじでいい？」と聞き、周りの人が「いいと思いまーす」と返す感じです。すべての作業は二人以上の同意(Four Eyes)でもって進んでいきます。

 2巡目からは、このタイマーが走っているPCのスクリーンを共有することで時間もわかるようにしてみました。

Zoomの音声を改善する

あと、周囲の環境音を消すアプリを紹介してもらったので、途中から投入してみました。

blog.animereview.jp

krisp.ai

環境音が低減されてよかったみたいです。人によっては隣で洗濯機が回っていたそうなのですが全く聞こえませんでした。すごい。

私の環境だと、なぜかマイクをオンにすると、ヘッドフォンが左耳しか聞こえなくなるという相性の悪さを発揮してくれましたが、そんなにこまらないので助かりました。

たぶん思ったよりスローペース

多くの人が最初に思ったよりもスローペースで進んでいると思います。でも、とりあえず初めての人が多いので、このペースが大事な気がしています。自分たちのペースをつかまずに、コミットしてしまうとしんどいんですよね。そういう意味ではヘルシーな作業といえると思います。今後ペースが上がっていくのか、違う方法を考えるのかは、また今後の話。

自分たちの実力がわからないうちの、初期の見積もりは信用できないので、まあこれでいいんじゃないか、という合意をしています。わかっていても、なかなかこういう作業の仕方をすることができないような気もします。私たちの敵は常に憶測であり、未検証な要素をそれと知らずに土台にしてしまうことなのでしょう。

みなさんのご参考になれば幸いです。

米Target社の受入型集合研修(Dojo)でのモブプログラミングとDevOps

DevOpsDays Tokyo で来日してくれた、米Target社の  Michael Migliacio さんの記事を訳しました。衣料品小売の会社で、DevOpsやモブプログラミングを実践できるチームを作るための研修のお話です。

tech.target.com

一緒にレベルアップしよう - 多様な経験を持つ人々のチーム

Posted by Kin Wong & Michael Migliacio
Apr 15, 2019

人々の成長を促すために、みんなの経験をどうやったら楽しく共有しあえるのか？ … 私たちがエンジニアリングリーダーとしていつも直面している課題です。それには献身的で規律正しくある必要があり、最も大事なのはコミュニケーションです。チームメンバーのあいだで継続してコミュニケーションと対話が行われるよう促すことは、必ずしも簡単なことではありません。うまいやり方を探すのは、多くのみなさんが思う以上に大変な道のりなのです。

“小打も積もれば大木を倒す” Little strokes fell great oaks. - 日本のことわざ (訳注: 少しづつの努力を続ければいずれ大きなことが起こせるという意味)

道場の門を叩く

さまざまなチームの人たちが、Target(訳注: 筆者たち)の没入型学習環境(訳注:受入型研修施設)である道場(Dojo)にやってきて、さまざまな理由で助けを求めます。例えば、製品のプロトタイプ作成、アジャイルの習得、DevOpsのベストプラクティスの実践などです。ビジネスニーズを解決するために集められた、できたてのチームが訪れることもあります。最近訪れたチームはその典型でした。API型のWebアプリによって、コントロールルームの在庫を迅速・正確に管理できるようにするために、店舗ホスティングの経験の豊かな人たちが集められていました。このアプリはゼロからの新規開発で、弊社のCI / CDパイプラインを通じてデプロイされます。チームはスクリプト作成とDBクエリーの経験は持っていましたが、RESTfulの概念とCI / CDは多くのメンバーにとって馴染みがなく、オンボーディング(全員を参加させる)には膨大な時間を投資する必要がありました。

一緒に変わる

最初のステップは、技術知識の基盤を確立することでした。午前中、チームは講義に参加して教室スタイルで概念の紹介をうけます。午後に入ると、午前中に教わった概念を強化するように設計されたワークショップや実地体験をおこないます。このアプローチはチームが前に進むのを助け、コラボレーションを促進する環境を作り出すのに役立ちました。ソースコード管理、基本的なPythonスクリプト作成、RESTfulサービスの使用などのケーススタディを含む、様々な形式のアクティビティがあり、すべてチームとしてやり遂げるよう設計されています。ほんの数日間のハンズオン活動によるコラボレーションによって、チームの真の生産性が解き放たれました。「モブプログラミング」を通じて。

モビングで心を一つにする

モブプログラミングはソフトウェア開発のアプローチの一つで、チームが1つのモニター、1つのコンピューター、および1つのキーボードを介して同時に成果物に取り組みます。各チームメンバーには、数分間キーボードを担当する「ドライバー」役が回ってきます。時間はタイマーで測り、時間になったら交代です。キーボードにさわらない人も開発に積極的に参加し、技術的なハードルを乗り越えたり、解決策を調べたり、概念を説明したりしてドライバーを助けます。 モビング(Mobbing)はチーム全体の活動です。お互いが黙ってスクリーンにコードを書いていくのを眺めあう活動ではありません。

タイマーを忠実に守って行うことは本当に大切なことで、規律のないモビングだと、「キーボードを奪い合う」チームや、キーボードで積極的にタイプせず「絶ってしまう」チーム、取り組んでいることをコロコロ変えるチームになってしまうことがよくあります。Dojoでは、チームメンバー全員の参加を繰り返し促していくことや、Mobsterタイマーを使うことで、こうした問題を軽減します。Mobsterはオープンソースのツールで、参加者全員に順番を回したり、交代の時間になったら画面にちょっとしたメッセージを表示することで、確実に交代していくことを助け、「チームとしてソフトウェアを作る」ことに全員が集中し続けられるようにします。

このチームにとってモブプログラミングの利点は計り知れませんでした。モビングによって、各チームメンバーはグループと知識を共有できたのです。また、コードの作成、リファクタリング、およびテスト中にチームメンバーがアイデアを生み出す頻度が高まりました。モビングの各セッションを通して、生産的な会話が自然と頻繁に起こりました。

テスティング

今日のビジネス環境では、チームがビジネスの敏捷性と迅速にソフトウェアを展開するための器用さを備えていることは、関係を保つ上で不可欠です。ソフトウェアの変更やアップデートへの需要が高まっているため、CI / CDパイプラインの中で自動的にテストを行うことが不可欠です。この問題に対応するために、店舗ホスティングチームは、APIを作成する際にスペック駆動型開発(spec-driven development)を用いました。別の表現をすれば、Swaggerで定義されるAPI仕様は、どんなコードが書かれるより前に完成していました。このアプローチはチームにとって非常に役立ちました。チームは作業開始時点で各エンドポイントのデザインを詳細に理解することができるようになったからです。 Swaggerによってもたらされる互換性問題を解決するオープンソースのPythonテストライブラリpytestと組み合わせることで、チームはAPIエンドポイントの開発と並行して、ユニットテストと統合テストの堅牢なライブラリを構築することができました。

Pytestにより、このチームは堅牢なテストライブラリを構築し、それらをDroneのCI / CDパイプラインに統合することができました。何か新しいコードがマスターブランチにチェックインされると、Droneのジョブが起動され、、アプリケーションを構築し、Dockerコンテナにデプロイし、テストスイートを人手の介入なしに実行します。チームはテストとCI / CDを組み合わせて行うことで、開発プロセスを通して日々発生するエラーをキャッチできるテストインフラを獲得し、それによって自分たちがやりたい実験ができる自信を得ました。

結果

店舗ホスティングチームはすぐモビングできるようになり、研修中に醸成された信頼関係を大事にするようになりました。チームは一種の「集団意識」で活動するようになり、各メンバーはリズムを崩さずに交代できるようになりました。さらに、考えたことや意図は効果的に伝達され、キーボード操作の引き継ぎがあっても作業を続けるすことができます。モビングによって、チームが一緒に失敗し、一緒に学び、そして一緒にミスを修正することが可能になりました。チームはたった数週間のうちに、FlaskによるAPI開発、CI / CD、Python、PytestによるTDD、自動化、機密情報管理まで、幅広く取り組めるまでになったのです。

店舗ホスティングチームによって提供されたMVP(最低限の実行可能な製品)は期待を超え、新しいチームはソフトウェアエンジニアリングの概念を学び、さらに大事な、大きな相互信頼を獲得しました。

- - -

Kin WongとMichael Migliacioは、Targetでソフトウェアエンジニアリングチームをより良くすることに焦点を当てているシニアエンジニア/ Dojoコーチです。

(翻訳はここまでです)

本記事の翻訳には様々な方のレビューをいただきまして、特に松元健さん、新井剛さん、荒井裕貴さん、木村卓央さんからは修正提案を頂き、マージしております。ありがとうございました。他にもご指摘がございましたら、ご連絡いただければ幸いです。

モブプロの聖地 Hunter Industriees で学んだこと 〜 複数モブ編

日本は長かったゴールデンウィークが開けるということで、戻って働けるのかしらという話が飛び交ってますが、いかがお過ごしでしょうか。引き続き Hunter Industriees にいまして、学んだことをメモしておこう、というエントリです。前回のエントリは単体のモブプロについて気がついたことが中心でしたが、今日は複数モブについてです。 

Hunterで学んだことその8: 仕事領域 = モブ != 人

3つのモブを持つプロダクトに参加していているのですが、それぞれのモブは同じコードベースで、別の仕事をしています。モブごとに紙ベースのタスクボードをホワイトボードに作っていて、WIPは1に制限されてます。

これは私がソフトウェアを作る人生の中でも初めて体験したのですが、モブは作業場所なだけでなく、どの部分をいじっているか、も示します。フィーチャーブランチを切らず、トランクベースで開発しているので、同じところをいじるとマージが発生しますが、声をかけて避けているようでした。目の前で衝突とマージは起こっていません。作業が終わったらコミットして、 git push / pull / テスト で同期します。

Hunterで学んだことその9: ウィンドウはそのまま!

モブごとに2枚のディスプレイを使っているのですが、ウィンドウの配置はそのままにします。前の作業で開いたウィンドウはそのまま。IDE、シェル、ブラウザ、クラウドの管理コンソールのウインドウは基本すべてそのまま置いときます。シェルのヒストリに必要なものは全部残ってますので、思い出したり調べたりするのが楽です。ローカルで起動した開発用のサービスなどもそのまま使い続けます。ということなので、初めて参加する人がいても、環境構築タスクはありません。

ウインドウ構成の基本は、右画面がコードで、左画面がUI(ブラウザ)でした。テストを書くときは、左右にそれぞれコードとテスト。SQLスキーマやデータを調べるときは、左画面がDBで右がコード。ログを見るときも左画面に出すことが多かったです。

デプロイはもちろん自動化しているので、ローカルでの確認から、デプロイまでは一貫しています。本番リリースもモブで決めているようです。

ということなので、初めて参加する人がいても、環境構築タスクはありません。

Hunterで学んだことその10: モブでメールを出し、モブでメールを受ける

モブごとにメールアドレスが付与されているので、モブからメールを出し、モブで受ける感じです。「メール本文にモブの参加者名を書いておく」という慣習のようでした。

ハードウェアが絡む開発の場合、ハード内蔵ファームウェアの開発者との連絡が必要になります。Hunterではハードウェアの担当や、運用監視の担当は別のオフィスにいるのですが、適宜電話やチャット、メールで連絡を取ります。連携するハードウェアの実機も置いてあるので、常に確認しながら進み、何かあれば運用担当にログを解析してもらったり、ハードウェアの担当にファームウェアの仕様を確認してもらったり。「都合のいいとき電話して」といっておいて、モブはいつでも電話に出る、というようなこともやっていました。あと、近くのオフィスの人はたまに歩いてモブまで来てました。

Hunterで学んだことその11: やり方はモブ次第、モブをまたいだ問題解決も

3つのモブがあるのですが、びっくりしたのはやり方がバラバラなことでした。スキルも、タイマーの時間もバラバラ。モブで決めて、実験する。変えたほうがよければ変える。テストファーストで進めるかどうかもモブ次第でした。ローカルに置くテスト用のサーバの起動の仕方すらまちまちなのがすごいなと思いました。正解を決める判事も、取り締まる警官もいないので、正義を争う宗教論争にもならないのだろうなと思います。

ある時、隣のプロダクトから「ちょっとこれから一人参加してくれない？SQL query についてのセカンドオピニオン欲しいんだけど」と相談があって、一人手を挙げてさっと動いていきました。

Hunterで学んだことその12: このPCしばらく使えないから、あっちのモブに行こう

ちょうど大きめのWindows Update がありまして、モブ用のPCにアップデートを当てるためにしばらく使えない、ということになりました。他にもちょっと不調があったみたいで、しばらくだめだぞと。そこで10分もかからずに「あっちのモブで作業しよう」ということになりました。幸いカンファレンスで人がいないので、隣のモブスペースはあいてます。

移動して、さて前の仕事をそのまま継続するのかと思ったら、なんと移動先のモブのやりかけの仕事をはじめました。一人は隣のモブをやってた人だったので、内容はわかるのですが、さっきの続きじゃないのかーい。

「仕事領域 = モブ != 人」なので、考えてみれば、そのままの環境で作業を進めるほうがよいのですが、驚きました。

Hunterで学んだことその13: 休憩はいつでも

休憩はいつでも取ります。ちょっと抜けるわー、って言って電話に出たり、おやつを買いに行ったり。残っている人でモブは進みます。コードがよくわかっている主力の二人が抜けたときにも、そのまま続きをトライしていました。進みは悪いかもしれないけど、ちゃんと自分で考えて進めてみる。少なくとも学習は進むのだろうなと思いました。

ちょうど16時になったときに数人帰って、主力の二人が残ったのですが、グリーンの状態で15分くらいリファクタリングしてました。それもまた見てて勉強になりました。

Hunterで学んだことその14: カンファレンスで人が半分いないときも進む

ちょうどカンファレンスが重なって、半分くらいモブからいなかったのですが、残った人でバグフィックスやPOからの優先の要望を着々と進めてました。

Hunter の場合は、見積もりもしないし、事前にビジネス側に進捗の約束を行わないので、ベロシティが落ちるとか、スケジュールに間に合わない、と焦ることはあまりないようです。逆に、人がいないから、上司がいないから、ということで進めないこともないようです。

・・・という状態で大丈夫にするために、経営陣との間で様々な調整をしてきた結果だと思いますので、他の組織で簡単に真似できるものでもないのでしょうけれど、信頼貯金を貯め、ソフトウェアについて理解のある経営陣であれば、できるのかもしれません。

Hunterで学んだことその15: 金曜夜にコミットしない

これは海外の企業でよく聞くパターンですが、やはり金曜の夕方に慌ててコミットやデプロイはしません。コミットはすることがあると思いますけど、テストが通っている事が前提で、慌てません。「また月曜朝に考えよう」で作業終了してました。

Hunterでは、金曜14時から「Learning Time」になっていて、作業を中断してそれぞれの学習に時間を使います。AWSのe-Learningをやったり、言語を勉強したり、組織に関する本を読んだり、ということをしているようでした。

Hunterで学んだことその16: モブ解散後は自由時間

毎日だいたい16時にモブは解散になりますが、さっさと帰る人もいれば、個人ブースでメールを読んだり、勉強したり、様々に時間を使っているようでした。

16時に外に出てみると、まあ明るい。夏時間ということもあり。こんなに早く帰っていいのかな、と思いながらスーパーで惣菜買って帰る毎日でした。

だいたいメモしたことは書きました

だいたいメモは以上なのですが、まだ数日いるので、また気がついたことがあれば書くかもしれません。あと、写真をいろいろ撮ったのですが、これはそのうちまとめて許可もらって貼るつもりでいます。

下は、雨がふって出てきたカタツムリ。珍しいそうです。

 前回のエントリはこちらです。あわせてどうぞ。

kawaguti.hateblo.jp

モブプロの聖地 Hunter Industries で学んだこと

日本方面は、平成最後とか、令和こんにちわ、連休ながーい、という噂を聞いておりますが、私はなぜか米国に来ていて、フィーバーに参加できておりません。アベンジャーズは一応、公開日に観に行きました。字幕ないし、アメリカンジョーク(推測)とかは聞き取れなかったんだけど、そんなのどうでもいい感じの映像美でしたね。

Hunter Industries にお邪魔してます

モブプログラミング・ムーブメントを生み出した、Hunter Industries に来てます。２年前に半日だけお邪魔したんですけど、モブ自体には参加してなくて、もうちょっといろいろわかりたいな、と思いまして。1月にRegional Scrum Gathering で来日してくれた、Director のクリスさんにお願いしてみたら、いいよーってことだったので、お邪魔しに来ました。

ビザの関係で生産活動には従事できないのだけど、横で立ってるのもなんなので、モブには参加させていただいています。ただ、たまに回ってくる私の番でやっていることといえば、「alt-tab押して」「もうちょっと上にスクロールして」「xxxって打って」っていう指示をもらってちょこちょこ動かす程度だったり、他の人同士で議論してたりとかしてて、なんか申し訳ない限りです。いることによって生産性は押し下げていることは間違いないです。

Hunterで学んだことその１: 帰るの早くて、体調良さそうで、機嫌もいい

だいたい16時にモブは終わり。多くの人は「またあしたー」ってサーッと帰っちゃいます。それもそのはず、始業は8時。8:30くらいにはモブが始まって12:00-13:00のランチを挟んで、休憩入れつつモブし続けます。

全体的に日本の職場に比べると余裕を持って仕事してる感じはあります。サボってるわけじゃないんだけど。代わりに、体調悪そうな人が職場にいません。機嫌も悪くない。変わった人はいますけど、機嫌はいいです。

そういえば、変わった人が機嫌悪いと怖いですよね。自戒を込めて。

Hunterで学んだことその2: モブの集中度合い

ペアプロやモブプロは集中するから効率がいい、というような説明をすることがあるんですけど、実際Hunterではどうなのか気になりますよね。

モブは大きな二枚のスクリーンの前で仕事するんですけど、感覚的には、SFで出てくる戦艦の司令室みたいな感じです。ドライバーがオペレータで、周りの人が状況確認しながら意思決定していく。

作業中、ずっと話してるのが印象的です。朝会の時だけ集まって話して、あとは自席で静かに作業する日本のありがちな現場とは対極です。たまに歓声あがってます。いいやり方見つかったんでしょうね。

予定があれば、いつ抜けても大丈夫です。30分くらいで大体ふりかえりや休憩を入れるので、そのタイミングで抜けるケースが多いようです。

Hunterで学んだことその3: 調査と打ち合わせとテストとコミット

コード書くだけじゃなくて、いろいろなことをモブでやります。

• テスト (BDD)、デプロイ
• アラートの調査
• Webでライブラリや書き方を調べる
• コミット、git pull/push (モブ間で同期)
• ミーティング (電話会議)
• メールを読む (POから、問い合わせ、人事異動)

これらすべてを分担しないで、モブでやっていきます。常に情報が共有され、アップデートされるわけです。 

Hunterで学んだことその4: 慎重なコーディング

割とコード書くこと自体に慎重だと思いました。「こうしようと思うけどどう？」「いいね」という合意があって初めてコードを入力します。動作は最低限。ガーッといじることがないので、操作ミスがほとんど起こりません。

Webで調べた時にも、他のファイル見た時にも、コピペはそれほど多くないです。今時はIDEの力でミススペルは見つけてくれるからっていうのはあるかも。とにかく打ってコード補完を使う印象です。もちろんマジックナンバーとかはコピペですけど。

コミットのコメントも、ナビゲーターが言うことをドライバーが入力していきます。他のナビゲーターが「いいね」と言ったり、アイデアを足したり。

ペアではなくモブなので、3人以上を想像するかもしれませんが、最小の実施人数は2名です。4-5人の時もありますが、6人になった時は、しばらく後にみんなで相談して割ってました。

Hunterで学んだことその5: 「いいね」ってちゃんと言う

そこで、見逃しがちなポイントが「いいね」の表明です。ちゃんと他の人が言ったことに、同意するのかどうかを表明するのが大事っぽいです。だいぶ相手をしてくれているAndyの口癖は「Cool」です。

同意を表明することで、モブは前に進んでいくみたいです。

Hunterで学んだことその6: 立ち止まることを恐れない

モブの作業は進んでいくのですが、わからないところが出てくると、ちゃんと立ち止まって議論します。イラついたり焦ったりして適当に前に進むことがありません。

じゃあ今日の仕事が終わらなければどうするのか？Hunterでは見積もりをしません(No Estimation)。いつまでになにをやらなければいけないという約束もしません。

実はこれは昔 Woody Zuill がIT部門の長を引き受ける時にCEOに出した条件です。その結果、得られたものはちゃんと人の目が行き届いていて、バグの少ないないコード、そして、不具合の報告があればすぐに取り組むチーム、と言えるかもしれません。

私が参加したことや、カンファレンス参加者が多かったりして、スピードが下がるところもあるのですが、「そんな日もあるさ」と言ってました。事実としてそうなんですけど、日本の会社だとあんま言ったら怒られそう。 

Hunterで学んだことその7: BDDのコードカバレッジとリファクタリング重視

BDDでの自動テストを重視しています。Specification by Example といって、仕様を想定ケースのテストコードとして書き出すのですが、それをやり続けます。「どんなテストを書くべき？」と言う議論もよく行われます。

コードカバレッジも一応見ています。ラインカバレッジや分岐のカバレッジに目標値はなく、テスト時に必ずカバレッズがチェックされて画面に表示されるので、それを見て、ふーんという感じ。機能 = ストーリーカードあたりに数個のテストは必ず書いているようです。

「どういうテストを書くべきかな？」「うーん、この機能だと...とかはどう？」「いいね。どこに入れるかな」「xxxってファイルあたりじゃないかな」「名前はどうしようか」「xxxxとか?」「うーん、xxxxとか」「それいいね」みたいな議論をよくしていました。

テストを先に書くかどうかはモブによって違うみたいです。モブ間の差異どうしてるかの話はまた書きますね。

Hunterで学んだことその8: ゼロバグリリース

テスト上で既知のバグ = Greenになっていないテストをゼロの状態でリリースします。Zero Bugs ないし Zarro Boogs というプラクティスです。ソースコード管理ソフトウェアにpushする際のフックスクリプトにもテスト実行が入っていて、チェックします。

コミットログもモブで編集して、コミット内容も2人以上で確認して、コミットします。トランクベースで直接最新の本線にコミットするときもあるし、試行的にやる時にはブランチを切ったりもしてました。

7年ほど前の最初のモブチームでは1年半バグが出なくて、その結果、人数を拡張してみることになったそうです。目の前の機能やコードを全員で見て進め、設計も見直します。設計の見直しといっても、UML図を眺めながら唸るなんてことはほとんどなくて、コードを見ながらよりよい名前をつけ、メソッドをくくり出したりするリファクタリングが中心です。すべてが一歩一歩。粗製乱造されて行数だけが多いコードとは対極にある感じはします。専従のQA担当はいません。

つづきます

いかがでしょうか。すでにモブプログラミングやBDDをやられてる方からすると、普通に想像できる事が多いのかなと思います。

今回書いているのは「モブプログラミング」という手法の話ではなく、現在の Hunter Industries で行われているプラクティスを、私の目で観察したところです。あと、日本語で書いている都合上、スタッフの人達に読んでもらうこともできないので、ちゃんと訳して確認してみるとちょっと違うよ、というところはあるかもしれません。にしても、何かしらみなさんのご参考になれば幸いです。

複数モブのすすめ方とかは、また数日中に書きますね。(追記: 書きました。)

kawaguti.hateblo.jp

旅行の余談 : リゾート気分

モブについてはいったんここまでにします。ここからはちょっと旅行の話を。

最寄りの大きな空港はサンディエゴなので、初日はサンディエゴに一泊して、海リゾート気分でした。

翌日からは丘の上のAirBnBで山リゾート気分です。

今日は駐車場で同僚の車に少しぶつけてしまって、レンタカー会社の指示で地元警察のチェックを受けるなど、新しい体験をしました。従業員の皆様におかれてはまったくもって邪魔でしかない状況ですが、私は元気です。ぶつけた相手の車の持ち主は初日のモブ仲間のScottで、終始笑顔で保険会社や警察と連絡とってくれて、ナイスガイでした。Hertzのレンタカーだとハワイに24時間対応の日本語デスクがあって助かりました。安心大事。

ではまた。