やっぱりセットベースアプローチ！

改めて、複数案から絞り込む事はとても効果的であると感じます。
何が効果的かというと、以下の4点かと思います。

1)自身の考えを整理出来る
2)多角的に客観視出来る
3)セルフレビューとなる
4)後から見直す場合に理解が早い

案を検討する上で、
メリット、デメリットを明確していくのですが、
意外とやっかいなのが、デメリットを考える事です。

すんなり出てくる事もあるのですが、なかなか手強いです。

メリットを返せばデメリットとなる筈！
などと思ってはいますが、
そもそもが、解決策の1つとして考えているので、
ある意味「良い案」だとも思っているところがあるのだと思います。

なので、ちょくちょく固まります....

しかし、固まるので考える必要が出てきます。
これが重要かと思っています。
この時間は無駄ではなく、これこそ必要な時間だと思うのです。

だとすると、単純に複数案をプロセスとして定着させれば
考える時間が必然的に生まれる可能性もありますね。

ものすごく簡単そうですよね。
しかし、現実はなかなか広まらないし、定着しそうでしていないって感じです。

ですが、今は本質思考道場効果で定着する事を期待しています。
さて、どうなるでしょうか？！

議論で開発スピードを上げる！

アマゾンの策略にはまり、
「行為のデザイン思考法」
に出会い、読んでみたところ...アマゾンに感謝です！

考え方がアジャイル的であり、
リーンのセットベースやMVP的な要素も含んでいて、
開発においてやるべき事は共通していて「考える事」であると改めて感じました。

開発関連の書籍とはちょっと違う雰囲気で
とても読みやすく、さらっと読めてしまいました。
とても重要な事もさらっと読めてしまい、印象に残らないかも！？
と余計な心配をするほどです。

ちょっとだけ内容（お気に入りの表現という感じでしょうか）を紹介しますと、

「ズレの原因となるバトンタッチ型フローから時間を共有する円卓型に変える」
＞　瞬間的に、ミッション・リスク分割型から、ミッション・リスク共有型へ
＞　ウォーターフォールからアジャイルへ　の2つをイメージしました。
＞　しかし、ウォーターフォールでも円卓型は可能ですね。

「議論をしっかりしているからこそ開発スピードが上がり、製品化までの時間が短くなる」
＞　具体的な比較データは掲載されていませんが、断言されているので
＞　今後、いろいろと引用させて頂く事になると思います。

「デザインには美しさがなければいけません」
＞　この表現大好きです！

「時間軸で流れる『行為の美しさ』、
「プロダクトやサービスの底にある『考え方の美しさ』」
＞　「考え方の美しさ」大好きです！

開発プロセスも美しく！
リボンモデルで行こう！

本質思考道場と手書き

本質思考道場を始めてから、
現場への活用が能動的に進められている状況が嬉しくもあり、疑問でもあります。

なぜ現場で活用出来ているのか？！
いままでのワークショップや研修と何が違うのか？！

なぜ？？？

ずっと考えています。

もちろん、参加者のモチベーションなどもあるとは思いますが、
それだけでは無い気がしています。

最近は、手書きの時間、考える時間
この2つを提供している事の効果かと思いはじめています。

ワークショップなどに参加しても
ぎちぎちのタイムスケジュールで、意外と考える時間は無い。
ある程度の時間で、打ち切られてしまい、
手書きで何度も作図するとか、書き直すなどのワークショップも意外と無い。

といった事がその理由です。

こう考えると、
何度も書き直すあたりは、A3プロセスのようですね。
本質思考道場そのものが、A3プロセスのようになっているのかもしれません。

そんな事を考えていたら、
最近、「モーニングページ」というものを発見しました。
手書きが重要だとの事ですので、
書籍などでもっと調べてみようと思っています。

A3の不思議

何かとA3を書くようになりましたが、
と、同時にA3を書いてもらう事も多くなりました。

A3って本当に不思議です。

書いてもらうと、
まさしくプロセスだと感じます。
「トヨタ式A3プロセスで仕事改革ーA3用紙1枚で人を育て、組織を動かす」

のように、まだまだうまくはいきませんが、
それでも、定期的に共有、更新（書き直し？）していく事で、
書いている人はとにかく考える。
書かせる私も同じく考えるので、
お互いに、同じゴールに向かって右往左往しているのが実感出来ます。
この右往左往する事が大事で、これがお互いの成長に繋がるのだと感じます。


一方、A3を書く機会が増えたのですが、
徐々に書き出すまでの時間が長くなっている気がします。

A3を作成し始めた当初は、あまり時間をかけずに作成していた気がするのですが、
最近は、最初というか書こうと決めてから数日は必ず固まります。

なんとなくですが、
作成したA3が増えると、過去に作成したA3を見る機会も多くなるので、
現状では、ぼんやりとした改善点が頭にあり、
モヤモヤした状態でA3作成に入るので、時間が掛かっている気がします。

恐らく、A3にすると悪い点が早期に発見可能で、たとえメンターがいなくとも
ある程度は自身で気づく事が可能なのではないかと思っています。

などなど、モヤモヤは晴れませんが、
想像以上の効果がA3にはあると感じる今日この頃です。

価値共創A3

ソフトウェア開発者は、基本的に受け身である
という仮定から

プロジェクト毎に価値共創A3を作成する
というアイディアが生まれました。

何が価値となるか、何が無駄となるかを
プロジェクトの最初から最後まで自身に問い続ける為のA3

プロジェクトを管理するのではなく、価値を管理する
というイメージで、A3プロセスを通じて、A3を作成していく。

CCPMの余計なところを管理せずに、集中すべきところを管理する。
というコンセプトにも合致していて、
集中すべきところを「価値」として管理する。

実際のところソフトウェア開発では認識の違いが大きな問題となる為、
作業の進捗管理よりも、価値などを管理する方がより効率的になるかもしれませんね。

ただ、価値をどう管理するかはかなり難しいですが....
A3として作成する事で、他者が活用可能となり、
更に、良いA3が作成されていく。

課題はさておき、こうなると良い事ずくめですね！

やっぱりやってみようかなぁ

受託開発のサガ？！ソフトウェア開発のサガ？！

最近、トラブル続きで、
その原因を対立解消図や因果関係図を使って分析しています。

分析の結果、
「受け身だった」
「早く終わらせたいという気持ちから自分勝手なゴール設定をした」
という根本原因が見えてきました。

「ソフトを作っていたい」、「動くものが作りたい」、「早く動かしたい！」
といった”サガ”が、その行動を引き起こす！

という分析結果です。

これってプロフェッショナルのやる事？？？
これも「不確実性の非耐性」と言っていいのか？？？
という感じですが、
この”性（さが）”も分からなくは無いです。

ここで、1つの疑問が。
これは、受託開発だからそうなるのか、
それとも、メーカーやツールなどの
製品開発に関わるソフトウェア開発技術者全般に言える事なのか？！

組込み系の製品ソフトウェア開発では、
ハードなどの仕様に合わせて作り込む事が多いと思います。
この場合は、仕様提示者が別にいる事になり、
受託開発と似た状況でもあるかと想像しています。

ツール開発などでも同様に仕様提示者がいる場合は似た状況といえるかもしれません。

大きくは、システムや製品としての上流工程に如何に関わるか、
というより、プロとしてどのように関わるか
といった「関わり方」の問題なのかもしれません。

いずれにしても、プロとしての性（さが）を持つような革命？
が必要なのかもしれないと思う今日この頃です。

「和」とアジャイル

ある人からの宿題で「タレント」の時代　読みました。
http://www.amazon.co.jp/dp/4062883031

読み終わって

「和」は、まさしくアジャイルだ！

最後に「和」について記載されていた事もあり、
「和」が強く印象に残っています。
もちろん、人材の考え方、知識労働の考え方、価値の捉え方、ハタラキ
についても、もうその通り!

印象が強い理由のもう1つは、
トヨタのリーン、スクラム同様に
アジャイルも日本発の可能性が多いにあった！
って感じたからです。

それが出来なかったのは、
「堕落した和」「甘えの和」「無責任な和」
という事なのでしょう。

とてもとても悔しい感じです。
とてもとても残念です。

と、後悔しがっていても始まらないので、
日本人の強み「和」を発信していきたいですね！

「和」＝全員が一丸となってそれぞれ自分ができるレベルで努力する

これは、無限大の可能性があると思っています。

1+1＝∞＝「和」

だとも思うのです。

今は、興奮してまとまらないので、

冷静に、「和」についての発信の仕方を考えていこうと思います！

本質思考道場が本になりました！

今年度から始めた本質思考道場が本になりました！
トヨタ式Ａ３プロセスで製品開発

もちろん著者は稲垣さん。
今回はA3シリーズの続編のような形での出版のようです。
前編の著者である成沢さんとの共著となっています。

実は、内容は既に知っているのですが、
書籍として手にするのが待ち遠しいです。

道場の方は、少しずつ実課題に入っています。
やはり、課題はアナロジー思考となりそうな気配。

ソフトウェア設計では、考え方の流用が有効といわれてからも、
現場では、なかなか進んでいないのが現状かと思います。
デザインパターンもなかなか浸透していないですよね。

このあたりも、アナロジー力というか、
アナロジー思考を鍛える必要があるのだと思うのですが、
まったく異なる物や事から、違う事は目についても、同じ点を見つけるのは
なかなか難しいようですね。

デザインパターンの適用も、着眼点をどこに置くかで、
適用範囲は広がる筈なのですが、なぜか浸透しない。

不思議な気がしますが、誰もそんな事教えてくれないので
当たり前のような気もします。

さて、今後アナロジー力の向上で、考え方の流用が進むまで
どのくらい掛かるでしょうか....
それとも、流用はされないのでしょうか....
いずれにしても、楽しみです！

何をキャッチアップするか

ソフトウェア開発のマネージメントで
何をキャッチアップしていますか？

利益率や進捗などでしょうか？

私は進捗などはほとんどチェックしていません。
バーンダウンチャートなども、たまには見ますが、
あまり当てにしていません。

現状では、ほとんどの開発がトラッキングシステムを使っています。
そのチケットの更新情報は全てメールで来るようにはなっていますが、
中身を見る事はほとんどなく、なんとなく気になったものだけ見ています。

という感じで、
なんとなく、メンバの様子をみている

というのが表現としてはしっくりくる気がします。

そこからアラートをキャッチアップしているつもりでした。

しかし、最近トラブルが続出！

キャッチアップ出来ていなかった！
と反省したのですが、

最近、どうも、そうでは無い気がしてきました。

キャッチアップしてたけど、何もしなかった
という表現が正しい気がします。

ちょっと話を戻して、
では、いったい何をキャッチアップしているのでしょうか？

やはり、各メンバの態度というか、必死度というか、悲壮感
といったところでしょうか。

どんな数値よりも、現場の雰囲気が最も分かり易い気がしています。

ですが、何をキャッチアップしているかはうまく説明出来ませんね....

SWEST17

SWEST17参加しました！

参加する度に、すごいワークショップだと思います。
これだけの多様な人が真剣に議論出来る場は、そうそうないですよね。

そして、
会社も立場も違うのに、議論のネタが尽きない事にも毎度驚きます。

なんといっても、
議論する事で得る事がたくさんあります。
失う事は何もありません。


開発現場でも、もっと議論が必要だと感じます。
その為に、あれこれ　もがいていますが、
なかなか難しいですね。

ソフトウェアは、創る”もの”が決まって、どう造るかを決めれば、
あとは早いと思うのです。
なので、創るもの　と　どう造る
を議論しまくる必要があると思うのです。

ですが、現状は、なぜか可能な限り早く造る作業に入りたがる。
まさしく不確実性の非耐性ですよね....

その解消に向けて、悩み続ける日々です....

問題を解決しようとするな！

問題を解決しようと思うなら、
問題を解決しようと思わない事！

本質思考道場でお世話になっている、稲垣さんの言葉ですが
最近、これを実感する事が多いです。

この言葉の意味は、

問題を解決しようとすると、
問題を深堀しているつもりでも、ついつい対策についての話になってしまう。
ある前提（対策）ありきで、問題を深堀している。
という現象に陥ります。

これ、なかなか気づかないんですよね。

その為、問題の本質を掴む為に、
思考が解決策に行かないような工夫が必要となってきます。

頭では分かっていても、
なかなか行動には現れませんよね。


最近、工夫の1つとして、
事ある毎に対立解消図を書いているのですが、
対立解消図を書くと、ことごとく解決しようとしている自分に気づき、
「あーまただぁ....」と打ちひしがれています。

なかなか行動が伴いません。

ですが、対立解消図を書けば書くほど、なんだか楽しくなってきます。
なぜでしょう？

問題が明確になり、すっきりする？
いや、どちらかというと、対立が明確になる事で、すっきりするのかもしれません。

対策を立案し、実施しないと意味無いんですけどね！
とてもすっきりするんです！！

開発と意思

開発には技術はもちろん必要ですが、
各関係者の意思も重要な要素のひとつだと感じる事が多くあります。

お客に喜ばれるものを創る
価値のあるものを創る

といった「創るもの」に対する思いから、

期限内に終わらせる
挑戦する

などの、プロジェクトに対する思いや
個人的な思い

などなど

様々な思いがあると思います。

当たり前ですが、
これら、全てがとても重要な気がしています。

ですが、ソフトウェアの受託開発では、
これらの「思い」を無くしてしまう事も多々ある気がしています。

なぜでしょうか？

単純に「思い」を共有する機会が無いのだとは思うのですが....

いつ、どのように共有するのかは、答えが一つでは無い気がします。

インセプションデッキもその1つの手段であると思い、
取り組んではいますが、
まだまだ足りていない感じがします。

セットベースアプローチとコンセプト

リーンのセットベース開発を始めるにあたり、
すぐに出来る事

1)複数案を考える
2)複数案から選択する

だと思っていましたが、
意外と複数案をどう考えるか
が難しいようですね。

そこで、以下のように考えてみました。

すぐに出来る事として、

1)現状の設計案、構造案の一番良いところ（拘った点や、アピール点）
2)現状の設計案、構造案のメリット
3)現状の設計案、構造案のデメリット
4)なぜ、そのデメリットを受け入れたか、回避方法はあるか
5)一番実現したかった事
6)これだけは避けたい事
7)いま、いちばん気持ち悪い点、事

これは、先月記載した「簡単な？7つの質問」
と同じです。

以上のステップで
新たな案が生まれる可能性が高まると思ったのですが....

そもそもの設計コンセプトが固まっていないと
メリット、デメリットさえもブレてくる事がわかりました

改めて、コンセプトの重要さを実感しました。

と、いう事で、コンセプトをどう決めるかを考える必要がありそうです。

手書きと開発

本質思考道場を開始して、手書きの機会が増えました。

道場では紙に手書き。
1日中、手書き。
こんな時間がとても貴重な気がしています。

最後には、手書きで作成した資料を提出するので、
参加者の資料を見るのもとても楽しいです。


手書きするだけで、いろいろな感覚が研ぎ澄まされる感じがしています。
配置や大きさ、みなそれぞれです。
決して、同じものはありません。

ですが、みな結果は同じです。

開発ととても良く似ていますね。

設計や、プログラムコードは、各々異なりますが、
結果は全て同じになります。

ある意味セットベース的なアプローチとも言えるでしょうか！？
他人の手書きした資料を見るだけで
セットベースアプローチとなるかもしれませんね。


いやぁぁぁ、しかし、つくづく漢字が書けないですね.....

簡単な？7つの質問

先日、ロボコンの設計をレビューする為に
以下の7つの質問をしてみました。

1)この設計（モデル）の一番良いところ（拘った点や、アピール点）
2)この設計（モデル）のメリット
3)この設計（モデル）デメリット
4)なぜ、そのデメリットを受け入れたか、回避方法はあるか
5)一番実現したかった事
6)これだけは避けたい事
7)いま、いちばん気持ち悪い点、事

この質問は、セットベース思考、セットベースアプローチとして、
「どのように考えていくのが良いのか」
を考えていた中で、
今回のレビュー依頼を受けて、直観的に生まれたものです。


回答するまでには、けっこう悩んだようですが、
その回答を見た感じでは、
そこそこ考えを整理出来るかも！？
って感じました。

昨年から、
インセプションデッキを使い始めていますが、
その設計版みたいな感じでしょうか。

インセプションデッキも各チーム毎にカスタムされてきて
定着しつつあるように感じています。
設計版もここから進化出来たら面白そう！
もちろん、セットベースに繋がるアプローチとして。

セットベース開発アプローチも少し更新しました。

UDEも美しく！？

私はマコネルの「アートな」という表現が大好きになり、
開発プロセスもリボンのように美しく！アートに
というコンセプトで作成しました。

最近、プライベートでアートとの接点があった事もあり、
ぼんやりと、設計とアートの共通点が何かを考えてみました。
といっても私はアーティストでは無いので、
アートは私の勝手なイメージですが....

じっくり考え抜く、追及する、集中する、変換する
なんどもやり直す

といった感じで、
大きくは表現の方法が違うだけかとも思います。

いっぽう、表現方法はもちろん違いますが、
その他の違いは、

1つ1つに命を吹き込む
じっくり思いを込める

など、どの作品にも圧倒されるようなパワーを感じる事が多いので、
何かが込められているのでは　
と感じます。

設計も、最適設計を考える上では、
何が最適かを追求する必要があり、
設計でも、同じように思いがこもっている　とは思いますが、

その設計を見て？　パワーを感じる事はあまり無い気がします。



話は変わって、
本日、今年から始めた「本質思考道場」にて、
間違ったUDE（ウーディー）を修正する100本ノックに挑戦しました。

しかし、どうしても、問題点を否定形で表現してしまい、かなり苦戦しています。
100本などとても無理！
8本でダウン...って感じでした。

しかし、これも考えてみれば、
美しい表現に変える！

って考えると、自由な変換へのチャレンジ精神が湧きあがる気がします。

美しさへの追及というだけで、ワクワクするのですが、
これは私だけですかね.....

言葉のダシの取り方

先週の新聞で
「言葉のダシのとりかた」　という詩が紹介されていました。

これは、「星の王子さま」のサンテグジュペリの
以下の名言と共に紹介されていました。

完璧が達せられるのは、付け加えるものが何もなくなった時ではなく
削るものが何もなくなった時である


昨今のソフトウェアにおいても
付け加えるものもが、次々と増え、削る事は一切していないように感じます。

その影響か、開発に関する様々な表現や言葉も肥満化している気がします。


詩の中で、

「言葉が透きとおってくるまで削る」

という表現があり、背中がゾクっとしました。


透きとおるまで、言葉を吟味していきたいですね。

MVPと特許

リーンのMVPの考え方に感動し、
自分なりの理解で独自に推進してきました。

推進すればするほど、MVPの考え方はすばらしく、
現状のソフトウェア開発業界には必須な事でもあると感じるようになりました。

と同時に、
トヨタのカンバン方式に通じるものがあるとも、強く感じるようになり、
カンバン方式と同じような特許に出来ないかと考えるようになりました。

いろいろ悩み、弁理士さんとも相談しながら
どんな形になるのか、はたまた特許となるのか
などなど、模索してきました。

それが今月なんとか出願まで辿り着き、いちおう形になりました。

今後は、これをどのように広めていくのか
どうしたら、広められるのか
などなど

更なる課題が盛り沢山です。
が、そんな課題を楽しみながら解決というより、
何かの形にしていければなぁ
と思っています。

愛せば見える！？

先日(2015/4/8)の朝日新聞に
「愛さないと見えないモノ　というのがあるんじゃないですか」

という記事がありました。

内容は、研究の話で、
学べば出来る客観的なものではなく
愛のまなざしがあってはじめて見えてくるものがある
愛が無ければ、見えるはずのものも見逃してしまう

と。

ソフトウェア開発は見えないものばかり

ソフトウェア開発でも愛のまなざしで見つめると
見えてくる不具合があったりして！？

複雑な製品も愛があれば、
見えてくるアーキテクチャーがあったりして！


TOCの開発者ゴールドラット博士の4つの信念の1つに

「人はもともと善良である」

とあります。

これも愛に通ずるものかと思います。
愛のまなざしでは、善良な部分が見えるのだろうと思います。


これまでは、開発に必要なモノの大きな要素の1つは
「興味」だと思っていましたが、

この記事を読んで、
見えないモノが多いソフトウェア開発において、
最も必要なものは「愛」ですね！

美しい設計、美しいコード

みなさんは、
美しい設計となった！
美しいコードが書けた！

といった時に、
どのような見せる化や共有をしているでしょうか？

もしくは、美しい設計、コードが自己満足　or　他の技術者も美しいと感じるか
といった議論などしているでしょうか？

と、いうのも、
美しい設計やコードって、日の目を見ないと思いませんか？

それって、なぜでしょうね？！

ソフトウェア開発において、
美しい設計やコードは、もっとクローズアップされて良い筈だと思うのですが....

まぁ、その原因の一つは、「美しい」の基準が無いからですよね。

基準としては、
ソフトウェアメトリクスだと複雑度は、ひとつの基準と成り得るでしょうか？！

「美しい」という基準作りや、
構造と品質の因果関係など、2015年度も、いろいろと考えて行きたいと思います！

Menlo

またまた「リーン製品開発方式」から

8章の事例5で
紹介されているメンロ・イノベーション

すごいです！！
まさしく目指すところって感じです。


そしてそして、翻訳者の稲垣さんとの交流で
メンロに関する情報をGet！

それがまた、すごいです！！
とにかくすごいです！！

我々もMVPサービスとして、こんな事例がありますが、
メンロのハイテク人類学者は、
このような事を極めた技術者なのだと想像出来ます。

更には、XPのプラクティスもほとんど実践しているようです。

と、いう事で、
新たな目標が出来ましたね。
メンロを超えるチーム、更には組織を作る！

やったるでぇ～

設計コンセプトを共有しよう！

設計コンセプトを共有しよう！

という事で、
実際に記載したコンセプトマニュアルを参考に
何を共有するのかをまとめてみました。

ここにも複数案が登場します。
結果、セットベース開発にも関係してきます。

複数案のメリット、デメリット比較は
インセプションデッキのやらない事リストにも似ていると感じています。

「やる事」という視点と
「やらない事」という視点での
クロスチェックであり、同時にチームの認識が明確になる。

ですが、なかなか「やらない事」視点って難しいですよね。
複数案の方が比較的容易かと思うのですが.....

セットベース開発へのいざない

セットベース開発へのとっかかりとして
複数案を検討する事から始めては如何でしょうか！？

って事で、
セットベース開発アプローチ
としてまとめてみました。

複数案検討している時間が無い
という場合もあるかとは思いますが、

初期段階でどれだけ検討出来るかが
後々のスピードアップに繋がります。

また、レビューも効率的に作用します。

時間も不確実性の非耐性
により、上流工程での工面が難しいのだと思いますが、

ゴールに向けて、今、何にいそしむべきなのか
という本質思考、目的意識は
常に持っていたいですね。

意識も、1人だと難しいので、チームで補いながら。
がベストでしょうか。

セットベース開発と品質データと見えない力

リーン製品開発方式
先日の人間ドックで、やっとこ全て読み終わりました。

前半には、衝撃的な事ばズバズバと書かれていて
とても爽快です。

改めて、ソフトウェア開発においては、
セットベース開発と
品質をデータで示す事と
チームワークや熱意のような見えない力を成長させる事
が
これまで、おろそかにされてきた気がします。

見えない力については、
序章のヘンリーフォードと豊田喜一郎の比較はとても印象的で、
共に学習し成長する意識が、全てを解決に導いてくれる気がしました。

ですが、この意識改革が最も難しい点かもしれません。

セットベース開発については既に取り組んでいますが、
その成果が残せず、模索中です。

セットベースとしての試作はもちろんの事、
複数の設計案、実装案を考える事も、
セットベースの1つとして少しずつ広めています。

これが、最適設計、最適実装を見つける事に繋がる筈ですし、
最適を模索する事が品質向上になる筈ですので。

しかし、複数案についても
何をどのように検討したのかが残せていません...

ここ数年、どのように残すかを検討中で、

現状では、セットベース開発にて
設計技術として解決した課題を一般化し、
品質データと共にドキュメント化したい！

という野望に成長しています。

設計と紐づけした品質データを残す方法については
まったく何も思いつきもしませんが、
とにかく考えてみたいと思います。

プロセス VS チームワークと熱意

2015年一発目も、もちろん「リーン製品開発方式」 からです。

あと最後の8章を残すのみとなりました。
以下が、一番のお気に入りの言葉となりそうです。

「従来の開発プロセスの考え方は膨大なムダを生む。
　プロセスをやめて、代わりにチームワークと熱意を入れると
　直ちに劇的な改善効果を生み出す。」

「従来の」がポイントでしょうか。
前回の通り、ケースバイケースで考えられていれば
プロセスも効果がある　という事かと思います。

最近、チームワークや熱意と品質、生産性には
相関関係があると感じる事が多くなりました。

そして、従来の？プロセスの最大の欠点は
チームに決断させない事ではないかと感じています。

チームで決めた事は
能動的な行動になり易いと思います。
しかし、プロセスとして決められたアクションは
なかなか能動的になり難いのかと思うのです。

逆に、プロセスもチーム内で、目的達成の手段として必要という決断をすれば、
共通認識となり、能動的になるのかと。

「リーン製品開発方式」にも、
具体的な方法の1つとして、プロセスから解放する
といった記載がありましたが、
何かと制約が多いと、熱意があっても徐々に失われますよね。
そうなると、受け身になり、
決断もしなくなるのかと思います。

品質においてもチームで目指す品質や、
その品質を確保する具体的な手段を決める（決断する）事で
能動的になり、達成する事が可能になる気がします。

プロジェクト管理においても、
マネージメントすべきはチームワークや熱意なのかもしれませんね。

本来、プロジェクトが成功すれば
どんなやり方でも良い筈ですから。

まぁ、ソフト開発だと、
それだけ管理しても成果物としてどの程度完成しているのか
などの進捗判断が出来ないので、
そうなっていないのでしょうけど。

そうなると、やはり動くソフトが見える状態を
可能な限り早く作って
チームワークや熱意のマネージメントに注力すべきな気がしますね。