瀬宮の球拾いブログ

エンジニアだったはずが、みんなにヘイストかける方がチームに貢献できた男のブログ

株式会社はてなに入社しました。

株式会社はてなに入社しました。

エンジニア採用するときに、地元ではスケールに限界があるので地方支社をつくろう、そこでエンジニアを採用しよう、という会社は多いです。
しかし大阪に支社を作る会社はセンスがないと思います。
なぜなら関西というのは、Bizの中心地が大阪であり、エンジニアの活動の中心は京都という珍しい地域です。つまり職種によって中心地のズレがあります。
きっと経営の意思決定をする方がネクタイを締めたBiz職で固められているとそうなるのでしょうね。
エンジニアのもつ現場感、とても大事です。

はてなは京都にあり、京都においてはこの規模だと大手、ブランド感というカンバンのパワーが大きいです。
私も今後ははてなerとして実力を発揮していこうと思います。

hitode909の日記

また退職しました(3年ぶりくらい)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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の数字をもってのタイミングになります。

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

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

ユーザーファーストis何

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

現代人は居場所が欲しい

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

例えばtwitter

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

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

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

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

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