CLOSE

技術的負債とか新しい技術とか(仮)(全1記事)

「負債解消に取り組むには、破壊的なイノベーションを起こすしかない!」 プロダクトを作り直す気持ちで始めた“山籠もりプロジェクト”

東大関連スタートアップのCTO、VPoEがプロダクトの成長を技術的な側面で語る「PMもエンジニアも必見!プロダクト成長と技術的挑戦のバランスどうしてる?【開発PM勉強会vol18】」。ここで株式会社Legalscapeの城戸氏が登壇。技術的負債解消のために取り組んだことについて話します。

株式会社Legalscapeの事業紹介

城戸祐亮氏(以下、城戸):「技術的負債とか新しい技術とか(仮)」というタイトルでお話しできればと思います。Legalscapeという会社から来ました。よく名前を間違えられるんですが、リーガルスペースやスコープではなくて「リーガルスケープ」なので、そこのところよろしくお願いします。リーガルフォースでもありません。

「リーガル」という名前のとおり、法と法務に関連するテクノロジーの会社です。例えば弁護士や企業の法務部にいる方って、すごく(たくさん)リサーチをするわけです。基本的に法律に答えが書いてあることはないわけで、解説書籍や過去の裁判でどういう結果が出たか、あるいは官公庁がなぜかPDFでしか出してくれない謎資料に重要なことが書いてあるとか。そういう感じで(リサーチは)めちゃくちゃ大変な作業なんです。

いろいろなところに散らばっている情報が1ヶ所に集められている。かつ、そこから検索できたり、あるいは我々の技術力でそれをもう少し分析したり、変換したり、使いやすくするようなことでリサーチを助ける。それを「Legalscape」という社名と同じプロダクトで行っています。

それを本業としつつ、そういう情報をきれいにすることをやっているうちに、「きちんと上流をきれいにしないと」というのもありました。例えば、裁判の判決とかって、先進国だと普通はきちんとオンラインデータベースで出してくれるわけですが、日本は先進国ではないらしく、紙でしか出てこないので、「ちゃんとデータベース化しないとヤバいよね」ということを国もずっと言っていて、法律と技術の専門家としてその実験にも協力しています。

最近デジタル庁ができましたが、中央省庁などで法律を作る仕事をしている方々の作業もめちゃくちゃアナログかつ大変で、そこも「どげんかせんと」ということで、そのデジタル化をどう進めるかという検討会にも、Legalscapeは技術者として呼んでもらうというかたちで(協力しています)。本業ではありませんが、この国のリーガルを良い感じにアップデートするという意味で、いろいろなことに取り組んでいる会社です。

創業は2017年で5年ほど経つんですが、今は正社員と役員だけで13人。その他に業務委託としてお願いしている方を入れると20人強の会社です。半分と少しがプロダクトサイドで、開発やデザイン、研究、SRE。あとはNon-Devのプロダクトオーナーがいるかたちでプロダクトチームを構成しています。

先ほどの大森さん(大森亮氏)の発表の中で、「その事業領域においてどこがすごく大事なのかが違う。そこが重要」という話があって。まったくそのとおりだと思います。リーガルは金融とは違いますが、僕たちの会社や事業もけっこう近いところがあって。仕事で使うまじめなツールなので、使いやすさやきちんと使いたい時に使えることは重要です。逆に、ユーザー数がスパイクする、あるいは土日にめちゃくちゃ使われることはあまりないという意味では、(リーガルは金融と)ちょっと近いのかなと思います。

城戸氏の自己紹介

自己紹介をすると、一度卒業したあとに就職したんですが、半年で辞めて今の会社を立ち上げたので、実を言うと今時のWeb開発のベストプラクティスやプロジェクトマネジメント、プロダクトデザインなどはあまり知らず、実質社会人経験が半年のまま今の仕事をやっています。正直この場でみなさまに有益なことをお話しできるのかわからないんですが、一発芸だと思って聞いてもらえればと思います。

雪だるま式に増えていく技術的負債

僕たちのプロダクトにも、おそらく多くのスタートアップと同じようなことが起きています。最初はとにかく早く作らなきゃということで、がんばって技術選定をしました。当時はバックエンドでTypeScript(を使うこと)に対してみんなあまりチヤホヤしていなかったんですが、ちょっと背伸びして選んでみたり、NuxtやElasticsearchを使ったり、がんばっていろいろ作ってきました。

そこからチームは徐々に大きくなって、開発者も増えて、できることも増えましたが、利用者も増え、想定以上のスピードで事業が伸びて、そのまま正式リリースを迎えました。利用者が増えると、いろいろなヒアリングなどを通じて「あれも作りたい、これも作りたい」とやることも増えて、当然の帰結として負債もガンガン増えていった。やはり最初に選んだ時には気づかなかったベストプラクティスが、後悔というかたちで後から見つかるわけです。

そういったかたちで特に僕はWeb経験がないまま来てしまったので、業務未経験の技術をガンガン選んでしまい、「ああすればよかった」というものがいくつか出てきてしまいました。

これはあるあるだと思うんですが、一度「こういうライブラリ、こういうミドルウェアを使います」という感じで選んだはいいものの、「それをどうやってバージョンアップするの?」と。そこがめちゃくちゃ大変で、結局なかなかできず、負債が雪だるま式に増えていきました。

負債解消のために実施した「どんな負債があるのか」を書き出す会

最初に考えたこと。そもそも負債の解消もものづくりの一部なので、プロダクトロードマップの一部にきちんと載せることがけっこう重要だと思い、まずはみんなで「どんな負債があるのか」を書く会をやって、「それをきちんとロードマップに入れていくよね」(とみんなで)合意しました。

その時に「新規開発と負債解消のどちらを優先するんだっけ?」ということがなかなかわからない。そんな時に、それをうまくみんなが納得できるかたちで比較するために「プロジェクトの優先順位はこういう感じでつけよう」という基準というか、「こういう感じで考える」という内部の文書を作りました。

結果として良かったことは、いきなり単純にプロジェクトのロードマップの中に「負債解消を入れます」と言っても、みんなが「わかるわかる」という感じで受け入れてくれて。プロダクト外のBizチーム/Corpチームの理解度が高くて、それはかなり助かりました。

それから、開発をしているとやはり「こういうところを直さなきゃ」と、みんな(それぞれ)が脳内に持っているものがいくつかあるわけです。そういう時に、きちんと負債を書く会を設けることで、いわば見える化というか、「みんながこういうことを気になっている」と共有できて。それで「そういえばちょうど今時間があるから、あのへんのことをやるか」と。一度書き出すこと自体が、資産(になること)として良かったと思っています。

プロダクトオーナーの加入により整いつつあるバックログ

ただ現実はそう甘くはなく、なかなか着手できないものも多いし、「こういうかたちでプロジェクトの優先順位を考えよう」という基準を作っても、ちょっと形骸化しちゃっていたり。あるいは、その負債のリストすら更新できていなくて、みんなの脳内にモヤモヤとしたものが必然的にできちゃっている。

(そういったことが起きるのは)「なぜなのか」と考えると、やはり負債解消はけっこう気合いを入れないとできないことも多い。特に弊社のような始まったばかりの小さなベンチャーの場合、やりたいことはどんどん出てくるけれど、(その出てくるものが)どれも優先度がMAX(に高い)なものしかない。

本当に「やるしかない」というものがたくさん出てきて、その「どれを諦めるか」という戦いの中で(ありながらも)、基準に照らし(合わ)て順位をつけるとか言っている場合ではない。もちろん事業のフェーズがガンガン進んでいく中で、常に製品の本体の開発の中でもやりたいことが増えていく。

そこへの銀の弾丸として最近というかここ半年以内にプロダクトオーナーの専任者にフルタイムで加入してもらえた。(この方が)めちゃくちゃ強い人で、我々がてんやわんやしながらがんばって捌いていたプロダクトのバックログが、徐々に整いつつあります。

「もう破壊的なイノベーションを起こすしかない!」

しかし、一言で言うとやはりまだ常に余裕がない状態なんです。つまり、やりたいことはいっぱいあるけど、それに対する人手がぜんぜん足りていないのが恒常的になってしまっていて、これだけだと負債というものに取り組めない。いわば、自分たちの本業で手いっぱいで、刀を研ぐほうに時間を割けない。少し意味が違いますが、イノベーションのジレンマ的なことがベンチャー(である)にも関わらず起きている。

その時、1人が変なことを思い付きました。「イノベーションのジレンマなら、もう破壊的なイノベーションを起こすしかない!」と。

(スライドを示して)どういうことかというと、こういう感じで、あんなプロジェクトやこんなプロジェクトで手いっぱいな人を1人引っこ抜いてきて山籠もりをさせる。

これは「山籠もりプロジェクト」という名前で、しかも(その対象が)たまたま僕だったんですけど、1人をあらゆる会議やふだんの緊急対応など、すべての業務から一度剥がしてて、新たにプロダクトを作り直すような気持ちでがんばる。そういった時間をかけてやってみようと。

いわば、式年遷宮のようにゼロからうまく作る。その人はその部分をやって、残りのメンバーは製品自体の改善をきちんと続けるという感じで分担することで、一度全力投入してみようと。

その結果、実はまだ結果は出ていません。時間が足りなくてまだ終わっていなくて、もう少ししたら再開しようと思っています。

ただ想定どおり、まったく新しいものを作ることがほどほどにできて、良い感じだなと。

加えて、たまたま僕がけっこう初期からいるせいで、僕にしかない知識みたいなものがあったんですが、その僕が突然いなくなってしまったので、結果的に知識移転が起きて、それはそれで良かったのかなという副作用的なことがありました。

少し時間が過ぎていますが、Legalscapeという会社でリサーチシステムを作りながら、こんな感じで日々がんばっていろいろなことを考えています。採用もがんばっているので、よかったら調べてみてください。

以上です。

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!