標準化のトレードオフ その2 - 本当に狼男ですか? -
「ソフトウェア開発に銀の弾丸はない」といいますが、ソフトウェアプロセス成熟度の改善の序文には
「ソフトウェア危機」は死んだ!
と書かれています。でも、ソフトウェア開発の混乱はなくなっていません。銀の弾丸を見つけたはずなのに、うまくいかないのはなぜでしょうか?
そういえば、ソフトウェア開発を熊とのワルツに例える本もありました。
銀の弾丸は昔の狼男には効果があっても、いつのまにか狼男が耐性を身につけたのかもしれません。もしかすると国防総省には狼男が居たかもしれませんが、一般向けのソフトウェア市場に居たのはドラキュラで、少しでも早く仕様を陽のあたるところに出すべきだったのかもしれません。
でもドラキュラも銀の弾丸を撃たれれば、死にはしなくても少し弱まります。方向性が定まらずにプロジェクトが混乱している時は、誰か声の大きい人が方針を決めるだけで、混乱が解消するからです。
同じように暗がりから迫る狼男に、光を当てれば少しはひるむでしょう。やり方が決まれば、あとは工夫で乗り切れるかもしれません。
プロジェクトにはゴールがあり、同じ開発はありません。しかも最近は開発期間が短くなっています。なんとなく開発がうまくいって、それに開発者が慣れてしまえば、その方法を悪くいう人は少ないでしょう。
では、ソフトウェア開発の問題は何で、どの開発法が良いのでしょう?
昔は簡単でした。とにかく動く事。信頼性が低くて動かないシステムが多かったので、バグが少ない事が第一でした。
そして、その次は生産性でした。実装方法が限られていましたので、1ヶ月に何行を開発できるかで生産性が測れましたので、同じ信頼性なら生産性の高い方が良かったでしょう。
今はどうなんでしょう?その方法が良いと言える条件は何でしょうか?
不具合の現象が問題だったのか?生産性が問題だったのか?必要な時にリリースできないのが問題だったのか?世の中の変化にあわせられない事が問題だったのか?開発者が苦しんでいたのが問題だったのか?それはプロジェクトによって異なります。
ソフトウェアプロセスはソフトウェアと似ています。問題が明確なら正しい答えを出せますが、問題が曖昧なら動いたように見えていても、後から問題が発覚するかもしれません。
また、ソフトウェアがレガシー化するように、人には慣性力があります。慣れている方向には簡単に動きますが、方向を変えるのは大変です。
ソフトウェアの様に様々な制約の中で良い方法を選ばないといけません。制約を考慮して、より良い実現方法を考えます。
様々な方法の理解が欠かせませんし、プロジェクトの問題を見極める事も必要です。様々な方法のトレードオフを考えて、問題を解決しないといけないのです。
« 標準化のトレードオフ その1 - 標準化のパターン - | トップページ | 標準化のトレードオフ その3 - 応用のできない習熟 - »
「私のアジャイル」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 「任せて、任せず」「魚を与えるのではなく"釣り"を教えよ」(2021.08.16)
コメント
この記事へのコメントは終了しました。
« 標準化のトレードオフ その1 - 標準化のパターン - | トップページ | 標準化のトレードオフ その3 - 応用のできない習熟 - »
ソフトウェアプロセスを決定するものもシステムに対する要求ですよ。
一回しか使わないソフトウェアのプロセス、レガシーのコードしか残っていないソフトウェアを改造するプロジェクトのプロセス。気の知れた達人たちが作業するプロセス。初めて顔を合わせる人間だけで開発する場合のプロセス。
みんな、違うはずです。その違いを生み出すものも、システム開発に対する「要求」だと考えると、どこから違いが生まれるのかがわかるんじゃないかな?
投稿: おおのすすむ | 2014年2月 3日 (月) 16時14分