CCPMとアジャイル（その３）

しつこいですが…もう少しだけ。

道具の使い方のような流れになっていますが、
やはり『管理』の考え方な気がしますね。

改めて、私がアジャイルを始めたきっかけとなった
『エクストリームプログラム入門』
を読んでみると、

12章に「管理戦略」という章がある。
ここでは、XPの原則に従って考えをまとめています。

先日のゴールシステムコンサルティングの村上さんのセミナーと同じです！！

やはり極めた人のアプローチは同じなのだと改めて感じます。

話しを戻して、
ケント・ベックは管理として
大きく、コーチとトラッキングの必要性を説明していますが、
随所にプログラマーの邪魔をしない事という感じの説明が出てくるので、

管理＝ケント・ベックは結局のところプログラマーの邪魔をしない事
と読み取れてしまいます。

ある意味では、何もしない事が究極の管理と言えるかも…

管理として何をするかは棚上げして、
ケント・ベックが言いたいのは、
管理＝プログラマーのパフォーマンスを最大限に出す事
なのでしょうね。

となると、村上さんの解説と全く同じになります。
という事は、
私は、何十年も前に管理が何かを知っていた事になりますね…

『エクストリームプログラム入門』
の最後に、またヒントがある気がしました。

27章に「結論」という章があり、
そこで、変化に備えない事が究極の備えである
と言っています。
全てに備えようとするのは無理なので、逆説的に何も備えない。
準備する事を諦める事が完璧な備えである。という事です。

この考え方がCCPMとの大きな違いなのかもしれません。
恐らく、バッファを準備して備える事が、
しっくりこなかったのだと思います。

最後の章を覚えていた訳ではありませんが、違和感の元はここな気がします。

しかししかし、バッファだけを監視して
バッファに問題がなければ何もしない。
バッファが危険になった場合の備えをしない
という考え方を取れば、こちらも究極の備えと言えますね！

ループに入った感じですね…

CCPMとアジャイル（その２）

前回の自問

価値がある事が大前提だと管理が必要？
価値がある事を疑うと、管理は不要？

恐らく、どちらでも無いというか、
単純に価値がある、無いだけの事では無いのでしょうね。

CCPMは、やはり管理が前提な気がしますね。

そもそもなぜ管理が必要か？
管理って何？
という感じです。

アジャイルでは、やはり管理を不要とするプロセスな気がします。
ただ、要求と価値は管理していると言えるかと思います。
しかも、関係者全員で。
そして、それ以外は管理していない。

本来管理する目的は、価値創造を最大限にする事な気がします。
CCPMもここは同じだと思います。

するとやはり、何を管理するか
が問題なのでしょうか？？？

大きくは今の状況を見える化して、対処すべき事を判断する
のが管理な気がしますが、
アジャイルでは対処ではなく、価値創造に集中している気がします。
これが管理となると、対処となり、
元に戻す（正常状態にする）事に集中している気がします。

ここが大きな違和感の元な気がします。

アジャイルでは
何をするかを決めるだけなので、あまり管理している感じはしません。
だから違和感となるのかもしれません。

CCPMもスケジュールやバッファを管理しているのではなく、
バッファにより変化した状況を把握して、価値創造の為に次に何をすべきかを管理する。
とも言えそうです。

そんな事を考えていたら、
本日、偶然にも「管理とは？」の1つの答えを得ました。
これはまた次回以降で紹介するとして、

CCPMでとてもしっくりくる事が1つあります。
それは「フルキットの」考え方えす。
これはアジャイルにとても近いと思うのです。
そして、CCPMのキーとなるのもフルキットだと思っています。

リーンの安価な実験と同じく、
いまある、もしくは近い将来整う最大限のフルキットで、
何が出来るかを考えて、実践する。

という事は、
要するに道具の使い方って事なのだろうか…

まだまだ自問自答が続きます…

CCPMとアジャイル（その１）

CCPMとアジャイル
知ったのは、アジャイルが先です。

アジャイルを知ってから10年以上たってTOCを知りました。
そして、ザ・ゴールのCCPMを読んだ時は何かが違う気がしました。

なんでしょう？！
バッファという概念は分からなくは無いのですが、
「遅れていい」という感覚が違う気がしました。

あっ、間違えました。今でも違うと思っています。

クリティカルパスではなく、クリティカルチェーンという
考え方も分かりますが、何かが足りない気がしています。

知れば知るほど、
アジャイルに、とても近いようで遠い感じがしていました。

なぜでしょう？？？

何かが確実に違うのです。

先日、ゴールシステムコンサルティングさんの
CCPMセミナーを受講して、
ますますアジャイルに、とても近いようで遠い感じを受けました。
セミナーの内容が悪い訳では決してありません。
ゴールシステムコンサルティングさんとは、これまで共に戦ってきています。
セミナーの内容はとても分かり易かったので、ますます違和感が大きくなったのかも！
しれません。

なぜでしょうか？？？

ずっと考えていたのですが、違和感の根本は「管理」だと思います。
管理しようとするからバッファという考えがある気がします。

アジャイルではバッファという考え方は無いと思います。
なぜか？

恐らく、先の事まで見積もらないからだと思います。
分かる範囲で見積もるからだと思います。
しかも、分かる範囲で、確実に価値に繋がるものだけを見積もるからだと思うのです。

CCPMでは価値がある事が大前提だと思います。
アジャイルでは、価値があるかを疑い続けているのだと思います。
ここが大きな違いでしょうか？

価値がある事が大前提だと管理が必要？
価値がある事を疑うと、管理は不要？

永遠と自問自答が続きそうです…
もっともっと考えてみたいと思います。

つながる快感

”直感”に引かれて衝動買いした
野中郁次郎さん、山口一郎さん共著の『直感の経営』は予想通り面白いです。

なかなか読み進みまないので、最近はもっぱら拾い読みですが、

事例や書籍の紹介なども多くあり、

拾い読みしても面白いです。

そして、なにより今回はいくつかの驚きがあります。

それは、今まで勉強してきた事と繋がったからです。

ここで繋がる？！

という感じです。

驚きましたが、今ではジワジワと快感に変わってきています。

ナラティブ、物語（ストーリー）

アブダクション

美意識、羽生善治、茂木健一郎

ナラティブや、羽生さんにまで繋がったのは快感ですね。

しかしながら、逆の視点で見ると、

全く違う視点からアプローチしたものと自分では思っていますが、

そう、違う事はなく、遠くも無く、実は近い！　

という事でもあるかもしれません。

全ては「考える」が根底にあるので、

当たり前といえば、当たり前なのですが…

繋がった事で、更にまた深くなりそうです。

視野を広げる為に

30年もソフト開発やっていると
なかなか考えなくなります。

長くやっていると「このケースでは、これ」
という感じで、パターン化されているからです。

パターン化しないように、常に、本当に今回のケースでも「これ」？
と疑うように心がけていますが、
考えなくなるのも癖のようなもので、
常日頃は、そうそう疑いません…

じっくりじっくり考えるような難題や、新たなチャレンジなどでは
比較的考える時間を取るので、疑う事も出来ますが、
日常となるとね…

その為、実践しているのは、
複数案とクラウドです。

複数案は、他にどんな方法があるか
と考えるだけなのですが、
他の案が無いかを考えるだけでも、考えていますので、いちおう立ち止まりますね。
考えないよりは、マシですね。

はじめから、セットベース設計をする！
と力まないで、他の案が無いかを考えるようにしていると、
そのうちセットベースとして複数案をしっかり検討出来るようになります。
まずは無いかを考える事から始まる感じですね。


クラウドはニーズや反対の行動からの視点で考えますので、
これまた、考える事になりますので、
考えないよりは良い筈かと。

時間があろうと無かろうと、
今ある時間の中で、常に考える事を「癖」にしたいですね。

ソフト設計にもTOC！

昨今は、何をするにも正解を求めようとする傾向がある気がします。
ツールを使うにも正しい使い方で、正解を求めようとする。

正解とは何？
という感じですね。

ソフト開発の世界では、正解が無い事の方が多いですよね。
もっと良い設計、もっと良いコードと求めればキリがありません。

その為、目的により何かを選択していく事の繰り返しになるかと思います。

品質基準や品質目標に従い、設計コンセプトやアーキテクチャーを選択する
設計方針やコンセプトに従い、抽象化する対象を選択する
などなど

正解という言葉を使うと、
目的により、正解を選択していく、
正解を変化させていくイメージでしょうか。

そして、TOC思考ツールは
選択や目的達成に向けた考えを整理する為、再認識する為に活用出来ます。

設計などでモヤモヤする事があれば、
クラウドが活用出来ます。

UDEには品質目標とのギャップや
現状のメトリクスなどを設定すれば良いかと思います。
現状のメトリクスよりも上げたいのであれば、
現状のメトリクスの値がUDEとなりますので。

新規であれば、前バージョンや似たシステムのメトリクスや
予想される（見積もった）テスト時間や開発期間などでよくある
顧客要求（予算）と見積りとのギャップをUDEにすると、
考えが整理されると思います。

よくあるモヤモヤは、
リファクタリングする／しない
新たな手法や技術にチャレンジする／しない

かと。

それぞれのニーズを考えるだけでも
考えが整理されます。

そして、結果的に考えが視覚化されます。
ツールとして中途半端であっても、使い方が間違えていても
考えが視覚化されるので議論が可能となります。
この効果はとても大きいかと思います。
議論出来る事も収穫であり、議論した結果が収穫となる事もあるかと思います。

TOCは、正しく使えなくても、
収穫が得られる素晴らしい思考ツールですね！
ソフト開発でモヤモヤしている時にも活用してみましょう！

考えるツールTOCその2 逆の行動が視点を変える

前回は、クラウドを使った考え方を紹介しました。

その後、いくつか似たようなクラウドを書いていますが、
改めて、逆の行動を考える事の重要性に気づかされます。

行動としては単純に逆の行動を記載するだけですが、
記載した瞬間から視点を変える思考が開始されます。

更にそのニーズ（図のC）を考えるとなると、
視点を切り替えて考える必要があります。

ここでニーズが思いつかない、出てこない事も多いですが、
その場合は、視点が切り替わっていない、思考が切り替わっていない
感じがしました。

思考が切り替わると、多くの気づきが生まれます。
図として完成しなくても、気づきが得られる事も多いのだと
改めて実感します。

今やっている行動から、逆の行動を考える！
単純ですが、協力なアプローチです！


話しは少しそれますが、
ソフトウェア設計でも複数案考えるセットベース設計は、
これと少し似ている気がします。
複数案＝複数の視点
複数の視点で設計を見る（見直す）事で、新たな気づきが生まれる。

複数の視点から見る事が、検証になり、品質が向上する。
こちらも広めていきたいです。