海と山が好き

海と山が好きだけど埼玉に住むおっさんが遭遇したアジャイルとかのはなし

俺のアジャイルマニフェスト

アジャイル スクラム

アジャイルマニフェストを鵜呑みにしていいのか

って話でして。

中身の理解をしないで腹落ちもしないまま人に勧めるような場面を見かける。

中身をわかってて勧めてるのとわからないまま勧めてるのでは天と地の違いがある。

（主にそいつが信用できるか、と言う点で）

ってわけで、アジャイルマニフェストをどう理解しているか？を見直そうと思った。

マニフェストはわかるし、価値と原則もわかる。

が、いざ正確な言葉で表現するとなかなか難しいかもしれない。

自分の理解を見直すいい機会になりました。

Manifest

Item Because hoge
プロセスやツールよりも個人と対話を、価値とする なぜならば
包括的なドキュメントよりも動くソフトウェアを、価値とする なぜならば
契約交渉よりも顧客との協調を、価値とする なぜならば
計画に従うことよりも変化への対応を、価値とする なぜならば

Principal

Item Because hoge
顧客満足を最優先し、価値のある
ソフトウェアを早く継続的に提供します。		 なぜならば
要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。		 なぜならば
動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。		 なぜならば
ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。		 なぜならば
意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。		 なぜならば
情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。		 なぜならば
動くソフトウェアこそが進捗の最も重要な尺度です。 なぜならば
アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。		 なぜならば
技術的卓越性と優れた設計に対する
不断の注意が機敏さを高めます。		 なぜならば
シンプルさ（ムダなく作れる量を最大限にすること）が本質です。 なぜならば
最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。		 なぜならば
チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。		 なぜならば

これの、‘なぜならば‘ に続く理由が言えるか、腹落ちしているか、は、スクラムマスターやアジャイルコーチをやる上で大事だな、って気がしました。

エンプラアジャイル勉強会（20190212）に参加してきた。

アジャイル スクラム

２月のエンタープライズアジャイル勉強会に参加してきた話

オージス総研さん主催のエンタープライズアジャイル勉強会に参加してきました。

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

たまによく行く(謎)のですが、レポッす。

品川インターシティ開催だったのが、大崎開催となり、職場から近くなったのでちょっとラッキー。

仕事の都合で少し遅れて参加しました。

セッション ① スクラムマスターの目で見たサイボウズの変化 -アジャイルの先にあるもの-

講師は天野祐介 ( ama-ch (@ama_ch) | Twitter ) さん。

speakerdeck.com

サイボウズでアジャイルコーチをやられているとのこと。

(アジャイルコーチっていう職種が認められている会社って時点で若干羨ましい。)

アジャイルコーチチームは３名いるとのこと。

そのうちの一人は永田敦さんで、以前会社でアジャイル先駆者として活躍されていた方だったのでビックリ。

別の会社に行ったとは聞いていたけどいつの間にサイボウズに。

契約形態で優秀な人間を逃すな

興味深かったこととして、アジャイルコーチを採用する上で、副業上等な柔軟な契約形態が取れたことが理由の一つ、という話。

確かに、裏を返せば、契約形態を固定したいがために優秀な人を逃していいのか？という問題にぶち当たる。

そうまでして押し通したい契約形態ってなんだろう？

（往往にして管理する側がめんどいだけだと思うけど。）

マネージャが消えた話（誇張表現）

もう一つ面白かったのは、プロダクトに合わせてフラットな組織にしたら、部長の役割がなくなってしまったという話。

「組織運営チーム」のメンバーとしてマネジメントをしているらしい。

役割が給料に直結してしまい、下げられないような大きい会社とはフットワークが違うなと感じた。

古い大きい会社でそんなんやったらゼッタイ偉い人反対するでしょそんなん。

放浪するアジャイルコーチ

チームが育って空調調整おじさんと化した(理想だ)ある日、暑くも寒くもないと言われついにチームでやることがなくなってしまい、他のチームを見に行ったりしていたが、特に上司からは怒られなかったという話が面白かった。

権限が移譲されている（管理を不要としている）素敵な状態だ。

権限委譲ってどうやるんだろ

マネージャーからの権限の委譲って、そう簡単な話ではない。

大抵の場合、マネージャが結果責任を負う一方で、過程に介入できないというのはかなりリスクだ。

ってなると、「何やってるか逐次報告しろ！何をやるか俺の指示通りに動け！」ってなる。

権限委譲しようと思うと、マネージャーから見て、チームが向かっている方向性が適正で、働き方が適正で、正しい方向に是正する力学が働いている、というのが把握できていないと心配でしょうがない。

個人的な経験で言うと、マネージャのクソ度胸というか、器の大きさにも依存する気はする。

セッション ② あなたの会社にアジャイルを見つけよう

講師は LINE の横道 ( Minoru Yokomichi (@ykmc09) | Twitter ) さん

omoiyari.fm の Podcast をやってる人だ！

lean-agile.fm

資料は ↓

speakerdeck.com

LINE の社風と、アジャイルが合っているので、アジャイルが進む、と言う話をされていた。

自分たちの中で何がアジャイルで、何がアジャイルじゃないか？を見つけることから始めようと言う話だった。

アジャイルじゃないものを変えるための第一歩は何か？を見つけて、自分の手の甲に書くこと！というワークショップをやった。２日経ってもまだ消えねえよサインペン。

そしてワークショップをやると行っていないのにどこからか湧き出てくるポストイット。さすが。

何がアジャイルって考える基準か？

ちょうど自分の仕事でも、「アジャイルってなんだろう？」を考える会があった。みんな認識バラバラだし。

端的に言えば、アジャイルマニフェストで書かれている価値と原則だし、本質としては変化に対応して勝つための姿勢だと思っている。

アジャイルソフトウェア開発宣言

今回の LT でも、アジャイルマニフェストをベースに、会社のミッションに沿っている（＝取り入れていくべき）価値観があるよね、と言う話だった。

個人的には、自社のアジャイルなところ/アジャイルじゃないところを考えた時に、真っ先に浮かんだのが、「非アジャイルマニフェスト」だった。

kawaguti.hateblo.jp

涙無しで読めるようになりたいぞ。

そのほか学んだこと

突如湧いて出たポストイット、川口さん (Yasunobu Kawaguchi (@kawaguti) | Twitter )の私物(?) だったわけだが、その時に面白かったのが、

ポストイットケース！

今までもポストイットとサインペンを持ち歩いてたが、書類ケース内でポストイットが散乱して鬱陶しかったので、困っていた。

どうやら１００均の折り紙ケースが使えるらしい。まじか。

で、今日３件くらい回って程よいサイズのケース（ハガキケース）をゲット。

これでかさばらなくて済む！

モノがキッチキチに詰まってるのがなんか好き。どうでもいいけど。

ウッキウキで帰りにピープルウェアを買って今に至る。

ピープルウエア 第3版

ピープルウエア 第3版

スプリントで終わらなかったストーリーのポイントはベロシティに入れるべきか？

スクラム

ユーザーストーリーを活用しているチームは多い。

ユーザーストーリーの形式はシンプルに「背景」と「実現したい状態」を表現していて非常に認識齟齬を減らしてくれる良いツールです。

逆に、「やる事」だけが書かれているようなユーザーストーリーは注意が必要です。

（往々にして何故やるのかわからないからやった内容に後からイチャモンが付く。）

で、ユーザーストーリーに対して見積もりとしてストーリーポイントを付与するチームも多い。

相対見積もりによって効率よくプロダクトバックログ全体のボリュームを見通すのにちょうどいい。

また、バックログを消化するスピード（ベロシティ）にもちょうど良い指標にされている。

ところで、「スプリントで終わらなかったストーリーは、終わった分だけ割合でベロシティに計上していいですか？」って聞かれることがよくある。かなりある。

結論から言うと、計上しなくていい。ということを勧めている。

① 理由として、計上すると、終わらなかったことに対する責任をチームが持てなくなる。

終わらなかったけどベロシティとしてチームの成果に見えてるぞ、と。

となると計画に積んだのに終わらなかったことを振り返る気にもならない。

結果、ふりかえりで改善のフォーカスが当たらず、チームのパフォーマンスは上がらない。

② さらに、積まなくてもどうせベロシティ計算するときに薄まるから気にしなくていい、ということもつたえる。

3スプリントでベロシティ見積もるとして、それぞれ未完了があったとしたら、次のスプリントで完了したときに、次スプリントで計上されるから。

もちろん次スプリントでも（考えたくないが）未完了は発生するが、3スプリント間で相殺するので、影響は 1/3 になる。

そこまでいったら経験上ベロシティとしては誤差だから気にしなくていい。

③ いちいち気にするだけ時間の無駄だ。

ってあたりをチームに話してみて、計上したい？って聞くといい。

仕事をしたのにベロシティという目に見える形に影響出来ないのは辛いが、ベロシティは成果を評価するためのツールではないので気にしない方がいい。

チームには、終わらなかったことから何を学んだか？んじゃ次はどうしたいか？を考える方に情熱を使ってもらおう。

ちなみに、仕掛かりのままの仕事が多いと、とても生産性が落ちる。

たくさんの仕事をスプリントに積んで食い散らかすより、食べ残しが無いようにしてみると、意外とベロシティは上がる。

（色々着手しないことでサイクルタイムを減らす圧力がかけやすいから当たり前だけど）

始めることをやめて、終わらせることを始める

っていうカンバンの原則を活用すると良いかも。

カンバン仕事術

カンバン仕事術

ふりかえりはチームのためのもの

アジャイル スクラム

職業柄色々なプロダクトのスクラムチームを見ることがある。

で、いくつかのチームで共通する、形骸化したふりかえりのあるあるパターンの１つ。

個人のふりかえり → 個人の反省 → 個人の改善になってるパターン。

「風邪を引いて作業が進まなかった」→「体調管理に気をつける」

みたいなやつ。

作業が進まなかったのは チームの問題 なので個人の問題のままに改善しようとしているならスクラムマスターを何とかした方がいい。

第一、個人のふりかえりと改善なんてスプリント終わりまで待たずに毎日やってくれていい。

スクラムガイドを見ると、

https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf

スプリントレトロスペクティブは、スクラムチームの検査と次のスプリントの改善計画を作成する機会である。

(中略)

スプリントレトロスペクティブには、以下の目的がある。

• 人・関係・プロセス・ツールの観点から今回のスプリントを検査する。

• うまくいった項目や今後の改善が必要な項目を特定・整理する。

• スクラムチームの作業の改善実施計画を作成する。

スクラムマスターは、次のスプリントが効果的で楽しいものになるように、開発チームにスクラムプロセスフレームワークの範囲内で開発プロセスやプラクティスを改善してもらう。

チームのやり方を見直して、改善するのがレトロスペクティブの目的。

これを忘れるといつまでもチームとしての能力は大して上がらない。多分絶対に。

こうなるチームの特徴の１つが、ストーリーを人にアサインするアンチパターンがある。

Ryuzee さんのブログに詳しいので詳細はそちらを。

www.ryuzee.com

このスタイルで作業を進めると、「レビュー待ちです」「あとはマージだけです」みたいな会話をレビューでよく聞く。いや終わってないからそれ。

そもそも スクラム なんて読んで字のごとくラグビーの話じゃないですか。

どこの世界に各自1個ずつボール持ってヨーイドンするラグビーがあるんです？

というわけでスクラムのレトロスペクティブにおいて、個人のふりかえりにはあまり興味はない。敬意はある。くらい言わないと伝わらない気がしている。

うまくいったやり方をチームでどうすると継続できるか？をシェアして考えて掘り下げて身にしていくサイクルにしないとだ。

なお、やると決めたら、チケット切って次のスプリントの一番上に置くことをお勧めします。

そうすれば改善が進まないんですなんてこともないですし。欲張らずに１つでもいいです。やらないよりは。

計画ってなんだろう

アジャイル

計画ってなんだ？

仕事だけでなくスポーツでも教育でも必ず耳にする 「計画」 という言葉

アジャイルと計画って言葉は密接に関係していると思う。

密接ではあるが表裏では無いのがミソ。

とりあえずググると、、

計画（けいかく、英語: plan）とは、何らかのものごとを行うために、方法や手順を考え、企てること。また、そうして考え企てた内容のこと。

計画とは、何かのものごとを行うために、あらかじめ、その方法、手順などを考えること（この場合「計画する」などと述語、動詞的に用いる）、およびそうして考えた方法や手順のことである。

ブリタニカ国際百科事典によると、計画とは、将来 実現しようとする目標（目的）と、この目標（目的）に到達するための主要な手段や段階とを組み合わせたもの、とのことである。

だそうだ。

要は 「目標」 と 「実現方法」で構成されている。

大抵の場合、実現方法（実行計画）を無視して突撃すると上手くいかないか、多大なコストを支払う羽目になる。

ちょっとずつやってるから大丈夫！と思っても夏休みの宿題が終わるかは分からないからだ。

だからママは聞く。 「夏休みの宿題終わるの？」と。

「算数の15ページ目だよ！」と言われるとツライ。

ママにとって気になるのは終わるかどうかであって何をやってるかどうかでは無いのだ。

って話は進捗管理の話なので今回は置いといて…

「計画」 が立てにくい状況にはアジャイルが効くと言われている。

１つは、「目標」が不確実・不安定な場合があるから。

  • 後になったらもう要らない、というもの

  • とりあえず言ってみたけどそんなに重要じゃないこと

  • その時は必要だと思っていなかったけど、後になって必要になったもの

とか。

そういう状況では「目標」に向けて計画を立てたとしても、目標そのものが目指すべきものでないので、悲惨な結果になる。

だから、間違いなく必要、というところは達成したいので、精緻に計画を立てる。

逆に、多分必要かも〜レベルの内容であれば、そのうち目標として明確になったらやる、と言った程度で、粗く見積もる程度にしておく。有名なのがストーリーポイントとか、T シャツのサイズとか。

やるかどうかもわからんものに計画を立てるのはただの無駄だ。

どうせ作っている間に陳腐化したり、新しいものが必要だと気づくので、先の詳細は先に考えるのが良い。You ain't gonna need it だ。

逆に、ウォーターフォールなんかで要求定義をするということは、

「これを作ります」という宣言の裏で、
「これ以外は作りません」という宣言をしているのと同じなのだ。

IT のプロセスの問題の不都合をビジネス側に押し付けるのは、流石に傲慢では？という感がある。

もう一つ、「実現方法」が不確実・不安定な場合がある

わかりきった、枯れきった技術でやるのと、新技術や出たばかりの OSS なんかでやるのとでは、同じことをやるのにもリスクが全然違ってくる。

ある程度試行錯誤して泥沼にハマって進まないといけない。

こんな場面で実現可能な「実現方法」を計画として建てろと言われてもアホなだけだ。

全く未知の場合は、ある程度ジャブを打って Shure な状態にしてから着手したりする。

スクラムで言えば「技術的スパイク」とかいうやつがそれに当たるか。

（以下、例えがすごく怒られるやつ）

要は、幼馴染とご飯に行くのと、街中で出会った女の子とご飯に行くのでは途中のプロセスは全然事前に読めないし、ある程度試行錯誤が必要なのと同じだ。

前者であれば、いつ何食べに行こうぜ、って誘えば来るな、って計画が立つけど、

後者であれば、何が好きか？何が嫌いか？そもそも初めまして、、、とか色々やらないといけないし、具体邸に何をやるかは計画できない。

ある程度の「構え」的なものを持っておいて、柔軟に対応するしかない。

そして当たるものを試行錯誤するために、頻繁に手を替え品を替えてご飯に誘うしかない。

そう、ナンパとはアジャイルなのだ

（以上、すごく怒られるやつ）

というわけで、不確実な目標や手段を必要とする場合には、試行錯誤のサイクルが勝負につながるので、アジャイルなやり方が性に合っている、ということになる。

（というか、計画駆動を選んだ時点でほぼ ”負け” になる。）

そのやり方で、本当に意味のあるものを作れますかね？勝てますかね？っていうは、開発手法を考える上で、必ず考えておきたい。