実データで学べるRedashハンズオンをやってみたら完全に求めていたものだった

Redash?

RedashとはさまざまなデータソースからSQLなどのクエリを駆使してデータを取り出し、グラフやレポートをGUIで作ることのできるオープンソースのツールです。
Webエンジニアをされていれば、いい感じにデータを抽出してほしいという依頼が飛んできたりすることもあるのではないでしょうか?
Redashでは実行したクエリを保存して別の人が違うタイミングで実行したり、ダッシュボードにまとめてレポートを作ったりすることができるので、その辺の要求に簡単に応えられるようになるのではないかと思います。

Redashハンズオン?

この記事のタイトルにもありますRedashハンズオンid:kakku22 さんが作られているもので、ハンズオン中で使うデータを含め環境構築まですべてが書かれています。
MacでもWindowsでも問題なくできるそうなのでこれも嬉しいなと思いました。

動機

どのくらいの知識量なのか?

僕自身、SQLはふつうに書ける(チョット調べたら複雑なものも書ける)くらいです。
また、今回紹介するハンズオンではDockerで環境構築を行っており、僕のDockerの基礎知識は限りなく0でしたが、全く問題なく最後まで終えることができました。

なぜこれなのか?

Redashについては以前から知っており、会社でも溜まってきたデータをそろそろ可視化して次の施策につなげたいなどの要求が高まってきたこともあって「自分で使ってみよう!」と思ったこともありました。
使ってみよう、と思ったはいいものの、公式の解説ページであるSetting up a Redash Instanceからいろいろやってみたのですが、何故か*1うまくいかず、Redash怖いという印象で終わってしまっていました。

id:ariarijp さんとid:kakku22 さんが主催でRedash Meetup #0 - Redash 初心者向けハンズオンを開催されるとのことをconnpassのサイトから知り、ハンズオンならやれそう!と思って申し込んだものの業務都合で参加できなくなりました。
一度やる気が出たのでこれを逃す手はないということで、公開されている資料を見て実行に移しました。*2

スクリーンショット 2017-12-29 12.25.20.png (69.5 kB)

内容

実際の内容について、詳しくは元の資料を参照してください。

Dockerのインストール、環境構築から、基本的な操作

環境構築から基本操作が出来るようになるまでの流れが一通り体験できます。 基本的な操作とは、

  • クエリ作成
  • グラフ作成
  • ダッシュボード作成

のことを指しています。 Redashは基本的に使う分にはすごくシンプルなので、簡単なSELECT文が書けたらこのあたりは2回目何も見ずとも実行することができると思います。 僕は普段、MySQLのクエリを探索的に使う際にはSequel Proを利用していますが、それよりもSQLの補完がいい感じに効いていて楽に書けるなと思いました。 これはチームで触る際に、特にBizDevの方々に触り始めてもらうに当たってすごく良いことだと思います。 一部補完が強すぎて、Enter Keyを押すときに違ったクエリになってしまうことがあり、行末に空白を打つという工夫によって回避していたりしました。

クエリ操作をサポートする機能を使ってみる

SQL文を書く際に、上記の機能だけで言うと、Sequel Proなどでもできますが、こちらで紹介されている - パラメータ付きクエリ - フィルタ - クエリスニペット - クエリに色を付ける

などの機能を利用すると、より快適なSQL生活ができると感じました。 普段は、Google 日本語入力を使って、よく使うSQLを出力したりしていますが、クエリスニペットを使うとそこも覚えなくてすむのでコストが削減できますし、チームの知見を共有できるという意味ではすごく良いと思いました。

フォーク、リンク集作成、結果のダウンロード、アラート通知などの機能の紹介

簡単ではありますが、これらの発展した機能にも触れられていました。
特にアラート通知機能は革命的に便利で、Slack通知をいとも簡単に実現できました。
コードをわざわざ書いて、cron回してということをしていましたが、GUIで作成からメンテナンスまでできるので、楽に評価高くできそうですね!

その他、自由課題

また、ミートアップの発表資料を見ると早く終わった方のための自由課題がありました。
そちらもやってみると、先程も書いたとおり基本操作はすんなりできたので、自分ひとりでも簡単に最後まで終えることができました。
振り返り記事では、追加演習も紹介されており、admin周りのページも一通り目を通してみました。
同じく紹介されているGoogle Spreadsheets連携についても、社内便利ツールとして使い所がかなりありそうなので、次に学びたいなと思っています。

まとめ

Dockerをやってみたら意外と楽にできた

おまけチックですが、Dockerについて少しだけ耐性ができました。
「Dockerよくわからん」という状態で、以前にRedashを試そうとしたときもAWSを選択してしまっていました。
今回Dockerを入れて触ってみて、*3特に問題なく環境構築できたので、Dockerいけるんじゃね感が高まってきました。そういう意味でも0からとりあえず1まで動く前提で工程が記されているハンズオンって偉大だなと思いました。

実際の業務でチームに導入していこうと思う

実際にやってみて、これならお試しでチームに導入できそうだなと思いました。
そういえば、つい最近BizDevの方が、「クエリ触れる用になりたいんですよね」的なことを話されたので、年始に導入やれるんじゃないかと思いました。

ただ、実際運用する際にDockerでいいのか?
など、あくまでハンズオンでわかりやすくしてくださっていた部分で嵌りそうなので、その辺を公式ドキュメント読みつつやってみようと思います。

初心者向けハンズオン再演があるようです

一回目のハンズオン回の再演があるそうです。
こちらから申し込むことができるので興味がある方は是非行ってみてはいかがでしょうか?*4 redash-meetup.connpass.com

*1:春頃なので詳細には覚えていないですが

*2:その週ではできませんでしたが...汗

*3:あまりわからないながらも

*4:すでに定員オーバーしていますが、1月末なのでキャンセルも見込めると思います

ajitofm忘年会に参加してきました

僕が普段聞いているajitofmというPodcastの忘年会が開催されていたので、参加しました。

connpass.com

このエントリでは、ajitofmの紹介と今回開催された忘年会の感想を書こうと思います。

ajitofm

ajitofmはsuzuken id:suzu_v さんがホストとして、VOYAGE GROUPさんの社内バーであるAJITOでの*1エンジニア同士の語らいを収録し、公開されているPodcastです。 *2

Tech系のPodcastといえば昨今幅が広いですが、比較的技術的な話が多く、基本的にはVOYAGE GROUPの方々がお話しされています。

またVOYAGE GROUPの外からゲストがいらっしゃっているときにはそのゲストの色が色濃く出ているように感じるので、 id:suzu_v さんの回し力が垣間見れます。

言語としては、普段書かれている(らしい)PHPやGOの話が多く、インフラ環境や機械学習的な話?もあったりします。

僕とajitofmとの出会い

普段からTech系のPodcastをよく聞きますが、ajitofmと出会ったのは7月の上旬でちょうど2エピソード目がリリースされた直後くらいだったと思います。新しいPodcastを探していて偶然発見してから毎回欠かさず拝聴しています。

僕は現在でプログラミングを始めて1年半足らずと日が比較的浅いほうですが、おそらく普通に話されていたらわかりづらいだろうなという点もしっかり言葉を割いて話してくださっているように感じ、優しいPodcastだなという印象を受けました。

ajitofm忘年会

さて、忘年会はもちろんAJITOで行われたわけですが、僕は19時が定時だたっため遅刻して参加しました。*3

するといきなりid:suzu_v さんによる開会の挨拶らしきプレゼンが入ります。

本当に間に合ってよかった。

個人的には、PodcastsConnectによるリスナー数の分析や離脱率のグラフが面白かったのと、ajitofmのページhttps://ajito.fm/ で少々レスポンシブがうまくいっておらず、id:suzu_v さんがCSSが苦手とおっしゃっていたのが新鮮で良かったです。(スライドはたぶん公開されていないのでURLはありません)

suzukenさんと話した

到着からいろいろな人と話すことができましたが、特に印象に残ったことでいうと、やはりsuzukenさんとお話ができたことがあります。

普段からPHPを書いていたり、記憶に新しかったりと、特に最新2回の話をして、それについてや、それについて思ったことを交えて感想を 話した伝えたように思います。

注意 以下技術的な内容も含まれますが、あくまで話を聞いた僕の解釈となっています

あまり楽しいとは言えないプログラミングも業務ではあるんだよという話

エピソード16で機械学習の進歩によって人間がプログラミングをすることがなくなるのではないだろうか、というような文脈の話をされていました。

一度考えたらあとは作業になってしまうような、機械にやらせたいプログラミングはある、ということの例として、PHPのバージョン5.6から7.2への移行作業を挙げられていました。

僕は最近業務で、*4既存のPHPのPDOを使ったSQL文をEloquent*5のモデルを導入することで移行するといった作業をしています。 この作業自体は本当に考えることは少なく、ただ変更していくというもので、楽しくないな、辛いなと思っていました。

そして、このエピソードを聞いて、suzukenさんでもそういう作業をしているんだ! という風に励まされ、嬉しかったという話をしました。*6 jQueryで書かれた古いコードのメンテをすることもある、であったり、関連する話が盛り上がってすごく良かったし、勇気をもらうことができました。

設計の悩みから、アドバイスを受けてうれしかった

↑の流れでもう1つ自分が最近抱えていたDB設計についての悩みについて相談しました。 状態を管理をビットフラグで行っているものが複数箇所あり、パッと見でわかりづらく、コード変更が怖いといった相談をしました。 すると、その「状態」が、順番のあるものなのか、そうでないものなのかによって、enumなどで1カラムで管理するものと、すべてのビットをカラムに分ける方法とが考えられる、といったアドバイスをいただきました。

そういうふうに分けて考えるのか、と勉強になったことだけでなく、こういった日々の悩みをしっかり聞いてもらえて、的確なアドバイスまでいただけたことが嬉しいなというふうに感じました。

その他にもいろいろな話を聞いていただき、ajitofm忘年会の主催を独り占めしてしまった感のある時間帯を作ってしまって少し反省しましたが、それでもすごく良い経験ができて本当に楽しかったです。

そして、こういった設計についての悩みはいろいろな部分で存在し、僕自身日々不安に思っていたため、このような話を、レベルはもっともっと高いと思いますが、たくさんのエンジニアが就業後日常的にされているらしいAJITOという環境は本当に素晴らしいんだろうなと思いました。

その他感想

たくさんの方とお話できましたし、プレゼント企画もあって、ajitofm忘年会本当に楽しかったです。 何より、普段聞いているPodcastの中の方々と直接会って話せて嬉しかったです。

またの機会があれば是非参加したいですし、AJITOの方にも来ていいとのことなので話したくなったら行ってみても取って食われたりしなさそうだな?笑とか思いました。

中の人まで届くかはわかりませんが、最後はメッセージでしめたいと思います。

お忙しいとは思いますが、お体にお気をつけてください。来年からのエピソードも楽しみに待っています!!

*1:実際は会議室を借りているらしいですが

*2:とはいえ、VOYAGE GROUPさんと公式な関係性はなく、あくまで個人の見解として公開されているようです。

*3:最新回で適当に来ていいとおっしゃっていたので甘えさせていただきました。

*4:経緯と詳細は省きますが

*5:ORM

*6:ちなみにsuzukenさんはORMではなく生SQL派だとおっしゃっていました。

Tech系Podcast しがないラジオ忘年会を開催しました

はじめに

しがないラジオアドベントカレンダーの19日目の記事となります。

僕は、1日目にもTech系Podcast『しがないラジオ』をはじめて変わった5つのことというタイトルで記事を書いていますので、そちらも読んでいただけると嬉しいです。

さて、僕はしがないラジオでパーソナリティーをやっていて、

昨日(12月18日)しがないラジオ忘年会を主催したので、本日の記事ではそちらのレポートを書きます。

shiganai.connpass.com

当日の様子

過去回ゲストのかた5人と、公募のリスナー枠で3人のかたが参加してくださいました。

f:id:zuckey_17:20171219200556j:plain

ゲストの中でもsp11でゲストに出ていただいた石丸さんはなんとドイツからSkypeで悪の組織のボス的に参加してくださいました。

f:id:zuckey_17:20171219200642j:plain

リスナーの3人とはパーソナリティー両方が初めましてだったので、日常的に、一方的に声を聞いていただいている人にお会いして、「あ、本物がしゃべっている」と言われるというなかなかできない体験ができました。笑

てぃーびーさんが楽しくてしかたがない、しがないラジオ忘年会レポートという記事を書いてくださっているので、そちらも参照してみてください。

忘年会のコンテンツ

主に3つの企画をしました。

ゆるくやっていたためパーソナリティー2人がLTで計50分以上もしゃべったため、たった3コンテンツで3時間半まるまる使いました。

公開録音

公開録音には出席していただいたすべての方に参加していただきました。

ゲストの方には、自分のゲスト回の思い出を、

リスナーの方には、印象に残ったエピソードの話をしていただいています。

特にどういう内容でやるかを事前に共有せず、その場でお題を出したにもかかわらず、しっかり答えていただきました。

こちらのエピソードは、「ep.29 楽しいしがないラジオ忘年会」として既に公開しているので、 公式ページや各種Podcastクライアントにて聞いていただければ嬉しいです。

https://shiganai.org/ep/ep29

個人的には、グダグダしてお蔵入りするんじゃないかと思っていたのですが、 皆さんが順応に対応していただき、素晴らしいなと思いました。

リスナーの方々の印象に残ったエピソードがすべてゲスト回だったので、 パーソナリティー2人の回もこれからもっと頑張っていかないとという気持ちになりました。泣

LT大会

順番に紹介していきます。

まずパーソナリティーの2人がそれぞれ25分ずつくらい話しました。LTとは...

しがないラジオの作り方 - @zuckey_17 -

収録/編集環境の変遷や、Webサイトの実装、 そして、その課題点や今後の方向性について話しました。

スライドにも書きかしたが、

  • 音声コンテンツの収録や編集に詳しい方
  • SoundCloud APIに詳しい方

いらっしゃいましたらアドバイスいただきたいです笑

しがないラジオの1年 - @ikegami_jumpei -

  • SoundCloudの視聴数の変遷
  • Twitterのフィードバック
  • 僕らのプライベートSlackのやりとり

などをもとにこの1年を振り返ってくれました。

さまざまな方々が徐々にしがないラジオに関わっていってくださっているのを実感することができました。

たった一つの盛り上げる技術 - @tbpqr -

ハッシュタグでのツイートだけでなく、パーソナリティーへのDMなどでも含め いつもたくさんのフィードバックをしてくださるてぃーびーさんが、 なぜそこまで積極的にフィードバックをするのか、ということについて、

「その行動の結果なにが起こるかを考える」

という観点から解説してくださいました。

※ 残りのお二方は公開記事がありません。

Web系に転職したらその次は? - @hkdnet -

僕らのラジオの名前(SIerのSEからWeb系エンジニアに転職したんだが楽しくて仕方がないラジオ)に寄せて、Web系に転職した後のステップアップについての考え方についてを話しくださいました。

パーソナリティー2人よりも早くにWeb系に転職したはくどーさん、 いつもいろいろ教えていただいていたりしていてやはりすごいなという感じがありますが、 それでも切磋琢磨できる存在になりたいという気持ちの高まりとも感じました。

無題 - OSCAさん-

はくどーさんに引き続いてエンジニアのキャリアについての考え方を話してくださいました。 詳しくは、本アドベントカレンダー23日分の記事で詳しく書いていただけるようなのですが、 エンジニアが自らの仕事へのモチベーションを考える上での考えうる選択肢を紹介してくださいました。

また、エンジニアは常に自分の考えている最もモチベーションの上がる仕事ができるわけではなく、

  • その状況の中でどのように仕事をする理由を見つけていくのか
  • もし部下がそこに疑念や不満を持った時にモチベーティングしていくのか

について話してくださいました。

今僕は、Web系に転職して、コードが書けて自分の能力が向上していくことそのものに喜びを感じていますが、 それが年を経ると、他のモチベーションが生まれてきたり、それを見つける必要が出てきたりすることもあるのだろうな、と漠然と考えました。

楽しいドイツの観光地ベスト5 - @shoya140 -

残念ながら時間不足で石丸さんのLTを聞くことができませんでした。 (ドイツからのリモート参加にもかかわらず、時間を取ることができず、すみませんでした。) sp11bでも話されていましたが、ドイツの様々な名所を趣味である写真をベースに紹介してくださっています。

どれも素晴らしい写真で、ドイツへのいきたさが高まります。

スペシャルコンテンツ

こちらは企画していたわけではなかったのですが、LT大会終盤のはくどーさん、OSCAさんの発表を受け、議論が白熱したので少しその内容を書きたいと思います。

仕事の方向性と自身のモチベーションについて

OSCAさんの発表でもありましたが、エンジニアが仕事の中に求めるモチベーションはさまざまで、

企業がそのモチベーションにあった仕事を必ずしも提供できるわけではありません。

その中で、組織の中でてぃーびーさんはMBB(Management by Belief)を紹介してくださいました。(OKR(Objectives and Key)と対比されていました。)

まだしっかり調べきれていないですが、

チームで誰がどんなモチベーションを持っているかを把握し、すり合わせる。

そして全員が高いパフォーマンスを発揮することができる。

いうのは簡単だが、なかなか実践できていることは少ない。そういう話だったと思います。

将来の描きかた

上記の話の中で湊川さん(llminatoll)から、前職での取り組みについての紹介がありました。

10年後の目標をチームで共有して把握し、個々がやるべきことを分担できるようにするという施策でした。

それを受けて、長期的な目標の立て方、その難しさについての話になりました。

結論としては、長期スパンな目標ほどと抽象度を持って手段を明確にしないのが良いのではないか、という話になったと思います。

各個人、目標を立ててそれを進めていきたい、目の前のことだけ片付けていけば良い、などさまざまな性格の中で、

(特にWeb系と呼ばれる世界で)どんどん変化していく世の中に適応しつつ成長していくためには、

もしかしたら当たり前かもしれないですが、そういった考えを持っていかないといけない、という話になりました。

似た人が集まった

いろいろ議論に花咲きましたが、おふたりのLTからこのような議論に発展したのは、勝手ながら、みんなこういった話が好きで僕らのPodcastを聞いてくれていて、実際に集まったらめちゃくちゃいい話あいができたのだ、と思いました。

僕もこういう話は大好きですし、モヤモヤすることも多いです。これからもそれをラジオという形でアウトプットし続けて、いろいろなフィードバックを受けていきたいと思いました。

最後に

この会に参加していただいた過去回ゲストのみなさま、リスナーのみなさま、

すごく楽しい時間を過ごせたと思います。

初対面の方もいたりして微妙に緊張していましたが、終始じんわりとした感動の中にいました。本当にありがとうございました。

そして、僕と同じくパーソナリティのガミさん id:jumpei_ikegami は会場手配、飲食の手配をしてくれました。本当にありがとう!

この日のために、ステッカーを作ったのですが、皆さんにお渡しすることを忘れてしまい、それだけが残念です。

また、昨日参加していただいた方にはお会いすることもあるでしょうし(ゲスト回待ってますよ!)、Twitterフィードバックや、iTunesレビュー企画などで配布しようと思っているので、今後にご期待ください。

まだ、残り日数もありますし、ラジオの更新もあると思いますが、忘年会ということでこちらで締めたいと思います。

今年もありがとうございました!来年もどうぞよろしくお願いします!

Tech系Podcast『しがないラジオ』をはじめて変わった5つのこと

はじめに

f:id:zuckey_17:20171201233552j:plain

しがないラジオアドベントカレンダーの1日目の記事となります。 このアドベントカレンダーを立ててくださったてぃーびーさん、いつもフィードバックなど関わっていただきありがとうございます。

今年の3月にしがないラジオをはじめて、自分がどのように変わったのか、周りの環境がどのように変わったのか、を書こうと思います。

本題

1. インプット量が増えた

ラジオを配信する、しかも1週間に1回のペースで1時間 ~ 1時間半ほど話すとなると、話題が豊富に必要になります。

1週間に平均1回のリリースをしようと決めて始めたこのしがないラジオですが、かなり早い段階でネタがなくなってしまっていました。

序盤*1については、パーソナリティのこれまでの経験について語っており、学生生活、社会人生活でITやプログラミングとどのように接してきたか、パーソナリティ2人の前職でどのようなことをしていたか、感じていたか、などを話していました。

そういった話題も長く続くことはなく、前週にあったTech系のニュースの雑多な話を拾って自分たちの意見を取り上げるといった方式になりました。

しかし、途端に 「以前の方が面白かった」と言われるようになります。

よくよく考えるとエンジニアになってそう長くない2人が雑多なニュースに対して深い考察ができるとは思えません。

パーソナリティの間でも議論し、積極的に本を読んでその報告をすることにしました。

結果、技術書を1ヶ月に2~3冊くらいのペースで読むようになりました。

そのほかにも、

など、興味をもっていろいろ読むことができました。

「ラジオで話せるし、とりあえず読んどくか」

と考えられるようになったのは、かなり良い変化ではないかと思います。

登壇駆動でいろいろなことをインプットできるということはよく言われていますが、 ラジオ駆動でいろいろインプットを加速するというのもあるなあと思いました。

2. アウトプット量が増えた

インプットに引き続きアウトプットも増えるようになりました。

ラジオの公開を始めた3月頃、あまりのリスナーの増えなさに、宣伝したい!という思いから、 LT大会や勉強会で発表することを始めました。

それまでは1度も勉強会で登壇をしたことがなく、 また僕自身あがり症で大人数の前で話すことにすごく苦手意識がありました。

そういうこともあり、3月から月に1度はなんらかの発表活動をするということを目標に掲げ、 発表することにしました。

そして徐々に「話すのが楽しい!」「もっといろいろと伝えたい」と思うようになりました。

発表以外にも、React初心者向けハンズオンでメンターを行ったりと、積極的に人前に出るようになりました。

印象深いエピソードとしては、過去回ゲストでもあるたみーさんが最近まで代表で運営されていた We Are JavaScripters!のLT大会にてこちらも運営の一人である深見さんから 初めての発表の時から比べて格段に上手くなったと褒めていただいたことがあり、 その時はすごく嬉しく、苦手意識が薄れていくのを感じました。

f:id:zuckey_17:20171201233354j:plain

また、ゲストに出てくださる方は、

をはじめとして、いろいろな形でアウトプットをされている方がいらっしゃり、自分もすごく刺激を受けることができています。

ラジオというアウトプットを始めると連鎖的に色々なアウトプットにつながるのだなと思いました。

※ アウトプットといえば5月頃、「ブログをやる」と息巻いていましたがやっていません。がみさんは同時に宣言していた筋トレを最近始めたようなので、もう一度頑張りたいと思っています。

3. SIerについて知見を得た

特に ep.3b 楽しい大手SIer SEのお仕事ではSIerや日本のIT業界の多重構造についての疑問点を話していますが、基本的に省略しない方の名称の通り、

SIerで疲弊しているのではなくもっと楽しいWEB業界に行こうよ」

ということを押していこうと始まったラジオなので、少し強めにSIerディスる、ということをしています。

このようにSIerについて1意見あります、というスタンスを明示的にとっていると 例えばTwitterや他のTech系PodcastなどでSIerについて触れられているものが目についてくるようになります。

やはりSIerがつらい、SIerのここがダメ、などと言及されていることがほとんどですが、 中には

  • 半年やもっと短いスパンでプロジェクトが変わるので様々な技術スタックを身につけることができる
  • SIerにいたからきちんとした工数などの見積もりが上手くなり、結果として周りとの期待値調整がうまくなった

などなど、良いことも目につくようになりました。

もしかしたら筋の良い*2SIerで経験するのは非常に良いことなのではというふうに思うようになり、 現在では一概には言えないのかなというふうには考えを改めています。

とはいえ、ラジオの中でも度々いっていますが、 ブラックでは?と思ったり、もっと楽しいことがほかにあるんじゃないかな、と思ったならば、 実際にするのかどうかは置いておいても、転職活動を始めることをオススメします。

それだけで、

  • 自分が何を大事にして仕事をしているか
  • 世間の自分への評価はどんなものなのか
  • 世の中にはこういう仕事(業界)もあるのか

という様々な発見があると思います。

4. 個人でWebサービスを運用するという経験ができた

6月頃にしがないラジオWebPageを作りました。

このサイトは Firebaseホスティング機能で、静的なファイルを置き 音声ホスティングサービスの SoundCloudや、 TwitterSlackなどのAPIを利用して 動いています。

パーソナリティの2人が業務でReact.jsVue.jsを主に使っていることもあり、 2人とも触ったことのない Angularで作ってみるか、ということになりました。*3

Angular日本ユーザー会*4が開催されていたAngular入門者向けハンズオンに二人で参加し、 そのあとにこのWebサイトを作成しましたが、いろいろなAPIを利用したり、するとハマったことも多く、*5 ただ自分たちでどのようにこのサイトを作っていきたいのかというのを話し合って作り上げました。

それだけでもすごく勉強になったのですが、 一度エピソード一覧が引けなくなる、という不具合があり、それをリスナーの方がTwitter経由で知らせてくださる、ということがありました。

内容はSoundCloudAPIのトークン切れという問題だったのですが、*6 報告をいただいて、とりあえず直さないと、この間に来ていただいた人が2度と聞いてくれなくなる! と頭を抱えながら対応したのはすごくいい経験になりました。

ちょうど先週に過去回ゲストにも出てくれている前職の同期のみっつん*7がヘッダーを作ってくれたので 久々の更新をしましたが、少し仕事が忙しい時期もあり改善から離れてしまっていたのでもっと改善していきたいなと思っています。

5. 仕事以外の名刺ができた

普段はソフトウェアエンジニアという職種で名乗っていますが、今ではTech系Podcasterという肩書きができました。 勉強会でも時々「しがないラジオのずっきーさん」「楽しくて仕方がない人」というので認識されていることもすくないですが、あって、 知ってくださって聞いてくださる人が本当に実在することに毎回感動しています。

とはいえ、僕が普段聞いているbackspace.fmでは100回配信して初めてPodcasterと名乗れ、とおっしゃっていた回が あったと思うので、11月で折り返しを超えていますが、ひとまずはそれを目指して、頑張っていこうかなと思います。

最後に

かなり自分語りになってしまいましたorz これを書いていて改めて、ラジオを始めるといいことしかなかったように思います。

2017年の2月に同じくパーソナリティのガミさんとスノボ旅行に行った際、かのRebuild.fmの話で盛り上がり、 そのあと自分たちの今やっている仕事の話で盛り上がり、「これPodcastとして話せるんじゃね?」と言い合って実際に3月に始まった時は、 まさか12月にアドベントカレンダーを立ち上げて自分が1日目のエントリーを書いているとは思いもしませんでした。*8

こうしていられるのは、いつも聞いてくださっているリスナーさんのおかげです、本当にありがとうございます。 これからもいろいろと改善を重ねてよりよくしていくつもりでいるので、フィードバックなどありましたらどんどん #しがないラジオでいただければと思っています。

*1:ep4くらいまで

*2:どう良いのかはさておき

*3:こちらもラジオによるインプットの促進ですね!

*4:とても暖かい方々でした!

*5:特にSoundCloudAPIがあまりよくなく?辛かったです笑

*6:今でもあまりわかっている自信がないので、もし詳しい方いらっしゃいましたら、話を聞かせていただきたいです

*7:みっつん本当にありがとうありがとう

*8:初めてのアドベントカレンダーで、かなりギリギリですが間に合ってよかったです

雑な感想とメモ【Meguro.es #10 @ ラクスル】@20170615

TODO

  • リンクを適切にはる
  • 感想を書く
  • 体裁を整える

Meguro.es #10に参加してきたので感想とメモを雑に共有する。

感想

  • vueの盛り上がり
  • Reactは難しい?

まとめ

meguroes

10回目らしい

Raksul

  • 仕組みを変えれば世界はもっと良くなる
  • ただの印刷会社じゃない
  • Rubyを中心としたmicroservice化
  • 業界を変えていきたい
  • 60人のメンバー
  • 速い安い

ServiceWorkerを使ったtypescript開発考察@brn0227

ブルーノさん

what is ServiceWorker

es6 Modulesを使うには

typescript Compiler(この発表では、以下、僕には難しすぎてあまりまとまっていない。)

コンパイルの流れ

ServiceWorkerとMain threadの流れを追う(スライド中に図が有り)

Problem

ES6 Modulesに対応していないModuleは動作しない

GitHub

https://github.com/brn/swts.git npm moduleも公開済み

まとめ

ServiceWorkerでbabel、typescriptはめんどい

Contextual ThisType and Vue.js@katashin

vueの中の人?

*スライド中のコードは全てTypeScript

メソッド中のthisの型は"any"担っている Vueのコンポーネントの中のメソッドなどでthisを対応するため

ThisType

Contextual ThisType vuejs/vue #5887 今までは型を導入し易いラッパーを用意するのが一般的だったがThisTypeを使うと楽になった

react-boilerplate@さっちゃんさん

  • 普段はサーバサイド
  • Reactの入れ方 → めんどくさい

react boilerplate

git clone https://github.com/react-boilerplate/react-boilerplate

npm run generate

色々作ってくれる

reselect

Control.Lens(Haskellのもの?) Haskell勉強しようよ

react-boilerplateは趣味でやるにはちょうどいい!

Source Map Revision 3の仕様概要@rchaser53

SORABITO ※独自調査なので指摘をしてほしい

規格(リンク)

  • 7ページなのですぐ読める

interfaceと概要

sourceRootとsources

  • sourcesContent
    • 変換前のソース
    • ts=>JSであればTS
  • name
    • 変換後のファイルに単語がはいれつとして保存される
  • mappings

inline sourcemap

ファイルに直接sourcemapの情報を書き込む ファイルが重くなる

X-Sourcemap

sourcemapのイチをヘッダーで指定する ソースに不要な情報が表示されなくなる

便利なライブラリ集

  • mozilla/source-map
    • sourcemapの作成やsourcemapの関連付け
    • babel,webpack,ugilifyなどが使用可能
  • azu/malti-statge-sourcemap
    • サンプル・コードして優秀

Sentryで始めるJavaScriptエラーのトラッキング@endam

Sentryって?

  • アプリケーションのエラーをリアルタイムで教えてくれるサービス
  • どんな環境で何のエラーがおこったかがわかる
  • OSSとしても公開されている

なぜSentry?

検討したサービス

  • Google Analytics
    • カスタマイズ性に書ける
  • TrackJS
  • Sentry
  • New Relic
    • JSも実はできる

選定基準は3つ

  • コンパイル前のコードの場所がわかる
    • コンパイル後は見てもしょうがない
    • sourcemapに対応
    • new relicは今年の3月に対応
  • 料金
    • Sentryはただ!
  • バージョンを管理したい
    • デグレなども確認したい
    • リリースバージョンの管理

全てを満たすのはSentry

外部連携できるサービスも豊富

まとめ

  • リリースバージョンを含めたエラー管理

vue.js 2系でサービスリニューアル@tsukasa_murashige

Raksulの中の人 デザインテンプレートに関連する機能をVueJSで実装

使用したフレームワーク、ライブラリ

  • vuejs2.2.2

vueJS2系は良くなった

  • 単一ファイルコンポーネントで見通しが良くなった
  • データオブジェクトのネストされた子のプロパティもwatchできる
  • vue-routerのscrollBehaviorで、スクロールイチの管理がしやすくなった
  • axios(VueJSで推奨されている)でAPIのモックデータの開発がしやすくなった

Cloud Functions for Firebaseを始めよう@ovrmrw

ちきさん(Angularのハンズオンでチューターしていたのを見たことが有る!) ng-japanのスタッフ 5月からwebエンジニアになった

firebase/functions-samples

公式で様々な使い方が紹介されているので一部を紹介 firebaseはホスティングができるが、それを克服するためにfunctionsを公式で用意してある https://github.com/firebase/functions-samples

色々できる

  • firebaseにExpressアプリを組み込める?
  • 外部サービスの認証を用いていろいろする
  • SSRを行って返す
  • 不適切な画像を判定してモザイクをかける
  • 外部のサービスで文字列検索してfirebaseで使える
  • firebase認証したら、tripe(決済サービス)のユーザーを自動生成し、紐付ける
  • firebase/friendlychat

デモ

  • Googleの基準でchatで挙げられた不適切な画像にモザイクをかける
  • 入力されたテキストからgoogle cloud languageAPIでpositiveやnegativeを認識し大きさを変える

まとめ

Firebaseともっと遊ぼう。

雑な感想とメモ[WEBエンジニア勉強会 #01(東京都,新橋)]@20170602

WEBエンジニア勉強会 #01(東京都,新橋)に参加してきたので感想とメモを雑に共有する。 僕もLT枠として発表した。 togetterでもまとめられている。

感想

※お前の感想じゃなくてまとめだけ見たいという方はこちら

エンジニアの世代間の違いが現れていて面白かった

この勉強会ではまず、ある程度ベテランのエンジニアさんがたが20~30分の発表をされ、そのあと若手エンジニア勢(自分も含め?)のLTがあった。
ベテラン勢の方はWeb系エンジニアとして働く上で役に立ちそうな知識を話されていて、
若手はエンジニアとして仕事し始めて感じた悩みや楽しいことなどを話していた。
多くの勉強会と違い、新橋で開催されていることや、特定の技術にフォーカスを当てている勉強会ではなかったこともあって、普段とは少し違った雰囲気だったように思う。

ベテラン勢の発表が軒並み刺さりまくった

Web技術の歴史、OAuth2.0、開発環境についてという3つのベテラン勢の発表は忙しい昨今自分だけでは振り返ったり勉強できたりしない分野をしっかりまとめてくださっていて、
自分が気になった時に参照できるようなものになっていて、単体で見ても非常に良いものだった。

発表者 + 数人で打ち上げをした

主催のOSCAさんの声掛けで打ち上げの飲み会を会場の横のビルで行った。
ベテランの方々のSIerでの苦労話などが聞けて面白かったし、
僕がやっているpodcastをOSCAさんが聞いてくださっていて、そのFBなどが得られてよかった。
SIとか受託をしていたほうが技術的には幅が広く多くの経験をつめるという意味で良いのかなぁという気が最近してきている…どうなんだろう。
もっとキャリアの長い人、いろんなキャリアを歩んできた人のエンジニア観を聞きたい。
そういう意味ではこの勉強会はちょうどいい題材を扱っているとも言える。

以下、本編

勉強会の目的

  • Web技術の共有と学習
  • 普段の取り組みの発表
  • Webエンジニアの友達や仲間を作る

近年のWEBの歴史と現状について (@engineer_osca)

自己紹介

趣味

  • 夜景写真家
  • 舞浜在住(ディズニーの三歩が趣味)

主催の目的

  • エンジニアで現役
  • 友達づくり、知識を共有したい
  • 老害トークはしたくない

どこまでがWEB?を話したい

主催として過去ではなく、未来の話をする勉強会にしたいが、今回は歴史の話をする。

Web

ブラウザとサーバがHttpでやり取り

WEB GUI / インターフェース

FlashSilverlightが駆逐されHTMLの時代に

HTML 5.1の話

  • pictureタグ
    • sourceタグを子に持ちmedia属性によって表示の制御が可能
    • スマートフォン対応やレスポンシブ対応がやりやすくなる
  • input type
    • datetime-local
    • week
    • month
      • 日付の入力を受け付けやすくする
      • input typeがHTML5で増えたがまだあまり使われていない?
      • 今後、どのように使えるのか、watchがひつよう

Webブラウザ

  • InternetExplorer
  • Mozilla Firefox
  • Apple Safari
  • Google Chrome
  • Edge
    • ブラウザの凌ぎ合いによる肥大化(誰が使うのかわからないような機能が追加される)
    • ブラウザに本当に必要な機能はなんなのか?
    • Electron
      • Webの知識でデスクトップアプリ
      • ブラウザの仕組みが裏で動いている
      • ブラウザ肥大化の象徴?
    • ブラウザでやるべきこととネイティブでやるべきことの線引をすることがこれからのエンジニアに求められる

クライアントサイド・スクリプト

通信(HTTP、HTTPS)

HTTP/2

  • 通信の高速化
    • ヘッダの圧縮
    • PUSH通信(サーバ側から送るものをスケジューリングできる)
    • HTTPバイプライン
    • Head of Line(HoL)ブロッキング問題の解消
  • HTTPS通信が前提
    • Let’s Encrypt
    • サーバ上で証明書の発行要求を行う
    • 取得できるのはDV証明書
    • 有効期限は3ヶ月だが、コマンドラインで要求可能なのでcronなどで自動更新が可能
    • 流れとしては、GoogleHTTPSを優遇するということを公表していたり、通信の傍受を防ぐ目的でメジャーになっている
  • 各種サーバーのサポート()

サーバー環境の変化

その他の話題

次回以降の発表候補

OAuth 2.0 をかみくだく (@garbagetown)

認証と認可

  • 認証
    • Authentifcation(AuthN)
    • 誰であるかの証明(運転免許証やパスポートなど)
      • ID/Password
  • 認可
    • Authorization(AuthZ)
    • 何ができるか(鍵や切符など)
      • AccessToken

OAuth2.0が必要となった背景

サービス増加に伴う認証の課題

  • IDなどの文字数の制限がサービスによって違う
  • アカウント争奪戦
  • 文字種の強制 など

サービス連携に伴う認可の課題

ログインの共有、パスワード変更などの問題が有る 近年Finteh界隈ではパスワードをサービスに預けるということをゴリ押ししているため、 金融庁の指摘が入っているなどで話題

それぞれの課題と解決策

  • OAuth 2.0 2012年10月にRFC 6749 こちらでOAuth1.0が正式に廃止

  • 用語がわかりづらい

    • OpenIDなどで使われる用語との差異
    • 世間一般で使われる用語との差異
    • 混乱を招くので注意が必要
    • 現実で起こりうる問題
  • 仕様で定められていない処理が多い
    • クライアントを登録する方法
    • リソースオーナーを認証する方法
    • アクセストークンの内容と検証方法
  • 処理フローが複雑
    • HTTPリダイレクトの連続(OAuth Dance)
    • セキュリティの考慮事項が多い

身近な例Connpass(勉強会サービス)とTwitter(マイクロブログサービス)

  • リソースオーナー
    • エンドユーザー
  • リソースサーバー
  • クライアント
    • 勉強会サービス
  • 認可サーバー

事前準備

クライアント登録手順、リソースオーナーの認証手順は仕様の範囲外こちらはRFC6749を考える前に必要

  • Protocol Flow
    • クライアントクレデンシャル
      • クライアントIDとシークレットで認証
      • クライアントアクセス情報の取得
      • フォロワー情報取得などは可能
    • リソースオーナーパスワードクレデンシャル
      • リソースオーナーの認証情報(パスワード)を渡す
      • クライアントに悪意がある場合、リソースオーナーになりすまして任意の操作を行えてしまう
      • アカウントの乗っ取りが可能なのでサービスが信用出来ないと、エンドユーザーはこのフローを踏んではいけない
    • インプリシット
      • リダイレクト祭り
      • アクセストークンのやり取りの末、勉強会サービスがアクセストークンを入手する
      • アクセストークンがローカルに保存されてしまうため、端末共有時などは要注意
    • 認可コード
      • Webアプリケーションで使われている、一般的にOAuth2.0と呼ばれているもの
      • アクセストークンをローカルに保存されないため、勉強会サービスが攻撃に合わない限り大丈夫

OAuth 認証と OpenID Connect

まとめ

  • 認証と認可をちゃんと理解しよう
  • サービスの増加と連携に伴う認証、認可の課題
  • OAuth2.0は認可のためのものでOAuth認証を使われている

Appendixが資料に挙げられているので参考にする

webエンジニアがスタートダッシュをキメるためのローカル開発環境の勘所 (@nabedge)

ビズリーチの人(リンク)

新橋はいい街

  • 「魚金」(が多い)
  • なんくるないさ」(ガード下に有るらしい・ゴーヤチャンプル)
  • 宇和島」(高いけど珍味が良い・板前さんがいかつい)
  • 「PUBこだま」がおもしろいらしい(アド街ック天国で紹介、90歳のママさん)
  • 「Footers」など

ローカル開発環境を素早く準備する(スタートダッシュは大切)

  • 目的にフォーカスする
  • 炎上した時に助っ人にすぐに仕事に入ってもらえる

Webサービスのコードをどこで、どうやって書くのか?

  • 【レベル0】データセンター建物内にて本番サーバにアクセスしてコードを書く?
    • 古き良き思い出
    • データセンターで寝泊まり
  • 【レベル1】エディタとSCPクライアントによって本番サーバにアップロード
  • 【レベル2】ローカルなサーバXAMP、MAMPで書いて、SCPクライアントで本番サーバにアップロード
  • 【レベル3】検証サーバを立てて、動いたら本番サーバにアップロード
  • 【レベル4】MySQL,Redis,…チーム開発、VCS、CI、で検証サーバと本番サーバを運用

レベル4のローカル開発環境の話

  • ローカル開発環境の要件

    • コードをサクサク書ける
    • 書いたコードが動くことを自分のPCで確認できる
      • コードが動くための バックエンドサーバが必要
  • ミドルウェア

長大な「ローカル開発環境構築手順書」

  • 長い
    • 抜け漏れ、手順書書き直すの忘れ
    • 他のWebサービスの開発環境とバッティングしてインストールできない(バージョン違いなど)

NOT 手順書、そして仮想OS

OracleVirtualBox or VMWareVagrant, Docker

  • ホスト型(ハイパーバイザ型)
    • IPをずらして複数の開発環境の共存によるバッティングを起こさないようにできる
  • コンテナ型
    • 起動速度が軽い

組み合わせでやるのが良い

ローカル開発環境4原則

  • サルでもできるくらいの自動化
  • 誰でも環境を変更して配布可能に
  • 他の開発環境と干渉しない
  • 金の弾丸(富豪的開発)

エンジニアになって2ヶ月経って思うこと (@ak6mcz2)

自分の前の発表だったのでまとめきれなかったorz

大企業でWeb開発はできるか (@renjikari)

  • 通信業界のエンジニア(サーバ寄り)
  • 新卒2年目
  • MSPのベンチャーでアルバイトしてました
  • 好きなこと
    • Infrastructure as Code
    • ISUCON

Web開発の話

  • 業務向けのシステム
    • SIに近い
  • クラウド利用のための契約とかprovisioningとかをポチポチできるようにする
  • 社内の人がクラウドを触る助けをする

  • 内製開発

  • Python + Django

pros , cons

pros

  • スピード感
    • ある意味丸投げ
    • 2月
  • エンジニア間
    • 大企業でもコードが書ける
    • ツールとか言語はなんでも基本OK
    • Gitlab+Jenkins+Slack+Trello

cons

  • POがいない(責任を取りたくない?)
  • Testを書かない
  • レビュー
  • 継続的デプロイができない
    • 商用環境が神聖

ロードマップ(これからしたいこと)

  • フィードバックを貰ってUI改善
  • マルチクラウドも契約から疎通まで
  • テストを書いてほしい

まとめ

  • どうも大企業でもWeb開発はできる

雑な感想とメモ | Geeks Who Drink in Tokyo -Design Renewal Edition-(デザインリニューアルのしくじり特集)@ヌーラボ 20170526

Geeks Who Drink in Tokyo -Design Renewal Edition-(デザインリニューアルのしくじり特集)に行ってきたのでその感想と、話を聞きながら書いたメモを共有する。あくまで自分の備忘録として書いているので、抜け漏れ解釈違いなどはあると思う。

感想

※お前の感想じゃなくてまとめだけ見たいという方はこちら

デザイナー、フロントエンドの担当が数字に敏感

両者(フリルさん、ヌーラボさん)でおっしゃっていたが、デザインや導線を決めるときにもっと数字に敏感になったほうがよいということだった。
当たり前のようで忘れがち。
結局感情や直感で決めるにせよ後々の理由付けのため、という意味でも数字は非常に有効。

目的への立ち返り

こちらも両者で述べられていたが、目的を事前に明確にし、事あるごとに立ち返って良くしていこうということだった。
これも忘れがち、というか、仕事してたらそんな余裕が無いことは多々ある。。自戒。

結局はコンバージョンしてくれるユーザーを獲得することが大事

流入元がWEBのユーザーのほうがアプリから入ったユーザーよりも回遊率が高くコンバージョン率も高い、とフリルさんがおっしゃっていた。 検索からの流入を見込んでWEBを強くしたという話だったが、流入の違いによって以下の属性の違いがある。

  • WEBの商品検索から入った人 → その商品を買うためにフリルに出会った
  • 始めからアプリをダウンロードした人→なにかいいものがないか眺めている

という感じで、ハナから目的が違うので、たしかに動きも違いそう。
アプリを使っているユーザーという一括りでみると、わざわざアプリをダウンロードしてくれているという意味でブランディング的にロイヤルユーザーが多いと安直に考えがちだが、流入元を見てユーザーをもっと細かく分析することが今後は大事になってきそう。

見た目はユーザーのリアクションを見て調整できるようにしておく

Backlogのβテスト期間で見た目の調整に継ぐ調整を行っていたという話だった。
この話を聞いて僕が思ったことは、いま自分が作っているものはこんなに簡単に隅々まで調整できないんじゃないか、ということ。
CSSについては全然わからないが、なにか見た目に関わるものを作っている場合は、簡単に調整できるように設計しておくことが必要だと感じた。
ユーザーの意見を反映するには、反映へのハードルを下げられる開発をしておくことが重要。(後にA/Bテストにも使える)

以下、本編

「小さく早く試す」 フリルのリニューアルの舞台裏

株式会社Fablic プロダクトマネージャー / デザイナー 山口 有由希さん フリルの分析、企画

アプリファースト

  • 2014年ベストアプリ
  • 2016年ベストデザインアプリ

フリルWebリニューアルプロジェクトの話

手付かずなWEB
→最適化により流入量の増加を見込める

WEBでは購入の口がなかった
→WEBきっかけのユーザーをもっと増やせる

WEBメンバー

  • 企画・デザインフロントエンド(本人)
  • サーバーサイド * 2

現状分析・調査

  • 検索流入の最大化
    • フリルの現状
    • 3ヶ月で実現可能なKPIの策定
  • 購入動線の最適化
    • 現状フローのCVRを調査

フリルの現状を知る

購入導線の調査する

データ参照元

  • GA
  • Party Track
  • DB →現状の離脱ポイントとConversion Rate(コンバージョン率: CVR)の洗い出し

ECサイトのカートのCVRを調査し、現状のフリルと比較 分析結果から指標を仮置きし試算すると、アプリでしか購入ができないのは、かなり筋が悪いことが発覚

リニューアルの目的 = WEBきっかけで登録・購入するユーザを増やす

検索流入の最大化のために

オーガニックUU目標を設定

購入動線の最適化のために

WEBで完結するように機能追加

やること

  • 拡張しやすい構造にして組み直す
  • 適切なページを増やす
  • 各ページで適切なワードが表示されるようにする
  • 欲しい商品を見つけやすくする

やらないこと

  • 登録・購入までのステップ以外のUIの最適化はやらない
  • その他のアイコンなど、ディテールの最適化

どのようにしたか

  • 検索については、SEOで段階的なリリースによるトライ&エラー
  • 並行して、様々な機能を順にリリースし、最後に購入機能をリリース

WEB登録、購入が可能にするには工数が必要だったので、ちゃんと時間を取った

結果

  • オーガニックUUは3倍
  • 登録ユーザ数は20倍

振り返って、デザイナー視点でもっとやりたいこと

  • 購入に至る経路以外の体験の最適化
    • ユーザーインタビューを重ねて突き詰めたい
  • ディテールへの最適化

今回の目標は達成できた

目標に対してしっかり結果を出す

  • リニューアル時に最初から全てを完璧にやりきるのは時間的にもコスト的にも難しい
  • 結果がついてくればまたチャレンジできる
  • 経営判断を引き出せる
  • 引き続き改善もできる

ゴールに合わせて都度最適な手段を選ぼう!

質問コーナー

  • リニューアルの設計タイミングで定性的な調査をしたか?
    • テストをして問題無いことは確認した
  • WEBとアプリでカスタマージャーニーの違い
    • 違う性質のユーザーが来るという想定
    • WEBは大量の検索からフリルに入る、アプリはフリルを使うと決めている
    • 上記の動機の違いを意識した
  • 登録後のユーザーはWEBでフリルを使うか?
    • 積極的にアプリに流したい
  • 実際に行った施策で狙った目標まで到達したか?
    • 購入導線を改善して、出品者への確認が必要、ECのCVRを超えることはできなかった
  • もともとWEBはあったわけだが、新しく作ったという認識で良いか?
    • 徐々に全部作り変えたので、順次りりーすだが、結果全く違うものになった
    • 新機能だらけ
  • 効果測定、WEBの改善によるアプリへの影響
    • WEBで登録した人をアプリに流す施策を打ったので、アプリのユーザー数も増加した
    • WEBからアプリに入った人のほうが、アプリから入った人よりもよい動きをしてくれる
  • CMなどの影響とWebリニューアルの影響はどう違うのかを判定できたのか
    • CMなどの広告では基本アプリを宣伝するので、今回に限っては分けて考えることができた

Backlog UIリニューアルの舞台裏

株式会社ヌーラボ Webデザイナー 中川 裕二

  • typetalk: チャット
  • cacoo: デザイン
  • backlog: プロジェクト管理

リニューアル

5年ぶり2度目の大規模リニューアル

目的

  • これからの時代にあったデザイン
  • ユーザーがやりたいことに集中できる
  • 新機能などを追加しやすくする

どんな問題があったのか

“課題”(backlogの1つの単位)の詳細についての情報が一番重要だが、周りに情報が多すぎてわかりづらい、分散している

やること

「仕事の中に楽しさを」というBacklogのコンセプトをひきついでかつ、画面をスッキリして、整理

やらないこと

大幅な画面構成の変更

約一年に渡るビッグプロジェクトになったが、開発の後のリリースまでの話をする

リニューアルに当たって事前にケアしたコト

  • リニューアルのストレスを最小限に
    • 大幅な画面構成は変更しない
    • 既存機能の削除はしない
  • ユーザビリティテストをする
    • 自分たち以外の人に使ってもらう
  • β期間を設ける
    • いつでも新旧を切り替えられる

結果

ユーザーから不満の声が大量に…

フィードバックの主な経路

→Typetalkで議論しBacklogに課題として登録、対応

現実的なすり合わせと対応

  • ダッシュボード
    • タブで切り替えるようにした→3つの情報が俯瞰して見れない
  • コントラスト
    • 今風なものにした→目が疲れる…
  • メリハリ
    • よりスッキリに→コンテンツの境目がわかりにくい

Backlogの課題でやり取りしつつ週次のデザインMTGで議論 - Cacooでのイメージ共有 - デザインカンプ - プロトタイピング - 実装してから暫く使う

コンセプトに立ち返ろう

ダッシュボードのしくじり

  • 大幅な画面構成をしてしまった→戻す

    コントラスト、メリハリのしくじり

  • 見づらい→下地とコンテンツの背景色を逆転させた
  • フォントがぼやけて目が疲れる→フォントの変更
  • wikiで整形後のテキストにメリハリがない→差し色を入れる

ちょっとずつ前のデザインに戻る?生まれてくる葛藤

  • 慣れと使いづらさ →新デザイン + 旧デザインの良さ 溶け込ませる

リニューアルの極意(1): 旧デザインの優れていたところは活かす(featuring)

眩しさの原因を調査

  • 報告のあったディスプレイを買ってまで調査
  • 背景がグレーが真っ白で緑が目に痛い

→ 実際辛い 色という色の調整した

何が悪かったか

ユーザビリティテストは、人はもちろん様々な環境でテストをするべきだった

眩しさの葛藤

  • ディスプレイによって違う
  • どの環境が最もあるべき状態なのかわからない

→眩しさは辛くて仕事にならない、これは一番ダメ P/D/T型 色覚で状態の色が見分けづらくなった リニューアル前程度に見分けられるように再調整

  • 少しずつ濃くしていった
  • 背景や文字色も更に濃く

遠目からの比較

  • 必要な情報にパッと目が行く

リリースしてみて

  • 実際暗さに対する意見はなかった
  • ユーザーからの良いフィードバックがあった

機能は削除せずに画面をすっきりさせてやりたい作業にという目的の達成

リニューアルの極意(2): 三歩進んで二歩下がれ!(ユーザーの皆さんにとってはインパクト大!)

β提供後一ヶ月経過、フィードバック二期を取られて気づかなかった問題が…

新デザイン使ってる人、少なすぎ問題(10%)→このままリリースしたら間違いなく炎上

  • ブログ
  • アプリ内ヘッダーにお知らせ
  • βリリースのお披露目イベント
  • 目立つダイアログ

答えられないと旧デザインに戻れないアンケート

  • 大きな声が上がっていたものを出す
  • どれも主観的なところなので実際どのくらい調整できているかわからないから、だったらユーザーに直接聞いてみた

アンケート結果の分析

  • 旧デザインに戻したユーザーが8%
  • 良いFBを得た→修正

→予定通り切り替えても良さそう

リニューアル後の効果

  • これからの時代にあったデザイン
  • やりたいことに集中できるデザイン
  • さらなる機能追加・改善の余地を作る
  • 嬉しい意見もたくさん

最近はA/Bテストもやっている

こちらが提供したいUIと求められているUIを比較

まとめ

  • コンセプトを持つ
  • ユーザーとコミュニケーションをする
  • 数値の計測と分析をする

質問コーナー

  • β版で出そうな問題を事前に潰すためにはどうすれば良いと、今は思いますか?
    • ちゃんといろんな環境でチェックする
    • ユーザーの多様性を考える
    • ユーザーインタビューの徹底
  • Twitterエゴサーチは毎日してるの?
    • 日常的に使うアプリのアプリなので、Twitterへの書き込みが多いこともあり、良くしている
    • 社内チャットにエゴサ専用のチャンネルが有る
  • UI改善の契約数への影響
    • 全体的な成長もあるので、確実な情報がない
    • しかし、最近はトライアルが増えていて割合的には正式登録数が減っている
  • 1年にも及ぶリニューアルへの社内の合意を得るために
    • 社内の合意を得ることは全く問題なく、ユーザーの反発を防ぐことに注力した

両者への質問

  • 辛かったこと
    • フリル
      • プロダクトオーナーデビューだったので、結果への要求とデザイン、マークアップに忙殺された
    • Backlog
      • 調整期間で、なにが良いのかわからなくなって、葛藤する
      • 自分の判断の正しさがわからなくなる
      • 自分は何と戦っているのか
  • 開発とデザインはどのように連携していたか、日程調整、QA(Quality Assuarance)的な意味で
    • フリル
      • 密にコミュニケーションを取っていた
    • Backlog
      • スクラムで、デザインは開発の1週間前に始める
  • 予想できなかったアクシデントの印象的なエピソード
    • フリル
    • Backlog
      • ちゃんとしてれば予想できたんじゃないかなーと思ってしまう
      • 毎日Backlogのことを考えていたので、わからなくなってしまった