ブログ開設一発目には日々携わっているagileの話についてつらつら書いていく。
わたしについて
- 中堅規模のSIerに所属
- サーバサイドの開発に従事
最初はagileな現場に入ると聞いて意気揚々と参画した。
しかし、参画したての頃は以前まで所属していたウォーターフォールPJと比較して劇的な変化を感じることはできなかった。
ただ、時間を経て直面している課題やチームの現状を認識できてくるとそれらに対する自発的な行動をメンバがある程度自由にできる風土、文化が当たり前に存在していることに気づいた。これはウォーターフォールPJではなかったことだったため、そこから少しずつ社会人としてチームのために自律した行動をするという意識が芽生え始めたと振り返る。
agileなFWに基づいてただやることがagileな働き方に直結するとは限らない
scrumといっても、実は自分の参画しているチームの特徴は以下のような感じである。
- プランニングは最小限(2week sprintで1h)
- タスク分解はassigneeにほぼ任せている。
- story pointの付与もplanningの時間でできるものだけやる
- user story、story point の消化数の推移などのtrackingも非積極的
これ自体は一件無計画に運用していると思いきや
チームである程度合意したいわば戦略的な措置なのである。
- planning時に計画したものでsprintが進まないことがわかりきっている（突発でくるsupport対応など）
- POCや調査系taskがほぼほぼを占めており、相対見積もりができない
- プロダクトの特性上、開発メンバが作業しているものが技術的に独立している（メンバの作業状況が互いのクリティカルパスにならない）
こういった特徴からplanningでチームメンバ全員の時間をとって、user story一つ一つに対して、やりかたや勝ち筋を丁寧に見出す作業は行っていない。
ふわっとした内容でも作業者に任せて、全体の調査をしてもらい後追いでどの程度のscopeか判断していくようにしている。
(もちろんdaily scrumではメンバの状況のsyncは常に行っている。)
大事なのはチームの抱えている状況や特徴を見極め、仲間と話し合うこと
scrum guideはいわば必修の教科書であり、全てのPJに共通的に実施して失敗しないだろう方向性を見出してくれていると思っている。
これは有用であり、まずは教科書通りに実践してみることから始めるべきなのは至極当然である。これがいわゆるagileの「守」である。
ただ、それだけをひたすらやっていくことだけで全員が満足して開発を進めていけるとは限らない。
やり方や手段には必ずメリットとデメリットが存在している。
そんな中で、メンバ内で薄々感じている
- 「これってちょっとモヤっとポイントだよな」
- 「このやり方ってうちのチームには合ってないような」
- 「やってても何も恩恵ないな」
などの声が出てくるはずである。
これらの潜在意識を表面化させていき、チームの体質改善につなげていくことが
agileの「破」になっていくのかなと思う。
私の所属するチームは厳密にscrum guideには則っていないかもしれないが、
在籍しているメンバで良いものを作り続けるためにはどのように変化、進化していくべきかは模索し、実行できているなとは思う。
最後に
東北楽天ゴールデンイーグルスの石井監督の言葉に対して、agileなチーム開発に通ずるところを感じたため引用する。
オフが野球界では大事になってきている。自分なりのオリジナル野球観、教科書を作って、大人な選手になってほしい
自分なりのagileな働き方がどういうものか、オリジナルのagile教科書をそれぞれが作りあげていくことで、素晴らしいproductを生み出していけると思う。
まあ、私は鴎党ですがね。
