スクラム実践入門読了

スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)

同僚から借りていたスクラム実践入門をようやくのことで読了した。
長い期間借りていたのだが仕事が忙しくなったりしてあまり読んでいる時間が確保できず
このタイミングまで読み切ることが出来なかった…。

ぼくはアジャイルやスクラムに対して名前だけは聞いたことある
なんとなくこんな感じでしょ？程度でしか知らないのだけども
mixiやGMOペパボ、DeNAなどの事例集が乗っていたこと、ちょうど開発中期〜末期にかけて読んでいたこともあり
比較的今携わっているプロジェクトで発生している事例などと照らし合わせることが出来たので理解しやすかった。

本書の前半は専門用語が多く実際に行ってみないとわからない(単語の持つイメージがぼんやりとしてしまっている)が
後半の各社実例が非常にわかりやすかった。
実例であるためイメージしやすかったのだろうと思う。
逆にアジャイルやスクラムについてある程度知識がある人にとっては恐らく物足りないものになるだろうとも思う。

この本を読むちょっと前から思っていたことなのだけどもプロジェクトで問題になるのには以下の4点のうちどれかが当てはまるのだと思う。

• 見える化
  • 問題の可視化が適切に行えていない、もしくは担当者以外に見える化出来ていないケース。
• 共有方法
  • 問題事項や情報などの共有方法が適切でない、もしくは共有する手順になにかしらの問題があるケース。
• 属人性
  • ○○に強い開発者がいるとどうしてもその人に依存してしまう、もしくはそれらの技術の標準化が行えていないケース。
  • サーバーサイドエンジニアがフロントエンドがわからない、もしくはその逆などなど
• ステークホルダー
  • 本著を読んで初めて知った概念なのだけどもいわゆる鶴の一声というやつで上司(特に直接現場とは関わりがない幹部や社長など)の個人的意見がそのまま反映されてしまうケース。
  • サラリーマンだとこの辺No!っていいにくいしね

結局のところチームとしての改善を望む場合、
アジャイルだとかスクラムだとかというのは手法やツールにすぎず
きちんと見える化し、その情報を適切に共有、属人性を排除していき、それらをきちんと振り返るデブリーフィング的なものを実施することで
だいたいのプロジェクトやプロダクトの問題というのは解決しなくとも改善していくのだなと強く感じた。
結局のところ開発時に感じる不満の多くはこれらが起因しているように思う。
例えばこの機能を実装しろと仕様書に書いてあったがこれは本当に必要なのか？と思いつつも言われた通りに実装したらこうじゃないああじゃないという話になって最終的になくなってしまったり、別の機能を追加したことで形骸化してしまったりとか…。

ステークホルダーに関しては他の3点とはちょっと別方向のハンドリングが必要だと思う。
これはチームとしてもそうだがプロジェクトマネージメント的な側面も強いのかな。
ステークホルダーをチームの一員とするならきちんとチームメンバーとして扱うべきだと思うし(意見をいう場を設定しそれ以外の意見に関しては応相談とか)
チームの一員として含めないのであればきちんとその意見を突っぱねる、あるいは取捨選択出来るような体制が必要なのだと思う。

よくチームとして改善したいのだけどもうまくいかない、うまく動いてくれないということを耳にしたが
これらは結局のところ見える化と共有方法そして属人性のどれか、もしくはどれもが問題を抱えているということなのだろうと思う。

KPTやPDCAのような形でこれらをきちんと回してやれば存外今抱えているチームとしての問題内容の半分くらいは解決するか、少なくとも改善するのではないかなと思っている。
今週中にこれらの話し合いを行いましょうと同僚から言われているのでその結果が出てなにかしら知見として残せるものがあれば残しておくかもしれない。