この記事は エンペイアドベントカレンダー 22日目の記事です

こんにちは。株式会社エンペイで開発部門のマネージャーをやっております木村(@nakir323)と申します。

私は2021年5月にエンペイに入社しました。当時自分は一人目エンジニアとして入社したのですが、そこから2年半ほど経って色々やってきたなぁと思い、アドベントカレンダーという良い機会をいただいたのもあって、振り返ってみようというのがこの記事です。 思い出話をつらつら書いている記事なので冗長です。し、ためになるかは分かりません。が、よければ見ていってください🙇‍♂

時系列でざっくり振り返ると大きく以下のようなことがあった気がします。

これ以外にもでかめの機能追加だったり、色々奔走した覚えもありますが、これだけでもそれなりに盛り沢山ではありますね。 早速、思い出していきましょう。

2021年5月、株式会社エンペイに入社しました。会社としてはちょうど業務委託の方に開発を頼っていたところから、正社員を増やしていこうとしていた時期です。自分はその中で一人目エンジニアとして入社しました。（実は同じタイミングで3人入社しているので一人目タイがあと二人います✌️） 当時、「webアプリケーションのフロントエンドが余命半年だから助けてくれ」とCTOの田野から言われ、「やったるで〜👍」と思い入社したことを覚えています。

スタートアップらしいワイワイ感を味わいたいというのと、将来良い履歴書を書けそうだと思ったのが主な入社理由なのですが、現時点でそれは満たされており良い判断だったと思えています。

そして、入社してすぐ「余命半年のコードの命を救う」タスクが始まります。

対象となる製品はRuby on RailsとVueで構成されていました。とはいってもキレイにフロントエンドとバックエンドで分割されたSPAになっているわけではなく、MPAだけど一部htmlの構築にVueを使っている、というような形でした。

自分はそれまでRubyもVueも触っていなかったので、そのあたりの勉強から始め、問題があるというフロントエンドのソースコードを読み込みました。そして、聞いていた負債についての調査を始めました。その調査をする中で感じたのは、「皆負債がたまっているとは言うものの、何が負債なのか明確ではない」ということでした。 そのため、噂に聞く問題箇所を1つ1つ丁寧に読み進めることで更に調査を進め、ある程度どういった要因でコードの保守性が下がっているのかを突き止めることができました。具体的には以下のような点です。

これらを修正すればかなり見通しが良くなるだろうと考え、1つずつ修正していきました。

今思えば本当に泥臭い作業でした。1つ1つメソッドを見て、悪さをしているかしていないか分類して、悪さをしていたら対処して...。

また、ビッグバンリリースを避けるために、できるだけリリース可能な単位に分割し、末端から少しずつリファクタリングしていきました。

...少し話は逸れるのですが、こういった見通しの悪いコードのリファクタリングをする仕事について、以前の自分はあまり前向きに捉えていませんでした。なんとなく面倒だし、他人の尻拭いをただやっているような感覚だったからだと思います。でも今は違っていて、なぜならリファクタリングが難易度の高い仕事だと思うようになったからです。こういう考えになったおかげで、誇りを持ってタスクに取り掛かれるようになりました。

話を戻してリファクタリングの案件ですが、なんとか少しずつ対応して、リリースして、完了させることができました。かなりコードの見通しもよくなり、どこに何が書いてあるか、次に機能追加するときはだいたいどのあたりに書けばよいかも判断しやすくなり、また不具合の原因調査もやりやすくなりました。 数ヶ月かけて1300行ほどあった神.jsも60行くらいにスッキリさせることができました。いやーめでたし、めでたし ☺️

さて次は既存製品のリニューアルの案件がスタートしました。簡単に説明すると、製品におけるメイン画面のUIを変更する、というのがリニューアルの案件です。ブラウザで請求を行う製品なので、請求対象者を選んで請求内容を入力し、請求ボタンをポチッと押す、そういった画面です。

この製品ですが、既に開発を始めてから2年半以上が経過していました。そこまで多機能な画面では無いものの、初期のデザインをベースにつぎはぎで機能追加をしていたので、使いにくい部分が各所に出てきていました。それを改善するためのリニューアルです。

こういった大きめのリニューアルにはデグレの恐怖がつきまといます。が、上記のリファクタリングを行った今、何も恐れることはありません。（仮に上記をやっていなければリニューアルは不可能でした）

どこかを修正すると何も関係ない遠くのどこかがバグってしまう、ということは無い状況だったので、正確/着実に進めていきました。デザインについてはデザイン会社さんがあげてくれていたものをベースに、使っていたフレームワークで簡単に実現できる範囲でよしなに落とし所を見つけ、CTOやエンジニア（一人目タイ）と一緒に進めていきました。

また、大きな変更となったため、社内の調整は必須で、営業の方に意見をもらったりCSの方に説明会を実施してもらったりと全社的なプロジェクトになりました。協力してもらった皆さんには本当に感謝です。

ビッグバンリリースを避けることはできませんでしたが、無事にリリースされ、大きな混乱もなく終えることができました 🎉　うーん、めでたい 😄

開発業務と並行してフローの整備も行いました。具体的にはスクラムを導入しました。

守破離の守からということで、デイリースクラムやレトロスペクティブといった基本のイベントの整備から始めました。一部、既に運用されていた全社を巻き込んだ機能お披露目会？みたいなものとスプリントレビューの噛み合わせが悪かったのでそこだけカスタマイズしてとりあえず走り出しました。ツールはJIRAを導入し、スムーズにスクラムに従って開発を行えるようにしました。

スクラムについて、自分は前職時代に外部の研修でみっちり勉強したこともあり、ある程度知識はあったのですが、当時のメンバーはあまり知らない人が多かったので、開発チームに向けてミニスクラム研修のようなこともしました。ちなみにこのスクラム研修は、営業CSといった開発以外職種の方向けにも行いました。開発部門がどのように仕事を進めているか知ってもらう良い機会だったかなと思っています 🙂

スクラム導入においては、「タスクに人をアサインしない」ことを徹底しました。つまり、タスクと人を1:1で対応させないということです。もしそのタスクを最初に一人で実装していたとしても、途中で複数人で取り掛かる方がチームとしてパフォーマンスが上がるならそちらの方が良いはずです。個人の成果ではなく、チームの成果を最大化するにはどう動けば良いかというのをチーム皆で意識して開発を進めていきました。

この考え方は今でも続いており、また弊社開発部門全体にある優しい雰囲気の基礎となっている考え方だなと感じています。これからも良い雰囲気で生産的に楽しく開発できると良いですね 🤗

各種開発と並行して採用活動も行っていました。初期はやはり主にリファラルですね。自分も他のメンバーもリファラルに奔走し、何人か入社してもらうことができました。 私も3人リファラルで入社してもらい、今でも一緒に働けています。ありがたや。

その後、規模が大きくなってくると、リファラルだけではなく採用媒体を使った採用活動も行うようになりました。人事の経験豊富な方と二人三脚で、どのようにスカウトを送るか、どの媒体を使うか、どの媒体だとうまく採用に繋げられそうかなど数値を見ながら進めていきました。個人的にも50人以上の方とお話をすることができました。

採用の面談や面接については、対等な立場であるという前提で臨み、またできるだけ素早くかつ真摯に対応をするというスタンスで行っていたためか、ある程度好評を得られていたのかなと思っています。

自分が入社したときは3名だったエンジニア組織も、今では13人ほど（QAエンジニア、デザイナー、PdMを含めればもっと多い）となりました。わいわい。🙌

人が増えてくるにつれて、「自分たちにとっての正しい振る舞いは何なのか？」という疑問が出てくるようになりました。なんとなくの感覚でこれを感じ取り、当時のメンバーについて言えばうまくワークしていたものの、これが長続きするイメージはありませんでした。また、今後さらに人が増えてくるときに、予め自分たちのカルチャー（何が正なのか）を候補者の方々に伝えることで、ミスマッチを防ぐこともできると考え開発チームのカルチャーを策定することにしました。 カルチャーと雑に表現してしまいましたが、イメージとしてはかなり広めの概念を想定していました。例えば細かなワーキングアグリーメントのようなもの（例：PRのレビューは最優先でやろう、とか）は少しずつ準備されてきていたので、もっと広い範囲での、仕事におけるスタンスのようなものを言語化することにしました。

このときは、トップダウンで決めて作るのではなく、既になんとなく皆が意識しているものを言語化する形でカルチャーを策定していきました。当時、会社としてのミッション・ビジョン・バリューが策定されていなかったため、とりあえず開発チームの皆にどういうことを考えているかをヒアリングして決めていきました。

最終的に3つに絞り、さらにそれを短く表現しSlackの絵文字に落とし込んでカルチャーの定着を図りました。具体的には以下の3つです。

結果として3つ中2つは絵文字もかなり使われて定着していきました。1つめの「作るものの...」についてはうまく使いやすいSlack絵文字に落とし込めなかったのもあってあまり絵文字としては定着しませんでした。とはいえ当然のように皆意識はしていたと思います。

その後、会社全体としてのミッション・ビジョン・バリューが作られ、そちらにマージされていったので上記の3つは使われなくなりましたが、今でも良いカルチャーだったと感じています。😊

既存製品の保守をしていると、社として非連続な成長を遂げるための第二の矢として新規webアプリの立ち上げの話がやってきました。 具体的に言うとこれですね。

当時自分を含めたエンジニア4人でこれを作ることにしました。技術選定やアーキテクチャ決めからチームで行い開発しました。

4人エンジニアがいたのですが、作るものを考えたときに、フロントエンドの方が軽そうだという話になり、自分が一人でフロントを担当することになりました。（なので残りの3人がバックエンド）

それまでReactは使ったことはありませんでしたが(AngularとVueはある)、社内で既に利用されていたVueでつらいという声があったのと、自分がReactに挑戦したい気持ちもあったのでReactを使うことにしました。 開発が始まってから軌道に乗るまではかなりしんどいところも多く、頼れる人もいなかったためメンタル的にズーンとなっていた時期もありましたが、徐々に想像した通りのものがスラスラ作れるようになってからは快適なReactライフを送ることができました。

作るものについてはPdM陣がかなり機能を絞ってくれたので非常に助かりました。やはりPdM含めたチーム全員が、リリースに向けて作業できていると強いですね。「最悪ここは手作業でも良い」といったことまで考えてくれていて頭が下がる思いでした。

開発終盤において、バックエンドは完了の目処がついてきたけど、フロントエンドのみ遅れそう、という自分が全体のボトルネックになりそうな状況になりまして、そのときは非常に焦りました💦チームメンバーには迷惑をかけましたが、MTGを少し減らしたり、自分じゃなくてもできるものをバックエンドメンバーに任せることで業務を調整してなんとかスケジュール通り完了まで持っていけました 😌

このプロジェクトで非常に素晴らしいと思ったかつ、自分でも初めての体験だったのが、それなりの規模の開発がオンスケで完了したことでした。恥ずかしながらしっかりオンスケで何ヶ月もかけたプロジェクトが完了することはこれまでなかったので驚きでした。詳細については以下のブログでも語られています。

オンスケで終わらせられた要因はまとめると以下の2つかなと自分では思っています。

やはりエンジニアがどう頑張っても無理なプロジェクトってあって、そう考えるとやはり優秀なPdMの方と働けるのは非常に幸運なことなんだと思いました。

エンジニアもPdMもQAEもデザイナーも、その他関わった人みんな頑張りました。お疲れ様でした。🙇

上記のプロダクトをリリースして少し落ち着いた頃、面接に関する課題が挙がりました。雑に言えば、「雰囲気で面接やっちゃってる問題」です。 具体的に言えば、人によって質問や判断基準がズレてしまっているのでは？面接官の質がばらついているのでは？といった課題が挙がるようになりました。

以前から少しずつ上記のような課題は挙がっていたものの、なんとかワークしていたので後回しになっていましたが、面接の数がどんどん増えてきていたことと、自分が少しこの件に時間を割けそうというのがあり、本腰を入れて対処することにしました。

まず最初にやったのは、そもそもどういった面接をやれば良いのかという調査です。幸いこれは少しググれば「構造化面接」というキーワードにたどり着くことができ、それを調べていきました。具体的にはGoogle re:Workの構造化面接のページを読んで、これをベースに作っていきました。

やはりその中でも一番大変だったのは面接で使う質問の作成です。これは本当に大変でした。

面接でどういった質問をするのが良いかを考えようとすると、もちろんその前段となる「何のために質問をするのか」「そもそもなぜ面接をするのか」さらには「そもそも方法として面接が最適なのか」といったことまで遡って考えることになります。 ですから、そもそも方法として面接が最適なのか？といったところから順に考え、面接の役割を定め、その役割に沿ってどのような質問をすべきかを考えていきました。

また、エンジニアの「スキル」とは一体なんなのか？ということについても深く考えさせられました。当時はこれをいくつかに分類し、その中でもエンジニアとして重要な「技術的な思考力」に面接ではフォーカスすることにしました。 「技術的な思考力」の定義や意味、構造についても、「思考・論理・分析」や「思考力の地図」といった書籍を参考にしながら、どういった切り口で判断していけば良いのかを考えていきました。（かなり細かく考えたのでこれの詳細もどこかで話したいなぁ...）

質問の作成以外にも、面接のフローの決定、プロジェクトチームの組成、あとは継続的な改善が行われる仕組みの構築を行い、全体的には4ヶ月ほどかけて形にし、手離れすることができました。

あまり普段エンジニアをしていると使わない脳を使った気がして、非常に難しくもやり甲斐がありましたし、純粋に楽しめた仕事でした。 自分も楽しくて会社の仕組みにも貢献できて、いいことばっかり。良かった良かった。😊

第二の矢が放たれたしばらく後にやってくるのは第三の矢です。当然です。次はモバイルアプリ開発の話が舞い込んできました。

まずはチームを組成します。ですが、社内にはなんと業務でのモバイルアプリの開発経験者がいません❗困りました❗自分はなんとか以前個人でモバイルアプリをリリースしたことがあります。以前にも立ち上げを経験していますし、そうなったら自分がやるしかありません😡 他にも、モバイルアプリ作ってみたいぞ！立ち上げやっていきたいぞ！というメンバーたちと一緒に開発を始めました。

結果からいきましょう。なんとこのプロジェクトもリリースにしっかり間に合わせることができ、遅延なく（リリース予定を変更することなく）お客様のもとに届けることができたのです🎉

これも、上に書いた新規webアプリの立ち上げと同様で、PdMの方に本当に助けてもらいました。「エンジニアには作ることに集中してもらって、決め事や調べ物はこっちでやります！」というスタンスでいてくださったので、こちらは実装に集中できましたし、また本当に最低限の機能に絞っていただき、あとは機能の仕様について質問しても瞬時に回答してくださって、待ちが本当に少なかったのが成功の大きな要因だったと考えています。

実装の話でいくと、技術としては新規webアプリのときと似たようなアーキテクチャを採用しており、社内でたまった知見を使いかなりスムーズに実装できた記憶があります。また、こちらのモバイルアプリ実装によって得た知見を上記のwebアプリのチームに共有したこともあり、良いシナジーが生まれているのを感じています。

スケジュールについて少し補足すると、実はビジネス上の理由から設定したタイミングには間に合ったものの、エンジニア内で開発初期に立てた目標のスケジュールからは少し遅れてしまいました。この理由は、ひとえにエンジニアのモバイルアプリ実装の経験不足による見積もりミスだったと考えています。

webアプリの感覚で見積もりをしていたところ、特にAndroidアプリリンク/iOSユニバーサルリンクの周辺での工数増加が著しかったです。また、画面数が思っていたよりも多かった箇所などでも予想よりも工数が増えました。（例えばヘッダー/ディテールを表示する画面について、webアプリなら1画面で済むけど、モバイルアプリだと画面が小さいのでヘッダーとディテールは別画面に分けないといけないよね、とか）

そんなこんなでリリースを迎えたこのアプリですが、今もどんどん機能追加を行い改善を行っています。利用も増えてきており、嬉しい限り。いい話だ‼️

今まで書いていた内容がだいたい2023年10月頃までの話です。そして自分はそこからマネージャーになりました。あまりソースコードを書かない仕事になるのでそれなりの葛藤がありましたが、今ではその迷いもなくマネージャー業に邁進しています。

今も既にそうなのですが、これからは更に今まで自分が経験したことない業務が待っていると思います。ですが、新しい経験だと思って楽しんでやっていく所存です。

思ったよりもかなり長くなってしまいました。そろそろ終わりにしようと思います。

このブログが、スタートアップに一人目エンジニアで入るとどうなるんだろう... と思っている人の好奇心を少しでも満たせたなら幸いです。

ご高覧いただきありがとうございました。