ニーズ/シーズ指向、改善型開発と脆弱性を排除する構造設計(その2)
ニーズ/シーズ指向、改善型開発と脆弱性を排除する構造設計(その1) - 練習帳のつづき。
改善型開発 〜 システムを作るのではなく育てるという発想 - kuranukiの日記（移転しました）→ http://kuranuki.sonicgarden.jp
まず断っておくが、俺は発注側の窓口である企業内システム部門の人間だ。だから、SIerの内情は良く知らないし、たぶん迷惑をかけている側になるだろう。
「よく知りもせずえらそうな事を言うな」というのは、そのとおりなのだが、まぁこういうこを感じるユーザもいるという事で一つ。
「改善型開発」ってなんだろ。
俺なりの理解では、「改善型開発」っていうのは
- 最低限の機能を有したコア(または、ベース)のシステムはSIerが予めもっている
- そのシステムを現場で動かしながら、必要な部分について細かく開発していく
- 追加で開発する部分も、同じような考え方で開発する(はてなの近藤社長いうところの完成度50%でのリリース)
って感じだろうか。多分前提とするレイヤーの違いで理解が正しくないような気がするが気にしない。
疎結合とかオブジェクト指向とかのキーワードにきっと関係があるんだと思うけど、細かい分析をするにはかなり勉強不足なのでここでは触れない。
重要なのは、少しずつ開発が続いていくってことと、永遠に未完成(いい意味で)ってことでいいのかな。
ニーズ指向でもシーズ指向でも(ニーシーズ指向でも)無い
先日の俺のエントリニーズ/シーズ指向、改善型開発と脆弱性を排除する構造設計(その1) - 練習帳で書いたように俺はニーズ指向とかシーズ指向を否定している。
実際このエントリの「改善型開発」はそのどちらでもない。
社内にノウハウを抱えてそれをコアとして提供する点ではシーズ指向に似ているが、それは決して「こんなシーズがあるから使い方を考えよう」的な発想ではないだろう。
ユーザのニーズに合わせて柔軟に改善していくのでニーズ指向かといえは、必ずしもそうではない。
実際に存在するものに対してであれば、何が足りない、これができないといった具体的な要求を出しやすいのである。
これは、ニーズに対応するというよりも、見えなかったニーズを見えるようにしている(場合によっては、思ってもいなかったニーズを創造する)わけで、いわゆる「ニーズ指向」とは一線を画する考え方だと思う。
じゃあ、グランドデザインというか、方向性は誰がきめる?
「改善型開発」は結構よさそうな気がするが、改善が継続するがゆえにはっきりしておかなければならない事がある。それは、追加すべき機能の取捨選択や、どういう方向に改善していくかということを誰が責任をもって行うかという事だ。
「改善型開発」のエントリにはこの部分は書いていない。
「それはユーザサイドの仕事でしょ?」と丸投げされいるような不安と不満を思わず感じてしまう。
ユーザサイドは、ユーザサイドで、近視眼的な判断しか下せないのが実情だ。
この責任問題についてのヒントとなりそうなのが、高木浩光＠自宅の日記 - 「高橋メソッド」的突貫工事と、脆弱性を排除する構造設計は両立するかである。
というわけで、(その3)につづく。
ああ、又わけの分からない事になってしまった。
