プロセスのムダを取る3つの方法
前の記事(救いにならないアジャイル、救いになるアジャイル)で「プロセスのムダ取りをしないプロセス改善はありえません」と書いたので、プロセスのムダをなくす方法をまとめておきます。
作業のムダを取る
作業のムダが生まれるのは、必要のない作業をするからです。
リーンの引き取り([#agile] 「リーン開発の現場」を読んで その1 - 引き取り的な仕組み -)のように必要に応じて実施することで、ムダがなくなります。まずは、その作業がなぜ必要か、何時までに必要か、を明確にします。
メトリクスもGQMのようにゴールがあるから収集するのですから([#TiDD] チケット駆動開発はプロセスを軽量化する)必要のないメトリクスを収集する必要はありません。
計画のムダを取る
計画する際に生まれるムダは「ついで」(序で)です。冷蔵庫で人参が干涸びるのは、たくさん買った方が安いからとまとめ買いするからです。余った人参はシチューをすればさばけるかもしれませんが、余分に作った機能をムダにしないようにプロセスを変える事はないでしょう。
アジャイル開発のYAGNI(You Aren't Going to Need It:今必要のあることだけをやれ)という考え方に従えば、計画のムダをなくせるでしょう(アジャイル開発の生産性の高さを考える)。
時間のムダを取る
意外としている人が少ないのは、逆線表です。多くの方が計画を前から引こうとしますが、後ろから計画を立てていくとムダが無くせます。
その理由の一つは、上に書いた引き取り的な仕組みでムダな作業が省けます(アジャイルとプルシステム)。
もう一つはスケジュールの平準化と最適化です。瓶に粒状のものを入れるとき、トントンとすると、粒が詰まってより多く入れる事ができます。もし、粒に大小があるなら、ナップザック問題の様に大きな粒から入れるとうまくいきます([#agileto2012] 『チェンジ!』の考え方 ~マネしやんと!~)。
ソフトウェア開発では一般に下流ほど工数の変動が少なく、工夫が難しくなります。そこで下流から線を引くと隙間なくスケジュールできまし、避けられない現実も明確になります。
ありがちな失敗パターンは、ウォーターフォールの典型的な計画を立てる事です。少人数で始めると増員時の負担によるムダが大きくなりますし、ついつい後工程で人を増やせば何とかなるだろうと思ってしまい、ズルズルと計画が遅れがちです。
予算取り時は残業なしで見積もったはずが、実施時にはどう考えても無理な状況もあり得ます。その際に後ろから線を引いて考えると、厳しい現実も平準化でき、チームで戦う事ができます(元気が出るチケット駆動開発 - 補完型TiDDの経験 - @XP祭り関西2010)。
おわりに
ムダなプロセスを生む人に悪気はありません。その人の思う普通を実践しているだけです。でも、プロジェクトによって開発対象やメンバー、スケージュールなど、様々な制約が異なるので、普通のプロジェクトはめったにありません。
まずは、プロセスがどのような構造になっているか、なぜ、その作業が必要なのか、きちんと理解してください。その上で、プロジェクトの様々な制約にあわせられたとき、ムダのないプロセスが実現できると思います。
なお、ムダはなくすことと、乾いた雑巾を絞る事は違います(リーンを考える - 無駄と必要なアソビ -)。 リスクの低減に必要なアソビはきちんと確保して、より良いプロセスを実現してください(オプションを維持するためのアソビ - CCPMのバッファを考える -)。
« 救いにならないアジャイル、救いになるアジャイル | トップページ | ベストなセカンドベスト »
「私のアジャイル」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 「任せて、任せず」「魚を与えるのではなく"釣り"を教えよ」(2021.08.16)
この記事へのコメントは終了しました。
コメント