スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
拍手コメントを見る

情熱は仇となる(こともある)

要求仕様があって、それを実現するには要求者が考えているような簡素なアイデアでは実現できないため、このようなUIを設けてやらないと使い物にならない。

という説明をするのに、えらく骨を折る。

図解して、このケースはこうだから、このような制限を設ける必要がある。
かといって、次のケースだと、先の制限を設けたところで矛盾が発生するから、先の制限は無意味になる。

さぁどうする?だから、要求仕様を的確に実現するには、こういったUIを設ける必要があるわけです。
ただし、(他社の機関)システムの制限があるため、ユーザーにはそれなりの手順が必要になり、UIとしては複雑になります。

と説明しても、「なんで?そんなに難しく考えることないんじゃない?」と。四面楚歌状態。

いいや、だめです。お考えの簡素なUIだと矛盾が解決せずに破綻します。それについてドキュメント書いたのですが、誰からも反応がないのが残念なところです。

大人げなくキレたりする。

・・・・といっても、みな忙しい。僕の提示したUIを実現するには、それ相応のマンパワーが必要になることは一目瞭然で、スケジュールに間に合わなくなる危険性が非常に高くなる。

午後、「難しく考えすぎている」という意見をもった二人を捕まえて、このケースはこうだから、だめで、この解法をもってしても、次のケースで適合しないから、やっぱり駄目で、簡素化なんて無理なんですよ、とクドクド説明したところ、ようやく分かってもらえたようだ。1時間も2時間もかかった。ドキュメント作成まで入れると、その数倍かかっている。
わかってはもらえたが、解決に一番近いと現状考えているアイデアを実現するための工数を試算すると、みな閉口してしまうのです。

で、一番「難しく考えすぎ」と言っているキーパーソンは会議で不在だったため、改めて時間をみつけて、もう一度説明しなければならないのだけれども、なんだか、萎えてきた。
頭の中では「ダメ」と分かっているアイデアに対して、このケースは駄目だから、このケースは駄目だから、とダメ出しを沢山書かないといけないのが、とっても生産的じゃない気がしてまったくモラールが湧いてこないのです。

ただの面倒くさがり屋とも言います。

UIとロジックってのは難しい。一見単純な機能を実現しようとすると、プログラム的には全然単純なものではない事が多い。いや、たぶん100あれば99はそうだとおもう。
しかも、矛盾を打ち消したUIはえらく複雑なものになることが多い気がします。
複雑なUIになると、誰も使いたがらないことが予想される。使わない機能になりかねない目標物に精力を注げるようなモチベーションは自ずと下降していくのです。

やばい、泥沼にはまった。

物事には絶対は存在しません。
今現在、解決できるだろうという案も完全ではないことは分かっているのです。

弱点は、「複雑すぎる」、「工数がかかる」、「特定の視点からしか導けない」事が挙げられます。

どう単純化するか、ここからはアイデア勝負です。
「オッカムの刃」。シンプルであればあるほど真により近いはずです。

と、書いてみたものの、どうやら「Occam's Razor」の解釈は間違っていた事が判明。
こらー!「コンタクト」のカール・セーガンさん?それともゼメキスさん?映画での引用間違ってませんか?それとも、僕の勘違いだったの?

Occam 調べて Paul Dirac という人物の言葉にグっときた。
研究者は自然の基本法則を数式に表現しようとするとき、数学的な美しさを追求するべきだ。単純さを求めると、美しさを求めるのと同じ結果になることが多い。ただ、どちらかを取るとすれば、美しさの方を優先するべきだ

嫌いじゃないけど「芸術は爆発だ!」といった抽象的な言葉より、今の僕には心に沁み入ります。
いや、オッカムの刃で削って削って、その結果残った言葉だったら御免なさい、岡本太郎さん。

あぁ、まとまらない。やっぱり泥沼だぁ・・・(笑) 拍手コメントを見る

コメント

思い当たります

どうしてこんな複雑なの?っていうシステムを見ることがありましたが、そんな場合そもそものまとめられた要求仕様が間違っていたり、もしくはユーザーの真の要求を開発側がちゃんと理解していないケースだったり、ということがありました。ユーザーの欲しいUIはやはり大切だと思うのです。うまく解決できるといいですよね。

すみません、今自分の書いた読み返すてみて「複雑なUIをつくってしまうのは開発の問題」的な感じに読めてしまうな、と気づきました。

要求仕様をまとめるのって難しくて、まとめる開発側だけではなく、要求者側も上手に伝える伝達力があって欲しいし、開発側も曖昧模糊としたところに喰らいついて要求をクリアにするという持久力が必要だし、、、やっぱり難しいですよね。

開発のマネージャーがそういうことを面倒になって放置するような人だと、後になって問題噴出、面倒を起こした張本人は休暇中、みたいなことが以前の職場では日常茶飯事のようにあったのでついつい過敏に反応してしまいました。すみません。まだまだ傷は癒えてないようです。

そうなのよ

創ってみたら期待していたモノじゃないなんて、疲れ倍増だもんねぇ。

事前のネゴって本当に大切です。特に相手が抽象的な表現に長けている人だと、コロッと騙されちゃって、「小さな努力で何て効果的な手法なんだろう!」なんて思いこんだりして。

ガリガリガリクソン風に、「おぉ、こわっ」
非公開コメント
ブログ内検索
プロフィール

雷ぶ

Author:雷ぶ

最近の記事
最近のコメント
最近のトラックバック
カテゴリー
月間アーカイブ
ブロとも申請フォーム

この人とブロともになる

RSSフィード
リンク

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。