答えは現場にあり!技術屋日記

還暦過ぎの土木技術者のオジさんが、悪戦苦闘七転八倒で生きる日々の泣き笑いをつづるブログ。

CCPMな日々

2014年12月15日 | オヤジのCCPM修業

 

 

上が一週間前で、下がその一週間後。

順調に進んでいるかのように見える現場だが、まったく進んでない。

のみならず後戻りさえしている。

「どうしたの?」

週イチの全体工程会の席上、思わず私がそう問いかけたのも当然のことである。

「あと工程を見直して・・・」

「見直すたんびに日数が増えていって・・・」

という回答に、

「見直すのはええことやけど、そんなしょっちゅうしょっちゅう見直ししよったら身体がもたんぜ」

とかナントカ返しつつ、時間がないのでその場は終了。

あとでじっくりヒアリング、ならびにカウンセリングを行うことにした。

すると、なんのことはない。

一つのチェーン(作業のつながり)が完了して、次のチェーンにバトンをわたすときのタイムロスが全体工程に大きな影響を及ぼしているのである。

具体的にいうとそれは、コンクリートの養生。

品質管理の上で必要不可欠なものだから、タイムロス(=ムダな時間)という呼び方はふさわしくないかもしれないが、

その間、実質的な作業はしていないのだから、時間的な意味だけからいえばやはりロス。

その「養生」によるタイムロスが数カ所あり、それを工程に入れ忘れていたか、あるいは入れていたが日数が短かった。

そこを見直したがためにチェーンの総日数が増加した、とこういう理由である。

もともと「養生」というものは、その期間を経ずには次工程に移れないという意味で、「つながり」としてはクリティカルそのものである。

だが「養生」をクリティカルなタスクとしてしまうと、実行されないタスクがクリティカルチェーン(クリティカルなタスクのつながり)の総日数にカウントされてしまい、おかしなことになってしまうのである。

なぜそれがおかしいのか。

「養生」にかかる日数には安全余裕がないからである。

一つひとつのタスクから安全余裕(バッファ)を差し引いて、プロジェクトバッファとして工期の前にまとめて配置する。

そして、クリティカルなタスクが進んだか遅れたかではなく、プロジェクトバッファが増えたか減ったか、あるいはどういう増え方や減り方をしているのか、で工程を管理する。

これがCCPMの根幹中の根幹である。

このときプロジェクトバッファのサイズは、クリティカルチェーンの総日数に一律の割合を乗じて決められるが、

もともと安全余裕がないタスクをクリティカルチェーンに足し込んでしまうと、プロジェクトバッファのサイズがその分だけ(ムダに)大きくなってしまう。

ということはすなわち、それだけ余計に工期が必要になるということであり、

「契約工期という約束」を前提として組み立てられる工程にとっては、それだけ余分な日数が必要になるということである。

これが「おかしなこと」の理由である。

だから「養生」は、でき得る限りクリティカルなタスクとはしないと、こういうわけである。

 

ところが、どうやっても「養生」期間中に工事がストップしてしまわざるを得ないことがある。

今回の場合もそうである。

で、私がアドバイスをしたことは、

まず、「養生」のタスクに占めるバッファの割合を、算出されたプロジェクトバッファのサイズから差し引く。

クリティカルチェーンにおける「養生」の占める割合が多ければ多いほどこれは効く。

だがそれは、あくまで机上の計算。

もっともシンプルかつ効果的なのは「養生」の日数を短くすることである。

で、秘策を授けた。

じつのところをいうと、「秘策」、というほどの大げさなものでもないが、そこは企業秘密である。ここには書かないでおこう。

 

「なんや、さんざん理屈を並べておいて結論はそこかいな。そんなん誰でもわかるやろ」

とお思いのそこのアナタ。

たしかに、こんな回りくどいことを言わなくてもデキるアナタはわかるだろう。

だが現実は、皆が皆そうではないのである。 

そして私と私の環境は、そういうなかで現有戦力の底上げを図り、チームワークでたたかっていかなければならない。

そんなとき、どうみても順調至極な今に惑わされず、3ヶ月先の明らかな危険信号を、誰でもがわかるように教えてくれるCCPMは威力抜群である。

発せられた信号への有効な解決策は、場合によっては誰でもかれでもが立てられるものではないかもしれない。

当然そこは技術力の優劣や経験の多少によって違ってくるだろう。

だが、「赤信号」と、どこが「赤信号」の原因なのかという共通の認識は持つことができるはずである。

 

で、我と我が身をふりかえり反省し、担当さんに「ゴメンね」と頭を下げる。

「見直すのはええことやけど、そんなしょっちゅうしょっちゅう見直ししよったら身体がもたんぜ」という言葉をである。


わかったことはすぐ修正、そして早め早めに対策を。

その対策が効果を産み出すかどうか、やってみなければわからない。

ダメなときは二の矢を放ち、それでもダメなら三の矢を放つ。

そうやって今日も、私と私の環境の、

CCPMな日々はつづいていくのである。



  

  ↑↑ (有)礒部組現場情報ブログ


   

   発注者(行政)と受注者(企業)が

チームワークで住民のために工事を行う

(有)礒部組は三方良しの公共事業を実践中!


コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

威力倍増

2014年11月26日 | オヤジのCCPM修業

 

ご存知CCPMで、新しい林道工事の工程会議中。

 

 

完成イメージ。

 

 

 

レイヤーやら表示非表示機能を使って3Dモデルをばらし、

行きたいところ見たいところ、

見たい時点行きたい時点へ、

空間と時間を行き来する。

3D+時間軸=4D。

これでCCPMの威力倍増。

今日もまた試行錯誤中、

というか、けっこうさまになってきたのである。



  ← クリックすると現場情報ブログにジャンプします

 

           

            有限会社礒部組が現場情報を発信中です

 

         

            発注者(行政)と受注者(企業)がチームワークで、住民のために工事を行う。

               三方良しの公共事業実践中!


コメント (2)
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

見えている景色

2014年11月20日 | オヤジのCCPM修業

3DモデリングとCCPMを合体させて施工計画を立てる、

という試みに継続してチャレンジ中である。

というより、CCPMによる工程計画に3Dモデリングを取り入れる、

といったほうがより実態に近いか。

どちらにしても、目指すところはコミュニケーション&コラボレーション。

「伝え合いそして協働する」である。

8年間にわたるCCPMの実践を通じて、

ずいぶんと話しの通りはよくなった。

だが今でも、話しがかみ合わないことがよくある。

ようは見えている景色が違うのである。

見えないのか、見ても気づかないのか、はたまた見ようとしないのか。

それはその人その場で異なるのだろうが、

見えている景色が互いで違うと、何をするにも上手くは行かない。

もし行っているとしたら、それは単なる偶然か、上手く行ってないことに気がついてないだけのことである。

とはいえ、毎日顔つき合わす女房殿とさえ、それはままあるのだ。

赤の他人同士が共通したイメージを持つことは、実際のところ簡単なものではない。

だから私は、何度でもチャレンジする。

目指すところはコミュニケーション&コラボレーション。

「伝え合いそして協働する」である。

ということで、 

3DモデリングとCCPMを合体させて施工計画を立てる、という試みに継続してチャレンジ中である。

目指す方向も理論的にも間違ってはいないと思っているが、

だからといって上手くいくとは限らない。

私ひとりでは、な~んにもできないからである。

あせらずに、ぼちぼちと行きましょう。

 

 

  ← クリックすると現場情報ブログにジャンプします

 

           

            有限会社礒部組が現場情報を発信中です

 

         

            発注者(行政)と受注者(企業)がチームワークで、住民のために工事を行う。

               三方良しの公共事業実践中!

コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

「ある」工程表と「ない」工程表について考えた

2014年10月23日 | オヤジのCCPM修業

現場はこのあとどんなふうになっていくのでしょうか、

と私が問うたとして、

例えばこのような工程表を出されると、

少し哀しくなってしまうのである。

 

 

たしかにこの工程表からは、どんな工種にいつ(ごろ)取りかかっていつ(ごろ)終わるのか、

というのは読み取れる。

だが「”つながり”のある工程表」を共通の言語として会話をすることに慣れ親しんでしまった私の脳ミソは、

いや脳ミソのみならず身体が、コイツに対して明らかな拒否反応を示すのだ。

「”つながり”のある工程表」とは例えばこのようなものである。

 

 

上の「ない」も下の「ある」も、同じ現場のものである。

つまり、「何がどうしてああしてこうなる」がわからない工程表と、一目瞭然に見える工程表と、

どちらがより優れていますかということであり、

私なんぞに言わせてもらえば、それはもう圧倒的な大差で後者に軍配が上がってしまうのだが、

ところがどっこい世の中はさにあらん。

前者を選択する人が圧倒的に多いのが現実なのである。

それについて、何年も前から折にふれ考えてきた私は、

多くの場合、「”つながり”のある工程表」の優位性は認めても、手間ひまがかかりすぎるからだとか、面倒臭いからだとか、

あるいは、役所が提出を義務づけているのが「”つながり”のない工程表」だから、とか、

消極的もしくは消去法的な理由で採用しているのだと、ずっと思っていたのである。

ところが最近、そりゃチト違うんでないかい?という疑念を抱き始めている。

ひょっとしたら好き好んで使っているんではないか?と思い始めたのである。

「どちらがより優れていますか?」

と質問する私は、その時点ですでに「コッチに決まってるだろう」という答えを(それも自信満々で)用意しているが、

その問いを、「○○という目的に対して使うツールとして、どちらがより優れていますか」と変えてみると、

その答えが違ったものになったとしても何らおかしくはない、

という考えてみれば至極当然のことに気がつき始めたのである。


「”つながり”のない工程表」を採用する人は、たとえば私のように、

工程表を情報共有ツールとして、あるいは共通の言語として使う意思がないのではないか、

(前出のような消極的理由で使わない人もそりゃたくさんいるでしょうが)

断定してしまえばつまり、(本当のところは)自分さえわかってりゃええやないの(説明するのってけっこうヤヤコシイし)という考えが根底にあり、

それ故に、工程表に「つながり」を求めていないのではないか、という仮説を持つに至ったのである。

この場合、自覚しているかしていないかは別である。

多くの人が無自覚的だろうとは思う。

だが、私たちの仕事において「工程を引く(計画する)」という行為は、ロジカルシンキングでなければならないと私は思う。

そのロジックを他人に伝えることで、「自分ひとりじゃな~んにもできない」土木の仕事が「うまくいく」。

「経験と勘」は土木の仕事にとって肝要かつストロングなポイントである。

だが、その「経験」と「勘」を、自分でも「よくわからないもの」にとどめて(他人にとってはなおさらわからない)おくべきではない。

「”つながり”のある工程表」はそれを可能にしてくれる突破口なのだ。

その工程表を構成する一つひとつのタスク(作業)から安全余裕(バッファ)を抜き出し、

プロジェクト(工事)でもっとも守られるべきもの~納期(工期)~の前にひとまとめにしたとき、それは、

「”つながり”があって安全余裕をひとまとめにした工程表(=CCPM工程表)」となり、

「つながり」を「見える化」したことによって、それはさらにパワフルなツールとなる。

暗黙知を形式知に変換して伝えることができる工程表。

それがCCPM工程表なのである。

 

と突然、火がついてしまって一気呵成に書き上げた朝。

それを加筆修正してアップする夜。

点火したキッカケはどうであれ、

こうやって自分の考えを整理するのは、

すこぶる良いことなのであります。

ということで今日もまた、ブログを書く日々に感謝。

 

 

  ↑↑ クリックすると現場情報ブログにジャンプします

 

           

            有限会社礒部組が現場情報を発信中です

 

      

    発注者(行政)と受注者(企業)がチームワークで、住民のために工事を行う。

コメント (4)
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

北の国から~2014年秋

2014年10月08日 | オヤジのCCPM修業

日曜日、「CCPM雑記」という名のミサイルを、めぼしいと思われる方々に打ち込んだ。

「笑覧のうえ、ご批判ご意見などいただければ幸いです」

と結び、メールを送ったのである。

すると、そのうちの一人から想定外にダイナマイトな返信が、きのう届く。

「北の国から~2014年秋」である。

私信なので、無断でその中身を晒すわけにはいかないが、

その内容をひと言で表すと、「CCPMとBIM(CIM)のランデブー飛行によるフロントローディングへのチャレンジ」とでも言おうか。

向かっている方向性は私と同じである。

ただ、彼のほうが数段レベルが高く、進んでいるように感じた私は、

ギリギリと歯ぎしりをしながらそのメールを読みつつ、

「いいなあ、勉強させてもらいたいなあ」と独り言ちながらこう思う。


持つべきものは前を向く朋。

 

 

  ↑↑ クリックすると現場情報ブログにジャンプします

 

           

            有限会社礒部組が現場情報を発信中です

 

      

    発注者(行政)と受注者(企業)がチームワークで、住民のために工事を行う。

コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

CCPMによる「見える化」がなぜ凄いかについて

2014年10月05日 | オヤジのCCPM修業

堰を切ったようにCCPMについて書いてみたのは、突然スイッチが入ったとしか言いようがないのだが、

その思考自体は、なにも突然始めたものでもなく、

頭のなかで混沌として渦巻いていたものが、ある時ひょこっと顔をのぞかせる気配を見せたのをいいことに、

すわチャンス!とばかりに書いてみた、

というだけのことである。

そこで、ふと思い出した下書きの存在。

いつだったか、書きかけたまま、まだ考えが熟成してないぞと寝かせていた草稿があったはずである。

ということで、ブログ編集ページの「記事一覧」を遡ると、

思ったより以前にそれはあった。

2014年4月28日18時20分49秒、

『ホントの意味でCCPMの見える化が凄いことについて』

イマイチ気に入らなくて留め置いていたテクストだが、

きのうの稿をアップしたあとならば、そのままでも理解してもらえるかなと思い、

加筆修正をせずにアップをしてみる。

きのうに至るまでの途中稿てな感じで、読んでいただければ幸いである。

 

・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

 

CCPMを使って何をするか?

という問いに対する答えは、もちろんのこと一つではない。

だが、どうしてもひとつだけ。

と言われれば、今ここにいる私ならこう答える。

各自の頭のなかにある工程(段取り)を「見える化」して組織全体で共有するところから、コミュニケーション(伝え合い)し、コラボレーション(協働する)をする。

こうも言える。

ベテラン技術者の経験知を「見える化」するところから、経験や(経験から得た)知識が乏しい若手に具体的イメージを持ってもらうことで、問題や課題を浮かび上がらせ、それを組織全体で共有し、コミュニケーション(伝え合い)し、コラボレーション(協働する)をする。

どっちにしても、スタートは「見える化」である。

今朝、犬の散歩をしていてふと、その「見える化」の効能について考えていると、違う視点が見えてきた。

つまりその、「CCPMによる見える化」というやつは、何も他人さまに対してだけではなく、

自分にも向けられているのではないか、ということに気づいたのである。

「これがオレサマの経験と勘なのよ」、とかなんとかホザイてみたところで、

私を含め多くの人は、自分自身の行為について、わかっているようであまりよくはわかってない。

暗黙知を形式知に、と言えば簡単なようだが、生半なことではでき得ないのが現実なのである。

積み重ねた経験と、その所産としての勘。

CCPMを実践することでそれと向き合う。

まだまだ考え方としては練れてないが、備忘録的に記しておくことにした。

 

・・・・・・・・・・・・・・・・・・・・・・・・・・・・・


以上、ひのさんのCCPM講座、

ナント、「その5」までつづいてしまった。

こうなりゃ明日もあるかも知れないし、ないかも知れないが、

ひとまずお付き合いいただいた読者の方々に感謝して、お礼の言葉で終わりたい。

お粗末さまでした。

そして、どうもありがとうございました。

 

 

 

  ↑↑ クリックすると現場情報ブログにジャンプします

 

 

           

            有限会社礒部組が現場情報を発信中で

 

 

      

    発注者(行政)と受注者(企業)がチームワークで、住民のために工事を行う。

 

コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

れっつとらい

2014年10月04日 | オヤジのCCPM修業

調子に乗ってもひとつオマケ。

CCPM講座第4弾。

ではなぜ多くの人(そして意外なことにデキる人ほど)は、「つながり」を解明しようとしてタスクを細分化しようとしないのか、

についてである。

 

じつはこのことを考えていくと、安全余裕をなぜ吐き出そうとしないのか、にもつながっていく。

いわゆる「デキる技術者」は皆、この「つながり(=因果関係)」が頭のなかで整理されており、

それに基づいて仕事をしているのだとばかり、私は思っていた(つい最近まで)。

それを白日の下に晒さないのは、ただ面倒くさいだけ、もしくは、他人に説明するのに労力を割く必要性を感じないため、だとばかり思っていた。

だが、ひょっとしたら違うのではないか。

いや、間違いなく、多くの場合は違うのだ。

と思い始めたのである。

そして考えれば考えるほどそれは、確信に近づきつつある。

思いきって断定してしまえば、「わからない」のである。

「デキる技術者」と目されている(自認している)人でも、じつは「わかってない」のである。

そして不幸なことに、その「わからない」を、「わからない」と認めることができないのである。

言い換えれば、「わからない」に拠って立ち、「わからない」からスタートすることができないのである。

ではなぜ、「つながり」を詳細に検討することなしに、現場をスムーズに運営し利益を上げることができるのか。

そこで登場するのが「経験と勘」である。

経験的に「わかる」のである。

そしてまた、現場で培った「勘」が教えるのである。

「なんだかよくわからない」けれど、こっちのほうが(たぶん)正しいのだと、「わかる」のである。

しかし、現場というやつが不確実で一筋縄ではいかないのもまた、経験的に知っている。

だから、「つながり」を細分化して詳細を詰める、なんぞという手間ヒマをかけても、そのとおりにはならない。

だったらそんな無益なことはやめて、「なんとなくこれぐらいだろう」という安全余裕を、ざっくりとしたタスクのなかにざっくりと入れておくほうが、よっぽど利口なやり方なのである。

であればその安全余裕は、現場を上手く回すうえで必要不可欠のものであり、

自分を守る砦であり鎧であり、と同時に、けして他人さまに晒してはならない武器なのである。

これが、「デキる技術者」ほど安全余裕を欲しがる、というロジックである。

そして、「デキる」と人から思われている、あるいは「デキる」と自分で思っている技術者の多くが気づいていないポイントが、

「つながり」を中心にロジカルに考え、それを解明していくという行為が、じつは苦手なのだという事実。

そこから必然的に導き出されるのが、

伝えられない。

伝えられないから(ホントの意味での)コミュニケーションがとれない。

コミュニケーションがとれないから(ホントの意味での)コラボレーションができない。

したがって、技術の伝承ができない。

しょうがないから開き直り(本人そのつもりはないのですが)、

とどのつまり、口をついて出るのが、「目で見て盗め」。


それでも受け持った現場で成果を上げつづければ問題ないだろう、と思っているとしたら(思っているだろうが)、

それは甚だしい勘違いだと、私は言わざるを得ない。

個々の現場の損得や局地戦での勝ち負けの積み重ねが組織の優劣となる、という考えは合成の誤謬(※)であり、

誤った考えだと私は思う。


連々と書き散らかしたが、そろそろ今日の結論としよう。

結局のところ、クリティカルチェーン・プロジェクト・マネジメントを実践するということは、

もやもやっとした、「なんだかよくわからないもの」に頼ることなく、「わからない」ままにせず、

「わからない」に拠って立ち、「わからない」ことを「わかろう」とする行為のなかから、

「つながり」を解明し、その「つながり」を足がかりにして現場を回す。

そしてそれを「見える化」することによって、頭の中身を他者にオープンにすると同時に、

「なんとはなしにわかったつもり」だったが確とは表現しきれなかったものが、ロジックとして「わかる」。

そしてそれを自分自身の言葉(あるいは「見える化」された工程表)で伝えることができるようになり、

組織にコミュニケーション(伝え合い)&コラボレーション(協働する)の文化を根づかせる。

そういうものではないかと、私は思っている。


だから、さあ「れっつとらい」なのである。




(※)合成の誤謬(ごうせいのごびゅう)

ミクロの視点では正しいことでも、それが合成されたマクロ(集計量)の世界では、かならずしも意図しない結果が生じることを指す経済学の用語

(Wikipedeia「合成の誤謬」より)

http://ja.wikipedia.org/wiki/%E5%90%88%E6%88%90%E3%81%AE%E8%AA%A4%E8%AC%AC


 

  ↑↑ クリックすると現場情報ブログにジャンプします

 

 

           

            有限会社礒部組が現場情報を発信中で

 

 

      

    発注者(行政)と受注者(企業)がチームワークで、住民のために工事を行う。


 

コメント (4)
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

細かくしないと見えないもの

2014年10月03日 | オヤジのCCPM修業

急にスイッチが入ったかのようにCCPMについてまた書く。

怒涛の三連チャンである。

一昨日からのどれもこれもが初級編(ここんところが理解できてりゃ腹に入れやすいという意味で)ではあるが、

あまり皆さんが触れないことなので、御用とお急ぎでないかたはつきあってほしい。

興味のある方ならば、少しは得るところがあると思う(たぶん)。

 

では、一昨日の稿に、

何故ただでさえ多いかもしれない約20項目のタスクを100以上に細分化しなければならないか、

という問いをいただいた、と仮定しよう。

『されど・・・』(2014.10.01)参照

http://blog.goo.ne.jp/isobegumi/e/cda9bdfa9e5d908538c1b58f86c130ea


日数の見積りにはそれ相応の根拠があるのだから敢えてそれをオープンにする必要はない、だとか、

細かくしすぎればロスがロスを生み、全体の工程が長くなる傾向になりはしないか、

などなどの指摘を受けたことは確かにある。

現に、大雑把な項目でCCPM工程を引いている人も少なくはない。

だが私は、こここそが避けて通れないところだと思っている。

そうしなければ「つながり」が見えない、あるいは、肝心な「つながり」を見落としてしまうからである。

「つながり」(因果関係)を重視しない、または無視してしまうCCPMは、もはやCCPMとは呼べないと私は思う。

なんとなれば、クリティカル(重要)なチェーン(鎖)を優先してプロジェクトをマネジメントするからこそのCCPMであって、だから、その「つながり」を明らかにするために、必要なところまで細分化しなければならないからである。

 

例をあげよう。

野菜を煮る、と想像してほしい。

仮に、「1.湯を沸かす」5分、「2.具材を切る」8分、「3.煮る」12分、とした場合、こうなる。

 

参考資料『TOC/CCPM標準ハンドブック』(西原隆・栗山潤著、秀和システム) 

 

この場合のクリティカルチェーンは2→3のつながりで、所要時間は20分である。

これはこれで、ごくごく理解しやすいようにわざとシンプルにしているのだろうが、

具材が1種類ではないとしたらどうだろう。

玉ねぎと人参とネギが具材だとしよう。

「玉ねぎを切る3分」、「人参を切る4分」、「ネギを切る1分」がそれぞれのタスクにかかる時間である。

さらに、

「玉ねぎを煮る8分」「人参を煮る11分」「ネギを煮る1分」というふうに細分化すると、

クリティカルチェーンは「具材を切る8分」→「煮る12分」という単純なものではないことが判明する。

そこで再度工程を組み直してみると、

 

 

あ~ら不思議。

まっ先に始めなければならないのは、じつは「湯を沸かす」作業であり、つづいて「人参を切る」→「人参を煮る」とつづく。

そして、その他の切る作業は順次終わらしていけば、4分の時間短縮になる。


と、こういうふうに大雑把なタスクでは判らない「つながり」が、

タスクを細分化することによって整理され、

あまつさえ(ここからが肝心だ)それが、「見える化」の効果により、

工程を組んだ人の頭のなかだけに留まらず、

この工程表を見る人すべてに周知される。

おわかりいただけただろうか?

ジス・イズ・ザ・CCPMである。

 

 

あの~、あくまでもこれは、誰も言わないCCPM初級編で、

もうちょっとレベルが高くなると、上の工程における「湯を沸かす」「煮る」といったタスクを、そのままタスクとして扱うことがどうなのか、とかいう問題も出てきたりして(コンクリート工事における「養生」とか、あるいは材料納期とかですネ)、そうなってくると、違った意味で楽しくなってきます。

あくまでも理解しやすいようにつくった例なので、ツッコミどころが満載なのは勘弁してくださいネ。

では、また気が向けばいつか。

ひのさんのCCPM講座でした (^^)v

 

 

TOC/CCPM標準ハンドブック―クリティカルチェーン・プロジェクトマネジメント入門
西原 隆,栗山 潤
秀和システム

このアイテムの詳細を見る

 

 

  ↑↑ クリックすると現場情報ブログにジャンプします

 

           

            有限会社礒部組が現場情報を発信中で

 

      

    発注者(行政)と受注者(企業)がチームワークで、住民のために工事を行う。

 

コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

一歩前へ ~ 会社のトイレでCCPMを思う

2014年10月02日 | オヤジのCCPM修業

 

 

我が社トイレに貼ってある「仕事のカキクケコ」。

知る人ぞ知る、というよりも、

排尿に気を奪われ、社員さえもその存在を忘れてしまっている「仕事のカキクケコ」(たぶん)。

今日のテーマはそのうち最後のひとつ。

つまり、「仕事のコ」である。

 

「コ」 行動する

どんなに綿密な計画も行動が伴わなければ意味がない。

現場屋は、みずから率先して行う実践者になりましょう。

 

きのう書き忘れたことである。

というか、ごくごくかいつまんでCCPMを説明したため、実践段階において大切なことが書けなかった。

今まで何度も書いてきたことだが、建設業でCCPMが語られるうえで、

どうも抜け落ちる(か、片隅に追いやられる)ことが多いような気がするのであらためて書いておく。

 

私が提唱するところの、

「先読みする」→「やる」→「ふりかえる」「気づく」→「そしてまたやる」

というサイクルは、有り体に言えばパクリであって、

ネタ元は色々あれど、もっとも基本となっているのは、なんのことはない。

世に有名なあのPDCAサイクル、

Plan→Do→Check→Actionである。

そして「どうも抜け落ちる(か、片隅に追いやられる)」というのが、

「Do→Check→Action」、

言い換えれば、「やる→ふりかえり気づく→そしてまたやる」であって、

じつはこれこそがCCPMを実践するうえでもっとも肝要な部分、根幹を為しているとさえ私は思っている。

つまり、計画→実行→修正の繰り返しのなかにこそ、CCPMのCCPMたるゆえんがあり、

いくら立派でワクワクする当初計画を、皆んなでワイワイガヤガヤやりながら立案したとしても、

たとえばそれが、発注者参加のもとで組み上がったとしても、

いわばそれはスタートラインにしか過ぎず、

実践段階での泣き笑いを盛り込みながら練度の高い工程にしていくことを抜きに、

ただカタチだけに終始していては、クリティカルチェーン・プロジェクト・マネジメントの凄みは実感できないし、

その恩恵にあずかることもできないのである。

 

な~んてことを、

男子用トイレの真ん前に貼っている「仕事のコ」を見ながら、

排尿に気を奪われず、マジメに考えてしまった朝。

一歩前へ、

思わず踏み出す私なのだった。 

 

 

 

  ↑↑ クリックすると現場情報ブログにジャンプします

 

           

            有限会社礒部組が現場情報を発信中で

 

      

    発注者(行政)と受注者(企業)がチームワークで、住民のために工事を行う。

コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

されど・・・

2014年10月01日 | オヤジのCCPM修業

 

ある現場の総合工程表。

同業の皆さんなら説明は不要だろう。

横線は作業の日数を表していて、

そして、下にある曲線の縦軸は工事の出来高(お金)。

すなわち、これで判るのはどれだけの金目を消化しているかであって、

どの作業が工期に影響を与えるのかはわからないし、

厳密にいえば、工事が進んでいるのか遅れているのかもわからない。

なにより、作業と作業の間の「つながり」がわからないので、

何がどうしてどうなってああなってこうなるのかが、この工程表を見ただけではわからない。

「つながり」がわからないということは、これを土台として話し合いができないということであり、

すなわち関係者がコミュニケーションを図るための道具としては、まったく用をなさないということである。

「そんなことがわかっていてなぜ?」

と思うアナタは正しいが、これで管理しなさいと官から義務づけられているのだから、

たかが私ごときが否定はできない。

(公共工事の場合は)否応なしにつくる必要があるのだ。


一方、これ。

 

 

CCPM工程表。

同じ工事のものである。

まずもってヴィジュアルが大きく異なるのは、作業項目の数。

上の総合工程表の作業の項目が約20なのに対し、

(それでも5,000万円ぐらいの工事にしては多いほうだと思う)

ここでは100を超えている。

それだけ詳細に積み上げているという表れである。

しかし、本当の意味でこの工程表が優れているのは、

作業と作業の「つながり」を基本としてつくられているということであり、

そのおかげで(直接的に)工期に影響を及ぼす作業や、作業間の因果関係が理解しやすいという点にある。

ということは、コミュニケーションツールとしての威力も持っているということ。

だが、ここまでならネットワーク式工程表と変わりはない。

最大のポイントは、各作業のつながりの最後尾に置かれたプロジェクトバッファ。

一つひとつの作業日数を見積もるときにとる安全余裕(バッファ)を、各作業から引き離して、

プロジェクトでもっとも守られるべきもの、すなわち納期の前にまとめておいて、

一つひとつの作業の進捗ではなく、バッファの増減でプロジェクト全体の工程を管理する。

価値を見出さない人にとっては「たかが」だろうが、

私にとっては「されど」。

いやいや伝家の宝刀なのである。


これがクリティカルチェーン・プロジェクト・マネジメント(CCPM)、

(今ここにいる私の)原点であり、最大の武器。

今さらながらではあるが、そう感じさせてくれることがつづき、

あらためて書き留めておこうと、そう思い立った。

長いことやっていればマンネリにもなり、

いつもいつでもテンションとパッションが持続でき得ないおのれに対し、

自戒をうながす意味も込めて。



 

  ↑↑ クリックすると現場情報ブログにジャンプします

 

           

            有限会社礒部組が現場情報を発信中で

 

      

    発注者(行政)と受注者(企業)がチームワークで、住民のために工事を行う。

コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする