【ログラスCTO】コードがきれいだとビジネスは伸びる。プロダクトを腐らせないための秘策とは

昨年から社員数が倍増するなど、急成長を続ける株式会社ログラス。経営に関するデータを管理し、さまざまな形で出力・分析等ができるSaaS「Loglass 経営管理」「Loglass IT投資管理」（以下、Loglass）を開発しています。

CTOの坂本龍太さんによると、創業期のメンバー全員が「今度こそプロダクトを腐らせたくない」と、コード品質の高さや開発のしやすさにこだわり、開発当初から保守タスクと新規開発を両立し続けているそうです。

「コードがきれいなら、ビジネスは伸びる」と語る坂本さん。きれいなコードや整えられたデータ構造をつくり維持していくための、ログラス開発チームの取り組みについて聞きました。

• keyboard_arrow_down コード品質にこだわる開発。大工事が発生しないような設計×定期的な保守タスクの二段構え
• keyboard_arrow_down 「今度こそプロダクトを腐らせたくない」創業メンバーに共通する原体験
• keyboard_arrow_down それでも大きなつくり直しは発生する。大事なのは「中長期的なベストをとる選択」
• keyboard_arrow_down 「コードがきれいならビジネスは伸びる」エンジニア同士の合意形成が経営層を変える

――ログラスでは新規開発とリファクタリングを両立しながら開発を進めているそうですね。

そうですね。新規開発と一緒に、エンジニアから提案があったリファクタリングを進めています。リファクタリングが必要な箇所に気づいたエンジニアがタスクを立てていって、重要度を適宜判断しつつチームごとに対処してもらっています。

また、使っているライブラリや言語のバージョンアップは、やらずに放置すると開発を進められなくなってしまうので、創業時から毎週欠かさず行っていますね。

――創業当初は、新規開発のタスクも山積みのはずです。なぜその段階から保守タスクも同時に進めることにしたんですか？

「Loglass」というプロダクトのドメインが特殊で、最初から品質の高いプロダクトでなくてはならなかったのと、保守タスクを溜めずに開発し続けてコード品質を高く保つことは長期的にプラスだと判断したからです。

ドメインの特殊性という面では、ログラスのプロダクトは、経営管理、いわゆるCPM（コーポレート・パフォーマンス・マネジメント）と呼ばれる領域に携わっています。経営データをクラウドで管理するサービスですから、企業の経営を左右するとても重要なデータをたくさん保持しています。このデータを扱う上で、少しでも数値がズレたり、万が一漏れるなんてことがあれば、影響範囲は甚大です。このデータを着実に守りながら扱えるプロダクトでなくてはならないので、必然的に高い品質が求められます。

――創業当時は特にスピードが大切だという考え方もありますが、スピード重視で進めることは考えていなかったのでしょうか？

もちろん、コード品質よりもローンチまでのスピードを重視して勢いでつくり、リニューアル時にフルスクラッチでつくり直す方法もあります。しかし、何度も大きな改修を繰り返していては、ビジネスの仮説検証を回すスピードはどんどん遅くなってしまいます。スピード感が最重要といえるスタートアップにとっては、その遅さはかなりの痛手です。

だったら、コストがかかったとしても、最初から保守タスクを溜めずに開発し続け、コード品質を高く保つことは、後々大きなプラスになるのではないかと考えたんです。

事業が軌道に乗れば、スピード感をもって新しい機能を追加していく必要がありますし、新しいメンバーもどんどん増えていきます。コード品質が高ければ、そうでない場合に比べて、新規開発のリリースまでの期間も短く済みますし、新しいメンバーがキャッチアップしやすく、すぐに開発に取り掛かれます。

また、実はCPM自体は40年前から存在するシステムで、「経営管理」における主要なデータ構造は40年前から変わっていないんです。それをもとに、プロダクト内のデータ構造やデータの持ち方を確実に見やすくきれいにつくり上げられるので、後々大きな負債になるような設計ミスが起きづらいという要因もありますね。

――たしかに。とはいえ、特に初期の少ないメンバーで開発していた段階では、リソースが足りなくなってしまうときもあったのではないでしょうか。

リソースが完全に充足しているとはいえませんが、全く足りず手が回らないというわけでもありません。負債が極大化するまで放置することはないので、大量のリソースを必要とする改修はほぼありませんし、ありがたいことにメンバーもみんな優秀なので、そこまで悩むことなく開発を進められていますね。

それに、「きれいな状態をきれいなまま保つ」ためのメンテナンスコスト自体はそこまで大きくないので、新規開発と保守タスクを無理なく両立できています。

というのも、私は「きれいなコードの上に、汚いコードはなかなか書けない」と思っていて。最初からコードがきれいなら、それを保ちたくなるのがエンジニアの心情です。何か機能を追加するときも、元のきれいなコードに沿って書ければ、おのずと整ったコードになります。つまり、コードをきれいに保つことで、修正にコストがかかるような汚いコードが発生しづらくなるんですよね。

――創業当初からコード品質を高く保つための取り組みを徹底していて、「絶対コードをぐちゃぐちゃにさせない」という意志を感じます。

「コードがぐちゃぐちゃ」は珍しいことではないと思いますが、本当によくないことだと思います。私は原体験として、その思いが強い方ではあると思いますが。

まだ駆け出しのエンジニアの頃、いくら頑張ってもソースコードが読めないチームに配属されたんです（もう10年前なので全く状況は変わっていると思います）。技術書を片手に少しずつ読み解こうとしても、うまく読めず書けずでとてもつらかったんですが、それが当たり前だと思っていました。そのあと「コードがきれいだ」と知られているチームに配属されて、驚きました。何がどうなっているのかすぐに理解できるんです。開発自体も楽しくて、モチベーションも大きく向上しましたね。

この経験から「コードが汚いと、開発効率にも、キャッチアップの速度にも、エンジニアのモチベーションにも大きな悪影響を及ぼす」と、身をもって学びました。

それに、エンジニアの初期メンバーたちも「今度こそプロダクトを腐らせたくない」との思いが強い人ばかりで。転職してきた彼らは、過去にプロダクト開発で苦い経験をしてきています。例えば、見切り発車でつくったために設計も場当たり的でテストもドキュメントも存在しなかったり、プロダクトを改善したいのにコードが汚すぎて読み解けないし、書くとしてもさらに汚いコードを重ねるしかなかったり。そんな経験を大なり小なりしてきて、それぞれが忸怩たる思いを抱えているんです。

このやりきれない感情は「お客様に貢献できなかった悔しさ」であり、ビジネス感度を持っている証なんですよね。だからこそ、「お客様に動かぬ価値を提供できる良いプロダクトをつくりたい」「何年経っても腐らせたくない」という強い想いを全員が共有し続けていて、それが今のログラスのカルチャーにつながっています。

――その思いを、どのように開発に生かしているのでしょうか。

お客様の課題を本質的に解決できるプロダクトをつくるために、お客様の業務や課題をエンジニアが深く理解した上で開発に取り組めるようにしています。

例えば新機能を開発するときなどは、エンジニアがデータ構造の概念図を用意して「どうやって、どんなものをつくろうとしているか」をお客様やCSに説明し、フィードバックをもらっています。そのフィードバックをもとに、正確な処理ができるよう、設計を組み直すこともあります。ほかにも、お客様の業務への理解を深めるために、商談の録画を見たりもしていますね。この「お客様の業務理解をもとにプロダクトを設計する」という発想はドメイン駆動設計（DDD）とも呼ばれていて、「Loglass」の開発にはとても役立っています。

「つくる側」であるエンジニアが、「使う側」である現場の課題やビジネスをダイレクトに理解していれば、確実に役立つものをつくることができます。それに「実際の業務と設計が全くずれている」という状態になりづらい点も、開発組織にとっては大きなメリットですね。

――それだけコード品質の向上に手を尽くしているなら、ログラスでは今まで抜本的な改修を経験したことはないのでしょうか？

実は過去に一度経験しています。創業から1年ほど経った頃に、データ構造の抜本的なリファクタリングを行ったんです。ただ、当時はその改修を行うかどうかでかなり悩みましたね。

この改修を行わないと、今後このデータに紐づいて新規開発するとき、まったく同じことをするコードを、「if○○」「if▲▲」の2ルート分開発することになってしまいます。改修すれば1ルートで処理できるので、改修しない場合に比べて開発工程が半分で済み、仕様変更の影響範囲も半分に抑えられ、エンジニアにとってもシンプルで分かりやすい。

ただ、改修を行うなら、根本のデータ構造を丸ごと変えることになります。当時はまだエンジニアが2人体制。工数を見積もってみたら、他の新規開発をすべてストップしないと到底やりきれないとわかりました。

お客様から「すぐにでも欲しい」とご要望のある機能実装もたくさんあるし、資金を途絶えさせないよう投資家に一定の売上増を見せる必要もある。大企業のデータを扱う以上、もしミスしてデータを破損するようなことがあれば、事業を潰しかねない大きなリスクになり得る。当然、リファクタリングを行ったところで、ダイレクトに売上が増えるわけでもありません。

――エンジニアとしても、経営者としても、葛藤がありそうですね。

本当に悩みました。ただ、悩んで悩んで「やる」と決めた私の判断を、共同創業者（CEO）の布川（友也氏）も信用してくれて、任せてくれました。

布川自身が経営企画の領域でキャリアを積んできたドメインエキスパートでもあるので、ドメイン駆動設計の手法に則ってリファクタリングの意義を説明したら、「それはやったほうがいい」と理解してくれたんです。ログラスが大事にしているバリューの中には「LTV first 長期間でみて最大の価値を生むことを重視し、大胆に決断する」というのがあるように、このリファクタリングは、未来のログラスをつくりあげるうえで必要不可欠なことだと決断してくれたと思います。

――このリファクタリングは、やってよかったと思いますか？

本当によかったと今でも思います。ここでしっかりとコストをかけたからこそ、冗長で無駄なコードを書かずに済んでいますから。

それに、このリファクタリングは、開発チームのみんなと共有している成功体験でもあるんです。チームのメンバーにとっては、「これだけの大きいリファクタリングを、こんなに厳しい状況でも、やろうと判断してくれる」「実際にできるんだ」と、経営陣やマネジメント側を信頼してくれる要因になっています。

そのおかげで、以前にも増して、エンジニアからボトムアップで建設的な改善提案をどんどん出してくれるようになりました。臭い物に蓋をせず、必要な保守タスクはどんどん見つけて片づけるという価値観も浸透しましたし、胸を張って「Loglassのコードはイケてます！」と言ってくれるようになりましたね。

――コード品質の向上に取り組み続けてきて、よかったことを教えてください。

開発チームにとってはもちろん、プロダクトにも事業にも、よかったことばかりです。私は「コードがきれいならビジネスは伸びる」と思っています。「きれいなコード」は、お客様にとっても、今進んでいる開発や採用にも、大きなプラスをもたらしてくれています。

コードがきれいであれば、開発工程でのロスとミスが減り、より多くのお客様に満足いただける価値を素早く届けることができます。エンジニアはモチベーション高く、高速に開発でき、採用活動でも多くの求職者が当社に魅力を感じてくれて仲間が増え、事業の更なる成長につながります。

きれいなコードを保つ、すなわち「今は目に見えないけど将来的にシステムが負債化していくリスクを回避する」という共通認識を持って保守タスクを実行したり、リファクタリングの意思決定をしたりすることは、あらゆる面で投資効果が高いと思っています。

――一方で、保守タスクまで手が回らなかったり、工数を割けなかったりする企業や組織もあります。その状態から脱するにはどうしたらいいでしょうか？

企業や組織によるとは思いますが、おそらくエンジニアは、本当はもっとスピードが出せる部分や、負債化している部分を知っているはずです。ただ「経営層がそれを把握できていない」というパターンが多いのではないでしょうか。

こういった状況を打開するには、まずはエンジニア内で合意形成をしたほうがいいと思います。例えば、技術的負債に対して3カ月の工数を当てれば、1年後の開発スピードはこれくらい加速する、などと事業が伸びる可能性やポテンシャルを見積もって合意形成します。

そしてマネージャー層が代表となって、ROI（投資利益率）や障害の起こりうるリスクの削減効果、開発スピードの向上といった、ビジネスで出せる価値の話に変換し、経営層に向けて説明する。

こうしてエンジニア全員が、ソースコードの話ではなく、ビジネスの観点で話ができるようになり、開発の責任者が経営の言葉で説明できれば、経営者の判断もおのずと変わっていくはずです。

経営者は得てして開発のことが見えづらくなってしまうものですから、こういった、経営者の認識を正しく改めるための動きをエンジニア全員にしてもらえると、経営者とエンジニアが協力し合って、よりよいプロダクトやよりよい事業をつくることにつながってくるのではないでしょうか。

取材・執筆：山岸裕一
撮影：曽川拓哉