技術的負債との付き合い方のススメ〜「Qiita Engineer Summit 2021 Winter」イベントレポート
2021年12月17日、エンジニアとして活動している方を対象にしたオンライントークセッション「Qiita Engineer Summit 2021 Winter」が開催されました。こちらは、“Be a Contributor”がメインテーマとして据えられて、「エンジニアリングは社会に、そして世界にどう貢献できるのか？」を各企業が考え、取り組むそれぞれのエンジニアリングについて語るべく、Qiitaが主催したものとなります。
第6弾のセッションテーマは「技術的負債との付き合い方のススメ」。エンジニアリングをしている中で議論として取り上げられることが多い「技術的負債」について、今回は株式会社サイバーエージェントと株式会社ニューズピックスの取り組み内容が語られました。そもそも技術的負債とは何なのか、サービスを提供しているエンジニアとして技術的負債にどう向き合っていくべきなのか。当日の様子をお伝えします。
※本レポートでは、当日のセッショントーク内容の中からポイントとなる部分等を抽出して再編集しています。
登壇者情報
メディア統括本部 Ameba事業部 リードDivフロントエンドリーダー
執行役員 CTO（※肩書きはイベント登壇時。現フェロー）
目次
具体的にどんな技術的負債があるのか？
－－まずは「技術的負債」と言った時に、具体的にどういうものが挙げられるのか。それぞれ教えてください。
高山：まずは最初にお断りしておきたいのですが、僕がニューズピックスにCTOとして入社したのは2020年でして、NewsPicksにある技術的負債は全て僕のせいではありませんという風に言いそうなところですが、そういうことではないんです。むしろ僕が思っているのは、これまでのNewsPicksに関わっていたエンジニアの判断はもの凄く真っ当だったなということです。サービス開発において、120%正しい技術選択をずっとされてきたんだなと噛み締めながら、いつもやっています。
とは言え、NewsPicksが始まって4〜5年くらいは開発者も15〜20人程度でやってきたわけで、その頃だったらそれが120%正しい技術選択だったとしても、人数が増えた今では真っ当ではないことが起こり得るかなと思っています。そういうところが、僕たちが現在抱えている主な技術的負債だと思っています。
－－ぜひこの後、深堀りさせてください。続いて柳さん、サイバーエージェントの中でもAmebaの技術的負債と聞いて、どういうことが挙げられますか？
柳：いま高山さんが仰っていた話に近いのですが、当時として問題ない設計だったとしても、時が経って古くなっていたり、あるいはローンチした後のアプリケーションが高頻度で改善されずに放置されている状況になっているものが存在します。あとは、メンテナーが異動や別プロジェクトに行ったりなどの理由で動かなくなるものもあります。
そこに対してどう返済するかということですが、例えばデプロイの頻度やリードタイムみたいなものを計測して、「このリポジトリはしばらくリリースされてないけど大丈夫かな」というのを分かるようにしています。例えば最近話題になった「Log4j」の脆弱性問題では、導入しているプロダクトが「リリースできない」状態にあると致命的な問題になってしまいます。
そのため、重要度の高そうなものからにはなりますが「リリースできない」ということがないように、デプロイをできる状態に持っていくというのを意識して改善しています。
あともう一つ、負債という話ではないかもしれませんが、やはり年々UIが洗礼されていく中で、Amebaとしても「共通感」を持たせたいというのがあります。とはいえ、全部のプロジェクトを触るのは難しいよねと。そんななか、最近「Spindle」というデザインの仕組みがリリースされました。SpindleをアップデートすることでUIのアップデートも一緒に行えて、Amebaブランドの統一感を維持していこうという、そんな動きも進んでいます。
高山：一つ僕が抱えている、嫌な技術的負債の話ができればと思います。コードの中で出てくるドメイン言語に相当するものが統一されていない問題です。作った瞬間から「この概念に対するものはこう」と、呼び方を徹底していて欲しいなと思います。
－－その時最善にやったものが技術的負債になるという話の対として、そもそも最初から負債として注入されているものもあるよね、ということですね。これは結構あるあるだと思っていて、名称なんかはごっちゃになっているというのがよく起こるのではないかなと思いました。
高山：そうですね。長い間やっているサービスだと、たとえば表から呼ばれる機能の名前が変わってしまっているとか、裏側と違うものになっているとかありますね。そういうのって、本来は後々の人がしっかりと調査しないといけなくて、気を付けないと開発スピードを出せないというのにつながってしまいます。最初から定義されていれば良かったものの、不必要にそういう状態を強いてしまうというものも、技術的負債だという風に思います。
柳：めちゃくちゃ分かりますね。アメブロも元々「読者登録」という名前だった 機能を「フォロー」に変えた時がありました。その時に、たとえば「リーダー」という名前を「フォロー」に置き換えていく作業がありまして、漏れもあったのですが、僕らの場合はレビューしてくれる人がとても細かく見てくれていて、コメントの直し忘れや参照のモデル、コーポネントの名前忘れとかを全部指摘してくれていたので助かっていました。
技術的負債等に向き合う仕組みとしての「Yatteiki」
－－1つ質問が来ています。「すでに実装されていて、前任が移動して、バックグラウンドがゼロのメンバーに引き継ぎをする場合は、どのように返済しましょうか？」ということです。チームとしての運用について教えてください。
柳：最近、新卒の子が書いた記事にもなっているのですが、サイバーエージェントのアメブロでは「Yatteiki」というキャッチーで良い名前の活動を行っています。プロダクティビティ、アクセシビリティ、パフォーマンスという3つの軸に分けて、それらを良くしていこうというチーム活動になります。
アメブロのフロントエンドエンジニアは、その3つの中でどれを自分がやりたいのか、選んで所属することができ、その中で例えばパフォーマンスで改善の余地がある部分に対して調べたことを導入するというのを、業務時間とは別にとって良いよとしています。例えば僕はプロダクティビティのチームに所属していまして、先ほど言っていた「デプロイできていないリポジトリをデプロイできるようにする」とかに対応していました。「Yatteiki」という取り組みの中で、技術的負債やそういうものに向き合う時間を“意図的に”作っています。
－－そもそも、そのような時間を作っているという合意を得ていくことも大変だと思っていて、組織の中で価値提供と技術的返済をしてく時間を設けるにあたって、どうやって合意を得ているのでしょうか？
柳：これは「Yatteiki」という活動を作った人が凄いよねという話にもなってしまうのですが、大義名分を作る上で、これが組織にとってどういうメリットがあるか、これをやることにおいてどういうリスクを軽減できるのかをきちんと言語化して、上の人とコミュニケーションするということをしっかりやったのが大きいかなと思っています。「リファクタリングしたいんです」と言ってはみたものの価値提供に関わる時間の方が大きいからダメですと言われました、というところまではよくある話なのですが、「Yatteiki」の場合はそこに留めないで、きちんと見込める効果やメリットを作って合意形成を進めていったということです。
－－ありがとうございます。技術的負債を返済していくこと自体がメリットだ、ということをきちんと伝えているということですね。高山さんはいかがでしょうか？
高山：サービスを開発していく限りは、リファクタリングと新しい機能の追加は常に良いバランスでやらないといけないので、僕たちはタスクにしてます。完全に新規開発だけの案件だったとしても機能開発のリファクタリングはするはずなので、普通に仕事の中でナチュラルに行っています。
スタンスとしては今の状況が起こったのは自分たちのせいじゃなかったとしても、なんとかできるのは自分たちしかいないわけで、なんとかしなければ良くもならないからこそ良くしましょう、という感じかと思っています。
－－技術的負債を返済するとなった時に、返済する時の「優先度」が難しいと思っていて、会社やサービスを提供している組織だと、価値提供にどんどんフォーカスがいってしまうというジレンマがあると思っています。負債を返済しないといけないけど、価値も提供しないといけないとなった時に、タスクに乗せる時の優先順位はどう折り合いを付けているのでしょうか？
高山：どれだけ良くしようとしても、漏れてしまう部分というのはあるので、改善のためのプロジェクトはここ数年のNewsPicksでは常に動いている状態です。問題が見えやすくなっているところ、あるいは次に大きな問題となり得るところが焦点になっていますね。その上で、そこに優先度を付けるという点で気をつけていることは、メンバーが挑戦しやすい環境を整えて、挑戦したいという気分が出た時にいち早くお膳立てができるようにするイメージです。
そもそも、技術的負債は何故ダメなのか？
－－次に、そもそも技術的負債は何故ダメなのかということについて、改めてお考えを教えてください。
高山：先ほどから何回か話にあがっていますが、開発を遅くしてしまうことが一番の大きな理由だと思います。本来であれば使わなくていい時間を使ってしまうわけです。もう少し付け加えると、例えば5年前くらいにこういう登壇をしたとすると、「経営陣、マネージャー、プロダクトマネージャーは理解してくれないんです」といった話になっていたかなと思いますが、そこに対する世の中の理解がすごく進んできたなと思っています。改善をしたいんですと言うと、エンジニアのみなさんも悪意をもって言っているわけではないはずなので、妥当なんだろうなという感じの話からスタートすることが世の中的にも多くなってきたなというイメージです。
そうなると次にやらないといけないことは、そのエンジニアのメンバーが、それにかかるトータルコストはこのくらいで、日々の開発のうちこのくらいの時間使っていきますという感じで、より具体的な話をしないといけなくなってきています。あえて悪い表現をすると、エンジニアにとっては今までは不満だけ言っていればよかったものが、具体案を示さないといけなくなって、より難易度が上がっているなと感じています。
柳：技術的負債というのはサイバーエージェント全体で言えることなのですが、事業課題ときちんと紐付けられているかなと思っています。例えば技術的負債を抱えていて、最近で言うモダンなコードを書けるわけではない部署があったとして、そこに対して新しく入ってきた新卒を入れてレガシーなコードをずっと書いてもらうというのは、本人のモチベーション的にどうなんだろう、成長につながるのだろうか、というところです。これは「負債を取り扱っていると成長につながらない」という意味ではなく、もう少し現代に合わせて加速度的な成長をするにはどうしたらいいのかという観点では、モダンで新しい技術に触れられていて新しいことを試せている状況が大事だと思っているので、そういうことも含めた事業課題として表現してます。
改善するためには計測が必要という話があると思うのですが、先ほど話したように、経営事業に置くためにリードタイムやデプロイの頻度、リリースごとの障害発生率を計測したりする話があって、アメブロの中で日々行っています。
参考：エリートDevOpsチームであることをFour Keysプロジェクトで確認する
－－例えばQiitaで広木さんが技術的負債について記事を書いているのですが、その中で、技術的負債は社会問題として毎月十何兆とかを機会損失として生み出しているという話があります。漠然としたダメではなく、社会問題として認知をするようになってきていることを、お話を伺いながら感じました。
高山：いま柳さんがおっしゃった中で、一人ひとりの成長や体験とあったのですが、もう一つ、セキュリティもあるかなと思います。頻繁にデプロイ・開発されているリポジトリの方がやはり対応しやすいですし、デプロイのフローが整ってなかったり、メインでやっていた人たちがもう居ないというところは、現にすごく時間がかかってしまいます。Webが牧歌的な時代だったら問題にならなかったのかもしれませんが、今の時代は営利活動をする企業の定めと言いますか、どうしても狙われる運命にあると思うので、きちんとモニタリング指標を決めて、ライブラリが最新かどうかというのを決めて常にやっていかないといけないということを、改めて痛感しています。
技術的負債にまつわる「ゴール」を考える
－－そもそも技術的負債を0％にすることが目指すべきゴールなのか。そこにずっと向き合っていく必要があると思う中で、どういう状態がゴールなのかという点についてはいかがでしょうか？
柳：ゼロになることは、僕はないと考えています。それを分かった上で、それに対してどうアプローチしていくかという手段を増やしていき、その手段の多さが組織やチームであったり、プロダクトの強みになっていくのかなと考えています。
最初の仕様に対して完璧なものを作りました、でも仕様って家の増築みたいに増えて変わっていくものなので、どこかに無理が出てくるものと考えています。その無理をどうやって吸収し続けるのかみたいな部分が、重要なポイントになるのではないかなと考えています。
高山：財務会計の話をする時に、あらゆるものは資産であり負債である、というような話をよく聞きますよね。これと同じで、一度作ったソフトウェアは会社のビジネスを回していくための資産であって、同時に世の中から借りている負債でもある。負債であるからには、いつか精算しないといけないものなんだけど、その期間には資産を生むようなものであるという考え方です。個人的には、お客様がいてユーザーがいて、使ってくれている人がいるという、その幸せの面を大きく捉えたいと思ってます。
－－新しいツールやライブラリを使う時点で前借りをしている状態に近いので、技術的負債って言葉がそこにかかってくるようなイメージなんですかね。この「前借りをする」みたいな話の際に、返済をする指標をどうするのが良いのかが、次にあるのかなと思っています。
高山：先ほどの「Four Keys」の話で、どういう風に運用されているのかが気になります。
柳：今まさに動いている最中ということで、その足がかりとしてリードタイムやデプロイの頻度など、リリース後の障害発生率を計測するところから開始していて、そこから次のアクションを練っている最中です。
改善するにはまず計測という話に近いです。たとえばSlackを見ると「このリポジトリは何週間リリースされていません」といったメッセージが流れてくるチャンネルがあります。計測した後にどうするかという話なんですが、僕らエンジニアとしてどういう部分を目指すべきなのかということを、経営層まできちんと握ってコミュニケーションをするというところまで考えている状態です。まだ握れているというわけではないですが、これからそれをやっていきます。
高山：「このリポジトリは何週間リリースされていません」は凄くリアルで面白い話だなと思いました。僕らで言うと、例えば以前は一週間に一回必ずこの曜日にデプロイしましょうと言っていたプロジェクトがあったのですが、もっとデプロイしていきたい、そのためにデプロイの手順とか自動化とかも進めていきたいと動いて、今だと一週間のうちいつリリースしても良いという風にしてきたものがあります。
それも近いような考え方で、開発したものがすぐにリリースされる状態、どんどん改善していける状態というのを理想として、デプロイの回数を増やすのが一つの成果指標、バロメーターみたいなものと思っていて、デプロイの頻度は凄く大事にしている指標です。最近はデプロイまでいかなくても、プルリクエスト作成の数など、より先行指標となるようなものも活用しています。
色々な役割をきちんと見える化して、会社として優遇していくべき
－－技術的負債に向き合っていく中で、社会的もしくは会社的に課題だなと思うところや、そこに対する取り組みも伺いたいです。
柳：今後やっていきたいことという話になりますが、アメブロでは刷新という形で大きく溜まった負債を大きく返すという、いわば大規模リファクタリングをしてきたのですが、今はリードタイムの計測をきちんとしているので、より細かく小さく返し続けるというフローができるといいのかなと考えています。
高山：今のお話もすごく良いなと思ったのですが、弊社はJavaからKotlinに置き換えていこうという話をしていまして、別の言語に切り替える中でも1ファイルずつや1クラスずつなど、少し前だったら考えられないようなやり方ができているんです。それも先ほどの話にもあったように、ちょっとずつ変えていくのがいいよねという風に世の中がなってきて環境も整ってきたからこそ、Kotlinみたいな言語が出てきて、僕らもそういう選択ができるということなのかなと思っています。
質問に戻ると、世の中や我々にとって課題として残っている部分は何かという話ですが、色々なタイプの開発者がいるということですかね。全員が技術的負債を解決しないといけないということもないですし、全員がUIを作らないといけないということでもありません。会社の中で色々な役割をきちんと見える化してあげて、責任者という形にしてあげて、感度の高い人がそこの専門家になって、会社として優遇していくことなのかなと思いました。
－－ありがとうございます。ちょうど今のお話につながるご質問がきていまして、「技術的負債に関わりたくないメンバーが居た場合、どのようにそのメンバーに対応してコミュニケーションをとっていくか」ということなのですが、最後にこれについてのお考えも教えてください。
柳：広い話になりますが、まず全体としてサイバーエージェントのエンジニアはグレード制度が存在して、専門性・戦略性・業務遂行能力・オーナーシップ・フォロワーシップの基準がどれぐらいあるかで本人のグレードが決まります。本人のやりたいことと本人のグレードを、コミュニケーションをとりながら、やってもらえるレベルに落とし込んでやってもらう。必ずやらなければいけないわけではないですが、先ほどの「Yatteiki」の中でプロダクティビティ、アクセシビリティ、パフォーマンスのどれに向き合うのかを選んでもらうかという細かい工夫を重ねて、現状だと向き合いたくないですという人は出ていない認識です。なるべく本人が「やりたいこと」と「やらなければいけないこと」をマッチさせる仕組みがいくつか存在するということです。
－－サイバーエージェントさんって、技術的負債を事業的な課題という風に捉えていると感じるので、そもそも事業課題を解決していくと、結果として技術的負債も解決しているような環境ということですね。高山さんはいかがですか？
高山：「技術的負債っぽいから自分のタスクに入れたくない」は、ありそうですね。輝いていただける部分を見つけていくとか、何かしらで輝けば良いと思うんですよ。負債解消で輝く人もいれば、ユーザー価値を出すことで輝く人もいると思います。
取材／文：長岡武司