技術的負債解消に対する人やチームの充て方は？
白石久彦氏（以下、白石）：あとは「負債と向き合う」というところです。なにかissueが発生した時にどのように向き合っているかというところで、先ほどSmartHRさんの例で、負債解消チームを暫定で作ったり、今はスタティックでやっているというお話もありましたが、そのあたりの人の充て方もイメージがあれば聞いていきたいなと思います。順番に下司さんから。
下司宜治氏（以下、下司）：最初の攻め10割から守りを始めた時は、さすがに専門チームを作って、そこに注力をしました。今は一応あるといえばありますが、「プロジェクトとしてやっていくぞ！」みたいなところはそんなになくて、あまりやっていなかったりします。
ただ、人によって課題に思っているところは違うので、社内で定期的に「解決とかはいいから、ただ課題に思っていることをしゃべろうぜ」みたいな会議はやっています。その中で「なんかこれはまじめに向き合ったほうがいいよね」というものがあれば、向き合い方を考えるみたいなことはやっていますね。
白石：ありがとうございます。課題認識からしていかないといけないので、今akippaでも課題をとりあえず話し始めてみることはやっています。非常に参考になるなと思います。ありがとうございます。川口さんはいかがですか？
川口将貴氏（以下、川口）：そうですね。うちは技術基盤のチームを作っていて、やはりそこのマネージャーも僕なんですけど。
白石：（笑）。兼務がメチャクチャ多いですね。
川口：そういうところもやっているから、いつまでたっても「忙しい」と言われていてちょっと悩んでいるんですけど。そういうチームに影響が広範囲に渡る場合は任せる部分が多いです。ただ、チームが持っている機能で出た負債を解消したいのであれば、ぜんぜんチームに任せてやってもらっていますね。
「DBの移行が必要になってくるよね」みたいな、負債というか災害に近いものは広く各チーム、SREチームや基盤チームや、場合によってはプロダクト開発チームからも人をアサインしてやっています。
白石：影響範囲によってあたり方を変えているというところですかね。そういう負債解消チームを組成するタイミングはあるんですか？
川口：あまりないですね。もちろんEOLなど期限が決まっているものがあれば、当然やらざるをえないので、きちんとやりますが、そこに対してはわりとマネージャーがOKRなどで管理をしているので、「今Qの〜〜さんの目標の中に入れたいんですけど」というような話やコミュニケーションをマネージャーとしています。
一応僕もそこはオーソライズをするか、あとは「別のチームで機能リプレイスがあるから、そこの負債を解消したところで、3ヶ月後にはリプレイスされちゃうからあまり意味ないよね」など、そういうコミュニケーションはしていますね。
白石：そうなんですね。ありがとうございます。
技術的負債を解消するチームのモチベーション管理・維持はどうしているか？
白石：先ほど森住さんが「SmartHRは負債解消チームがある」みたいな紹介をされていて、モチベーションの話がすごく興味深くて「本当にそうだな」と思いました。モチベーションの管理・維持は、ミッションを持たせてみたいな感じでやっているんですか？ そのへんを聞きたいなと思いました。
森住卓矢氏（以下、森住）：そうですね。負債解消チームはかなり限定的にやっていて、全体的に負債を解消しましょうという感じではないんですよね。最初にお話ししたとおり、従業員の履歴管理機能がけっこうやばいです。なので「そこを集中して直そう」と言っていて、そこを直すことでどれぐらいの事業インパクトがあるのかみたいな話も、PMを立ててやっているので、ある種の機能開発に近いモチベーションでやれるとは思います。
ここを解消すると、変更容易性によってユーザーにメリットがあるよねとか、本当にわりと全社的に注目を集めている負債なので、そんなにモチベーション管理に困ってはいないはずです。逆に本当に「何でもやります！」みたいな感じだと、モチベーション管理にすごく苦労するだろうなとは思います。
白石：では相当絞ってきちんとゴールを設定して、PMもいて、それでその成果をきちんと伝えてあげる。普通といえば普通のことをきちんとやっている感じなんですね。
森住：そうですね。あとは、そもそも固定のチームを作っているのは、先ほどお話ししたように、そんなに理想的だとは思っていないので、ゆくゆくはなくせるといいなと思いますね。
白石：ありがとうございます。そこのチームの中にマネージャーがいるわけですよね。
森住：そうですね。
白石：それは向いている人をアサインするんですか？ そうじゃなくて、その負債に近い人みたいな感じですか？
森住：わりとそこに向いている人をアサインしています。履歴管理の機能に詳しい人や、シンプルにRailsやActive Recordに詳しい人をアサインしますね。
白石：やはりそういう人選があって、そういうチームを作っているんですね。ありがとうございます。
各社における、技術選定の自由度とガバナンスは？
白石：溜まりがちな負債の話はいろいろ話せたので、次にいこうと思います。「技術選定の自由度とガバナンス」というテーマです。
エンジニアの中には、いろいろとチャレンジしていきたい人も多いと思います。ばらけたテックスタックは、技術的負債につながるかもしれないという話で、会社としてもきちんとうまく回していくために、変に「守る」よりも、どんどん技術的に「攻める」こともあると思います。その中でどのあたりまで自由にやらせるか。何がダメか。先ほど似たようなことを聞いてしまった面もありますが、そのあたりの話をうかがっていきたいなと思います。
akippaの井上さんが先ほど「フレームワークがいくつかばらけています」みたいことをお話ししていたので、そこの状況を軽くakippaチームから紹介していただければと思いますが、村上さんお願いできますか？ PHPのフレームワークが中心だけど、いろいろあるという話ですよね。
村上健一郎氏（以下、村上）：そうですね。akippaはサービス開始が2014年です。当時いたエンジニアが得意で一番よく使っていたZend Frameworkというフレームワークを使って開発を進めたのがスタートです。アプリAPIは、協力会社さんに開発をまるっとお願いしました。「akippaではこのフレームワークを使っていない」とかは言わず、その開発会社の得意なフレームワークが唯一それでした。
そのフレームワークを導入した時は僕もいなかったのでわからないのですが、そういう理由で、おそらくコードレビューもせずに、まるっと開発をお願いしていた状況です。リニューアルの時は、当時のいろいろなフレームワークの中から「これから主流になってきそうなPHPフレームワークは何だろう」と、チームメンバーで相談をしてLaravelを採用して半年ほど進めたのですが、頓挫しました。
ですが、1画面ずつでもいいから新しいフレームワークに入れ替えていこうと、ALBのパスルーティングを使って、例えばこのトップページだったらLaravelとか、検索画面だったらLaravelとか、それ以外だったらZendにという感じで、1個ずつ画面のリニューアルを進めて、徐々にLaravelに進めている状況です。アプリでも同じくそのように進めているのが現状です。
白石：ありがとうございます。
「1画面ずつでもきちん進んでいるだけで、貴い」
白石：こういう状況を防ぐためにはどうしたらよかったのか？ をみなさんに相談していきたいなと思います（笑）。難しい話になるかもしれませんが、質疑応答も入れて、どう困っているのかを聞いてもらってもいいかもしれません。下司さん、どうでしょうか？
下司：そうですね。LaravelやZendのバージョンは全部一緒ですか？
村上：LaravelとかZendのバージョン……。
下司：PHPのバージョンですね。
村上：PHPのバージョンも違います。Zendは2014年ぐらいから始まったので、あまり大きな声では言えないバージョンを使っています。
（会場笑）
村上：Laravelに移行を開始したのは2017年ぐらいなので、今やEOLを迎えたバージョンになっていますね。
白石：他のパネラーのみなさんも、もし質問やツッコミがあったら突っ込んでいただいて。
川口：1画面ずつでもきちんと進んでいるだけで、すごいなと思います。だいたいこういうのは途中で頓挫して、さらにもう1個生まれちゃいそうなので。新Laravelとか……。
（会場笑）
川口：「今度はGoで書こう！」とかで3つ目が生まれちゃうケースも見るので、気合いを入れてとりあえずまとめようとしているのは、それだけで貴いと思います。
白石：貴いですか（笑）。SmartHRさんも、RailsはRuby一択みたいなところもあって、わりとばらけにくいかもしれませんが、他のものが入ってきちゃったりとかは、以前はあったんですか？
森住：なかったんですよね。正直Ruby一択になっているという、本当にわりとそれだけなんですよ。
白石：油断したら違う言語でこうなっているかもしれないみたいな。
森住：そうですね。どうなんだろう。可能性としてはなくはなかったのかなとは思いつつ、難しいですね。フレームワークの流行り廃りはわからないですからね。
白石：バックエンドはけっこうアレですが、フロントエンドは本当にもっと選択肢があったり、メチャクチャになりがちですよね。ということで、じゃあどうすればよかったか。
技術スタックにおける各社の考え方
下司：ちなみにアンドパッドはもっとすごいですよ。
白石：そうなの!?
（会場笑）
下司：RubyとGoと、サーバーサイドでNode.jsが動いていて、フロントはVueのNuxt系とReact系の全部が動いていますね。あとはAngularもあります。一通りかじりました。
白石：遊び放題ですね。
下司：遊び放題です。
（一同笑）
白石：それは、バージョン管理は？
下司：テックリードに任せていて、「なるべくEOLを迎える前にやろうぜ」という話はしていますが、EOLを迎えているものもちらほら。
白石：ちらほらあると。そこは下司さんが一覧みたいなものでモニタリングしているんですか？
下司：さすがにスプレッドシートとかでは管理はしていなくて、Dependabotががんばってくれていたりするので。そこでがんばっていただいているのですが、PHPで揃っているだけ幸せなんじゃないかなという気がします。
白石：まさかの「意外と悪くないんじゃないか」という回答が。
井上直登（以下、井上）：安心しますね。
白石：そうですね。「自信を持ってやっていきましょう」みたいな良い材料になる話ですね。
井上：アンドパッドさんはそれを揃えようみたいな話にはならないんですか？
下司：まったくならないですね。
白石：そうですよね。Goを入れて直すみたいな話も、Node.jsもそういう流れがあって。
下司：Node.jsは昔の勢いで入れちゃったやつですね。
（会場笑）
川口：2013年、2014年ぐらいのですよね。
下司：そうですね。
川口：話題になった。 Expressが出た時に売れそうだなと。逆にPHPが嫌な人は採用できないんですよね。うちもPHP採用企業なんですが、転職ドラフトなどで「PHPを書きたくないのでお断りします」と言われてしまう、ということが3ヶ月に1度くらいはあります。
でも、「Goとかで遊ぶ場所があるんです」と言うと、気になってくれて話を聞いてもらえる。スカウトの時点で切られちゃうと、あまり詳しく説明ができないまま終わっちゃうので、全部が統一されている必要はそこまでないのかなと僕は思っていますね。
白石：遊びの部分がなく、ずっとPHPでLaravelに粛々と移行しているだとモチベーション管理がけっこう難しいので、そんな感じですね。SmartHRさんの視点は？
森住：Rubyは「Rubyは死んだ」と毎年言われているので、毎年死んでいますね。毎年恒例で「Railsは終わった」という話があるし、実際に求職者の中にも「Goはやっていないんですね」みたいな人も一定数はいるので、Rubyで揃っているのは弱みでもありますね。
白石：ですよね。エンジニアのキャリアやスキルの幅を考えると、複数言語をやっていったほうが絶対に得なので、そういう意味でもメンバーにチャレンジさせられる環境が揃っているのが良い感じがしますね。ポジティブに捉えると、ここからそういう世界に持っていくというチャレンジをしてもいいのかなと思いましたね。
川口：言語はわりと適材適所な部分もあります。なので、遊びもそうですが、単純にパフォーマンス要件やプロダクトのために、あえて言語を変えてなにかを作るのも技術選択としてはあったほうがいいかなと思いますけどね。
白石：確かに。ちょっとその視点で聞いてみたいんですが、スタックがばらけると「学んでいけばいいじゃん」みたいな話がありますが、例えば、やっていた人が辞めちゃって保守しなきゃいけない場合、やったことがない人がやるとなると大変かなと思います。そういう状況になって困ったことはありますか？
川口：まぁ、いっぱいありますよね。
（一同笑）
川口：だからコードが残っているとうれしいなと思うのは、だいたいLambdaです。Lambdaで直接AWSのコンソール上にコードが書かれているところに当時行ったので。仮に新しい技術をやるのであれば、CI/CDをきちんと組んでもらうのは絶対に言っています。フローが決まっている状態にするというか。
白石：アンドパッドさんはけっこうばらけているという話ですが、そういうリスクや責任はテックリードに寄っていくんですか？
下司：一応許可はしているので最終的な責任は来ます。いなくなってすぐは、やはりどうしてもリスクはあるんですけど。先ほど川口さんが話していましたが、CI/CDが揃っていれば一通りはなんとかなるだろうな、行動が早ければなんとかなるだろうと思います。うちもLambdaはいろいろありましたね（笑）。
白石：直書き系はということですよね。SmartHRさんもフロントやそういうところでいろんな言語があるのかなと思いました。
謎のパーツが生まれてしまったことはない
白石：派生した話になっちゃうのですが、そういう技術スタックでやっていた人が抜けちゃった時の手当てはどんな感じでやっているんですか？ 採用で全部なんとかするんですか？
森住：SmartHRでは本当にあまり人が抜けなくて。
白石：良い企業アピール。
（一同笑）
森住：事実として、今のところ起こったことがないという感じですね。
白石：へー。「誰かが飛んじゃいました」みたいな話はぜんぜんないんですか。
森住：ないですね。誰かが突然いなくなって謎のパーツが生まれてしまったことは、今のところ特にないかなと思いますね。
白石：バックエンドはRubyで統一されている盤石感プラス人が飛ばないから、あまりそういう課題にならないということなんですかね。
森住：そうですね。フロントエンドのディレクトリ構造は、差分はあれどReactやTypeScriptで基本的に統一されているので、フロントもそんなにないかなという感じですね。
白石：なるほど。ありがとうございます。
（次回へつづく）
