How IT Works

プログラマーやっています。技術よりも人間学的なところが好きです。

STORES.jp(hey)に入社して10ヶ月が経ちました

背景

最近、チームの内外でSTORES.jpの入社後の記事を書くのが流行っていて、自分も最近の心境を言葉にしてみたいと思ったので書きます。

前の会社の人からも転職記事を見てみたいと言われていて、その人たちへのメッセージでもあります。 全く違う文化が東京にはあってそこにいてこういう風に感じているということを伝えられれば、少しは離れてしまったことへの恩返しになるのかなという気持ちもあります。

他のメンバーの記事はこちらです。

note.mu

note.mu

また、フリーランスの方もチームについて書いてくれました。ありがたいです。

blog.inouetakuya.info

書きたいこと

特にフロントエンドの仲間は現状の会社の仕組み、チームの仕組み、チームの雰囲気について書いてくれました。 会社の宣伝が必要なタイミングで必要な記事を書いてくれる優秀な人たちだと思います。

みんなが書いてくれたことを繰り返しても仕方ないですから、自分としてはその行間を縫うような個人的な体験について書こうと思います。

自分が体験してきたことを通じてチームの根本的な考え方だったり、あるいは技術者としての成長、転職についての思いが伝わればいいなと思います。

転職の動機

前の会社への不満は特になかったです。 給与、待遇、仕事内容、人間関係、地理的なもの諸々の全てがよかったと思っています。

ただ、どうも関東の開発者は業務ではお客さんからの電話を取らずにひたすらプログラミングに集中できるらしい、毎日勉強会をしていてすごいスピードで成長しているらしいという話を聞いてどんな世界なんだろうなという気持ちが大きくなりました。

特に勉強量はそれなりだった自信があったので、プログラミング単体でも勝負できるのかなぁというのが気になりました。

ちょうど高校時代の同窓生に会ってそういう話を繰り返すうちに憧れが芽生えて、もしその世界を経験するには今しかないと思って、転職をしようと思いました。 STORES.jp(hey)は流行りのWeb系で、前の業務エンジニアとは対照的でとてもいいなという印象でした。

会社で経験したこと

違う文化に苦戦

転職自体が初めてだったので、どれだけのレベルを要求されているかわからずに色々苦戦していたような記憶があります。 仕事の仕方について色々考えながら、他の人の一人前になるべくとにかく真似したり、工夫したりしていました。

途中参加のプロジェクトに慣れるまで - How IT Works

特に驚いたのは「仕事は自分で見つけて、自分でやりきる」という文化だったと思います。 前の会社だと仕事を工夫するということは合間の時間でやることでしたが、STORES.jpのフロントエンドはあらゆることが自主性に任せられていました。

2つの文化、2つの世界 - How IT Works

あとはSlackでほとんどの会話、コミュニケーションが完結するという仕組みが衝撃的でした。 隣にいてもSlack経由で話すということを理解するのに1週間ぐらいかかった記憶があります。

前の会社では疑問があると、すぐにペアプログラミングしながら会話していたので、電子情報で会話するという文化はほぼなかったです。

今は入社キットが整備されてきたり、積極的に新入社員にはサポートでつくようになったので、こんなカルチャーショックへの戸惑いは少ないと思います。黎明期だった気がします。

技術的な挑戦

転職の時に技術のことばかり喋っていたせいか、最初の頃は何となく技術担当みたいな仕事が振ってきていた気がします。 転職動機が技術最初の頃からKPTとかで技術面で気になるところを忖度なしに言っていたので、それならということで任されたのかもしれません。

やったのは共通コンポーネントと呼ばれるコンポーネントライブラリ作成です。 ここら辺はkskymst1さんが詳しいです。

logmi.jp

speakerdeck.com

Storybook、Webpack、Vue.js、Jestあたりの設定をごにょごにょしながら、仕事をしていました。 不安はありましたが、意外に何とかなったので当初描いていた『プログラマーとして通用するのか』という疑問について考えることはなくなりました。

デザインとの邂逅

共通コンポーネントを作っているとデザイナーと話をする機会が増えました。 ですが、自分は前の会社ではデザイナーがおらず、自分もデザインに自信がなく、コミュニケーションで一方通行になりがちでした。

他のフロントエンドチームのメンバーは割りとデザインの話をして意見を言っているので、自分ももっと対等に話したいなと思って勉強を始めたのがその次だったように記憶しています。

デザインとの邂逅 - How IT Works

デザイナーの考え方、思想を知るのはとても刺激的で勉強したのはすごく良かったです。

エンジニアはコンポーネントをまとめようとしますが、デザイナーはユーザー体験を考えて、それが良くなるならコンポーネントを増やしてもいいと考えます。 そういう発想が知れて、やっとプログラマーではなくてフロントエンドエンジニアになれた気がしました。

見積もり問題とスクラム

共通コンポーネントを作ったので、次は本格的にリプレースをしようということで動き出しました。 しかし、端的にいうと全然見積もりが当たりませんでした。数字でいうと10倍ぐらい違いました。

これは次回のMeetupで話すので、終わったら詳しく書くかも知れません。 hey.connpass.com

簡単に書くと下記のような感じです。

  • タスクの洗い出しが不十分でやるべきことが全て出ていない
  • デザイナー、バックエンドとの要求の調整がうまくいっていない
  • 数字を使わない開発者の経験で見積もりをしている

見積もりに必要なプロセス、前提知識あらゆるものがなかったと言ってもいいでしょう。

前の会社だとWBSベースだったのでそっちの方面がいいのかなという思いもありましたが、他のチームはどうもスクラムをやっているらしいので、そこからやってみてダメなら考えるということにしました。

それをやってみると、人が対面的に集まることが多くなり、上手く行くことが増えた気がします。 今まではSlack上で会話が多かったですが、フロントエンド、デザイナー、バックエンドの面々が対面で集まって、共同で同じものを見るという体験ができて、いろんな認識の齟齬が減りました。

それを企図してスクラムをやったというわけではおそらくないと思いますが、「場」ができて、それに数字を使った見積もりができるようになって、大分進歩したと思います。 大事だったのはオレオレスクラムではなく、とりあえず完璧なスクラムをやってそこから調整しようとしたことで、スクラムの恩恵をフルで受けれたように感じます。

スクラムを始めてからは結構、その仕組みの調整を頑張りました。

ルールを考える人

スクラムをやる傍ら、コーディングルール、テストのルール、あるいは新入社員向けのドキュメントを書く時間が増えました。 あとは、Meetupでdaitasuさんが話してくれると思いますが、フロントエンド全体の設計とかを考えていました。

これを見るとコーディングの時間が減って、他の人が働きやすい為に何ができるのかという視点で働いている時間が増えてきた気がします。

「仕事は自分で見つけて、自分でやりきる」という文化は色々なところにあって、コーディング、テスト、その他諸々の作業は各人の力量次第というのが個人的にはどうにも気になるし、自分一人で複数人が助かればそっちの方がチームのためになるしなぁという気持ちが大きいです。

これを見るとリーダーを志向しているみたいな感じがしますが、どうなんでしょう、今のチームは全員が似たようなことをしていて、開発だけしているという人は少ない気がします。

ただ、ドキュメントに興味を持つ人、タスク管理に興味を持つ人、コーディングに興味を持つ人、新技術に興味を持つ人がいて、それぞれが混ざり合って組織を作っているという感触が大きいです。

そもそも入社記事についても誰かに言われて書いているというか全員が自発的に書いています。後から聞いて驚くことが多いですね。

振り返って

プログラミング単体でも勝負できるのかなぁ、という疑問から始まった今の仕事ですが、この疑問についてはとうに決着がついていると思います。 振り返って見るとやっとフロントエンドの全体が見えてきて、足りないところは大分減ってきたのではないかなと感じます。

チームに関しては「仕事は自分で見つけて、自分でやりきる」に尽きて、情熱があり、守備範囲が広く、それに伴って求められる能力が多いという一文に尽きます。 入ってからずっとこの文化と良くも悪くも戦っています。

それにしても、東京のひとの情熱の大きさ、広さは本当にすごいですね。

今後やりたいこと

流れからしてこれからはマネージャーとかリーダーを目指すんだろうなぁという風に思われそうですが、別にそういった要求も必要性も感じていません。

今考えているのはルールで足並みを揃えるようにしているけど、それが通用するのは今の一瞬だけだよなぁという思いです。 人が増えて、メンバーが変わって、仕事が変わって、それでも残るものって何なのかなぁと漠然と考えます。

強いルール、強いリーダー、強いメンバーのいずれも今はよくても持続して行くものではないので、もっとあるかないかわからないような弱いルール、弱いリーダー、弱いメンバーで戦えるような何かがあってもいいのかなぁと。

今でも役割を聞かれても全部と答えるしかないような感じですし、色んな曖昧性を残しながらそれでいてしっかりとした線が通っているような自分、チーム、ルールが残って行ったらいいなぁと思います。

今まであった恩師はみんな静かで、弱そうに見えて、それでいて抑えるところは抑えていてみんなを上手く回していたので、これからは強い人ではなく弱い人を目指して頑張っていけたらなぁと思います。

めざせ老子、めざせ荘子

宣伝

フロントエンドのミートアップが近々あります。現状埋まっていますが、スライドとかも早めに公開して行くので見たら面白いかもしれません。

テーマがバラバラで人を集めにくいなぁと正直思うのですが、今考えるとうちのチームはなんだかんだ皆が何でもやるので、どうしてもこうなるんですよね。 だから、これはこれでうちのチームのあり方を象徴していて面白いなと思うのです。

具体的な技術、プラクティス、解決策はどうでもよくて、なぜそうしたのか、なにが背景にあったのかに注目して見るのが個人的には楽しいのかなと思います。個人ではなく、会社単位でそういう発表をするのはなかなかに珍しいので。

hey.connpass.com