こんにちは。
株式会社Beer and Techで開発側のPdM（プロダクトマネージャー）をしております、新原です。1号社員として入社したあと、ずっとエンジニアとして事業に関わってきました。RailsやGithubを使ってお仕事するのが初めてだったので、最初にLGTMを頂いたときは気持ちが盛り上がったことを今でも思い出します。

新原 大介　略歴
SIerにて業務システム開発を約7年間経験したのち、お手伝いさんとして「スマート予約」の開発に参加。その後「株式会社Beer and Tech」に入社し、観葉植物とフラワーギフトのECサイト『HitoHana（ひとはな）』の立ち上げから関わり、今はエンジニアリングマネージャー兼メンバーとして働いています。
技術負債をや仕様のカオスと一緒に戦ってくれるメンバーを募集中です。まっとうに頑張ってるRailsエンジニアチームを作って、世間から認知してもらうことが夢です。

株式会社Beer and Techについて

さて、そんな私が働く弊社ですが 『スマート予約』というサービスから始め、エンジニアを中心に集まっていましたが、胡蝶蘭の通信販売へピボットして、観葉植物、フラワーと広げていき、最近はお花の定期便というサブスクリプションサービスに広げていっている会社です。
オペレーションサイドはお花が好きで仕方ない！という素敵なメンバーが多く集まっていますが、ピボット時点では『ビジネスとテクノロジーの力で、古い産業の未来をつくる』というミッションを掲げていました。（今も掲げています）

弊社代表の森田を中心に、優秀なメンバーが揃っており『お客様から考える』『思いっきりやる』『最高のチームを作る』というValueのもと、働いていており、次の様な素晴らしい文化があります。

• 課題があるとき自分や自部署の都合だけで解決策を決めず、お客様や他部署の事を優先して考える
• 誰かが失敗したときに責めずに原因と対策に焦点をあてる
• 立場の違いで人を蔑んだりしない
• アルバイトさんでも経営にかかわる数字を見られる様になっているくらい情報が透明化されている
  こういうところが会社の特徴になっているのかなと思います。

今回の記事では、開発チームの歴史を記事にしようと思います。
次にどういう計画を立てているのかを記事にしたいと思っています。
採用面談のときに毎回説明させていただいているので、事前に公開しておくことでより多くの方に興味を持ってもらえるといいなぁと期待しています。
技術的負債は大きくなってしまったものの、返済へ向けての計画をしっかり立てており、経営と合意を取りながら進めている点について評価いただくこともあったので、ポジティブにとらえていただける方も多いのではないかと思ったことも大きな理由の一つです。

本題に入る前ですが、弊社の開発環境は技術的負債が大きく、特定分野に特化したエンジニアというよりは、システム開発全般について薄く広く知識があり、画面でもバックエンドでも活躍できるよ！というRailsエンジニアに長く関わってもらいたいと考えております。（誤解を恐れずにいうならば、フルスタックエンジニアというところです）
開発の規模を大きくしつつ、HitoHanaドメインの知識を蓄えたエンジニアを揃えて、マイクロサービス化など抜本的に変えていくときに有利に進められる状態にしたいと計画しております。
現状はバックエンドが得意なエンジニアが多く、フロントエンドがそこまで強くないので、デザインシステムの構築をしつつ、HTML/CSSを整えつつ、デザインと開発をうまく運用に回せるような方もご縁があればご一緒させていただきたいです！

Solidusを深く理解せずに魔改造

2015年11月頃。
エンジニアチームのスキルセットがRailsに寄っていたことや、ECサイトに関する業務知識がまったくなかったため、Solidusという簡単にECサイトを構築できるgemを採用しました。短期間でビジネスをスタートさせたかったので、みんながマニュアルをじっくり読むというよりは必要なところだけドキュメントを読んで進めた結果、モデリングを（今思えば）間違った方向に改造してしまい、大きな技術的負債となってしまいました。（今思えば）pluginを導入すれば解決したようなこともあるような気がします。
結果、Solidusのバージョンアップ作業がつらく断念してしまい、依存しているRailsのバージョンも上げられないという状態になってしまいました。

スタートアップあるあるのとりあえず出してみて修正するときにガッツリ作っては要件が変わる

スタート〜2017年7月頃。
花き業界やECサイトの業務知識がない状態でスタートしているのでビジネスサイドも何が正しいのかわからない状態で、要求分析、設計をして開発を進めていましたが、途中で新しい事実が判明したり、運用していたら全く必要がない機能をつくってしまったりということが結構ありました。もちろんヒット作もたくさんあるので、とりあえず作ってリリースしてきたことが、今のHitoHanaを作ったことには間違いがないと思います。もう一度やり直せるとしたら、”捨てやすい構成”で機能を追加して、リリース後の評価をして本体に組み込むようにちゃんと実装するのか闇に葬り去るのかを決めていくスタイルを取ればよかったのかなぁとはちょっと思います。
リリースしてみて修正するというスタイルもあったが、技術サイド（主に私😭）が未熟だったこともあり、エラーのアラートやバグ報告が多くなってきて、業務を回すためや、お客様の不都合に瞬時に対応するために場当たり的修正を連発するようなり、技術的負債が爆発してきました。

メンバーの出入り

2017年7月頃〜2018年7月頃。
技術的負債が積み上がりやすい状態で、新しくメンバーが入ってくると合わせやすい基準がないので、各々が理解しやすい書き方で設計し、コーディングをしはじめました。さらによくなかったのが、この頃はエンジニア各々がビジネスサイドと要件を擦り合わせるところから仕事をお願いしており、私が把握していない機能が増え始めました。ビジネスサイド側も各々のメンバーが要件定義をしていたので、リリース後に他の部署から変更要求が飛んでくるというような悪循環に陥った感じもありました。この状況が終わったのは、私以外のエンジニアメンバーが全員退職してしまい、ビジネスサイドも多めに退職してしまったときでした。「なぜ、このような仕様になっているのかがわからない機能」が残されてしまいました。
また、技術選定に関して甘く見ており、メンバーレイヤーが好きずきに新しい要素技術を導入できる感じにしていました。勉強したことをすぐに活かせる職場というのは、エンジニアにとって働きやすい職場になると思っていたからですね。でも、その結果ReactとVueの両方を使っていたり、ビルド環境も複数あるみたいな状態になってしまいました。今も残っております！
ところで誤解があるといけないので、念の為申し上げておきますと退職してしまったエンジニアもビジネスサイドのメンバーも優秀な方々でした。スクラムでいうところのプロダクトオーナーの機能が滲んでぼやけてしまったことが、このような悲劇を生んだものと思っております。

個人レベルで改善し始める

2019年10月頃〜。 そんなときに、ベテランRailsエンジニアの松山さんが参画してくれることになり、改善しはじめました。

前記の通り、課題点はいろいろありましたが、テストのカバレッジとテストの実行時間を大きく改善してくれ、まわってなかったRubocopを回せるようにしてくれたり技術的負債の増加がとまりはじめました。新規参入するときに開発環境が作りづらいなどの課題も解決していただいて、メンバーを増やしていける環境が整い始めました。

即離脱してしまうメンバーの発生

2020年4月頃。
松山さんが参入しやすくしてくれた結果もありエンジニアも数名増え、また徐々にチームらしくなってきました。しかし、参画２週間以内にうまくパフォーマンスが発揮できず離脱してしまうメンバーが出現してしまいました。優秀なエンジニアだった思うし、通常のRailsプロジェクトなら十分活躍できるはずという評価でした。（私もそう感じましたし、他のメンバーもそう感じていました。 ）残ってくれているメンバーとの違いを考えたとき、部分理解をして進められるエンジニアは短期間のうちに成果を出せるので心が折れないのですが、全体理解をしてから進めようとすると、うまくパフォーマンスできないような感じでした。技術的負債を抱えたままある程度の大きさになっていることが大きい要因になっていると思います。

マネジメントの強化を含めた開発チームの中長期計画

2020年8〜10月頃。
技術的負債の大きさがチームの運営や、会社の経営に大きいダメージを与えていると改めて認識しているところに、メンバーとして参画してくれていた八木田さんにマネジメント改善を含めた開発チームの中長期計画を立てていただくことになりました。それまでも計画のようなものを作ったこともありますが、仕事が忙しくなりいつの間にか忘れてしまうということを繰り返していました。
マネジメントの改善も計画に組み込んでいただいており、私はコードを書くことを辞めてPdMとして要件を整理・調整して開発チームの窓口となることを中心とするようになりました。八木田さんはSM・EMとしてスクラムを回すことを中心となるようにしました。さらにHitoHanaが次に目指すべきシステムのアーキテクチャを定めてシステム基盤の抜本改善も着々と進めてくれています。
二人のマネージャー体制で運営しており、私が忙殺されてしまっても八木田さんが着々と改善活動を進めてくれているので過去のように頓挫することもなさそうな気がしています！
あと、とても大きいこととして開発チームの中長期計画は経営とも合意をしており、技術的負債がもたらすリスクの大きさや、返済するために時間とお金をかけることをきちんと合意できているところです。私が計画を立てていた頃は、このあたりを軽視していたこともあり、急ぎの仕事に忙殺されてしまっていたのかもしれません。

次の記事では、開発チームの中長期計画を説明させていただきたいと思っております。