スクラム開発の立ち上げに携わる

はじめに

  • 気づいたら一年振りのブログです
  • 職場も新しくなり右往左往しています

この記事の概要

  • スクラム開発立ち上げの時期に入社したのでその際に感じたことなどを書きます
    • 厳密には、すでに移行の準備は始まっており、自分が入社した段階ではチーム開発を始める手前の状態でした
  • ポエムっぽい側面もあります。

スクラム開発スタート

前提

見積もりは時間ではなく相対的なポイントで見積もる

  • 個人的な観点ではなしますと時間で見積もれるならそれはもう不確実性がなく、何をどう実装しどれくらいで終わるか明瞭であるため、スクラムで開発する必要性はないと思いますので、まぁスクラムでやらなくていいんじゃないんですか?と思っています

  • 不確実性とは?

    • ふたしかなこと と定義されています。
システム開発においての不確実性とはどんなことがあるのでしょうか?
  • 例えば
    • 影響範囲、結合度が高い実装がされている場合至る所に影響が発生します。これは予め予測が可能なものではないです。
    • 外部サービスを使用している場合、社内に知見がなかったらドキュメントを読み解きながらの実装になりますので想定より時間がかかってしまうことが多いですね。
    • また途中で考慮漏れに気付いてのタスクの追加、設計の見直しなども起こりうることですね

他にも様々なことが起因になり、想定外のことが発生し、時間を使うこともしばしばあると思います。

時間で見積もりを出すとどうなる?

  • 時間という概念は、皆が平等に共通認識を持っています。15分は15分以上でもなく以下もなく15分です。なのでその時間内に終わらせないといけないという縛りがメンタル的に発生します。そうなると心理的ハードルがあがります。また焦りも生まれ、その時間内に終わらせるために気づかないうちにバグを生み出しているかもしれません。そうなると本末転倒ですね。なので時間で見積もる必要性がないです。また不確実なことに対して時間を見積もれるわけがないです。

  • また時間というのは、あればあるだけ使えばいいという発想になりがちです。締め切りがm月d日だったとしてぎりぎりその日までに終わればいいやとなります。実際は、もっと早く終えられるかもしれないのにです。

    • ただしポイントにしたからといってここが完全に解決されるわけでもありません

結果正しい見積もりって可能なの?

  • 結論は完璧には、無理です。

    • なので不確実性に対して学習をしていき、スクラムイベントのスプリントプランニングで決める計画がスプリント内で完走できる計画になるように確度を上げていく姿勢(学習だったり、のうはうの蓄積)が大事になります。
  • もし社内で正しい見積もりが必要であるなら概算を出すことは可能だが前後するという共通認識は必要ですね。

    • スクラムを続けていくことにより確度の高いリリース予定日は想定可能になっていくと思いますが

守破離を意識しましょう

  • スクラムに限ったことじゃないですが、未経験の未知なことに対して分からないことがわからないままカスタマイズするのは、かなり悪いミス(悪手)です。

    • わからないことが悪いことではないですが、経験した上でオリジナルに昇華させるのが大事です。
    • また経験も自らが学んだこと出なければいけないと思います。事実に基づいてがとても大事ですね
  • またルールがあるということは、そのルールに従うことを想定したフレームワークになっているので原則は、従うのがベストだと思います。

守破離の守を守らずに始めるとどうなるか?

  • スクラムをやっている気になることです。
    • 中途半端な状態でなんとなくうまくいっているふうに感じてしまっている状態と言えそうですね。
    • スクラムは経験主義なので経験し学習し、改善し自分達にあったやり方を見つけていき、不確実性に対して向き合うことが大事だからです。
    • やっている気になると、問題点に対して誤った解釈し、ミスリードされたまま話が進みレールから外れた状態に陥ります。

チームでの動きが始まってから

  • まず僕がスクラムマスターに就任しました。ただこれも開発者との兼務なので良くない状態です。
    • CSM(認定スクラムマスター)を取得しました。

やったこと

  • スクラムがわからない人で集まって事前勉強会
  • 他のチームのスクラムマスターとの振り返り
  • チーム内で率先としてスクラムマスターの動きなどを行う
    • タスクのやる目的、タスクが終わる状態の確認(受入条件の確認)
    • MTG時にアジェンダの作成や空中戦を避けるための資料作成など
  • SCRUM BOOT CAMPの輪読会を開催

スクラムの文脈とは異なることもありますがどれも不足していると感じたため行動しました。

今後の課題

  • 責任の所在など
    • ここは、個人の領域から離れてしまうため事業部全体でどうしていくかの共通認識を取る必要がありそう
    • 肩書き上は、明確には分かれているように外から見えなくもないがひどく曖昧な状態と感じている
  • 開発者のスキルの底上げ(現状webとmobileのエンジニアが混在している)
    • 誰がどのタスクをとっても作業できる状態になるといいんですが領域が異なるため基本的には、各人の領域でのスキルアップが当面の目的になりそう
    • スキルの底上げにフォーカスして考えるモブプロかペアプロを常に行う必要性がある
  • スクラムイベントの目的の再共有
  • 複数のスクラムチームが存在しているためLeSSへ昇華させるよう働きかけ

他にもたくさんの課題が潜在的にも表面的にありそうです。が課題等は、積極的にみつけて改善していきたいですね。

まとめ

  • スクラムは、経験者がいればどうにかなるってこともなく、大事なのは、アジャイルスクラムに対してのマインドセットな部分も強いんだろうなと感じてます。個人的には、スクラムでの開発は、スプリント内のやることが明確だったり目指すゴールが何かなどが知れたり、ウォーターフォール開発よりは好きです(対極の開発スタイルと言っているわけではないです比較対象として)

  • 今後は、開発者のロールは剥がされ、スクラムマスターとして接していく立場になる予定です。この半年でスクラムマスター兼開発者→SRE所属のスクラムマスターとなりそうです。本来ならスクラムマスターとしてだけの立ち回りがいいのでしょうが今のチームの自己組織化がまだまだ未達の状態なので(自分の至らなさですね)そのような状態になりそうです。