1000年アーキテクチャー(07)

設計工程について考えてみたいと思う。設計工程は各アウトプットを分かりやすくするためにウォーターフォールモデルでの開発を想定して考える。

詳細設計工程及びテスト工程について考えてみる。詳細設計工程は採用される製品やフレームワークに依存する内容が多くなる。ここで製品ごとに設計する内容が、システムを使う人、システムの提供する人、システムを作る人の誰が利用するための機能か明確にする必要がある。そうすることにより、製品の入れ替えが発生した際、システムの利用者(ユーザ)に影響がある機能が限定できるだめ、継承しなくてもよい機能が増え、選択の幅を広げることができる。システムを提供するひとや作る人は、製品にあわて利用方法を改めて学習すればよい。

テスト工程も同様で、各テスト項目が、どの人の操作を想定した項目なのか明確化する必要がある。それにより、システムを使う人を対象とした試験項目は今後も再利用するべき試験項目となる。また、システムを作る人を対象とした試験項目は、システムとしての挙動が確認できればよいようは試験項目もあるため、事前に机上で試験結果の期待値を整理するのが難しい場合がる。このように試験項目が誰が使用することを想定しているのか明確にすることにより、試験の準備や、再試験の効率が良くなるばずと考える。

システムの奴隷(2)

現在のシステムは多結合過ぎて、繰り返されるメンテナンスにかかる手間も指数関数的に増えている。もはやシステムの維持のために人間が徹夜して一生懸命働かざるを得ない状況にあり、SEはシステムの奴隷と言える。

さて、システムの奴隷にならないためにはどうしたら良いか。それは単純にシステムを停止させたり、廃止する権利を人間に戻す必要がある。今の日本の開発現場の多重請け負い構造では、階層ごとに役割がわかれているため、全体像を把握できない。そのため、みんなが極力影響を出さないように、システムのご機嫌を伺いながら開発を続けている。

ならば、影響がわからないものは停止して然るべきと考えることはできないか。このようなにどのような影響が出るかわからないシステムは負の遺産と捉え、影響がわかるように作り直せば良いのではないか。人間が主導権を持ってシステムと付き合っていくにはscrap and buildも必要と考えた。