「デザイン勉強会」に参加してきました!(その5)

「Webサイトのあり方と考え方」

デザイン勉強会もついにラスト!大トリを飾るのは、CSS Niteなどのセミナーでお馴染みのgakuさんです。

Web標準の日々では、CSSレイアウトのセッションを担当されて、かなり好評だったとか!そう、gakuさんはマークアップエンジニアとしてご活躍中ですが、主催者のまめこさんの熱烈なラブコールを受けての登場となった模様です。

ご本人曰く

「俺、そっち(客席)に座ってるべきだよね…」

とちょっと緊張気味。デザインの具体的な方法論が続いた後の「大トリ」ですし、しかも、デザイナーという立場ではないですし、……心中お察しします。

でも、ですよ。最後にこの「Webサイトのあり方と考え方」という話を持ってきて正解だったと思いました。

要は「コミュニケーション」されど「コミュニケーション」

セッションの内容は、広義での「デザイン」の話でした。ざっくりとまとめると…

  • 2000 年から現在まで、Webはサイト同士がつながるものから、ユーザー同士が繋がるものへと変化。そして、企業とのつながりが密になることでユーザーは、ただお金を落としてくれる「消費者」から、1人の大事な「顧客」へと変化。(ちなみに未だに「消費者」と呼ぶお客さんがいれば、それは認識がかなり古い、とのこと。なるほど。)
  • これはOne to Oneマーケティングにつながるけど、元を正すと地域に根付いた「八百屋さん」や「魚屋さん」に正確は似ている。昔からそうだったように、1人のお客さんのことを考えて、その人の為に何かサービスを提供する。
  • ここで大事なのは「価値のある存在か?価値に見合った対価か?分かりやすい場所にあるか?コミュニケーションは良好か?」ということ。それは、デザインにも言える話でもあり、マナーにも通じる話。
  • デザイナー、プログラマーなど、それぞれのマナーを互いに知ることが大事

話題は多岐に渡るんですが、個人的に感じたのは、デザイン以前の「コミュニケーション」の問題なのかな、ということ。サイト構築全体のデザインだったり、Web全体のデザインだったり…。

そのサイトは誰のため?何のため?、ということを考える際には、お客さんとのコミュニケーションが大事で、その中から答をみつけなきゃいけない。
デザイナーやプログラマー、マークアップエンジニアにディレクターetcetcのチームが連携して、サイトを構築して行く上では、そのスタッフ間のコミュニケーションが大事で、たとえばデザイナーはそのデザインの意図を伝え、マークアップエンジニアはその意図をちゃんと理解した上でソースに反映して行かなきゃいけない。

そのコミュニケーションをおこたると、サイトの存在理由や存在価値がゆらくことになるし、スタッフの本意ではないサイトが出来上がってしまう、と。

「コミュニケーション」って大事だと分かっているつもりでも、本当にそれができているのか、ちょっと考えさせられました。

マークアップエンジニア的には、デザイナーがどういう意図でこのデザインにしたか、というのが重要で、それを知る為には、もちろん上がってきたデザインをよく見て、その構造を把握して、…ということも大切だけど、やっぱりデザイナーと直接話して、その意図をちゃんと聞き出さないと、……と最近思ってたところでした。

逆に、マークアップエンジニアの視点から、デザイナーとこまめにやりとりして、デザインに反映してもらうとか。

手法・テクニック・考え方を、生かすも殺すも「コミュニケーション」次第。そう感じました。

「デザイン勉強会」に参加してきました!(その4)

「簡単に名刺作ろうぜ」

デザイン勉強会、3番手はwoopsdezさん。通称、まめこさんの登場です!

フリーランスのデザイナーのまめこさんは、「名刺作り」をテーマに持ってきました。

レイアウトの基礎、ベジェ曲線の基礎、と来て、「名刺」という実践編。
流れ、完璧です。実際、ベジェの話も、レイアウトの原則の話もちゃんと織り交ぜてあって、再度今まで教わってきたことを確認できるようになってました。(スピーカー陣であらかじめ打ち合わせを重ねて、こういう流れにされたそうです。お見事。)

これなら名刺作れるかも、ってレベルじゃないですよ(良い意味で)

このセッション、ざっと名刺を作るまでの過程を見せて、「はい、できあがり!」……どころの内容ではありませんでした。

  • 紙の種類
  • 大きさ
  • 断裁位置
  • 印刷可能範囲
  • 版権フリーの素材の探し方
  • イラレ、フォトショの操作手順
  • さらには入稿の仕方まで…

もう、事細かに手取り足取り教えてくれる訳ですよ。しかも、実際のイラレやフォトショの作業は、ちゃんと動画に落としてあって、それを見つつ、1つ1つの過程を教えてくれる訳ですよ。
正直、これを受けるまで、トリムマークの入れ方なんて知りませんでしたし(恥)。
フォトショで好きな素材をグレースケールにして、さらにトーンカーブを調整して、パスに変換して、…で、エンブレムマークにしてしまう、なんて発想にも驚かされましたし。
で、この動画は後日公開されます。ご本人の音声解説入りで!

細かい内容については、公開されてるスライドや、近日公開される動画をチェックして欲しいんですが、本当に名刺、作れちゃいますよ。ここまで説明してもらえれば。
特にWebのお仕事やってる人間とっては、印刷、というところを大きな壁に感じてたんですけど、その点もちゃんとフォローされていたので、これならできる!って思えました。

このセッションに関しては、つべこべ言わずにぜひ、スライド&動画をチェックして欲しいです。

…さて、どういう名刺にするべきか…(思案中)。

「デザイン勉強会」に参加してきました!(その3)

「ベジェ曲線で行こう!」

デザイン勉強会、つづいてはCHEEBOWさんの登場!「ベジェ曲線で行こう!」というテーマでお話をされました。

CHEEBOWさんが、MTのプラグイン開発や、MTによるサイト構築で知られる、知る人ぞ知るプログラマーさん。

…え?!プログラマーなのに、なぜベジェ曲線の話?……、とご自身でつっこまれていましたが、CHEEBOWさん、実は看板用のデジタルデータを作成されていた経歴をお持ちなんだそうです。
だから、ドローソフトをかつてバリバリ使ってらっしゃったと。なるほど…。

むしろ、デザイナーではなくてプログラマーの方が話されることで、ベジェ曲線初心者(自分含め)にとっては、自分達の目線で話してくださるんじゃないかっていう安心感がありました。

ベジェ曲線、怖い。

また自分の話になるんですけど、一応、これでも新人研修というものを受けた時に、ベジェ曲線の練習はさせられたのですよ。
一通りドローソフトの簡単な使い方を教わってから、あとはいろんな会社のロゴのビットマップデータを渡されて、ひたすらそれをなぞるという練習を。

それから4年。今、アレを再び渡されても、ちゃんと仕上げる自信がありません(汗)
ベジェ曲線がなんたるかは分かってるつもりだけど、いざ描いてみると、思うように線が引けなくて、悪戦苦闘………、ってイメージが強いんですよ。
だから、ベジェで複雑なイラスト描いちゃう人なんて、人知を越えた存在と言うか何と言うか。

だから、なかなか手の出せない道具、って認識だったんです。ベジェ曲線って。

ベジェ曲線はそんなに怖くない

で、今回のセッションですが、「そもそもベジェ曲線って何?アンカーポイントって?ハンドルって?」という、初歩の初歩からのスタートでした。

そこから、直線の書き方、曲線の書き方、折り返しの仕方、と続いて行きます。

でもアンカーポイントを何処に置くのかも、ハンドルをどの方向に向かわせるのも、自由。だから、混乱しちゃうんですよ。何と言うか、「絶対正しい解法」みたいなのが分からないので、いくら練習用のサンプル見て分かったつもりでも、いざ何か描こうとすると、すごい不安になるという…。

ここで、CHEEBOWさん、「シンプルに考えよう」と、こんな提案をされます。

  • ハンドルの方向は、水平と垂直だけに決めてしまおう
  • そうすれば、場所と、ハンドルの長さを決めれば良くなる
  • そのために、頂点と折り返しにアンカーポイントを置く
  • あとは後で臨機応変に調整すればOK!

…なるほど……。使い方を限定すれば、シンプルな原則で描けるってわけです。思うように書けなかったら、あとから調整掛ければ良いと。

ここから、「水平」「直線」といった、基本がつまった「トランプのマーク」の実習に入ったんですが、……描けた!ちょっと怪しいけど、確かに描けた!何よりも、描く時に自分に迷いが無かったのが新鮮でした。前述の原則を守ることで恐怖心が亡くなった…といいますか。

これは練習のしがいがあるかもです。自分の好きなイラストやロゴをトレースする練習を重ねれば、苦手が克服できるかも!
素敵すぎるセッションでした。

「デザイン勉強会」に参加してきました!(その2)

デザイナーでない人のためのレイアウト入門

デザイン勉強会、トップバッターは、フリーランスでWebデザイナーをされてるcremaさん。

「部長からチラシ作りを頼まれた」というシチュエーションをベースに、レイアウトに関する「4つの原則」についてのお話をされました。

この「4つの原則」とは…

近接の原則
内容から幾つかのグループに分け、同じグループ同士は近づける、異なるグループは離す
整列の原則
見えない基準線にそって揃える、意味の無いでこぼこを撲滅する
対比の原則
重要なところを目立たせる(大きくする、太くする、などなど)
反復の原則
同じ性格のもののデザインを統一、繰り返す

この4つがレイアウトの原則。

この4つの原則を元に、酷い出来だったチラシをリデザイン。「確かにこれだと見やすい!」「これなら、このチラシが何を言いたいのかよく分かる!」と1つ1つ目で確認しながら原則が学べたので、すごく理解しやすかったです。

これってそういえば…

この4つの原則、実は薄らと、何かの本でで読んだ記憶があったんです。そういえば、だいぶ前に読んだ気がするなー、と。

そうしたら、セッションの最後の参考書籍に、その名前を見つけました。

ノンデザイナーズ・デザインブック」だ!

……すっかり記憶の中から追い出されてました…。これ、すごくいい本です。「チラシや、企画書、資料などなど、普段仕事などで作る機会のあるものをより良くデザインする」ための本で、Webのお仕事を始めた頃によく読んでました。もちろん、「4つの原則」もこの本の中に登場します。

プラスアルファ、が凄かった

じゃあ、cremaさんのセッションはこの本の内容と同じだったのかというと、ちゃんとプラスアルファがありました。

  • 実際に作業をする際のイラレのTips
  • 不自然な余白の処理
  • 視覚調整(数値だけに頼らずに行頭の位置を調整)
  • ジャンプ率(見出しと本文の比率)とその効果

実際に「4つの原則」にしたがって作業する際に知っておいた方がいいコツや考え方をしっかり教えてくださったんです。おぉぉ…。

原則を知った上でさらに一歩前に進むためヒントが沢山あって、「これさえ知っていれば、はじめの一歩を踏み出せそう!」って感じました。

なんでも「デザイン」できる!

前述の本のコンセプトもそうでしたけど、何気ない資料とか書類とか、仕事の中で作成してるものから始められる気がしました。デザイナーって肩書きじゃなくても、「デザイン」できるじゃん!と。

デザインって聞くと、何か手の届かない所にあるようなイメージがあるけど、デザインするものは身の回りに沢山あるのかもしれないな、と感じました。1つ目のセッションがこういった内容で、良かったです!

「デザイン勉強会」に参加してきました!(その1)

まもなくスタート

もくじ

本当に開催された!すごいや!

昨日、9月8日にノッキングオンさんで行われた「デザイン勉強会」に参加してきました!

この勉強会、「モバイル勉強会」「JavaScript勉強会」と同様、twitterでのやりとりの中がそもそものきっかけ。

自分の記憶が確かなら、6月の「JavaScript勉強会」の最後のセッションが終わった際、今回のデザイン勉強会主催のwoopsdezさんが

「ぜひ、わたしたちデザイナーから恩返しをさせてほしい!」

と提案されて、そこからtwitterでやりとりしながら、writeboardが開設されて、参加希望者・スピーカーを集めて、会場確保して、MLを作って、スピーカーの皆さんで事前に打ち合わせをして、……と一気に進んでいってました。

woopsdezさんの行動力たるや、すごいものがあるなー、とマジで感心しちゃいました。なんせ、mixiみたいにコミュニティがある訳でもないtwitterで、3〜40人の人が集まって1つのイベントが成立するって、なかなか出来ないことだと思うんですよ。いろんな人との信頼やつながりが無いと。

今回は、プログラマーをはじめ、普段デザインに触れる機会の無い人達に向けたデザイン入門、といった内容で、こんなプログラムになってました。

まずは、レイアウトの基本原則を勉強して、そこからベジェの書き方、名刺の作り方、と具体的な方法の話に移って、最後にWeb全体を俯瞰した「デザイン」の考え方の話、という構成で、デザインになじみの無い人にも分かりやすいように配慮されていました。

突然ですが超個人的な話

で、個人的な話になるんですけど、自分、デザインに関してはかーなーり苦手意識を持ってます。超持ってます。

Webのお仕事をコーダーから入って、デザインの仕事に触れる機会が殆どない、っていうこともあるんですが、……なんか、自分には立ち入れない領域なのかな、という思い込み?があって。

この前のエントリーにも書いたんですが、一時期、あるデザインの専門学校に週末だけ通ってた時期があったんですよ。デッサンしたり、絵本書いたり、イラレさわったり、有名な映像作品を見てみたり。でも、週1回だとさすがに全ての領域を網羅できず、あくまで「さわりだけ」教えてくれる、そういう内容だったんです。デッサンの仕方の説明があって、デッサンして、講評があって、おしまい、という具合。

もちろん、そこから、自分で勉強を続ければ良かったと思うんですが、当時の自分は「そうか。やっぱり、毎日通わないといけないのか」と思ってしまい、妙にモチベーションが下がってしまったんですよ。実習で作ったものが散々な出来だった、ていうのもあり。

で、その時期に、肺の病気を患ってしまって入院するはめになってしまい、それを境に、学校に行かなくなっちゃったんです。挫折した、て言えるほど、立派なものじゃないですけど。単に病気を口実に逃げただけの話で。

一応、友達のサイトを作ってみたり、ブログのテンプレートを作ってみたり、「デザイン」と言えるようなものは、やったにはやってたんですが、……なんか、やっぱり自分にはセンスがないなー、と思ってしまう事が多くて…。

だから、ここのブログのテンプレートいじる以外は、「デザイン」からは無意識に距離を取ってた気がします。「自分はXHTML+CSSの人だから!自分のテリトリーじゃないから!」と自分で壁をつくっちゃってた気がします。

今回、このデザイン勉強会に参加した理由は、この壁を乗り越えるきっかけがみつかるかも!という期待からでした。こういうお話を生で直接聞ける機会なんて、なかなかあるものじゃないので、「これを逃しちゃいけない!」と思って。

で、どうだったのよ、実際

実際参加してどうだったかというと……、これが大正解でした。

「これでデザイナーになれる!」とかではなくて、単純に「自分も何かデザインしてみたい!何か自分の手で作ってみたい!」って気持ちになりましたよ。
別に仕事じゃなくていいから、趣味とか特技とか、そういうレベルでいいから、何かしてみたい!っていう気持ちです。
参加してよかった!心からそう思いましたよ、マジで。

…では、これから簡単に各セッションを振り返ってみます!

マークアップエンジニアも幸せ探し(中編)

前回のあらすじ

さて、中編です。(前編はこちら

…あれ?後編じゃなかったっけ?という皆さん。その通りです。

正直、書きながら結論がどんどん見えなくなってきてしまって、ただ無駄に長くなる一方なのです。なんか、大学時代の卒論を思い出した…。

とりあえず、前編の要点をまとめておきます。

  • 「コーダー」「オペレーター」はどうしても受け身になりがち
  • でも、末端の工程だからこそ、それ以前の工程の粗が沢山見えてくる
  • 上の工程に物申すべき!
  • 上の工程に物申せるように、守備範囲をどんどん広げてしまう!理論武装、みたいな。
  • 会社的に動かないのなら、自分でやってしまう
  • 上の工程に意識的であることで、案件の目的とか意義が分かって、仕事に対するモチベーションが変わるかも
  • …でもここまでしても「コーダー」「オペレーター」なのはどうなの?邪魔じゃない?

というわけで、まずは「マークアップエンジニア」の話から。

…という訳で、マークアップエンジニアの話

マークアップエンジニア、ってどういう仕事なのかというと、bAの募集要項にさすがに簡潔にまとめられてます。(ちなみにbAでは、マークアップエンジニアではなく、マークアップデザインエンジニアに変わってます)

マークアップデザインエンジニア

HTML/XHTMLのマークアップ、情報設計および文書構造のデザイン、エンタープライズCMSのテンプレート設計・開発、CSSの設計およびコーディング、JavaScriptのライブラリ設計・開発・実装。以下の技術に関する研究・設計・開発:XMLをはじめとする多様なウェブフロントエンド技術全般、アクセシビリティ、ユーザビリティ、各種オーサリングツールや開発プラットフォーム。経験年数不問。

[bA] 募集要項

「設計」「開発」「研究」って言葉が並んでいる時点で、「コーダー」「オペレーター」とはだいぶ印象が異なります。単純にコーディングするだけではないということがハッキリ分かります。作業工程の最後の辺りに位置することには、変わりなさそうですが、受身的な印象がありません。何より、「以下の技術に関する研究・設計・開発:」というところに惹かれます。この研究・設計・開発、やりたいっすよ。超やりたいっすよ。

…と、これだと「bA入りたい!」って話で終わってしまいますが、「コーダー」「オペレーター」とは異なり、工程の上流、設計といったものがちゃんと視野に入っているのが「マークアップエンジニア」なのかなと。Webオペレーター時代の自分にとっては、憧れの肩書きでした。実際、去年の年始の挨拶で、こんなことを言ってます。自分。

Webのお仕事ですが、今年は「脱コーダー」「脱Webオペレーター」で行きたいと思ってます。…っていっても、いきなりディレクターとかデザイナーに転身する訳でもなく、今の方向をもっと突き詰めて行きたいなぁと。最近、耳にする「マークアップエンジニア」だとか「インフォメーションアーキテクチャー」とか、そういう、“ただの作業”に終わらない、Webの本質的なところを考えられる人になりたいと思ってます。(necoze LOG2 [ネコゼログログ] | 謹賀新年

「人は肩書きなのか」問題

で、ここで「肩書きってそもそも何よ」という話。

「マークアップエンジニアテーブル」の中で、bAの方々が繰り返しおっしゃっていたのは、

職種は具体的にやることを明確にする場合のためのものであり、基本は全員Webデザイナー

そのスキルを持っている人が適切に工程に配置されれば良いので、マークアップエンジニアがプロジェクトマネジメントをしたりIAを担当したりもする

自分の持つスキルの中で最もとんがったものが職種

個人的にこのセミナーでの一番の収穫はこれです。職種というのは、その人の一番売りとするスキルを分かりやすく表したものだという考え方。何もそれに縛られる必要はなくて、それ以外に持つスキルもワークフローの中で適切に発揮されるべきだと。

自分も、やりたいことを手当り次第にやって、結果「コーダーとかオペレーターとか、肩書き邪魔だなー」と思ってた訳ですけど、それは肩書きを「自分の仕事内容を定義づける」というか「限定する」って印象を持っていたからなのかもしれないです。自分はこれしかやらない、これしかできない、って予防線を張ってしまうというか。

だから、肩書きだけで自分を見るとか、人を見るって言うのは結構危険なのかなとも思います。長谷川恭久さんのpodcastでも、以前、「人は肩書きになりたいんじゃない、“自分”になりたいんだ」ということをおっしゃっていて(Inflame Casting: IC #101 July 19 2007)、ホント、その通りだなと思います。世間に自分の売りを分かりやすく表現する為の方法が、肩書きであって、自分はそこから自由であっていいんじゃないかと。

だから、自分は「マークアップエンジニア」でありたいと同時に、それ以上の何かになりたい、って思ってたりします。

「自分の代わりはいくらでもいる」 問題

急に話は変わりますが、以前勤めていた職場は、自分を含めスタッフの半数近くが派遣社員でした。結構頻繁に、スタッフは入れ替わっていた気がします。

これは別にこの職場に限らない話で、昔、派遣のコーディネーターの方から聞いた話だと、大手の制作会社でもこういう感じの所が多いとか多くないとか。…いや、具体的に会社名言われて、ええ?あの会社が?…って感じだったんですが(謎)。よっぽど派遣の方が、名の知れた会社に潜入できるのかもしれないなー、と。そんな会社に必ず行ける保証はどこにも無いですけど。でも、新卒のころ、必死こいて受けまくってた制作会社に、派遣であっさりと行ける可能性があると聞かされた時は、なんか遠回りしたのかなー、と思ってしまった訳です。

…それはさておき、派遣のスタッフが半数近くを占める職場で、「弊社の優秀なスタッフが〜」とか「信頼の制作体制」とか、そういうキャッチコピーを打たれても、「でも、結局派遣頼みじゃん」と思ってしまうわけです。その会社のノウハウを徹底的に叩き込まれたエリート集団、みたいなイメージだけど、そうじゃないじゃん、と。そうなると、会社はタダの入れ物に過ぎなくならない?、と。その会社のアイデンティティとかオリジナリティって何だろうなー、と思ってしまう訳です。

でも、これは自分を含めたスタッフ側にも言える問題だったりします。自分がその会社との契約を切ることになると結構すぐ、自分の後継のスタッフが決まってます。「自分って結構会社から頼りにされてるのかもなー」ぐらいに思っていたとしても、あっさりと後継の人は決まります。…あれ?自分の代わりなんていくらでもいるの?……いや、いくらでもいるんです。たぶん。

例えば、今、自分は「マークアップエンジニア」って肩書きで、マークアップやらCSSの設計やらで会社に雇われてますけど、自分より若くて、XHTMLやCSSに精通してて、すごいモチベーション高い奴なんか、たぶん、うようよいるんですよ。CSS Niteとかいろんなイベント参加してきた実感として。だから、会社には面談とかあるたびに「自分の代わりはいくらでもいますから」って言ってしまいますし。

結局、何が言いたいかというと、「他には替えられない自分になりたい」ってことなんですよ。肩書き単位で見れば、持ってるスキルとか経験から判断して、自分と同じような人と入れ替えられるのかもしれないけど、それ以上の何かを身につけておきたいなと。そう、さっきの肩書きの話です。

「刺激が無い」問題

「マークアップエンジニアテーブル」のパネルディスカッションで、出演者(=bAのマークアップエンジニアの皆さん)に「いつ、どうやって勉強してますか」という類いの質問があったのですが、その回答は一律「普段、仕事をしていくなかで勉強してるつもりだから、特に勉強する為の時間は設けていない」というものでした。

考えてみれば、自分の意図しない場面で、あたらしい技術を身につけなきゃいけない必要迫られることがよくあります。ブラウザの未知のバグだったり、触ったことの無いCMSのテンプレートだったり。エラーを起こしてるJavaScriptだったり。仕事して行く中で、どうしてもそういう場面にはよく遭遇すると思うんです。自分が始めた頃なんかは、全てが知らないことだらけなので、殆どの作業がそんな状況でした。1年で、メモ書きがノート5冊分くらいになったくらいです。

仕事が忙しい中で、勉強する時間を確保するのは、なかなか難しいです。この本をいつまでに読もう!とか、「あとで読む」に残してたページを読もうとか、思っていても忙しいことを良いことに、いつまで経っても進まなかったりします。でも、その忙しい仕事の中から、新しく得た知識とか技術に意識的であれば、それもまた勉強になるって訳です。

ただ、毎日同じ作業の繰り返し、という状況ではどうでしょう。極端な話、自分が以前いた職場では、担当してるサイトが固定されていたので、毎週同じような更新を繰り返してました。だから、そこから学ぶことっていうのは、ほとんどなくて、「メモ書きがノート5冊分」どころか5ページもいかないんじゃないかという状況。ここから学び取れることといったら、「この作業をどれだけ早く効率的にできるか」とか「そもそもこの作業は必要なのか」とかそういうことくらいです。

「Webは別に好きじゃないし」問題

Webオペレーター時代の自分は刺激の無い状況に危機感を抱いてました。日々の仕事の中の経験から学ぶことが多いと思っていたので、それが無いとなると死活問題。こうしてるうちに、自分の同業者から差を付けられてる!気がする!以前の職場では、CSSレイアウトを一切していなかったので、ブラウザのバグに悩まされることが無かったが故に、経験値が圧倒的に不足してた、ということもありました。とにかく、仕事に刺激が足りない!仕事に刺激を!

ここで問題なのが、今いる職場を刺激のあるものにするのか、それとも刺激のある職場に移籍するのか、ってことです。

「刺激のある職場に移籍」が手っ取り早いのですが、「今いる職場を刺激のあるものにする」っていうのも、周りの環境を自分の手で変える面白みがあるかもしれません。

が!ここで問題なのが、「別に刺激とかいらないじゃん」って人がいることなんです。

自分みたいに、毎日LDRでfeedをチェックしたり、はてブにブックマークしたり、twitterしたり、flickrに写真上げたり、…年中Webと戯れてる(?)Web大好きな人がいる一方、
全くそうじゃない人もいます。mixiをやる程度で、「Webは仕事」だと線を引いてしまってる人。RSSもソーシャルブックマークもチェックしてないし、情報源はYahoo!トピックスだという人。
仕事とプライベートをはっきり分けてるか、分けてないかの違い、とも言えるかもしれません。

そんなWebに興味が無くて、仕事が成り立つのかというと、前述のように、日々の仕事が固定化されてる場合は、それでどうにかなってしまいます。長い視点で考えれば、それで良いとは言えないですけど。

Webの面白さとか楽しさとかに気付いてもらえるように、MLに見つけてきたサイトの紹介を流したりとか、ミーティングで最近流行ってるWebサービスの話をしてみたりとか、とにかくこっちに振り向いてもらうために、手を尽くすしか無いです。周りが変わるのを待つよりかはだいぶましです。変わってくれる保証なんて無いですから。

良く分からない奴になりたい

前編で、「自分の守備範囲をどんどん広げる」って話をしたんですけど、じゃあ、今の自分はどうなのかという話。

最近はコーディングばっかりやってますけど、極端な話、DreamWeaverを殆ど開かずに、エクセルばっかりいじってた時期とかもあります。ミーティングを仕切ってみたり、議事録書いてみたり、資料作ってみたり、企画のネタ集めたり、セミナーの報告まとめたり………あれ?

今いる会社って、実は「マークアップエンジニア」って肩書きの人間は僕1人しかいません。あとは、デザイナーとディレクターが20人くらい。もともとはデザイナーが、コーディングとかの工程までやってた会社なんですよ。で、CSSレイアウトでかつ大型の案件だったりすると、個人プレーでは立ち行かなくなるところがあって、で、雇われたのが自分、って訳です。

だから会社的には、初めは「マークアップエンジニア」って肩書きはもらいつつも、どう仕事を振ったらいいものか、自分も身の振り方が分からない、って状況があり、結局ひたすらコーディングを手伝うっていう、コーダー的な立ち位置に落ち着いてたんです。ただ、徐々に、上の工程に首を突っ込めるようになってきて、大きい案件の制作進行を仕切ってみたり、立ち上げから関わってみたりと、テンプレートを作ってみたり。状況は変わってきたかなと。会社的に、「デザイナー」「コーダー」みたいに、はっきり分業している訳じゃないので、「デザイナー」さん向けに、社内でCSSの勉強会開いたりもしてます。

もう、コーディングだけじゃなくて、何でもやりたい。会社には“成果物の「目に見えないクオリティ」を向上させる立場になりたい”って良く言っていて、そのためなら、気になるものは何でも身に付けてみたい。

なかなか食わず嫌いでいた、JavaScriptとかPHPとか、プログラムにも首を突っ込んでみたい。マークアップを真剣に考えれば、IAも勉強しておきたい。

「マークアップエンジニア」ってものを軸に、自分にしかないものを作っていきたい、そう思ってます。

…これ、本当に結論に辿り着くの?

次回、後編、というか完結編に続きます!たぶん!

マークアップエンジニアも幸せ探し(前編)

Webの仕事を始めてから、4年半が経ちます。…って、もうそんなに経ってますか(遠い目)。

「マークアップエンジニア」という肩書きになってから一年半が経ちますけど、それまでの間は、派遣社員で大手制作会社で一年、テレビ局で二年、「Webオペレーター」として働いていました。
「HTMLコーダー」「コーダー」とも呼ばれましたが、契約上はそういう肩書きでした。

「オペレーター」って聞くと、それこそ、コールセンターとかで応対してる人、みたいなイメージがあるので、初めて契約書でその名前を見た時にはビックリしました。
派遣の募集要項には「Webクリエーター」ってあったのに、蓋を開けてみたら「オペレーター」。
そもそも 「Webクリエーター」ってどういう仕事だよ、って気もしますが、当時は「騙された!」とさえ思いました。

だから、「Webオペレーター」よりも「HTMLコーダー」って肩書きの方がよっぽど好きでしたし、今もそうです。だから、「昔はWebオペレーターだったんですよー」なんて言えません。

そんな「Webオペレーター」時代の自分、と、それ以前の自分を、ちょっとだけ紐解いてみたいと思います。

この業界に潜り込んだ経緯

Webに関しては学校で学んだ経験が全くありません。デジハリのパンフレットを読んでは妄想を広げてはいましたが(関係ない)。
大学でサークルのサイトを作っていたくらいで、HTMLのソースはなんとか理解できる程度。DreamWeaverやPhotoShopは仕事を始めるまで殆ど触ったことはありませんでした。
イラレなんか立ち上げた日には、起動画面だけでもの凄い緊張したくらい。

この程度の自分が、デザイナーやプログラマーに簡単になれるとは思っていませんでした。実際、無理です。
就活でいろんな制作会社を回りましたが、全て奇麗に落ちました。運良く最終面接まで行った会社もありましたが、最後に待っていた言葉は全て「君は営業になる気はないのか」でした。
「ないです」と答えた後に何が起きたかは、……ご想像にお任せします。

そんなこともあり、どんな形でもいいから、Web制作の世界に潜り込みたいと思ってました。バイトでも見習いでもいいから、とにかくスタートを切らないと!
そんなこんなで、大学を卒業して、友達はみんな就職して働いている中、自分がある制作会社で働かせてもらえるようになったのは、6月を過ぎてからでした。

Webオペレーターというお仕事

「Webオペレーター」として働いていたころの仕事内容としては、請け負っているサイトの更新作業がメインです。
与えられた素材・原稿を元に、ページを新たに追加し、アップしていく作業です。新たにサイトを一から構築する機会もありましたが、それは稀。時にはバナーを作成したりもしますが、それも文字を打ち変える程度。JavaScriptは他人様のサイトから拝借しては多少カスタマイズできる程度。そんな感じでした。

とにかく指示された作業を素早くミス無くこなすことが求められます。しかも、仕事を始めた当初は、素人そのもの。分からないことだらけです。とにかく指示通りに作業することたけで必死でした。分からないことはすぐに調べる、先輩に聞く、その場その時に解決する。毎日必死でした。仕事内容はとにかく地味でしたけど、今よりも必死でした。毎日覚悟を決めて出社してたくらい。

「言われた作業を言われた通りやる」ということは、逆に言うと、それ以前の工程に口を挟む権限は無い、というかそもそも発言するタイミングがありませんでした。とにかく、次から次へと作業は入ってくるのを片っ端からこなすことで精一杯でしたから。いかに、手持ちの作業を終わらせて終電までに会社をでるか、で頭がいっぱいだったというか何と言うか。

ただ、作業にだいぶ慣れてきてから、いろいろと疑問は感じるようになりました。「このページで、“お問い合せ”と“お問い合わせ”が併存してるけど文言統一した方がいいんじゃないの?」とか、「このサイト、グローバルサイトのはずだけど、Shift_JISで作ってるのはマズくない?」とか。で、結構、その度さりげなく伝えるようになりました。「○○○○のページ作っておきました。あ、あと、ちょっと気が付いたんですけど…」という具合に。

コーディング以前の工程が気になりだしたのはこの頃からです。

未来も喜びもありません

Webオペレーターの仕事を続けていると、「自分はいつまでこの仕事をしているんだろう…」なんて不安にかられます。
毎日似たような作業の繰り返し。何か、今ひとつ、自分の将来が思い描けない感じがありました。
会社の先輩に、酔った勢いで「お前は、いくら頑張ってもDream Weaver以上にはなれないんだよ!」って言われて、ガーン、と思ったこともありました。
酒の席でディレクターに「お前が将来どうしたいのか、俺にはさっぱり分からない」と言われて、 ガーン、と思ったこともありました。
なぜなら、本当にそうだったから。自分は、ただ、ページ量産マシーンに徹してさえすれば、給料もらえるし、評価もされるけど、それ以上の何かがさっぱり見えてこない、そんな状況でした。

かといって、デザイナーになるにも、今すぐなれるほど簡単じゃないです。以前、毎週土曜に、デザインの専門学校に通ってみたりしましたが、半年も経たないうちに挫折しました。週1でマスターできるほど簡単じゃないわと。

ブログを更新するにもネタがありません。昔、こんなことを載せていたくらい。ネタがないことをネタにするくらいしか無かったんです。マジで。

たまには会社での仕事の話でも、とは思うものの、新規で大規模なサイトのコーディングとかが無ければ、大抵は先方から支給されたテキストデータや画像を流し込んで、整形して、加工して、ハイ!出来上がり!みたいな単純作業が中心なので、これといったネタもないのです。(単純作業のジレンマ

何よりも、新規案件が無事納品できた時に、「これでこの作業から解放される…」って安堵感はあるものの、「PV伸びた!」とか「注文増えた!」とか「お客さんに褒められた!」とか聞いても、なんか、いまいちピンとこない、というか別にどうでもいいと思ってしまう自分がいました。それ以前に、そんな話がそもそも聞かされない、なんてこともありますが。

そもそもの目的

Web制作のお仕事において、何らかの作業は、クライアントの何らかの目的を果たすためのものです。ただサイトを立ち上げさえすればいい、なんて、地面を掘ってはまた埋める、みたいな仕事は存在しません。たぶん。そして、案件よって、その目的も、解決する為の手法も異なる訳で、そこを考えるのが難しくも面白くもあるんだと思います。たぶん、このお仕事の醍醐味はここにあるんだと思います。

そんな中、コーダーやオペレーターという立場の人は、作業工程において「末端」に位置しています。
企画・設計・デザイン、といった工程を経てできあがってきた物を、最終的に実際にブラウザで閲覧できるように落とし込んでいきます。
だから、そうであるが故に、「この案件が持つ目的」を知らずとも、作業はできてしまいます。
ただ上の工程からの指示にさえ従っていれば、成果物は一応出来上がりはします。

そのため、案件が終わった時の達成感が、他の肩書きの人々にくらべて、何だか薄く感じてしまいます。
案件の目的を知らない以上、どの案件も、同じような作業に見えてしまっているが故に、「何かを解決した」とか「誰かに喜んでもらえた」とか、そういう感覚からは遠いような気がします。
目の前の作業をとにかく終わらせる、とか、目の前の赤字原稿を減らす、とか、それだけで必死。「目的?何それ?」というのが正直なところ。

でも、「上の作業工程」に不満が無いかと言えば、ウソになるはずです。絶対に何かあるはずです。
ディレクション、スケジューリング、用意された原稿・素材・デザインetc…。作業を対応するなかで、何かしら思うことはあるはずです。絶対。

「末端」にいるからこそ分かること

今となっては余り考えられないことですけど、

  • ディレクトリマップが無い
  • サイトマップも無い
  • 仕様書も無い
  • コーディングルールも無い
  • 文字コードの指定も無い
  • ターゲットブラウザの指定も無い

こんな状態で作業を振られた経験が過去に何度もありまし、

  • 渡された元のHTMLファイルに代替テキストの指定が1つもない
  • 閉じタグがことごとく無い
  • 今時フレームを使ってる

こういうHTMLファイルに遭遇することもよくありましし、

  • いつ作業を振られるのか分からない
  • いつ納品で、何時公開なのかも分からない
  • 案件全体のスケジュールはどうなってるのかも分からない
  • …どころか、「これ、あと1時間で公開だから」といきなり原稿渡される

こんな状態で作業を断続的に振られることもよくありましし、

  • クライアントから「この文字を青くしといて」と言われ、指示通りに青くし、「赤くしといて」と言われて赤くし、…を繰り返した結果、クライアントから「なんか色がバラバラだから統一してくれない?」と言われる
  • クライアントから「ここの文字間を広げて欲しい」と指示されて、文字と文字との間にspacer.gifを挟んで対応するように言われる
  • 「画面の上から○○cm、左から○○cmに画像を配置して欲しい」とクライアントから指示が来て、定規でディスプレイを計ってピクセル数を割り出そうとする

作業以前の問題をはらんだ指示が下りてくることもありました。(※これは実体験です)

作業工程の「末端」に位置しているが故に、こういった「粗」は良く見えてきますし、「こんな状態で仕事振ってくるな!」と思うこともしばしば。それは、コーディング以前の設計・仕様の問題です。
「末端」の工程には、それ以前の工程のしわ寄せが全てやって来ます。すなわち、 「その案件のクオリティ」がどれ程のものになるか分かるのもこの工程だと思います。
ディレクターやプロデューサー、デザイナーには問題と感じられないものが、ここで鮮明になるはずです。

スケジュール的に、これ以前の工程に後戻りすることは大抵の場合難しいと思います。でも、また同じことが繰り返されない為にも、
ここで、何の疑問も感じずに言われた通りに作業をすすめるのではなく、ここで上の工程に物申していく必要があるはずです。
自分は、今でもそうですが、とにかく物申しまくってました。うざがられてるんじゃないかと思う程。
自己防衛、ってこともありましたけど、それよりも、「これが当たり前」とは決して思われたくない、というか「これはマズい」と認識して欲しい、という気持ちがあったからです。
何も言わずにいたら、状況が変わる訳ないですし。

「末端」という響きから、何か弱い立場のようなイメージがありますが、僕は決してそうではないと思いますし、むしろ重要な鍵を握ってると思います。

「CSSレイアウト」というキッカケ

ある時期から話題になり、今となっては珍しくなくなってきた「CSSレイアウト」ではよく「構造と表現の分離」ということが言われます。

「表現」に関する情報は外部のCSSファイルに記述されいきますから、PSDファイルを1つ1つコーディングしていくという、テーブルレイアウトではあたりまえだった手法では効率が悪くなります。かつては、コーディングを複数人で手分けして作業していましたが、単純にPSDファイルを渡すという訳にはいきません。

だから、予めサイト上で使われるあらゆるレイアウトのパターンを割り出して、パーツ化してそれを組み合わせてページを構築できるようにするとか、CSSファイルを使用する部位別などに分割するとか、そういった工夫ができて、はじめて複数人で手分けして作業ができるようになります。

また、「構造」に関しても、どの要素を使うのかとか、id・class名は何にするのか、とか、何かとそのデザインの「意味」が問われます。単にテキストを枠線で囲むだけでも、その枠線は何を意味するのかが求められます。

いずれにしても、以前の通りのワークフローで仕事を進めようとすると、より末端の負担は大きくなります。
何度か、そんな状態で 「CSSレイアウト」の案件をやったことがありますが、……思い出したくもないです(本気で)。
「CSSレイアウト」では、単純に渡されたPSDファイルをコーディングさえすればいいというものではなくなりました。それ以前の設計が重要になったんです。

だから、「CSSレイアウト」が流行り始めた当初、コーダーとかオペレーターとか、末端にいる人達の扱いが変わるんじゃないか、と思ってました。むしろ、言うことは言わないと、ますます自分の首を絞めることになるんじゃないかとさえ思ってました。

「愚痴」の怖い話

仕事の愚痴って何かと出てきます。今でもそうです。で、言うとスッキリします。酒入るとさらにどうでもよくなってきます。自分、酒飲めないですけど。

でも、それで終わりなんですよね。別に状況は変わらない。会社も変わらないし、ワークフローも変わらない。で、また愚痴るという果てなく続くこのストーリー。

じゃあ、自分はどうなのかというと、2年くらい前に、mixiの日記にこういうことを書いてました。

昼休みに職場の愚痴を話すことになっても、「じゃあ、こうすれば面白いよね」って《これからの》話に必ずつなげる。あと、いろいろ問題の多い職場から給料もらってる身だってことを忘れない。他人事みたいに会社や職場の人達を陰で叩かない。

…自分で書いといて、胸の痛みを抑えきれなかったりしますが、それはさておき。

職場や同僚に不満がある一方で、その職場や同僚に守られてる自分、ていうのもいる訳ですよ。そこを棚に上げて、あれが悪い、こいつがむかつく、この会社は駄目だ、みたいな話をするのは本末転倒な気がするんですよ。だから、この時期に、それを止めて、具体的に何をすれば良くなるか考えよう、と。

会社がやらないなら自分でやってしまう

さっき、サイトマップや仕様書が無い状態で仕事が振られる、という話がありましたけど、そういう時は、自分で勝手に用意するようにしてました。頼まれもしないのに。

ディレクトリマップ・サイトマップも作りましたし、仕様書も作りましたし、勝手にスケジュール切ったり、案件のタスクをcheck*padで管理してみたり、あげくの果てには企画書書いてみたり。社内SNSを勝手に開設してみたり。

別にコーディング以外のことは何も期待されてないですし、自分の仕事の範疇ではないはずですけど、無ければ自分で作ってしまえばいいと思って、勝手にやってました。日々、作業の中で不満に思っているものの中で、自分でできてしまいそうなものは、自分で作ってしまおうと。あと、何よりも、上の工程に首を突っ込める面白さがありました。

あと、上に「物申す」時に、説得力を持たせたいために(あと、単純に興味から)SEOやユーザビリティ、アクセシビリティの本を読んだり、セミナー行ったりしてました。

会社が変わりそうも無かったら、自分で変えてしまえばいい、そういう訳です。

こうしていくうちに、仕事の本質的なところ、「自分は何のため・誰のためにこの仕事をしてるのか」ということを意識するようになってきました。
自分の守備範囲を広げることで、その案件の面白さをより感じられるようになったのかもしれないです。

マークアップエンジニア

あれもこれも勝手にやってると、「コーダー」「オペレーター」という言葉に違和感を感じるようになります。
自分はコーディング以外にも興味があって、いろいろ試してみたり勉強してみたりしてるけど、結局「コーダー」「オペレーター」というくくりで見られてしまう。

そこで出会ったのが、「マークアップエンジニア」という名前でした。詳しくは、自分がnowaに載せた、名付け親の森田雄さんの講演メモを読んでもらうとして(necoze nowanowa - [メモ]「マークアップエンジニア・テーブル」(W2C 定例セミナー)その1)、単純にHTML・CSSだけに留まらないものを期待されてるところに惹かれました。むしろ、こういう奴になれたらいいなぁ、とさえ思ったほど。

…という訳で後編に続きます。(※まだ前振りのつもりです)

追記

話が無駄に長くなって、中編に続きます。中編って。

「マークアップエンジニアも幸せ探し」(予告編)

今何かと話題(IT戦記 - マークアップエンジニアはどこへ向かうべきか(を考えてたらカッとなって LL の資料公開))になってます。「マークアップエンジニア」云々について、何か書こうとおもっている……のですが!、仕事がかなりごった返していて、なかなか思うように時間が確保できません…。この煮え切らない気持ちを貴方へ…。

ただ、このまま何も言わずにいるのも何なので、ひとまず前振り程度のものをアップしておきたいと思います。

貴方、1年前に似たようなこと言ってる人がいるよ

はい。見出しの通りです。…って誰がだよって話ですが…、自分です。自分。

ちょうど1年前、僕がCSS Niteのアフターイベントでやったプレゼンがあります。「マークアップエンジニア」云々については書きたい事がいろいろあるんですが、未だに言いたい事はここにつまってるかなーと。

いい加減、このプレゼンを引き合いに出すのは止めようって思っていたんですが、自分が「マークアップエンジニア」云々について考えると、どうしてもコレに行き着いてしまうので。

ただ1点言わせてもらうと、amachangさんのエントリーの中の「マークアップエンジニア」って、自分のプレゼンの中の「HTMLコーダー」とかなりだぶるんですよ。ここが、「言いたい事は分からないでもないけど感じる違和感」の正体なのかなと思うんですよ。それは、僕からすればマークアップエンジニアなんかじゃないっす。

…という訳で

続き、というか本編は今週末!いろいろ言わせてもらいます!

「Web標準の日々」復習会に参加してきました!

昨日、「Web標準の日々」の復習会に参加してきましたー!

……あれ?復習会なんてオフィシャルに告知あったっけ?とお思いの方。それもそのはず。
当日参加されてた皆さんで、勝手に企画して勝手に決行した会なのです。超アンオフィシャル企画です。

それぞれ自分が参加したセッションの内容について、当日配布・公開された資料&自分で用意したレジュメなどを元に、発表しあうものだったのですが………、
いやー、これは参加して大正解でした。本当に良かったです。
では、何が良かったのかと言うと…

自分の頭の中を言葉にするということ

まず、この「発表し合う」という形式がすごく良かったです。

今回参加された方はセッションが殆ど被っていなかったので、発表する人は、基本的に「当日そのセッションに参加していなかった人」に向けて、その人達に伝わる発表をしなきゃいけません。「いやー、良く分からなかったから、パスでー」とか許されません。

だから、発表する人は、参加されてない人に伝わるように、そのセッションの「何が重要で/何が面白くて/どんなことを考えたのか」を自分の中で咀嚼しながら、自分の言葉にして簡潔にまとめることになります。

この過程で、自分の頭の中に会ったものを形にすることで、発表する人にとっても当日の内容を深く理解することができたんです。自分の中に定着させることができた、とでも言いますか。

ブログで当日のレポートをアップされてる方も、こういう過程を経て、内容をまとめられていると思うんですけど、何せ直接人前で発表するので、適当に済ませる訳には行きません。ごまかしがきかないです。ドキドキです。

聞く側も、当日参加された人の実感のこもった発表を聞くことで、後日公開される資料を読んでいただけでは伝わらないものを掴むことができたんじゃないかなと思います。

資料を読むだけでは、読んで満足して、「ふーん」で終わってしまう恐れがあると思うんです。それを実際に仕事の中で生かそうとかは考えずに終わってしまう恐れがあると思うんです。実際自分がそうですよ。なんど、音声ファイルを聞きながら爆睡したことか(恥)。

でも当日参加された人の「ここは参考になった」とか「これは仕事で使ってみたい」とか、そういう言葉があるだけで、ただ資料を漫然と読む以上のものを確実に得ることができたんです。実感を伴った言葉は、やっぱり響くものがあります。全然違います。

このイベントを点ではなく線で理解すること

そして、今回、いろんなセッションの内容を発表し合うなかで発見したのが、一見、テーマも取り上げる題材もバラバラに見えたセッションに、思わぬ共通点があったこと。これは本当に収穫でした。声を大にして言いたいです。

  • SEOのセッションで言ってることが、ユーザビリティのセッションでも言及してたり
  • ユーザーエクスペリエンスのセッションで取り上げられていた概念が、XHTMLのトラックでも取り上げられていたり
  • アクセシビリティのセッションで話題になったトピックが、ブラウザのセッションでも話題になってたり。
  • 1つの本を複数のセッションで「オススメ」されていたり。

発表する度に、そういうものが浮かび上がってきて、その度にみんなで軽く興奮してました。

この会に参加するまで、自分は、それぞれのセッションがそれぞれの中で完結しているイメージを持ってました。でも、それは違ったんです。
この「Web標準の日々」というイベント全体を通しての視点がそこには欠けていたんだと思います。便宜上、幾つかのトラックに分かれていましたが、実はトラックの枠を超えた共通のメッセージが、このイベントにはあったんじゃないかなと思うんです。それは、60以上のセッションを通してではなく、参加した人が受講したセッション達を通して。

イベントを意義あるものにするのもしないのも自分次第

1万円を超える参加料を支払ってまで参加してるんです。元を取り返すくらいの気持ちは必要なんだと思います。
会社のお金で参加してるなら、会社に何か還元しなきゃいけない責任を負ってはずです。

ただ、セッションを受けるだけでは何も得るものは無くて、残るのは当日の資料だけ。
参加する人は、「ただのお客さん」でいることもできますが、それでは駄目なんだと思うんです。

そうじゃなくて、そのイベントの中から、自分に取って有益なものを手に入れようとする気持ちが必要なんです。このイベントを自分にとって価値のあるものにしようとする気持ちが。

今回、こうやって復習会をすることで、「Web標準の日々」に参加して本当に良かったと感じています。それは、このイベントを価値あるものだと、復習を通して感じることができたからです。

お疲れ様でしたー!

復習会に参加できて良かったです!当日、幹事をされたcremaさん始め、参加者の皆さん(あ、idかハンドル出しちゃっても良いですか?)本当にありがとうございましたー!
また、何か大きなイベントがあった際にはまたやりましょう!!

[「Web標準の日々」速報]「パネル・ディスカッションブラウザはどこに向かうのか?」

2日目ラストのセッションですが、予定変更しました。ブラウザのパネルディスカッションへ。やっぱり、この顔ぶれはあり得ないです。

木達さん挨拶
いよいよスタート。
「Web標準」の言葉の定義
「企業が作った技術」を入れるかどうかで、若干の違いが
microformats
各ベンダーの対応について。mozillaは明言はできないけど前向き。IEは無視してる訳ではないが特に発言はなし。operaは興味深いとしつつも…。
あとでまとめます…
メモが追いつかなかったです…

中の人、ご紹介

制作会社でマークアップ芸人、改め、うっかりIA(自称)をやってます。CSSとかHTMLとかでもご飯食べてます。気が弱くて省スペース設計。でも小言が多い、環境に優しくない32歳です。

過去のイベント出演暦