asobannのAWS ECSデプロイでやったことと引っかかったこと その2

yattom.hatenablog.com

その1でasobannをAWS ECSに手作業でインフラ構築できた ので、これを自動化したい。CloudFormationかTerraFormを使うといいらしいと聞いて、あまり考えずにCloudFormationを使ってみることにした。これも初めて。

CloudFormationにアプローチしてたくさん間違える

軌道に乗るまでに、こんなことをした。

1. デザイナーを用いたチュートリアルで流れを把握
2. デザイナー上で自分で1から作ろうとしてみて、なにを作ればいいのか把握し切れてないことに気づく(コンソールからECSのクラスターを作ったときは、裏側で作ったり設定したりしてくれていたものがあって、それがわかってない)
3. アプローチについて調べていたらこちらの記事からテンプレートのサンプル にたどり着き、これを参考にすることにした
4. 手で作ったECSのクラスターからCloudFormationテンプレートを生成しておき、参照できるようにした

3番で見つけたテンプレートのサンプルが死ぬほど便利で、助かりました。

• どんなリソースが必要で、どうリソース同士をつなげるのか書いてある
• テンプレートファイルが分割してあり、わかりやすいし、分割するときの書き方もわかる
• YAMLの書き方、!Refや!Subの書き方の例が豊富にある

必要なリソース種類がわかれば、個々のリソースに必要な設定はリファレンスを見るだけなので、あまり苦労がない。

変える部分を見落とさないためにも、自分の理解のためにも、写経のように見ながら再入力しつつテンプレートを書くことに。理解は深まったけど、見落とし、ぽかミス、勘違いなどでたくさんトライ＆エラーを繰り返すことになったのでありました。

• 複数のアベイラビリティゾーンとサブネットを作って渡さないと、AutoScalingGroupでエラーになる(最低2つ、みたいな)。ここでサブネットを増やしたとき、AWS::EC2::SubnetRouteTableAssociationも合わせて増やさないと、ルーティングが狂って変な挙動になる(EC2インスタンスがクラスターのインスタンスにならない、サブネットのルーティングテーブルが勝手に変化する(ように見える)、EC2インスタンスにsshできたりできなかったりする)。エラーにはならなかったので気づきにくい。
• Service Discoveryで指定したホスト名が解決できず、VPCの設定で「DNS解決」と「DNSホスト名」の両方を有効にしたら解決した。テンプレートでは AWS::EC2::VPCに対してEnableDnsHostnamesとEnableDnsSupportを両方trueにする。(DNSホスト名が必要なのは解せないけど、こうしたら動いた)。
• Service DiscoveryのためにPrivate NamespaceリソースをCloudFormationで作成すると、HostedZoneが作られる(明示的に作らなくてよい)。サンプルにはなかったのでちょっと迷ったところ。
• LoadBalancerからTargetGroup(アプリ)にアクセスするには、SecurityGroupの設定が必要。LB用のSGとアプリのSGが異なるなら、アプリのSGはLBのSGからのアクセスを明示的に許可する必要がある。手で作ったときはアプリとLBを同じSGにしていたので、気づかなかった。なお本来は同じSGであっても通信は許可されていなくて、これはSecurity Groupについての基礎知識っぽいのだけど、VPC作成時にデフォルトでできるSecurity Groupでは自動で許可されているので、どうやら気がつかなかったみたい。SGさんいつも厳しい。いつか仲良くなれるだろうか。
• CloudFormationテンプレートを変更してスタックを更新するとき、Task Definitionが変わったりしてタスクが再起動することがあるが、このとき新しいタスクを起動→古いタスクを終了、という順序で動く(これはデプロイの設定で変わるような気がするんだけど、ちゃんと調べていない)。そのとき、新しいタスクを起動する分の余裕(CPUとメモリ)がコンテナインスタンス(EC2インスタンス)にないと、当然ながら起動しなくて、スタックの更新自体も先に進まなくなる(手で元のタスクを停止するとうまくいったりした気がする)。
• よくわからなくなったら、コンソールからスタックを削除して作り直すと、きれいにうまくいく場合がある。後から考えると、同じ論理ID(テンプレート中のリソース名)で後から矛盾する設定変更をしたせいだった気がする。スタックの削除は普通自動で進み放っておけば終わる(5～10分くらいだった。コンソール上で進捗を追える)のだけど、たまに削除が進まなくなることがあった。VPCが消えないことが多かった気がする。対象リソースをコンソールから手で削除すると、スタックの削除も無事に完了した。
• なお4番の、構築済みのClusterからCloudFormationのテンプレートを作ってくれるので、それで構築済みのものを見て参考にしようと思ったら、肝心なリソースがぜんぜん入ってなくてダメだった。リソースは手で選ぶので漏れたのかもしれないけど、再確認はしてないのでよくわからない。動いてるやつを元に作ったテンプレートを直すだけって、すごいいいアイデアだと思ったのになあ。

あとはまあ、テンプレートを更新して実際にCloudFormationで更新するのに、実行開始→作業中…→失敗！になるまでの時間が割とかかる(10分とか)のが、トライ＆エラーを繰り返すのに地味に厳しかった。また失敗したときの理由や状態を調べる方法が、なかなかつかめなかった。

• コンソール上でCloudFormationのスタックを指定してイベントを見る
• ネストしたテンプレートは別のスタックになっているので、そのイベントを見る。削除済みとかのものを見ると新しいことがわかるときもある。
• 作成したClusterをコンソールで開いて、Serviceを指定して、そこからイベントを見る
• 作成したClusterをコンソールで開いて、Taskを指定して、そこからLogsを見る。反映が遅いことがあるので、ページ下の方のコンテナから詳細を開いてCloudWatchのログを表示した方がいいかも(CloudWatchを設定している必要がある)。Stoppedのタスクを見ると新しいことがわかるときもある。
• EC2インスタンスにsshして調べる。インスタンス自体のログは/var/logに出ているし、docker execしてコンテナの中を見ることもできる

インスタンスやコンテナのことはあるていど探れたが、ネットワーク周りはどうやって調査したらいいのかまだよくわからない。また、ECSのタスクが起動しないで、必要な要件を満たすインスタンスがないよというメッセージを出すのがとても困った。いちおうここにガイドラインがあるけどあんまり役に立たない。

続く

これで環境はほぼ構築できたのだが、まだ動かない。クラスター内でアプリがMongoDBとRedisを見つけるところで、追加の作業(実装も含む)が必要になった。またMongoDBのデータがコンテナ内なので、なにかあったらデータが消えてしまう。その話はまた次回。

yattom.hatenablog.com

asobannのAWS ECSデプロイでやったことと引っかかったこと その1

asobannは現在herokuにデプロイしてMongoDBを使っているが、「herokuのMongoDBが11月で使えなくなるよー」という通知が来た。なるほど。また、サーバーをスケールするためにはFlask-SocketIOを複数プロセス起動してロードバランサを置かないといけないのだけど、herokuでそれを実現できない。あるいはすごいお金がかかる(herokuのガイド通りに1プロセス1Dynoにすると、ロードバランサ1つ＋メッセージキュー1つ＋アプリn個ぶんのDynoが必要になる。処理負荷はぜんぜん小さいのにもったいない)。

もともとパフォーマンス改善を考えていて、複数プロセス構成に載せ替えたかったので、これを機会に取り組んでみることにした。いちおう開発環境レベルでは動くようになったので、そこでやったことを主に自分のメモとして、もしかしたら誰かの参考になる情報として、書いておく。どれも、今さら？と思われそうな新しくない要素だが、初めての人はいつでもいるし(←自分)。ハマったところもたくさんあり、調査不足や勘違いが多いけれど、それも誰かの役に立つといいな。

初めてのDocker Composeで、nginxが使えないと知る

Flask-SocketIOを複数並列で動かすには、gunicornのworkerを増やすのでは対応できず、プロセス自体を増やさないとならない。プロセスを増やすということはリバースプロキシあるいはロードバランサが必要になる。またサーバー同士が調整するためのメッセージキューも必要(RedisやRabbitMQなど)。公式ではnginxの設定方法が書いてあるので、これに取り組むことにした。

AWSに上げる前に、まず手元でリバースプロキシ＋複数プロセスの構成を実験すべく、Docker Composeを使うことにした。docker-compose.ymlファイルを書くのは今回が初めて。このへんの成果は残っているが、結論としてはnginxをロードバランサにするとどうしても動かなかった。SocketIOがWebSocketに切り替えようとしても切り替わらず、結果としてまったく通信ができない。eventletをgeventに変えたり、gevent-websocketを入れたり、nginx.confの書き方をあちこち調べたりしたけどわからない。ごくシンプルなサンプルを書いて試したけど同じ現象が再現するので、諦めることに。AWS ALB (Application Load Balancer)を使えばなにもせずそのまま動いたので、結果的にはそれで問題なかった。

こんにちはAWS ECS、お前はいつもそうだなSecurity Group

前段の実験でDockerコンテナで動くようにしてあるので、AWS ECS (Elastic Container Service)を使うことにした。ECSはパフォーマンステストを作ったときにも使っているので、初めてではない。Docker Composeで一発デプロイができたら嬉しい気もしたけれど、まだそこまでECSの気持ちがわからないので、まずはWebコンソールからひとつずつ手作りすることにした。Cluster、VPC、Task Definition、Service、Load Balancerと作っていく。

起動タイプはEC2に。Fargateではネットワークが awsvpcになってネットワークの設定がシンプルになるが、軽いタスクをたくさん上げるとherokuのDyno数と同じ問題でお金がかかる。EC2 Launch Typeで1インスタンスに軽いタスクを複数入れて安上がりにしたい。最終的にはEC2のt3.smallインスタンス1個にMongoDB＋Redis＋アプリ3つが収まって、月15USDくらい(us-east-1リージョン)。

ところがEC2でawsvpcに設定すると、EC2インスタンスのタイプによって持てるネットワークインターフェース(ENI)の数に制限があって、たくさん実行できないと制限があり、今回はここに引っかかった。いくら待ってもTaskが起動せず、コンソール上でServiceのイベントを見ると、条件の合うインスタンスがないからタスクを起動しないよというエラーになっている。調べていたら、ENIの数に制限があるというドキュメントにたどり着いて原因がわかった。いったんawsvpcで作ってしまったので、いまは練習として放置し、EC2インスタンスを2つにしてしのごう。なおいま調べたら2019年にENI制限が緩和されたらしいけれど、NITRO以降のタイプのみだったので関係ない。

今回は練習としてawsvpcのままだが、本番のときはネットワークをbridgeに設定する。こうするとENI数の制約はなくなる。同じIPに複数のTaskが存在して、ポート番号で呼び分けることになる。Service Discoveryを使うとき、AレコードではなくSRVレコードを使う必要が出てくるのだが、これがあとで一手間増える原因となった。

ALB (Application Load Balancer)もServiceを作るときに設定する。ALBはそのままでWebSocketに対応していて追加設定不要だが、SocketIOにはスティッキーセッションが必要なのでそこだけ設定をONにする。設定はしたのだけど、ALBのURLをアクセスしても503になってアプリに到達できない。これはSecurity Groupの設定が悪くて、ALB自体にもSecurity Groupが働くので、ポート80番を開けておかないといけない。Security Groupはいろんなところに影響するのに、設定が悪いと気づける方法がなくて、いつもハメられている気がする。キミの気持ちがわからないよ。

続く

これでいったんAWS ECS上でasobannが動くようになった。固定URLがないし、MongoDBがコンテナで動いているので何かあるとデータが消えてしまうが、開発環境という位置づけならとりあえず大丈夫だ。httpsがないのはちょっとダメかも。

今度は今回手作りしたものを参考に、CloudFormationで自動構築できるようにするのだが……次回に続く。

yattom.hatenablog.com

yattom.hatenablog.com

受入条件はプロダクトオーナーのもの、完成の定義は開発チームのもの

プロダクトバックログアイテム(PBI)が完成したか、リリース可能と言えるかどうかは、開発チームとプロダクトオーナが判断する。判断基準は様々で、ちゃんと動くか、使いやすいか、重かったりしないか、デザインが整っているか、脆弱性が存在しないか、SLAを満たすか、十分テストしてあるか、アーキテクチャの一貫性を壊していないか、ドキュメントは書いてあるか…… どういう基準が必要か、基準をどのくらい緩く、厳しくするかは、プロダクトとチームによって千差万別になる。

受入条件は判定基準として、個々のプロダクトバックログアイテム固有になる。このように機能すること、動作がこうであること、前提がこうなら結果がこうなる、などのPBI個別で定める内容になる。言い換えると、受入条件はPBIの内容の一部、PBIがどんなものか説明する一部だ。PBIをユーザーストーリーで書いていれば、ユーザーストーリーは「プロダクトオーナーと開発チームが会話する約束」なので、会話の中に受入条件が登場し、相互に理解して、スプリント終了までに判定すると約束する。

完成の定義(Definition of Done)は、すべてのプロダクトバックログアイテム共通となる判定基準だ。 プロダクト全体で守るべき非機能要求や、組織・開発・運用などの観点から制約される、あるいは達成したいラインによって構成される。完成の定義は開発チームとプロダクトオーナーが相談して定める。

受入条件も完成の定義も、誰かが判定しなくてはならない。開発チームとプロダクトオーナーが議論したり伝達したりするものだが、最終的に判定する責任は誰にあるのか。受入条件はPBIの内容の一部であり、従ってプロダクトオーナーが責任を持つものだ。そのため判定するのはプロダクトオーナーである。プロダクトオーナーが受入条件を元に自分で受け入れテストを作り、自分でテストするというのが純粋な形となる。この部分だけ取り出すと、請負契約の納品物を発注者の責任で検収するのと同じ構図になる。

完成の定義は開発チームが判定するものである。PBIが完成したと言えるかの条件であり、すなわちリリース可能であるか、スプリントレビューの対象とできるか、受け入れ判定をしてよいかの条件である。受け入れ判定をする前に完成の定義の判定をクリアしないとならない。いっぽう、完成の定義は、PBIが完成してるのかどうか、透明性を高めるための道具立てでもある。そう考えると完成の定義は、判定のための仕事をしなくても判定できるような、見える化や自動化を進めるべき領域でもある。

リモートモブプロ勉強会をrepl.it＋Zoomでやれそう

モブプロ勉強会のリモート開催の可能性を考えて、簡単な素振りをしてみました。

• repl.it(オンラインIDE)は言語やフレームワークの幅が広く、使える
• replt.itのMultiplayer機能で、ブラウザ上で複数人(無料では4人まで)で共有できる。VSCode LiveShareとほぼ同じ感覚。参加者もアカウントが必要 https://repl.it/site/blog/multi
• ファイル追加したときに同期されないことがあった(リロードしたら見えるようになった)
• 誰がどのファイルを開いているかわからないので、ぼんやり見てると見失う可能性がある。ドライバーは編集箇所を頻繁に口に出すとか、ドライバーの画面を共有するといいかも。(なお、ファイル内では誰がどこにカーソル置いてるかはわかる)
• テスト駆動開発や自動テスト実行は、repl.itの機能としてはないけど、実現可能(テストケース実行を外部コマンド叩くとか、言語内から呼び出すとか。言語にもよる。今回はruby+rspecで、main.rbからexecでコマンドを実行した)
• コミュニケーションはZoom
• Zoomの文字チャットを使うのが一番ハードル低い(replt.itのチャット機能は貧弱なので厳しい。Slack使えるといいけれど、そのためだけにワークスペース追加してもらうのはちょっと心理的ハードルが高い)
• タイマーは、誰かが手元で動かしておく
• ドライバーは参加順などで強制的にまわすのがよさそう(リモートで空気読んで手を挙げるのは難しい

なお来週のテスト駆動飲み会自体は、予定変更せず普通のモブでやる方向で考えています。その後、リモート開催に切り替えることになりました

自分がどんなふうにインセプションデッキ作りをファシリテートしているか

インセプションデッキ Advent Calendar 2019 - Adventarの参加エントリです。

アジャイルコーチとして活動する中で、インセプションデッキ作りを手伝うことがよくあります。私がファシリテートする場で、どんなことを考え、どんなことをしているのか、思いついたところを書き出してみました。一例として参考になる部分があればいいなと思っています。書き出してみると、我ながらちゃんと考えられていないところがあるなあと気づいたりしますね。

目次

インセプションデッキ作りが重要だ、作ったインセプションデッキはどうでもいい (いくないけどそれほどでもない)

私がインセプションデッキを作るねらいは、参加者がプロジェクトの背景や目的、ねらいとこれからの進め方について議論し、理解し、合意する活動そのものです。その意味で、デッキ作りの成果は、参加者の中にある認識であったり、作ったデッキに対して合意したという仲間意識であったり、これから一緒にやっていこうという意気込みであったりします。

デッキの完成は、そうした成果に比べると優先順位は下がります。個々のスライドの完成度はあまりこだわりませんし、すべて完成しようともしません。組織、プロジェクト、参加者によって重要な要素は毎回異なるので、時間をかけたいスライドも変わってきます。

もちろん完成に意味がないというわけではありません。完成したデッキは有用で、目に付くところに貼っておいたり、将来のタイミングで見直したり手直しをしたりできます。ですが、完成のためにやっているわけではないのだと認識しておくほうが健全です。またデッキの完成を目標にしてしまうと、議論が足らなくなったり、空気を読んで“合意”してしまったり、しやすいようです。

タフクエスチョンカードを手作りする

タフクエスチョンカードを、最初に作ります。これは物理的な紙のカードで、「(タフクエスチョンするぞ…！)」という気持ちを表明するのに使います。質問、ツッコミ、反論をするときにこのカードを出してから言うという使い方をします。説明としてはそういうふうに言いますが、実態としては質問することを忘れないための手元のトークンになるものです。

インデックスカードを1人1枚配り、各自カードを作ってもらいます。デザインは人それぞれで、びっくりマークやクエスチョンマークを描く人や、人間の顔を描く人、爆発やツッコミのイラストなどもあります。インパクトあるデザインでもいいし、逆に雰囲気を和らげるように描くのもよいでしょう。

タフクエスチョンカードを手元に置いておくと、質問から議論が起こりやすくなります。話を聞いたときそのまま納得するのではなく、なにかツッコミを入れるように意識が向きやすくなるのではないかと考えています。

全体の進め方も合意で決める

インセプションデッキ作りの進め方そのものも、議論と合意で決めていきます。最初に導入として、インセプションデッキの全体像や個々のスライドの内容を簡単に紹介し、スライドのタイトルを付箋に書いて並べます。ここからは、参加者全員でのプロセスになります。どのスライドを選ぶか、どの順番で作るか、どのくらい時間をかけたいか、その場で検討しながら決めていきます。結果として作るスライドを順番に並べたものができます。これはスクラムのプロダクトバックログと同じで、進みながら見直し、随時変更、入れ替えていきます。

スライドを自由に選ぶ流れではありますが、実際には「なぜここ」が外れることはありません。他にも「エレベーターピッチ」「ご近所さん」「夜も眠れないこと」「トレードオフスライダー」あたりは採用されることが多かったです(私がファシリテーターをやるときの話なので、私自身のバイアスが影響してそうな気もします)。順序は「なぜここ」が最初、あとは気になっている箇所を優先していくと、けっこうバラバラになります。Why→Howの順序が崩れることもあります。

少なくとも最初の数枚を決めてから、スライド作りに入ります。1枚終わったら、本当に完成にしていいかを確認したうえで、付箋に大きなチェックマークを付けていきます(確認にはサムズアップ・ダウンを使います)。また、そこで残り時間を確認し、次以降のスライドを見直します。予定時間を調整したり、順序を入れ替えたり、ときには準備が不足だと気づいてスケジュールを立て直すこともあります。

オーナーは目的意識を持って事前準備する

インセプションデッキ作りには、通常オーナーがいます。すでにバスに乗っていて、今回の参加者もバスに乗せたいという意図をもった人々です。この人たちには、作りたいスライドを事前に考えておいてもらい、いくつかは叩き台を準備してもらうこともあります。しかし当日、スライドを決めるに当たっては、そうした意見もあくまでいち参加者の意見として発言し、そうしたい理由を説明してもらい、全員の合意で決めるようにしています。

オーナーは場合によっては、事前に他の参加者に状況説明や参加してほしい理由などを説明していることもあります。インセプションデッキ作りは合意を一とする場で、アイデア出しや各論の検討、議論をするには時間が足りないようです。

(こう書いてみると、まるで根回ししまくりの、当日は意見もアイデアも出ない静寂とした、オーナーの都合に合わせた予定調和の、粛々と進行してシャンシャンとまとまる、つまらない会議みたいに聞こえますね。実際はそんなことなく、それぞれの人がそれぞれの立場から色々な案や反論や感想が出てきますし、はじめに思っていたのとは違う合意があらわれることも多いです。上に書いたような気を使うのは、参加者の数が多く多様で、仕事上の立場もミッションも違い、利害対立する可能性があるような場合で、オーナーの判断によります。一例として、いわゆる顧客や発注側の内部で合意を作りたいときです。)

タイムボックスはあんまり使わない

完成を意識しすぎないよう、インセプションデッキではタイムボックスをあまり設けないようにしています。「なぜここ」を話し始めて、そのまま丸1日まとまりきらないこともありました。

議論をファシリテートするうえでのテクニックとして、時間を意識してもらうことはありますし、割と大事にしてもいます。ですが「このスライドはあと30分で打ち切りましょう」というような進め方は避けています。参加者が話し尽くしたと感じられる、挙げられた論点がひととおりカバーされている、熱意を持って「これでいこう！」という雰囲気ができているかで、終了にしてよさそうか判断します。ファシリテーターや、参加者から「これで完成にしましょう」のような意見が出て、みんなが喜んで合意すれば、完成です。合意できないときや、不承不承な感じがする、疲れてきてどうでもよくなっているようなときは、長めの休憩(15分～30分)をとってから再確認します。

スライドにより、時間あたりの収穫が急に下がるものや、時間で切らないと終わりにしにくいものもあります。最初にタイムボックスを決めることが多いのは「パッケージ」や「夜も眠れないこと」などです。
もっとも参加者が全員集まれる時間は限られているので、いくらでも時間をかけていいというわけにはいきません。時間がかかりそうな部分は、事前に叩き台を準備してもらったり、一部の関係者で議論を進めておいてもらったりするようアドバイスしています。

休憩は戦略的に

休憩は重要です。4時間、あるいは丸1日かけてインセプションデッキ作りをするのであれば、休憩もしっかり確保します。休憩には戦略性があって、お手洗いに行くていどの5～10分くらいの休憩は前の議論を続けやすくなります。議論が詰まったような場面では、15分～30分くらいの長めの休憩を取って、頭を切り替えます。場のあったまり方にもよりますが、休憩時間にリラックスしてコーヒーやお菓子をとりながら話しているときが、実は突っ込んだ話ができていたりもします。当然、ちゃんと休むのも大事なので、話が続いているのを遮ってしまうこともあります。

休憩を取るタイミングも工夫ができます。話が盛り上がったとき、特にテンションや感情が高まったときは、すこし落ち着くために休憩を挟むのも有効です。結論や合意になんとなく不満がありそうなときも、いちど休憩を入れて個別に話すタイミングを取るとよいです。デッキ完成など区切りがついたときに取るのもよいのですが、完成したときはテンションが上がっていて、そのまま休まず次に進んだ方がスムーズに移行できるようなときもあります。

それぞれのスライドについて個人的なメモ

なぜここでは、以下のような質問を使って、状況を深掘りすることが多いです。

• なぜ今、このタイミングなのか？
• なぜこのメンバーなのか？
• 他のことではなくこのプロジェクトをやる理由は？
• うまくいったとき、本当に喜ぶのは誰か？

会社組織の中で立ち上がるプロジェクトでは、プロダクトとして実現したい目標だけではなく、組織の事情、人の都合、予算や年度区切りなど、本質っぽくないドロドロしがちだけど必要な話というのがよくあります(面倒くさい……)。きれいごとだけではない背景まで明るみに出して、コアメンバーで共有するようにします。こうした話はデッキには書き残せないこともありました。

エレベーターピッチには苦手意識を感じています。おそらく、企業の社内システムに関わる仕事が多いためもあって、エレベーターピッチ作りで紛糾したり、議論がダレる場面を多く見ます。エンドユーザーにはっきりしたペインがない、他の選択肢がなく優位性を考えられない、上からやれと言われてやっている感がにじみ出てしまう、などです(そうした認識が表面化するのは、それ自体は有益だと思います)。ステークホルダーが顔の見える特定の個人で、その人を説得する言葉が政治じみていて、プロダクトからフォーカスが外れてしまう場合もあります。

パッケージデザインは、私は心の中で「プロダクトビジュアル」と呼んでいます。プロダクトのポスターを描く形式にすることが多いです。プロダクト名や特徴などの文字も使いますが、なにかしらの絵、イラスト、アイコン、ロゴを入れてもらいます。アイデアを出しながら、全員がペンを握って描くように、絵が上手い人に押しつけるようなことがないようにガイドします。上手だったり綺麗だったりするよりも、参加者全員が「自分が描いた」と感じられる方が大事です。できたポスターはそのまま、チームの仕事場に貼り出しておきます。

ご近所さんでは、顔が見える(個人名が分かる)ようにしています。部署だったり会社だったりではなく、その中の誰が担当なのか、内部にはどんな人がいるのか、何かあったときに誰に連絡することになるのか、わかる範囲で出してもらいます。

トレードオフスライダーの基本4項目(スコープ、予算、時間、品質)だけ議論するときは、必要ではあるもののあまり面白い話にならないことが多いようです。面白いかどうかは、大いに主観ですけれど。それ以外の項目の話が出てくると、このプロジェクトならではの話に発展します。

以上です。アドベントカレンダー次回は、12/21稲野さんの予定です。

スクラムで問題(バグ)対応するときのアプローチ

先日、現場の人から質問を受けました。

「スクラムで進めているプロダクトに、大きめの問題(バグっぽい挙動)が見つかった。POは最優先で対応したいと思っているが、まず状況把握や原因調査だけでも時間がかかりそうで、ましてや対応までどのくらいかかるかわからず、1スプリントに収まる気がしない。どう対応していくのがいいか」

バグ対応とスプリントについては、いろいろな人が言っています。自分の中ではそういう話と自分の経験がまぜこぜになってしまっていますが、それを思いつくままに書き出して回答を送りました。なんとなく、自分にとっても整理された感があったので、こちらにも置いておきます。

• 問題を特別扱いしない。問題も、機能追加も、どちらも「理想と現実のギャップ」であり別々に扱う必要はない。どちらも同じように、調査や準備をし、見積もり、プロダクトバックログに入れ、優先順位を検討し、スプリントで開発する。
• POが優先順位が1番だと判断したからといって、READYであるとは限らない。スプリントに入れて開発チームで取り組む準備ができていなかったら、スプリントに入れられない。
• 問題が大きそうで、プロダクトやプロジェクト(リリース)へのインパクトも大きいのであれば、スプリントに入れるのとは別の理由で、できるだけ早く見積もりができるほうがよいはず。リリース日の変更や、リリースに含める機能の大幅な変更、関係者への連絡や調整などのためにも、できるだけ早く見積もりがほしい。
• 粗く当たりをつけた当初の見積もりは、関係者に早く伝えるのが重要かつ、状況が変わったら随時伝え続ける、現状を更新し続けるのも重要。問題はとりわけ、どんどん対応工数がふくらみやすいので、最新の現状を共有しないといけない。相手にもよるが、あまり楽観的に伝えない方が先々お互いに安心。
• 問題の調査を開発チームがする必要があるのであれば、その作業を解釈としてはリファインメントの時間と考えることもできる。ガイドではリファインメントはスプリントの10%までだが、一時的に越えるのは大きな影響はないと思う。
• 問題の調査、切り分けはスプリント期間中、一定の時間枠(タイムボックス)を取って進める。逆に言うと、スプリントの他の開発も並行して進める(「4.1.20 常に誰かが進捗させる」組織パターン)。すべてが止まってしまうと後から立て直すのがしんどい。調査に12時間使う、1ペアはずっと問題調査に充てる、あるいは3～4人はモブでずっと問題調査をするなどということにして、残りの人数は他のPBIを進められる。12時間ならベロシティは通常の28/40になる。5人チームで1ペアが問題調査をするなら、ベロシティは通常の3/5になる。
• ペアプロやモブプロのスタイルで調査をする。問題調査は心が折れやすい仕事で、ペアやモブだと心が折れにくい。どこにあるかわからない、なにかもわからないものを探すのには、目玉と脳味噌が多いほうが良い。スタイルはゆるくてよく、自分のPCでちょっと確認するとか、相談した上で手分けをするタイミングが、あったりしてもよい。またペアやモブのメンバーもゆるく、時々入れ替わったり、誰かを呼んで教えてもらったり手伝ったりしてもらう。
• 問題調査もできるだけブレークダウンして、個別のタスクに切り出す。思いついたところから手当たり次第に進めたり、各自が勝手に調べたり、あるいは誰かが脳内で整理しつつ指示をするようなやり方は、効率が悪い。おそらくスプリント単位(1週間)でタスクを切り出すのは困難なので、タスク出しは随時おこなわれることになる。(Mikado Methodも便利。テストとリファクタリングに関する深い方法論 #wewlc_jp の36枚目など)
• 調査の状況や進捗は、できるだけ記録に残す。ラフで良く、またアナログ、できれば目の前のホワイトボードを占有するようなやり方がよい。作戦司令室とか、あるいは捜査本部みたいな感じで、その場に来れば状況が分かる、いま何を調べていて、どこまで進んでいて、次に何をすべきか全員がつかめるようにする。問題調査はカオスになりがちなので、そのカオスをそのまま表現する。
• 調べた結果は、できるだけ自動テストや自動化スクリプトなどで残す。調査自体も自動化しながら進める。勘違いや見落としを後から確認できるし、パターンを追加するのも容易。他の人が確認した内容を正確に共有できる。問題を特定したら、その問題を再現するテストを自動化しておく。
• 問題調査にキリがついて、対応方針が確定して、あとは直すだけというところまできたら、直すという作業をPBI(ストーリー)にする。あとは他のPBIと変わらない(見積もりをして、大きければ分割し、受入条件を作り、プロダクトバックログに並べる)。
• そもそも問題に緊急性が高く、スプリントで扱いきれないようであれば、スプリント緊急中止を検討する。本来のスプリント中止では、そこから新しいスプリントを計画する。また別の案として、スクラムそのものを停止して、全員で問題の調査や対応に全力で対応する。どうしても必要なときに検討すべき手段だが、あとでスクラムを再始動するのにかなりエネルギーがいることを覚悟する。
• そもそも問題調査を開発チームでやるのがいいかはわからず、外部の人に頼む、別にチームを作るなどのアプローチもできるはず。

RSGT2020勝手にプロポーザル紹介（2日目）

Regional Scrum Gathering Tokyo 2020 (2020年1月予定)のセッション公募が始まっています。プロポーザルがどれも面白そうだけどたくさんあるので、気になったものを紹介してみたいと思います。経緯はRSGT2020勝手にプロポーザル紹介（1日目） - The HIRO Saysも参照してください。

わたし自身はこちらを応募しています。興味あれば投票お願いします。

confengine.com紹介する方向性としては、入門や事例よりは新たな理論や突っ込んだ分析、あとは生の現場の様子なんかに興味があって、RSGTはけっこう参加してるぜ(だけど実はセッションはあんま真面目に聞いてないな)という立場です。

というわけでひとつめ。

confengine.com
野中郁次郎が『知的機動力の本質』で米国海兵隊を研究しているように、軍事組織から学べることってたくさんあると思います。良い点も、悪い点も含めて(悪い点は『失敗の本質』が有名ですね)。米陸軍のAARなんかも学ぶところがあります。

このセッションの内容については知らないのですが、そんなわけで新たな学びに期待しています。

 次は、いきなり前言ひるがえして入門的なやつ。

confengine.comJeff Sutherland, James Coplienらがスクラムというフレームワークをパターン言語としてまとめなおしたという、壮絶な手間暇がかかっている知の結晶がやっと書籍として出版されます(2019年秋。電子版はすでに入手可)。パターングループにも所属していてパターンライティングに参加している原田騎郎さんが紹介してくれると思います。

これは自分が興味があるというよりは、ぜひ採用されて多くの人に参加してほしいというプッシュの意味で紹介しました。

それから、理論を謳っているもの。

インテグラル理論を用いた、今までにない文化に根ざしたやり方を導入するためのトップダウン・アプローチ

confengine.comいまさらながらケン・ウィルバー読んでいるので、気になっています。林栄一さん、最近お忙しかったみたいであまり表に出てこられない印象だったんですが、久々の登場なのでお話を聞きたいなとも思っています。

最後に、ガチな内容が期待大なトークセッション。

confengine.comホロラボの中村薫さんのセッション。広い意味でのバーチャルリアリティを以前から研究されていて、いまは最先端で活躍されています。中村さん、以前アジャイルコミュニティやイベントでお見かけしてたんですが、それが本業でやっとわかってきた、というお話のようです。どんなことがわかったのか、すごく気になります。

というところで。次回はこちら、書かれたのは森一樹さんです！

qiita.com