３つの事
システム開発時、状況判断の場面において常に頭においておく必要があることが3つある。
-
- 仕様を変更を無くす事
- 期間を確保する事
- 開発者の能力を活かす事
仕事を達成するのは開発者の能力以外に推進力は存在しえず、
期間は達成という目標地点まで到達するのに残された時間であり、
仕様の変更は推進力の方向変更である。
方向変更ばっかりしていればその場でぐるぐる回っているのと同じ状態だし、
残された時間を意味無く*1削れば時間がなくなるのは当然の事態になる。
また、それらの問題が片付いたところで、開発者の能力を殺していれば推進力は弱いわけで、
目標地点にはなかなか到達できないだろう。
大企業のウォーターフォールは推進力が無い牛歩を前提とした戦術であることはわるかないのだが、
最短経路を歩く以外に到達し得ない奇妙な難し〜い期間設定をしたり目標変更したりするため達成率は丁半博打より悪い現実となる。
端的に言えば。
仕様変更無くして、開発者達の能力に見合った期間を用意してあれば失敗する要素なんて無い。
これに。
現実として「最もらしい嘘」が各所(主に仕様変更と期間)に混ざるので、問題がややこしく見えてくる。
現場でよくある光景として
(..・Д・)＜仕様変更が入りますた。でも期間かわんないよん。
あ。もちろんリスクなんかとれないからやり方代えちゃだめね。
ってなことをじわじわ言われる。
変更されて期間かわらないなら、開発者の能力に頼る以外に無いのにそこにも制限をかける。
よくきくどこにでもある話。
デスマーチ*2って言葉をよく聞いた頃にはとてもありふれたことだった。
っつか「だった」って過去形じゃないな。
こんなありふれた話でも、仕事上関係ない同業者な人と話をすると喜ばれることもある。
簡単なお題の「こんな時どうすんの！？」って状況への問いに対しての答えが問う本人と似たようなものだからか、
なんとなく問題解決能力がありそうにおもわれるからか、
他人の不幸がたのしいのかはさておき、酒の上の与太話の域をなかなかでないのはなんでだろ。
けど。
同じ話を会議室でするとほぼ煙たがられる。
データだせとか資料が無いことかたるなとかそんな釘をさされることもしばしば。
成功の事例のほうが少ない事例と同じことしようとしていて成功できる理由を聞きたいもんだ。
ってなことを。
思っていた時期もあったが、そんな人たちは失敗するってことが頭から抜け落ちていて、
都合の悪いことは事実だろうがなんだろうが意識から外される回路を持っているらしい。
ゆえに、話すと疲れたんだな。ボク。
