スポンサーサイト

  • 2016.05.30 Monday

一定期間更新がないため広告を表示しています

  • 0
    • -
    • -
    • -

    TOC/TOCfE関西分科会〜CCPMでもっと工期短縮!!〜 に参加してきました!

    • 2012.12.08 Saturday
    • 07:08
     
    2012/12/07に開催されました「TOC/TOCfE関西分科会〜CCPMでもっと工期短縮!!〜」に参加してきました。


    ■Project Managerは2度死ぬ


    ■市谷(@papanda)さんのスピーチ

    ■DevLoveの紹介
    • 主旨は各現場同士のフィードバック

    ■なぜCCPMなのか?
    • ゴールデンサークル
    • 何のために、どのように、何を実現するのか?
    • Why・・・納期を守りたい
    • How・・・クリティカル・チェーンの発見
    • プロジェクトを安全に運行したい
    • チームはバッファーに守られる
    • PMはバッファーに集中できる

    ■初めてのCCPM
    • 基幹システムの再構築
    • 長く続く保守の中から案件が産まれた
    • 問題点
    •  →納期まで時間が足りない
    •  →メンバー内に外部の人が多い(≒業務知識が足りない)
    • 何故そうなったのか仮説
    •  →不信感からくる過剰見積もりが起きていた?
    • 保守チームの二人が生命線
    • 作戦
    •  →見積もり納期を半分にしてみる(半分は当てずっぽう)
    •  →必要最低限の作業になるはず
    •  →顧客にも作業移管
    •  →迷わない、初心者を迷わせない
    • 集めたバッファをプロジェクト全体で使って行く
    • この時は、集めたバッファーを顧客と共有しなかった。(恐怖心から・・)
    • 切り札のベテラン二人の負荷を抑える(ボトルネックにならないようにする)


    ■バッファー管理は?
    • Excelでバッファー管理


    ■想定外の作業が発生!
    • システムテストが顧客ではなく、開発チームの作業となってしまった。
    • 切り札のベテランのバッファーを使うことで乗り切る。


    ■結果!
    • 納期には間に合ったが、メンバーは疲れ切っていた。
    • メンバーは削られたバッファーの行先が見えず不安感をもっていた
    • メンバーには全体像が見えていなかった


    ■アンチパターン
    • バッファーを隠したので、WBSの2重管理になってしまった。
    •  →PMの作業量が増える
    • 顧客には正直に話すべきだった


    ■2回目のCCPM
    • また納期まで時間が少ない!
    • 作戦
    •  →またバッファーを半分にする
    •  →またベテランを切り札にする
    •  →プロジェクトファシリテーションを使用した
    •    →プロジェクトの見える化
    •    →タスクかんばん
    •    →バーンダウン・チャート
    •    →朝会、振り返り
    •    →インセプションデッキ
    •    →ODSC


    ■自分への問い
    • メンバーを信じられるか?
    • メンバーは進捗を正しく報告しているのか?
    • レンガ職人の話・・・自分はレンガを積むのか or 協会を作るのか
    •  →目的を把握しているのか?


    ■問題発生
    • 作業項目が増えた。最初と違う作業が増えた


    ■2回目の結果
    • 納期には間に合ったが、やはりメンバーは疲れ切っていた
    • 1回目と異なり、メンバーがチームとなった


    ■それでは、CCPMの適応条件は?
    • PMとメンバーとの信頼関係


    ■CCPMが敗れるとき
    • 圧倒的なマルチタスク!
    •  →保守と開発が同じチーム
    •  →優先度がドラマティックに変化する
    • 対策
    •  →スケジュールバッファーを取る
    •  →切り札であるベテランの負荷を抑える
    • 問題
    •  →システム障害や3.11震災など
    • 結果
    •  →サービスインできたが、追加予算が必要だった
    •  →マルチタスクはPMを殺す
    • まとめ
    •  →不確実に対し、バッファーマネージメントは有効
    •  →マルチタスクは死ねる


    ■3つのバッファー


    ■バッファーの活用
    • スコープを固定…CCPM:納期を動かす
    • 納期を固定…アジャイル:スコープを動かす


    ■まとめ
    • 何を作っているかが不明瞭・・・Lean…セットベース
    • どうやって作るかが不明瞭・・・CCPM…ポイントベース
    • バッファーで助かるのは、2回まで!



    ■CCPMの実績や社内適用支援について






    ■柴山(@SHIBAO800)さんのスピーチ

    ■最大規模1000人規模で使用

    ■CCPMは時間をコントロールする手法
    ■従来ではSCOPEを調整



    ■CCPMでは、SCOPEとRESOUSを調整



    ■AGILE(アジャイル)では、TIMEとRESOUSを調整




    ■CCPMでのボトルネックは?
    • クリティカルチェーン
    • クリティカルパス


    ■マルチタスクとシングルタスク
    • マルチタスクは優先順位を見誤る
    • マルチタスクではメンバー内の誤解も生じやすい


    ■実績VS予測
    • CCPMは残り日数で管理
    • ファミレスで料理待ちのとき、後●分で持ってくるとはいうが、現在60%の出来あいですとは言わない。


    ■個別余裕とプロジェクト余裕
    • 本人が品質を考えて、時間すべてを使う場合、調整が難しい
    • 本人が余裕を使うと、過剰品質になりやすい


    ■CCPMは終わりを3点見積もり。 最短←→最長
    ■クリティカルチェーン以外のタスクは後方で作業する。
    ■CCPM実施のポイント:納得のいくギリギリ見積もり
    • (1)見積もりを半分にしてみる
    • (2)経験上早かった期間
    • (3)リーダの独断
    • (4)担当者が考える最短期間
    • あくまでもこの時の見積もりは目標であり、約束ではない!
    • 納得できる目標を作ることが大切


    ■プロジェクトバッファーの期間をいじらない
    • 基幹に対して、バッファーが短くなってしまう
    • 遅延が見えづらくなってしまう
    • 本来はバッファーを消費した状態のままとする


    ■適用範囲を見極める
    • スコープに大きな変化が少ない物
    •  →なぜならCCPMは、クリティカルチェーンを探すものだから
    •  →タスクが変動が大きいとクリティカルは判らない
    • 期間とボリュームがある程度あるもの
    •  →CCPMは無駄を削るものなので、小規模だとそもそも無駄が少ない


    ■CCPMやりやすい形
    • 内部設計
    • コーティング
    • テスト工数


    ■スモールスタート
    • CCPMはまず小さく初めて見て、最後までやりきる
    • 成功基準を決めないとダメ


    ■CCPMは基本的に計画的制御プロセスに属する
    • 計画以上には短くならない
    • チーム内で考えるベストの最短日数が計画できるかがポイント
    • クリティカルチェーンがゴロゴロ変わると逆に遅れやすい
    • つまり事前に最短日数を見えるかできる


    ■注意点
    • CCPMはあくまできかっけ
    • 工期を短縮するのはあくまで作業をする人


    ■NTTデータでの取り組み
    • 専用チームを作った
    • データ分析を行うチーム
    • 全社教育制度・・・若手リーダを育てている。役600人ぐらい受けている
    • 社内プロジェクト管理ツールがある

    ■CCPMの組織への導入
    • 腹をくくる

    ■ゴールデンサークル
    • 悪い例:What → How → Why
    • 良い例:Why → How → What


    ■組織で考えてみる
    • What・・・ソリューション
    • How・・・コンテキスト、対象顧客、組織
    • Why・・・ビジョン、目標、問題


    ■コンテキストは重要
    ■組織に広げるには、信頼貯金が重要!!



    ■まとめ

    市谷さんと柴山さんという著名人お二人のお話しが聞けるという、貴重な体験が出来ました。
    それに今まで曖昧だった、ウォーターフォール、CCPM、アジャイルのそれぞれの違いが理解できたのが大きな収穫でした。




    TOC/CCPM X リーン開発セミナーに参加してきました

    • 2012.10.05 Friday
    • 03:56
     
    2012/10/3 「TOC/CCPM X リーン開発」のセミナーに参加してきました。
    気になった個所をφ(・ω・ )メモメモ。

    ■製品開発マネジメントの問題点とリーンTOC

    • DBR・・・製造残率を減らす
    • CCPM・・・開発向け手法
    • 新製品の成否は開発コストより、開発時間を減らす方がよい。
    • 統計的に、SE系の労働時間は他業種より長い。(本当はもっとヒドイ?)
    • つまり、常に開発に追われ品質に影響を与えている可能性が高い。
    • WBS
    •   →スコープ対象が変わる。
    •   →決まらないと見積もりできない。
    •   →粒度のバラツキが発生しやすい。

    • リーン開発とは
    •   →各タスクからバッファーを減らす
    •   →客が望むタスクだけを残す
    •   →技術調整のタスクを減らす。
    •     →先行事例、他プロジェクト応用など、知識・経験を活用することでタスク時間を減らす。

    ■Q&A


    Q.4〜5人でのリーン開発事例は?
    A.日本で1〜2人の形でスタートしているところもあり。
    小さいチームでも、知識ギャップや蓄積不足は同じだった。


    Q.小さい会社でもリーンは有効?
    A.初期見積りなどの、見積もり予想を体系たてることで重要。


    Q.知識の共有方法は?
    A.組織間を通す、横串の繋がりを作らないと無理。


    Q.いつ知識検討をやめるのか?仕様変更ではまたやり直し?
    A.仕様変更ということは、顧客が価値を求めているということなので、前提としていたことが間違っている可能性が高い。その意味では、仕様変更では、知識検討見直しは必要。


    Q.リーンから、CCPMへの切り替わりタイミングは?
    A.リーン的にいうと、知識不足がなくなった時が、CCPMへの切り替わりタイミング。
    まず知識ギャップがどれくらいあるのか、ギャップ表を最初に作成しておくのも一つの方法。



    ■まとめ的感想


    今回の話で感じたのは、リーンで説明されていた知識ギャップを埋める作業をいつ辞めて、いつから開発作業を行うのか、切り替えタイミングが不明瞭なことでした。

    知識ギャップを埋める調査が重要なのは判るのですが、現実的には時間が限られているのでいつかは開発を始めないといけません。
    知識ギャップがあるうちは開発するなと言われても・・・・
    どうも理想論すぎて現実味が感じ取れませんでした。

    リーンスタートアップなどは、すごく共感できたのですが、本日のセミナーで説明されたリーンが指すものは、大分異なる印象でした。

    もっとリーンについて勉強する必要がありそうです。


    PR

    calendar

    S M T W T F S
    1234567
    891011121314
    15161718192021
    22232425262728
    293031    
    << October 2017 >>

    selected entries

    categories

    archives

    recommend

    recommend

    recommend

    recommend

    profile

    search this site.

    others

    mobile

    qrcode

    powered

    無料ブログ作成サービス JUGEM