変幻自在なWeb制作ワークフローの達人・こもりまさあきさん

連載

Webデザインの新しい参考書【達人に学ぼう】

こんにちは！ Webデザイナーのくれまです。

Webデザインには、幅広いスキルが必要です。成果の出るWebサイトをデザインするには、むやみに価値観を固定せず、自分とは異なるスタイルで仕事する人からも常に学ぶことが大切、と考えています。

この連載では、『ふところがより深いWebデザイナーになるためのヒント』をテーマに、くれまとさくらが選びぬいた話題をお届けします。

第3回は「カンプはいまどきのWebデザインに必要なのか」を考える

くれま：

さくらさん。私、この2017年という年に、自分の仕事スタイルが今のままでいいのか、ものすごーーく悩んでるんですよね。

さくら：

え、またですか？ くれまさんって、いつも悩みがちですよね……。まぁ、悩むからこそ成長する余地もあるのかも、って思いますけど（笑）。何について悩んでいるんですか？

くれま：

私、2017年でも、PhotoshopやIllustratorを使って「静的なカンプ」を作る案件が多いんですけど、案件によっては違うワークフローも取り入れたいと模索していて。

さくら：

それは、私もありますね。でも、まだ、どうやって着手していけばいいのか、見えていないという焦りがあります……。

くれま：

スマートフォンが生活の中に定着する頃から言われ続けていることなんですが、Webサイトを閲覧できる端末が多様化しすぎているわけじゃないですか。

さくら：

そうですね。いまさら感は強いんですけど……。

くれま：

そう。いまさら、2017年にそんなことで悩むなんて、遅すぎると思うんですけど。「固定サイズのカンプを制作するだけでは、最終成果物を表現しきれない」という場面もまだまだあるわけで、そこをきっちりさっくり解決しないと！って気合いを入れてるんです！！

さくら：

わ、分かりました。ちょっと、あんまりテーブルに身を乗り出さないで……（笑）。そういうお話でしたら、第1回と第2回は私が達人をご紹介したので、今度はくれまさんが達人を紹介してくださいよー。

くれま：

ですよね！ そう思って、フロントエンドエンジニアを中心にWeb業界で幅広い人気を誇る、こもりまさあきさんにお約束を取り付けておいたので、早速お話を聴きに行きましょう！

今回の「達人」はこんな人！ こもりさんのキャリアを解剖

こちらが、こもりまさあきさん。

HTML5 Conference、WPJ Conferenceをはじめ、様々なカンファレンスやセミナーでの登壇と共に、書籍執筆なども精力的にこなしていらっしゃるので、ご存じの方も多いのではないでしょうか。

しかし、はじめての方にも優しいのが、この連載。まずは、こもりさんがどんな経歴の方なのか、拝見していきましょう。

こもりさんは、こんな人

東京をベースに、旺盛に地方遠征もする、45歳。

日本におけるインターネット初期から活動スタート

1990年代前半の、日本にプロバイダが数社しかない時代から、副業でコーディングの仕事を開始。本業でネットワークの仕事をしていたこともあり、他の人よりかなり先にWebの世界に関わりはじめることになる。

転職するつもりがフリーランスに

印刷関係の会社にてネットワークの仕事をメインにしていたが、Web制作会社に転職したいと考え、2000年ごろに退職。ところが、夜な夜なチャットする「アングラ」な仲間から、すぐに「フリーでやらない？」と誘われ、以降ずっとフリーランスとして活動することに。当時は、（ある程度社会的地位があり）金銭的な余裕がある人でないとインターネットを利用しにくい世情だったこともあり、フィルタリングされた人たちの中で仕事を紹介しあう雰囲気があった。

外資系レコード会社の仕事を開始

その頃のチャット仲間から紹介してもらったのが、外資系レコード会社の「BMG JAPAN（のちにソニーミュージックと合併）」の仕事。会社を辞めてしばらくは、BMGの仕事に専念していた。ミュージシャンのライブで写真撮影をし、フライヤーもサイトも作る、というように、自分だけで完結するようなかたちで仕事をしていた。

コンサルティング的な業務も自然発生

印刷とネットワークに関する知識、写真撮影のスキル等々も活かし、BMG JAPAN内の複数レーベルのWebサイトに関することを、まるごと任せてもらっていた、こもりさん。最先端のインターネット関連知識も活かし、次の一手をどう打つか、企業内部の方々に助言するように。制作会社よりもフットワークの軽いフリーランスだったということもあって仕事をもらいやすく、別会社と合併するまで5〜6年間任せてもらっていた。

徐々に広がる取引先

こもりさんは、基本的に自分から営業しないスタイル。知人からの紹介が連続し、芸能事務所やエンターテイメント系、ファッション系の仕事などに関わるように。大きな案件の合間合間で、小規模なコーポレートサイトなどの制作にも関わっていた。

覆面ライターから実名の著者へ

制作の仕事と平行し、26歳頃から「アングラ的な」書籍にて名前を出さずに執筆を始めていた、こもりさん。30歳頃、今のひらがなのペンネームに変え、Webサイト制作に関することをきちんと書き始めた。専業のテクニカルライターが不得手とする「活きたサンプルデザインが入った書籍」が書ける人が出版社から求められ、本格的に執筆に着手。

電子書籍の自費出版も手がける

意義のある企画でも、売上の見込みがないと作れないのが、出版社。しかし、「いま書いておくべき」という企画が自身の中にあるとき、自費出版で電子書籍を出すことも。電子書籍が売れたら、売上を見つつ改めて紙の書籍にする、という仕事の作り方も実践している。40歳を超えてからは若い人に機会を提供するべく、最初の企画を出したり、監修で入ることが多くなってきた。

経歴を伺っているだけでも非常に興味深く、これだけで記事が1本書けてしまいそうですが、それはまたの機会にゆずるとして、そろそろ本題に入っていきましょうか。では、こもりさんの辛口トークを、お楽しみください。

そもそも、カンプ作成って意味があるの？

さくら：

そもそもの話として、こもりさんは「カンプ」という言葉について、どう思われますか？ 印刷のカンプと、Webのカンプって意味合いが違うじゃないですか。その上、Web業界では「オワコン」になりつつありますし。「カンプ」って一体何なんだろうなぁ、と思っているんです。

こもり：

「カンプ」って何なんですかね。思えば、紙って楽だったなと思うんですよね。だって、デザインデータと最終成果物との違いが無いわけですから。データと成果物の違いが無いからこそ、WISYWIG的なDTPが発展してきたわけですし。

でも、Webの場合はそもそも、デザインデータと最終成果物が違うじゃないですか。だからWebの「カンプ」って意味がないかな、とは思います。

くれま：

そうなんですよね、最終成果物が「変化するもの」というか。

こもり：

そう。Webって画面幅が変わるものですし。一昔前のテーブルレイアウトは画面幅が変わるものをテーブルで無理やり固定していたわけで。今もそれは脈々と受け継がれていて、横幅何ピクセルにするの？とか。いやそういう話じゃないよねっていうところはあるので、カンプ要るの？って言われたら、要らなくね？という。ワイヤーでいいんじゃない？って思います。

くれま：

なるほど、ワイヤーだけかぁ……。カンプを作らないと、クライアントの了承をとるのが大変じゃないですか？

こもり：

「作ってみないと分からない」というのは常について回りますが「誰」に「どう」分かってもらって意識を共有するか、ということを考えながら、相手によってツールを使い分けるようにしていますね。

くれま：

きっちり作り込んだカンプって見栄えがいいから一見分かりやすくて良さそうに見えますが、様々なデバイスサイズに対応しなきゃいけないケースではかえって分かりにくいのかも……。

さくら：

カンプと手元の機種での見た目が違う！というのは「分かりやすく」は無いですもんね。

こもり：

だからカンプってイマドキではないんですよねぇ（笑）

こもり：

もう一つ考えておきたいのは、いわゆる「Webサイト」を作るのか、「Webサービス」を作るのかでも、カンプの必要性は変わってくるよ、ということですね。

くれま：

確かに、「読ませるのがメインのサイト」と「ツールとして使うサイト」では、開発フローが違いますよね。

こもり：

ユーザーが「使う」前提の「Webサービス系」の場合だと、バックエンドのエンジニアと一緒にやらなきゃいけないから、全体的なイメージの共有のための絵作りはあっても最終的にこうなりますというカンプ作成はほぼ無いですよね。一般的ないわゆる「コーポレートサイト」などを作る時は、半々に近いかな……。お客さんによるんですよね。まったく作らない時もありますし。

さくら：

一概には言いにくいんですね。

こもり：

そう。あと、さっき言った「お客さんによる」というのは、組織形態によるんですが、「人数が多いから」「少ないから」じゃないんですよね。関わっている人がどうこうというのものもなくて……。一概には言えないです。

くれま：

固まった絵がなくても、できあがりを想像できる感性を持っている人が決裁権を持っていれば、オッケーな感じだったりします？

こもり：

どうなんですかね？ 「うまいことをやってよ」って任せてくれる人の場合には、固まった絵はいらないかもしれないですね。「もう任せた。あとは良きに計らってくれるだろう」みたいに進められるところであれば、あまり必要はないかなと思います。

さくら：

なるほど。

こもり：

まぁ、でも、きちんとカンプを作って関係各所と打ち合わせしなくちゃいけない、となった時には、作る場合もあります。

ただ、これは声を大にして言いたいんですけど、打ち合わせをパソコンの画面だけでやるっていうのがそもそもアホな行為だと思うんですよね。

くれま：

ほう。

こもり：

だって、実際の利用者はスマホユーザーが半分以上いたりする業界も多いですよね。そういうリアルなユーザーの現場ではなくて、自分たちの打ち合わせのためにパソコンの画面で見ているだけなのは、間違いじゃないかなと。

くれま：

ユーザーの閲覧端末に近いもので、ちゃんとチェックしたほうがいいと。

こもり：

したほうがいいですよね。カンプを作る作らないで言ったら、デバイスの画面の幅で変わるわけじゃないですか。変わるのにカンプ作るのってアホくさくない？っていう。

「パソコンの画面で打ち合わせをしなきゃいけない」っていう前提があって、関係各所が沢山関わっている場合は、紙やPDFの方が都合がいいこともあるのかなぁ、とは思いますね。

さくら：

クライアントと対面で打ち合わせをする場合なら、手元のスマホやタブレットでワイヤーを検討できると思うんですが、「オンラインでちょっと見て欲しい」というときなどは、どういう風に進めてます？

こもり：

僕は地方の仕事もしているんですけど、相手と会わないで見せる時は、グラフィックエディタ上で動かしているところをチャットなどの画面共有で見てもらう、ということもあります。コレがここに入ってコレはこうで、って、目の前でやった方が早く終わるじゃないですか。

くれま：

クライアントによっては「最初からカンプを作ってくれ！」というご要望もあると思うんですが、こもりさんはどうされているんですか？ お断りするのか？ 従うのか？ 意識を変えるよう、アドバイスなさるのか。

こもり：

その時の「自分の（そのプロジェクトとの）関わり方」によります。自分がどこかの会社の下にいる場合と、どこかの会社と並列にいる場合がありますよね。

さくら：

ありますね。

こもり：

並列の場合は、「意識を変えるようアドバイス」するかもしれません。並列じゃなくて、自分が下にいる場合は、黙っています。打ち合わせの場にいても、しょうがねぇなって言って、カンプを作ります。

さくら：

なるほど（笑）。私は下にいる場合もあるので、ちょっと安心しました。

こもり：

でも、上に立っている会社の人にもよりますよ。その会社の人がクライアントに言ってくれる、あるいはクライアントが理解してくれる雰囲気だったら、提案します。人によっては、クライアントに「今はカンプをきっちり作る時代じゃないっすよ」って言ってくれるので。

ただ、「クライアントと会社」、「会社と自分」、の関係性で仕事が成り立ってるところもあるので、そこの関係はあんまり壊さないようにはしますかね。

さくら：

ちょっと安心しました（笑）。「カンプは全部オワコン！」って言われるかなと思っていたので。

こもり：

気持ちは、オワコンですけどね（笑）

ここがポイント

実際に本番に近いものを見せたほうが早い、という制作手法

くれま：

少しお話を変えますね。カンプを作らずにブラウザ内で直接確認しながらCSSをしていしていく、いわゆる「インブラウザデザイン」という手法があって、こもりさんも取り入れていらっしゃると思います。どんな場面で使っているのでしょうか？

こもり：

インブラウザは、「お客さんと直でコミュニケーションをするのに見せた方が早い」という時に使います。コンテンツをいれたものをざっくり作って、デバイスごとにこんな風に見え方が変わる、というのを見せた方が意思決定も早い、という場合ですね。

くれま：

インブラウザで作業を進めるとして、並行して「見た目」、つまり、装飾やカラーリングを詰める作業が出てくると思うんですが、こもりさんはそういった「上に乗っける部分」に関しては、どうされていますか？

こもり：

上に乗っける部分は、一番最後ですかね。並行して、ではないですね。

デバイスがいっぱい増えてきたおかげで、昔みたいに「装飾をゴリゴリ作りこむ」ようなことがないじゃないですか。写真が背面に敷いてある、というのはあるかもしれないですが、昔みたいに、「ボタンがつやつやキラキラしてる」ようなのって減ってきてますよね。

フラットデザインが浸透したのだって、閲覧端末の多様化が理由だと思いますし。そうなってくると、フィニッシュの段階でもそんなにやることってないですよね。なので、一番最後にやることが多いですね。

くれま：

確かに、私の場合でも、そういうケースが非常に増えているとは、思ってます。

こもり：

「早く画面を見せて」って、よく言われますけどね。「画面って言っても洋服みたいなもんだから、一番最後でいいよねぇ」って返してますが。

くれま：

そこをいかに説得できるか、っていうのがキモですよね。

こもり：

途中まで、なんとなくのスタイルシートはあてておきますよ。

さくら：

それは、あとで変わるという前提で？

こもり：

そうですね。

さくら：

お客さんからすると、「ここからどう進化していくのかというのがわからない」ところもあるので、そこをコミュニケーションで補ってあげなきゃいけないですよね。私は、そこがインブラウザの難しいところだな、と思っていて……。

こもり：

そうですね、なかなか難しいとは思います。簡単なスタイルシートはあてていますが、コンテンツがわかって簡単に使える程度のものなので、実際のフォントサイズや種類も違ったりするし。

「どこの段階で見せるか」というのもありますよね。ちゃんと作った上で見せた方がいい時もあるので。受け手のお客さんが「これで最後なのかな？」という風に考えちゃう場合もあるので、お客さん次第で提出のタイミングを変えることもあります。

さくら：

なるほど、インブラウザにはそういったデメリットもあるんですね。確かに、依頼する側からすると、「早く完成品が見たい」という気持ちは理解できるので、完成形を想像しにくいインブラウザが良いとは一概には言えないですよね。

くれま：

こもりさんはプロトタイプツールについてはどう思われますか？

こもり：

インブラウザだけでなくプロトタイプツールも使ってますよ。静的な最終形態をイメージしただけのカンプの最大の弱点は「動かない」ことですからね。

お客さんが「ココを押したらどうなるのか」「どのページに飛ぶのか」がイメージできないので、それを元に作ってみたはいいけど「なんか思ってたのと違う」が起きてしまう。

最終形に近いイメージの共有とカンプが抱える問題を解消できるだけでなく、直接コメントなどでコミュニケーションも取れるものが多いので、プロトタイプツールは良いと思います。

くれま：

私も、案件によってはプロトタイプツールを使っていこうと思い、様子をうかがっています（笑）

こもり：

お客様に合わせた適切な方法を提案してあげることが重要ですね。その方法の見極めと、「最初の段階でどう説明するか」ですよね。
「カンプを作って、見せてもらえるんですか？」と聞かれたら「今時そういうのをやってたら、幅が変わった時とかスマホで見た時とか、わからないじゃないですか」という話から進めていくという手もありますし。

さくら：

多くの場合、向こうは「プロとしての意見を求めている」わけですから、言われた通りそのままやるというのは違いますもんね。

こもり：

お客さんがある程度何かパーツを用意していたり、やりたいことを想定しているのであれば、カンプから入らないで、いきなりスマホの画面にして作業をやってあげるといいと思いますね。その辺は、本当に人によりますよね。難しいですよ

ここがポイント

実装が「ラク」な方をチョイスし、開発速度を上げていく

さくら：

簡単なインタラクションを伴うWebデザインの場合は、どのように指定されますか？

こもり：

一番わかりやすい例はメニューだと思います。メニューの動きは、実装してマウスを乗っけてみないと動きがわからない。そこはインブラウザでやることが多いですね。

僕はインタラクションに強いプロトタイピングツールで何か作り込むぐらいだったら、ものによっては直接実装した方が早い。複雑なものだったら違う方法をとりますが、よくある「こうしたらアコーディオンが開く」くらいだったら、ちゃちゃっと作ります。

さくら：

画面を設計する人全員がコードを書けるのが理想ではありますが、「コードを書くのが苦手なデザイナー」は、たとえばインタラクションを再現できるプロトタイプツールを使ってもよい思いますか？私自身がコードに苦手意識があって、汚いコードを書くのも、プロトタイプツールで（動きを）作り込むのもどうなのかなって思っちゃうんです……。

こもり：

それは良いんではないでしょうか。

僕がなぜ直接書いた方が早いとかいうかというと、プロトタイプツールの中にはCSSを含めたコードの書き出しができないもの、JavaScriptになってはいるけど使い回しができないものなどがあるからなんですよね。

今後プロトタイプツールに求めたいのは、JSONなどで取り出したリアルのデータを使いたいこと、あとはアセットやコードの書き出し機能ですね。

さくら：

なるほど、そういった理由がおありなんですね。

くれま：

その二点が搭載されてくると、プロトタイプツールを使ったワークフローが、本当にスムースになりますよね。

さくら：

今後に期待ですよね！ ところで、こもりさんは、世間の流れ的に「脱jQuery」は意識していますか？

こもり：

そこは、あんまり気にしてません。ゼロから書くぐらいだったら、ライブラリなりなんなりを使った方が、ラクだよねと思っているので。僕は、実装がラクな方をチョイスします。

くれま：

全体的に「ラクな方」を選ぶんですね（笑）。

さくら：

だから、合理的な方に集約されていくんでしょうね。ラクするために、きちんと勉強なさるのがポイントですね。

こもり：

ラクをするというのも、もちろんありますが。たとえばWebサービスの制作では、フロントエンドだけの話じゃなくなってしまいます。デザイナーとエンジニアの仕事が別れていて、デザイナーが作ったものをエンジニアがきっちり実装しようと動いてくれるパターンもありますし。両者が話をしながら、これはいけるのか、ダメなのか、と話しながら作っていくパターンもありますよね。

そんな中、自前ですべてやらなきゃ、自分でコードをイチから書かなきゃ、というのはまったくないですね。車輪の再発明とかしたくないです（笑）。

さくら：

車輪の再発明……。時間とられますよね。

こもり：

インブラウザでワイヤーを作るにしても、フレームワークを使った方が楽なんですよね。でも、フレームワークでも案件に対しての向き不向きはあるので。たとえば、良くできたフレームワークを使えばいいかというと、ひょっとしたらグリッドレイアウトと、フォントサイズ、ボタンくらいが指定されているようなフレームワークを使う方がいいかもしれない。その時々必要なことによって使い分けてます。

さくら：

それぞれの特徴を知っていないと、できないことですね。

こもり：

とにかく、あんまりごりごり作らなくなりましたね。昔と比べて、あっさりしたデザインが好まれているというのもあると思うんですよね。

ここがポイント

知識のインプット、どうしてるんですか？

くれま：

こもりさんは、海外のニュースや情報を定期的に取得して日本に紹介しているというイメージがあるのですが。クライアントに最適なソリューションを提供するために、常にインプットをしているという。

こもり：

いやぁ、少ないっすよ（笑）。サイトでいうと、4サイトぐらいを定期的に見てるくらいですね。クリップボード的な「情報を集めてくれるサイト」を移動の間に見てる、とかはありますが。

くれま：

ナイショかもしれないんですが、いつも見ているサイトを教えていただいても良いですか？

こもり：

いいですよ。Designer Newsは、フロントエンドやビジュアルデザイン、UI、UXの情報が多いサイトです。時差の関係で、アメリカの夜にあがってきた記事が、日本の朝の時間帯に読めます。

Front-End Frontは、JavaScriptやCSSなどコード系の情報が多いですね。

Echo JSは、JavaScriptのサイトです。JavaScript周りで情報を見ておこうかなという時には、見ています。

Product Huntは、Web周りのツールやサービスのチェック用です。UIのヒントにもなります。

くれま：

ありがとうございます。読者の皆さんにも、とても参考になるかと。

こもり：

FlipboardでもPocketでも、要は「自分用に情報を最適化」できるかじゃないですかね。タグをいれておけば、情報を集めてくれたり。どうやってデザインしてるんだとか、そういうのを見ておけばいいと思います。

一人で仕事することも多いですけど、何人かで仕事をすることもあって、スタイルガイドを作ったりするような仕事をすることも多いんですよね。なので、たとえばスタイルガイドを紹介している記事などをチェックして、世の中の人たちはどうやってるのかな？というのを知っておくのは、おすすめです。

さくら：

ところで、英語圏のトレンドが日本に入ってくるのは、遅いとお感じになりますか？

こもり：

5年後ぐらいのイメージですね。早くても2年後とかですかね。今日話しているようなワークフローに関しても、日本は2〜3年以上遅れていると思うんですよね。

そういうワークフローが日本で浸透しない理由って何だろうと考えると、ひとつの答えは、「パソコンの画面ベースで打ち合わせをしているから」だよな、と思ってます。さっきも話しましたが。

制作者側が変わろうと思っても、体制が変われないわけですよ。啓蒙していかないと。

制作者から、「いま世の中はこうなってるんですよ」って言わないといけないんですが、なかなか言える人たちばかりではないですし、組織の仕組みを変えられる立場の人ばかりでもないので、そういう意味では色々難しいのかなぁとは思いますよね。

必ずしも、「海外のワークフローがいい！」という訳ではないんですけれど、海の向こうの彼らは彼らで、試行錯誤しているんですよね。「こういうやり方を考えたんだけど！」「こっちの方がよくねぇか？」というやりとりは活発です。日本みたいに、「誰かがこう言ったからこうだ」じゃなくって。

くれま：

それって、Web業界だけじゃなくて、「日本の全体の文化」みたいなものな気がしますね。

こもり：

文化ですね。セミナーとかで話しても言われるんですよ。「うちの会社じゃ、そのワークフローは適用できなくて」と。

僕としては「いや、適用できなくてじゃなくて、適用しようとしてないだけだから」って思うんですよ。なんにしても、すぐに全部を真似できるっていうのは、まずないじゃないですか。

なので、ある「良い事例」を知った時に、「じゃあ、ちょっとでも自分で適用できる部分ってどこなんだろう」って考えて欲しい。小さいところからでも良いと思うんですよね。

くれま：

取捨選択して、できるところから取り入れて欲しいですよね。

こもり：

みんなの同意を得られそうなところから「ちまっ」と変えていくことが、本当は必要なんじゃないかなと思います。

おわりに

くれま：

では最後に、「旧来のワークフローで悩んでる人たち」へのメッセージをお願いできますか。

こもり：

「やるしかない」んですよ。

「Webサイトを作る」こと自体は簡単ですが、「自分の属する環境を変える」のが難しいんです。新しいものには必ず抵抗があるので。ただ、変えようとしない限りは何も変わらないですから、ダメ元でも変える努力をすべきですね。

プロジェクトに関して、「今までと違う進め方をした場合、どう違うか？」というテストをしてみるのもいいのではないでしょうか。トータルでかかる時間を計測してみるとか。

時間は「コスト」ですし、「人が何人動いた」というのもあるでしょうから、そういう数字で上を説得するというのも一つの方法です。

提案時に、クライアントの目の前でスマホの画面しか出さない、とか、URLしか送らないとか、そういうところから試してみるのもいいと思います。

変えられない人たちが悩んでいるのって、周りを変えられないからなんですよね。自分は、もう変われるんですよ。

くれま：

「周囲の説得方法」を勉強した方がいいかもしれませんね。

こもり：

そうですね。これは某社のセミナーで作ってた資料なんですけど。見てもらえますか？

「ルールは大事、だが固執は終わりの始まり」

くれま：

まさに、まとめにふさわしい言葉ですね。

こもり：

「決まったルールを変えられない」と思っている人が多いんですけれど、ルールって破るためにあるわけです。時代に合わないルールなんて、変えちまった方がいいよねぇという。古いルールに縛られたために、デジタル化が遅れて潰れてしまった企業もありますし。

さくら：

秩序は大事ですが、古いルールに縛られるのは本末転倒ですよね。

こもり：

決まりを作ってそれに即して何かをやるというのは大事だと思うんですけれど、それが足枷になってしまうと本当に何も変わりません。

くれま：

肝に銘じます！ 今日は本当にありがとうございました。

まとめ

くれまのまとめ

Web制作の仕事に携わっていると、「変化し続けないやつは死ぬ」という恐怖心めいたものに追い立てられることはありませんか。そこまで強い言葉で表現しなくても、「いまのままでいいのかな？」という漠然とした疑問は、多くの人にあるのでないでしょうか？ そんなとき、こもりさんのような水先案内人に手引きしていただけると、心強いですね。変えること／変わることを恐れず、日々進んでいければと思います。

さくらのまとめ

Webがさまざまな環境で閲覧される2017年。当然クライアントの環境や条件もさまざまで、ワークフローもさまざま……。そんな「ワークフロー迷子」な私たちの疑問に明快にお答えくださったこもりさんには感謝です。つねに周りの環境が変化しているなら、自分たちも変わらなきゃいけませんよね。アプリのノウハウやコードの知識は素早く作業するためには当然大切ですが、アプリ＝手段に固執することなく、柔軟にワークフローを選んでいきたいな！ そのためには、やっぱり日々勉強ですね。