Sunday, November 17, 2019
 

セミナー参加記録:CSS Nite Shift7

banner-CSSNiteLP31毎年恒例となっているCSS Nite Shift7に参加してきました。3年連続?とかですかね。

その年のトレンドを各ジャンルで振り返りつつ、今後についての旗印を立てる意味で毎年参加するのを楽しみしているイベントです。Twitterも盛り上がりますしね。

海外事例も多くとりあげられるので、情報収集の場として大変助かってます。ありがとうございます。
なので、今年参加してみて思ったことの感想など。

デバイスが人を選ぶ時代がきてるかも

スマホ利用が当たり前になっている昨今、長谷川恭久(@yhassy)さんが実際に街にでて、スマホの利用シーンや使い方のレビューをされている事の共有があったのですが、横向きで使うユーザーが現状少ないという統計が、個人的に気になったところでした。

電車内などで動画を観てる方をたまに見かけるけど、その場合は大抵、横向きが多い印象なんですが、最近はvineや昔からあるTumblrなどは縦画面の横幅で小さいながらも動画(アニメgif程度のものですが)展開しているサービスもあるので、今後は動画だから横という固定概念ではなく、縦での動画描写の最適解みたいなのが出てきても良いかなと。

正直、パブリックなスペースにおいてはスマホでの横画面いっぱいの描画ですら「隣の人の目が気になる」という心理も働くのかなとお話を伺って思ったりしました。

アクセシビリティは当たり前。でも実装側の事情との溝はまだ深そう

アクセシビリティについてのセッションが去年同様ありましたが、音声認識への意識がまだ制作側に足りないというのは大いに言えるところだなと共感しました。

ただ、そもそもで『目の不自由な人のためのサイト』というユーザーのセグメントを持つべきなのか、『目の不自由な人でも過不足なく情報を届けられる様に考慮すべき』は工数面等も含めて議論の余地がありそうな気がします。

現状の制作においてCSS3の実装でトピックであがる効果も健常者をメインとした見せ方の議論から、その枠は出ませんし、マークアップにおいては、いかに効率よく作るかがメインのはず。
もう一歩、踏み込んだ実装の必要性と、それを鼻にかけることなく、「当たり前にやってますけど何か?」くらいの世の中になるべきだし、実装者のみならずディレクターやプロデューサーの視点から考慮していかないといけない事だと強く感じました。

RWDの次のステージ

RWDの流行を追っていた去年~今年の流れから、本質的な部分で突っ込んだなというのが今年のセッションの印象でした。
見た目のレイアウトを合わせるだけでなくUAの点からユーザーの利用シーンにあわせるという発想。

プロトタイプを使った実装も多くなってきている事から考えてみても、既存のPCレイアウトの枠にとらわれず「利用シーンに則したデザイン」の方法としてRWDの活用が広まれば、ただのワンソースによるウィンドウ可変対応の使い方から脱皮できるのではないでしょうかね。

他セッションも通じて感じたのは『今後のコンテンツのあり方はどうあるべきか』でした。
それは対ユーザーへの見せ方もさることながら管理面でもそうです。流行りや傾向を通してみることで、普遍的な概念が炙り出され、ユーザーの場所、ニーズ、状況を加味した上で最適な解を提供する。そのために制作側が留意すべき事。かつ、効率的に進めるにはどうしたら(何を使えば)よいかということだと思います。

最近のフラットデザインの傾向をサイトに取り入れるか、チーム間のコミュニケーションを考慮した制作ツールにいたるまでディレクターは適材適所な選択が求められますし、実際、案件ごとにその解も違うとは思います。
それでも『本質を意識してユーザーに適切に情報を届けていくにはどうしたら良いのか』を常に頭に置いておきたいものですね。

ご登壇いただいたみなさま。お疲れ様でした。
また来年も期待しております。

 

セミナー参加記録:# fc0設立5周年記念!公開MTG& takram design engineeringのセミナー

このところ忙しかったため、その反動のせいか、11月の末から今月にかけて立て続けにセミナー参加する機会が増えました。

小さい規模のものから300名が参加するものまで様々でしたが、どのイベントも得るものが多く来年以降の自分の良い糧になりそうな、そんな気分でいっぱいです。懇親会などで人と出会う機会も増えたので、今後につながれば嬉しいかぎり。

例によってインプットばかりではアレなので、今回からいくつかの回に分けてレビューという形でアウトプットできればと思います。

もし一緒に参加された方がいらっしゃれば、ご意見などいただけれると嬉しいですね。共有できる事項について、自分だったこう思うみたいな議論って個人的に好きなので。

11/28 #fc0設立5周年記念!公開MTG

普段からお世話になっている藤川 麻夕子さん(@fuuri)と山本 和泉さん(@izuizu)からなるユニット:#fc0さんが設立5周年&公開MTGをされるとの事で参加しました。

個人的に#fc0さんのお仕事には興味があり普段どういう仕事の進め方をされているのか根掘り葉掘り聞けるチャンスでした。
内容としては公開MTGと形ではあるもののお二人の過去、今、未来についての紹介+プレゼン?といったところ。外からだと仲睦まじいお二人も喧々諤々の時もあるとの事で、気苦労、お察しいたします(え)みたいな部分も見れましたね。

懇親会時には生々しいお金の話も伺えて、元々お二人ともフリーランスからスタートされたという点も凄く参考にさせてもらえました。顧客の選び方(自分たちがやりたい事やスコープの先鋭化)、キャッシュ・フローへのシビアな姿勢などなど。

伺っていて一番思ったのは、「あー、すごく出会いを大事にされている方々なんだな」という印象。山あり谷ありの中、ツライ時に助けてもらえる存在って大きいんだなと改めて深く感じた、そんな会でした。

12/5 takram design engineeringセミナー

こちらも普段からお世話になっている技術評論社の馮さん(@tomihisa)のセミナーでした。
技術系月刊誌やオンラインメディアを通して「コミュニケーション」「活字」「編集」の観点からのテクノロジーの変化についての講義でした。

活字文化をベースとして、メデイアの変遷を辿るといった内容で、90年代〜からの社会情勢の話もあり、背景がイメージしやすい内容でしたね。サン・マイクロシステムズとか懐かしかった。

それらの思想がUNIXへ通じ、現状のMac OSまでつながっているというのは、歴史が浅いと揶揄されがちのこの業界においても、しっかりと受け継がれていくものなんだなと感慨ひとしおでした。

これからのメディアにあり方についても考察されていて、大きくうなずける部分もあり紙媒体を基板としたメディアのこれからは、電子書籍も含め未知数であるからこそ、チャレンジングなビジネスになっていきそう。

既存のUI/UX、コンテンツの話と上手く絡んでくると、もっと見せ方の面で幅が広がってくるんでしょうな。
現状はそれらがバラバラだったりデバイスありきの議論になっているのはもったいないなと翻って感じたセミナーでした。

(次回は12/9週で受けたセミナーについてお送りします。)

 

プログラマの頭の中から読み解く『モノ』の考え方の可能性

『ずっと本棚に置いておきたい本』ってのに、出会う事は難しい。
気になった本は率先して読む様にはしているのだけど消費とブックオフ行きのサイクルが早くなってる気がする。(自分は、まだあまり電子書籍は読まない)

個人的に本を買う楽しみの一つに手元に残す本を厳選していくと段々、本棚が選抜クラスになってきて、知識がビルドアップされてく感じが可視化できてモチベーションがあがる。置くスペースの限界があるからというのもあるけれど。その本を経て今の自分がいるみたいな感覚が、たまに本棚を振り返るとちょっと勇気がわいてくる。

あと気に入ったり、後でまた見返すかなと思う本を手元において置くと、自分の知識に句読点を打つような感覚があって、また見返すときに、その本を初めて読んだ時に戻れる感覚がある。あんまりにも厚かったり翻訳が変だと何度読み返しても寝ちゃうけど。(え

思考は一方通行ではない。

自分はディレクターなのでノンプログラマーなのだけど、前々から『プログラミングをする』という事に関心はあった。

今でもHTML,CSSは使えるし、JS,PHPについてもある程度は触れるのだが、既存のフレームワークを使ったり、専門の方が作ったものを改修する程度の事がメインのため、そもそもの『プログラミングをする』発想の起点というか、構築をする上での頭の使い方についてモヤモヤとしたものがあった。

この本は、Sunabaという独自の学習言語を使い実際にブロック落としゲーム(言うなればテトリス)を作る事で、既存プログラミングの文法を学ぶ事より、もっと手前のプログラミングの思考法について至極丁寧にかつ時に冗長なくらい親切に書かれている。

プログラミング初心者に対して『プログラミングをするとはどういう事なのか』を通し、ある視点からのモノの考え方についてまで踏み込んでいて、個人的に目からウロコな部分が多かった。具体的には

  • 結果から考える。
  • 具体的な手法に落としこむため、問いかけを変えてみる
  • 目的があってこその手段

といったところ。
一方通行な考え方では、辿り着けずに迷いがちな事も、ちょっと視点を変えてみる事で見えてくる部分がある。
もちろんプログラミングなのでちょっとした数式はあるものの、それすらも根底にあるのは言語化された事柄として、スッと頭に入ってきやすかった。

ちょっと厚いけど「自分の考え方がコッてるなー」って感じる時に都度読み返したい。言うなれば凝り固まった自分の頭の使い方から一歩外に出て、新たな可能性を探ってみたくなる、そんな本。出来上がったらテトリスでも遊べるしね。

これからプログラミングを始めてみたい方のみならず、新たな発想の起点を模索している方にもオススメしたい良書です。

 

当事者意識がつくる『評価のステージ』

仕事をする以上、結果と評価は常についてまわります。

お題として得たニーズに対してソリューションを提示し、それについての評価を得る。
評価を下すのは、サイト制作の場合はユーザーまたクライアント、社内でしたら上司でしょうか。ただし一口に評価といっても自分のいるポジションなどから、どういった評価を得たいのかが変わってくる事があります。
それは補完的立場として求められる結果と当事者として求められる結果の違いです。そしてそもそもの起点の違いが結果のクオリティや周りからの評価に大きく作用します。

つまり『言われた事を言われた通りにやって得る評価』『自分のやりたい事をやりたい様にやって得る評価』は、結果的に評価自体は変わらなくても起点の違いがモチベーションに大きく差が出ます。

ワガママとは違った『自分本位』

後者の方が茨の道でしょうし、暴走にならない様に事前と事後の周りへの共有、自分と(+周りの目と)の戦いなど、目を配る箇所は多いです。しかし得たもの(評価)が仮に同じだったとしても本質的な価値が大きく違います。

「やりたい様にやる」と聞くと自己中心的なイメージがあるかもしれませんが、人間誰しも自分の興味のある事には率先して能動的になるものです。
とは言え、組織論においてはオペレーション的な動きを必要不可欠であり、それは関係者全員の約束事として抑えるべき点でもありますが。

また、人を仕う立場にあるなら、相手にどう当事者としてのモチベーションを持ってもらうかが大事であり率先して動ける組織作りが理想でしょう。ただ、受け手としては丸投げの様に捉えられてしまう事もしばしばあるのが現実です。
個々が当事者であり、かつ「今求めらてる結果は何なのか」。その意識の共有がワガママ集団ではなく、自立した集団となる分かれ目なのかもしれません。

『自己』と『周囲』のバランス

評価を得る事でソリューションが初めて価値を見出し、金銭や満足度といったもので代替されて自分に返ってきます。最近はよく「アウトプットが大事」と言われますが、ただ単にアウトプットすれば良いという事ではなく『評価のステージに挙げる事』が本質的な意味でしょう。

もちろん自分のアウトプット全てが評価してもらえるという訳ではないですし、逆に一挙手一投足が評価されてしまう人も中にはいます。自意識としてどちらが居心地が良いかは意見の分かれるところではあります。
「全ての人に好かれたい」は自意識過剰でしょうし、そもそもでターゲットが曖昧です。またそもそもで評価して欲しい人に結果が届かなければ評価してもらう事はできません。
自分のやりたい事、目指すべき得たい評価があるのなら、周りに対して愚痴る前に、まず自分のポジションを俯瞰し、誰から評価を得たいのかを再考しましょう。

自分としては、満足のいく結果が出ても周りからは辛辣な評価を得る事もあります。なかなか世の中は思い通りにはいかないものですが、評価を得続ける事が大事あり、そのためのプロセスもまた継続し続ける事が大切なのだと思います。
それが『自分のやりたい事』であるならなおさら良い事です。自分のステージは自分で作る。与えられた中で右往左往するのではなく、そのための試行錯誤にこそ本当の価値があるのだと思います。

 

制作は、調整役の漏れや遅れを巻き取るためにいるんじゃありません

PM(プロジェクト・マネージャ)という職種があります。
プロジェクト・マネージャは、そのプロジェクトにおいて、各タスクを整理、分解し、誰が、何を、いつまでに、どうするのかを管理します。

それらを制作へと共有し、進捗確認し、作業の遅れが出ていないか、遅れている場合、どれが先にクライアントへ提出できそうかを判断。
タスクとタスクの間のクリティカル・パスを俯瞰でとらえ、決められた納期中に定義された要件の成果物(サイトまたはサービス)を制作と協働しクライアントへ納めるのが仕事です。

PMという職種の流れついてザッと書きましたが、代理店と制作会社間においても端的に調整→制作のフローに変わりはありません。決められたスコープの元で契約が取り交わされ、それぞれのマターにおいて粛々と作業は進みます。そこに何も疑問はないのですが、ただしある前提条件が埋まっています。

制作側はスコープの提示から、必要なコスト、スケジュールを調整役へコミットします。要するに「この要件を満たすにはスタッフが何人必要でこれだけの期間がかかります」と調整役へ伝えます。
見積もりにも関わるところなので当然なのですが『プロジェクト』という大きな粒度でスケジューリングをした場合、大抵、調整の期間と制作の期間は内包もしくは、クリティカル・パスとして認識しきれていない事象が多々あります。
つまり「調整の進捗が遅れても、制作側で巻き取ればいい」という不文律が、往々にして起こりえるのです。

PMがマネジメントしているものとは

当然、制作が着手できるのは、調整役のフローが終わったあとです。調整のfixが遅れれば制作の作業時間が減ります。しかし、納品期限は変わらない。リソースはコスト的に増やせない。調整不足により追加要件も増えてタスクが増える。チェックなどに十分な時間がとれない。よって品質が下がる。というネガティブなフローが後を断ちません。

そのためPMや制作は『期限内に納める』という事に終始し、連日の徹夜やなんとか調整した追加リソースで要件をまとめ納品するものの、チェックなどが間に合わず、抜け漏れもあり、納品後の追加対応も発生する例が多いです。
調整役の多くは「品質を上げろ」などと言いますが、個人的には品質を下げている理由の半分は調整役による作業スケジュールの食い潰しだと思ってます。

PMがタスク管理や進捗管理をするのは、間に合わせるためだけでなく、定義された品質を納品物に担保するのが本来のはずです。
時間がなくなるとそれらが後回しとなりがちで、まさに本末転倒で契約などを傘に何のため作っているのか分からなくなるがままに、ただただ疲弊するというのは、よくある不幸な話です。

制作へ進捗を聞く前に、まず調整役が制作へコミットすべき事

掲題にもあげましたが、制作は調整役の漏れや遅れを巻き取るためにいるんじゃありません。要件を満たすために必要なスケジュールの中で、調整役にはできない作業を代行するためにいるというのが個人的な見解です。
そのために調整役は、まず『その調整がいつまでに調整しきれるのか』を制作へコミットすべき=制作に必要なスケジュールの確保を厳守する事です。

会社間の場合は力関係などもあり制作側から調整役会社へコミットを求めるのは難しいというのはあるかもしれませんが、品質を担保するためには必要なプロセスです。そして、調整役のスケジュールと制作作業スケジュールは基本、別で考えましょう

それらは最も大きいクリティカル・パスであるが故に見過ごしがちですが、制作としてデスマを避け品質を担保するためには、時間が必要であるという事を調整役に伝えコミットがもらえないのであれば納品物について早めに調整を入れるようにしましょう。

理想論も含みますし二次受けや三次受けだとなかなか難しいとは思います。ですが、そこで制作側が調整役へ進言できるかが、下請けとパートナーの違いなのかもしれません。