hor.note

I hope so.

殺風景な部屋に多肉植物を導入しました

f:id:Horaotoko:20160417183628j:plain

とにかく部屋にものが少ない。しかも全体的に暗い色調なので帰ってきてもリフレッシュできる感じがない、という問題を解決するために緑を取り入れました。しかも多肉植物

多肉植物って知ってますか?僕は去年までよく知らなかったのですが、興味が湧いたきっかけがありまして、「タニクちゃん」というWebマンガを読んでからとにかくほしくてたまらなくなりました。

ganma.jp

過酷な環境でも生き延びられるように、水分をたっぷり蓄えられるような仕組みになっていて、あと葉っぱや株からまた別の個体が生まれてくる。しかもそれぞれ個性的な見た目とくれば集めたくなりますよね。集めて増やして植物だらけにしたい。

今回買ってきたのは「十二の塔」と呼ばれているハオルチアで硬葉の方。サボテンじゃなくてアロエの仲間。詳しいことは知らないのだけど育てやすいとのことだったし見た目がとんがってておもしろかったから選んだ。鉢カバーもかわいいのいっぱいあった。

植物育てるの、多分小学生以来なんだけど楽しそうなので無理ない程度でやってみます。

老舗プロダクトとリファクタリング

とあるプロジェクトで、老舗プロダクトのpostcss化を進めていくことになりました。つまりリファクタリング。秘伝のタレからより管理しやすいフロントエンドへと変えていきます。

リファクタリングといえば、昨年ペパボのフロントエンドスタンダードにも書かれているリファクタリングの方法があります。こちらはSCSSを用いていますが、流れとしてはこんな感じ。

  1. 既存の各 CSS ファイルを SCSS に変換する
  2. イニシャライズ CSS・レイアウト系の CSS を分離する
  3. CSSLint を使ってソースの整理する
  4. SCSS ファイルのコンパイル設定をする
  5. 各ページの CSS を個別に整理する

CSS 設計の長い夢 - ペパボのフロントエンドスタンダード

この方法でやろうと思ったのですが、秘伝のタレすぎてちょっと無理そうでした。なぜ無理そうだったのか、そしてどうやって回避していこうと画策しているのかについて書きます。

影響範囲がデカくない?

今回の改修に伴ってまず懸念されたのが、コードを書き換えることによって受ける影響の大きさでした。クラス名ひとつ変更するだけでもjsが動かなくなるとか、そのレベル。装飾と機能+計測がごっちゃになっていました。あと読み込んでいるCSSが置かれている場所も階層構造もバラバラ。

そのレベルでぐちゃぐちゃな場合、イニシャライズやレイアウトに関する変更を先に行ってしまうと、思いもよらなかったところで表示崩れなどの不具合が発生する可能性が高いのです。ひとつひとつclassやidやnameなどをgrepしてもバグを見逃す可能性があるわけです。

なので、今回僕らは大→小でなく、影響範囲をできるだけ狭くしながら進めていくアプローチを進めています。具体的には以下のような順番。(設計はFLOCSSで行っています。)

  1. postcss 形式の新規スタイルシートを作成
  2. 最小単位であるコンポーネント系やユーティリティ系から postcss で書き直し(※要接頭辞)
  3. 必要であればグローバルに使う変数や mixin などをファウンデーション系のスタイルシートに書き込む
  4. gulp でもろもろのタスクを実行しビルドする
  5. 出力された css を必要なファイルでのみ読み込む

以下繰り返しで徐々にレイアウトやイニシャライズに手をつけていき、最終的にはひとつのcss(allみたいなやつ)で管理するのがいいんじゃないかというところで練っています。

その他ポイント

既存のスタイルシートに限りなく影響が出ないように接頭辞をつけます。あとこれは好みが分かれるかと思いますが、個人的には接頭辞があることでパッとレイヤーとモジュールが把握できて意図しないカスケーディングを防げるので好き。

接頭辞を用いることで既存のレイヤーやモジュールに干渉できない上に、その postcss を使って書き出したスタイルシートを、必要なファイルでのみ読み込ませることでさらに安全にさせます。マークアップの方も変えてあげなければいけませんから、つまりこの方法は、ページごとの改修になります。最初のうちは冗長的になってしまうかもしれませんが、UIの崩壊が起こるよりマシ。configかなんかでまとめて管理してあげるとよいかも。

まだ始めたばかりなので、この手法の悪いところは運用しつつ見つけて改善していければなと思っています。闇に立ち向かうぞ。

メールも大事だと思うんですよね

よさそうな企業の求人情報を眺めて、その時代に求められてるスキルを知り学ぶという勉強方法を数年前からやっています。なのでたまに海外の転職サービスみたいなものに登録しているんですが、最近はHiredがプッシュされてたので登録してみました。ちなみに関係ないけど panda のサービスいいよね。

panda.jobs

で、今回の話はそのスキルがどうこうとかの話じゃなくてHiredから送られてきたメールがおもしろかったということ。途中でユーザー登録をやめちゃったんだけど、そのあとに送られてきた。

f:id:Horaotoko:20160414001258p:plain

(I’m not a robot, no auto-response here.)

ロボットじゃないよとのこと。このまえにyou'll reach me directlyということも書いてある。いろいろもしかして嘘かもしれないけど、こんな風に「気軽になんでも聞いてよ!」みたいな雰囲気っていいですよね。

if you want to talk about the current mix of shows on Netflix this season, that’s cool too.

今シーズンNetflixにアップされてる番組について話したいのであれば、それもいいねと。これでマジで送ってくる人がいるかも知れないけど、もしユーザーがこのプロダクトを利用してて本当に何か困ったことがあったときに、それくらいフランクにコミュニケーションが取れるんだってことを印象付けるためのいいやりかただと思う。

僕自身メールはユーザーとのタッチポイントのひとつとして重要なものだと考えています。もちろんダサくてやたらと大量に送られてくるメールとかいっぱいあるけど、このようにうまく使えていそうな例はどんどんとマネしていけたらなと思います。

継続可能なデザインプロセスってなんだろう?

入社してからデザインプロセスの改善についていろいろな手法を試していて、もちろんうまくいかないことが多いのだけど、その中で気づいたことなどを。

自社でつくったプロダクトやサービスに関しては、デザインしたものは出して終わりでなく継続的に改善を行っていく必要があります。継続して改善していくためには、なんらかのデザインプロセスを用います。それは自分たちで考えたものや流行りのものであったり様々ですが、取り入れてみたところで、うまくサイクルが回らなかったり改善の効果がわかりづらかったりすることがありました。「このプロセスをグルグル回してください」と言われても「どうやって回せばいいんだよ...結構キツキツだったんだけど...」と思うときもしばしば。

まあ、PDCAをまわして〜とかいろいろと言いようはあるんですが、どうすれば継続的に改善していくことができるようなデザインプロセスを選ぶことができるのか、具体的にどんなことに気をつければよいのかということについて自分の中で考えていることを書き出していきます。

リソース的に限界にならないこと

物理的に継続できないことってありますよね。人も時間も限られていますから。 例えばGoogleのデザインスプリントをマニュアル通りに行う場合、週で5日x人数分のコストがかかることになります。それほどのコストをかけられる余裕があるのなら良いのですが、小規模なチームで別々のKPIを追っていくプロジェクトが複数ある場合、そんな頻繁にはできませんね。

リソース的に厳しいのであれば、お手本にするデザインプロセスの必要な部分のみを取り入れたり(取捨選択難しいですけどね)、もっとライトな方法を探していくべきだと思います。継続できなければ意味がありませんから。様々なチームで同じような境遇のところがあるので、調べると解決策はわりと落ちてます。時間がないのであれば25分で各プロセスを行うデザインスプリントみたいなものもありますしね。

studio.uxpin.com

成果が判定可能であること

なにかしらの施策を行っても、成果がわからないということは継続可能性を低下させます。

シンプルに効果が出てるか出ていないかわからないプロセスにかける時間はないと判断される可能性が高いからです。それは直接デザインプロセスに関わるチームだけでなく、経営の舵取りをする層も判断するところです。成果が良かったにしろ悪かったにしろ、そのプロセスと判定方法が共有されていなければ継続すべきかそうでないかはわかりません。

せっかく途中まで頑張ったのに、他の優先度の高そうなタスクに取りかかれと言われ、プロジェクトは数ヶ月以上寝かされ、もう一度掘り返してみたところで「あのときなに考えてたんだっけ?」とか「方向性が変わったからこのアイデアボツだ〜」とかどうしようもない事態になるんです。恐ろしい。

成果がわかるということは、継続かどうかの判断をしっかりとするための材料になるだけでなく、自分たちの施策の可否やそのデザインプロセスに参加しているメンバーのモチベーションを上げることにも役立ちます。まずはひとつだけでもいいので評価基準を決定するところからはじめましょう。HEART Framework と The Goals Signals Metrics なんかは手軽でわかりやすいです。

www.dtelepathy.com

粒度が適切であること

アジャイル開発を取り入れているチームの方々には当たり前のことですが、タスクにしろ変更範囲にしろ施策の粒度が大きすぎると挫折します。

特にデザイナーの話で言えば、プロダクトやサービスのフルリニューアルなんかはプロジェクトが動き出しては頓挫し、動き出しては頓挫し、という経験があるのではないでしょうか。どんなデザインプロセスを取り入れようが適切な粒度と順番でプロジェクトを進めていくことが必要です。

じゃあ適切な粒度ってなによ?ってところなんですが、個人的には上記にもある通り、その施策を行うことで「どんな成果になるかが明確に判定できる」ことが大事だと思っています。この点については現状探り探りやっているところなのでまだうまく説明できないのですが、例えばAページでのCVRの改善が目的の施策の場合、フォントサイズから画像から導線からなにまで一気に変えてしまっては、なにが原因で特定の成果が生じたのかわかりません。

「なんでこうなったのかわからないし、すごい大変だったからもうやりたくない」が一番最悪なので、まずは施策に明確な成果の判定方法があること、次に判定可能なレベルの影響範囲でタスクを切り出すことが必要だと思っています。

そんな感じ

ということで、自分の頭の中をガーッと書き出してみました。あと「参加可能であること」も大事だった気がするんですが、ちょっとど忘れしてしまったので気が向いたら追記したいと思います。そんな感じで、チームを移動したりやることが変わったりするといろんな視点でデザインをすることについて考えることになるので、なかなかよい勉強をさせていただいている毎日を過ごしています。ゴールデンウィークは福岡で過ごします。

24歳男性だけど格闘技を習い始めてみた

三日坊主を克服したのでもう書いてもいいかなと思った。

僕が格闘技をはじめた理由はだいたい100個くらいあって、ひとつめは24歳となると、こうだんだんと世間に潜む闇に気がついたり、身体の不調を感じていったり、将来的な不安みたいなものを抱えていったりしてくる。

なのでそれを払拭すべく、なにか環境を変えなければと思い格闘技を習い始めた。(まだ初心者なので基礎トレーニングや基礎テクニックがメインだけど)

しかしこれがなかなかよく、いままでとは想像もつかなかった新しい環境に飛び入ることで、従来の環境にも影響を及ぼし始めた。例えば食事の内容や生活サイクルが改善していったことであったり、メンタルの部分でもちょっと男らしくなれたり、体型の変化だったり、タバコをやめたり、とりあえずこれまで僕が付き合ってきたものたちに大きく干渉しはじめている。

正直24歳でもなにかまったく新しいことを始めるのはそれなりに勇気がいる。だって自分よりも年下で自分よりもできるひとがうじゃうじゃいるので。もしかしたら自分なりには頑張っていてもどこかで笑われているかも知れない。いまからやったって対して上手になれないでしょ?専業の人よりも時間取れないし身体も昔よりもう動かなくて...。

とかいろいろ推測してはみたが、いざ実際にやってみると事実は異なる。やってよかった。たまに「私はもう年寄りだからそんなことできないな〜」というニュアンスで「若いね!」と言ってくる人がいるが、そういう人って事実よりも推測の方を重視するタイプなのかな、とミドルキックの練習をしているときに思ったのでした。

4月時点での積ん読情報

いま積ん読になってる(ちょこっとかじり読みして放置してる)本を紹介します。来月までには読みたい...。

アテンション――「注目」で人を動かす7つの新戦略

アテンション――「注目」で人を動かす7つの新戦略

サービス・スタートアップ──イノベーションを加速するサービスデザインのアプローチ

サービス・スタートアップ──イノベーションを加速するサービスデザインのアプローチ

イノベーションのジレンマ―技術革新が巨大企業を滅ぼすとき (Harvard business school press)

イノベーションのジレンマ―技術革新が巨大企業を滅ぼすとき (Harvard business school press)

人間中心設計の基礎 (HCDライブラリー (第1巻))

人間中心設計の基礎 (HCDライブラリー (第1巻))

IA/UXプラクティス モバイル情報アーキテクチャとUXデザイン

IA/UXプラクティス モバイル情報アーキテクチャとUXデザイン

Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days

Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days

つらい...いっぱいあった...。がんばる...。