Agileと計画 - Agile/Scrumの考え方
私、IT業界にいるので、普段Agile/Scrumで開発を進めているわけですが、世の中ますます不確実性の高い世界＝VUCAの世界になっています。
VUCAは以下の頭文字を取ったものです。
- Volatility : 変動制
- Uncertinty : 不確実性
- Complexity : 複雑性
- Ambiguity : あいまいさ
こういう世界観なので、全ては予定通りに進みません。 そうすると、状況の変化に素早く対応していかないとまるで上手くいかなくなります。 そういう状況を解決するために生まれてきたのが、Agileの考え方なわけですね。
- プロセスやツールよりも個人と対話を
- 包括的なドキュメントよりも動くソフトウェアを
- 契約交渉よりも顧客との協調を
- 計画に従うことよりも変化への対応を（主にここ）
この文章はよく誤解されるのですが、決して「計画をしない」ということではありません。 物作り、特にソフトウェア開発において、全てをアドホックにやっても上手くいきません。
そういうやり方をすると、上の方の人から
- 何を作っているのかよくわからない、
- いつできあがるのかよくわからない、締め切りに間に合うのか？
という声がよく出てきます（実際に聞いたこともあります）。 Agileの考え方を理解していない人ならなおさらです。
- 計画は立てます、ただし、状況に応じて変更します
ということです。
物作りにおいて、計画を立てると次のようなことがわかってくるはずです。
- 何が作られ、何が作られないのかがわかる
- いつ頃までにできあがるのかがわかる
- 今何がわかっているか、今何がわかっていないのか
- わかっていないものはいつ頃までに解決できれば良いのか
今自分たちがわからないものがあることを理解しておくというのはすごく重要です。 そして、わからないものがわかるようになるときには状況が変わっていたりすることもあります。
計画の立て方はいくつもあると思うのですが、スクラムを回している前提があると、
- PRDが作られる
- どのようなものを作るのかはっきりさせる
- PBIが作られる
- どのような順番で価値を提供していくのかがわかる
- PBIのリストからいつ頃終わるかが予測される
- PBIに見積がついている、かつ、チームのベロシティがわかっていると導き出される
PBIの見積は通常、相対見積もりで行うことが多いのですが、予実計測が出来ているのであれば時間換算でも良いとは思います。 見積の話はそれだけでかなりの量になるので、今回は省略しますが、一番重要なのは
チームのベロシティ＝1スプリントでどれだけの量を終わらせることが出来るのか
を知る必要があるという点です。
ベロシティが安定していると、
1スプリントで作業できる量がわかる⇒PBI全部が終わるのにかかるスプリントの数がわかる⇒いつ頃終わるのかの予測が立てられる
というわけです。
ここの考え方は「スプリント期間で出来る作業量には限界がある」というものです。 箱の大きさが決まっているのに、それ以上のものをつめようとしてもあふれてしまい、蓋が閉まらないということを意識しておく必要があります。
そして、大抵のソフトウェア開発には締め切りがつきものです。大抵、PBIのリストを全部やるときの予測期間では間に合わないので、やること・やらないことの優先順位を決める作業も必要になります。
組成したてのチームや人の入れ替わりの激しいチームではベロシティが安定しないことが普通なので大抵遅延します。したがってスクラムチーム回す際には、終わるまでチームメンバーの入れ替えが発生しないのが理想です。 とはいえ、人の増減は発生するので、ベロシティの予実は必ず計測するようにしましょう。
LeSS・PBI・Scrum
これはMackerel Advent Calendar 2022の8日目の記事です
こんにちは、株式会社はてな Mackerel開発チームでディレクターをしています。
今回は今のチーム状況と気になっていることをつらつらと書こうと思います。
LeSS
前回の投稿から1年たちました。ずっとLeSSを回しています。 時間がかかるのは覚悟の上で、いろいろやってきたおかげで、まあまあ回るようにはなってきたと思います。
ベロシティの予測がほぼ正確に出来るようになってきました。 逆にPOの負担がさらに増えてきている状況です。さすがにタスクレベルの管理はやらないようにしていますが、限界に近そうです。 目下、可能な限り優先順を直列に並べて、並列度を下げるように工夫しています。 とはいえ、やらないといけないことも多くやりくりに苦労しているところです。
やり方に忠実に従うと、分割したチームごとにSMを置かないといけないのですが、現状2チームなので、チーム代表のみ置くようにしています。
PBI
PBIの書き方を変えたりしています。 特に完了の定義は「どういう状態になればこのPBIは終わるのか」を考えるようにしています。 本番リリース出来る状態にするのが大前提ですが、やらなくていいことも考えておかないと永遠に終わらないなんてことになってしまします。 また、可能な限り具体的に書くようにしています。 完了の定義に暗黙知が含まれているときも多いので本来であれば別に列挙しておいた方がいいのかもしれないです。
PBIについてもう一つ。 基本的には価値提供の単位となっているはずなのですが、実現したいことに対しての説明中、どうも上手くいかないことがあります。 どうやら、PBIの内容は決定事項であり、それをその通りに実現すればよいという空気が漂っているようです。
本来PBIに書かれている内容は - どのような価値を誰になぜ提供したいのか？ - その価値を提供するためには何を満たせばいいのか？ といったことであり、仕様書やタスクリストの類いではないと考えています（どのように扱うかはチームごとに決めればいいとは思います）。
PBIの内容はPOと開発チーム間で合意を取る必要があるのですが、開発チームは「その価値を提供するためには何をどうすればいいのか？」を全力で考える必要があるはずです。 したがって、設計から実装、結果の計測方法など、価値提供に必要なものを洗い出し、実際に実行し、できあがったものが完了の定義を満たすかをPOに確認を取り、プロダクトとしてリリースして初めてPBIがクローズできるようになります。
それでも、何か違うとなれば、完了の定義を進行中に変えることをPOと相談することも出来ます。 それは、Agileの原理原則から見ても許容されているものです。
したがって、仕様書（PRDやDD）は別で用意するようにしています。 Agileであろうと無かろうと、ドキュメントがなければメンテナンスをするにも大変ですし、どうしてこのような作りになっているのか、なぜそれをやったのか、なにをやろうとしたのかわからなくなってしまいます。 今やっていることに対して振り向く対象としてドキュメントを残すのであり、それを見直し向き直りをしていくことを許容するのがAgileであると思います。 たくさん書く必要はないのですが、必要最低限のものは残していく必要はあるでしょう。
Scrum
最近Scrumの意義、イベントの意味などに対して無意識になっているような気がしています。 一度有意識下にもっていき、下意識（体が覚える）にしていきたいところです。 そのためにも、メンバー全員に対する啓蒙活動を続けていかないといけませんね。
2021年を振り返って
仕事
前半
上半期は前職にいたわけですが、転職活動をしつつ、いろいろやっていた気がします。
毎度のことながら評価をするのは大変ですし、かなり大きなプロジェクトが動き出していた（その後どうなったかは知りませんが）ので、人員の割り振りやら、派生プロジェクトの面倒を見るなどしていたと思います。
一番最後にした仕事が評価だったのがつらかったですね。
後半
はてなに入ってからは、AgileやScrumについて再度考え直すことができたと思います。
号令をかけることはできても、実際にやる人たちとの相互理解がなければどうにもなりません。
この点については別の切り口でもよかったかなと思っています。
趣味
フットボール
我らが柏レイソル、なんとかJ1残留できました。
21シーズンはオルンガ被害者の会筆頭だと思っています。 一人いなくなるだけで、あそこまでガタガタになるとは思ってもみませんでした。
点が取れないのもですが、前半の20分くらいまでに失点するとあとはズルズルとやられっぱなしに。 後半終了間際にいい形を作っているように見えても、相手が引いているからそれっぽく見えているだけな気がしています。
2021年12月29日現在、レギュラークラスの流出が続いているので、来年こそは降格かもしれません…
模型
積みプラが増えました。＼(^o^)／
記録によると、今年の完成品はぱち組だけという有様でした。
地味に続けているものもあるのですが、しばらく止まっては再開してを繰り返しています。 試したいことがいろいろあって、それの寄り道をしていたことが一番の原因だと思っています。
来年は寅年なので、かなりの数コレクションしているTigerI / TigerIIを作ろうかなと思っています。
来年もよい年でありますように。
2021年買ってよかったもの
2021年の買ってよかったものリスト。
Belkin SOUNDFORM™ CONNECT AirPlay 2対応オーディオアダプター
これまで、初代AirMac ExpressでAirPlay接続していたのですが、さすがに寿命が来そうで、いろいろ物色していたところちょうどいいタイミングで出てきたのがこれでした。
なんといってもお手頃なお値段がいい。
大きさもコンパクトでアンプの裏においておくにはちょうどよい感じです。
デジタル出力が同軸ケーブルもあれば最高なんですけどね。
後で知ったことなのですが、ラズパイでAirPlayレシーバーを自作するなんてこともできるそうです。
そのうちチャレンジしてみようと思います。
サンワサプライ 工事物件タップ 3P抜け止めマグネット 8個口 5m TAP-K8-5
今の家に引っ越してきて10年くらいたつので、あちこちの電源ケーブルを総入れ替えしました。
8個口で裏面磁石付き&アース付きのものです。
ものすごいしっかりしたもので、メタルラックにがっちりくっつくので、非常に便利です。
電源ケーブルの耐久年数は10年くらいらしいので、皆さんも古いケーブルがあったら交換をお勧めします（職場で煙が出たことがあります）。
ちなみに、我が家の壁電源も一部アース付きの3穴タイプになってます。
ドロッパーボトル 小分けボトル スポイトボトル 液体容器 プラスチック 塗装 アート 多用途 (30ml 30個セット)
（自分が買ったものはAmazonで在庫切れなので検索してください）
よく使う塗料をあらかじめ希釈しておいてためておくために買いました。
栓がちゃんと閉まるものと閉まらないものが混在、明らかに手作業でバリを落とした傷がある付属のロートなど、ぶっちゃけ品質は微妙です。
本当は30個もいらないんですが、ちゃんとしたやつが在庫切れだったので、ネタ扱いで買ってみました。
自分はオール水性塗料なので、蓋の品質が悪くても匂いが出てくることがなくそんなに困っていません。
Mr.攪拌用メタルボールを入れておけば混ぜるのも楽です。
思ったよりは使えているのと、奥方がガサガサ入れてある袋を見るといつも笑ってくれるので満足しています。
Concepts
もともと紙と鉛筆を使って考え事をするタイプだったのですが、これ以上紙を増やしたくないので、iPadAir＋ApplePencilに乗り換えを決意。
手書きノートツールをいろいろ探した結果、たどり着いたのがConceptsです。
わりとマインドマップ的な書き方をすることが多いので、紙面が無限にひろがるのが便利すぎます。
ペンの色がCopic準拠なので、カラーピッカーみたいのでちまちま選ぶ手間が省けるのもいいです。
これまで、GoodNote5、Noteshelfなどいくつか渡り歩いてきましたが、一番ペン入力の反応がいいと思います。
NieR Replicant ver.1.22474487139... フェイスクッション ＜エミール＞
ほぼ原寸大のエミールのクッションです。
もちもちの感触がすごくいいです。
輸送の都合でやや潰れてしまっていましたが、元に戻りました。
今ではすっかり奥方のご愛用です。
adidas 4DFWD
すっとはけるスニーカーがほしくて、ふらっと立ち寄った直営店で試し履きして即購入しました。
ソールが3Dプリンタの出力品というだけでもう大興奮。
履き心地が異次元の感覚で、路面形状が直接伝わってくる感じがするのに、痛いとかそういう感じはまるでありません。
普通のゴムやスポンジのソールとは明らかに感触が違います。芝生の上を歩いている感じに近い？
歩くときは（なぜかはわかりませんが）かかとからではなく、つま先から足をつくような歩き方に自然になってきます。
表面はメッシュ素材なので、冬場は若干ひんやりしますが、あまり気にならない程度です。
靴紐はついていますが足の甲のあたりは伸縮性素材なので、毎回結び直す必要もありません。自分はゆるめに結んであります。
LeSSを回して3ヶ月
これは Mackerel Advent Calendar 2021 の8日目の記事です。
こんにちは、株式会社はてな Mackerel開発チームでサブディレクターをしています。
現在Mackerel開発チームにて、大規模Scrum導入とチーム改善に取り組んでいます。
今回はMackerel開発チームでLeSSを導入・運用して、わかってきたこと・課題などを振り返っていきたいと思います。
スクラムをスケールするには？
プロダクトに関わる人数が増えてきたときにどうスクラムを回すか？は、非常に難しい問題です。
今回、Mackerel開発チームでは、Lessフレームワークを採用することにしました。
日本語の解説本もあるので、そちらも参考にしつつ、チームの現状に合わせていく形です。
わかったこと
まずは3ヶ月でわかったことです。
教科書通りに始める
まずは教科書通りにやってみることが重要です。
教科書通りに進めつつ、状況に応じてやり方を変えていくことをおすすめします。
いきなりアレンジしてしまうと、うまく回らなかったり、結局やめようと言うことになってしまうことになってしまうと思います。
多少違和感があっても、まずは教科書通りにやってみましょう。
通常のScrumの知識は必要
10人以下でのチームによるScrumの経験と知識があると理解しやすいです。
LeSSは普通のScrumを拡張しているものなので、考え方のベースは何も変わらないと思っています。
何も知らない状態から始めることも頑張ればできるとは思いますが、その場合はがっつりアジャイルコーチに頼ることになりそうです。
スプリントイベントが高コスト
スプリントイベントは、開発チーム全体についてのイベントと、各チームのイベントの二部構成になっています。
通常のScrumでも同じだと思いますが、スプリントイベントはほぼ一日それにかかりっきりになります。
イベントで会話される話題も格段に多くなるので、時間切れにならないよう注意して進める必要があります。
連続してイベントを入れると疲れるので、休憩を入れながら進めることをおすすめします。
我慢も必要
先ほどスプリントイベントに時間がかかると言いましたが、扱うテーマ、関わる人、すべてが増えていくので、時間がかかるのは致し方ないところです。
なんとか早く終わらせたいという気持ちはありますが、プランニングやレトロスペクティヴは必要不可欠なものなので、時間をかけて会話した方が結果としていい方向へ進むはずです。
課題
うまく回っているように見えても、まだまだ課題はあります。
課題がないと言われる方がよっぽど怖いですが。
チーム分け
よくないのはわかっているのですが、現状、SREとデザインが職能別のチームとして独立してしまっています。
開発チーム全体が過渡期なのでこのように分けていますが、今後解消していきたいと思っています。
Agile、Scrumの知識共有
自らにもいえることですが、メンバー間の知識のずれを解消していく必要があると考えています。
枠だけできあがっても、その本質を理解していないとただやっているだけになってしまいます。
これまで、無意識的に行ってきたものを一度有意識下に持ってくることが重要になります。
時間をかける覚悟
導入への準備から、実際の導入、その後の改善、人間観家に構築など、Agile開発が軌道に乗り、チーム全体が自己組織化されるまでをゴールすると、それなりに時間はかかります。
「じゃあ来週からLeSSでやるのでよろしく」ですべてうまくいくものではありません。
開発メンバー、マネジメント層ともに時間をかける覚悟は必要です。
POの負担が増える
普通のScrumを拡張したものなので、POはただ一人存在することになります。
すべてのPBIを管理することになるので、優先順位をつけるだけでも大変です。
POの負担を減らすためにも、POの民主化を進めていく必要があります。
現在、アイデアレベルからPBIになるまでのフローを整備しようとしています。
まとめ
LeSSについてわかったことと課題をいくつか挙げました。
Mackerel開発チームの冒険はまだまだこれからです。
すべてはMackerelを使うユーザーの皆様のため、プロダクトの改善を続けていきます。
プロセスの改善はプロダクトの改善につながるものであるので、今後もチーム改善に取り組んでいきます。
来年もMackerelをよろしくお願いいたします。
転職しました
転職活動
今を去ること2年くらい前にFacebookに来た転職エージェントからのDMがきっかけで、転職活動を始めました。
途中、エージェントの方と方針が会わなくなってきたので、しばらく休んでいましたが、今年になってから真面目に活動を再開。
無事今の職場が決まったのはありがたい限りです。
転職
というわけで、8月から新しい職場にいます。
まさか、自分がはてなで働くことになるとは活動を始めた頃には想像だにしませんでした。
所属部署は国産監視ツールであるMackerelの開発部門です。
というわけで、入社4ヶ月もたってから、自社主力サービスを使ってみようと思い立ったわけです。
何をやっているか
マネージャー職で転職したので、開発におけるマネージメントをやっています。
主にやっているのはLeSSフレームワークを用いた大規模スクラムの導入です。
メンバーは全部で20人弱と大所帯なので、どのようにして、チーム全体を有機的に動かすかを日々考えつつ実践しているところです。
このあたりについてはもうちょっと結果が出てからアウトプットを残そうと思います。
これまでの感想
はてなといえばテキスト文化ですね。
最初は圧倒されてしまいましたが、そろそろなれてきました。
前職より会社の規模が相当小さくなったので、ほかの部署の方とのやりとりも頻繁にできるのがいいですね。
