新しいものをやる時にどう決められているのか？
白石久彦氏（以下、白石）：最後のお題にいきたいなと思います。「負債の返済、守りと攻めのバランス」です。先ほど（のセッションでは）「バランスとかじゃねえよ」みたいな話にけっこうなっていましたね。
川口将貴氏（以下、川口）：そんな言い方してましたかね。怖い怖い（笑）。
（一同笑）
白石：「（バランス）じゃねえよ」みたいな話がありましたが、一応負債の返済的なものを「守り」、新規プロダクトを作るのを「攻め」という体で書きました。
確かに別にそこで分ける必要はないかなと思うのですが、先ほど、やはりどちらかというとお客さんに価値を提供することが重要で、それが「攻め」で、新しいものを作っていくのもそうだし、守りの中でもより良い体験を与えられるように攻めを定義してやっていくという話があったかなと思います。
そのあたりの、新しいことにあたっていく時の技術の使い方をうかがえたらおもしろいのかなと思います。先ほど、もともと資産として持っているものが積み上がっていくというのがあって、それを活用する・しないという判断と、新しい技術で遊ぶという話もありました。新しいものをやる時にどう決められているのかをうかがいたいと思っています。アンドパッドさんから「テックリードが」というお話があったかと思いますが、いかがですか。
下司：基本はテックリードの「Design Docを書いてもらって」みたいなところと、言語特性は、例えばデータベースもいろいろな特性があるかなとは思うので、「実現したい要件って何だっけ？ それはこの技術選定で叶えられるんだっけ？」というところはDesign Docでレビューしていますね。そんな回答でいいですかね？
白石：大丈夫です。Design Docは提案を含めて書いて、その作るものに対して適切であれば「やってみたらどう？」という話になるんですか？
下司：そうですね、適切であれば。「どんな観点でチェックしましたか？」みたいなことは一通り書いてもらいます。
白石：Design Docでレビューするのは会社の仕組みとしてあるんですか？ それとも随時必要がある度にやる？
下司：必要がある度にやっているのと、それでも必要がある度に言えない人もいるので場所としても一応準備していますね。
白石：そのあたりの取り組みでBASEの川口さんはどうですか？
川口：新しいものを導入するための特別な手引きはあまりなくて、BASE自体がけっこう小さな単一サービスなので、新しい技術をあえて導入することはそこまで多くありません。基本的にVue.jsだけで、「ここの画面だけReactを使いたい」という瞬間はあまりないです。
「この管理画面側をReactにしたい」のほうが、「これからの技術的負債になる」と思っていたりするので、Design Docでレビューまでは形式ばっていませんが、どういうフローで、最終的なゴールはどこでみたいなところをけっこうフラットに会話をしている部分があります。
あとは僕の領域で専門外の部分は、けっこう任せたりしています。テックリードに関しては、わりと自由にやってもらっても心配ないかなと。モチベーション管理の部分も細かくしなくていいので、良いと思っています。
例えば、バックエンドのフレームワークをリアーキテクトとかでやっていますが、リプレイスしますという時にはけっこう長く時間がかかります。いろいろな観点で、採用観点もそうだし今のメンバーのスキルセットもそうですが、そこはリアーキテクチャが終わっていない分、まだ正解が出ていないですね。
白石：言語は学習していかないといけないところが、なかなか難しいところですよね。
川口：そうですね。僕は学習コストといった表現をしがちですが、そもそもエンジニアはそれなりに高い給料をもらっているので、コストというか普通に「それはインクルードだよ」と言います。「学習するのも仕事だよ」と。
白石：それはいい言葉ですね。やはり学習は続けていかないとという話ですよね。
SmartHRさんは、先ほどサービスのポートフォリオみたいなやつがすごくいっぱい出ていたと思いますが、基本的には固まったテックスタックで、プロトタイプも全部作る感じなんですか？
森住卓矢氏（以下、森住）：そうですね。基本的にだいたい一緒で、ものによってNextが使われている・使われていないという部分があるぐらいですかね。
白石：では、そのあたりはそんなに技術選定の議論にはならないですか？
森住：そうですね。そんなに突飛なものが上がってくることはないかなと思いますね。
白石：そのRailsでやっている基盤の部分も、しばらくはRailsでやっていく感じなんですか？
森住：そうですね。プロダクト特性に応じてという話があったと思いますが、今のところはそんなに「このプロダクト特性だったらRailsから離れなきゃね」みたいなものはないので、しばらくは続いていくかなと思っています。
白石：そうなんですね。ありがとうございます。
プロダクトの人たちが技術的負債に対して理解がない場合はどうするか？
白石：楽しく話していたら時間が迫ってきてしまったので、会場のみなさんから質問をいただいていればお答えしていきたいと思います。上から行きましょうか。いいね順とかにしてみて。
これにしましょう。「非エンジニアサイドに対して、どのように技術的負債や設計を説明していますか？」。どなたか、プロダクトの人たちが技術的負債に対して理解がない場合のコミュニケーションのプラクティスがあれば。
川口：最近はチームによってですが、ドメイン駆動設計を導入しています。ドメインモデリングは当然エンジニアだけでやるべきものではないので、仕様を決めているプロダクトマネージャーも入れて「こうやっていきましょう」「こういう障害があります。それはなぜか」「こういう技術的負債があるから」とやっていますが、それらを精緻に理解できているとはもちろん思っていません。
エンジニアも技術仕様じゃない部分、つまりドメイン仕様で理解できていない部分もあるので、そこはいいのですが、ただ「こういうものがあるので、ここを課題と感じている」というのをチームの課題として捉えるようにはしてもらっていますね。そこに対してそれを解消するコストは普通に時間ですよね。それと、それを得られるリターンはエンジニアとPMで話をして意思決定してもらっている感じですね。
白石：ありがとうございます。
akippaのリニューアルで諦めたものは全部捨てた
白石：違う質問にいってみましょうか。なにかありますか？ 「akippaのリニューアルで諦めたものは全部捨てましたか？ 部分的に継続したり導入したりしていますか？」。これは村上さんに答えてもらいたいです。
村上健一郎氏（以下、村上）：akippaのリニューアルで諦めたものは、基本的には全部捨てていますね。Laravelの部分的移行を始めた時に、Laravelを動かすローカル環境のVagrantみたいなものは残しましたが、今はそれも捨ててDockerに移行しているので、今はもう全部ポイッてなっていますね。
白石：またそこからやり直しみたいな感じになるということなんですかね。
井上：Laravelで移行を採用していこうとか、そのへんの方針は活きていますし、そのタイミングで改めてサービスをどう伸ばしていこうかというのは今の企画に活きています。確かにソースコードは消えてしまったのですが、思想、考え方、企画などはまだ残っていますね。
白石：ありがとうございます。
遠心力とは何か？
白石：これは下司さんへの質問かもしれませんが、「遠心力とは何ですか？」。僕も気になったのでちょっと解説をお願いします。
下司：先ほど言ったように「3年後に10倍にしていこう」みたいな話がある中で、そこまでいきたいよねみたいな話をします。その時に、開発速度という話のところで共通基盤をどんどん作っていって、車輪の再発明をなるべくなくして「本当に実現したい機能になるべく早くいけるようにしたいよね」と言っています。
遠くまでなるべく速く行く力をどう表現するかという時に「遠心力」という言葉を使ってみた感じです。
白石：ありがとうございます。わりと中長期のものをきちんと見ていこうという感じなんですね。
下司：そうですね。
各社が考える、技術的負債の定義とは？
白石：あとは「技術的負債の定義」です。先ほど「ヒトじゃないですか？」みたいな話がいろいろあったので、みなさんに技術的負債を喩えていただくのもいいのかも。難しいですか？
（一同笑）
白石：森住さんはどうでしょう？ 技術的負債とは何ですか（笑）？
森住：喩えですか？
白石：定義でも何でも。
森住：そうですね。名前のとおり技術的な借金かなと思っていて、なんらかの都合で犠牲にした変更容易性すべて、みたいなイメージですかね。
白石：変更容易性。
森住：そうですね。コードの変更容易性ですね。
白石：なんか家を買う時みたいになっちゃうけど、いろいろな制約を許容して借りてしまった負債なんですね。
森住：そうですね。
白石：川口さんはいかがですか？
川口：僕も基本的なのは当然前借りさせてもらったものだと思っているので、その中でも光を浴びていないものが負債だなと思っています。どんなに良くないコードやイケていない設計でも、光を当てて手を入れているのであれば、それを負債と呼ぶのは少し違うかなと思っています。放置されていたり、見ないようにしている部分は負債になっているので、そういうところを考えないといけないと思っています。
白石：良い定義ですね。ダメだけどメンテしてなんとか使っていこうというのは負債というよりは生きているものだし、そうじゃないものは光が当たっていないこと自体が問題なんじゃないかということですね。ありがとうございます。下司さんは、負債はどうですか？
下司：ほぼ同じですが、「変更にすごく時間のかかる、つまり変更容易性が非常に下がっているものが負債ですよね」と言っていて、特に、その変更容易性を改善するためにどう改善していくのかというところの道筋も見えにくいものたちを、技術的負債と言っていますね。ただやりにくいだけだと、それは技術的負債じゃなくてただの実装ミスぐらいの感じなので、そういうところを僕らは技術的負債と言っています。
白石：「何じゃこりゃ」と悩んじゃって「もうどうする？」みたいなかたちになるのが技術的負債。
下司：そうですね。
白石：ありがとうございます。時間もそろそろいい感じになったので、最後にみなさんから一言という感じで、村上さんにも技術的負債を話してもらって締めてもらおうかなと思います。
村上：先ほど変更容易性の観点をお話しされていましたが、1つ具体的に言うと、テストコードがないところが負債かなと思っています。テストコードがないから、どこに影響が出るかがわからない、なんでそうなっているかがわからない、というところがたくさん残っているので、今新しく作る部分はテストコードをマストにしています。
どんなに急いであっても、それはマストにしています。なので技術的負債といったら、テストコードがない部分のすべてという意味だと僕は考えています。
白石：影響範囲が見通せないところが怖いというのがエンジニアとしてはあるわけですね。ありがとうございます。お時間をちょっと長めに取っているのですが、すみません、答えきれなかった質問があるので、懇親会に残っていただける方はそこでぜひ聞いてください。
今日はいろいろな名言が出てきたなと思うのですが、「攻めとか守りじゃねぇんだよ」みたいな話がそうですね。
（一同笑）
白石：確かにすごく「そうだな」と思いました。あとは負債にきちんと向き合っている中でのモチベーションの管理が僕的にはやはりすごく興味があって、そういう視点でハッピーエンジニアリングができる人が増えていくといいかなと思いました。ということで、この場は締めさせていただきます。ありがとうございました。
（会場拍手）
