jfluteの日記 このページをアンテナに追加

2011-07-05

イメージを大事に、イメージに捕われず

| 16:51 |

最近、以前よりもさらに色々な人と会うようになって、
ベジの話など自然食の話題をすることが多くなりました。
その中でありきたりでありながら印象的な言葉を
よく聞くようになりました。

「自然食のごはんって、おいしくないってイメージが」

ありそうですね。多くの人がそういうイメージ持ってる
のかもしれません。一人だけでなく複数の人が同じことを
言ったので印象に残りました。

で、別に結果どうあれ、それはそれで良いでしょう。
どういうイメージを持っていようが個人の自由ですから。

ただ、プログラミングの世界でも同じことあるなぁって。
そんなノリでビジネスポリシーにまで飛躍させて、
ちょっとした思考を巡らせてみました。
o Javaは遅い、ってイメージが

一昔前によく聞いた言葉です。
もう今ではそんなことがテーマに挙がってもほとんど
無視しますが、ってもうちょいやわらかく言うと
「お茶を濁す」って感じですが、もうちょい踏み込んで
濁す理由を噛み砕いてみたいと。
(O/Rマッパは遅いってイメージが、ってのと似てますね)

Javaが以前、遅かったのは事実です。
マシン性能も今よりは遅いですし、何より JavaVM が
まだ未発達でした。ただ、その「遅い」と実際に問題に
なる「遅い」は必ずしも一致しません。

結局は何言語を使おうと、無駄な処理をたくさん処理する
遅く書いたプログラムは遅いです。

問題として出てくる「遅い」という結果の要因としては、
先ほどの「遅い」よりかはこっち「遅い」の方が遥かに
影響は大きいでしょう。

全ての食材が自由に扱える食事と、食材が制限された食事
では、当然のことながら前者の方が比較的おいしいものが
作りやすいでしょう。ただ、もっと大きい要因があって...

結局は丁寧においしく作ったものはおいしいし、
そうでないものはあまりおいしくはないです。

JavaVMは他の言語にはないメリットを引き出すために、
色々なことをやっているのは事実です。健康に良いという
メリットを引き出すために、食材を限定してるのは事実です。

ただ要は「程度」の問題で、別にJavaVMも円周率計算を
毎秒毎秒やっているわけではないし、自然食の料理も
「にんじん」だけでフルコースつくってるわけじゃない。
最終的に人間が感じる「遅い」や「おいしくない」という
問題に影響しない許容範囲内であれば、それらは要因に
すらならないと言えます。

その「程度」が、時代と共にどんどん小さくなってきます。
PCの性能は上がり、色々やってるというJavaVMの処理も
ほとんど気にする必要もなくなって来ますし、JavaVM自身が
かなり発達してきてサービスを落とさず効率化されてきました。

おいしい野菜作りの研究は至る所で行われ、さらに、それらを
どう使ったらおいしい料理になるのか、という研究も同じく。
そして、インターネットの普及でそれら情報を色々な人が
手軽に手に入れられるようになってきました。

15年前、20年前のことは確かに自分は知りません。
でも、今はその昔のイメージとは違う現状があることが
(他の分野の話でも同じく)とても多いような気がします。
o オブジェクト指向で書いたプログラムは
  わかりにくいってイメージが

逆に言うと、一つのクラスやメソッドに全てのロジックが
凝縮されていた方がわかりやすいってところでしょうか。

自分としては、Yes とか No とかという概念すらない。
あえていうなら、Yes でもあるし No でもあるというか。

様々な要因があってそんな単純なものじゃない。
基本はしっかりクラス分けしてロジックを分割しますが、
状況によってはあえてそれをやらずに集約させたりもします。
というか、できるだけ両方のメリットを多く享受できる
バランスを見つけようとします。プログラムだから、
それが物理的な現実世界よりかはやりやすいし。

オブジェクト指向ならどうのこうの、
凝縮したプログラムだからどうのこうの、
というよりも実際にその場の状況を考慮して、

どう書くと何がわかりやすくって何がわかりにくいのか、
それを鋭い感覚でしっかり捉えて細かく調整すること。

「テレビでオブジェクト指向ならわかりやすいらしいわよ、
 だからオブジェクト指向プログラム書いてるの」
なんて言ってる人が書いたプログラムはわかりにくいでしょう。

鋭い感覚でしっかり捉えて細かく味を調整された料理は、
ある程度食材を限定していてもおいしく頂けるでしょう。

そして、結局はある程度はプログラムを読む人によるし、
読む前後関係によるし目的にもよるしスキルにもよるし、
同じプログラムを同じ人が読んでもそれら次第でどっちに
でもなり得ると。

味蕾細胞(みらいさいぼう)は、人種差や個人差があると
言われます。実際、食のことに興味をもって色々な人と
話をするようになってからは、舌の感じる敏感さ、
それも辛い系、甘い系、しょっぱい系、何々系と、
それぞれ人によって全然違ってくるんだと実感しました。
(敏感な人は信じられないほど敏感なんですよね)
そもそもの味覚で千差万別、だから好みがあるわけで。

それまでの経験で味が濃いものばかり食べてた人は、
素材の味のおいしさにほとんど気付けないでしょうし、
(自分は何年か前そんな状態でした)
どんなにおいしくても隣でタバコ吸われて煙に巻かれたら
なかなかそのおいしさを堪能することはできないでしょう。
(なので自分はもう基本的に禁煙のお店しか行かないけど)

結果を演出する要因というのはキリがないほど様々で、
それゆえ論理的な矛盾を含んでしまうこともあります。

そう言う意味では、わかりやすくプログラムを書いても、
100人が100人とも100点満点ってプログラムはないわけで、
できるだけ多くの人に100点満点と思ってくれるように、
もしくは、あえて100点は狙わずより多くの人が平均して
70, 80点あたりに思ってくれるように書いたり。
(DBFluteで機能を作るときは常にこのジレンマとの戦い)
一方で、イメージを持つことは大事です。
漠然と物事を捉える能力、「漠然力」って勝手に
呼んでますが、それはそれで非常に大事なスキルで、
要は精度の高いイメージであればいいわけで。

具象物でしか物事を思考できないというのは、
物事を抽象的に捉える力が乏しいとも言えます。
検証し尽くした論理的に全て筋道の通ったものに関しては
精通していても、曖昧さを曖昧のまま精度高く捉えることが
苦手だと、世にたくさんある答えの出ない物事に対して、
的外れなアプローチをしてしまう可能性があるからです。
そもそも人には検証するための時間が限られていますし。

そして、精度に限らずイメージを持つときに大事なのは、
「イメージはあくまでイメージ」という認識であること。
頭の中のイメージフラグは true、つまり、分析を保留して
いるだけで、いざ必要になったらしっかりアプローチして
先入観のイメージは単なる先入観として間違っていれば
すぐに(柔軟に)破棄。これができればOK。

時に人は、あくまでイメージのつもりで捉えていたものが、
時が経ってそのフラグの存在を忘れ、
つまり、cb.query.setImageFlg_Equal_True()
という区分値メソッドを書き忘れて、事実かのように
捉えてしまう、イメージに捕われてしまう。それが一番怖い。
(ちょっと似たような話、以前にありましたね)
 -> 自分の中でデマを広げさせない

イメージを楽しむってのも人の文化、
イメージをうまく利用することで円滑に物事が進むし、
イメージを持っているからこそコミュニケーションが取れる。
だからこそ...

イメージはイメージとして大事に持っていようと
ちなみに、実際に話をしたときには「自然食の料理」
ではなく「健康に良い料理」っていう表現でした。
自然食オーガニック素材やベジタリアン(ヴィーガン)、
ロハスなどのもろもろのキーワードが「健康に良い」
という一つの「イメージ」に集約されたのでしょう。
基本的には間違ってないですが、実際にはもっと奥が
深いコンセプトがそれぞれのキーワードにあるわけで...

ベジというキーワードだけでも、ここに書いた通りで。
 -> マイ ベジタリアン ポリシー

オーガニックとかフェアトレードとかロハスとかまで
言及すると、ブログの読者がページスクロールで腕を
痛めてしまうでしょう。

逆に「肉を食べるのは健康に悪いイメージ」というのも
正しくないでしょう。そこにも程度の問題が存在していて、
少なくとも「食べ過ぎは良くない、同じ食べ過ぎでも野菜の
食べ過ぎに比べれば肉の食べ過ぎの方が良くない」ってこと
は言えても、その先には複雑なロジックが存在していて、
その行為自体が健康に悪いという単純な論理に落ち着いて
しまうのはそれはそれで「不健康」な思考かなと。

単純な論理で片付く物事なんてほとんど見たことありません。
単純なままの理解で突き進むのも良くないし、複雑なものを
追い求めて時間をかけ過ぎて他のことを置いてけぼりするのも
良くないでしょう。結局は、

程よく突っ込んで、程よく割り切って、
というようなバランス感覚が求められると。
それにしても、ベジという(少なくとも日本では)マイノリティで
なかなか普通の人から理解がされにくい世界を覗いていることで、
ビジネスにおいても同じように起こり得る現象とリンクさせて
多角的に分析するきっかけになっているのが、
なんとも予想していなかったことではあります。

対象物は違えど、世界は違えど、そこで発生する抽象的な
ロジックは同じようなことだったりってことがよくあって、
見事に Template Method Pattern にハマるかなって。

DBFluteも同じくマイノリティであることは否めなくて、
ベジの話が DBFlute にも通じて、その逆もまたしかりで、
相乗効果でその(つらい)境遇をうまくしたたかに利用して
向上していけたらいいなって感じですね。
トラックバック - http://d.hatena.ne.jp/jflute/20110705/1309852303