nayucolony

勉強したこととか

WordCamp Tokyo 2017にスピーカーとして参加しました。

WordCamp Tokyo 2017 | テーマ「Join 〜 つながる人・つながる世界・つながる未来 〜」2017年9月16日(土)-17(日) 開催 ベルサール新宿グランド 5F コンファレンスセンター

にスピーカーとして参加しました。

※セッション内で口約した「あとでフォロー記事書く」といったやつとは別の、参加報告エントリです。技術的な面は、改めて書きます。

登壇スライド

詳しい技術的内容は追って説明記事を書きます。

ひとまずは、参加しましたブログをかかないことには終われませんので、そういうブログを書かせてください。

今回この話をしようとしたきっかけは、「目の前のことに手をつけたら広がりに広がって一連の開発プロセスを経験できたので、せっかくだから外部化したい!」という思いと、ちょうどWordCampTokyo2017のCfP募集の時期が被っていたことでした。

会社のブログを更新する気がなかなか起きないという現状があります。

その原因を辿ると

「ネタはある、書きたいこともあるが、WordPressのエディタだとやる気がでない。しかし、手元で好きなエディタでマークダウンで書くと、それをWordPressで見れるようにする作業が発生する。レビューしてもらうのもめんどくさい。みんな忙しいしもういいや」

こんな感じでした。

実際、下書きのまま公開してない(あと一歩で公開できる)レベルのデータは存在します。ただ、メインの制作や個人活動に時間をさくと完全に「いつかやろう」状態。

これを打開するためのプロセス構築が、今回の事の発端でした。

そして、構築するにあたり、どうせ作るならいいものをと思って実際の紙のメディアのフローも参考にしました。執筆と出版(デプロイ)の間にあるものを、コンピューターで処理できればいいのではないかと。そのあたりで「校閲」というワードがピンときたのでした。

こういう「当たり前だけど、当たり前にすることがおろそかにされがちな行為」を原点にちゃんとしようとする性格があり(マークアップなんかもそう)ここをかなり勉強しました。

そして、「なぜちゃんとしないといけないのか?」という部分にもどって考えるということもしました。どちらかというと、僕はちゃんとしたいから、ちゃんとしないといけないんだという主張を通すための、理屈がとおるような理由を探しました。

とりあえずこれらの本は読みました。

もっとあるけどこの辺で。

そして、大した理由は書いてませんでした(笑)。もう、当たり前のようにその行為のことについて書いていたので、「あぁ、そもそも間違ったもの、世に出せないよな」というなんとなくな部分に着地しました。スライドでは「あやまった情報を出すことで信用を失う。真摯に向き合ってないことがバレる。読み手がこちらの情報に真摯であるほど失う信用はでかいし甘く見てはいけない。信用で色々なことが生み出せる今の時代でそれは大きなロス」みたいな話をしました。僕が自分を納得させられる最大の理由がこれでした。

スライドづくりが難しい

難しい。

ツールの選定からはじめました。最初、原稿をmarkdownで書いていたのでそのままreveal.jsに流しこもうとしました。たしかに作成ツールとしては非常に便利ですが、やはりプレゼンツールとしての機能に富んでいるのはkeynoteだなと思い途中で変更。

また、昔、著作権のことを考えずに拾って来たアニメの画像をばんばんつかって登壇していたのですが「そういうのちょっと考えたほうがいいと思うよ」と言っていただいたことがあり、photoACとAdobeStockからCC0の素材のみをピックアップするみたいなことも気をつけました。あれがなかったら今だにあの調子だったんだとおもうとぞっとしますね。恥ずかしい。

また、30分セッションは「短い!」という人もいますが僕からすれば聞き手側の30分は長いです。人間の集中力が持つのは何分とかいいますが、話がおもしろくなければ5分のLTでも早く終われやと思ってしまいます。なので「最後まで聞いてもらえる」を目指しました。がんばったつもりですが、こちらの世界に引きずりこむようなトークを盛り込みすぎた結果あまりテクニカルな部分にコミットできてないというのが現実。。。これはあとでブログを出すという事をその場で言いましたし、なんなら最初に謝りました。。。

あとは縦長の会場でどうスライドをつくるか?色は?文字は読めないだろうから画像を出すか?みたいなことも試行錯誤しました。でも会場のセッティングがちゃんと設計されてたので若干杞憂だったかな。

次回に向けてのメモ

まわせPDCA

接続確認はちゃんとする

デモができなかったんですよ。動かなかったわけじゃありません。ミラーリングの仕方がわかりませんでした。お見苦しいところをお見せしたくなかったので即中止しました。だって手元で動かしても、聴衆の目線の先には

普段、もちろんディスプレイに投影して練習はしていたのですが、ディスプレイが見える位置にあったので、練習ではデュアルディスプレイでもデモができていたんですよ。それが、背後にスクリーン、明るさも部屋とは違う、カーソルが見えない、などなど完全に本番を想定できていませんでした。いやまじで痛い思いして学んだ。

あと、iPhoneから画像を転送しようとしたらめちゃくちゃAirdropできる端末でてきて自分のが検出されないとか笑

姿勢

友人が写真を撮ってくれていたので写真を見ると、まーえらそうというか、緊張感がないというか。普段一人練習だとちゃんと直立で手も目の前で軽く組むみたいなことができてたんですが、完全にテンションがあがって舞い上がってるんですよね。緊張感がない。場なれのしてなさですね、、、次回までに改善します。

発言

生意気な若者みたいで嫌だなと思いました。笑

すごく嬉しかった事

ここからいい話だから読んで。

スライドの中でも言ったのですが、僕がウェブ業界に入るきっかけになったブログがいくつかあって、その著者のデザイナーさんにたくさん会えた事です。

これね。

フリーランス Advent Calendar 2014 - Adventar

主催はspicagraph氏なんだけれど、会場では旦那さんにご挨拶しました。笑

たぶんこの人たちは、普通に企画だからブログを書いただけなんだけど、それを見て誰かが何かを思うわけで、誰かの人生変える可能性だってあるわけですよ。

だから、「私なんて何者でもないし」と何かを言おうとした口を閉じるのじゃなくて、「今こうです、こういう状況だから、これをしていて、こうなりました」をただ言っていただくことが今のあなたが出せる価値なんですよというメッセージを最後に投げたという感じでした。

22の時に最初に入社した会社の上司とうまくいかずに、売り言葉に買いことばで辞めるといってからこの先どうしよ〜と思っていた矢先にこれを見て、こういう生き方がいい!と思って業界を志したのでした。勉強好きだし性に合ってるという気持ちでいま二年なんとか生きてこれたよー、、

で、「ぜひ関西遊びにおいでよ!」といろんな人に声かけてもらえたので、なんかのイベントの際に遠征しよーと思ってるところです。でも、直近めぼしいイベントが特に何もない(笑)年内は忙しいので、来年が楽しみです。せっかく行くんだから、LTくらいはしたいしね。

イベントの感想

はじめての1000人規模のカンファレンスだったのですが、特にセッション班のスタッフチームの方には本当にお世話になりました。ハングアウトでリハーサルや当日の流れの相談までしていただけて本当にありがたかったです。

しかも、運良く聞きたいセッションはほとんど周れて(どうしても自分の裏のトラック聞けないのまじで残念でならないんですけど)会いたい人にもたくさん会えて満足です。懇親会も楽しかった。たくさん声かけてもらえたし、たくさん声かけた。アフターで参加者のひとたちと飲んで話して楽しかった。コントリビューターデイも行きたかった(泣)

次のイベント

次は技術書典3に向けて準備をすすめています。また、11月にはCSSNiteに登壇します。トラックあたりの規模は同じくらいですが、やはりOSSカンファレンスとは少し違った雰囲気もあり、より一層気を引き締めていかないとなという気持ちです。

トークで登壇の1回目のチャレンジの場を与えてくださったという意味でもWordCampには感謝しています。来年もスピーカーなりLTなりスタッフなり、何かしらの形で貢献できたらなと思っています。

参加者の皆さん本当にお疲れ様でした。ありがとうございました。

reveal.jsでスライドを作るときに更新するたびに最初のスライドに戻されない方法

WordCamp Tokyo 2017 | テーマ「Join 〜 つながる人・つながる世界・つながる未来 〜」2017年9月16日(土)-17(日) 開催 ベルサール新宿グランド 5F コンファレンスセンター

はじめてのカンファレンス、トーク採択で30分セッションをさせてもらうことになり、スライドを作っています。 30分スライドとしたら1枚30秒くらい喋るとしても60枚はスライドを作ることになり、デザインが大変。

ということで、普段はkeynoteを使っていたのですが、reveal.jsに乗り換えました。 hakimel/reveal.js: The HTML Presentation Framework

普段使い慣れてるCSSでインブラウザデザインができるので、WEBデザイナーであればkeynote使うよりも楽かもしれません。 CSS側をフレームワーク化すれば、レイアウトも画一化できるし。

cloneしてyarnして必要なものを揃えたら、yarn run startしてライブリローディングしながら編集作業を行うのですが、いちいちリロードのたびに最初のスライドに戻される。世の中の人は毎回こんなことしてんのか?嘘だろ?と思い、reveal.jsを使った形跡のあるリポジトリを見ていると、僕のファイルとの違いを発見。

    Reveal.initialize({
      history: true,
      dependencies: [{
          src: 'plugin/markdown/marked.js'
        },
        {
          src: 'plugin/markdown/markdown.js'
        },
        {
          src: 'plugin/notes/notes.js',
          async: true
        },
        {
          src: 'plugin/highlight/highlight.js',
          async: true,
          callback: function() {
            hljs.initHighlightingOnLoad();
          }
        }
      ]
    });

このhistory: true,を記述するのがキモでした。

reveal.jsは、1つのHTMLファイルに全スライドをDOM要素として生成したあとにJavaScriptで出し入れしてスライドっぽく見せています。 なので、リロードがかかると初期状態に戻る=最初のスライドに戻されるというわけです。

しかし、上記の記述をすることで、スライドごとに固有のURLが発行されます。 なので、リロードしてもそのスライドのURLが更新されるので、最初のページに戻されません。

SPAでも、実際はJSがレンダリングしてるだけだけれど、それぞれの状態にURLを発行している、みたいなことをしているので、同じ原理ですね。

もちろんドキュメントには

// Push each slide change to the browser history

と書いているのですが、個別URLの発行というワードに結び付けられていなかった自分がいたりして、勉強不足でした。 スライド作りも佳境に迫ったところでこれに気づいてしまったのでもっと早く知りたかった感はありますが、ブラッシュアップに役立てたいと思います。

あと、Configurationはちゃんと読みましょう。ぐぐって情報があつまらない理由のほとんどは「そこに書いてあるから」だったりします。

誰かの役にたてば幸いです。

builderscon tokyo 2017にスタッフとして参加しました

昔の人は言いました。 鉄は熱いうちに打て。ブログはエモいうちにしたためよ。 ブログを書くまでがカンファレンス。

buildersconを知ったきっかけ

興味を持ったきっかけは、@GeckoTangさんや@Takazudoさんのような、CSSに明るいエンジニアがCfPを出していることでした。Twitterで見かけてbuildersconを意識しはじめました。

ちなみに、2016年にも@kubosho_さんのCSSを破綻させないというCSSのセッションがあり、それは動画で見ました。

当時「テックカンファレンス」に抱いていた先入観

日本のテックカンファレンスは、サーバーサイドやアプリエンジニアが盛んにやっているイメージを持っていました。フロントエンド系のカンファレンスももちろん盛り上がっていますが、AngularやVueなどプロジェクトベースの開催が多いように思います。

ちなみに、私が普段描いているHTMLやCSSのような、プログラミング言語ではない言語をとりあげると、業務ベースで「設計」「効率化」という話が多いというのが現状かなと感じています。そのため、カンファレンスというよりは、セミナーという形が多いですね。

Rubykaigi, PHPカンファレンス, YAPC, iOSDCなどでTLが盛り上がっていると、楽しそうだなーとよく思います。

buildersconへの参加

最初は「CfP出そうかな」「せめてLTくらいなら」と思っていました。しかし、日程確保ができなかったというのと「そもそも、空気感がわからない」というのもあり、その足は踏み出せませんでした。

ですが、あの場に立てることが名誉なことくらいはわかっていました。なので、「参加のきっかけが欲しい」などと思っていたところ、「ボランティアスタッフを募集している」というツイートが目にとまりました。

意識していたから目についたのか、たまたまなのかはわかりませんが、我ながら「〜〜したいな」と思ったらチャンスがくるラッキーさには定評があるなと感じます。

当日

3daysの開催でしたが、仕事(副業のほう)の都合で日程が確保できず、最終日のみの参加でした。「あーいきたかったな」と思ってしまうので、ハッシュタグ見るのがつらかったです。

当日は、メイントラックのスタッフとして常駐していたため

のセッションを聞くことができました。

また、一部トラックを移動して

を聴きに行きました。

今日から使えるCSS Grid

Gridが使えることは、先日の一斉実装の件もあり知っていました。 ですが、やはりその方面に明るい方から聞くのは得るものが多いだろうというのと、「buildersconでCSSの話ってどんな感じなんだろう?」というのが気になって参加しました。

Twitterやトラックの様子を見ていると、専業のフロントエンド(マークアップ)エンジニアはそんなにいないという印象でした。別畑からキャッチアップしにきているのかな?という感じもありました。

buildersconは「知らなかった、を聞く」をテーマとした技術を愛する全てのギーク達のお祭りですというキャッチコピーの通りだと思いました。

専門外の分野の話を聞いて見るのは面白い

ここまで出来るmrubyThe Evolution of PHP at Slack HQは、PHPRubyも書かない私が聞いても発見がありました(追いつけない部分もありましたが)

一番の発見は「〜って、〜なんですよ」という発言に、わたしは「へぇ〜」と思うのに対し、おそらく普段からPHPRubyを描いてる人は「wwwww」のような「あるあるw」的な反応をしていたことでした。

専門でやってる人から見たら当たり前な話でも、専門外の人にとっては「知らなかった」「今学んだ」なんだなぁと思いました。 もっというならば、僕がここでUIデザインの話をしたとして、もしかしたら誰かの新たな発見に繋がるかもしれないということです。別分野の人に向けてトークすることを「アウェイ」ではないと思い始めました。

クロージングトークのエモ

refs. Closing

後からスライドや動画は公開されると思うので完結に。 (自分の解釈が多分に含まれます)

  • エンジニア35歳定年説みたいな話は、誰かが勝手に決めた限界値
  • でも、時間が有限であるというのは事実
  • じゃあ、今すぐアクションしたほうがいい
  • 今この話を聞いてる人が、今この瞬間にアクションにうつせることは「スピーカーと話す」「参加者と繋がる」
  • この先アクションできることは「登壇する側になる」「カンファレンスを作る側になる」
  • 技術者はスキルだけあればいいってもんじゃない
  • 自分の分野の外側と繋がるともっといいもの作れる
  • buildersconはそういうカンファレンスだ

ぶっちゃけ感動しました。エモです。

当初は、よくわからないからちょっと覗いてみようと思っていたレベルだったのが、積極的に技術トークをしていきたいという気持ちになっていました。

最後に

とにかく、刺激になるカンファレンスでした。深夜のエモがとまりません。

もっとやばいのは、今回は最終日にスタッフ参加だけという、ほんのひとつまみしか参加できていないというのに最高みを感じているところです。

次回は全日程参加する、CfPだす、もっといろんな人と喋る、自分の専門外のトークも耳を傾ける、スタッフとしてももっといいものを作る・・・いろんな思いがあります。もっと楽しめそうです。

このエントリは、buildersconを終えた夜に「エモ」駆動でbuildされたものです。 これが、今私にできるアクションでした。

皆さん、次回は一緒にbuilderscon行きましょう!

f:id:nayucolony:20170806045251j:plain

WP REST APIで投稿データから著者名をひっぱってくる

普通にやっても取ってこれるオブジェクトのなかにはいってない。雑にメモ。

やりかた

wp-json/wp/v2/posts

ではなく、次のURLにGETをなげる

wp-json/wp/v2/posts?_embed

すると、帰って来るオブジェクトに_embeddedプロパティが追加される。 _embedded.author[0].nameに、著者名が格納されている。

これがないと、author idからエンドポイントを生成して叩いてオブジェクト取得して、、、ってしないといけない(?)ので見つけられてよかった。

【process.env】node.jsでプロジェクトごとに環境変数を設定する

circleCIに環境変数を仕込んだものの、ローカルで動かせないじゃんってなった。 どうにかしてプロジェクトごとに環境変数を追加できないかなと思って調べているとdotenvというnodeモジュールに出会ったのでメモ

どうするの

プロジェクトルートに.envファイルをつくる

USER = nauycolony
PASSWORD = password

node.jsで使えるようにする

dotenvというnode_moduleをつかうのでインストールする。 yarnでも、npmでも、使ってる方でどうぞ。

yarn add dotenv
npm i dotenv

動かすスクリプトファイルで次のように記述。

require('dotend').config();

こうすることで、process.envというオブジェクトに.envの内容をぶちこんでくれる プロジェクト固有の変数を作れる。

使ってみる

普通にオブジェクトとして使えるので、ブラケット記法なりなんなりで参照する。

console.log(process.env.USER) // nayucolony
console.log(process.env.PASSWORD) // password

あとは、.envファイルをgitに含めずにアップすれば、認証につかうユーザー名とかパスワードなんかをリポジトリにあげずに認証を通したりできるということだ。 絶対に.envファイルをリポジトリにあげないように。

process.envってなに

環境変数をまとめて管理するオブジェクト。

中身を見たければ次のようにする。

console.log(process.env)

一例としては以下のようなオブジェクトがでてくる。

{
  SHELL: 'usr/local/bin/zdh',
  VISUAL: 'vim'
  .
  .
  .
}

通したPATHとか、色々とここに全部集約されている。 通常、マシン全体で使うものだが、dotenvをつかうとプロジェクト固有の数値も持たせることができる。

Parallelsで立ち上げたIEからrailsにアクセスする

こうするだけ

たちあげるときに次のようにする。

rails s -b 0.0.0.0

what

通常、Macでnode.jsなんかをつかってローカルサーバーを立ち上げてそこにアクセスする場合、http://localhost:8000のようにURLをうつ。

しかし、同じマシン内でParallelsを起動し、その中でIEを起動して動作チェックをする場合などは http://192.168.11.2:8000のように、ローカルIPアドレスを指定する必要がある。

この192.168.11.2の部分は各自ネットワーク環境によってことなる。 ifconfigで確認できる人はそうすればいいし、わかんなければシステム環境設定>ネットワークを確認すれば Wi-FiはXXXXXXXに接続していて、IPアドレス 192.168.11.2が設定されています。みたいにかいているはず。

しかし、Railsでサーバを立ち上げる場合、ローカルIPアドレスを指定してもアクセスできない。 Railslocalhostでしかアクセスできないのだが、ParallelsからはlocalhostMacにアクセスできない(windows自身を参照してしまう) (そもそもlocalhostの正体は127.0.0.1という「ループバックアドレス」であり、自分のマシン自身だ。自分のPCをサーバーとして動かしているところに、自分のPCからアクセスするという自作自演をしている。)

よって、localhostではない、別のIPアドレスでアクセスできるようにしてやる必要がある。 そこで-bオプションを使う。 bindすなわち束縛の意味で、引数として渡したIPアドレスに結びつけてアクセスできるようにできる。

そこで、0.0.0.0というアドレスを使う。 0.0.0.0localhostのように自分自身を表すが、ループバックではなく、外部からもアクセスできる自分自身である。

mac0.0.0.0Railsアプリを公開している状態になるので、そのネットワークに繋いでいる人は0.0.0.0でアクセスできる。 これは、Parallelsも例外ではない。

よって、

rails s -b 0.0.0.0

としてサーバを起動し

http://0.0.0.0:8000/

のように任意のポート番号を指定することで、アクセスが可能になる。

レスポンシブのサイト制作で、必要なカンプは?

結論はないですが最後にいちコーダーとしての個人的なわがままがあります。

事の発端

この発言。TLで「モバイルファーストでCSS書く」みたいな話を見かけて、そういえばないなあっていう思いから漏れ出たツイーツでした。

注意事項

まず、ツイッターで意見を募る系の世論調査、業界全体でみると「意識高い人(NOTただ意識高い系の人)」が意見をくださる場合が多いです。 なので、わりと「アンテナはってる」層の意見が多いパターンが多く、一般世論とは乖離している可能性が高いことをご留意ください。

また、「モバイル/SP」のような表現をしますが「小さい画面」という意味で言っており、特定のデバイスをさしているわけではないのでご了承ください。

あと、私は元デザイナーでありコーダーですが、互いの職域に対する文句やdisではありません。 いただいた意見を元にした現状の解釈と、個人的な意見です。

ツイートに対する反応

この辺は、僕のツイートが「つらみのぼやき」に見えてしまったのか、デザイナーの「そんなことないよ」という反応とコーダーの「だよなー」という反応が多くを占めました。

デザイナーの反応

  • まじで?そんなパターンあるの?
  • PCとSPを想定してつくる
  • 大中小の画面パターン用意する
  • 実装者が社内のウェブデザイナーとかならコミュニケーションで回す

etc.

コーダーの反応

  • あるある
  • やっぱどこもそんな感じなんだな
  • 「よしなに」の指示が来ることが多い。工数増えるっていう話をすると辞退される
  • 完全なカンプは予算によっては存在するが、ディレクターが手書きワイヤーフレームで指示くれてコーダーが実装する
  • 元デザイナーなのである程度汲み取る
  • SPはトップだけくる

etc.

デザインカンプの持つ側面

たくさんの意見をいただいて、次のような側面が存在することに気づきました。

  • デザインカンプは、次工程への指示書である
  • デザインカンプは、前工程への報告書である

前者はコーダーに渡すカンプとして、後者はクライアントに見せるカンプとしてという意味合いです。

コーダーは「別バージョンのカンプ」が欲しいのか

そもそも、欲しいのか、欲しくないのか、ということから考えました。 結論からいうと、場合によるよね、とはなるのですが(笑)

前職では、クライアントの性質上「PCからの流入が圧倒的」であり、「小さい画面」については存在さえしていればいい、本当によしなにやってくれればいい、という感じでした。 しかし、「じゃあ適当にやっときますわ」というわけにもいかないのが現実でした。

なぜなら、「PC向けのデザインが本当にPCの画面いっぱいを使って表現するようなデザイン」であり、段組を変えてレイアウトを変更すればいいという話ではすまなかったからでした。

webコミックの話

具体的なサイト名を出せないので、下手くそなたとえ話をします。

例えば、スマートフォンでマンガを読む場合は、見開きではなく1ぺージずつスワイプを行なって読むことが多いですよね。もしくは、縦スクロール。 その際「見開きをぶち抜いて表現しているページ」が本来作者の意図した見せ方ができなくなりますよね。

もう、web連載なんかでは縦スクロールを前提としたコマ割りを行われているケースが多いですが、もし紙の本にむけて書いたものをその形式で出してしまうとほんとうに悲惨なことになります。 (その場合、そのコマにさしかかたときだけ横にスクロールするマンガもありますが)

・・・とまあ、話がそれましたが、その辺に近いものがありました。

そのため、「まあよしなにやってくれや」というオーダーがきた場合、かなり無理があるので、狭い画面向けのデザインの再構築をお願いしたいという気持ちがあるというのが当時の状況でした。

デザイナーは「別バージョンのカンプ」を作りたいのか

まず、多かった意見が「クライアントのビジュアルチェックがあるので絶対に必要になる」というパターンでした。これは私もやっていました。

特にコンペとかだと、おそらく100%のデザインを出すんでしょうし、それがそのままコーダーに渡って来る可能性が高いです。 レギュレーションとかもありますし、前職ではプレスチェックのために完璧なデザインを提出していました。

そのフェーズで「クライアントのビジュアル的要求」と「文書構造の一貫性」を両立することが困難になるケースも多くて、カンプのデザイン以外は「誰も知らない中間の姿」となってしまうこともありました。 当時はとにかくデザインのOKをもらうことを優先していたため、いつも、そこの調整を闇雲に行っては消耗していました。

その辺を確実に実装させるための戦略として、別バージョンのカンプを用意すると言う意見もありました。 それだけの予算をとる説得ができるかどうかは、もう一つ上の工程に掛かっているのかとはおもいますが、納期と予算の都合で難しいケースもあるとのことです。

コーポレートデザイン的な部分も含めてサイトを作ることのウェイトが高い場合は、そういう予算も惜しまずだしてもらえるのでしょうか。

ワイヤーフレームをしっかり決めることが大切

たじまさん(@DesignHumore) という、ブランディング戦略から現場のデザイナーまでを担当されている方がいて、その方の意見がすごく参考になりました。

複数ツイートに渡っての会話だったので、要約すると以下のような形になります。

  • ワイヤーの時点で仕様を徹底的に詰める。必要な要素に抜け漏れがないかの確認が目的。
  • デザイン(ビジュアル的な話)はイメージボードを使って方向性を決める
  • 「とはいえ実物見ないとわからない」場合も当然あるが、その場合は30%くらいの力でデザインしてイメージを見せる。
    • コーダーへの指示書ではなく、お客さんへのイメージ共有なので、最適レベルで見せるという意味だと思う。
  • デザイナーとしては、装飾の変更は言うほどつらくない。情報構造の変化は、大変。

デザイナーはデザインツール上で完結することはテクニックで完了させられますが、インフォメーションアーキテクト的な話は、そこだけでは完結させられないのでクライアントを巻き込んだ手戻りが発生しがちです。

実装でもそうで、CSSの書き換えはSassなんかを駆使すればけっこう簡単に終わらせられます。 しかし、情報構造が変わると、HTMLも含め考慮することが増えがちです。サーバサイドと連携している場合はなおのことです。

たじまさんは「その手戻り・修正にかかる費用と時間はお客さんのものだから勝手に資源にしてはならない」とも仰っていました。

作業の大変さとかしか考えてなかったので感心しました。

文書構造の変更は大変だが、あしらいの調整はそうでもない

たじまさんの話をうけて、下手くそなたとえ話をします。

家を建てる過程で、もう色々な作業が動いているときに「すみません!忘れてたんですけど、2Fにもトイレが必要なんでした!このスペースに置いてくれればいいんで!」みたいな話をされた時の話です(なんだそれ)。

  • 「いやいや、スペースはあるけど、このスペースは居住者の使いやすさをいろんな面から考慮してデザインしてまして・・・」
  • 「水道管の整備、電源の確保、換気ダクトの設置、収納、あらゆる要素を改めて考慮するので、一旦全作業をストップしてもらって、もう一度打ち合わせが必要です」
  • 「モノがありません、完了予定日は決まっています、無理です」

みたいな問題が生まれると思うのですが、コーディングもなんか、似たようなことが起こります。 なるべく文書構造のぶっこわしは発生してほしくないと思っています。

しかし、「すみません、外装なんですが、やっぱりクライアントのイメージと少し違っていて、もう少し濃い茶色のモノに変更してください!」という場合。

  • 「塗装業者をもう一回呼びましょう。最悪、材変えましょう。お金はかかりますが、いけますよ」
  • 「壁紙剥がして張り替えですかねー、内装業者のスケジュールにもよりますが、無理はないですよ、そのぶんお金はかかりますけど」
  • 「この色は、全体の調和を考えてデザインしていて、他の部分もトーンを変えないと変な感じになっちゃいそうですが、本当に必要ですか?」

みたいな、割とお金で解決できるフェーズじゃないかとおもいます。 この辺は、CSSを書くときにだいたい想定しているので、割と変更は楽です。

web制作の現場、家とかに例えると「なんだそれ」ってなりますが、結構頻繁にこういう事が起こっているのを考えるとおかしな部分がありますね。 リアルの物体じゃないという性質上、修正が簡単なのは、わからなくもないんですが。

私なりのわがまま

最後に、個人的な意見です。

大きな画面でないと表現できないようなデザインならば、画面が小さくなった時のデザインも欲しい

例えば、横長のヒーローイメージをドカンと置いているような場合、「よしなに」と指示をすると「画面幅に合わせて縦横比を合わせて縮小」されて、すごくダイナミックな表現だったはずのものがすごくみすぼらしくなったりします。 デザイナーとしては「私はこんなの認めないぞ!これはこれに向けたデザインをしなおす!」という気持ちになるのではないでしょうか? その辺りを放棄されると実装側は萎えるということもあり、お互いいい仕事をするためにも、ビジュアルの共有をしてほしいです。

レイアウトの変更だけでいけるようなサイトならば、ワイヤーレベルの指示書が欲しい

複数のカラムで構成されていて、1カラムに並べ替えるとか、1カラムを表示させないとか、そういう操作だけで行けるような場合はカンプはそこまで重要ではないかなとおもいます。 逆に、ケツの姿が決まってしまっていて、クライアントにも「これでいきます!」と固めてしまうと、中間の処理なども含めて無理が発生することが多いです。

・・・まあ、クライアントのチェックが入る以上、必要なものは必要なので、仕方ないのですが。

ただ、要素の増減が発生する場合、何を削ったらいいのかとかは実装者の独断では決められないので、指示書レベルで欲しいという気持ちがあります。 手書きワイヤーでもいいです。デザインも、デザインをかじったレベルでいいのならばまかせてくれという感じです。

結局、コミュニケーション

中間成果物がなくても、コミュニケーションで巻き取れる部分はかなりあると思っています。

  • 「ふってきたデザインがこれで」
  • 「ふってきたオーダーがこれで」

という風に何か超常現象のように捉えてしまいがちですが(いや、あいつぶっ殺すという人もいるとは思いますよ)、やはり決めてるのは人なのでコミュニケーションを大事にしたいですね。

そのコミュニケーションのためのベースとして、実装者はデザインに対する理解を深めておきたいし、デザイナーは実装に対する理解を深めていけるといいなと思っています。

最後に

元も子もないような感じではありますが・・・

「手戻りが発生することも含めて、お金で解決するのがプロフェッショナル」

ということもあるということを忘れてはならないと思います。

とはいえ、湯水のようにお金を使う事がプロフェッショナルかというと、そうではないということも合わせて肝に命じておきたいですね。

最後まで読んでいただきありがとうございました。