開発者体験を悪化させる方法は選択せず、要件を見据えて開発する　“開発当初のエンジニアがいない”状況下での、技術的負債解消のための検討

澤氏の自己紹介

澤道人氏：今回の（イベントの）テーマが技術的負債というところなので、「開発者体験から見える技術的負債」についてお話ししたいと思います。よろしくお願いします。

最初に自己紹介です。澤道人と申します。DMMには2015年に入社しています。さまざまな部署を渡り歩いてきて、2021年8月からオンラインサロン事業部にエンジニアとして参加しています。趣味は、走ったり山に登ったりというような感じです。

本セッションのアジェンダ

今日お話しすることです。「技術的負債ってどんなことだっけ？」というところから、オンラインサロンで実際に発生している実例を紹介して、どんな課題があるかだったり、どうして今こうなっているのかを見ながらいきたいと思っています。最後に今後どうしていきたいか、みたいな話もできればなと思っています。

技術的負債とは

「技術的負債とはどういうことか？」というところで簡単に検索すると、Wikipediaとかで引っかかると思います。「時間がかかるより良いアプローチを使用する代わりに、今すぐ簡単な（限定的な）解決策を選択することで生じる追加の手直しの暗黙のコストを反映したものである」となっていました。

技術的負債はいろいろとあると思いますが、結果生み出されたものとしてはコードの負債だったり、設計の負債だったり、テストの負債だったり、要件の負債だったりがあるかなと思います。

オンラインサロンのシステムの開発を進める上での課題

ここからは、オンラインサロンの開発を進めている中で、「ちょっと良くないな」とか「効率が悪いな」みたいなところの実例を見ながら紹介したいなと思っています。

まず、どういった機能で「効率が悪いな」と感じるかを紹介したいなと思っています。

サロンのオーナーがオンラインサロンを開きたい時に、まず何をするかというところでは、「オンラインサロンを開きたいんです」というところから始まり、「ユーザーにどんなサロンかを伝えて、入会してもらうためのページを作りましょう」というかたちで、サロンの紹介ページを作ることになります。（スライドを示して）実際の入会ページは（スライドの）右側にサンプルが貼ってあるので、（そちらを）確認してもらえればと思っています。

中身的には、ざっくりとこのサロンで何をするかということ（の説明）とか、注意事項みたいなところの記載があって。あとはサロンに入会するボタンがあるかたちになっています。

これ自体はオーナーさんが管理画面から入力することで作成できるんですが、オーナーさんからすると、実際にユーザーさんがどのように見えているかが気になるところです。

その場合にDMMからどのような案内をするかというと、「管理画面から入会ページのプレビューを見ることができるので、プレビュー機能を利用して確認してください」というご案内をしています。（つまり）ざっくり「プレビュー機能がありますよ」というかたちになっています。

プレビューの開発だけではなく、オンラインサロンのシステムの開発を進める上でどんな課題があるかを紹介したいと思います。

まず前提として、コード管理（について）です。「Git」のリポジトリが分割されています。分割されている単位としては、オーナーが利用する管理画面。あとは、ユーザーが利用する管理画面というかたちで分割されています。

コードの管理が分割されているんですが、「オーナーの管理画面からユーザーが利用する入会画面をプレビューとして閲覧したい」という要望（を叶えたもの）になっています。

この仕組みですが、ユーザーが利用する入会画面に変更があった場合は、そのコードだったりCSSだったりをオーナーが利用する管理画面に取り込むという処理をしていたりします。取り込む時にちょっとした変換や変更が入っていて、元データの取得元の変更をちょこっと入れているような感じになります。

（これによって）何が起こっているかというと、入会画面に変更が加わることで、その都度、管理画面にも取り込む必要性があるというのが1つ。あとは、取り込みの時に処理の変更が発生するので、その修正も必要になっているというところで、開発者体験の悪化が発生しているかなと思います。

あと、これは実際にけっこうある（ことな）んですけど、取り込み自体を忘れちゃって、管理画面と入会画面で差分が出ちゃっているということも発生しています。そんな課題があるということを前提にお話ししたいと思います。

そもそもなぜ今のような構成になっているかはわからない

今、なんで管理画面と入会画面が分かれていて、それぞれにコード取り込みをしなきゃいけない構成になっているのか？　というところがあるかなと思っています。実際、開発当時のエンジニアが異動していたり退職していたりで、わからないというのが現状です。

おそらくですが、リリースに向けて（の段階で）時間がなかったり、「入会画面ってそんなに更新は入らないよね」と思っていたり。あと、「コード取り込みって、取り込むだけだからすぐじゃん。簡単じゃん」みたいに思っていた可能性もあるかなと推測しています。

もしかしたらほかに理由があったかもしれないけれど、わからないことで悩んでもしょうがないので、次に進みたいと思います。

現状どのように対応しているか

現状どうやって対応しているかです。入会ページの変更があるたびに、オーナー管理画面のプレビュー機能に変更を取り込むという対応をしています。

これは先ほどちょっとお話ししましたが、入会画面に急ぎの変更とかが入った場合に、取り込み漏れが発生することもちょこちょこあるような状況になっていて、差分が発生したりしています。

この課題に向き合うために、今開発グループでやっていることとしては、取り込み漏れを発生させないために、実際のタスクのテンプレートに（スライドに記載した2つの）チェックを入れています。その（2つの）観点で影響範囲調査を実施したかという確認を含めていて、プレビューの修正の必要性があるかどうかを確認しています。

対象画面、入会画面に変更があった場合は、プレビューの修正をタスクに追加する作業をして回避しているかたちになります。

ただこれは入会ページに関係ないタスクだったとしても、一瞬プレビューのことを考えなきゃいけないところがあって、タスク作成時の体験がちょっと悪化しているかなと感じています。

今後どうしていきたいか

今後どうしていきたいかというところですが、管理画面にコードの取り込みをやめたいなとは考えています。これはなぜかというと、コードの二重管理を廃止したいというのはもちろんですが、取り込み漏れの発生もさせたくないというのがあるので、その抑制もしたいです。あとはタスク作成時の影響範囲の調査みたいなところも、なるべく考えないで済むのであれば、考えないほうがいいかなとは思っています。

コードを取り込むだけではなくて、オーナーの管理画面から入会ページを直接参照する仕組みにすれば、ある程度この課題はクリアできるんじゃないかなと考えています。（ただ）実際にそれをやった場合、ほかの課題が見つかりそうだとは考えています。

どういった課題が見えてくるかというと、複数の異なるオーナーがいるので、ほかのオーナーのプレビューを見せたくない。もちろん見えちゃいけないとは思うし、見せたくないというところ。

あとは、ユーザーに作りかけのプレビューページを見られるという危険性があること。これももちろん、検索エンジンにもインデックスさせたくないというところもあります。そのほかにも、「あくまでプレビューだけをさせたい」という機能になるので、入会ボタンだったり、リンクのクリックもできないようにしたいと考えています。

PC用のプレビューとスマホ用のプレビューに分かれているんですが、今はPC用のプレビュー画面を立ち上げて、確認して、閉じて、その後スマホ用のプレビュー画面を立ち上げて、閉じて、というようなかたちになっていて。オーナーの操作の体験的にはあまり良くないかなと思っているので、1画面でPCとスマホのプレビューを切り替えられたらいいかなと思っています。

いろいろ考えてみたところ、ほかの課題もいくつか見つかってきて、少し考えただけでも「プレビュー機能」という単純な言葉の裏に、いくつかの要件が隠れているなということがわかるかなと思います。

開発当初もいろいろと考えた結果、「今の解決策を取るしかないね」みたいなかたちで進んだんじゃないかなと予想できます。課題はいくつかありますが、大枠は見えてきたので、少しずつ課題を潰して効率的に開発を進められるようになるといいかなと思っています。

開発者体験を悪化させる解決策は選択せず、要件を見据えて開発する

本日のまとめになります。コードを二重管理したいと思っているエンジニアはおそらくいないと考えています。コードの二重管理は、やはり開発者体験を悪化させるなというのが正直なところです。

ほかに、要件がけっこう単純な言葉……。今回の場合では「プレビュー機能」みたいな単純な言葉なんですけど、当たり前の要件で（すがその中には）「他人に見せたくない」（という）要件が隠れている。

このあたりも（考えると）見えてくるかなと思っていて。当たり前の要件が課題になって、（その課題に対して当時は）簡単な解決策を選択した可能性がある（の）かなと思います。ざっくりとしたまとめは以上です。技術的負債を残したいと思っているエンジニアは、ここにいるみなさんを含めていないと思うし、要件を決める時に課題をきちんと洗い出すことは必要だなと感じました。

あとは、限定的な解決策が後に響くことはよくあるし、開発者体験を悪化させてしまうので、なるべくそういった解決策は選択せずに、きちんと要件を見据えて、課題を潰して開発をしていきたいなと思っています。

本日の発表は以上となります。ご清聴ありがとうございました。