管理パターンの考察
じゃあそれが終わると、次が管理パターンっていう章に入っていくって感じですかね。 そうですね。
管理パターンとは、なんだっけっていうところが気になるけど、あんまり書いてないんだよな。
そうですよね。パッとこの管理パターンという章のタイトルの意味とか、なぜここにこの章立てがあるかっていう意義というか、みたいなものっていうのはあんまり書かれてなくて、読んで感じ取ってくれ、みたいな感じですね。
そうですね。 少なくともなんとこの2章全体をパッといろいろ見て思うのは、問題を問おうとしているその顧客の要求とか問題の要求、目の前で起きている問題みたいなものっていうのは、止まっていてあるアクションを取れば、もういきなり解決するんだっていうよりも、日々常に動いていて、
なんなら自分たちの行動によってその問題の形式もまた変わってしまうし、外部要因によっても変わってしまう。で、それがどういうところからやってきて、どういうふうに変わっていくのかっていうことをちゃんと突き詰めたりとか、コントロールできないとうまくできないんだよっていうようなことは、なんと全体を読んで思いましたね。
うん。だからどういうところに問題を見出してどういうふうに対処していくかっていうのを決めるのが管理。まあマネジメントパターンだと思うんだよな、現状。
うん、たぶんそうだと思います。
そっちの方が最近のコスプレ。
コントロールってことは使ったけど、いやマネジメントかなって思いながら。
僕も最初はアドミンとか言っちゃったけど、いやマネジメントかなっていう気がする。
確かにセクションの扉のページ、これ57かな。見るといろんな不安定性、要素が絡み合ってその結果がどうなるかっていうのがぶりやすいよねとか、いろんなものに至るよね的な意味で不安定性って言ってると思うんですけど。
セクションの扉の最後の文読むと、最後の文じゃないな。
安定性を減らすためのマネージャーに試みる制御行動っていうような表現があるので、マネージャーがどう行動するの、周りをどう動かすのっていうところに見るサブカルチャーっていうかパターンの話だと思うんですよね。
うんうん。
ゲインさんが言った通りなんですけど、多分そういう意味で管理パターン、制御パターンって言葉が次出てくるんですけど、もうって感じ。
もうって感じ。
まあまあでもそういうニュアンスの話ですね。そうですね、ムービングターゲットみたいな話も出てくるし、ともかく何らかの理由でソフトウェアの品質や生産性は動く標的である。
その動く標的が動いてるのにそれを射抜かなきゃいけないんだって言ってるときに、マネージャーどうしていくっていう話で管理パターンとか制御モデルとか言ってると。
このところ全体的にっていうところでもあるんですけど、読んでて、ここでサイバネティクスの話が出てくるんですよね。あのさっきの最初のとこでちょっと言及した。
そうですね、サイバネティクスって話が出てきて、でその手前でフィードバックって話が出てきて。
この後後ろの方もまたいろいろ出てきますけど、システム思考みたいなそんな感じを感じられるものがたくさん出てきますね。
システム思考の実践
りんさん、本のタイトルもう一回見てみるとシステム思考って書いてあるじゃないですか。
そうですね、だから本当にここはあのシステム思考だったんだなっていうことに気づきました。読んでて。
そうですね、要素同士が相互に影響し合ってとか、でその影響っていうのが増やす減らすっていうフィードバックの仕方、フィードフォワードの仕方だったり。
時間差で来るよねー的な感じだったりとか。
なんかなんとなく自分はそこが抜け落ちた状態で読んでて、プログラマーの人の話だしシステム思考のではなくシステムをソフトウェアのシステムをどういうふうに考えるのかみたいな。
そういう感じでいくのかなってこの本手に取った時に思ってたんで、あれなんか近い話見たことある?みたいな感じを読み進めてて、あれ?思ったりしましたね。
そうだからソフトウェアシステムとかコンピューターシステムっていうよりか本当にどっちかっていうと組織の話ですもんねこれ。
そうそうそう。
っていう意味でシステムって言ってるなー的な。
そう。
管理パターンはなんか面白いところありました。集合の話触れますか?
そうですね。集合っていう言葉を使ってるけど。
集合制御モデルっていう話から始まるんですよね。
使われてるのが動く標的を打つ一般的な方法は集合の技法である。
集合制御はショットガン、もっと正確に言えば散弾銃で打つことであるっていうふうに書いてあって、どういうことなんだろうっていうふうに思いましたねいきなり。
でもなんとなく自分がそれを見てこういうことかなって思って読んだのは、たった一つ上手いやり方をするんじゃなくて、上手いと思われるやり方をたった一つだけやるんじゃなくて、
今いくつか違うアイディアを考えて、そのアイディアをいろいろ実行した方が確率が上がるから、そういうふうにやりなさいという話をしているのかなっていうふうに読みましたね。
モンテカルド法的な世界観っぽい感じがしますよね。
集合って言ってるのが、集合かっこアグリゲートって書いてあって、アグリゲーションって書いてあって、アグリゲーションって何ですか。集合が的役なのかなっていうのが。
集計とか集合?
我々で言うと一番馴染みのある役語は集役ですもんね。
そうですねそうですね。
集める的なニュアンスが感じられる。
集合対集団。
集合制御はショットガン、もっと正確に言えば散乱銃で撃つことであるっていうのが、散乱銃はなんかわかるんですよね。
そうそうそう。
ショットガンが最悪ではないが最高のたとえではないっていうこの感覚が伝わらないんだよな。ショットガンじゃなかったら何なんだろう。
ライフルが出てきたか。
出てきましたけど見落としてるかもしれない。
だからこれだって言って本当に一点集中でやるっていうよりかは、ある程度広く打ってフィードバックを得て次に進むみたいな、すごいアジャイルっぽい話をしてるのかなっていうニュアンスで。
なるほど。だから弾を撃つ回数も多いし、撃つにもいろんなフィードバック、可能性だったりとか情報が増えるようにアクションをしようみたいな。
そうですね。
確かに。
ただですね、ショットガンは日本語では散乱銃と訳されますって言われてしまったの。
そうそうそう。
でも違いますよね。銃の知識が、任天堂60の007しか僕ないんですけど。
俺の持ってるショットガンのイメージというか知識だと、大体弾がばらけて全部当たらないと大ダメージにならなくて、数当たりするとちょっとしかダメージが出ないみたいな、そんなイメージしかないですね。
あーマジか。ショットガンなんか攻撃力高いイメージがあったんだよね。
多分至近距離で撃つと散らばるから、いろんなところに当たってダメージがでかい。
離れるとそもそも散らばっちゃうから、10個にパーンと散弾した時に、この欠片が1個しか当たらない。離れれば離れるほど。
ショットガンって近距離で強い武器っていう。
うんうんうん、確かに。
ショットガンの解説になっちゃった。
そう、なんか複数発撃ち込むイメージがあって。で散弾銃は結構、あえてなのか広めにやるから、むしろヘッドショットが成功しづらいみたいな感じがあって。
ショットガンは同じ場所に2発撃ち込めるから強いみたいな、そういう雰囲気でいたんですけど。
まあ多分そこじゃないから、いいんですけど。
ライフルの話どっかで出てきたけど、ちょっと後で思い出したら。
ひどいです。
けど集合、アグリゲーションって言ってるのは多分だいたいそんなイメージ。
イメージが伝わってこないのは難しいなって思いながら。
パターン1の組織での自然到達、パターン2の組織ではなぜ集合が一般的なのか、他のパターンにおける集合みたいな話が一応出てくるんですけど、ここ読むと理解上がるのかな。
だからデッドラインでやってたのは多分集合制御までなんでしょうね。
あれか、2つのチームを作って、片方に人を大量に突っ込んで、片方は少数制でやるみたいな。
途中でぶっ壊されましたけども。
そうですね。
4のサイン、バターンとサイバーネティックス制御モデル、ここで出てきた。
集合は散乱銃で撃つのに似ているが、フィードバック制御はライフル銃で撃つのに似ているらしいです。
フィードバック制御がライフル銃で撃つものに似てるとなると違うんだよな、さっき言ってた話と。
そうですね。
言い間違えてるか。
狙いの科学であるサイバーネティックス。
集合制御モデルっていうのをあんまりポジティブに言ってないのか。
なるほど。
じゃあ当たるだろう的な話で言ってるのか。じゃあアジャイルとか言っちゃダメだな、良くないな。
逆にライフル銃で撃つような制御モデルはここを狙いましょうっていうのを決めてから撃ってるかな。
どういうことか。
少なくともライフルっていう例えから受ける以上はそう。
結構予想しながら。
ライフル銃で撃つっていうのは一発撃ってどれぐらい外れたか、そこをまた微調整して撃つっていうことかなって思うと三弾銃とそんなに変わらないんじゃないかみたいな気持ちになるけど。
当たったところが正解ですな感じがしますよね、集合制御モデル。
確かに。
緩衝で動く組織とかは多分そうじゃないですか。今までこれでうまくいってたんだからこれ繰り返しましょう的な。
ライフルだとちゃんとフィードバック受けて二次の方向に何センチみたいなやつなのかな。
例えに引っ張られてわけにわからなくなってる気がするな。
アインバーグの例えがいまいちで読みづらい説あるのかもしかして。
もしかしてそれはあるかもしれないな。なんかライトついてますか?でも似たようなことあった気がする。
頭いいんだけどな。
だいぶ読みやすかったですけどね。ライトついてますか?まだこれに比べたら。
でもあれですね、フィードバック、なんかサイバーネティックスって言ってる話とか、人間的な側面含めてるんじゃないみたいな。
僕が言ってたのは多分この章からもそういう印象を受けてて。
制御っていうのが入力と状態と出力っていうのが制御する対象となるシステムっていう世界観で言ってて。
入力っていうのが要求とかリソースみたいな。アウトプット出力っていうのが成果物だったりその他の出力っていうふうに書いてあるんですけど。
その他の出力っていうのに開発チーム力の向上なし低下とか、ストレス、妊娠、風邪、喜び。妊娠はどういう出力なのかわからないけど。
マネジメントへの怒りとか敬意とかっていうのがソフトウェア開発プロジェクトをやった中で残った結果、出力。
ソフトウェア以外の出力として扱われるべきものっていうのにここら辺の側面も含まれてるよねー的なことが書いてあって。
妊娠、風邪、喜びみたいなのはそれを意図したかどうかによらず、プロジェクトの機関の中においてプロジェクトメンバーとかチームに対して発生した事象っていう意味だと。
そのプライベートな話とか、人体、人間、社会ボロボロみたいなものが含まれるのかっていうのが制御対象のシステムって書いてありますね。
これか、システムの挙動は状態と入力で決まる。挙動っていうのがさっき言ってた出力みたいな話になるはずなので。
だから制御、仕様ってなった時にどこに焦点当てますかって話ですかね。
状態と入力をちゃんと把握しておかないとうまくいかんぞと。
パターン、今これが0と1の時にはこうなってるけど、2になるとそこにもう一個要素が増えるってことですよね。
そうですね。
制御機構ってやつが増えている。
こっちはもうちょっと入力と状態みたいなものを見ながら、入力と特にここで言うと資源ってなってるけど、資源を追加したり、
ここで言う資源っていうのは多分人だったりとか、人を成長させるとか、そういう働きかけみたいなものも含めてっていう風に変わっていくって感じですかね。
そうすると現場の感じを見て、マネージャーがこういうことが必要なんじゃないかって言って制御をするっていう風に確かに見えますね、こうなると。
そうですね。パターン0と1が制御対象のシステムっていうものにだけ焦点当てたのに対して、そこに影響をしているもの。
っていうのにもちょっと視野を広げてみようよみたいなやつですね。
パターン2だから監修、だからなんか組織っぽい、会社っぽいなっていう感じがやっぱりするんだよな、ここら辺が。
その流れで見ていくとパターン3は、その制御機構自体への要求が増えている。
つまり制御機構に、つまりマネージャーに対して何かしら要求を出していたりすることが見られたりとか、
ソフトウェアの出力、出力結果としてはソフトウェアだったり他の出力みたいなものを受けて、じゃあどういう手を打つかみたいな風な矢印の伸び方をしてますね。
なんですかね、ビジネス側とか顧客に対してもズイズイガンガンいっていくみたい。
会社の規模が大きくなると、中間管理職の上にいる管理職から要求が増えてくるとか、そういう風にも見えるかもしれないな。
パターン4とか5はないですね。
4とか5もないですね。というかパターン3ですらかなり薄くもないか。
管理パターンの理解
管理パターンこんな感じで、就労制御モデルとかサイバンティックス制御モデルとかっていうのがあって、
顧客的管理?
いう話がありますね。
ありますね。
特徴的なパターン2の誤りは制御機構とマネージャーを同一視することであるって書いてありますね。
さっきマネージャーって言ったな。
実はこれマネージャーって言ってるのがどのレベルのマネージャーかわかんないですよね。
開発チームと一緒にいるようなマネージャーよりか上の木がうるっていうのとあって、
マネージャーノットイコール制御機構っていう話ではない。
マネージャーは確かに制御機構である。しかし彼らは唯一の制御機構ではないっていうふうに書いてあるんで。
なんでさっきマネージャーって言ってたのとは特に矛盾はしない。
そうですね。
それ以外のまでよねって話。
マネージャーが唯一の制御機構であるとマネージャーが思ってしまうことは、なんか罠な気がするな。
でも先に急ぎますか。
そうですね。
管理パターンは他何か売れたいところありましたか?
特に自分はないかな。
隠月の神話の話が出てたのはここら辺でしたっけ?
ブルックスの管理モデル
隠月の神話の話が出てたのは次かな?
次か。次行きますか。
次が管理モデルを明確にするっていうところでもういきなりフレデリック・P・ブルックスの名前が出てきますね。
僕次って言ってたのはあれだった。セクション単位での次って言ってたので、そうですね。次の章で出てきますね。管理モデル明確にする。
管理モデルってシステムモデルですか?書いてあるか。
制御機構、さっき出てきた制御機構っていうのがソフトウェアプロジェクトを嫌なものとか失敗から守るには重要であって、
その制御機構っていうのは現在起こっている事態っていうのをしっかり観察していった上で、何が起きてるんだっけって観察したときに、
それってどういう意味を持ってるんだいとか、どういうことを表してるんだろうっていうのを明確に理解しなきゃいけない。
この理解っていうのをどう育んでいくか、もしくはその理解そのものっていうこと自体を制御機構のシステムモデルと呼ぶものであるっていう風にしてシステムモデルっていう言葉が出てきますね。
管理モデルはどこ行ったんだっけって。
それはどこに出たんだ。
どっちだ、いいのかな。
まあでもニアほぼほぼイコールな気するか、管理に関する制御機構のどういう風にモデル化するかリンチするかみたいな意味合いに感じたな。
まあまあでも制御機構の話ですよって感じですかね。
そうですね。
なぜ物事をしくじるのかっていう話とか、システムモデルの役割とか、暗黙的モデルとか、正しくないモデルとかっていう話が出てきますね。
この中でさっき言った人欠の神話の話が出てきますね。
そうですね。起きてる事象をどう観察するかと観察した結果にどう意味付けるかっていう話。
で、ブルックスが言ってたのはまさにそこら辺の話だよねっていう形ですね。
ここら辺が繋がってるの。
今でもブルックスが言ってた人欠の神話とか、そこら辺の話そのものをアップデートするっていうよりかは、あれが結構前に語られてて、と言ったこと言ってるけど、
あそこから時間が流れて時代が変わって、さらに発見があったりとかアップデートされたことってあるよね的なスタンスですよね。
そうですね。
あそこで語られてることは正しいけど、あれだけで全てじゃないというか十分ではない、もっと言うべきことがあるみたいな主張を展開していくためにブルックスを引いてる印象かな。
ブルックスの話でいくと、締め切りみたいなものが、納期みたいなものがやってきて、それの切迫っていうのは、それがやってくるっていうのが結局うまくいかない原因であるっていうような話をしているけど、
そうではなくて、カレンダー時間の切迫はソフトウェアプロジェクトがうまくいかなくなった理由ではなく、むしろそれが他の失敗が見つかった理由であるとみなした方が良いっていう風に言ってるので、
ブルックスが言ってる主張ってのは間違ってないけど、それ自体が原因ではなくて、もっとそこには理由があるんじゃないかっていうような深掘りをしてるって感じですかね。
82の83ぐらいのとこですね。
締め切り間際になって失敗が予定しただけであって、締め切りがあったことが原因じゃないよう的な話ですかね。
そうですね、そうですね。
テスト受けてみたから、その段階になってやっと、ちゃんと授業聞いてなかったんだって分かったみたいな。
失敗した原因は授業を聞いてなかったことであって、テストが設けられたことではないみたいな話かな。
つまりそのカレンダーの時間の切迫っていうことであれば、そいつを伸ばせばうまくいくってことになっちゃいますもんね。
じゃあ農機をあと2週間伸ばしましょうとか、1ヶ月伸ばしましょうって言ったらうまくいくかって言ったらうまくいってない状態でずっと続いてきてるんだから、カレンダー伸ばしたとって同じことがもう1回繰り返されるだけだよねっていう。
そうですね、農品とか出荷はできそうな気がしますけど、じゃあ人間の能力が上がってるかとかクオリティが高くなってるかとかっていうのは、クオリティは時間かけても上がらないっていうのが言われてるので。
そうですね。
そうじゃないよねって感じですかね。
まあ、顧客の要求が叶えようと思って作ってなかったら多分変わらないだろうしな。
そもそも要求の特定でミスってるのがあるじゃんっていうのが、それをブルックスも言ってたからあんまり言わんといてあげてって感じしますけど、銀の弾丸の方はそっちの話だったと思うんで。
あとここの話で、この後線形モデルの話になっていくんですけど、なんかこういろんなものを線形に捉えてしまうっていうのはなんか人間の特性としてあるんですかね。
今までこう来たから同じペースで行くとこうなるよねみたいな。
あるんじゃないですかねっていう気はしてるのと、なんか大きいもの見積もるのが苦手じゃんって話はありますよね。
まあ確かに。
ランニングポーカーで100使うなみたいな。
確かにな。
あそこって線形に予想しちゃうからだと思うんですよ。
基本的に正常性バイアスに近い感じがする。
倍だからとかN倍だからみたいな。
うんですね。
人間が本能的に線形モデルで物を見がちだよね。それで結構いろんな罠にはまってるでしょう的な話がありましたね。
そうですね。
この辺って、多分本が書かれて以降でいくとロングテールの話があったりとか、世の中はべき定則に従うみたいな話っていっぱい本が出たりしてて、
割と線形モデルとか正規分布とか、今までこういうものに従うってことはきっとこうなるでしょうね。
そういう考え方みたいなのがもうちょっと変わった時代なんだろうなっていうのを今の時代と本が書かれた当時の差別みたいなのがありそうだなって思ってたんですけど、
そういうことが明らかになったとしても、人間の直感とかカーネマンの言葉で言うシステムワンみたいなものとかで考えるとそんなに変わってないかもなっていうことも同時に思ったりしましたね。
なんかここの下り読んでてすごい思ったというか想起したのがダイクストラさんいるじゃないですか、構造化プログラミングの人だからこの時代よりも前の人なんですけど、
あの人が言ってたのが、手元に用意しておけばよかった、ちょっと正確な引用ができないんですけど、
プログラムの正しさをどうやって証明するか的な関心を持ってて構造化プログラミング的なことを言い出したって言い切っちゃうと危ないかもしれないですけど、
そういう文脈がある人なんですけど、構造化プログラミング、構造化されてないプログラミングっていうGoToを使って好きなところに飛び回るみたいな、
でそれってある程度コードベースがちっちゃい時はまあまあ全部読めばいいからうまくいくじゃんみたいな話とかあったりするんですけど、
なんか大規模になると必ずしもうまくいかないじゃないですか。
なんかそこら辺でスケールの違いっていうのは結構でかい問題だけど、そのスケールサイズが違うだけだからって言って過小評価しがちだよねー的な。
本当はもっとスケールが大きい、サイズ感が違う問題でもしっかりと正しいプログラミング、プログラムであるっていうのを証明する方法っていうのが必要だよねって言ったときに構造化プログラミングっていうのはそこに大して役に立つ的な話をしていて、
要するにファイルが分割していればコントローラークラスだけプロディックすればOK的な世界観だけど、構造化されてなくて全部1枚、1枚はどころか1ファイルにあると、
なんかデータベースのIO管理も、操作のアルゴリズムもここにありますだと、なんかリファクターしましたって言われたときに、これビューモアフと一緒だろうかって難しいじゃないですか。
的な問題、正しさを証明するのにあたって、その抽象と偶象を構造化して分離することによってやりやすくなるよねー的な話をしてて、
そういうのがサイズが大きくなってくると必要だよねっていう、逆に言うとサイズがちっちゃいときに通常してた、学校の授業で習ったような問題であらゆる現場のリアルに起きてる問題が対処できるかっていうとそんなことないのに、
学校で習うプログラミングがすごい洋食物ばっかり綺麗すぎるみたいな話をしてるよねー的な話をダイクストロが言ってて、そこら辺に今まで言ってたやつをあと100倍やればいいだけだからうまくいく的なモデルは、なんか似てるなーって思ってました。
大きなシステムは小さなシステムと似たようなもので、単に言うと大きいだけだっていう縮尺の作語っていうのが87ページに書いてあるんですね。
それ本当に本質だなっていう気がしていて、結局この本の中でもちょっと、どんて詐欺取りみたいになっちゃう。ちょっと先の方にあった気がするんですけど、じゃあやっぱ分割統治だよねっていう話になっていって、すべてが分割統治になるわけじゃないですか。
で、まあ多分分割統治することによって、もうちょっとスケールの問題っていうのを小さくすることが可能になるんだろうけども、今度じゃあこれ組み合わせるだけなんで、みたいなそういう単純感をした結果、その小さくしたものの今度組み合わせのパターンによって結局分割統治したと思ったらその分割したものを接合するためのコストみたいなところが
膨大に膨れ上がって、あれ結局このクラスはどこから呼ばれていて、どこに繋がっていて、誰が参照してるんだっけみたいなこととかがどんどんわからなくなってて、あれ分割統治すればうまくいくはずだったのではって叫びながら、なんていうかプロジェクトが失敗していくみたいなような気もしていて、
結局うまく構造化っていうものにいったとしても、実はその先にもまだまだスケールの罠みたいなものは潜んでるんだよなとかって思ってて、それに対してどうやったら綺麗にできるかみたいなことをまた人は悩んでいき、それをどんどん繰り返してるだけなんじゃないかなみたいな気持ちに今なしを切ってなりましたね。
全体の情報量が減ってるわけじゃないですからね。
そうそうそう。
クザスなものを分解しただけであって。
失敗の原因と線形モデル
そう。
まあでもその先継モデルで人が見がちだし、プロジェクトの、まああれですよね、進捗の予想グラフみたいなやつが右肩上がりに一直線なわけないじゃんみたいな。
そうそうそう。なんかその話も後ろにありましたね。
後ろでしたっけ、あります、ちょっと後ろか。このくだりであったな。
そうそう。
それに対してどうしていく、もしくはそれぞれのパターンにおいてどうなってるっていう話が、でも出てきてるか、あれですね、ライフル的な制御をやっていくためにどうしていくっていう話ですね。
うんうんうん。
ここどうします、なんかそんなに。
そんなに拾っても。
まあなんか望ましい出力とか求めてる結果っていうのを定義して、それに至る要素をブレスト的にやって、で関連要素を線でつなげてみてどういう影響してるかなっていうのを見ながらやっていこうよ的な感じでしたね。そこまで端折ると怒られるのかな。
まあまあ、マイセンスとかめちゃくちゃ喋ってるから。
そうですね、第6章がフィードバック効果、で正のフィードバック、不のフィードバックっていうのがあったり、第7章がソフトウェアを舵取りするっていうのがあったり、で8章が舵取りに失敗するっていう話があったりっていうのが第2部の残りのところですね。なんか6、7、8章で触れてみたいところとかありますか。
出てみたいのは、なんかすごく読んでて刺さったのは123ページ、これはソフトウェアを舵取りするっていうところの部分で、すごくいいなと思ったのがシステムの意思決定時点では次の事象を決定するのはいつでもその前の事象ではなくその事象に対する人々の反応であるっていう話があって、
プロジェクト管理の意思決定
これすごくいいなと思って、なんか一つ前に起きたことによってその次のことが引き起こされているっていうふうに捉えてしまいがちだけど、結局そっちの道に行こうとしたのって人間の意思決定だよねとか、その人々がどういうふうな反応をしたからそっちの方向に行くことになったのかっていう部分があるので、
しょうがなかったんやみたいな、そんな気持ちとかあったりしますけど、なんかこれすごくいい言葉だなと思ったりしましたね。
これ事実と評価みたいな話ですかね、問題はどういうふうに起きた結果、状態っていうのをどういうふうに解釈するか的な話ですかね。
なんかその後似たような話として、より多くのソフトウェアプロジェクトはカレンダー時間の切迫に反応する方法をマネージャーが知らなかったために失敗するっていうような話があって、つまり反応するっていうことはどういうふうな反応するだので、反応しないっていうことも一個だと思うんですけど。
結局さっきの最初のブルックスの話がカレンダーの時間がやってきたからプロジェクトは失敗したんだではなくて、そのプロジェクトを失敗しているのはマネージャーがうまく反応しなかったから失敗っていう事象にたどり着いてしまったんだみたいなことですね。
これなんかこのフレッドブルックス側のところの言い換えの方法論みたいなのはわかるんですけど、これ言い換えたからとって何が言いたいんやってちょっとなってたんですけど、どういうことなんだろうと思いました。
そうですねこれは結局その締め切りが近づいているっていうことに対して、例えばアンチパターンだけど人を追加するとかスコープを削るとか、アンチパターンって言ってたのは人を追加するですね。
だったりとか、結局締め切りを変えるとか、そういう部分に対して特に締め切りが迫ってしまったことが、締め切りが来てしまったことが大事じゃなくて、ちゃんとマネージャーが締め切りのコントロールしなかったからなので、
そのために制御するってことが大事で、制御するってことが大事ってことは、今までこの7章に来るまでに制御モデルの話があったからそういうところをちゃんとしなさいよっていう、つまりそこには本当はもうちょっと介入できる余地があるんだぞっていうことが言いたいことなのかなって気はしますね。
なるほどな、確かに。なんかあれですね、結果はコントロールできないけど行動はコントロールできる的な話にも接触してきそうだな。
で、まあ決して完全に制御できるわけではないかっていう話がその後にまた続いたりするんですけど。
でもそうですね、なんかそこのクラリリートエットその2ページ後、125ページに、受け入れるべく学ばなければならない自然の法則、制御するべく学ばなければならない人の意思決定の法則っていうようなことも書いてあって、なんかこの問題を見誤るなよ的なことではあるなっていう気はして、いいですよね。
感想が急に荒くなるんですけど、いいですよね。
いやでも結局これってどういうゲームをプレイしていて、どういうルールの中でゲームをプレイしてるのかって、変えられるルールと変えられないルールみたいなものは多分その中にあるはずでみたいな。
っていうところを知っているか知ってないかで、その後の行動だったりとかプロジェクトの整備みたいなところは大きく変わるので、こういうことに意識的であるっていうのはすごく大事だよなって気がしますね。
なんか学校とか、学校で生活していた時って高速って変えられないもんだと思ってたし、先生の言うことは基本的には正しいって思ってるしとか、つまりなんかボールが机の上を転がって落ちると同じような感覚で高速、学校のルールみたいなものっていうのはあるっていうふうに思ってたんだけど、
そこってもうちょっとコントロール可能だったりとか、解釈の余地があったりするとか、ネゴシエーションできるとか、そういうようなことって後から振り返るとそうだったなってことを思って、それを自然法則と同じように見ていたら全然もったいないというか息苦しいなって思ったりはしましたね。
なんかあれですね、フレームワークの使い方一生懸命覚えてそれに合わせないとって思ってたけど、なんかある人に会ったらフレームワークにあっちを送ってるとか言ってるみたいな、あれは書いていいルールだったのかって。
確かに、一生懸命ワークアラウンドしてると思ってたけど、いやそもそも直してよかったんだって。
あとあれですね、さっき言った感収に従って動くパターンと、なんかその上というか発展したというかその次っていうのかな、パターンとっていう差分とかもありそうですし。
カジトリ、感収の後がカジトリですもんね、問題を自分たちで主体的にコントロールしてるみたいな。あとはそうですね、見えないものと見えてるものを意識しましょう的な話とかも出てきたり。
この辺って結局、たぶん今のビジネス本とか、システム思考でもいいんですけど、本でもなんか書いてありそうなことだよなって思ったりとかしますよね。
ライトついてますか?の人ですからね。
まあそうですね、そうですね。
あと、どこだっけな、この章のようやくかどっかに、詳しくはコンサルタントの秘密を読んでくれるみたいなことが出て。いいなーって思った。
自分で本出してると、詳しくはこちら絵ができていいですね。
そうですね。あの管理パターンそんなとこですかね。
そうですね。
カジトリに失敗する。
メモで俺は悪いニュースを聞かないって書いてるけど、でも悪いニュースほど上に上がるの早いんじゃなったっけみたいなと思いながら、いや違うな。悪いニュースは早く上がるんだけど途中で書き換えられて順調ですに変わるんだって。
なんかその話もどっかであったよな。ありますよね、なんか伝わり方が。
いろんな本にあるんですけど、この本にもあったりする。
まあみんな同じことやってるってことだったりすると。
カジトリに失敗する。
あーこれか。あった。120中130ページで。
あ、違う。違った。違った。まあいいや。
そんなとこですかね。
そんなとこですかね。
