トマルバ Lv.0 から Lv.1 になりました！

sansan.connpass.com

Legacy Meetup Kyotoに参加してきました。 元々はこのイベントでの参加ログを書くつもりだったんですがそこであった発表の中に「yahoo!で働くようになってまだ半年なんですが…」という一言に影響されてこのエントリを書いています。

ぼくが株式会社トマルバに実際に入社したのは去年の5月からなのでまだ1年経ってはいないのですが副業の開始時期が去年の2月頃からだったのでまあちょっと多めにサバ読んでだいたい1年として見積もって、いろいろなことがあったこの1年を振り返ろうと思います。

構想段階でポエムが長文になるなという感じなのでサラッと目を通すくらいの気持ちで読んでください。 （書き終えたら1万字とかいってた、ヤバい…）

イベントの参加ログとしてのエントリはまた後日気が向いたら書く…かもしれない。

ついでに告知をば。 つい最近、というかまさに昨日知ったのですがWantedlyの求人ページができていたので紹介しておきます。 残念ながらまだエンジニアやデザイナーとしての募集エントリーはないようなのですが常に人と時間とお金は無限に足らないのでもし興味があればTwitterのDMでもお知らせください。 肉か寿司が出るかはわからないですがまあ「飲み行くぞ！」みたいな感じで話すのは可能です、Skypeとかのリモートでちょい話し聞かせてくんろ！とかもOKやで。

tomaruba.me

www.wantedly.com

閑話休題。

入社前と入社後の期待とその結果

入社前に現CTOと面談していてそのときのために書いていた「株式会社トマルバに入社することでぼくが期待すること」メモがあったのでそれを元に入社前後でその期待がどうなったのかを振り返ってみます。

ぼくが当初期待していたことは大きく2つあってそれは「個人としてスキルアップできる環境か？」ということと「英語の語学力向上」を掲げていたのでまずはその経過報告から。

個人としてスキルアップできる環境か？

この「スキルアップできる」という表現が非常にふわっとしているけどぼくが当時考えていたのは開発する技術周りの向上を期待していました。 株式会社トマルバ(めんどいので以下弊社)ではサーバーサイドにRuby on Rails、フロントエンドにReact(ジョインする直前はVueだった)を採用しています。

当時からいまに至るまでぼくはあまりフロントエンドの技術にあまり興味が持てないというのもあり、苦手意識があります。犯人はだいたいIE6とかいうやつのせいです。

入社前の段階のぼくの状態としては「個人でRails Tutorialsやってる(未完走)」、「個人でVue触っている」くらいの温度感です。 プログラミング教室を出たての人よりはマシかもくらいの状態です。その当時までは主戦場がPHPだったのでね。

なので「Railsエンジニアを名乗っても恥ずかしくないレベル」であること、「苦手なフロントエンドをメインではないにせよ仕事としてこなせること」というのを期待していました。 Railsに関しては仕事としては最近あまり触れていないのですが一応「Railsの案件あるんだけど…」と言われても「ものにもよるけど出来るんちゃう？」と思えるくらいには成長できたかなと思ってます。

苦手領域のフロントエンドですがこちらはまだまだだなというのが正直な感想ではあるもののサポートしてもらえればなんとか担当チケットを（理想的なコードではないものの！）実装可能くらいにはなったなと思っています。 とはいえ長らくJavaScriptに苦手意識を持っていたせいで基礎的な部分がスコーンと抜けてしまっているのでReact入門を読んでまず基本を抑えようかなという感じです。

入門 React ―コンポーネントベースのWebフロントエンド開発

ここ最近のぼくに対して期待されているスキルとしてはマネジメントの知識、DDDのようなドメインの知識、そしてソフトウェアアーキテクチャ設計のような設計関連での知識が求められている感じです。

マネジメント(の一部権限が移譲されてるだけ)に関しては正直いままでやりたくないと思って逃げていたことなんですが逃げ切れずここ数年向き合わざるを得ない感じになってきたというのが正直な感想です。

とはいえ、マネジメントを嫌々やっているわけではなくぼくらが今目の前で抱えている問題を解決するにはプログラムだとかソフトウェアアーキテクトというレベルでは解決できないことのほうが多く、今日参加したイベントのスライドにあった「おそうじガイド: 合意」におけるステークホルダーとの合意、開発メンバーとの合意、そして更に弊社の場合はホテルの運営業務が主となるビジネスなのでその運営業務メンバーとの合意が必要になってきます。

大変。とても大変……。 (これでもまだマネジメントの一部なんだよなーとたまに絶望しそうになることがまれによくある感じですね。)

speakerdeck.com

DDDに関しては名称だけは常々…という感じだったのでまずはエリック・エヴァンス氏のDDD本を少しづつ心を折られながら読み進めています。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

一旦一通り目を通し終えてからもちこちゃん本と一緒にドメインとはなにか、どうあればよいのかを考えていきたいなという感じでいまは進めています。 とりあえず現段階の感想としてはエリック・エヴァンス氏とは仲良くなれそうにないな、ということです。

booth.pm

ソフトウェアアーキテクチャ設計に関しては現在読んでいる技術書が多すぎるの意図的に読まないようにしてるんですがClean Architectureが良書っぽい感じかつオススメされたのでDDDが一段落したらガッと読み進めてしまおうと考えています。 DDDは後回しにすると永遠に読まない感じが非常にしており、読みたいけど読めないみたいな状態になっています。ぐぬぬ。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

英語の語学力向上

良くなった点はルー大柴みたいな英語でも躊躇せずに「これは○○だからI don't careなんだよね！」とか臆面もなく言えるようになったのは成長かなという気がします。 あと発音を無駄に気にするのがマシになった気がするのもよい。

ただ全体としては期待したほどは向上してなくてこの原因は明らかでぼく自身が英語を話していないからということに尽きる。 とはいえ、いきなり話せ！とだけ言われても無理ゲーなのでまずは会話英語のフレーズとかパターンにもっと触れないといけないなと思っていてその上で単語だったり文法だったりを覚えていかないと正直モチベーションが保たない。

ということで最近英語字幕をつけてAnime Crime Divisionsを0.75倍速で毎日みるようにしています。 まずは英語の苦手意識とフレーズのある程度のパターンとイメージを脳内に意識つけるのが大事だと思ってやっています。

How we made ACD Season 2, Pt. 1

書籍としては「ITエンジニアが覚えておきたい英語動詞30」がいい感じでした。 英単語としては中学英語のときに習うありきたりな動詞ばかりなのにこういう表現の仕方があるのかと思いました。 また日本人が英語で困るときというのは多分だいたいみんな同じで教科書に乗っている例文のような英語しか思いつかないので単語がわからないと話せないということだと思ってるんですがそういう意識とかイメージをもっとシンプルなものに置き換えてくれるなという気がしています。

似たような本に「会話もメールも英語は3語で伝わります」という書籍もありますが個人的にはこちらよりも「ITエンジニア〜」のほうがしっくり来たという感じです。

ITエンジニアが覚えておきたい英語動詞30

会話もメールも 英語は3語で伝わります

成長

エンジニアとしての目にみえるスキルということであればまずRailsエンジニアとして必要最低限のレベルには到達したかなと感じています。 ただエンジニアとしての成長よりも実感している成長としては「ヒアリング能力」「Issueを察知する能力」がほぼゼロだったので経験を得て成長できたなと感じています。 これは課題図書としてオススメしてもらったユーザストーリーマッピングが大きく貢献していて、読んでから実践を何度かやったので少しずつマシになってきたなと感じています。やったぜ！

なお今まではプランナーや営業さんにお任せコースみたいな感じでヒアリングをきちんと技術の1つとしてみたことがなくて属人性の高いスキルだと思いこんでました。

ユーザーストーリーマッピング

あとデザイナーとプログラマーのみの2人しかいないチームですがそのチームビルディングみたいなことをしていて四苦八苦したのでそのあたりの能力というか知識や経験を得て成長できているなと思うことがあります。

特に良くなったなと自他ともに感じることが増えたのはヒアリング能力とチームビルディングのための知識や経験だと思っていて ここ最近だとデザイナーとうまく意思疎通ができていないなと感じていたのですが「いちデザイナーがチームビルディングのために何ができるか？藤本 貫二郎さん / レバレジーズ株式会社」というスライドに書かれていた「弱音を吐く会」というのをオマージュして(パクって)毎朝10分〜15分ほど困っていることや相談したいこと、サポートできることを1on1で話し合う時間を作って1ヶ月ほど試してみたのですが「プログラマーが考える理想のチームってどんな形？私はそれにどう協力できるの？」という質問を引き出すことに成功できたので成長できたな！と思うと同時にやったぜ！！！みたいな気持ちになりました。

note.mu

いちデザイナーがチームビルディングのために何ができるか？ from Kanjiro Fujimoto

www.slideshare.net

またどれくらいこのことが影響してるのかわからないですがCTOとデザイナーが1on1したときに以前よりも意思疎通がスムーズになっていたと報告を受けていて、仕事というくくりの中で雑談を潤滑油にしながらコミュニケーションを行ったのが影響してるんじゃないか？とポジティブな評価をしてもらえてめちゃくちゃ嬉しかったです。

なおこの毎朝のMTGによってぼくの出社時間は30分早くなりましたし、最初のほうは全く手応えがなく不安と苦痛がいっぱいでした。 「こういうのは継続するのが大事だよ」と事前にアドバイスしてくれた id:daiksy さんありがとうございます、仰るとおりでした！

入社以降にスキルアップのために始めたこと

Railsがわからない2人で開発していたのでRailsとしてのベストプラクティスを知る必要があり、その際に非常に勉強になったのがTechRachoの週刊Railsウォッチでした。 本当に頭が上がらない感じで投銭したい気持ちです。KyashかAmazonのほしいものリストが公開されてたらめちゃくちゃお菓子とか送りつけたい。

techracho.bpsinc.jp

あとはTechRachoで知ったのかAjitofmで知ったのか忘れてしまいましたが八木さんのブログエントリも気になったものや自分たちが使っているものに関係している場合できるだけ時間をとって読むようにしています。 最近はあまりできていないですがRailsに触り始めたときはどういうコードを書くのか、どういう書き方がベターとされているのかがわからなかったのでコードを読む時間を意図的に多くとっていたということもあって頻繁に目を通していました。

y-yagi.hatenablog.com

マネジメントに関してはいろんなものの影響を受けているので代表例だけ。 主にメルカリ、はてな、クックパッドのマネジメント手法や思考、思想などに大きく影響を受けています。 あとはぼくはGoolgeの文化が好きなのでGoogleにも大きく影響を受けているといっても良いかもしれません。

あとマネジメントというとかなり大仰だと思っていてぼくが四苦八苦しているのはまだ開発部署内のみでうまくチームがワークする環境とその下準備をしているという感じです。 この下準備というのは仕組み的なものではなく属人性によるコンテクストのバラつきを減らすみたいな感じで本来は仕組みでうまくフィットするようにするのがベターだなと思ってるのですが ぼくにはまだ難しいというのが現状であり、また根本的に解決したいと強く思えるだけの熱量をまだ持てていません。

あくまでこれらは「ぼくが働く上で楽でありたい」というのが動機の大きな要素であり、そのためにマネジメントの真似事が必要だし、一番効果的なので取り組んでいるという感じです。 ぼくらはスタートアップ企業で人が少ないということもあり、今後人が入ったときにいまのままだとスケールしない組織やチームになってしまうのでそういう点でも気をつけている、という感じです。

ぼくにとってこれらのチームは理想であり、今後、如何に彼ら彼女らに追いつくために頑張らないといけないかみたいなポジティブな気持ちがあります。 まだまだ山頂が遠いのですがぼくらなりの最高のチームプレイとそのありかたを模索していく上で参考にさせてもらいあわよくば踏み台にしていくぞ！という気持ちです。

tech.mercari.com

developer.hatenastaff.com

techlife.cookpad.com

マネジメントではないですが最近読んだエントリに感化されていて、こういう関係を構築できていなかったという反省とこういう関係を作れるようにやっていかないとな！みたいな気持ちになっています。

blog.sushi.money

これに対するアンサーソングがこちら。めちゃくちゃいい関係性を気づいててエモさが高まリングでした。 こういうアンサーソングが返してもらえるように振る舞っていきたいなと考えています。

blog.pastak.net

期待以上だったこと

価値観や文化のフィット

これは思いもよらなかったことという感じなのですが…。

組織、会社全体が非常にフラットで階層構造を意識することがない…というよりは階層構造を意識しないことが正しいという価値観と文化が浸透していて個人の価値観と非常にマッチしていて働きやすいなと日々実感しています。 そしてその環境はただ口開けてれば黙ってても餌が投げ込まれるという感じではなく、みんなでいろいろ工夫したり協力したりして作り上げているのでポジティブに「よっしゃ！じゃあぼくも協力するか！」みたいな気持ちになれてよいです。

その分ちゃんとやらないとそれはそのまま自分に返ってきてしまうのでいわゆるセルフマネジメント能力が重要になってくる部分が大きいです。 また会社としてのOKRやMission/Vision/Valueを現在刷新するということでよりこれらの裁量と求められるものが大きくなりそうです。

この会社の価値観や文化が期待した以上にフィットしたことは弊社に入ってよかったなと思うときにまず最初に思い浮かぶことの1つです。

プロダクトに誠実に向きあう

前職が受託メインの会社だったことも多少なりとも関係しているのかもしれないですがぼくには受託開発という仕組みではプロダクトに対して愛が感じられず、やりがいとかモチベーションの管理という面でマイナスでした。

なので転職する際に自社サービス開発であることを絶対条件の1つとして設定していました、期待するのは「プロダクトに愛が持てるかどうか」というところになるかなと思います。

実際に入ってから感じたのは「愛が持てる」ではまだ足りなくて「愛情を持って育てていく覚悟」が必要だと痛感しました。 ぼくたちが今作っているサービスは正直まだまだ足りないものだらけですし、もっと根本的に改善していきたいことなどもたくさんあるのですが「このプロダクトがどうすれば正しい成長ができるだろうか？」ということが改善案や問題が発生したときに度々議論の訴状に上がります。

「いま困っていることは○○だが本質的にこれを解決することが正しいのではなくてこの問題点を解決してもそれはただの暫定対応でしかないよね」という話が部署を問わずにいろいろなところで聞くことができます。 「プロダクトに愛を持つ」のはむしろスタート地点で「どうすれば正しく成長させられるのか？」と真摯に向き合わないといけないということが結構な頻度で発生しています。 これは非常に嬉しい状況であり、ぼくとしてこういう環境に身を置きたいと考えていたこともあって期待以上の結果が得られていると感じています。

愛を伝える

ぼくとは少し表現の仕方が違うんですが弊社CEOがことあるごとに愛という表現でHRTを伝えてくれます。 口だけ言う人を何度も見てきたので最初は正直なところ懐疑的に見ている面が半分、信じている部分が半分という感じでした。

ただ回数を、それも頻繁に目にするし口にするしまたその語り口のときの熱量も伝わってきて「この人は本気だ、ちゃんとぼくらのことに真剣に向き合ってくれている」と感じました。 またCEOは愛という言葉で「尊敬、信頼、謙虚」を表現してくれているなと感じており、四畳半神話大系の小津のような「ぼくなりの愛ですわい」というような愛情を感じています。

人間というのは単純で愛を与えられるとそれに答えたくなる面があります。 ぼくもこのCEOやCTO、一緒に働くメンバーの愛に応えたいし、応えていくぞ！という機運があり、そういう意味でも気持ちよく働けています。

やらないように注意していること

タスクに着手する前に1ステップ置く

ホテル業界って実はかなりマイナスの意味におけるレガシーさがあって、Web業界としてはもう10年も20年も前に「デファクトスタンダードだよね」という感じで定着している文化や仕組みがまだまだ浸透していない現実があります。 弊社ではSlackを使ってのやりとりが多いのですが依頼の内容に緊急度がわからないものがあり、前職のときであれば「すぐに直します！」と返答していたのですが直せるとしても調査でまず留めるように注意しています。

これは人的リソースが2人しかないのでこの手の運用に問題があったために発生した不具合や運用でなんとかできるレベルのものであればそちらで対応願っています。 結果としてこれが1ステップ置く形になり、冷静な目で対応策を検討する余地を生むことになったりして開発としては良い面が出ています。

とはいえ直せるなら直したい…みたいなジレンマは出るのでいまは我慢を強いられてるし我慢を強いていると思っているので今後こういう対応にも素早く対応できるよう仕組みでカバーしたいと思ってます。 ぼくは「運用でカバーする」という言葉がめちゃくちゃ嫌いなのでこの単語の社内での使用率を0にしたいと思ってる。

運用でカバー、殺すべし。慈悲はない。

終業後の対応は出来る限りしない

本当に緊急で他部署の業務に深刻な影響がでていない限りは終業後や休日中の対応や調査は行わないように意識的にしています。 というのもぼくはあまりこの仕事のオンオフの切り替えがうまいタイプではないので仕事とプライベートがシームレスになっている部分があります。

結果として休日に気が休まらないことによって平日のパフォーマンスに影響がでることがあり、やりたい気持ちややろうと逸る気持ちを押し付けて営業時間内でやる！ということを意識的にしています。

この休日などに意識してしまうことで平日のパフォーマンスが劣化する現象は30歳超えてから自覚したので20代だったら気づかなかったかもしれないです。

その分、業務時間で集中的に行うということを意識するようになったのでこれは結果としてよい効果をもたらしたかなと考えています。 また出来るだけ残業というものをしないように努力していて、最小のコストで最大の結果を求めないとそれをサービスにも反映できないんじゃないかという思いがあり、ぼくらに求められているエンジニアリングとはそういうことだと認識しているので「与えられた時間内で最大の成果を出せる」ようにしたいと日々考えています。

あと仕事は無限に増えるのでそうしないとパンクしちゃうというのもあるし、基本的にぼくは「働かずに飯が食えるなら働かない」でいたい人間なので性質的にもそれがあってるという感じです。

で、実際どうなの？

日々めっちゃ充実してるね！ もちろん課題は山程あるし、大変なことがないわけではない。

でも「楽しい include 苦しい」という感じで大半がいまの状況を楽しめていると実感できる日々を送っているので充実しています。 また弊社に入ってよかったと思うことの1つに成長を実感できるというのがありそれがぼくには非常に魅力的だということが言える。

以前「最近やった新しいこと」というタイトルで新しい技術や挑戦をしているということを書いていますが昨日参加したRegacy Meetup Kyotoでも同じようなことを山本寛子＠ヤフー株式会社のかたがスライドに書かれていたんですがコンフォートゾーンの外にでるのは怖いんですがそこを超えるとめちゃくちゃ気持ちがよくてそれを会社内で継続的にさせてもらってる&ちょうどよいハードルがいくらでも転がっている状況というのはぼく自身が成長したいという欲求とそれに対して求める環境というところにめちゃくちゃマッチしていて入って良かったなと思ってます。

luccafort.hatenablog.com

前職ではある程度そういう仕組が出来上がっていたことや階層構造的な組織だったことなどなどの事情からここまでチャレンジングにするのは難しかったと思ってます。 もしそれを前職でやろうとするならぼくが経営陣全員追い出して「こうするぞ！」という旗振り役にならないと難しかったと思う、少なくとも個人の裁量と権限では手に余るのは間違いなくてボトムアップだけでは不可能だっただろうというのがぼくの見解です。

そういう意味では安心して成長できる環境があるという素晴らしい状況に身をおいているなと改めて感じるところがあります。

まとめ

という感じで月ごと、下手したら週ごとに成長を感じることのできる環境に身をおいているので感謝と転職を決断した判断は間違ってなかったという思いがあります。 クソエモエントリですが、こんなところで締めたいと思います。

まだまだ成長するべきところは会社にも、チームにも、個人にもあると思っているんですがぼくらならやっていけるんじゃないかというポジティブな気持ちがあるので伸びしろしかないな！みたいな気持ちです。

もっと承認欲求を満たせるように会社でもそうですが会社外でもプレゼンス発揮していきたいなーと思ってます。 最近京都にWeb企業が東京から進出してきたり、スタートアップ企業やベンチャー企業が微増してるように思うのでもっと活気がでて若くて優秀な人に協力したり、協力してもらいたいですね。

余談

ところで最近これが気になってるので誰かください。もしくは使用感のレビューを教えてください。

アイリスオーヤマ 衣類乾燥除湿機 スピード乾燥 除湿量 5.0L サーキュレーター機能付 デシカント式 DDD-50E