「納期コミットのオーダーは結果的に納期を遅らせること」を逆手にとる - @i2key のBlog

「納期コミットのオーダーは結果的に納期を遅らせること」を逆手にとる

読み返してこの辺あ〜〜〜ってなってる
>「見積もりは予測であり約束ではないのである」とか正しい理屈を説いても基本的に意味がなく

>合気道すべきところを何故か正拳突きをしてしまう

これは超分かる。『うまくいったら終わりそうなあたり教えて。別に守る必要ないよ。ただ、すぐに作業して毎週動くもの見せてね。』が経験上、一番速いしメンタル的にもいい。

これは賛否両論ありそうな納期の話だなぁ…
個人的には事業計画に響くのでバッファを積みすぎるより遅れたら頭下げてリスケのがいいと思うが…
起きるかどうかも解らないことは認められづらいけど、起こってしまったら認めるしかないし、改善策の検討材料にもなる

これを読んで、最近どこかで見かけた「失敗を推奨する文化は、無能を許容しないという背景とセットでないと機能しない」みたいなやつとを考えている。技術的負債という言葉の当事者感覚のなさみたいなやつとかも。フムン。

主題じゃないけどここが刺さる “小難しい理屈を関係者全員が理解している必要はなく、その考え方が染み込んで浸透した状態の選択肢をいくつか用意出来れば良い” ／

“合気道すべきところを何故か正拳突きをしてしまうのである。そんなこと知らなくても良いのに。 ”

人類の「納期をコミットさせたい」という素朴な<<願い>>こそが遅延を確定させてしまう。哀しい存在だ。リリース速度と日付の確定は確率のトレードオフだから 「期日を守るならリリースは遅れる」(たしかに〜)。人間活動の認知の仕方のバグっぽいから仕組みにしないとだな

メモ

つまり、約束すると遅くなるというメカニズムを前提とした上で、約束する（日付の確定）をビジネス要件とするか、約束しない（リリース速度）をビジネス要件とするか。これすらも要件として扱うことが大事である

これ、納期コミットの件、個別のタスクにも言えるんだけど、アジャイル的なスプリントでやってると、1スプリントが1週間単位だと1週間という期間に律速されることあるよね。どう解決するべきなんだろう。スプリントを3日とかにする？

なんかCCPMで良くねって思った。

納期をコミットさせることで、結果的に納期が遅くなる。なぜなら、それを確実に守るためにバッファを取ろうとするため。納期をコミットしないことで、最短で終わる可能性がある。ただ、それが良いか悪いかはビジネス要件による。わかりやすい。

つまり約束しないという約束もありということ

納期コミットが締め切りを遅らせるというのは確かにある

なるほど・・・理論を理解してもらうように頑張るよりも、行動や意思決定の候補の中に理論をすり込んでコミュニケーショする方が上手くいくのかも💡

バッファの時間 x 残り時間を使い切る法則（パーキンソンの法則）によって、結果的に遅くなるという話。（わかる）

一方で適切な締め切りを置かないと、速度が出にくいのもあるので、個人的には良い感じの締切も置いておきたい気持ちもある。

“また、付け加えると、「見積もりは予測であり約束ではないのである」とか正しい理屈を説いても基本的に意味がなくて、期日守るからリリース日遅くなる or 期日なしでリリース日早まるけど確度80%、のようなトレードオフの形にして選択可能な状態にすることが重要である。”

なるほどなぁ / 「納期コミットのオーダーは結果的に納期を遅らせること」を逆手にとる

技術に鈍感なマジョリティ施策に有効

>思想みたいなものはあえて声高に説明するのではなく構造の中にそっと織り込んでなじませておけば良くて、そうすれば無意識下におかれ自然とスケールする。思想を理解しないと適用できないみたいな状態だと理解出来る人にしか

ぐわあああ(吐血) / "思想みたいなものはあえて声高に説明するのではなく構造の中にそっと織り込んでなじませておけば良くて、そうすれば無意識下におかれ自然とスケールする。(中略)方法論者は、その小難しい理論が如何に正しいか・素晴らしいかを説明してしまうのである"

“「見積もりは予測であり約束ではないのである」とか正しい理屈を説いても基本的に意味がなくて、期日守るからリリース日遅くなる or 期日なしでリリース日早まるけど確度80%、のようなトレードオフの形にして選択可能な状態にすることが重要である”