今日、関東で春一番が吹いた。
朝も冷え込みが弱く、暖房をつけなくても大丈夫なくらいに暖かかった。
冬が終わり、そして春が来る。
では・・・

　　＼春ですよー！／
　　　　　,.-､
　　　　 /　　＼
　　,､　}>< {===ヽ、
　 〈 ＼i　ｲﾉハﾚリ/〉
　Σヾﾉ ﾘi ﾟ ヮﾟﾉﾘ /
　∠ / く/(つT(つ>
　　ﾚ､/,くン 〒ﾊV
　　　　ﾞ’ｰr_ｪ’ｧ┘

昨夜、どうして思い出したのだろうか。
どうして二夜連続、夢に現れたのだろうか。

webという情報の海を彷徨っても、あなたは現れない。
あなたはいつも、夢の中で私を呼ぶ。
私はあなたを追って、夢の中へ。

紙とペンを使えばあなたと連絡を取ることが出来るだろう。
webよりも確実に、そして早く。
しかし、いつも影が私を包み、踏み出せずにいる。

あの時、あなたは私に向かって笑ってくれた。
見せかけの笑顔ではなく、あの頃、毎日のように私に見せてくれた笑顔。
ほんの微かな時間だった。

あの日々から、あの夢から私の人生は始まった。

十四年という時を越えて今。

例えば、ある事に対してガイドラインを設けるとする。
そうだなぁ、じゃぁ〜ガジェットについて評価し合うときのガイドラインを作るとしよう。
「モノを評価する。」ということは、評価項目があれば評価結果が分かりやすく、
あらゆるガジェットに対して公平な評価が出来る。

では評価項目をリストアップしよう！
とは言ったものの、そういった項目をリストアップするにはそれなりに時間が掛かってしまう。
なので雑誌に掲載されている評価項目を目安にすることもひとつの手段としてあるだろう。
参考に出来るものは参考してみる。
そこからなにか新しい項目を見つけ出せば良い。

評価項目がある程度リストアップできたら、今度はそれら評価項目の定義を行う必要がある。
例えば「操作しやすさ」という評価項目があったとする。
ひとそれぞれ「操作しやすい」と思う感覚はバラバラ。
個々が持つ感覚で評価しあうと、まとまらない場合や結果にばらつきが出てしまう。
そうならないために、共通した「操作しやすい」の判断基準や、「操作しやすい」とは
何をもって操作しやすいのかなど、評価項目に対して「定義」をする必要がある。

操作しやすいとはどういったことを指すのか？
片手で持った時の安定性？
タッチパネルの感度の良さ？
などなど、色々出てくると思う。
それらをブレストの時に出していき、最終的にはある程度の輪郭を持たせた案へまとめる。
そしてその案をブラッシュアップし、定義として位置づける。

まぁ、ガジェットの評価項目を実際に作るとしたら、こんなにきっちりやらなくても良いような
気がしなくもないが、人を評価する際に用いる評価項目だったらどうだろうか。
ガジェットの時とは違って、より綿密な行動、ミーティングの中で作られなければならない。

評価の方法はどのようにして行うのか、またその手順は？
前提となる条件の洗い出し。
（例えば自社で作業する者に対してなのか、客先で作業する者に対してなのかなどなど）
ブレストやミーティングはいろ〜んな下準備があった上で行うべき。
（ときおり下準備もなしにいきなりドーンとやってしまう節は私もありますが…）

ミーティングというものは、開始したその時にヨーイドン！ではなく、ある程度各々が材料を
持ち寄って行うべきもの。
（材料というのは、自分なりの考えなり、アイデアなり、モノだったり）
あと１番大切なのは共通した意識があるかということ。
というか「ミーティングする＝共通した意識があること」のはずなんだけどね。

C言語チックに言うと、
　プログラムの処理内容（ミーティングのテーマ）はヘッダーに書いておく。
　使う変数（材料や前提など）はあらかじめ宣言（持ち寄って・宣言）しておく。
　そして求める処理内容（求める案なり答えなりまとめなり）に向けて
　コーディング（ミーティング）を行う。
　そして、戻り値Return （結果）を返す（提示する）。

それが出来ていないと・・・上手く回らないし、結果もでない。