このあとの懇親会で......。ラスト、もう1問会場からいただいて、懇親会の準備に移らせていただきますが、もし質問がある方がいれば。返済の話ばっかりだったんですけど、技術的負債は積み上がるものだという前提のもとで、自分の書いたコードが良いコードだったとしても5年後にはクソコードになっちゃうよねと場合に、技術的負債の良い積み上げ方。積んでいくと後で返済しやすいかみたいなところで、気を付けていたこととか。いうふうに技術的負債を積んでおけば後で解消しやすいよねみたいな。いう気を付けているところがあれば教えていただきたいなと思います。うちの場合は、けっこう僕がいろんなコードを残しちゃっているので、その不平不満を僕が受け止める。(会場笑)福村:そういうところですかね。質問者4:ありがとうございます。福村:けっこう「なんでこうなってるの?」みたいな感じで言われたら、やっぱり当時の状況とかがあるんですけど、突っぱねる感じではないんですけど、説明は簡素にして、「これからの話をしよう」っていう感じで......。(会場笑)福村:未来志向型で。福村:結果、今僕がそのプロジェクトを牽引しているんですけど、そういう感じでやるのがいいんですかね。藤倉:基本的に僕は、個人的には持論としてドキュメントを残すみたなことは好きではなくて、すべてがソースコードのアーキテクチャで表現されているという世界が好きなんですね。ソースコードレベルで、致し方無いこの実装を、例えば周辺コードと同じマナーでやることに違和感はあるが、1ヶ所だけ別の方式にすることのほうが圧倒的に違和感があるのであれば「それに倣っておきます」って1行コメントが書いてあれば、後から見た人はたぶん納得できると思うんですね。アーキテクチャレベルになると、なかなかソースコードだけでは解読できなかったり、将来のアーキテクチャのロードマップってさすがにドキュメントにしないと難しいので、そういうアーキテクチャドキュメントとかは残していいのかなと思います。それこそメンバーの方のモチベーションとかエンゲージメントとかでいくと、将来のロードマップが引かれていれば、ちょっと安心できるじゃないですか。この暗闇がずっと続くのか、ちょっとしたら光が見えてくるのか、というのはあるので、アーキテクチャで言えるところで言えば、ここで切ってこれぐらいのタイミングでここまでを置き換えていこうというのは書いたりすることはありますかね。将来の計画と今の負債を意図的に積み上げるんだったら、返済計画も一緒にセットにしてプルリクにも書くとか、そういうことはしたりしますかね。質問者4:ありがとうございます。みなさんまだまだ質問したいことがあるとは思うのですが、いったんこちらでセッションを終わりとさせていただきます。お二人に拍手をお願いします。PLAYに関する記事をまとめています。PLAYに関する新着記事が公開された際に、通知を受け取ることができます。