認証認可システムのリノベーションチームに所属する岸直輝氏
岸直輝氏：それでは「リライトプロジェクトを安全・効率よく進めるための取り組み」というタイトルで発表いたします。よろしくお願いします。
初めに簡単に自己紹介したいと思います。名前は岸といいます。インターネット上では「p1ass」というIDで活動しています。DeNAには2021年に新卒で入社しました。現在は、認証認可システムのリノベーションチームに所属をしています。
好きなプログラミング言語はGoですが、最近は業務でJava、TypeScript、Perlといった言語を触っています。最近は、DevOpsだったりDeveloper Experienceだったりといった、開発者体験みたいなところに興味を持っています。本日はどうぞよろしくお願いします。
さて今日の発表ですが、このような流れで進めていきます。初めに、タイトルにもあるリライトプロジェクトがいったいなんなのか、という点について説明したいと思います。
その後、今回の主題である安全かつ効率よく進めるための具体的な取り組みを紹介したいと思います。最後に今後の展開やまとめをお話しして、このセッションを締めようと思います。
リライトプロジェクトとは何か？
ではさっそく本編に入っていきましょう。今回のリライトプロジェクトがいったいなんなのかを知っていただいたほうが、セッションを聞く上で話を理解しやすいかなと思うので、初めにリライトプロジェクトについて簡単に説明しようと思います。
リライトプロジェクトを一言で表すと、「長年運用してきた大規模サービスを新たに刷新するプロジェクト」です。そもそものプロジェクトの背景ですが、私たちが運用しているサービスは、開発開始から8年が経過していて、2023年で9年目に突入しています。この8年間の開発の中で多くのエンジニアが開発に携わり、さまざまな機能追加や仕様変更が行われてきました。
具体的な規模感をお伝えするために、今回の発表に合わせてリライトプロジェクトの対象のレポジトリのコード行数を調べてきました。テストなども含めると、35万行以上のコードが含まれていて、かなり成長してきているものになっています。
しかし、こういった長年の開発の中で度重なる仕様変更が行われてきたこともあり、現在のPerlで書かれたコードベースは、理解容易性や変更容易性の観点で課題を抱えていました。
「このサービスの運用期間がもうすぐ終わる」「そんなに長く運用していくことが想定されていない」のであれば、こういった課題感があったとしてもそのままでよいと判断できると思うのですが、今回の対象のサービスは認証認可基盤なので、その特性上比較的長い期間運用されることが想定されていました。
その他にもさまざまな課題があり、こういった状況を鑑みた結果、新たなコードベースに書き換えるほうがよいのではないかという判断になり、リライトプロジェクトが始動することになりました。
このリライトプロジェクトによって、技術スタックは大きく変わりました。プログラミング言語はこれまでPerlを使っていたのですが、これからはJavaになります。またWebフレームワークは今までAmon2というものを使っていたのですが、これからはRed Hat社がメインでメンテンナンスをしているQuarkusというWebフレームワークを使うことになりました。ここまでがリライトプロジェクトの概要です。
目指したのは安全かつ効率のよいプロジェクト
次に、私たちがこのリライトプロジェクトにおいてどういうプロジェクトの進め方を目指しているのかについて、お話ししようと思います。
リライトプロジェクトは、基本的に外部仕様を変えずにシステムを再実装する方向で進めています。もともと存在している仕様書やテストケースに明記されていない使い方をしている利用者がいるので、そういった中で挙動を変える実装をしてしまうと、思わぬ箇所で影響が出てしまう可能性がありました。そのため、このリライトプロジェクトでは、利用者へ提供する機能や挙動は基本的に変えられません。
とはいえ、コードベースを新規に実装し直す、つまり一新するわけなので、意図していない挙動差分やバグが埋め込まれてしまうのは十分考えられます。このような不具合を発見できずにリリースまでしてしまうと、利用者に迷惑がかかってしまいますし、大きな問題にもなってしまいます。
そのため、いかに事前に不具合を潰して利用者に影響を出さないかが、このプロジェクトを進める上での鍵になってきます。この発表では、利用者に影響が出ないことを安全と捉えて、いかに安全にリリースできるように開発を進めていけるのか、についてお話しすることを1つのゴールとしています。
一方で、安全性を重視しつつも、できるだけ効率よく開発を進めていきたいとも考えています。安全性ばかりを重視していると、例えばチェック項目などが増えてしまって、リリースまでにかかる開発の期間がどんどん長くなってしまいます。それではせっかく今リライトをしているにもかかわらず、その恩恵をなかなか受けることができなくなってしまいます。
どういうことかと言うと、リライトプロジェクトを進める中でも、並行して機能開発を行わなければいけない、という状況がありました。リライトしたコードベースがリリースされていなければ、その開発者たちは、理解容易性や変更容易性が低い、古いコードベースの開発を並行して続けなければいけません。
せっかくリライトによって、生産性が高い新しいコードベースを作ろうとしているのにもかかわらず、自分も含めた開発者がその恩恵に与ることができないのは、なかなか勿体ないかなと思います。
そうはなりたくないので、できるだけ効率よく開発を進めることで、リライトの恩恵を早く受けられるようにしたいと思いました。以上の2つをまとめると、安全であることをしっかり確認しつつも、効率よくリライトを進められること。これが私たちが目指しているプロジェクトの進め方です。その目標に向かって行ってきた取り組みを紹介するのが、今回のセッションの趣旨になります。
開発において大事にしている「Shift Left」という考え方
ではここからは、安全かつ効率よく開発を進めるために行ってきた実際の取り組みについて、より踏み込んでお話ししていきたいと思います。その前に、今回の発表で大事にしている「Shift Left」という考え方について、みなさんに紹介したいと思います。
Shift Leftは、「ソフトウェア開発におけるなんらかの作業をできるだけ早期に行えるように前倒ししていく」という考え方です。数直線上において、過去は左に書かれることが多いので、Shift Leftと呼ばれています。
このソフトウェアの開発では、アジャイルであれウォーターフォールであれ、ある程度要件が決まった後は設計や実装をして、テストやQAを行った後にリリースするという流れになります。
その工程の中で、リリースよりはQAのタイミングで、QAよりはテストのタイミングで、テストよりも開発のタイミングで……というふうに、できるだけ前のタイミングで（バグを）発見しよう、という考え方になります。
今回の発表では、Shift Leftという単語を「不具合の発見」という文脈で使っているのですが、セキュリティなど他の分野でも使われている言葉です。
「Shift Left」が提唱されている理由
では、なぜShift Leftという考え方が提唱されているのでしょうか。これは問題の発見のタイミングと、その修正にかかる時間の関係性を見るとわかってきます。
一般的に問題は、発見が遅くなればなるほど、その修正にかかる時間が長くなると言われています。（スライドを示して）グラフで表すとこういうかたちで、発見のタイミングが遅くなれば、それだけ修正にかかる時間は遅くなってしまいます。
裏を返せば、問題の発見までの時間が早くなれば、その修正にかかる時間は短くなります。短くなればそれだけ修正コストや時間を削減できます。
これがShift Leftの考え方の最大のメリットです。不具合を発見しつつも、その修正工数を削減できるという、安全面と効率面を両立できる考え方になっています。
（次回へつづく）
