技術的負債に取り組むか否かの判断基準とは
――河合さんは「負債を許容するか返却するかはPdMもしくはTech Leadの判断」と言っていましたが、深澤さん自身はどのような判断基準を持っていますか。
深澤：事業会社にいるので、負債の返却は儲かるかどうかが判断の全てだと思います。負債を返却して技術的に素晴らしい環境になったとしても、そのサービスが儲からなければ意味がありません。最終的にはこの機能が直ると開発スピードがどのくらい上がり、それによって新機能が開発でき、いくら儲かるというところまで算出するのが、技術的負債に対する責任だと思います。
河合：組織面では私も納得です。持ちつ持たれつだと思うので、組織の軸と個人の軸の2つを持つ必要があると思います。
――原さんでは「ビジネスが伸びているから負債返済のプロジェクト化を意思決定しやすかった」という話がありましたが、そこまでうまくいっていない場合、どうしていたでしょうか。
原：事業がうまくいっていない場合には、負債返済というよりは使われていない機能を捨てるなど、スリムアップをすることの方が必要かもしれないですね。
――プロダクトがうまくいっていない場合に、手を入れる必要があるが、ビジネスとして続いてしまっているので難しいというようなこともあると思います。その場合、どのように判断すれば良いでしょうか。
深澤：個人的な考えですが、新しい機能をつくる時に、不必要なオーバーヘッドを技術的負債で返済しても良いと思っています。このスコープの中で何が最適か、どのスコープでどんな成果を上げたいかを定義した上で、今障害になっているものを優先度を上げて対応していくことが大事なのではないでしょうか。
――プロダクトの機能が変わったときは、負債として捉えるということですね。将来性やスピード感によっても、負債のパラメータは変わると思うのですが、いかがでしょう。
河合：非常に面白い質問ですね。大人な回答ではないところで言うと、ミニマムなモックを作ってPDCAを回していくのは当たり前ですが、ビジネス側とのコミュニケーションは難しいので、あえてコミュニケーションを取らずに、エンジニアの都合で技術的負債を解消するという手があります。2日ぐらい合宿を行って集中的に直す、一部をOSS化するなどの方法が考えられます。
原：自分自身も1人のエンジニアとしての視点でみたときには、技術的負債をプロジェクト化した先で解決したかったのは、エンジニアが開発が楽しいと思える環境と状況を取り戻すことでしたね。
河合：根源的なWillを忘れてはだめですよね。
技術的負債を取り組むエンジニアを適切に評価するには？
――河合さんに質問です。ワーキングアグリーメントをエンジニアチームに定着させるためのコツについて教えてください。
河合：ひたすら言うことでしか定着できないと思います。これは評価制度の問題もあります。ビジネスに貢献した方が評価されるので、負債を解消しようという方向にはなかなか向かわないからです。チームでは「これは絶対にやめよう」と言っていくことが大事ですね。
原：当社も評価制度を定義する必要があると思っています。ビジネス側からの成果が見えやすい新機能開発だけではなく、運用を支えているエンジニアや、サービスのライフサイクル全体に貢献しているエンジニアこそ、評価されてほしいと思っています。
――では、どのようにして負債の返済に取り組んでいるエンジニアを評価すればよいのでしょう。
深澤：デプロイの成功率、開発のリードタイムなど、KPIに類するものをエンジニアリングでも用意して、定量化すると良いのではないでしょうか。それらを計測した上で、改善につながる施策かどうか、課題の整理をする。開発のスピードが上がると、ビジネスを加速することにも間接的に寄与しますからね。
河合：評価やお金に関連しない気持ちの部分も大事にしたいと思います。AI LabではスモールWillシートを用意し、「この人のやったWillがすごく良かった」という声を可視化し、こんなに活躍しているんだということをビジネス側に伝えています。
――充実した議論になってきましたね。ここで新しい質問です。エンジニアメンバーの入れ替わりや新規加入によって発生する負債については、どのように取り組めばよいでしょうか。
河合：ワーキングアグリーメントを読み合わせし、ルールで縛ることでしょうか。
原：当社が機能開発を止めてリファクタリングに取り組んだのは、まさにこの状況があったからです。GoのAPIサーバがあったのですが、当時の意思決定の背景や経緯がドキュメントとして残されていなかったこともあり、1行を書き換えるために5～6個のファイルを書き換えないといけないという複雑な設計になってしまっている箇所がありました。このようなことを今後、起こさないためにはドキュメントとして残すことが必要だと思います。
ドキュメントを書くのが苦手というエンジニアは、その筋力をつけていくしかありません。ドキュメントを書くことを促すために、私は良いドキュメントを書いた人は、社内のオープンな場所で紹介するようにしています。
深澤：ドキュメントも大事ですが、変化の少ないところについては、コーディング規約を定めたり、自動検出するテストなど仕組みを作ったりすることも大事だと思います。変化の大きなところは自然言語で書いて、柔軟性を持たせる。当社ではそういう仕組み化に取り組んでいます。
大企業とスタートアップ、技術的負債への取り組み方への違いとは
――みなさん、前職では大企業で働いた経験をお持ちです。スタートアップと大企業では、プロダクトの運用、負債への考え方、取り組み方について何か違いはありますでしょうか。
河合：キャッシュフローが異なります。大企業では資金があるので、プロジェクト化して負債の返却ができます。スタートアップは資金調達や上場などを目指し、ユーザーにサービスを提供していかねばなりません。崖から落ちないように飛行機を作っていくような感じです。そこが大きな違いだと思います。
原：同感ですね。前職では「これをやると会社が潰れる」という心配はなかったです。カミナシでは、「技術負債返済のプロジェクト化の意思決定が、結果として会社を潰すことにつながってしまったらどうしよう」という不安は今でもあります。
深澤：体力の違いだけではなく、大企業では標準化も進んでいます。もちろん標準化が障壁になることもあるのですが、標準化があるから楽にできたということも多々あります。開発を行いながら、標準化も進めていくのは、悩みながらの作業となります。だからこそ、スタートアップは技術的負債が溜まりやすい。その分、エキサイティングな環境なんですよね。
――最後は良い締り方で終えることができました。皆さん、ありがとうございました！
左下：キャディ 河合俊典氏、右下：カミナシ 原トリ氏
