Ognacの雑感

木漏れ日々

目次

Blog 利用状況

書庫

ギャラリ

「変更に強いシステム」は「どんな変更も簡単に可能可能」ではない

10日〆は毎月10日に処理します。当日が休日のときは、直後の営業日に処理といったルールだと、機械的に決まります。(営業日カレンダ機能が必要となるケースもありますが)
しかし、10日前後の手薄な日などと曖昧な日のときは、手動で処理日を設定することになります。
そんなシステムで、月ごとに 日を入力を設定できるように、1がら月末日までの値が入力可能な項目を作り、処理日を設定できるようにしました。
 その後、日の入力欄はカレンダ機能が欲しいと要求があり、カレンダPopUpに対応しました。
カレンダPopupは特定月だけでなく、月が移動し、年も移動ができるので、当月以外の月に変更して、入力できてしまいます。
4月の処理日の入力なのに、 カレンダーをPopup表示して、6月にカレンダーを進めて11日を指定したそうです。
プログラムは日の入力欄なので,4月11日と解釈します。
ところが、ユーザーは 6月のカレンダーで入力したので、6月の処理日を11日に指定したと解釈したようです。
特定月内の日の設定なので、他の月を入力できるのはおかしいと考えます。
ところが、顧客側の言い分は「OOPは変更に強いと言ったのは御社でしょ。カレンダは任意の月に変えられので、任意に月の処理日の設定に使えるべきでしょ。
変更に強いはずのOOPがこんな変更もできないなんて、看板に偽りありでしょ。」.....なんか変。
   この誤解の問題はどこにあるのだろう.....
・日のみの入力欄でカレンダーPopupを実装したことが間違い。 
・カレンダーコントロールが他の年月に移動できるのが間違い。
・そもそも日のみ入力欄にカレンダー連動させたのが間違い。
・特定日の入力でなく特定年月日の入力で設計すべき。
いずれも該当しそうですが、カレンダ機能を実装したのが間違いだと思います。
同時に、変更に強いという言葉も誤解をうみます。ペースに近い部分の変更につよいシステムは難しいでしょう。
OOPは変更に強いという誤解はなんともならないんでしょうかねぇ。

投稿日時 : 2008年4月8日 1:46

Feedback

# re: 「変更に強いシステム」は「どんな変更も簡単に可能可能」ではない 2008/04/08 9:34 まさる

「変更」に強いというよりは「拡張」に強い作りに「しやすい」だけですよね。

第一、件の処理はOOP関係ないし。

# re: 「変更に強いシステム」は「どんな変更も簡単に可能可能」ではない 2008/04/08 10:34 やじゅ

日の入力欄はカレンダ機能が欲しいと要求があったの
だから、カレンダはつけてもいいですね。
操作性を考えると年月の移動も可能としたい。

特定月以外の月であるなら、エラーを出せばよかった
のでは?

# re: 「変更に強いシステム」は「どんな変更も簡単に可能可能」ではない 2008/04/08 11:42 trapemiya

カレンダーが他の月に移動できたことが一番の問題だと思います。カレンダーを実装したのが誤りというのは、自動車は事故を起こすから自動車に乗っちゃダメのように聞こえます。事故が起きたのならなぜ起きたのかを調査し、起きないように改良すればいいと思います。
工数の問題もあるかと思いますが、そこは意欲でがんばってほしいと思います。(何か、うちのシステムを開発しているSEさんへの愚痴みたいになっちゃった)

# re: 「変更に強いシステム」は「どんな変更も簡単に可能可能」ではない 2008/04/08 12:13 がる

がると申します。
んと…マーフィーの法則より。
「誰でも使えるものは作れない。なぜなら、バカは思いもよらないことを考え出すからだ」

# re: 「変更に強いシステム」は「どんな変更も簡単に可能可能」ではない 2008/04/08 12:16 ddnp

>・カレンダーコントロールが他の年月に移動できるのが間違い。
これだと思います。

『手薄な日』の判断には曜日が強く関わるかもしれないから、
カレンダー表示は大変良いと思います。

# しかしこの件にOOPはどう関係するんですか?

# re: 「変更に強いシステム」は「どんな変更も簡単に可能可能」ではない 2008/04/08 12:47 シャノン

「プログラムの変更」じゃなくて「年月の変更」にも強くないとOOPダメでしょ、というように聞こえる>顧客

# re: 「変更に強いシステム」は「どんな変更も簡単に可能可能」ではない 2008/04/08 12:53 Ognac

コメントありがとう御座います。
当月のみ有効なカレンダーコントロールがあれば丸く収まってました。
該当画面は、月毎のスケジュール等の設定画面なので、4月のページで、他の月の日の入力を許すのは、尚更悪い結果を招くかと。
当月のみのカレンダーを作るか、カレンダーを実装したことがダメだった気がします。
仰られているようにOOPとは無関係の話題なのですが、顧客へ「OOP指向は変更に強いんですよ」とプレゼンした様子で、顧客は真に受けて誤認してしまったようです。
コメントのように、「拡張に強い」のであって「仕様変更に強い」わけではないのです。
 SE職の中に、この区別が不明確な方も見受けられるのはどうしてだろう。

# re: 「変更に強いシステム」は「どんな変更も簡単に可能可能」ではない 2008/04/10 1:01 Pasie.

>当月のみ有効なカレンダーコントロールがあれば丸く収まってました。

どうでしょう? 収まっていないのでは?
顧客がカレンダーの実装を迫った段階で、各月の例外入力したいという期待が見えている気がします。事実、不具合時のクレームは「カレンダーの表示は当月だけにしたい」ではなく「任意に月の処理日の設定に使えるべき」ですよね。

本件の問題は、日の入力に対して、年月日を指定するコントロールを採用する際に、年月の部分をどう考えるかを顧客に確認しなかったところにあるのではないかと思います。

そして、もっとまずいのは、"日"の入力に"年月日"で入力するという非合理性に、要件定義者からプログラマに至るまで誰も疑問に思わなかったことにあるのではないかと思います。

なんでOOPはもちろん、仕様変更や機能拡張の問題でもなく、要件定義のありかたや、言われるままに実装することの不味さとか、幾人もの目をすり抜けてしまった原因は何なのかとか、そういうレベルの問題ではないかと思うのですがどうでしょう?

p.s.
ところで私などは前半部分を読んだとき、4月の処理日を6/11にしたいのかと思ってしまいました。

# re: 「変更に強いシステム」は「どんな変更も簡単に可能可能」ではない 2008/04/10 9:21 Ognac

的確なご指摘ありがとうございます。
>"日"の入力に"年月日"で入力するという非合理性に、要件定義者からプログラマに至るまで誰も疑問に思わなかったことにあるのではないかと思います。

>言われるままに実装することの不味さとか、幾人もの目をすり抜けてしまった原因は何なのか
今回の例では、日の入力に年月の無関係要素が入ることの矛盾性を指摘した、要員も居たそうです。
しかし、顧客の要望を優先するあまり、「変更実装しろ」といわれるままに GOサインを出したようです。今回のような不具合がでたら、どうするの? と尋ねたら「顧客が"日の指定にしか使わない"と言っているんだし、矛盾の責任は顧客側だから、実装しろ」....(この姿勢が原因でしょうが、後出しの言い訳っぽかった。。)
実装してしまったので、開発者側の全体責任になるかと思いますが、顧客要求の矛盾点を指摘して、譲れない点を堅持するのが大事です。......一方で、譲れ・譲れない 論争で、工期が遅れると全体に迷惑になるし悩ましい点です。 PM/PL がどちらを向いているかにもよるのでしょうかね。

タイトル
名前
Url
コメント