技術的負債の解消に積極的なチームが魅力。ログラスで日本一のスクラムチームをつくる

こんにちは、ログラス採用担当です。

ログラスの開発チームはスタートアップでありながら、スクラムを忠実に回し、技術的負債の解消に積極的に取り組んでいます。

今回は、そんなログラスの開発体制に惹かれて入社したエンジニアの佐藤有斗さんにインタビュー。ログラスに入社した理由は？佐藤さんがログラスで進めた技術的負債の解消プロジェクトとは？今後の展望は？お話を伺いました。

DDDに真剣に取り組むチームに惹かれて

まずはこれまでの経歴について教えてください。

学生時代に、教育系のスタートアップでエンジニアのインターンを行いました。まだ10人くらいのチームで、開発の初期に携われたのは非常に面白かったですね。

就活では、総合職かエンジニアの道に進むかで迷いました。しかし自分が働いている姿を想像したとき、プログラミングをしている自分のほうが楽しそうだと思い、2017年にビズリーチにエンジニアとして入社しました。

ビズリーチでは、人財活用プラットフォーム「HRMOS」の新卒採用システムの立ち上げに携わりました。

ログラスへの転職を考えたきっかけを教えてください。

ビズリーチで、DDD（ドメイン駆動設計）が導入できないかの検討を進めていました。そんなときにログラスが主催しているDDDの勉強会に参加したんです。BtoBのSaaSで、ここまで本気でDDDに取り組んでいる会社があるのかと驚きました。

知っていくにつれ、ログラスが取り組んでいる事業内容にも興味を持ちました。経営管理はさまざまなデータを扱うし、各社ごとに分析しようとするデータのフォーマットも、分析の仕方もバラバラです。エンジニアとして、難しい課題に取り組んでいけるのは面白い環境だなと感じました。

また、チームも魅力的でした。ログラスは、松岡や飯田などスクラムやアジャイルに理解があり、かつレベルの高いエンジニアが揃っています。ここでならば、複雑な課題を分割して、品質高くリリースして、ユーザーからのフィードバックをもとにプロダクトを磨いていく、そんな理想的な日本一のスクラムチームを作れるのではと考えました。

技術的負債は「税金」

他社と比較して、ログラスの開発チームはどのような魅力があったのでしょうか？

経営陣が技術的負債の解消に対して理解があることです。私達はよく「税金」という言葉をよく使います。事業的な優先度に関わらず、税金として一定の割合で維持しています。

技術的負債自体は貯まりすぎると、エンジニア1人あたりのプロダクトの成長率が低下します。技術的負債のせいで、開発スピードが落ちていくからです。はじめが100として、90→80→70→60→50と、どんどん下がっていくのです。そしてしまいには手が付けられなくなり、新規の開発をすべてストップして、全員が技術的負債の解消にあたるような事態が発生してしまうのです。

それに対しログラスはスタートアップでありながら、長期的に開発価値を下げないように、はじめから技術的負債への対応、いわゆるリファクタリングに当てる工数を一定の割合でもっています。スプリントと呼ばれるスクラムの最小単位である1週間で、30ポイントのうち6ポイントは必ず技術的負債の解消に当てています。すなわち、80→80→80で維持し続ける形です。この必要性を理解してくれる経営陣がいることは、非常に大きいと思います。

技術的負債をため込んでしまう会社は多いのでしょうか？

誤解していただきたくないのが、技術的負債自体が悪いものではないのです。会計用語と同様、「負債」は今の利益を得るために必要なものでもあります。問題なのは、気づかないうちに大きくなっていること。そして、技術的負債の解消を訴えても、経営陣の判断が下りずにそのままになってしまうことです。

エンジニアは、技術的負債が貯まると、負債の解消に当てたいと感じます。しかし機能開発がトップダウンで決まっている会社では、その計画の中に差し込むことができません。経営陣としても、開発が進んでいるのであれば、その必要性がいまいち理解できないのです。CTOがいても、実際にコードを書かないと分からないため、伝わらないケースがよくあります。ボトムアップで差し込めるカルチャーがないと厳しいですね。

技術的負債の解消で、スピードに大きな変化が

実際に佐藤さんが入社後、技術的負債の解消に取り組んだ事例を教えてください。

連携している会計システムの都合で、ログラスには必要のない概念及びデータがあり、それによって開発に時間がかかっていました。その解消を2か月間かけて行いました。（もちろんこれも税金として対応し、その間も新規の開発は並行して進めています。）

僕が入社する前も、「このデータは必要ないし、直したい」という声があったようです。しかしすぐにできるものではなく、かつ難易度が高いため、放置していました。僕が入社後、この技術的負債に気づき、改めて見積もりをしてみたんです。すると意外と簡単にできそうだと分かりました。そこで経営陣の承認もおり、新規開発と並行して技術的負債の解消にとりかかりました。

どのような点に苦労しましたか？

ログラスは経営管理のシステムを作っており、数値を間違えることは許されません。そのリスクがある作業です。計1千万行以上のレコードに変更を加えたので、本当に大変でしたね。ミスがないよう、細心の注意を払いました。

大変だったのですね！それでもやるべき価値があったからだと思うのですが、具体的にどのような効果がありましたか？

お客様の画面においては何一つ変化はありません。効果があったのは、開発チームの今後の工程です。

その後の開発において、コードがすごく減りましたね。実感としては約3分の1くらいは短縮されたように思います。今回修正を行なったデータは、ログラスの根幹の部分であり、そこを変更するということはすべての開発に響きます。この技術的負債を残しておいた世界線と今とでは、開発スピードが大きく異なっていると思いますね。

エンジニアの意思決定が、大きな影響を及ぼす

ログラスの開発チームは、ほかのチームとどのような連携を進めているのでしょうか。

まずログラスでは、エンジニアもPdMとともにヒアリングに同席します。DDDをうまく進めるためには、システムとユースケースを近づける必要があるからです。ときにはシステムを理解している人でなければうまくヒアリングできないこともあります。仕様においても、エンジニアでなければ分からないことも多くあります。PdMとともに連携してヒアリングに入ることで、お客様の課題解決につながっています。

ビジネスサイドとも情報連携を行っています。毎週スプリントレビューというフィードバックをもらう場をつくり、1週間のテーマに対し、ユーザーに近い視点を持つ弊社代表であり元経営企画である代表の布川などにフィードバックをもらいます。そこで出た課題をもとに、また新しい開発を進めるという、スクラムの基本的な流れがしっかりできています。

もちろんCSとのやりとりもあります。CSとはスプリントレビューを待たずにすぐに連携。すぐに解決できる課題はダイレクトに解決しています。

佐藤さんからみて、ログラスの課題はどのようなところにありますか？

開発における課題のデータベースが必要だと感じています。たとえばCSがお客様から要望をいただいたとき、すぐには改善できずに流れてしまうことがあります。現時点では、Notionでストックしていますが、情報を探し出すのに時間がかかっています。より良いデータベースとして過去のログをすぐに見つけられるようにすることで、業務フローの改善を進めたいです。今後アプローチをしなければならないと感じています。

佐藤さんの今後の目標を教えてください。

エンジニアには大きく2タイプがあると思います。建築家のような、新機能を作るのが得意なタイプ、医者のようなプロダクトの寿命を延ばすのに長けているタイプです。ログラスは非常にバランスがいいチームであり、どちらのエンジニアも大事です。僕は医者タイプのエンジニアとして、技術的負債の解消にこれからも注力していきたいです。

僕の目標は、日本一のスクラムチームを作ることです。僕自身に関しては、マネージャーになるイメージはなく、ずっとコードを書いていきたいと考えています。エンジニアの意思決定は、実は何十億円も動かすような、ときにはマイナス10億円の負債を作ってしまうような、非常に大きなものです。いちエンジニアとして、意思決定の精度を上げていきたいですね。