つれづれなる技術屋日記

しがない技術屋。専門は情報工学で、「つれづれ技術屋」って呼んで。

山を登りながら「ザ・ゴール」想起

今日は、伊勢原・大山。紅葉のライトアップ最終日だったので、急遽登ることにした。ただ最近、高尾山とか丹沢とかを登ったり、走ったりが多くなってる。(数年前とかなら、もっと頻繁に山などを走ってたんだけど。)

急な上り坂を登って、大山下社に到着。ライトアップまで時間があったので、なだらかな登山道も少し歩いてみた。そこで、ふと思い出したのが「ザ・ゴール」での登山の様子。TOC(制約条件理論)を分かりやすく説明するのに、子供たちへの宿題として出題する。グループ内に遅い子がいて、その子の荷物を皆で分担しても遅くなるので、それを防ぐ方法を考えなさいというもの。ロープでつなぐとか、タイミングの信号を出すとかが書かれている。(ネットとかで、更に分かりやすく書かれているのもあるので参考に。)

実際の山で思い出し、えらく違和感を感じた。あるいは、「ザ・ゴール」を読んだ時に引っかかったのは、実際の登山を思い起こしたからかもしれない。

そもそも、荷物を無くしてあげても遅れる子を、登山チームに入れることが不可解。極端だけど、その子はケーブルカーとかを利用して貰った方が良い。まっ、それは極端としても、別ルートからというプランも選択できる。

ロープで結ぶのも変。雪山とかでの遭難防止なら分かるけど、ハイキングレベルだと周りから文句言われるだろうとか。例えば、高尾山。 ハイキングでの、ちょっとした岩場ならかえって危険? 

実は、我々数名で高尾山に登った時は、さほど道に迷うわけでもないので、遅そうな人を先頭にした。それも固定的ではなくて、時々真ん中辺りだったり、、、。

コンスタントに歩ける平地のハイキングとしてなら理解も可能だけど、岩場などのような予測しにくい場合には当てはまらないと思える。逆にTOCは前者のようなケースだと考えられるので、「ザ・ゴール」での例としては悪くない。 本件は、TOCをプロジェクトに応用する際に、小さな部分への応用から考えるのと似ている。TOCというよりもクリティカルチェーンの方が良いかも知れないし、小さな部分への応用を先にというのは私の周りだけかもしれないが。

なお、ふと机の上の書類を見てみたらレターがあり、1面に「登山とプロジェクト」と書かれていた。プロジェクトマネジメント学会の、@pm.Letter。発行が7月15日とあるから、結構積ん読状態だったようで少し反省。 プロジェクトマネジメントと登山の、似ている部分とそうでもない部分の対比が面白いし参考になる。特にステークホルダー関与の仕方。登山は結局現場に任せることになる。プロジェクトだと、余りに関与しすぎ。

「ザ・ゴール」での登山部分も含めて、プロジェクトと登山の類似点と相違点を考えてみるのは役立つと考える。

©2005-2022 ほんだ事務所(honda-jimusyo) All rights reserved.