また退職しました（３年ぶりくらい）

代々木にあるピクシブ株式会社を退職していました。
なぜか１２月にかけて会社の会議室をイベントの会場として使用したいという旨の相談が急増していたので私はもう代々木の会社にはいないよ、ということをここに明言しておきます。
社員の方、連絡がある場合は２つだか３つだかあるという元社員グループのどれかからご連絡ください。

在職中はBOOTHというクリエイター向けECサービスや、自社配信の広告管理システムなどを作っておりました。
またpixivのUIリニューアルにも関わっていました。

今はB2B系のサービスに関わっています。
トレンドの移り変わりで、億単位の月間PVや100万単位のユーザーを確保できないと収益的に辛い2Cサービスよりも、2Bサービスの方が今後は伸びると思っています。
もうアガってしまったサービスを作るより、これから伸びるサービスを作る方が楽しかろうということで成長期の会社に入りました。
実際楽しいです。

転職のきっかけとなったのは、ECサービスのBOOTHを作った時に、「ユーザーの気にいるサービス」を作るために、ユーザー側のマインドを理解しようと思ったことです。
自分でサービスを作り、ゼロからプロダクトを作りました。
今でも年収分に相当するくらいの売上間で成長させたのですが、プロダクトを作る過程でプロダクトマネジメントやグロースハックを学べたのは大変大きな収穫でした。 InspiredやHookedが当時のバイブルでした。
作る過程で当時はサーバサイドエンジニアだった私は、フロントやAWSの知識、あるいは各フレームワークの選定から習熟にかけてのスキルがつき、ユーザーサポートや品質保証、SEOやマーケティング、広告の運用やOKRとKPIの設定など多種多様のスキルがつきました。
今振り返ればここで大きく人生が変わったのだと思います。
しかし会社にいても、私のスキルはサーバサイドエンジニアのスキルの分しか会社に買い取ってもらえずおちんぎんも少ないままでした。だってフロントやSEOやサポートはそれぞれ専門の職種の人がいましたし、分業した方がスピードも速く品質も高いですからね。
私は新規でサービスを立ち上げるなら、分業しない方が最終的に低コストと高スピードが成り立つと思っていました。つまり一人で高速にプロダクトを立ち上げ成長させられる自分のスキルが活かせる環境を求めて転職を考えたわけです。
私自身のスキルの成長が、会社とのアンマッチを生み出したというわけです。

最終的に拾われたのは立ち上げフェーズではなく、成長期でサービスの幅を広げるにわたり各職種の橋渡し役になれるエンジニアを求めていた会社でした。それはそれで自分に合っていると思います。 また幅広いスキルを評価してくれて割とおちんぎんは多めに出してくれました。

転職したいなーと思ったきっかけは もともとピクシブはエンジニアも「サービスをよりよくするための意見を出すことができる」というのが私が入社した頃のアピールポイントだったのですが、ある時期から何を言っても「そんなことをしている余裕はない」と却下されることが相次ぎ始めた時期でした。

そうなったきっかけは
・ 「何が正解かわからない」「だからとにかく、思いつく限りよいサービスを作ってみよう」
・ 「小さく作るとインパクトが不足するから、新規サービスは十分な規模のサービスで作ろう」
という方針のもと「とにかく大技を撃ちまくれば一発は当たるだろう」という方針になってからです。

大きなプロダクトを高速で生産するために「生産性」が重視されました。そのために
・ディレクター、デザイナー、エンジニアでそれぞれ分業制が組まれ
・考える人と手を動かす人を徹底的に分業し
・エンジニアは会議の時間を減らし、席に座る時間を１分でも長くする（会議をすると時間xヘッドカウント分の工数が無駄になるという思想）
政策が実行に移されました。

その結果
・「そもそもなぜこの機能を実装しないといけないの？」という疑問が解消されないままとにかく深夜まで実装作業を続けたり
・意思決定があるのはわかったが、どういう意図でこのような意思決定があったかわからない変更があったり
・ エンジニアが機能について口出しすることが嫌われたり
・「デザイナーが作ったSketchのデザインをもとに、この画面からディレクターやデザイナーは何をしたかったんだろう？」を忖度しながらSketchからコードにリバースエンジニアリングを続ける
そんな作業が増えました。

それでいて次々繰り出されるプロダクトはmarkezinなどには記事になるのですが収益につながりませんでした。
（記事自体もお金を払って書いてもらう広告記事だった疑いもあり） エンジニアも「結果にコミット」ということで、関わるプロダクトのビジネス的な数字の部分まで目標設定に組み込まれていたため、数字があがらないと給与も上がりませんでした。

・毎晩遅くまで働かされる割に、利益が出ない。ユーザーも増えない。当然給与も増えない。
・機能リリース前の最終段階で、社員の中にいるクリエイター業をしている（見込みユーザーど真ん中の）人に触らせると苦笑いをして「まあいいんじゃないですか？」と言われる。
・これは明らかに変えたほうがいいですよ、といっても「リリース日が近い。今更変更している時間はない」と却下される。
そんな日々に疲れ果てて友人に相談したところ「まるでインパール作戦みたいだね」と言われました。

ああ、牟田口司令官の下で山ほど日本人が死んだインパール作戦。たしかに近いかもね。
そう思ったら自然と転職を考えるようになりました。

マネージャーから、「ピ●シブUIリニューアルチームはB級の戦力を中心に集めただけあって、出来が悪い」と面と向かって言われた点が最終的なトリガーとなりました。
一生懸命スケジュールや仕様のほころびを取り繕うために走り回った人間を目の前にそれを言うか、という。
ほぼ唯一の収益源のサービスの大改修をB級の戦力に任せるという経営判断も正直謎ですね。
ああ、現行UIのユースケースをほぼカバーせずに破壊しているため、ヘビーユーザーほど嫌って離脱するから方針を転換して欲しい、という話を定量的なデータをもとに求めはしました。何一つ止まりませんでしたが。
またデータ分析チームは「Google Analyticsを見る限り何一つネガティブなデータはない」として新UIを限定公開から全面展開に踏切り、恐ろしいほどの広告収入の下落に直面したそうですが、いったい彼らはGoogle Analyticsの何を見ていたのか、是非とも知りたいところであります。そのうちピ●シブ insideで報告してくれることを期待しています。
追記：ピ●シブ TECH FES2020で明かされたところではGoogle Analytics無料版とSNSでエゴサして「ヨシ！」していたそうです。現場猫かよ。

話が逸れました。
私はエンジニアの中ではビジネス志向、サービス志向が強く「テクニカル志向にあらねばエンジニアではない」という風潮が強まり始めたピクシブはもう居心地の良い場所ではありませんでした。

プロダクトオーナー祭りにおいて、プロダクトマネジメントについての発表をしようとしたところ前日に「それはテッキーな内容ではないから」と自粛を強く求められたこと、そして「業務外の活動」を理由に登壇しベストスピーカー賞をいただいたことで
「自分の志向を認めてくれる会社もこの業界には存在するが、社内ではない」と判断し転職活動を本格化させました。

いろいろあって今の会社に拾っていただき、ビジネス志向、プロダクト志向を生かした仕事ができています。
給与も倍近く上がり、満足しています。

自分の志向と会社の求めるものを擦り合わせることはきっと重要なことなのだと思います。
皆様も良い転職を。

30歳Webエンジニアのおちんぎん

30歳当時は某pクシブ社に雇用されていました。 今は雇用関係にありません。 もう2年以上経っているので、今は評価制度なども違うそうなので、時効だと考えています。 会社も給与体系もなんか昔と変わっているそうなので、今あの会社に入りたい人には参考にならないと思います。

雇用当初の説明では27万円 * 12ヶ月 + 夏冬賞与が1ヶ月分 + 住宅補助5万円 * 12ヶ月分、残業代なし裁量労働制438万円という説明でした。 なのでその額をもらっていたことになります。

そこから昇給が一切なく、時々賞与が少なかったり出なかったり、あと電車遅延とか関係なく月3回、朝10時に遅刻したら減給（精勤手当とかいうのがあってそれがなくなる。他社でもそういう制度があると聞いたのでよくあるのでしょう。社会は厳しい）で、その年は電車遅延が多く、上記の減給があり満額は出なかったですね。

裁量労働制だったので残業代はありませんでした。

昇給はマネージャーに昇格するとマネージャーのお手当が増えるので給与がもっと欲しい場合はマネージャーを目指せと上司との面談で説明されました。記録もしてます。

今求人票（ ピクシブ株式会社への転職･求人情報 ）を見たら「【賞与】年1回(6月)※業績により支給」とあったので今も私が働き続けていたら、もっとおちんぎんは低いのかもしれません。

また参考までに「※定額深夜手当（80時間分／26,000円以上）を職種手当として支給します。 」とあります。 26,000円 / 80h = 325円 なのでベースは時給1300円で計算していると思われます。時間外割増25%と深夜割増25%含めているかは不明です。 これも私の頃はなかった気がします。 だいぶ制度が変わったのでしょう。

あと住宅補助5万円/月、というと大きいように見えますが、代々木の会社オフィスから半径800m以内という縛りがありました。 代々木は家賃が高くいまの部屋の条件(RCワンルーム10平米強Not古い)で探すと高級住宅地の豊洲より家賃が5万円高く、実はそんなに美味しくなかったです。

[今の生活について]

マネージャーへの昇格なしでもおちんぎんアップありの会社で働いています。今年はおちんぎんがあがりました。 始業が遅いのに帰りも人間的な時間に帰れるのでベン・トー（スーパーでの半額惣菜争奪戦）競技という趣味ができました。 労基法についても割と守られていて、非常に不思議な感じがします。 私はサービス志向なので今の職場の方がフィットしていた気がします。

向いている会社で働いたほうが、世界は変えられるしおちんぎんも上がるしストレスも少ないのでよいと思います。 幸いにしてWebは流動性が高い業界なので、勇気を持ってジョブチェンジするのもよいのではないでしょうか。

サービスのユーザー品質を上げるために、開発チームに必要なもの

susumu-akashi.com

こちらの記事にスラック(余裕)を設けることの大切さが描かれています。

あるとき、ひどい開発をしたことがあります。
寡少な人員と期間で、過大なタスクリストの消化を求められました。
結果的に徹夜や長時間労働でリリースまでには間に合いましたが、ユーザーの評判はひどいものでした。

要するに結果だけ見て酷い言い方をすれば大量のリソースを突っ込んで、ひどいガラクタを一生懸命作っていたわけです。

さてこの開発をして学んだことがあります。
ユーザー品質にかかわることはタスクリストには乗り切りません。動くものを見ないとわからないからです。そしてそれに最初気づくのは、動くプロダクトの最初のユーザーである開発者です。
ですので、通常の場合は開発者がタスクリストにない、ユーザー品質を上げる暗黙的なタスクを認識し、消化します。
ところが過密なスケジュールは余裕がなさすぎるため、「ユーザー品質を上げる暗黙的なタスク」よりも優先度の高い「タスクリストに記載されたタスク」を消化することに全力を傾注します。結果的にユーザー品質を上げる暗黙的でタスクリストに記載されていないタスクはほぼ未消化のままリリースされるため、ユーザー品質は低くなります。
これをビジネスサイドで認知できるのは、ユーザーの悪評や暗澹たるKPIの数字をもってのタイミングになります。

ユーザー品質を上げる方法は３つあります。
１つめは開発者にユーザー品質を改善する時間を与えること。
２つめは開発者にユーザー品質を改善するモチベーションを与えること。
３つめは開発者にユーザー品質を改善するために、リソースを効率的に使える情報を与えること。

せっかく苦労して作ってユーザーに使っていただけないのは非常に残念なことです。
なにしろどれだけ苦労しようと、開発リソースがほぼ無駄になるわけですから。
あの開発を契機に、ユーザーに使ってもらえる開発を重視するようになりました。

ユーザーファーストis何

「ユーザーファースト」という言葉を最近よく聞きます。
しかしユーザーファーストとはなんでしょうか？

How Google Works エリック・シュミット という本の中でこの言葉が出てきます。

ユーザーファーストというからには「通常では1stになる"なにか"を差し置いて"ユーザー"を1stにしろ」と言っているように見えます。
では「通常では1stになる"なにか"」とはなんでしょう？

作中では「ヒッポ(かば)」という言葉で表現されています。
ヒッポとは「会社の偉い人」のことです。たとえばテレビのリモコンで、電話がかかってきたときなど頻繁に使う「ミュート」ボタンより、使わない「メーカーからのお得なお知らせ」「マイポータルへ」などのボタンが大きく目に付きやすい場所に配置されるケースがあります。
これは、ミュートボタンが押されても誰の営業成績にもなりませんが、「メーカーからのお得なお知らせ」「マイポータルへ」が押されれば偉い人の成果になるためです。
ユーザーの都合よりも会社の偉い人の都合が優先される、すなわちユーザーではなく会社の偉い人の方をむいてサービスを作るのをやめよう、ユーザーのために作ろう、と"How Google Works"は言っています。

こういうのはヒッポファースト

• コンテンツを覆い隠すように表示されるキャンペーンのポップアップ表示(きっとキャンペーンの参加人数がKPIなのでしょう)
• コンテンツを見ようとすると執拗に表示される「会員登録をしてください」「あなたの情報を入れてください」(コンテンツを見せるサービスなのに、コンテンツ表示を妨害してでもユーザーの情報を奪いにくる、"前払い"を強要する)
• 「スマホアプリをDLしてください！」(アプリはすでにインストール済なのにWebから見たせいでしょうか？)
• 「俺の考えた最高にCOOLなサービスをお前らにも使わせてやるよ」という既存のUXを無視した大幅なUX/UI刷新

それってユーザーファースト？

ユーザーファーストを掲げている会社は多いと思います。
ところで質問なのですが意味を理解していてユーザーファーストと言っていますか？
偉い人が、ユーザーの利益を損ねることを言った場合、あなたは反論できますか？
会社としてそれが支持される雰囲気はありますか？
偉い人に睨まれるのが怖いからみな黙っていませんか？

Twitterの謎仕様の正体を推測する

タイトルは若干詐欺ですごめんなさい。
小ネタサイズですがWeb開発の経験から推測します。

お気に入りは全件保持されるわけではない

これは実際にやってみるとわかるのですが、あの膨大なレコードの中から全レコードを探索するためパフォーマンスが恐ろしく悪化します。
そのため過去の一定件数に絞ってしか見せない形にすることでパフォーマンス対策をしていると思われます。

画像をアップロードすると謎の文字列に変わってしまう

一つはオリジナルのファイル名に全角文字が含まれていた場合、それを扱うのがいやなのでしょう。全角文字はいろいろやっかいですから。
もう一つはキャッシュを使っているはずですが、同名ファイルだとサーバ側のキャッシュとブラウザ側のキャッシュでそれぞれ見分けがつかず厄介なことになります。たとえば、実際には新しいものに置き換わっているのに古いものがキャッシュのせいで表示されるとか。

ユーザーに居場所を与えるサービス作り

最近流行っているSNS系のサービスは、いわゆる「バナージやリディ少尉」を満足させるサービスなんだと思いました。
ガンダムUCという小説原作のアニメがあるんですよ。それを例に使って説明します。

ガンダムUCの１巻から引用
そこで主人公バナージがヒロインに向かってこう訴えるわけです。

バナージ「初めて自分の居場所が見えたみたいなんだ。君が誰だってかまわない。必要だって言ってくれ。一緒にいた方がいいって。」

現代人は居場所が欲しい

現代人の欲求として「今の自分には居場所がない」「居場所が欲しい」という欲求を感じているのではないか、という仮説を私は持っています。

例えばtwitter

例えばtwitterでフォロワーが100人になれば、「自分の発言に興味がある人が100人はいる」ということになるわけです。
あるツイートをして100個RTやfavがつくと嬉しいわけです。
日常生活をする上で100人から褒められる、ポジティブな反応をもらえる経験はそうはありません。だからこそユーザーはtwitterにはまり込んでしまうのではないか、と考えています。

褒められたいユーザーがいつく場所

褒められたいと感じるユーザーは褒められやすい場所に居着きます。すなわち、人が大勢いる場所でかつ自分ができることをやって褒められやすい場所です。
単純な人の数と拡散力ならtwitterですし、映像における芸が得意ならyoutubeですし、服のコーディネートがうまいならiqonでしょう。

つまりそういうユーザーを獲得するには「人がいる感」「見せびらかせる感」「自分が何かやっても褒められそう感」がユーザーの獲得と定着に重要です。
事実としてそういう機能が備わっているかよりもユーザーがその期待を実感できるかのほうが１００倍重要だと考えます。そうでないと、ユーザーは居着きません。

サービスを作るときはユーザーが居着くメカニズム作りと、それをユーザーに感じさせるデザインの２つを最近は重視しています。

私がユーザー体験の仮説をたて施策をうつときにすること

前提条件として

• ターゲットとなるユーザー層に知り合いがいることが前提です。
• え、いない？　作りましょう。いないと話になりません。
• え、つくりたくない？　興味を持つつもりもないユーザー相手に商売してもうまくいきませんよ。

システムしているの？

• 検証でやることはほぼ地道なアナログ作業です。
• このあたりの作業を最後までやりきってルーチン化できれば自動化できます。
• ようするに最初はほぼアナログです。この作業に限って言えば、ディープラーニングや機械学習は「機械に任せられるフェーズが早められる」「分析する変数が増やせる」くらいの効能しかありません。

これを１サイクル回すのにどれくらいかかる？

• 約２週間〜４週間
• 1~2イテレーションくらいです。
• 施策を検証せずに打つより時間はかかります。しかし有効度が高いためこの方法を採用しました。
• 「連射性」より「命中性」を重視した施策の打ち方です。
• 大事なのは「有効弾」や「有効ダメージ」をどれだけ出したかなので、連射性を下げてでも命中率の向上にこだわりました。

やること

1.オフラインインタビュー

最初にユーザーになりえそうな知り合いに直接サービスを見せて、どう思うか？を聞いてみましょう。

• ズケズケものを言うタイプの人がイイです。
• ものを知っている「素人じゃない」人でもいいです。
• ある程度仲が良いなら、競合であってもかまいません。というか競合同士ならお互いにインタビューができます。
• 逆に、取引先とかインターン生とか、そういう利害関係にある人は向きません。こちらに気に入られようと頑張りすぎます。

言われた内容をまとめます。主に、問題点として感じている部分が中心です。

• 逆に解決策として提案されたことは直接は役に立ちません。解決策として提示された内容があれば、実際には何を解決したかったかに注目します。
• 一般ユーザーは問題に対する適切な解決策を知りません。
• 片言隻句に注目するのではなく、発言内容の傾向に着目します。注目すべき点は１０種類以下になるくらいに絞りましょう。５種類以下でもいいと思います。
• 一度に多くは追えません。コストパフォーマンスを考えて重要な奴から叩きましょう。

2.選抜インタビュー

上の内容でまとめた内容をもとに「質問」としてまとめます。質問は複数作ります。

• 「このサービスはどんなサービスだと思いましたか？」
• 「〜〜するときに探しづらいとか思いましたか？」
• 「〜〜しようとしたときに、ちゃんと予約するところまでたどり着けましたか？つけなかったとしたら何が問題ですか？」
• 質問の回答を通じて「ユーザー体験の課題」を検索することが目的です。

質問は選択形式が２、３個、あとは自由記述式がよいです。回答はGoogleフォームでいいと思います。メールベースでも長々書いてくれる人はいます。

• このサービスの第一印象として、どんなサービスだと思った？は私なら絶対入れます。
• たとえば「このサービスを一言で言うと」の部分は運営側とユーザー側で印象は一致しているか？
• 「旅行を比較しながら旅行の予約できる」サービスだとして、「旅行を予約するサービス」だと直感できた？「選ぶ楽しさ」は感じられた？という質問は入れます。
• 作っている側が感じて欲しい部分は「本当に伝わっているか？」はシード段階で検証すべきです。そうでないと伸びません。伸びが止まります。

回答者の選び方

• 「お気に入りリストに大量に登録している」「アクティブに使っている」「滞在時間が長い」というようなヘビーなユーザーを選びます。
• 比較的リテラシーが高く、回答するモチベーションも高いからです。回答する可能性と有意な回答を返す可能性が高いです。

3.少量データチェック

• 選抜インタビューで得られた「ユーザー体験の課題」が本当に正しいか？という点を調べます。検証方法はDBに直接SQLを投げたりスクリプトを走らせたりして収集します。
• いきなりビッグデータ検証はしません。
• 地道かつ不定形な作業になります。
• コスト的に総当たりで調べられないので、調べるには絞りこむためのドメイン知識が必要になります。

目的は２つ。

• 一つは検証方法を確立すること。何を見たら課題の検証ができるか？がわからないと検証の意味がありません。
• もう一つは「回答者が主観的に感じた課題は実在するか？」の検証です。ユーザーが主観的に感じているストレスの原因はユーザーが主張している内容とは異なっている可能性があります。間違った原因を調べても無意味です。

ユーザーの主張する原因に一致する結果が得られない場合

• ストレスを感じている原因は別にある可能性があります。
• アンケートの質問が悪かったのか、ユーザーの認知がゆがんでいるのか、実際には背後に別の問題が隠れているのかを調べる必要があります。

4.大量データチェック

• 上の少量データチェックで有意な仮説検証方法を見つけられた場合に遷移します。
• 「時間をたっぷりかけて調べてみました、よくわかりませんでした。」にならないように基本的にこのフェーズは有意と思われる仮説検証方法を見つけてから移ります。
• 「なんかの参考になりそうな数字」にならないようにしています。
• Google Big Queryでも Hadoopでも Treasure Dataでもお好きなものをどうぞ。

5.自動データ取得

• 大量データチェックでユーザーの挙動を象徴する指標をとります。
• 「施策の効果を測定するための、短期的に監視する数値」は特に監視対象です。

施策実施

• インタビューから時間をかけて検証した仮説をもとに、施策を打ちます。

1.施策の策定と実装方法の立案

• ProttやSketchにおこすまえにペーパープロトタイピングで設計します。
• これは意図やプランをメンバーにも考えさせることで、あとあとのマネージメントコストの低下を狙います。
• 実装者の深い理解は必須です。作っている人間が理解していない意図が、ユーザーに伝わるわけがないからです。
• しかし「理解しろ」の掛け声だけでは解決しないため、実装者にもこのフェーズに参画させることで理解と動機を植え付けます。

2.プロトタイプの検証

• 上で作ったプロトタイプを使って検証します。
• 検証は複数タイプでやります。本命は事前に決まっていても、対抗馬から思わぬユーザーの理解が引き出せる可能性もあります。
• また「対抗馬はなぜ敗れたか？」を理解させることは次回以降の時間の節約になります

実際の検証方法

• ユーザー体験は本当に解消するか？という点はUXデザイナーとそれ以外の素人(チーム外の同僚がいい)を使って検証します。
• チーム内の人間はほぼ隅から隅まで知り尽くしているため、施策を打てば敏感に反応しますが、素人の場合情報の洪水に流されて期待と異なる行動をとったり、挫折したりします。
• 重要なのはユーザーの大半は「怠惰で士気が低く観察力が低い」という点です。偏差値５０以下のユーザーが使えることがヒットサービスの条件です。
• なのでちょっとぼやっとした感じの人の方がテストには向いています。
• 集中力が低下する朝イチか、昼食直後がオススメです。

3.デザイナーによるデザイン

• この段階でようやくデザイナーがデザインします
• 一番最初にこのフェーズを経ないのは、「目に見えるものがないと人間は考えづらい」ので事前に検証をしたいからです。
• デザインの後に最初の検証をかけないのは、仮に「これってよくないのでは？」という疑問が出たときに「必死に考えたデザインを否定された」デザイナーは抵抗を感じますし、実装者は「なぜこれがよいのか」という説明をされていないため「上からふってきた」ものとして感じるからです。
• この２つの感情は「チーム内の軋轢」と「他人事感」を生み出していまう原因になります。

4. 実装

• 上で実装者を施策の実施意図まで含めて 説明しているためこのフェーズはスムーズに進みます。

5. リリース

• 触ってみて、これで大丈夫か？という確認をします。
• 直前まで触っていた人間は親のひいき目がでるので、この段階でも「チーム外の同僚による検証」を入れるのが望ましいです。

6. 検証

• ちゃんと効果は出たか？
• 副作用はなにが出ているか？
• この２つは検証します。問題なければこのまま続行します。
• もしまずかったときにすぐに引っ込められるようにリリースサイズは小さくするのが望ましいです。