業務委託古参が estie について語ってみる

f:id:estie:20220106140941p:plainestie 業務委託3年生の上水流です。

普段はエンジニアとして、estie 以外でもいくつかの企業で働いています(すべてフルリモート)。

気づけば社員を含む estie 参画メンバーの中でもかなり古参になってしまい、あるミーティングでは自己紹介をした際「もうヌシじゃないですか」とまで言われてしまいました。

今回「Advent Calendar 書かね?」という強い圧を受けましたお話をいただきましたので、古参らしく「estie でこんな働き方してきたよ」を語ってみようと思います。

書くこと

  • 参画、そして混沌へ

  • 印象的だった出来事

  • 業務委託から見た estie

書かないこと

  • ビジネス的なあれこれ

  • 技術的なあれこれ

estie のメンバーが他の日にたくさん良い記事を書かれているので、そちらも合わせてご覧ください。

参画、そして混沌へ

きっかけ

2019年、当時 estie にいたインターン生が、社内のメンバーに私のことを推してくださったことが始まりでした。

そのインターン生とはもともと別の会社で一緒に働いており(私は業務委託)、縁あって estie で働くことになりました。

そして参画

まず衝撃を受けたことは、開発状況が色々とカオスだったということです。

デプロイは手動で実施、コードの方針も決まっておらず品質が担保されていないなど、とにかくルール化がされていないものが多かった印象です。

そのため、参画当初は

  • CI/CD を利用した自動リリース(これは後述します)

  • linter / formatter を導入してコード品質を担保

  • Ansible を使ってサーバ構築手順を IaC 化

のような、アプリケーションの「コードを書く」以外のところを色々やっていた記憶があります。

スキル不足

これはネガティブな意味ではありません。

せっかくチームで開発しているのに、詰まったときにフォロー可能な環境ではないという印象を受けました。

当時アプリケーションエンジニアはほとんど副業での参画だったので、同期的なコミュニケーションが取りづらかったのが大きな要因だったと思います。

レビューもあまり機能しておらず、テスト環境に反映してようやくバグに気づく、みたいなことも多々ありました。

せっかくユーザにとって有益な機能をスピーディーに提供できても、バグだらけで業務ではまともに使えないとなっては元も子もありません。

そういう問題もあり私がレビュアーとして参加したのですが、テキストだけだとうまく伝えられなかったりといった問題もあり、「チームとしての技術力」はなかなか上がらなかったように思います。

印象的だった出来事

終わらないリリース作業

これは先の話の繰り返しになりますが、参画当初は青木さん (@kirin_shi) が「夜間アクセスが無い頃」を狙ってリリースしていました。

もちろん人力なのでミスが起きることもありますし、(リリースに含める内容によっては前提が不足していたりなどで)手順通りにやってもうまくいかないといった問題もあったようで、結果的に徹夜した…といったこともあったようです。

そこで CI を導入して、特定のイベント (master ブランチへのマージなど) をトリガーにして自動でリリースされる仕組みを導入したのですが、とにかくこれに感謝されました(社内的には「そもそも CI とは?」という感覚だったようなので、「すげえ!!」ってなっていたようです)。

私はたまたま別件で使ったことがあったものの、まだまだ手探りな感じも否めなかったので、「役に立って良かった」と同時に「実際のプロダクトへの導入を通して自分の理解も深まり有り難かった」という思いが強かったです。

有無を言わせぬ巻き込み

首を突っ込めば何でもやれました(というか首を突っ込まなくても事あるごとに引っ張り出されました)。

参画後は以下のように色々なチームに参加しましたが、どちらかと言うと「助けてほしいからとにかく呼んでおこう」という温度感で呼ばれることが多かったです。

2019/11〜:estie【物件掲載数No.1】|オフィス探しをシンプルに。 開発チームに参加

2020/09〜: estie pro 開発チームにも少しずつ参加

2021/06〜: データパイプライン改善チームにも参加

2021/09〜: SREチームにも参加

私自身色々なことに首を突っ込んでいくタイプだったので、この働き方は結果オーライでした。

参画当初は兼任メンバーがいるのが当たり前でしたが、現在はユニット制をとっていることもあり原則1人1ユニットになっています。

ただ、私自身はどのユニットに属しているのかよくわかっていない(今日はAチームのタスク、明日はBチームのタスク…みたいなことを普通にやっています)ので、ちょっと特殊な気もしています。

安心してください、実在しますよ

参画から丸2年が経った先月、ついに estie のオフィスを訪問しました(人生初の東大訪問でちょっと圧倒されました)。

普段やりとりすることが多いエンジニア陣はもちろん、他の職種の方たちともお話できたのはとても嬉しかったです(オンライン通話時もほとんど音声だけで参加していたので、「上水流は実在しない説」もあったようです)。

ただ、オフィス到着が夕方になってしまったこともあり、オフラインで一緒に仕事する時間がほぼ取れませんでした。

次回訪問時はオフラインで仕事する時間をもう少し増やせるようにしたいなと思っています。

業務委託の立場から見た estie

面白かった・興味深かったこと

スタンプ

estie の Slack には多数のスタンプがあり、大体どんなシチュエーションでも良さそうなスタンプが見つかります。

業務委託で参画した企業はそれなりにあったものの、ここまでスタンプを多用している企業は初めてでした。

中には意味がよくわからないものもあり、先日オフィスを訪問した際にいくつか教えていただきました。

個人的には「〇〇まだ?(〇〇は人の名前)」スタンプが大体全員分あるのが面白かったです。

あとはお酒を飲むメンバーが多いこともあり、酒関連のスタンプが多いです。

f:id:estie:20211223153406p:plain
酒にまつわるスタンプ

GitHub のコメントも Slack に流れてくるので、私もコメントで :yosasou: と打って Slack にスタンプを表示する、みたいなことも結構やっています。

f:id:estie:20211223153648p:plain
:yosasou:

estie values estie には 4つの values があって、毎月キング/クイーンを決めるという取り組みを行っています。

詳細はあまりよくわかっていませんが、普段何気なく押したスタンプがそんなところで役に立っているのかと思うとちょっと楽しくなりますね。

f:id:estie:20211223153806p:plain

チーム開発ならではの面白さ

技術的には、業務委託含めいろんな経験をしたメンバーが集っていることで、自分が気づかなかった視点を知ることが多々あり、刺激的に思っています。

業務委託メンバーの働き方については、以前公開された Nari さんの記事をご覧ください。

inside.estie.co.jp

私はフリーランスということもあり、チームビルディングをはじめとした組織的な取り組みの経験が多くないので、日々 Confluence や Slack を読んで勉強させてもらっています。

副業メンバーが次々社員に

また、副業として参画していたメンバーが気づけば社員になっていた、というケースがかなり多かった印象です。

月並みな表現なのかもしれませんが「estie で働くことの魅力」がしっかり伝わった結果なのかなと思っています。

私もお誘いいただいたのですが、

  • 状況的に複数企業での稼働を減らせない

  • 大阪を離れることを考えていない(estie はフルリモートが出来ない)

などの理由で一旦お断りしました。

ただ、「あくまでも現状は難しい」なので、いずれこの状況も変わる日も来るかもしれません。

SQL 勉強会

面白かったのは、エンジニア以外のメンバーが SQL を学ぶ時間があるということです。

機能の利用状況やユーザデータを分析するにあたり SQL を覚えて損は無いのですが、これが勉強会として成立していて運用メンバーが能動的に取り組んでいるという光景は他企業ではなかなか見られるものではないと思っています。

ついにはプログラミングする方たちまで現れました。

qiita.com

まだまだ良くなると思うこと

ドキュメントも書くだけでは負債と同じ

前述の通りカオスな状態を解消するため都度ドキュメント化されるようになり、(エンジニアに限らず)日々 Confluence にノウハウが集約されています。

一方で、集めたものを活用できているかというと、そこはまだまだなのかなという気がしています。

ぱっと思いつくだけでも、例えば以下のような問題があげられます。

  • タイトルや紐付けるツリーのルールが曖昧なのでそもそも目的のページを見つけられない

  • 「前に誰かが書いてた気がするけど…」「見つからないし書くか」→重複したページができる

  • 機能や使い方が新しくなった場合に追従できていない

estie では 2021/10 から fixit (負債解消)期間を設けていますが、これはプロダクトやコードだけでなく Confluence などドキュメントについても実施していけるのではと思っています。

安定した基盤を

開発メンバーが増え、アプリケーションについては安定稼働するようになりました。

一方で、システムを支えるインフラ面についてはまだまだ課題が山積みです。

SRE チームは半分以上が副業メンバーなので、インフラ周りにおいて有事の際には :shin: へ頼りっきり、みたいなことが多いです。

前述の通りアプリケーションが安定稼働してきたからこそ考えられる問題なのかもしれませんが、estie にとっての最良の解を一緒に考えるのも私のミッションのひとつかなと思っています。

終わりに

色々書かせていただきましたが、私自身は estie で得られるものが多いと感じているので、今後も自分ができる精一杯の貢献をしたいと思っています。

この記事を読んで「estie 面白そう」と思っていただければ幸いです。

是非一緒に働きましょう。

www.wantedly.com

© 2019- estie Inc.