・ソフトウェア開発をどう考えるか
出来上がればそれでいいなら、難しいことは必要ありません。できるまでやり続けるだけです。評価基準ができたかどうかだけなら、それでいいのです。
そういう価値基準しか与えず、出来上がったものに不具合があれば非難するのは理に適いません。
・品質の基準を問う
ソフトウェア工学も、開発プロセスもすべては「品質」に向けられています。プロダクトの品質を保つにはプロセスの品質を問う流れになるのも、きわめて工学的手法と言えます。
これらを評価するには、エンジニアリング的にソフトウェア開発を捉える必要がありますが、これができない人が経営層にはまだいる現実があります。
・ビジネスリスクの前に開発リスクを理解するべき
開発にはリスクを伴う部分があります。できるかできないか等というレベルではなく、できても、品質がどうかとか、そういうレベルです。
開発におけるリスクを評価できないのであれば、工業製品としてギャランティしなければならないことがどれだけのリスクを背負うことになるのかわかる必要があります。
結果から人の能力が低いというのであれば、人の能力を上げる施策が必要です。これが改善です。改善を回すことが開発のリスクをコントロールすることです。原因を断じておきながら放置するのであれば、それは経営者としての背任行為といえるでしょう。
こうした組織は残念ながらまだあるのでしょう。
目を背け続けることは、何も生み出さないのです。小さくとも改善を回し続けたモノが最後には勝つのだと信じています。
