LEGOスクラムに参加した！(座学編)
この記事なに？
12/14(木) に行われたLEGOスクラムのレポートです！
イベントの詳細についてはこちら↓
参加の理由としては、「今のチームでやってる手法がちゃんとアジャイルのレールに乗っているか？」「体系的に一回知識を入れてる一貫として、先輩におすすめされたから」
といった感じでした。
チーム決めでは、スクラムについて詳しい順に並んでくださいということで、まさかのプロジェクトでやってる方が私しかおらず、参加者の中で１番詳しい人となりましたｗ
この記事では座学で学んだ部分についてまとめます。
ちなみに、メモは会社の slack で垂れ流ししてました。
アジャイル is 何？ スクラム is 何？
まずは、なんでもかんでもアジャイルを適用すればいいのか？ いわゆる銀の弾丸なのか？という話です。
大前提アジャイルに定義はない！！
あえてあげるとすれば、態度や概念。
スクラムやカンバンといった方法論を身につけることで、アジャイルが習得されるでいいということです。
では、スクラムとは何なのか？
スクラム＝複雑で変化の激しい問題に対応するためのフレームワーク。可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのもの。
複雑で変化の激しいとはどんな状況なのか？
何を作ればいいか・どうやって作ればいいかが中途半端なものをここでは、複雑(Complex)なものとして定義します。
例えば、夏休みの宿題のようなものは、スクラムに向いていません。
なぜなら、何をするかも、どうやるかも明確で、各教科を１つずつ終わらせていけば全ての作業が完了するようなものだからです。特に変化が発生する要素がないので、別の方法を適用する方がよいらしい。
セミナーの中では WBS*1 に切ることが出来るものということも仰っていました。
また、漠然としすぎていてもそれはそれで問題だそうで、「世界を良くするものを作る」という、何を作ればいいか・どうやって作ればいいかが難しすぎる(Anarchy)な問題に関してもスクラムを適用することはできません。
これを達成するには、デスマーチしかないとのこと。
これらの真ん中の作業の時にスクラムが有効な手段となりうるそうです。
アジャイル開発は、オブジェクト指向開発を人間に当てはめたもの
オブジェクト指向形のプログラミング言語の特徴として、クラスに生えてるメソッドはどのインスタンスでも同じような振る舞いを行うというものがあります。
その考え方をプロダクトマネージメントにも応用しようと考えたのがアジャイルなチームの始まりで
- １つ１つのタスクが誰がどの作業をやれる状態となっている
- アサインではなく、サインアップ
- 機能横断型なメンバーでチームを構成する
１つ１つのタスクが誰がどの作業をやれる状態となっている
これは、タスクの粒度や共通認識のレベルの話で、全員が同じ規模感や認識を持つことが重要ということです。
そして、１つ１つのタスクに対して、誰かから当てはめられるのではなく、手が空いた人から「これやります！」というのが大事になっています。
確かに、うちのプロジェクトでもサインアップは意識されている気がする
機能横断型
機能横断型とは、自分の領域を絞らずに全部出来る(しようとする)ゼネラリストのような人が集まった集団が求められるということです。
例えば、「自分はバックエンドだけしかするつもりありません」という人より、「デザインもできますし、インフラもできます」というような感じです。
今まで、スクラムは一手法として捉えていたので、オブジェクト指向を人間に当てはめたものという表現は納得感のあるものでした。
一回で完成品を作ろうとするのは無理
半年がかりで、どかっとした機能を作るのではなく、雪だるまのようにちょっとずつやれることを増やしていく考え方でプロジェクトを進めます。
- 最小の単位で作ってみる
- 製品とプロセスの振り返りを行うこと
特にどのようにこれらを作っていったか？というプロセスまで振り返りができるようにすることで、個人としてではなく、チームとしての成長を狙っています。
座学の中では最高に美味しい焼きそばの作り方というテーマでワークが行われました。
ラグビー型のチームへ
複雑で変化の激しい領域に対応するならば、継続的にちょっとずつ前に進める変化に強いチーム作りを意識しなければならない。
引用：The New New Product Development Game
type A のようなリレー形式のように、引き継ぎ引き継ぎで作業をするのではなく、同じチームで継続的に少しずつ進んでいく type C のようなラグビー型のチームのほうが早く進めることができるという調査。
このラグビー型チームにしていくためには、決まったパターンがあるので一回それに当てはめてみてトライアンドエラーで進めていくことが大事そうに感じました。
基本的に【プロダクトオーナーxスクラムマスターx開発チーム】の構図
ここでいう開発チームは、実際にコードを書く人だけでなく、テスターやデザイナーも含まれるそうです。
そして、プロダクトオーナーは「何を作るかの責任者」であるため、必ずしも技術に長けている必要はない。 顧客からの要求をスキニングしたり、製品の価値として、どこまで求めるかの意思決定を行う。
スクラムマスターは「どうやって作るかの責任者」であるため、そのチームの中で一番技術に長けている人がなるべき。
チーム内で発生したバックログに全く関係のない雑務(例えば会議の調整)もスクラムマスターが行うべきだそうです。
その理由としては、チームとして目標を達成できることが一番なため、個人のスキルを高めるために余裕のある人が「技術的に一番余裕がある人」である点。 また、他の人に目を配る余裕がある点や、何をやっているかが(技術的に)わかる点も１番スキルの高い人がやるべき要因です。
そしてなにより、技術に長けている＝ Complex な問題を解決する力が強いわけではないということも前提としてあります。
まとめ
ここまで、アジャイルの方法論の一つであるスクラムについて書いてきましたが、最後にまとめると。
- スクラムは適度に複雑(Complex) な問題を解決する方法で簡単すぎても漠然としすぎてもいけない。
- なんども繰り返してチームとして問題解決を行える力を付ける
- そこでは必ずプロダクトとプロセス両方の振り返りを行う
この座学のなかではあまり触れられていなかったのですが、お客さんがアジャイルに積極的かどうか？という点も実際の仕事においてはかなり重要になっていくそうで、お客さんの理解を得る方法については、アジャイルサムライに、確実に動くものを毎週届けることで、少しずつ信頼を得ていくというのが大事という風に書いてありました。
あと、ここや本に書いてあることはあくまでもテンプレートなので、最終的な形は自分たちでカスタマイズして作っていくことが大事になってくるのかなと思いました。
最初から、アジャイルな気持ちで〜と言っても何をすれば？となってしまうので、初めは型にハマって、次第にカスタムしていくというのかな。
特に Web 業界だと、週に1回のリリース頻度だとちょっと遅すぎるので、そこらへんのバランスも必要になってきたりしそうです。
というのが座学の感想です。
後半のレゴ編に続きます
*1:Work Breakdown Structure：作業分解構成図
