メッセージ。 - にゃー
# にゃー
たぶん、詳細設計書が必要かどうかは、いま(あるいはここ数十年ずっと)起こっている問題の本質じゃない。
より本質に近いことは、コの国の開発では詳細設計書を作成するために必要な期間や工数がないことだ。上流レベルでの仕様変更が多発したり仕様が決まらなかったりした場合でも、納期が変わらなかったり下流に落ちてくるお金が変わらなかったりする。そもそも始まる前から、無理な納期や無理な予算でやることを強いられる「やるしかない」案件が多すぎる。そんな状況で、正しい内容の詳細設計書を正しい方法で作ることができるだろうか?
ソフトウェアの開発には時間や工数がかかること、よくあるウォーターフォール型で開発を進めるなら要求・機能・詳細設計で仕様変更が発生したときには、上流側がしかるべき工期延長と予算増加を受け入れなければならないこと、とはいえフェーズが詳細に進んでから上流仕様の問題点を発見しえないリスクはそれなりに大きいのでリスクバッファが必要なこと、そしてこれが重要なことだと思うのだが、リスクが現実の問題に顕在化してきたときに、より下流や弱いところばかりに皺寄せが行かないようにしなければならないこと、そういったことを、発注元から最下流の現場まできちんと理解していなければならない。
だが実際にはそれができていない。全般的に、コミュニケーションレベルの問題が多いような感じがする。日本には言葉で議論する土壌がないのと、上流(客)=偉い、下流(店)=口答えは許されないという風習によって引き起こされているのではないかと思っている。そういうこともあって、とくに問題になりがちなのは、これまで付き合いのないお客やチームでの案件だ。流動性の低い環境ならそれでもいいのだが、そうではなくなって問題が起こっている。日本の風習や土壌がスケールを阻んでいるといえるかもしれない。
より本質に近いことは、コの国の開発では詳細設計書を作成するために必要な期間や工数がないことだ。上流レベルでの仕様変更が多発したり仕様が決まらなかったりした場合でも、納期が変わらなかったり下流に落ちてくるお金が変わらなかったりする。そもそも始まる前から、無理な納期や無理な予算でやることを強いられる「やるしかない」案件が多すぎる。そんな状況で、正しい内容の詳細設計書を正しい方法で作ることができるだろうか?
ソフトウェアの開発には時間や工数がかかること、よくあるウォーターフォール型で開発を進めるなら要求・機能・詳細設計で仕様変更が発生したときには、上流側がしかるべき工期延長と予算増加を受け入れなければならないこと、とはいえフェーズが詳細に進んでから上流仕様の問題点を発見しえないリスクはそれなりに大きいのでリスクバッファが必要なこと、そしてこれが重要なことだと思うのだが、リスクが現実の問題に顕在化してきたときに、より下流や弱いところばかりに皺寄せが行かないようにしなければならないこと、そういったことを、発注元から最下流の現場まできちんと理解していなければならない。
だが実際にはそれができていない。全般的に、コミュニケーションレベルの問題が多いような感じがする。日本には言葉で議論する土壌がないのと、上流(客)=偉い、下流(店)=口答えは許されないという風習によって引き起こされているのではないかと思っている。そういうこともあって、とくに問題になりがちなのは、これまで付き合いのないお客やチームでの案件だ。流動性の低い環境ならそれでもいいのだが、そうではなくなって問題が起こっている。日本の風習や土壌がスケールを阻んでいるといえるかもしれない。
Comment
Trackback