デスマーチプロジェクトのチーム
きんじょうひでき
第四章、ディスマーチプロジェクトの人々。なんか、ドラマのタイトルみたいですよね。
げんえい
そうですね。
きんじょうひでき
これは、政治交渉みたいなチームの外的な話から、少し内側に入っていく感じはしますね。
げんえい
そうですね。まとめとかを見ると、この章は、愛のあふれるプログラマーと団結したチーム。適正な作業環境の3つが揃っても、必ず成功するわけではないよとか。
だからといって、これらがどれか欠けていても大丈夫かって言われると、そもそもそれはプロジェクトはダメになるから、みたいなことを述べていて。
チームの団結とか、プログラマーについてとか、作業環境について話しているような章ですね。
きんじょうひでき
逆に言うと、この後に出てくるプロセスとか、そこら辺の話よりも、より土台にあるのがその人。
本当に、ソフトウェア、ハードウェア、ピープルウェアの、ピープルウェア的な話ですよね。話ですよねっていうか、そういうふうに書いてあるんですけど。
げんえい
ピープルウェアに言及もさらにしているし。
きんじょうひでき
そもそもこの言及ももちろんあるんですけど、書籍名としてじゃなくて一般名詞としてピープルウェアっていうのに注目している章ですね。
だから逆に言うと、僕らはもう売れなくても読んだことあるし、みたいな感じはなくもないけど、どこらへん掘りますか?
げんえい
一緒に働く人みたいな観点、そのプロジェクトのメンバーみたいな話でいくと、組織パターンで一緒に働く人を選ぶっていうのがあったよなとか思ったりもしたし、
この中でちょっと面白いなと思ったパターン、パターンじゃないや、ものとしては、プロジェクトメンバーに報いるっていうような話が102ページにあって、
メンバーに対してどういうことができるかみたいな話を言いたりするんですけど、
教学の札束をぶら下げれば、やる気で問題解決できるように見えるが、そう簡単ではないので会社とかチーム、マネージャーがどういうことできる?みたいな話をしていて、
その中でこれは面白いなと思ったのが、プロジェクトメンバーの家族に必要的なサービスを提供するといいよみたいな話があって、
つまりデスマーチに参加していると、その参加者が男性で奥さんや子供がいて家事ができないってなった時に、
お金とかよりも必要的なサービスとして、例えばベビーシッターを呼べるようにサポートしてあげるとか、
子供の送り迎えの送迎の手配をしたりとかいうようなものだったり、
スーパーマーケットに買い物に行って家に届けるみたいな、そういうような福利構成を用意するといいよみたいな話があって、
それはお金がかかるんだけどプロジェクトの全体からすると大した金額じゃないよねみたいな話があって、
そういうふうに考えるみたいなのってあんまり考えたことなかったなと思って、ちょっと面白い観点だなと思いましたね。
それがいいかって言われると、またちょっと微妙って感じになるんですよね。
きんじょうひでき
なったら給料を上げてくれみたいな話になるかもしれないし、子育て世代に対する支援が厚いっていうのは本当に素晴らしいなって思う反面で、
じゃあ独身は男女問わず死ぬほど働かせるんですねみたいなやつとかちょっと出がちなので難しいですよね。
全員なんですけど差別になるみたいなところがあったり。
げんえい
とか下手すると夫婦仲があんまり良くなかったとしたら、仕事をしてくれた方がこういうサービスがもらえるから仕事をしててみたいなことになってデスマッスルに送り込まれたりとか。
きんじょうひでき
なるほど、仕事が家庭分離する街みたいな。
げんえい
そうそう。とか制度を把握して、こうした方が得になるからっていうことによって無駄に残業しちゃうとか、
いうようなことが起きてしまうんで、必ずしもこれをものすごく推奨するというところまでは多分意図では書いてないと思うんだけど、
どうしてもしょうがなく例えば日出勤をしてくれみたいな状態になった時に、そういう手段だったりとかを考えましょうっていうことなのかなって思ったりとかしましたね。
きんじょうひでき
あとなんかプロジェクトメンバーで貴重な開発者である以前に一人の生活者だよねとか、その人の世界に出てくる登場人物周辺の関係者とかっているはずだよね。
どこまでちゃんと視野に入れて意識しておくべきなんじゃないのみたいな話は非常に納得感ある言いますよね。大事にしてもらってるなって。
雰囲気を出すっていうとなんかすごい手先っぽくなっちゃってるんですけど、せっかくこんなに仕事のコンテキストで報いてくれてるんだから、ちゃんとその人が不幸にならないように報えないといけないだろう的なところはありますよね。
プロジェクトメンバーへのサポート
げんえい
そうですね。あとはこの中で似たような話で、デスマーチプロジェクトに参加した場合には、例えば休暇の延長をできるようにしてあげるとか、
有給のサバティカルっていうのがあって、終わったらチームメンバーを6ヶ月の間プロジェクトXで割り当てる。プロジェクトXは何でも良いって書いてあって、
要はすぐに次にアサインするんじゃなくて、学習のための時間を確保しましょうみたいな話があって、これいいなーって思いながら読んでて、
たぶん現代だと競争が激しいので、そんなに学習してる時間あるんだったら次のやつやってって言われて終わるんだろうなーって思いながら読んでました。
きんじょうひでき
これいいですよね。単純に有給が増えるとかだと嬉しいんですけど、なかなかそうもいかんやろって感じはあるなーって思うんですけど、
げんえい
社内で自分の好き勝手なプロジェクトをやってていいですよとかだったら、もしかしたらあるのかもなーとか。
それができるって相当強者というか、強者のムーブだなーって思いながら。
きんじょうひでき
でも速攻ですよね。ただあのサバイバルモード、エラスティックリーダーシップでいうところのサバイバルモードを抜け出すにはゆとりが必要じゃないですか。
ただなぜゆとりがないのかっていうと、サバイバルモードに陥るぐらいの実力状況だから、
本当に鶏卵っぽい感じがあって、鶏を先に生み出すっていうのはもしかしたら成果測定が難しいんですけど、ありなんじゃないのかなーっていう感じがすると。
げんえい
そうですね。やれるようにしたいなーって思うけど、現実は厳しいみたいな。
っていうところは結構読んでて、いいなーと思ったりとか、面白いなーって思ったりしましたね。
きんじょうひでき
そうですね。あとはレスマーチプロジェクトの人々でいうと、コミュニケーションの重要性っていうような話とか言われてたりもするわけですけど。
あとあれか、スカンクワークの話が。スカンクワークめっちゃ出てきますね。
げんえい
そうですね。スカンクワークめちゃくちゃ出てきて。
きんじょうひでき
なんでそんなみんな差も当たり前のように。今のところ僕らがこのボットキャストで触れた著者3人ともスカンクワークいいぞって言ってますからね。
げんえい
そうですね。
きんじょうひでき
割合で100%ですよ。
げんえい
それぐらい向こうではやっぱり有名な話なんですね。たぶん、こんなに言及されるってことは。
か、まあ大根丸子と仲がいいからスカンクワークの話をしたから。海外だから単純にそういう話なのか。
きんじょうひでき
そうですね。これスカンクワークって出てきてるのが、いつものオフィスとは別室とか別の建物借りて、そこでもう缶詰状態でやらせましょうみたいな。
デスマーチっぽくなるほどきついプロジェクトっていう事実はもう揺るがしようがないから、万難を背して少しでも集中できるようにお膳立てしてあげましょう。
そのための一手手段としてこういうやり方があるよね。的なくだりで触れられてるんですけど。
あとあれか、プロジェクトの進捗の敵になるやつをどんどん万難を背していけみたいな話なんですが。
働く時間を深夜にさせればみたいな話があって、それはなるほどなって思いましたね。
周りの人と同僚と同じ時間で日中に働いてるといろいろ差し込みとか連絡とかきちゃう。
だから一層そのプロジェクトのメンバーは夜働かせて昼はやらせとけみたいな。
そしたらユーザーからの問い合わせもないし、くだらねえ会議に呼ばれることもないし、周りがうっせえとかもないしみたいな。すごいですよね。
作業環境の工夫
げんえい
書き出しはまずこれは大胆な方法だがって書いちゃって、大胆すぎるやろうみたいな感じがしますね。
きんじょうひでき
大胆すぎますね。
げんえい
これぐらい自由な働き方が許される場面がいっぱいあったのかな。今だと難しいですよね。
老期だったりとか、デスマッチなのかそんなこと言ってられるんだろうっていう可能性もあるっちゃあるんですけど。
きんじょうひでき
あるっちゃあるんですけど。
げんえい
それでいうと深夜勤務へ変更の一個前が長距離通信通勤っていうのがあって、
これはまあ今では普通ですけどプロジェクトのメンバーに自宅勤務するように毎週の工程会議は近くのマクドナルドでやると伝えるみたいなところで、
プロジェクトチームが消えたことを数週間誰も気づかないしとか、勝手にひっそりとやりましょうみたいな感じですね。
すごいアイデアをいっぱい出してくるな。
きんじょうひでき
長距離通信通勤のところ、言ってることはオフィス来なくていいんで自宅でやってください、あとはどうにかしておきますみたいな話でしかないんですけど。
プロジェクトチームが消えたことは数週間誰も気づかないとか、この方式の応用としてプログラマーがいつも座る位置に欠かせぬような人形を置くみたいなことが書いてあって。
酷いんですよね。会社の上層部は他のオフィスの主体のような変人たちと見分けがつかず困るはずだ。何を見てきたんだこの人はっていう感じが非常に。
げんえい
これ真面目に言ってるのかどうかちょっとどう受け取っていいんだろうという気持ちになりますね。
そうなんですよね。愛想笑いするぐらいしかできないなみたいな表現がちょいでくる。
きんじょうひでき
でもそんなところですかね。デスマーチプロジェクトの人々。このショーを要するに何ですかっていうと、デスマーチっていうプロジェクトは悲惨な状態だけどそこにいる人たちは大事にしましょうねとか。
結局メンバーが頑張ってくれないとその広いプロジェクトはより広くなるだけで終わらなくなっちゃうんだから、せめてどうにかできることはしようみたいな。そんなショーですかね。
そうですね。
げんえい
そういうことを頑張ってやって、あとは開発プロセス適正な技術も大切なんでそれを見ていきましょうみたいな感じですね。
きんじょうひでき
第5章がデスマーチプロセスですね。デスマーチプロセスっていうとどのようにしてデスマーチが進行していくのかどういうふうにゲームオーバーを迎えるのかみたいな感じですけど、逆ですね。
デスマーチ的なプロジェクトになってしまった場合にどのようなプロセスを築くことで改善していくか回復していくかっていうのを頑張ろうぜっていう章ですね。
割とここは具体的なハウによってくる感じですね。ここはというかここから。
ふっちゃってるんですけど面白い話ありました?原産的に。
げんえい
そうですね。まずこの本で一番大事な概念ですよみたいなのが実は最初の方に取り味っていう話があったんでちょっと取り味の話をしますか。
きんじょうひでき
前書きだか初めにだかで、一つだけ覚えるとしたら取り味っていう言葉だけでも覚えてくださいみたいなぐらいの強調をされている言葉ですよね。
げんえい
そうですね。だからこの本のキーコンセプトみたいな。これは実際この5章のとこでも本全体がたった一言だけ覚えるとすればそれは取り味であるって書いてあって。
なるほどとりあえずこの本読んでデスマッチ読んだって言われたら取り味を載ってるやつねって言えば大丈夫ですみたいな感じですね。
きんじょうひでき
そうです。分かってるなみたいな。最初の3ページしか読んでない可能性あるけど。
でも要するに制約、例えばさっき言ってたねクオリティーコストをスケジュールみたいな話とかも含めてですけど、ありとあらゆることをやれって言われた時に全てを活かすことは無理。
プロジェクト管理の重要性
きんじょうひでき
というか全部やろうとすると何も救われなくてプロジェクトを丸ごと沈没してしまうよねって言うんだったら本当の沈没とか全滅っていうのを回避するためには微切りをつけて少しでも生存可能性を上げられるところを見極めてやっていこうぜっていう話が取り味ですね。
げんえい
そうですね。もともとは医療の現場とかでよく使われている言葉なんですよね。
きんじょうひでき
そうですね。災害とか起きた時とかですよね。
げんえい
そうですね。それだけとりあえず皆さん覚えて帰ってくださいっていう感じがまずプロセスの最初ですかね。
実際ディスマーチのプロジェクトにおいてはユーザーが求めているものを全部実装するような時間はないので、多分全部作らなくていいような方法を考えるとか、全部作りにしても何かウルトラシーがないとみたいな感じですね。
きんじょうひでき
そのくだりの中で、もしユーザーが全てのデータフローダイアグラムを承認するまでコーリングを始められないとの考えでプロジェクトを開始したなら失敗することは目に見えているって書いてあって、それもまたレモデコが言ってた話だけどまさき完全否定なんだなみたいな。完全否定ではないか。
げんえい
ある種こういうプロセスを決められたら失敗するぞみたいな。
きんじょうひでき
デスマーチだなって思ったらもう非常事態っぽい動きをしましょうって話ですもんね。それは日常だったら怪我人とか患者全員救った方がいいけど、デスマーチってそういう状況でもない。
げんえい
そうも言ってられないから誰を生かすか誰を諦めるかっていうのをちゃんと選びましょうみたいな。じゃないと友達折れちゃうだけなんて的なとこですね。
きんじょうひでき
その取り味っていうのをやっていきましょう。重要ですよっていう話した上で、じゃあどのように進めるかっていうようなちょっとしたハウっぽいところも踏み込んでたりっていう。
げんえい
とりあえずの単純な例でヨドハさんが関わったプロジェクトではマストとシュートとクッドに3つに分けてるのが常識となっていたよみたいな話があって。
大体あれですよね、まずこういうふうに3つに分けますよねみたいな気持ちにはちょっと読んでてなって、大体が全部マストに入ってて、これ全部作るってことかみたいな気持ちになるところまでがセットだよなって思ったりしてますね。
優先度全部こうでみたいな感じになっちゃうよ。
きんじょうひでき
そうですね、割と見覚えがある、身に覚えがあるとか、知った話とかっていうのがちょいちょい載ってたりしますけど、もうちょいアジャイル寄りな本とか話とかってなると、対話して何を引き出すかみたいなところのハウみたいな話がよく出てくるなと思うんですけど。
シップヒットとかアジャイルな見積もりと計画作りとかだと、ステークホルダーにバックログアイテムに投票させて、100ドルで投資できるとしたらどのアイテムに投資しますかみたいなのを選ばせてみましょうってワークショップやったらどうですかって点が書かれてたりって記憶があるんですけど、
デスマウチっていう本だと割と固着との対話とかっていうのが結構閉ざされてる。より絶望的な状況を想定しているなーっていう雰囲気を特にこの本とかから感じたりしますね。言ってることは変わらないんですよ、要件を削りましょうなので。
げんえい
そこの結局裏返しがアジャイルソフトウェア開発宣言とかにつながっていくのかなーみたいな気がしますよね。
きんじょうひでき
そうですね。
げんえい
結局そうしないと役に立つというか、ちゃんと効果的なソフトウェアは作れないっていう風に考えていくと、やっぱこういうところの失敗から学んできて、ああいうものが出来上がってるんだなーみたいな。
書いてあることって当たり前っちゃ当たり前なんだけど、その当たり前がいかに過去できてこなかったかっていうのが、本当にデスマウチの本を読むとよくわかるなーっていう気がしますね。
きんじょうひでき
そうですね。
そこでちょっとハウとして出てくるのが、ハウというか、ここやっときましょうとかこれを意識しましょうっていうので出てくるのが、
例えば幼虫管理の重要性っていうセクションがあったりするんですけど、
これはいわゆる小作から幼虫を全て引き出して明示的なドキュメントに行って整理整頓するところから始めましょう。
じゃなくて、ちゃんとリストアップして見える状態にしておかないと、そもそも削るのを何にするかっていうのを選べないでしょ。
だからちゃんとリストにしておくんだよっていう話が出てきたりとか、
あと公式プロセスVS非公式プロセスみたいな、社内標準とかで決められてる手順を守るのは大事かもしれないけど、君たちに今一番大事なのはどれですか的な話とかが出てきたりとか。
あとそこそこ使えるソフトウェアっていうセクションがあって、これはなかなかいい翻訳表現だなと思ったんですけど、そこそこ使えるっていうのはグッドイナフですね。
十分なラインは超えているみたいな話だと思うんですけど、めちゃくちゃ使えるじゃなくてそこそこ使えるっていうところを見極めていきましょう、意識していきましょうみたいな話だと思うんですよね。
MVPとかって言っちゃえば簡単なんですけど、そういうふうにしてとにかく削る、少しでも自分たちが余裕を生み出せるようにする雰囲気が第5章全体でずっとありますね。
プロセスのダイナミクス
げんえい
そうですね。ベストプラクティスとワーストプラクティスの話があったりとかしてますね。
後、後ろの方で面白いなと思ったやつが1個あって、これですね。日程短縮が必要だという理由で新技術の利用を正当化しちゃならないっていうことが書いてあって。
きんじょうひでき
トイボックスで見たやつですね。
げんえい
最近もとある建造物がビルを建てるのに新技術で日程が短縮されるってやった結果ビルが建たなくて、まだ6階7階ぐらいしかなくて、本当は30階とか40階建つはずのビルが全然建ってなくて。
これを読んでそれを連想してしまい、やっぱりハウに劣らされるというか感じもあって、非常にいい話だなって思いましたね。ここに書いてあって。
昔からこう言われてんだなぁみたいな、いうような気もしましたね。
きんじょうひでき
そうですね。本当に改めて経験主義的にというか自分たちがリアルとか練習しながら本番やりますみたいなことはやめましょうとか。
ランブルですもんね。
げんえい
あいつは実践の中で強くなっているみたいなのは、うまく漫画の宣伝講座から強くなってもらわないと話が進まないんだみたいな裏話もありみたいな感じもして。
でもどっかで素振りはしておかないと突然プロダクションに大きく入れて失敗するみたいなのは、ひと昔前よく勉強会行くと聞いたなぁみたいな気がしてて。
きんじょうひでき
え、モンゴリーウィー。
げんえい
そうですね。その後このモンゴされなければみたいなことを言ってる人たちをいっぱい見てきた記憶がありますね。
そういうのもそうだし、プロジェクトっていうか組織の中にそういうツールみたいなものを入れていくって、やっぱりハレーションみたいなものはあるんだからちょっとずつ試して広げていくのが大事だよみたいなのって。
小さく試してやっていくのがいいよみたいな。すごくひと昔前よく聞いたなっていう気がしてて。
なんか最近そういうものがある前提になっちゃったからみんな知ってるよねみたいなってスルスルとツールがいろんなものが入っていくような気がしますけど。
昔は勉強会行って前の登壇者が発表して最後のまとめに絶対ちょっとずつ広めていきましょうとかちょっとずつ入れていきましょうみたいにしてて。
本当にみんな同じことしか言わねえなって思った時あったんですよね。
きんじょうひでき
そうですねツールがいかに素晴らしいかっていう話かける自分たちのやり方に合ってるかっていうのがそこってどっちか一つが支配的なパラメーターっていうわけでもないし単純な足し算でもないと思うので。
で合ってるか合ってないかってそこに対する習熟度学習進捗とか慣れの話があるのでこのデスマーチを救う銀の弾丸〇社の〇〇サースですっていうのは非常にオチが見えてますよね早くその会社辞めた方がいいですよっていう風に言われそうですよね。
げんえい
そうですね。
きんじょうひでき
日程短縮が必要だという理由で新技術の利用を正当化してはならないっていう箇条書きで書かれているリストの2つ目に書いてあってでその2つ下に銀の弾丸〇アプローチを擁護してはならないって書いてあるんでなんか落ち着けっていう非常に痛いんだろうなぁみたいな気がしてますね。
げんえい
そうですねもうプロジェクトはひどい状態なんで神頼みというかなんでかこう。
きんじょうひでき
楽に狙わないで負けない戦い方をしろみたいな感じですよね。
そうそうそう。
まぁ強いて言うとあれか、XPの諸々に言及されてますね。
良い意味合いでXPとか取り入れてみるといいんじゃない的な感じでプラクティスが紹介されているってところですね。
げんえい
そうですね。アプロとかコードの共同所有みたいな話とか。
きんじょうひでき
出た話題のコードの共同所有。
げんえい
共同所有のところにEVCSっていうのが俺もこれはわかんねえやと思ったしマイクロソフトのソースセーフって書いてあってなんかすごく懐かしい名前だなと思いながら使ったことはないですけどはい久々に聞いたのって思いながら読んだりしてました。
きんじょうひでき
まぁまぁまぁそれであとはあれか継続的なリファクタリングとかも厳重がありますね。
げんえい
当時これを読むと結構おおってなるほどそういうものがあるのかってなったのかもしれないですね。
きんじょうひでき
確かに第二版とはいえそうですねまぁ開発プロジェクトで言うデスマーチってこの本が元ネタ流行りの原点になったのかなっていう認識ではいるんですけど多分そうですよね。
げんえい
そうだと思います。
きんじょうひでき
失敗プロジェクトの代名詞となったデスマーチ待望の改訂版って上に書いてあるんで。
げんえい
そうそうこの本が出たことによって多分こっつのデスマーチっていう言葉がIT業界で使われ広まったっていう風に一般的には言われてますね。
きんじょうひでき
でその書籍の中でXPっていう話が書かれてるんでなかなか面白いですよねっていうようなところで次行きますか。
げんえい
行きましょう。
きんじょうひでき
今ですね全11章のうちの次が第6章です。
まぁでもなんか前半なんですよね結構。
げんえい
うんそう。
きんじょうひでき
それこそ政治投稿書でデスマーチプロジェクトの人々まででほぼ半分超えてるぐらいなんで。
げんえい
そう後ろの方はおまけで書いてあるのかなっていうぐらいにだんだんだんだん章がね一章一章が薄くなっていくんですよねページ数が。
きんじょうひでき
そうですね6章はここからちょっとずつ薄くなっていくというか多分我々の話も薄くなっていく感じがありますが。
6章はプロセスのダイナミクスっていうふうに目打ってる章でデスマーチプロジェクトでの最も深刻な問題は政治的社会的文化的人間的要因に関するもので技術的なものは多くないっていう書きらしいから始まってるんですけど
ダイナミクスって言ってるのはプロジェクトをやっていく中でその技術的な話以外の部分でもその予測とか変化とか適応とかっていうのはなかなか大変というか明確認識しとく必要があるよねみたいな。
最初に決めたことをそのままやりきりましょうデスマ話じゃねーぞ的なことが書かれている章ですかね。
げんえい
そうですね。
きんじょうひでき
何かどうですか議員さん的なこの章は。
げんえい
そうですねそういうような話をしないといけないぐらいにはやっぱIT業界のその経験みたいなものが少なかったのかなみたいなことをちょっと思ったりしましたね。
書いてないことですけどこれは。
全体を把握しながらどういうものを見ながらそのプロジェクトがうまくいってるいってないみたいな指標だったりとか何が何に依存してるのかみたいなことを考えるということがまだまだ慣れてない経験したことがないことがたくさんあるみたいな状態になってるからこそそういうものを紐解いて明らかにしていって
ちゃんとプロジェクトをコントロールしていこうねっていう風になっていってこの6章みたいなものがやっぱ必要だったのかなっていう風にちょっと全体を通しながら思いましたね。
きんじょうひでき
そうですね。
デスマーチプロジェクトの理解
げんえい
あとはその多分このダイナミクスでなると変数が増えれば増えるほど良くしないというか把握が難しくなっていくことでもあると思うのでそうなるとやっぱ組織パターンのロールは少なくみたいな話につながっていったりするんだろうなとかいうことをちょっと思ったりしましたね。
きんじょうひでき
あとはあれか、いかにシンプルに考えるかっていう話と、物事を見る上でどういう風に考えていかなきゃいけないかみたいな話があって、その中で静的モデルと動的モデルっていう話があるんですよね。
ここは結構なかなかなるほどなって思ったんですけど、パラメーター1個いじったら他のとこに影響を及ぼすでしょうみたいな話、要するにXっていう要素を変化させたらそこから連なっているYとかZとかの要素への影響を受けていくよねとか、
あとその変更しました、その影響が現れてきましたっていうのって、独自的にパッパってくるものじゃなくてタイムラグあったりする、徐々に変化が進んでいく、気づいたら全然違うものになってるとか、そういうメンタリティで物事を見ていくっていうのは必要なことだよねー的なことが書いてありますね。
げんえい
今の現代の我々はどういうふうにこれをコントロールしているのか、合っているのか、どう考えているのかっていうところは、実はチームトポロジーだったりとか、オーディファイモデルとか、もしかしたらそういうところ、ちょっと今フチームなりしか出さなかったですけど、そういうところに繋がっていくのかなーみたいなところはちょっと思ったりしましたね。
きんじょうひでき
あとあれなんですよね、すごいなんかシステムシンキング的な話をしてるなーと思ったので、何だろうな、学習する組織呼べば会えへんちゃうみたいな、というふうには感じましたね。
げんえい
ダイナミクスって言われたらもう全てそういうようなものを連想してしまうなーみたいな気もしますね。だからそれはなんか我々がもうそういうことを学習してしまったから、そういうことでしょうっていうふうに読んでしまうのかな、すると。
きんじょうひでき
いやでもあれじゃないですか、参考文献には載ってない、なるほど。
げんえい
でもピーター宣言の名前とかは参考文献に載ってますね。
きんじょうひでき
ここの章の参考文献に載ってます?
げんえい
そうですね、参考文献の7番にフィフスディスプリンが載ってるんで。
きんじょうひでき
あー一個前の方ですね、じゃあ。
げんえい
そうそう、一個前。
きんじょうひでき
最強組織の法則かな?
げんえい
日本語だと。
日本語だと。
もちろんエドワード・ディオードも読んではいて仕入れてるんだろうけど、
だからちょっとやっぱこの時代感みたいなところ、この20年ぐらいで多分そういう話が流通して、
デスマッチ以外のところでもそういうものに触れる機会があるのと、
当時、別に当時も読んでる人は読んでたかもしれないけど、ここで知るっていう人、
そういう文とかはあるんだろうなとか、
別の本がいい本があるからわざわざここで研究しなくてもいいよねみたいな場合もあったりするんだろうなみたいな。
きんじょうひでき
そうね、あれか、さっき言った動的モデルみたいな話で言うと、
要するにプロジェクト始まった時と終わった時だと、
全然見えてた景色、思ってた景色、全然違うものになっちゃうので、
ってなるとプロジェクト終わった時のポストモーティングとか、
ちゃんとやってこうなー的な話が元に書かれてはいるんですけど、
ただこれポストモーティングやって残念なのは、プロジェクト崩壊しプロジェクトマネージャーはクビになり、
メンバーとエンドユーザーはマシなプロジェクトに移り、
非難と責任の所在を査定するために法律課と監査人が呼ばれるっていう状況で、
ポストモーティングって大体行われるみたいな、
それが書いてあって、そのプロジェクトの下中にいた人たち、
本当にそのプロジェクトの結果から影響を受けた人たちっていうのは、
ポストモーティング実施する時にはその場にいないし、
そこから得た学びっていうのはじゃあどこに引き継げばいいんですか、
みたいな難しさってあるよねー的なことを言って終わってるんだよな、このまとめ。
クリティカルチェーンの理論
げんえい
そうですね、しかもこの本ではその9章とかでもポストモーティングの話が出てきて、
ポストモーティングやっても誰も読まないし、あんまり意味がないっていうのではないな、
それを活かそうってするのがなかなか難しいね、みたいなこともあって、
ポストモーティングに対してやった方がいいのはそうなんだけど、
あんまりポジティブな例がなかなか本の中でどうして出てこないなってちょっと思ったりもしました。
なんかもどかしそうにしてますよね、
きんじょうひでき
当たり前に大事なのはわかってるんだけど、そもそもディスマッチを起こすような組織で
げんえい
どうやればいけるんだ、みたいなちょっと。
きんじょうひでき
そんなところがあって、第7章。
第7章、クリティカルチェーンと制約条件の理論っていう話なんですけど、
要するにディスマッチプロジェクトってその見積もりとか期日、
実装とかビルドの能力に対してタパシティに対して十分な予算とかスケジュールとか
っていうインプットリソースがないよね、みたいな話。
なのでスケジュール管理、めちゃくちゃ大事なんだけど、
どうやっていくのっていうと、クリティカルチェーンとかTOCの話っていうのを意識していくと、
なんか少しシンプルで効果的にプロジェクトの運用とか、
エルフチェックできるんじゃないの?
バッファっていうのがちゃんと意味があるように効果的に使えるんじゃないの?
みたいな話として、第7章、クリティカルチェーンと制約条件の理論が固まってくるわけですね。
ずっとクリティカルチェーンの話してません?我々。
げんえい
そうですね。ずっと俺はザ・ゴール読みたいな。
話をする度にゴール読んでないなーみたいな気持ちになるっていう。
きんじょうひでき
ザ・ゴールは漫画でも読めるんでね。
げんえい
そうだね。8章はそれでいいかなっていう気はしますね。
きんじょうひでき
第7章の書き出しは結構好きというか、この本全体の本質をついてるなーって思ったんで、
ちょっとそこだけ紹介したいんですけど、第7章の最初の節が機能不全っていう名前になってて、
そこの書き出しの一文目ですね。
この本の少なくとも最後の数章の暗黙の前提はデスマーチプロジェクトとは、
誤着やエンドユーザーや利害関係者や組織全体の機能不全そのものであるというふうに書かれてて、
僕はこの一文を読んで、ちょっと冒頭でも話したんですけど、
デスマーチっていうのがプロジェクトがきついことを表す形容詞的な表現かなーって思ってたんですけど、
そうじゃなくてそのデスマーチを生んでしまうような組織全体、
プロジェクトチームを取り囲むいろいろな諸要素っていうところの機能不全、
病理みたいなものなんだよっていうふうなことを言ってる気がして、
なるほどそういう見方というかそれを伝えたくてこの本があるんだなーっていうふうに思ったりしましたね。
げんえい
だからこそプロジェクトマネージャーはそれに対して取り化しないといけないと。
きんじょうひでき
プロジェクトマネージャーの腕が悪いからデスマーチが起こるじゃなくて、
本当はもっと大きな問題だよっていうような感じですね。
プロジェクトマネージャーはめちゃくちゃ頑張らなきゃいけないし、
プロジェクトマネージャーにできることなんて超限られてるよねっていうことを言ってる一冊だな。
救いはどこにあるんだって。
げんえい
救いは組織全体をちゃんと見れる人がこの本を読んで、
自分の会社がこうなってるってことは組織がうまく回ってないんだっていうことをちゃんと理解するとかですかね。
きんじょうひでき
組織全体のあり方とか見え方とか考え方というか、
当たり前のセットする位置が全然違うよねみたいなところからデスマーチが始まっちゃってるので、
それって機能不全じゃんっていう話になり、
その機能不全の最たるものとして本当はできもしないことを3日でできますとか1年でできますとか言っちゃってるとか、
バッファーをめちゃくちゃ変に食い潰しちゃうみたいな学生商工群的なところに陥ってしまったりする。
それが個々人っていうレベルじゃなくて、本当に組織全体っていうレベルで起きてくると本当に組織全体の機能不全だよね。
よしそこでクリティカルチェーンですよみたいな感じ。
げんえい
でもこれがちゃんとあれですよね、まずは使う練習をして、
この銀の名が本当に扱い方がいいかみたいなことをちゃんとやっとかないと、
なんかこれでやるとちゃんとお付けでいくんでちょっとこれ使わせてくださいってやって、
あれなんかこれでうまくいくって聞いたのにうまくいかねえ、
誰としてやるんだみたいなことが起きてしまうってことですね。
きんじょうひでき
そうですね、まとめでもちゃんとそういうふうに厳重した。
この章でそういうアプローチを簡単に解説したが、
失敗からの学び
きんじょうひでき
十分な勉強や訓練をしないで次のプロジェクトにこれを使うと大怪我をするはずだっていうふうに書いてるんで。
難しいですよね、練習しないとできるようにならないし、
ただできるようにするためになるべく本物で練習したいなっていう気持ちはあり。
ほんとそう。
げんえい
見積もりの練習をするって自分のプロジェクトでやったってほとんど自分のやる気次第で左右されちゃうわけで、
なんか自分のプロジェクトでやるのは無理なんだよなーみたいな気持ちになると、
一体どこでこれを試せばいいんだみたいな。
きんじょうひでき
プログラミングとかそれこそAWSのトレーニングみたいなのは結構ね、
ちゃんと東西使ってやっていきましょうとかできるんですけど、
プロジェクトマネジメントこそ、プロジェクトマネジメントだとチームビルディングとか含めてですけど、
そこら辺こそマジで練習必要だからなんすかね、
そういう砂場をちゃんと組織としては用意してみてはいかがでしょうかっていう気持ちになりますよね。
げんえい
でもこういう砂場を用意したら砂場だなって思うと真剣に取り組まないみたいなことは起きそうだなと思ってて、
このジレンマどうしたらいいんだろうみたいな。
きんじょうひでき
まあまあちゃんと本気でやってほしいんですよプロジェクトとしては。
ただまあでもなんか本当に実際自分がEMとかやってる時に考えてましたけど、
執行役員とか社長レベルでできる失敗と、高々マネージャーとかメンバーができる失敗って規模が違うので、
俺がプロジェクターをリーダーやって全然上手くいかなかったとしても、
社長はかすり傷ですらないなあみたいな感じが中間管理職やってからそういうことを思うようになり、
いかにして若者に失敗させられるかなあっていうことばっか考えてましたね。
げんえい
いかにして失敗させられるかなあってすげえ意地悪な人みたいな感じだけど、
チャレンジしてもらえて、まあ別に全部を成功させる必要はないよっていうことですよね。
失敗を恐れずにチャレンジしてほしいってことですよね。
きんじょうひでき
いやでも失敗させたい。
げんえい
まあそうね。
きんじょうひでき
成功した時と失敗した時の差分を知ることも大事だなと思ってて、
それとして成功体験だけで道を生み尽くされるとダメなはずなんですよ。
げんえい
うけみの取り方が、うけみの練習しとかないと大変みたいな感じはありそう。
きんじょうひでき
実際なかなかきみに任せたプロジェクトがうまくいかなかったぐらいの結果になっちゃった人って、
げんえい
その後めっちゃ伸びてたりするので、
きんじょうひでき
だからなかなか修正できないっていう人は、もしかしたら失敗が足りてないのかもしれないですね。
げんえい
バーボックスに立つ回数をもっと増やすと修正できるチャンスがあるかもしれない。
きんじょうひでき
はい、かもしれない。
失敗を通じた学び
げんえい
でもその話につなげながら発祥に行きたいんですけど、いいですか?
きんじょうひでき
はい。発祥時間の換気ですけど、我々が言えば時間の換気ですね。
げんえい
そうですね。我々は失敗から何も学んでない、失敗を認めていないだけの可能性もありますけど、
きんじょうひでき
一番最初に失敗を認めるのが大事なんで。
げんえい
さっきの失敗をするためには、決断を繰り返していって、
早く失敗した方がいっぱい失敗できるじゃないですか。成功を引く確率も上がるし。
けど、いくい今自分が持ってる時間とかタイムリミットみたいなものがどこにあるのかみたいなことを意識して、
つまり早く決断して早く失敗していけばいくことを打てる手が多くなるんで。
この本の中でも、決断が遅くなっていくとノーキーがどんどん遅れていくよみたいな話が書かれていて、
成功を引くまでの時間が遅れていくぞっていう風にちょっと読みながら思ったりとかしてて、
さっきのチャレンジとか失敗をするためには早く決断をする必要があるよなと思ってて、
そこのトレーニングも必要なんだよなってことをちょっと思ったりしましたね。
きんじょうひでき
ぐずぐずするなってことですよね、だから。
げんえい
完全に組織パターンのぐずぐずするなを連想してましたね、読んでてこの章は。
きんじょうひでき
アイゼンハワーマトリックスが出てきたりとか言ってますけど、仕事が上手い人って言うとなんかすごい最近嫌いなんだよな、その言い方な。
要するに僕らは今ここが分かってないから、こういうアクションしたらここが明らかになって、
それであのアノーンがなくなるよねとかっていうような見立てを持って動くと本当に要するに仮説検証を回すっていうことだと思うんで、
それがいい時間の使い方だなっていう気が。
げんえい
そうなんですよ。実装スピードが早くなくても仮説検証がうまく回せて無駄なものを作らずに必要なものだけを作っていけば、
実は全然ゴールにたどり着くっていうこともあるだろうし、実装スピードが早いに越したことはないけどそれだけは全てじゃないって気もするし、
極力最短で行きたいんですよね、ゴールに。でも最短経路が分からないから最短経路が分かるように早く道が合ってるかどうかを知るために、
こっちの道が合ってるかな、とりあえずちょっとこの道を明らかにして、
こっちじゃないってことは引き返し別の方に行こうっていうようなことを早くやりたいんですよね。
きんじょうひでき
そうですね、軌道修正の回数とかタイミングを早くしたり短くしたりしたいんですよね。
げんえい
限られる時間っていうのは別に大量にあるわけではないので、それをもっと活かすためにはどうしたらいいかっていうのは、
やっぱり仮説を立てながらこれかなあれかなってやっていって、それは失敗と呼ばないかもしれないけど、
早く失敗していくとゴールが見えてくるような気はしているなって思ってます。
きんじょうひでき
そうですね、大発想はそんなところだろうな、短いですしね。
げんえい
そうですね、すごい短いんですよね。
きんじょうひでき
短いし、最初の方は会議は時間通りに始めろみたいな中間行ったりもするので。
