2013年11月5日火曜日

アキレス最後の戦い「アジャイル/スクラムvsTOC/CCPM」

最近twitterやFacebookをみていると、CCPMとアジャイルについて議論しているのを見かけますが、自分の書いている物を引用しているものもあるのでTOC/CCPMについて自分のやってきたことと、アジャイルについて自分が思うことだらだら書いてみます。乱文失礼

今の会社に入った2002年からCCPMのインプリメントを10年やってきました。海外の方から色々教えてもらって、現場で指導してきたのですが、結構大変でした。CCPMの計画の立て方は入念に教わったのですが、私の行く大規模開発環境だと、計画を立てているのは1ヶ月、開発期間は1年以上、コンサル契約も1年以上、計画しているとき以外の長い期間どうするのかは手探りでやらざるを得ませんでした。
そうしているとバッファが赤になったり、黒になったりして、どうすればいいのだ!!となるので大変でした。海外の書籍も色々見ましたが、海外の事例は期間の短い物が多く、実行段階で参考になる物が少ない。コンサル先のワーキンググループのメンバーと一緒に考えながらやってきました。

全く別で、たまたま、XP本を読み、これは面白いと思いました。自分の直観に会う感じです。それがあってXP祭りなどアジャイル関係のイベントにちょこちょこ参加していました。

当時のアジャイルは計画よりも、実行段階のことがほとんどでした。そこでCCPMをやっていてのの困りごと解決にアジャイルのプラクティスを紹介し、ワーキンググループで検討して展開するという事が始まりました。朝会、タスクボード、ペアプロなどなどです。紹介したらすぐ展開できました。やはり開発者の直観にあうのでしょう。

以来色々調べていました。2004年には当時マイクソフトのDアンダーセンが「FDD towards a TLS for software engineering」でTOC/DBRとアジャイルの組み合わせをTOC-ICOで発表。AgileManagement software engineering applying TOCを出版しています。
しかし私が読む限り、この本は実務的に使えるレベルとは思えませんでした。本としては悲惨です・・・

しばらく試行錯誤が続きましたが、営業同行していたプロジェクトリーダーからあるプロジェクトが非常に短納期になり困っているとの話を聞きました。08年です。
たまたまマイクコーン「Agileな計画と見積もりづくり」の本が鞄に入っていたので、これが使えるかも、と本をあげました。この本には計画領域のアジャイルの考え方・やり方が明確にまとめられています。

先方はCCPM経験は十分あります。プロジェクトリーダーは、本を読みマイクコーンのやり方とCCPMを組み合わすことを考え、様々な人を巻き込み実践し、成功しました。
私はたいしたこと出来ませんでしたが、チームのすごさで新しいやり方を創り上げました。この方法は 2009年10月PMIでプロダクトリーダーと私で共同発表しました。

その後たまたまアジャイルのコンサルタントをご紹介頂き、一緒に共催セミナーなど事業展開をする事になりました。当時も今もアジャイルを指導することはしませんが、これで紹介先ができました。

打ち合わせでは、それぞれの位置づけを明確にする必要があります。そこで出来たのが3層モデルというものです。この考え方は今の私のCCPMインプリメントの骨格になっています。

マネジメント層:パイプラインマネジメント(複数プロジェクトの開始タイミングを計画しマネジメントする)

プロジェクト層:バッファマネジメント(単独プロジェクトのバッファをマネジメントする)

チーム層:チームマネジメント(プロジェクトファシリテーション及びアジャイル開発)

弊社のCCPMインプリメントではこの3層のPDCAサイクルをつくり連携させる仕組み作りを行います。私が書籍「CCPM標準ハンドブック」を出したのは2010年6月。ここにアジャイルのプラクティスとCCPMを組み合わせた2つの事例を載せています。

2012年にはアジャイルとCCPMの組み合わせがTOC-ICOで発表され世界にでていきました。

アジャイル開発はスクラムの登場などどんどん進化しているようです。その中でも2011年4月Dアンダーソン著「Kanban」は色々な意味で驚きました。やればできる!!

この頃から、自分の中でバイブル的本であった「リーンソフトウェア開発」に疑問を感じます。この本はTPSをソフトウェア開発に応用する考え方が書かれており何度も読み、使ってみました。しかし実務的に使ってみるとおかしいように感じます。いくつかこの周辺の本がありますがなんか更におかしい。

仕事がらTPSの本は沢山読みますし、製造の現場にいきます。「リーンソフトウェア開発」の本自体おかしいのではとこの頃から明確に思うようになりました。平準化計画していないのにカンバンが回るわけがない等々。

その後私の興味は開発上流に移ります。
私の認識は、アジャイル開発が解こうとしている問題は、「ソフトウェアの機能のうち半分以上は一度も使われていない」というつくりすぎのムダ。これをシステマチックに解決していく方法論と理解しています。使われない機能をCCPMで早くつくってもムダです。そこにメスをいれているのが共感するところ。

プロジェクト環境でTOCを活用する方法をまとめたS&Tプロジェクトテンプレートでは、この問題に対して、フルキットしてからプロジェクトを開始しろとしています。フルキットとは要求と仕様を万全に準備した状態でプロジェクトをスタートさせろという意味合いです。たしかに要求仕様がぐたぐたの状態でCCPMをやるとバッファ傾向グラフが2回転後方宙返りのような感じになりどうにもなりません。

しかし「要求と仕様を万全に準備した状態」それは簡単なことではありませ。これにたいする解決戦略がS&Tツリーには実施策が書かれていますが、まともに開発標準がある企業では既に用意されていることがほとんど。それでも出来ないので多くの人が悩んでいます。アジャイル開発はここにメスをいれているのでとても重要だと思っています。

ただしアジャイル開発にも限界があるように感じます。契約問題とかが議論されますが、そうではなく。
・足の長い金型があるなどハードウェア開発の場合適用ができない。
・要求自体が固まっていない場合

その後
リーン製品開発を知り、ここに解決策がある事を知りました。トヨタの製品開発手法であるリーン製品開発/セットベース設計。
更にリーンスタートアップにあるMVP検証による要求の検証。

以上だらだら書きました。それぞれの手法には限界や前提条件があります。しかしこうやって書いてみると、この10年それぞれあきらかに進化しています。更に10年立つと全く新しい形になるかと思うとワクワクします。

(上記一部日付が違うかもしれません。あれば指摘ください。また私がやってきたTOC/CCPMの一つの側面ですので、別の方の意見もあるのは当然です)