Monthly Archive

先日、銀座アップルストアで行われたCSS Niteの後の飲み会での話題。

何の話からそうなったのかは知らないけれども、ヘッダーのあたりのCSSでpositionを使うかどうかという話をしていた。見ていると、コーディングをやっている4人中、3人がfloatのみ使う派、1人がfloatとpositionの組み合わせ派であるようだった。面白かったので参戦することにした。わたしはpositionも使う派です。

基本的には、どっち使おうが、見た目や使い勝手に問題が無ければOKだと思うけど、floatのみでできるのはスゴイなーと思っていろいろ聞いてみた（わたしはCSSが好きだしやっているけど、マニアックなほどにできるわけではないので）。

たとえばヘッダー内に、下記のようなものがあった場合。

・ページタイトル
・キャッチコピー
・グローバルナビゲーション
・ユーティリティナビゲーション（サイトマップとかの小さなやつ。なんて呼ぶのが正式？）

この順番でhtmlには書きたいけど、デザイン上は順番を崩したいときが、けっこうあると思う。
たとえば、ユーティリティナビは一番上の右側が良いとか、ページタイトルが製品名などならキャッチコピーはその上に置きたいとか。
その場合はどうするのか聞いてみたら、デザイン上の順番でhtmlも書く、ということだった。

わたしにはそれがとっても意外だった。
急いでいるときや、必要があるときに、そうすることはあるけれど、できれば順序よく書かないと気持ち悪いような気がするのだ。それを伝えようとしたが、うまく説明できなかった。

「それは本当に必要なの？ 誰のためにそうするの？」とfloatの方々に聞かれ、
「え、なんでそうしないの？ 使い勝手っていうか、気持ちの問題っていうかモゴモゴとにかくモゴモゴ」と答える堀内。

モゴモゴ・・・

今思えばこういうことかもしれない。
わたしはデザインとhtmlを同時進行することが多い。
デザインで煮詰まっているときやデザインカンプをクライアントに確認してもらっているときに、素のhtml書いてプロトタイプ作るとか、むしろデザインより先にhtmlと簡易的なCSSで作ったプロトタイプで動作確認とか。

そうすると、htmlは、デザイン上の制約を考えずに書くことになる。だからわたしはhtmlだけ見ても意味が伝わりやすいと思える順番で書くのだろう。
だから疑問に思っちゃったんだろう。

基本的にはどっちでも良いです。
そのときも、どっちが正しいかという議論をしていたわけではない。

結果が同じなら、人それぞれ、生産性が高いほうが良いと思う。慣れた方法が一番早いし、勝手なこだわりで工数が増えるのは誰にとってもよろしくない。
ユーザ層や戦略によって、優先順位も変わってくるわけでー。

面白かった。仕事人間としては、飲みの席での仕事の話、好きです。

追記：
float と position の戦いって、実際あると思うが、あまり興味はない。
興味はないけど、必要だとは思う。こだわる人がいないと進化しない。
そのあたりについては、別のエピソードがあるのでまた今度。

今日読んだ本で、「ラーキンの時間管理の法則」からの引用があったのだが、覚えておきたかったので、「云々」にメモ。

「ひとつの書類を扱うのは一度だけ」

このタイムマネジメントは古くからある法則らしく、「書類」と言われても、ほとんどがパソコン内に格納されているわたしには、すぐにピンと来たわけではない。
しかしそれにまつわるエピソード（同じ書類を何度もひっくりかえして、多大な時間を浪費している）などを読んでいたら、なんとなくわかってきた。
わたしの場合、それは「メール」だ。
「あのメールに返事を書かなきゃ」と、脳内で何度も返事をしていたり……。そのような無駄な時間を省くために、「ひとつのメールを扱うのは一度だけ（脳内含む）」だ。
すぐに返事できない種類のメールはタスクの振り替えをやろう。

これまでに、

・仕事のできる男はメールに即レス（By 益子さん）
・二分以内に返事ができるメールは即レス（By GTD関連の書籍）

という言葉も頭に残っていたので、これで3つ目だ。
3回繰り返せば、脳に定着する。
メールの返事の早いときと遅いときの差が、あまりに激しい自分であるが、また少し変わるだろう。よし。

ちなみに、わたしが読んでいる本はこれだ。
「いまやろうと思ってたのに… かならず直る―そのグズな習慣」リタ・エメット (著)
どこかのブログで紹介されていた本で、良い方向に自分を洗脳しようと読み始めた。
さてさて、自分がどう変わるのか楽しみである。

昨日は、2月から3月にかけてやっていた某Webサイトリニュアルプロジェクトの、ラップアップミーティングおよび打ち上げであった。
このプロジェクトは、プロジェクトメンバー（クライアント、システム開発会社、Web制作会社、フリーの方々など）が一体となれたプロジェクトで、それぞれが熱意を持ち、それぞれのパワーがいかんなく発揮されていた。

ラップアップミーティングは、AI（アプリシエイティブ・インクワイアリー：Appreciative Inquiry）の手法にのっとったポジティブアプローチで行われた。
それぞれがこのプロジェクトにどう貢献したか、どんな強みがあったかなどを評価していく方法である。

自分がどう貢献したかを述べたり、プロジェクトメンバーにそれを評価してもらうのは、こそばゆいような感触もあるが、自分の立ち位置や期待されていることが再確認（あるいは発見）できる。
問題点や弱点に注目していくやり方も、ナシだとは思わないし、何が何でもポジティブでなければならないというような、偏った見方をしているわけもない。だが、基本的にわたしは、「本人が気づいて反省している場合は、その問題点を指摘しない」という考え方をしていることもあり、人の良い点や強みに注目していくやり方には大賛成である。

わたし自身はダメ出しも指摘も嫌いではなく、一旦落ち込んでも、すぐに何くそと立ち上がる負けず嫌いタイプだが、凹んだら立ち直りにくく、モチベーションを落としてしまう人もたくさんいるだろう。
Web制作というような仕事は、モチベーションに左右されることが大きいと思う。
もちろん納品物に一定以上のレベルは保つが、さらなるパワーが出るかどうかは、関係性や熱意のような目に見えない部分であることが多い。
自分の価値が認められることが、モチベーションにつながらない人はいないのではないだろうか。

今回のプロジェクト自体は終了しても、今後、効果検証や新しいプロジェクトの発足などがあるわけで、チームが解散ということではない。もちろんWeb制作的人生も続く。
情熱と言ったら暑苦しいと思うかもしれないが、好き、楽しい、喜んでもらいたい、一緒に喜びたいという気持ちで仕事をしていける状態を保っていきたい。

ラップアップミーティングは、こういった評価の時間だけでなく、KPT法（Keep/Problem/Tryを洗い出す）にのっとった振り返りや、具体的な積み残しの整理などを行い、5時間の長丁場で終了。
長時間のMTGは疲れるが、脳みそが活性化される有意義なものは大好きである。

その後、その場にお寿司やビールが持ち込まれ、打ち上げ5時間、移動してカラオケ朝までと続いたわけだ。
全力で仕事をし、全力で楽しみました。

（弊社のWebデザイナーである竹田も一緒に朝までコースだったのですが、笑顔がとっても良かった。彼女が2月に正式にうちに入ってから初の本格的なプロジェクトだった。一緒にやれて本当に良かったと思った。今後ともよろしく！）

こういった形でチームになることが、当たり前になれるといい。
クライアントと単に発注者・受注者というだけの関係になってしまうのは、もったいないのだ。
互いに成長していこうとしてくれるプロジェクトメンバーの方々にあらためて感謝なのである。