こんにちは、今年4月から tebiki 現場教育のエンジニアをしている許斐です。

スクラム未経験だった私が Tebiki のスクラムチームに参加し、葛藤し、その中で得た学びを、スクラム初期・中期・後期という時間軸で振り返りながら整理していきます。

この記事を通して

と、とても嬉しいです！

【初期】スプリントゴールって複数あっちゃいけないの？

スクラムチームに入ってまもない頃、次のような事がありました。

この出来事は、ゴール外の作業をすることに対して、私を臆病にさせるのに十分な体験でした。

蚊帳の外にいるような気持ちで日々不安を抱えながら実装を進めていたところ、案の定手戻りが発生したからです。

しかし、包括的なドキュメントより動くソフトウェアに価値をおくアジャイル開発において要件の修正は往々にしてあります。

必要だったのは２番目のスプリントゴール、個人のタスクに注目を集めるイベントではなく、不安要素を自分の中で言語化して適宜アドバイスをもらうことでした。

【中期】自分ってチームに貢献できてるんだろうか？

スクラムチームに入ってから暫く経ち、次のような事に悩まされました。

チームの意思決定が滞りなく進んでいれば良いのですが、どうすべきか皆が悩んでいる時に解決策を提示できないのは無力感がありました。

果たして自分はコラボレーションの一端を担えてるのだろうかとモヤモヤしてたところ、開発組織内のドキュメントに「助言プロセスによる意思決定」という表題の ADR を見つけました。

Tebiki での助言プロセスの定義はこちら。

説明責任を持っている人が、それを果たす手段として決定権を持つ。ただし、決定を下す前には必ず、関係者に助言を求めなければならない。

ここでは詳細を割愛しますが、全員の意見を調整しようとするのではなく、責任者の決断を皆で支援しようというものです。

この考え方は目から鱗で、必ずしも自分の意見を持つ必要はなく、他人の意見のサポートに回るという動き方もアリじゃんと、ミーティングにおける役割の認識を改められました。

つい最近の話ですが、次のような事がありました。

最後の方をもう少し補足すると、技術的な制約により当初想定していたものとユーザー体験がかけ離れたものになっていたのです。

もっと早い段階でその制約に気付けなかったかという声もあり、認識合わせをやり直しながら、どのプロセスをどう改善すべきだったのかを考えました。

そんななか、1on1にていつも鋭い洞察力を発揮してくださるメンターの方に「自分がどのように動けば良かったと思いますか？」と問われました。

自分にフォーカスして振り返ると、ワイヤーが完成してからアーキテクチャを考えようとしていたことが思い当たります。

仕組みに目を向けるより前に自分がどうすべきだったかを考える必要があったと痛感しました。

「自分に2％でも問題があると感じるのなら、自分のせいだと思った方がいい」というのは、同じ方から既に頂いていた言葉です。

スクラムガイドを読んでルールを理解したり、プロセスやツールを学んだりするのは大事なことに相違ありません。

しかし、それはあくまでハードウェアであり個人の認識なくしてスクラムは機能しないのだなと、振り返りを通して自分のソフトウェアが更新されました。

仕組みに目を向ける時、まずは自己を正しく認識し、そこからチームへの貢献度を高めていこうと思います。

最後まで読んでいただきありがとうございました！

Tebiki社では一緒に働く仲間を募集しています！
スクラムに少しでもご興味を持っていただけた方、ぜひ採用サイトをご覧ください！ tebiki.co.jp