ビジュアルファシリテーターの阿呆な研究

Read Article

ごはん作りから考えた、エンジニアとUI設計者の間の橋

「今晩は鍋食べたいな」
ある日、夫がぼそっとつぶやいた。真夏のクソ暑い時期に「鍋食いたい」というのはめずらしい。夏向きなトムヤムクン鍋でも作るかなー、と思いつつも「何鍋がいいの?」ときいてみた。

「おなかに優しい鍋。きのうトムヤムクンラーメン劇辛にして2玉食ったら腹壊したから」

・・・( ゚д゚)我が夫ながら阿呆じゃのう

しかし、冷蔵庫を開いたところ、優先して食べるべき食材は、なす、みょうが、長芋、おくらだった。
どう考えても鍋が作れるラインナップではない。
さてどうするか?冷蔵庫を前にしばし考えた。

この食材で何かを作る?それとも買い物にいく?
でも買い物にいってたら、夕ご飯の時間相当遅くなりそうだ・・・

そのときふと、エンジニアとUI設計者(デザイン)についての言葉を思い出した。
エンジニアの仕事が0を1にする仕事なら、デザインは1を100にする仕事
0から1を作るのと同時に、1から100にする過程も当然考える必要があるよなーって。

エンジニアとUI設計者の間の橋をかける人からのメール

エンジニアとUI設計者の間には、深くて暗い川がある?」という、エンジニアとUI設計者の思考の違いについてのエントリーをかいたところ、同じチームのメンバーからこんなメールをもらった。(公開は本人の了承済み)

私は、どちらかと言うと、思考はUI側の人間なので、エンジニアの作るものに対して、「馬鹿なの?死ぬの?」と思うことも、山のようにあったわけですが、10年ほどの経験を通して(上司に解説してもらいつつ)理解したのは、
「理系人間は自分で前提を考えることが苦手」
ってことです。
これを理解してから、「馬鹿なの?死ぬの?」はあまり思わなくなりました。
算数の問題って、必ず、「前提条件」が付くじゃないですか。

Aさんは自転車に乗って、時速15kmで2時間進みました。Aさんは何km進みましたか。
※ただし、自転車は常に同じ速度で走るものとします

とか。
問題を解く時には、必ず前提条件は「与えられる」もので、自分で考えるものではないんです。
だから、その前提条件から自分で考えて、となると、とたんにわけが分からなくなる。

※ただし、自転車は常に同じ速度で走るものとします

がないと、

・Aさんが途中で怪我をするかもしれないのは考慮するのか?
・追い風/向かい風は考慮するのか?
・途中に信号はあるのか?
・途中で疲れて休憩することはないのか?
・自転車のタイヤがパンクしたらどうするのか?
・その時速は、平均時速なのか?途中での休憩も含まれてるのか?
含まれてるとしたら何回休憩してるのか?

等など、懸念点が一杯で、問題解くこと自体に入れないわけです。
だがしかし、実際に、自分が自転車に乗るとして、そこらへん適当に考えてよ、というと、それは難しいです。。。。ということになり、それでも無理やり作らせると、これまた非常にセンスがない前提を作って考えてくるのです。多分、興味の向きが「人間」ではなく「仕組み」にあるから、なんですね。
どうして今自分はこういう動作をしたんだろう?ではなくこれはどういう風に動いてるんだろう?と。

で、元の話に戻ると。
「要件にマッチしてるかどうか」を判断しながら動作を規定するは、結構「理系人間」には難しいのです。
なぜなら、『動作を規定する=「要件」に照らし合わせながら「前提条件」を自分で定義していく』作業なので。
そして、良く言われるのは、エンジニアは機能をいかにウツクシク実現できるか、に目がいきがちでそれがどういう文脈で使われるかまで考えられない。思いが至らないってことですね。

前提条件の必要性


mnx personal today todo list / manu contreras

「デザインは1を100にする仕事」というけれど。そのデザインには、1から100に増幅させるための前提条件を定義することも内包されているのだ。

いつ、誰が、どういう想いを持ってそのツールを使うのか。もちろん、そこを考えるのはエンジニアさんでも、UI設計者でもいいと思う。チーム内でちゃんと共有さえできているなら考えるのはだれだっていい。大事なのは、その前提条件そのもの。影響力大きくよいものであればあるほど、かけた工数に対する効果は大きい。1が100にも200にもなれると思う。

家庭でごはんを作るということ


金魚鉢 / Sig.

さて、ここで我が家の食卓に話は戻る。
実際に私が把握し実施した、晩ご飯作成のための諸条件と行程をまとめた。

前提条件:

・腹の具合が悪い夫が食べやすいものを作る
・なす3本、みょうが2個、長芋1本、おくら10本を使い切る

前提条件から考えた施策:

山形の「だし」をつくり、冷ぶっかけうどんにのっけて食べる

調理者(エンジニア)の行程:

・なす1本、みょうが2個、長芋1本、おくら10本を刻み、だし汁や塩などを入れ、前もって「だし」を作り、味をなじませておく
・(その間少し時間をおいてぼんやり茶をのむ)
・余ったなす2本は焼き茄子にするため、編目の切り目をいれておく。
・ついでに万願寺とうがらし(ししとうみたいなやつ)も切って、茄子と一緒にグリルで焼きはじめる
・うどんをゆではじめる
・大根おろしを超速で作る
・ついでにデザートの梨もむいておき冷蔵庫につっこむ
・うどんがゆであがったら冷やす
・うどんに「だし」をのっけて、糸唐辛子をのせて、完成
・茄子もちょうど焼けたので、大根おろしのっけて完成
・食後に冷えた梨を冷蔵庫からだして食べる

デザイナーとして考慮した点:

■夫の腹具合を想定
・腹の具合がよろしくない夫でも食えるやさしい味のものを作る。
・夫は昼に唐揚げ丼食べてたので、夜は軽くても大丈夫なはず。

■食材利用制限のクリア
・なす3本、みょうが2個、長芋1本、おくら10本をできる限り使いきるメニューにする

■ご飯としての栄養、色合い、味の品質担保
・あたたかい焼き茄子と、冷たいうどんが同時のタイミングでだせるように進行する
・焼き茄子は単品だと寂しいので、万願寺唐辛子(緑)、大根おろし(白)を添えて彩りよくする
・うどんは白、だしは緑。赤い色がほしいので、糸唐辛子と赤い塗りのお椀でカバー
・梨はより冷えるように食べる直前まで冷蔵庫にいれておく

こう考えると。家庭で料理をつくることは、一人でエンジニアとデザイナーをこなす大役に見える。
家庭内の場合、一人で一気通貫できちゃうのが利点だと思う。「鍋食べたい」を「腹の具合が悪い夫が食べやすいものを作る」におとしこんで、鍋じゃないけど違うものも自由に考えて作ることができるから。

他方。もしエンジニアとデザイナー(UI設計者)が分離してるような状況だったら・・・
「鍋食いたい」という要望に対して、エンジニアだけだったら鍋を作り始めるかもしれない。材料ないから買い出しにいかなきゃいけないので、料理をはじめるまでけっこう大変だ。デザイナー(UI設計者)だけだったら、冷蔵庫の中身をみて「鍋じゃないものはつくれるけどなー」とまでは考えられるけど、うどんと焼き茄子をおいしく同時タイミングで仕上げる具体的行程と作業ができない。(例えば「だし」を一番最初に作って冷蔵庫にほうりこんどく、とか。「だし」は時間をおけばおくほど青臭さがとれておいしい。作りたてではなく時間をおいてから食べるのがミソ)

同じことは、きっと会社でもいえるんだと思う。
エンジニアと、UI設計者。一人で一気通貫すれば速いけど、そんなスペシャリストはなかなかいない。
だとしたら一気通貫がスピーディーにしやすくなるよう、チーム体制を作っていく必要がある。そのチームのありかたとして、アジャイルが注目され、現場でとりいれられてきているのだと思う。


bob’s cooking dream / Robert Couse-Baker

↑いろいろうまくいかなくて、炎上しちゃった案件なイメージ

———-

かくして、トムヤムクンラーメン劇辛にして2玉食って腹を下した夫は、無事に穏やかな夕ご飯を食べることができた。目標達成である(と私は勝手に認識した)。
夫というユーザーを目の前にして、私は日々エンジニアもデザイナーもやって家庭を運営している。一人アジャイル。ついでにいうと、多変量解析などもとりいれユーザー動向をたしかめてもいる(「夫vs妻 家庭内における文化摩擦と文化触変 ーカレーを混ぜるか、混ぜないか」参照)

仮説をもって毎日ごはんをつくる。日々のごはん作りだってクリエイティブである。

URL :
TRACKBACK URL :

Comments & Trackbacks

  • Comments ( 1 )
  • Trackbacks ( 0 )
  1. すばらしい文章だと思います。とくに:

    >「鍋食べたい」を「腹の具合が悪い夫が食べやすいものを作る」におとしこんで、鍋じゃないけど違うものも自由に考えて作ることができるから。

    単にユーザーの欲しいもを提供してしまうのではなく、ユーザーのゴールを発見して満足させるというポイントは大事だと思います。ありがとうございます。

Calvin C. への返信 コメントをキャンセル

*
*
* (公開されません)

Facebookでコメント

Return Top