いてづきブログ

情シスでやってみたことの備忘録

プランニングを制するものはスクラムを制す

というのを考えた。

 

アジャイルコーチに見てもらいながらスクラムのイベントを一通りやってみて、これまで仕事してきた中でうまくいっていたチームに共通してそうなことを考えてみた。

 

 

その中で一番違いを感じたのがプランニングだった。
うまくいっていたチームはスプリントのタスクの内容を細かく確認していた。

逆にそうでなかったチームはやるタスクを決めたら中身はざっくり確認で終わる、そもそもプランニングに時間を割いていなかったというパターンが多かった。

 

タスクの内容を細かく確認するのはチームが進捗の状態を検査できるようにするため。
例えば何らかのデータを表示する機能を作ろうとするとこんな感じ。

  1. APIのエンドポイントを作る
  2. データを取得できるようAPIの中身を実装する
  3. フロントから呼び出せるようにする
  4. 呼び出した内容で表示を整える

こういう形になっているとデイリーで何番の作業までは終わっていると明確にわかる。

これを作るためには全員がこのタスクについて理解できている必要がある。
そしてそれが出来ていれば作業を分担したり交代したりすることが出来る。

 

これを怠ると既にシステムや技術を理解している人はどんどん進捗が出るけど、新しく入った人や経験の浅い人は進捗が出せなかったり出来ても品質が悪くなったりして結果として悪いものが出来上がるのだと思った。

 

ではなぜプランニングで細かく見ないようになるかを考えると、わかってる人にとっては作業を細かくする作業は無駄に感じられるから。
上記のタスクの1~4はわかってる人にとっては自明でわざわざ分解して書く必要などないしそれで途切れるような作業進捗にはならない。

そういう人はわからない人のために時間を取られて自分の作業効率を下げられていると感じるし、本人単体は成果を出しているから声が大きい人ポジションにいることが多くプランニングを無駄な時間と切り捨てていってた。

出来る人はそれでも困らないけど新しく入ってきた人や新卒や若手はタスクが終わらず疲弊したり、それだけならまだしもレビューで大幅な変更が入って無駄が発生したりする(レビュー工数がかさむというのは出来る人にとっても無駄だしそれを削減できるだけでも効果は十分あると個人的には思う)

 

結果としてどれだけスクラムをやろうとしてもうまくいかないし、出来る人にとってはむしろ自分の生産性を落とすものとして嫌悪する方向に向くだろうというのが自分の考え。

 

上記を含めてスクラムのメリットを享受するためには結局のところ、成果を出す主体が「個人」ではなく「チーム」だということを理解するのが必要なことだと改めて感じた。

 

 

そういえばこの記事が出た日からRSGTやってますね。
毎年何かしらの都合が合わなくて行けてないので、来年こそは行けたらいいなぁ。