揺さぶりによる気付き

やり慣れた方法に頼っていると、変化できなくなることがあります。また、新たな(よりよい)方法に気付くことができなくなることがあります。
もちろん、それに気付くべきなのです。
自ら気付くことができれば、それに越したことはありません。
しかし、自ら気付くことができなければ、そとから「揺さぶり」をかけると、気がつくことがあります。
いつも使っている道が通行止めだったので止む無く行った道が、実は知らなかった近道だったというようなものです。
詳しくはコチラ、
コンサルタントの秘密―技術アドバイスの人間学
G.M.ワインバーグ, 木村 泉, ジェラルド・M・ワインバーグ

みずほ証券事件から考える その3

なんか連載風味ですが、他のネタが枯れているという事情もありこのネタを続けます。
東証のシステムで「取り消しができなかった」という不具合について、続報がありました。コチラ:ITmediaニュース 東証システムの不具合が判明 大量誤発注取り消せずです。
不具合の発生条件のくだりを読むと、頭が痛くなりそうな複雑な条件です。むしろ、これだけ複雑な条件を解明する手間が大変だっただろうとお察しします(しかも、解明したからと言って褒められるとは限りませんし…)
しかし(私は株式-金融方面はずぶの素人ですが)、発行株数の42倍もの数量を値幅制限を大幅に下回る値段で注文できるという仕様はいかがなものでしょうか。
そういう意味では、ムリな仕様は悲惨な不具合を生む元になるという良い見本かと思います。
また、そういう現実離れした(と私には思える)データは、ちゃんと入り口で止めなければいけません。
どのシステムでも、設計・実装に一番気を使うのは「エントリ系」-つまり、入力です。ゴミを入れればゴミが出ますから、きちんとしたものを入力させなければいけません。
※先日ヒサビサにエントリ系を書いてかなり緊張したというのは本当です。

みずほ証券事件から考える

昨日来ニュースを賑わせています、みずほ証券による誤発注事件について考えて見ます。
コトの次第は、「61万円で1株」と入力すべきところを、「1円で61万株」と入力してしまったことらしいです。
これが元で、100億単位の損失が生じる可能性があるとのコトです。もう実感のわかない金額の単位になってしまってます。
報道によりますと、担当者はシステムからの再三の警告メッセージを見落としていたとの事ですが、認知科学の専門家でなくともその過程は推測できます。
要求分析の過程でありがちなのが、
「警告ダイアログを出して…」
「メールで催促して…」
「画面項目が赤くなるようにして…」
と、ユーザにそれを知らせようというものです。
しかし、場数を踏んだエンジニアは大抵の場合気が付いています。
「すぐに慣れちゃて、警告メッセージも見ないで[OK]押すよ。」
とか
「面倒くさいと思われて無視されるよ。」
と。
昔から、「木の葉を隠すには森の中」といわれるように、たくさんの警告の中にある、本当に重大な警告というのは気が付かないものです。
かといって、適切な頃合と言うのが、これまた難しいわけです。
<オマケな雑感>
・発行済み株式数の42倍もの注文がまかり通る事自体が理解できません…正直よくわからないです。

統一せよ

例えばあるステータスがあって、そのステータスが特定の値になった日時を別フィールドに持つとします。例えばこんな感じです。

ApprovalStatus   int
ApprovalDate    datetime

こんな中で、ある機能はステータスで見て、別の機能は日時で見て。
混乱しないほうがおかしいですよね。
「決め」の問題として、「Statusを持って判定するものとする」と定めてそれに従うとか、そのようにしてシステム全体の統一感を出していく必要があります。
そうやって統一されていた中で一つか二つ「悪い子」がいても、それくらいの例外だったら、なんとか記憶の片隅に入れることはできます。
それに対して、「あれ、この機能はどっちだったっけ??」というやり取りは、バグ取りの修羅場の中では避けたいものです。

窓口はまとめよう

例えば会社の営業さん。
A社さんの担当営業はXさん。B社はYさんというように決まっているのが普通です。これにより、お客さんは誰に言えばいいのかがわかるようになるわけです。で、営業で処理しきれない話なら、他部署にふるわけです。
プログラムでも同じで、Aに関する処理をやりたいときはXクラスというように分けます。Xクラスで処理しきれない話なら、ビジネスロジック層とかにふるわけです。
この層のことを facade というようです。
facade とは元々はフランス語で「(建物の)正面、前面」「(比喩的に)前面、外見」という意味です。

ユーザから変更要望が頻発しそうなところはユーザが変えられるように

たとえば画面の色、項目の並び順ナドナド。ユーザから変更要望が頻発しそうなところは、大体わかるものです。
そこをユーザレベルで変更できるようにしておくと、仕様変更どころか、保守フェーズもかなり楽になります。そして、ユーザとしても、いちいち頼む必要がないので、かなり嬉しいはずです(そうですよねぇ…発注すると結構な金額が…)。開発者も、くだらない(失礼!)保守ではなく、もっとやる気の出る作業に入ることが出来ます。
私はVB6上のシステムでそのように設計されたシステムの面倒を見たことがあります。そこでは、ユーザレベルでできない部分は、プログラマレベル。さらには上級プログラマレベルと、きれいな「層」が出来ていました。
あれこそ、保守まできちんと意識した設計だと思います。
(守秘義務の都合上お見せできない点をお詫びします。)

要求にもう一歩踏み込んでみる

ある依頼にたいして、最も良くあるアプローチは、「は、左様でございますか!」といって、丸呑みにしてしまうことです。
たしかにそれもアリですが、もう一歩踏み込んでみると、思わぬ発見があったりします。たとえば…
・「検索キーを増やしたいのはxxなデータを見たい為だ。」
・「並び順を変えたいのは、業務がその優先度で動いているせいだ。」
・「ここで関連データを出したいのは、変更の影響度を見たいためだ。」
と、いう訳です。
その裏事情をよく理解すると、「こっちの方がより良い解決案ですよ」と、逆提案することも出来ます。
こうすることにより、開発工数が削減でき、納期も短縮され、顧客も望むものが手に入り、みんなハッピーというシナリオが出来る場合も、多々あります。
何故それを欲しているか、もう一歩踏み込んでみましょう。

よくわからない要求仕様

よくわからない要求仕様は、
・どこかで伝言ゲームが起きている
・要求元も、自分が欲しいものが「何か」がわかっていない
という原因から発生したと考えられます。
伝言ゲームが起きているなら、それを解きほぐして、真意を探る必要があります。
要求元が自分の要求を解っていないならば、それを一緒になって解明する必要があります。
本当は要らなかった機能を作ってしまうことほど、無駄なことはありません。怪しいと睨んだら、ちゃんと確認しましょう。
※ここで挙げた原因は一例です。念の為。

エラー理由は返せ!

たとえば、郵便番号の入力欄。テキストフィールド1つとします。
要求書式は、”999-9999″とします。
(書式記述方法が古くてすいません。)
ここでの単体チェックとしてはイロイロ考えられますが、その結果エラーが出ました。
エラー原因はきちんとユーザに返してください。
何が悪いのか、ユーザに解らなければ直しようがありません。
単に「郵便番号が不正です」では、ユーザはストレスを感じます。どこをどう直せばいいのか?というクイズ状態になります。
たとえば全角・半角が悪いのかとか、面倒がらずにちゃんと返してください。
※多いんですよ、ココまでもやっていない商用サイト…

ユーザに反応を返せ

ユーザのアクションには反応を返さなければいけない。
GUIでリアルタイム処理をしているならともかく、Web上で、メールシステム上で、イロイロな処理形態があるが、とにかく、反応を返してください。
反応がこないと、ユーザは不安に陥ります。その「不安感」も、システムの品質の項目のうちです。
そのあたり、Amazonはうまく作ってあると思います。ちったぁ見習って欲しい商用サイトの多いのなんの…。