読者です 読者をやめる 読者になる 読者になる

亀岡的プログラマ日記

京都のベッドタウン、亀岡よりだらだらとお送りいたします。

「締切りは絶対に守る働き方」と「壊れたダンプカー」

雑記

二つの好対象なエントリ、それに自分の周りの反応もそういえば割れたなあ、なんてことをおもったのでそこら辺をつらつらと。

まず、記事っていうのはこちら。

まずは中島さんの話。締め切りを絶対に守る⇒スタートダッシュし最後に流す仕事術 というお話。

これでは「プロの仕事」とは言えない。その根底には「締め切り=努力目標」とう考えがあり,「目標に向けて精一杯努力をすることが大切」という体育会的な姿勢がある。そして最もいけないのが,「最初はのんびりしていても最後に頑張ればなんとかなる」,という「楽観的なラストパート思考」である。

「ラストスパート」なもの作りの一番の欠点は,最後の最後まで,そのタスクの本当の難易度がわからないという点にある。どんなタスクでも,「やってみないとわからない」部分はどうしてもある。個々のタスクに「本気で取り組む」タイミングを遅らせれば遅らせるほど,「予想外に時間がかかってしまってほかの人に迷惑をかける」可能性が高くなる。

Software is Beautiful:第2回 「締め切りは絶対に守るもの」と考えると世界が変わる|gihyo.jp … 技術評論社
(強調筆者)

理想論だけでなく、現実論としても的を得ていると思う。
まあもう言い古された言葉ではあるし、エントリでも何度も言われていることなんだけれど、「実際の製品は作ってみないとわからない。」早め早めにリリースして使用の齟齬を取り除いていくことは重要だし、それをやらずにソフトウェア開発をするのはいまや無理ゲーだと思う。
(まあまだまだ無理ゲーを繰り返している会社は星の数ほどあるわけですが・・・)

しかし、これがシステムとして機能せず、有能な一個人において行われると、「壊れたダンプカー」になってしまうのかな、と。
壊れたダンプカーとは。

なんらかの要因があってこれまでの最高スピードでモノを上げた場合、上司や顧客(要は直接作ってない人)はそれを「最高スピード」ではなく「平均スピード」もしくは「最低スピード」と錯覚してしまう、ということ。

 一回スピードを上げてしまう(←ここ重要)ことで、次以降も「このスピードで上げるだろう」と思い込んでしまうことなんですな。要はブレーキ壊れたダンプカー。

Ž~‚Ü‚ê‰ó‚ꂽƒ_ƒ“ƒvƒJ[

(強調筆者)

そう、序盤に開発スピードを上げリリースを繰り返すことで、ステークホルダーは、「もうできてる」と思い込み、次回以降の要求がどんどんエスカレートするんですよ、と。

んで、どういうときにしおれが起こるかというと、やはり組織としてそういうリリースファースト的なアプローチに慣れていないとき。そしてそこに陣取るステークホルダーが体育会系の残念な人たちだった場合。
こういう状況は組織の理解を得られずにアジャイルしたり、個人がライフハックに感銘を受けてやたらと精力的な働き方をするとき起きちゃう気がします。よくライフハック本は、まず個人が変われ見たいなことが書いてあったりしますが、働き方を個人で決められるほど日本社会は解放的じゃないと。

文字とおりのライフ八苦になってしまうわけで。

結局人を巻き込む力がないと、(組織によっては)つぶされてしまう、という話なのではないかなと。

働き方を変えることも、どうやってマイルドに変えていくかも、まあ自己責任ということで。ひどい。