Book Review KAIZEN JOURNEY

本書について

システム開発におけるアジャイルソフトウェア開発について、ストーリー形式でまとめられた一冊
実話を基に構成されているため、実際の現場で起こりがちな出来事とその対策を、個性的な登場人物に感情移入しながら学ぶことができます。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

自身の経験から

私は、これまで10年ほどソフトウェア開発のプロジェクトマネジメントを行なってきました。ただ、本書のストーリーのように、アジャイルなプロジェクトマネジメントの経験は少なく、いわゆるウォーターフォール型とプロジェクト計画書に記述することが殆どでした。

しかし、ウォーターフォールであっても実際には定義されたプロセスの通りに恙無く進行することばかりではなく、常に現状を把握し、限られた期間の中で、様々な要求事項と課題に優先順位をつけ日々のアクションプランを立てていく活動を繰り返してきました。

つまり、本書に登場するプロダクトバックログ、スプリントバックログというような名称こそ利用していませんが、本質的には同様の活動を行っていたのだと感じます。

ウォーターフォール型との違い？

しばしば、ウォーターフォール型とアジャイルは比較されますが、アジャイルは形容詞的な表現であるので同列に比較するものではないのかもしれません。その上で、いわゆるアジャイル的なシステム開発の特徴はなんであるのか？これまでのウォーターフォール型のプロセスとは異なり、留意することはなんなのかを考えてみました。

主には体制面、時間軸の差異が大きなところかと感じます。
ウォーターフォール型の体制は比較的、階層的であり計画の見直しの間隔も一定程度の長さがあります。

一方でアジャイル型はチーム制もしくはネットワーク型の組織で
小回りよく計画の見直しを短期間内に行う。
XPやデイリースクラムがこれに該当するものであり、
実現するための前提となるチーム作りのためのツールががインセプションデッキ、１０の問い、星取表等なのかと思います。

また、ディシプリンドアジャイルデリバリーによれば
ウォーターフォール型の欠点として、要件定義を初期段階で確定することが非現実的であることが述べられています。
これは、まったくその通りであり昨今の変化のスピードが早いビジネス環境においては、当然のことなのでしょう。

アジャイルは銀の弾丸か

それではウォーターフォール型ではなくアジャイルだと宣言すれば、変化していく要件に柔軟に対応できるのか。
後からでも変えられるからと要件定義をおざなりに行なってよいのか。
いずれもNoであると本書のストーリーを読むと理解できます。（この誤解から発生する衝突についてもエピソードとして登場します）

「このように決めておけば大丈夫」という計画を真摯に疑うということが、この思想の源流なのではないかと感じました。

まとめ

アジャイルなシステム開発は、参画するメンバー全員で誤謬や齟齬、計画の不確実性のリスクを受容した上で、時に混沌とすることもチームとしてポジティブに対応していこうというものなのだと思います。

今回はアジャイルにおける「価値観」を中心のまとめとなりました。
具体的な手法については、今後の実際のプロジェクトの中で実証、習得していきたいと思います。

詳しい方はぜひご意見をいただければ幸いです。