理系学生日記

おまえはいつまで学生気分なのか

忍者TOOLS

merpay Backend Engineer Meetup #6~技術的負債について~

現在のプロジェクトでも様々な技術的負債が出てきていて、出るだけならまだしもなかなか返済を計画化できず、どうしたものかと思っています。 そんなとき、 merpay Backend Engineer Meetup #6~技術的負債について~ - connpass が開催されるというのを目にし、これは是が非でも行きたい、話を聞きたいと思っていました。 そして行ったら meetup はとにかく最高で、懇親会まで含めて最高だった。

自分のところの技術的負債

最初のコンテキストとしてぼく自身の関わっているプロジェクトの技術的負債の状況を記載しておくと、技術的負債は多いです。多いのだから返済を計画しなければいけません。

でも、やはり機能開発を優先してしまっていて、負債の返済は遅々として進んでいません。負債は「返済しましょう」とって返済していけるものではないのです。 Google よろしく 20% ルールを定義し、その 20% は返済のみに使うということにしていたのですが、その 20% もいつの間にか「機能開発が遅れたときのバッファ」として使われてしまうようになってしまいました。

負債を返済しないまま機能開発をすすめると負債が利子で膨張していきます。新たに開発した機能は負債で蝕まれ、返済するための負荷が大きくなります。 開発スピードにも影響を与え、開発の後段になればなるほどベロシティを押し下げようという圧力が大きくなります。よくあるよね、最序盤で開発スピードを優先しようとして「あとで返済しよう」と思って負債を作っていると、いつの間にか首が回らなくなる状態。

そんな悩みを解決するようなヒントが何かないかと、そんな思いで Meetup に参加したのです。

Meetup

Meetup は、パネルディスカッション形式で進んでいきました。 @oinume さん、@execjosh さん、@ogataka50 さん、@tyamagu2 さんという Tech Lead 陣が、技術的負債に対する様々な質問に対して、自分のチームではこういうことをやっているという形で答えてくれます。 merpay ではチームに対して幅広い権限が委譲されていているようで、それぞれ採っているルールも開発スタイルも異なっているようでした。

以下、かんたんに Meetup でお聞きしたことをまとめていますが、きっと他にも様々な取り組みを行っているチームがあるのだろうと思います。

技術的負債の状況

まず、開発スピードの高いイメージのある merpay さんにも、技術的負債はたくさんあるそうです。

  • データの二重書き込みが発生するケースがあり、整合性の確認バッチ等を含めた運用で整合性を担保している
  • 使われていないコードや古い変数名がきちんと消せていない
  • ユーザ情報の更新順序が望ましくない状態になっている
  • 管理画面を作成しないままで、sql 直更新で運用している箇所がある
  • 3rd. Party の呼び出し部分が遅くなっている
  • 開発スピードを優先するため、特定の機能を責務的に望ましくないマイクロサービスに相乗りさせている

merpay さんなら技術的負債を生み出したとしても高速に返済していっているんだろうなぁと思ったら必ずしもそういうわけではなく、各チームでその返済に頭を悩ませているようでした。

負債の返済方法

一番気していたのは、できてしまった負債をどう返済しているのかです。

負債返済専門の人を作る

なるほどなぁと思ったのは、「負債を返済する役割の人をチーム内で作る」という方法でした。

冒頭に述べたように、ぼくのチームでは負債返済用に 20% の時間をバジェットとして確保しておくという方法を採っていましたが、当該の時間は進捗が悪い場合の「バッファ」として消費されてしまいます。おそらくこれは、負債返済用の時間と機能開発用の時間の境涯が曖昧で、バジェットを機能開発に使うことに対する障壁が低くなっていたからなのでしょう。

merpay さんのように「負債返済のみを担う人」を作れば、その人の責務は「負債返済」という点がはっきりするため、負債返済用のバジェットで機能開発の遅れを補填しようという甘えができにくくなります。 こういった役割の明確化こそが、境界線が曖昧な事柄をうまくすすめるための方法なのだなぁと思いました。

四半期ごとに負債を含めて OKR を定義

四半期ごとの経営的な OKR のかなり高い優先順位の項目に負債返済目標を置く、という方法です。

もちろんこの方法は、経営陣や PdM への説明に労力を使います。一方で、きちんと相手に伝わる言葉で説明 (問い合わせ対応の削減、インシデントが発生すると金融庁報告、etc.) し OKR として定義されてしまえば、 経営陣の力強いバックアップを受けての負債返済ができるので、大きな推進力を得ることができます。

また説明への労力という点では、merpay 社内にはインシデントレポート(SRE 本でいう Postmortem)という仕組みあり、障害が発生すると顧客影響や技術的原因、その発生理由が社内全体に公開されることになります。 このインシデントレポートにより、技術的負債返済の説明すら不要になるケースも多くなってきたというお話がされていました。

負債と新規開発を分けない

負債と新規開発とを分けず、並列に並べて優先度判断をする、というお話もありました。理想ではありますが、これを実現するには PdM と開発チーム間で強い相互信頼が必要になりそうです。

負債返済のポイント

いずれについても、PdM、あるいは経営陣が技術的負債とその影響を正しく理解しているからこそ、できることなのであろうと思います。もちろん、PdM、経営陣を待つだけでなく、開発チームからもきちんと説明・共有を尽くし、同じ理解に立った上で機能開発・負債返済の価値判断をしていくことへの強い意識を感じました。

技術的負債を作らない工夫

もちろん、技術的負債は作り込まないに越したことはありません。

技術的負債には、負債になることがわかっているがそうせざるを判断して負債化するものと、当初想定していなかったが負債化するものが存在します。 前者については、リリース期限に間に合わせるために負債を受け入れるというようなケースですが、こちらについては計画的な負債返済計画が立てられます。

一方で、負債返済の計画も戦略も立てられないという点で後者は非常に痛く、負債を作る前にどう発見するかがポイントになります。

merpay では Design Doc を記載する制度が始まっていました。 そのメリットとしては、機能・要望の実現方法は必ずしも1つではないため、その Pros、Consを並べてドメイン知識がある人のレビューを受けるとともに、もし誤った選択をしたとしても振り返り、フィードバックを回すことができるという点があります。 迅速に開発をしないといけないとしても、何となく機能を実現していくのではなく、きちんと設計とレビューのプロセスを踏む。こういった当たり前のことを当たり前にしていくことが、負債を作らない上での当たり前の方法なのかもしれません。

イベントとして

(懇親会以外の)すべてがパネルディスカッション形式のイベントというのは初めて参加しましたが、進行もやり取りも非常にスムーズでとても聴きごたえが有りました。 また、Q&Aの時間も十分に確保され、会場からの多くの質問に様々な観点から回答を頂けるという点でも充実感に満ちたイベントでした。

最後の懇親会も、本編と並ぶくらい良くてメチャクチャ質問してしまったんですが、メチャクチャ質問に答えていただけて、マジで行ってよかった。 本当に良いイベントでした。登壇頂いた皆様、運営いただいた皆様、本当にお疲れさまでした&ありがとうございました。