スクラムビギナーのスクラム実践 その1
お久しぶりです！アジャイル開発チームのたけやんです。
スクラム始めたてのくせにスクラムマスターとして銀行内プロダクトの開発に携わっております。好きな食べ物はウナギです。なぜかチームメンバーから逆に高級ウナギを奢れと迫られてます。助けてください。
noteへの投稿は2回目になります。前回の投稿では、スクラムマスター研修のお話をしましたが、今回はスクラム実践編ということで、この一年携わってきたプロダクト開発について、スクラムな目線でご紹介したいと思います。
プロダクト概要
携わっているプロダクトはこちら。
ついこの間ローンチされたばかりの、ホッカホカのサービスになります。
今回はプロセスの紹介をしたいので、プロダクトの詳細は割愛させていただきます。
体制
では、我々がどんな体制でこのプロダクトを作っていったのかをご紹介します。
(私の所属するチームは、ジャッカルチームです）
・・・。
・・関係者多いなっ！！
開発するものに対して、機能横断的にチームが構成されるのが良いとは言われますが、既にリリースされているプロダクトを開発してるチームや、共通的な機能を提供しているチームが居たりでこのような体制に。
まあでも、こういった体制ってわりと現実的にあるんじゃないかなと思います。
それに、「全部理想どおりに始まってうまく行ったぜ！」というより、色々と試行錯誤しながらやったことをご紹介した方が、
「スクラムってどうなの？」
「現場のリアルなスクラムを知りたい！」
と思って見て頂いてる方の参考になるかなと。
課題
図を見てのとおり、体制が複雑なことです。何事も、複雑な構成というのは複雑な問題を引き起こしがちです。
例えば、実装を行うチームだけでも外部ベンダー含め6チームが混在しています。これらのチームが同時多発的に仕様を変えたり、実装したり、試験をしたり・・・と考えると、不穏な匂いは感じ取って頂けるかと思います。
解決案
上記の課題の解決策を考えるとしたら以下の３つでしょうか。
A. 機能横断（フィーチャー）チームを作る
B. 細かく機能をリリースする
C. チーム間のコミュニケーションを密にする
実際に我々が取った策は・・・Cでした。
体制やスケジュールの大幅な変更はそれもまたリスクであるため、AやBは実践できませんでした。そういった働きかけもスクラムマスターの大切な役割なので、私の課題として今後精進していきたいと思います。
しかし、「プロセスよりも対話を(*)」というアジャイルソフトウェア開発宣言にもあるとおり、手段に縛られず、全員が課題を認識し、対話を重視することが最も大切だと気づかされました。
ここまで来れたのは、各チーム、各メンバーが難しい体制の中でもお互いに対話を繰り返していった結果だと思っています。
全開発チームでのミーティング風景
*アジャイルソフトウェア開発宣言より。正確には、「プロセスやツールよりも個人と対話を」
おまけ
まだまだ紹介したい事はたくさんあるのですが、長くなってしまうので一旦切って続きはまた次回とさせて頂きたいと思います。
最後に、我々が実践したものでやってよかった！おすすめ！というものがあるのでその内の1つをご紹介します。
それは・・
アンガーマネージメントゲーム！！
「アンガーマネジメントゲーム」は、様々な「できごとカード」の内容がもし起こったら、カードを引いたプレイヤー（回答者）がどのくらいの怒りを感じるかを他の人が予想し、最も予想が当たったプレイヤーが勝ちになるゲームで、当会が開発した、世界初となる“怒りのツボ当てカードゲーム”です。
同じアジャイル開発チームのまっちゃんが持っていたのを借りて、チームが編成された初期にチームビルディングの一環としてやってみました。
これが、想像以上に楽しく、非常に盛り上がりました！同時に、周りの人から見た自分像がわかるので、自分自身を見つめ直すいい機会にもなりました。
またチャンスがあればやってみたいなぁと思っております。（薄情なうちのメンバーはやりたくないと言うかもしれませんが・・・笑）
話が少し逸れてしまいましたが、次回もスクラム実践編の続きをお届けできればと思っております。
ではでは、肌寒くなってきましたのでお風邪など召されませんよう！