手法の限界を見た管理

昔ソフトウエアの開発には、大別して

• 直線的に進むウォーターフォールモデル

• 色々と試行錯誤するスパイラルモデル

の二つの方法がありました。なお、両者は典型的な動きで

ウォーターフォールモデルでも手直し修正あり

という場合も多くあります。ウォーターフォールモデルは、アメリカのモノづくりの

技術者の検討重視

という観点から、相性が良く、アメリカのソフトウエア工学の成果として、日本にも輸入されました。

一方、日本のモノづくりでは

現場の力で手直し

が重視されていたので、ウォーターフォールモデルを使っても、現場での修正があり、状況によっては実質

修正で完成するスパイラルモデル

という状況もありました。

さて、今回は

スパイラルモデル（試行錯誤）の使い方

について、もう少し考えました。まずは、以下の二つの使用法の区別が必要です。

1. 概要が見えているが細部の調整用

2. 要求が不明確なので作りながら完成度を上げる

1．の概要がある場合は、更に二つに分かれます。設計図的な完成度の高いモノなら、ウォーターフォールモデルの手直しになります。一方、前例や類推の効くモノから作り出す場合は、スパイラル的に完成度を上げていく必要があります。

さて、2．の要求が不明確な場合でも

何らかの叩き台

が必要です。前例があればよいのですが、無ければ以下のような手段で作ります。

1. 一般論から導く

2. 類推を効かせて他のモノを使う

1．の一般論の一例として、知的生産の一般図を挙げておきます。

この図は、一般的過ぎと思う人も多いでしょう。しかし、こうした切り口だけでも、検討が進みました。

一方、類推の活用ですが、例えば

物流のリサイクルを考える時
水の循環システムからヒントをえる

等の発想があります。

しかしながら、こうしたスパイラル手法には

モデルが収束しない

危険性があります。

例えば

色々な立場での要求が増えまとまらない

と言う場合があります。また別の状況では

相矛盾する要求

で片方を満たすと、他方が崩れる。この状況で、右往左往する場合もあります。飛行機を設計するとき

遠くまで飛びたい
高速を求める
多くの人を乗せたい

等の要求を全て聞いていると、どんどん大型の飛行機になってしまいます。

そこで、エンジンの力などの制限があると、大きさが決まり

客席数と燃料搭載

は、片方を増やすと、もう一方が減っていきます。

こうした、要求の収束の見通しなしに

とりあえず叩き台から議論

と言う発想は、失敗に繋がります。

こうした

手法の限界

を知り管理することが、指導者の役割ですが、悲しいかなこれをできる人は少ないです。さらに言えば、この大切さを知らず

よそで成功したからここでも

という人もいますね。