00:00
こんにちは、言語化.fmです。言語化.fmは、あんな話やこんな話をキリンと伊達の2人で緩く話しながら、言語化を試みるポッドキャストです。
というわけで、本日のテーマは、伊達さん、何ですか。
何でしたっけ、えっとね、この直前に打ち合わせをするのに秒で忘れるっていう。
何だっけ、あの散歩歩くと忘れるって何のやつだっけあれ。
散歩、わかんねえなあ、犬かな。
忘れちゃった、なんか道具ついたよね、まあいいや。
今日は負債の話をしようかなと思ってます。
熱いですね、ちなみに負債ってまあいろんな意味があるかなと思いますけど。
僕が別にお金に困ってるとかそういう話ではなくてですね、ソフトウェアを開発していくにあたって、どうしても開発には負債がつきものなんですけど、
この負債とどう向き合うかという話を言語化したいです。
やっていきましょう。
いやもう多分、数多のエンジニアたちが言語化を試みてきた劣等者の領域なんですけども。
多分ね、負債は返した方がいいよねって言うと、それはそうだよねっていう話にしかならんので、やっぱりどうして負債が生じるのかと、
あとどうして負債は返済できないのかっていう話と、
じゃあその負債にどういう心構えで向かうべきかという話にぶっ返してお話をするといいかなと思っているんですが。
めちゃくちゃ良さそうな分解ですね。
ね、なんか見切り発車の割にはすごい良さそうな展開だよね。
台本が手元にないんで、アドリブで喋ってますけど。
まあそもそもね、負債が、あ、ゆう子みなさんどうぞ。
そうですね、その3つの分解で言うと、1個目は結構パッと浮かんできた、おぼろげに頭の中に浮かんできた言語化がされた文章があるんですけど、
なぜ負債は生じるのかに対する答えは、パッと思い浮かんだから喋りながら考えるが、
負債を抱えるソフトウェアや組織やサービスが進化し続けるから負債が生まれるというのを個人的には思っている。
その心は、まあそうですね、10個中10個のケースはそうとは言わないけど、
大抵のケースではエンジニアの手腕とか組織の、組織やチームの能力に依存するものの、
そのタイミングタイミングで作ってるものっていうのは、100点は取れずとも80点90点、90点だったら相当良い方か、
60点70点くらいの回答はどの組織も出せてるんじゃないかなと思っていて、
03:06
それは本当に正解がない話で、その場面でそのメンバーで事業のフェーズとかサービスのフェーズを考えたら、
これが良いよねみたいな意思決定を多分、面場面では各々ベストを尽くしてできてるんだが、
それが何かいつか負債になったりすると。
それが負債になるのはなぜかというと、めちゃくちゃシンプルで状況が変わるからで、
例えば、何ですかね、分かりやすい例あるかな。
なんか、親の顔より見た光景あるあるとかは、
例えばその事業的にこれPOCなんで、半年後に捨てる前提で作っていいですよみたいな、
なんでスピード優先で作りましょうみたいなんで作って、
その状況下では確かにそれは正解だし、
悪い意思決定じゃないんだが、半年後に蓋を開けてみたら、
例えばそのサービスが思ったより上手くいって、
なんかお客さんの引き合いとかが強くなって、
その捨てる暇が状況的に許されなくなって、
元々捨てる前提で作ってたものを捨てないっていう、
全然別のコンテキスト上で運用し始めてしまって負債になるよねとか、
なんかそういうような、今のは一つなんですけど、
変化に、僕たちの書いたコードは変化に適応してくれないので、
適応していかないものは基本的には負債になってくるんじゃないかなと思ったんですが、
いかがですか?
その事例はね、いろんな現場で起こってるね、それはね。
マジで100回思ったけど10回は見た気がするな。
見たな、それは。
スタートアップっていうのは最初にまずPoCを作って、
それがプロダクトマーケットフィットするのかみたいな、
PoCをプロダクトマーケットフィットするのはさすがに乱暴すぎるけど、
ファーストリリースしたものがPMFするかっていうのを検証していって、
よっしゃマッチしたみたいな、ある種の錯覚であるとは思ってるんだけど、
とりあえずこれでいけるなってなったらそのままスケールさせようと、
あの手この手を尽くして頑張るんだけど、
それにソースコードの進化が追いつくかというと、
まあそうではないのでっていう事例がね、いろんな現場で起こってますね。
起こってますね。
あとはやっぱり、基本的には状況の変化な気がするな。
多分優秀なエンジニアとかだと、
それを見越して行動をかける人材も一定数はいる気がするし、
自分も個人的には結構そこを、
なんか、いつきっかけかわかんないね。
いつきっかけかわかんないけど、結構強く意識して、
できてるかどうかは別として意識してやってると自分で自分を評価してるんだけども、
06:04
やっぱり予測できないことが起きることも往々にしてあるし、
ほぼほぼ予測通りにはなんないから、
その辺はすごい、
不採が生まれるっていうのはある意味、
なんか組織が前のフェーズに進んでるってことなのかなっていう気持ちですね。
コードが書いた時から不採になるとはよく言いますけど、
よく言いますね。
じゃあ我々ぐらいの、
なんていうか能力のある、自分で能力あるっていうのはすごいキモいけど、
能力がある人が備えてるものってやっぱそういう将来の不採に対するセンサーみたいなものは、
やっぱりあって、書き捨て前提でも、
極端にひどいコードって我々書けないじゃん、もう。
書けないですね。
いろんなアンチパターンが、そうそう。
自信が出るみたいなアレルギー反応を起こしちゃうんだよね、そういうのを書くと。
だからもうそもそもそういうのがだんだん書けなくなるのと、
あとなんか、
仕様を考える人から、こういう仕様にしたいんだけどっていうものが飛んできたときに、
もうそういう、ある種けしからん仕様が入ってきたときに、
この仕様でいくとこういう事故が起こるよっていうのはもう過去の経験とか、
いろいろ予測が立つので、
そこでもうアラートがガンガンガンガンなってですね、
どうしてこの仕様をこのまま受け入れるといけないのかっていうのを、
ある種論議的にその提案者に説明ができるんですよね。
その能力がないっていうか、そういう経験がない人は、
いやこれなんか誰かがなんとなくこれダメだって言ってたような気がするんですけどみたいな、
だいまいな否定の仕方しかできないので、説得力がないんですよね。
だからその、開発経験を積んでそういうアラートを備えるっていうのと、
あとそのアラートをもとに相手にちゃんと説明ができるっていうその行言がないと、
そういうのを阻止できんのやろうなという感覚があるよね。
確かに。いやー確かにな、説明能力めっちゃ大事だな。
しかも基本、いやー、まあなんか場合によるけど基本的にはやっぱその、
なんか引きの要件の領域の話がどうしても多いじゃないですか。
その仕様があって、受け入れ条件があって、その受け入れ条件通りに動けば、
究極なんか、なんだろうな、
まあそのビジネス的にはゴールラインには乗ってるけど、
まあゴールラインには乗るんだが、
まあまあなんか、ここで3日で適当に作るんではなく、
1週間かけて作っとかないと、1ヶ月後に2週、
09:01
まあ1ヶ月、わかんない、1ヶ月後に2週間編載しなきゃいけませんよみたいなのを説明するってなった時に、
その、そうだね、説明能力大事っすね。
なんか、いやでもどう説明してるかな自分は。
そうね、なんかよくやるのは、
なんかよく持ってこられる仕様っていうのは、
もう割と目がヒットしてる大きな会社のアプリとかの機能を引き合いに持ってこられて、
このアプリがこうやってるからっていうのをよく言われるわけなんですけど、
それはそのアプリを作った時のベストプラクティスであって、
時代と標準は常に動いているので、
その時の標準を持ってこられても、
こっちとしては、いやそれ今標準じゃないんでっていうしかないんだけど、
じゃあ何がスタンダードなんですかっていうのも、
ちゃんと的確に言えなきゃいけないと最近よく思うわけですよ。
なるほどね。
スタンダードとは何かっていうのを、
スタンダードがその時代によって、
だんだんだんだん新しい方に動いていることに気づかずに、
前これでやったからこれで通るはずだっていう、
指向的な仕様の組み方をすると、
それはだんだんだんだん動いてるスタンダードから離れていって、
結果不再現になってしまうと。
不再現もなるし、すごい前時代的なものになってしまって、
前時代的なものになると、
エンジニアの標準はだんだんだんだん先を行ってるので、
古いものを眺めている気持ちになると。
なるほどね。
そういうケースも確かにあり得るね。
ケースとしては、
作る時点で不再現になることが確定してる系の仕様なりで、
それに仕様提案してる人が気づいてないパターン。
なるほどね。
運良く俺はあんまりそういう場面はそんなに多くなかったけど、
でも世の中的には無限にありそうだなという気がするな。
そうね。
自分はそれを作った時に無かったけど、
後から入ってみたら、
すごい古めかしいコードがあるなっていうのは、
分かりやすく不再じゃん、それは。
なんだけど、もう一種類あるのが、
自分が長らくそのコードをメンテしていて、
自分自身が古くなっていることに気づかないっていうパターンもあるんですよ。
なるほど。
それはちょっと、自分そうかもって思うと怖いな。
まあでもあり得るパターンだよね。
12:00
全然あるなと思ってて、
同じ組織に長らくいて、外部刺激がない環境にいた場合は、
今自分がやってることがだんだんだんだんスタンダードと信じてされていくわけじゃないですか、社内的には。
だからそれに対して別に文句を言う人もいないので、
普通に文句は言われないんだけど、
そういうことを言ってくる人もいないので、
じゃあこの標準でいいんだってなるんだけど、
世の中的にはもっと標準はどんどんどんどん先に常に動いていると。
そこのギャップに気づかなくて、
外から入ってきた人が何これめっちゃ古いじゃんっていう風な感じかな。
その古いじゃんみたいなのは、
利用的なところもそうだし、どっちかというとソフトウェア的な話の方が多いのかな。
そうね。
アーキテクチャーとか。
アーキテクチャー。
多分エンジニアが感じる古さっていうのは、
まず目に入るのはそっちじゃないかな。
なるほどね。
もちろんそこが出しているサービスの根本的なレイアウトとか、
広告の出し方とか、
そういうパッと目につく機能要件だけ見ても、
いやこれはちょっと前時代的ですね、みたいなものはどうしてもあるんだけど。
まずエンジニアが検知するのはソースコードじゃないかな。
そう、なるほど。
いやー。
隠して不採は生まれると。
不採、そうだね。不採は生まれるんだが、
気づいたら不採を。
なんか、まあそうだな。
個人的に一番理想論の開発は多分、
不採は、不採を作らないっていうのはもう個人的には不可能だと思っていて、
ただ、
じゃあ不採になるまでの賞味期限がなるべく長いコードを書くみたいなのは、
能力次第とかチームの取り組み方次第でできると思っていて、
それを常にし続けるのが、
まあ、俺が今んとこ考えてる最適解なんだが、
今のラテッシュの話とかは、
なんか、分かんない、その人がどういう意識、
分かんない、別に具体的な人がいるわけじゃないと思うけど、
そういう場面があった時に、その実装する人がどういう意識なのかを回させておき、
まあ、本当は不採に不採を積み上げるなんてしない方がいいに決まってるんだが、
まあ自分で気づかずにそれをやってしまってるパターンがあるみたいな感じですよね。
そうね、前提として、わざわざ不採を作りたい人はいないという前提はもちろんあって、
だし、ビギナーだろうがベテランだろうが書いたコードには賞味期限があって、
ビギナーというか、よく分かってない人が書くコードの賞味期限はもちろん短いんだけど、
15:04
ベテランが書くコードが未来永劫腐らないかというとそんなことは全くなくて、
ちゃんと賞味期限はあるんだけど、他の人に比べるとまあ長いかなみたいな感じなので、
何が言いたいかというと、結局不採を生まないようにするためには、
常に返済をし続けなければいけないという話なんですよね。
生まないっていうか、増やさないっていうか。
そうそうそう。
まあどっかのプロダクトによって違うだろうけど、絶対に敷地があるよね。
もうここまで行ったら、もうやべえぞっていう、
やべえの語彙力がなくてやばいけど、まあ多分いろんなパターンがあって。
たぶんね、検知できるまでにある程度敷地が存在していて、
たぶんもう書いた瞬間からどんなコードでもどんどん不採になる種はもう植えてあるわけですよ。
それがだんだんだんだん、開発が進んでいくとそれが育っていって、
で、あるとき誰かが気づくわけですよ。
ここなんかちょっと違和化した方がいいなっていう気づきがまずあるわけですよ。
で、その気づきの目をそのまま、じゃあ今度余裕があるときに直そうかっていう風にして、
一旦見なかったことにしちゃうのか、
それともじゃあこれはちょっと時間をとって済んだ方がいいねっていう風になるのかで、
たぶんその不採のたまり具合がたぶん変わってくると思うんだよね。
要はその機能開発と不採の返済をバランスよくやっていかないと、
どっちかに偏ると、
例えば機能開発を一旦止めて不採を返済しましょうってなったら、
当然その事業はそこで一旦止まっちゃうわけだし、
かといって事業開発に振りすぎるとそれは不採がどんどんたまるので、
要はそのバランスをうまいことやりましょうという話なんだろうなと。
理解しました。
いやーなんかちょうど思い当たりじゃないけど、
そういえば最近考えてたのは、
今の不採が生まれる、なぜ生まれるのかっていう話と、
不採をなぜ返済できないのかみたいな話。
2ステップ目だと思うんだけど、
返済できないみたいなところで、
個人的にすごい難しいなって最近思ったのは、
なんだろうな、返済すべきラインが、
まあでもそうだね、
今ちょっと頭の中でバーって考えちゃったんだけど、
何を考えてたかっていうと返済すべきラインを見極めるのが難しいなということを結構思っていて、
それどういうことかっていうと、
例えば感覚として、
今のソースコードで半年経ったらやばいとか、
18:00
各々の経験とか、
持ち合わせるスキルから裸でそういう判断をすることができるし、
そういう声をチームとかに対して上げることはできると思うんだけど、
そういうイシューをレーズして机に並べたときに、
じゃあそれってどのくらい返済しなきゃまずいんだとか、
じゃあなんかお金って例えばそれっていくらぐらいの借金なんだっけみたいなのを、
なんか結構正しく評価したり、
みんなで共通認識揃えるのがめちゃくちゃ難しいなという気持ちがあって、
例えば、なんか俺はめっちゃやばいと思うけど、
なんか同僚は、いやこれあと2年ぐらいいけるっしょって思ってるみたいなときに、
なんかそこどう擦り合わせるのかとか、
それがなんかチーム2人とかだったら別に協議すればいいけど、
なんか返済の規模感によっては、
開発チーム全体で取り組まなきゃいけないよねみたいなときに、
じゃあその開発チーム全体で取り組む価値があるんですかみたいな、
そのコストに対してリターン見合うんですかみたいなのを、
どう表現、それこそどう言語化するべきなのかっていうのは結構個人的に悩ましいなと最近思いましたね。
で、そこに対して一つの会話はさっき伊達氏が言ってた、
そもそも多分、なんかヤバくなるまで放置しないっていうのが基本的な理想だし、
不再返済って営みを開発のサイクルに組み込んでいくのが理想ではあって、
それができていれば、
そういうデカい意思決定、
返済をするって意思決定の重さが重くなることをちょっと遅らせることができるんじゃないかっていうのを、
今ぐるぐる考えてました。
そうね、なんかその辺で言うと、要はその人によって捉え方が違うって話だけど、
多分一番ヤベェなと思ってるのは、その不再の種を発見した人なんだよね。
なんでかって言うと、その人はその不再が生まれる経緯を知ってるわけですよ。
ここに根本があって、ここなんかおかしいなと思って、ソースコードをどんどんどんどんディグっていくと、
根本的にヤバそうなところが、そういうコードスメールがあるわけじゃないですか。
それを見つけて、そこを見つけたのでヤバいって言ってるんだけど、
その表層的なところ、この辺がちょっとヤバそうですって言ってしまうと、
他の人から見ると、なんかこの程度だったらいつでも潰せそうじゃんみたいな見え方をしてるわけですよ。
たぶんそこでその温度感が変わってくるんじゃないかなっていう。
あとはその経験とスキルによって変わるんだろうなっていう印象がありますね。
なるほど。それで言うと難しいのは、
たぶんその塞いを見つけたメンバーのメンバーというか、
21:01
塞いを見つけてそれを返済すべきだと思ったメンバーの責務は、
なぜその塞いを返済しなければいけないのかっていうのをきちんと言語化することをたぶんしなければいけないんだろうなっていうのを今の話聞きながら思ったんだが、
全員が全員その能力があるかというと、
それはまた難しいなという。
何より自分がそういうのをうまく、
最近、
今、クォーターと呼ばれる1年を4分の1した末、クォーター末なんで、
ちょうど自分の1月か3月の仕事を振り返って思ったんですけど、
その辺うまくできないことあったなみたいなのを思ったりして、
何が言いたかったんだろう、難しいなという気持ち。
説明対象によるかなと思っていて、
同じコードを触っているエンジニアに説明するのが結構簡単なんですよ。
コンテクストが共通なので、
そこやべえよなって分かる、そこやべえわっていう風にたぶんなるし、
あとスキルの関係によっては、
スキルが上の人がいれば、
その人に言えばだいたい話が通じるみたいなところもあるじゃないですか。
なんだけど本当に真に説明しなきゃいかんのは、
プロジェクトを管理しているマネージャーだったりとか、
あともうちょっと上にいる人に対して、
こういうふさいがあるので、これだけ工数がかかるので、
今やらねばなりませんということを言わなきゃいけないわけじゃないですか。
そうすると思っているコンテクストが違うのに、
絶対に施策を優先してくれみたいな風に向こうは思うわけじゃないですか。
みたいなバランスを取っていかなきゃいかんので、
結構説明するのは骨が折れるよねっていう話もあるんですよね。
確かに。それも100回見てきた景色やな。
仕組みからしたいな、個人的には。
2ステップあって、1ステップは同じコンテクストが共有できているエンジンに対して、
一緒にレーズして認識を揃えて、
その次にその事業を握っているステイクホルダーとか会社に対して、
それの大事さを説得するみたいな2ステップが本質的だし、
多分一定正しいアプローチだなと思いつつ、
頭では分かっているけど、それができないんだよっていう、
机を叩いているリスナーの人がすごい一歩でいるだろうなみたいな気持ちになって、
そうやってなんか仕組みで営みできないのかなみたいな、
昔、何かどっかで聞いたGoogleの2,3年リファクタ話をちょっと思い出した。
はいはいはい。
24:00
何かね、それを多分都度やるとすごい疲弊するので、
要はその不細が出てくるために、
その経営レイヤーまで説得するのは結構骨が折れるので、
そういうのをやると、
僕がその技術顧問で見ている組織で、
これ上手いなと思ったのがあって、
要はキャンプという期間を設けるんですよ。
1ヶ月とか定期的なスパンで、
1スプリント分を気になっていた技術的なことをやるとか、
そういうのをやると、
あとその溜まっている不細を返すとか、
ちょっとアーキテクチャを見直すみたいな、
割とエンジニアが自由に使っていい期間というのを設けて、
そこに関しては、
新規の機能開発とかは差し込まないようにするみたいな取り組みを
前者的にやっているところがあって、
そうすると、
その2週間、
別にどんな不細を返済しようが、
別に音が目なしなわけですよ。
もちろんソースコードに、
ソースコードの改善に寄与するという明確な目標は前提として、
要はエンジニアに対して好きなことをやっていいと思うわけですよ。
そうすると、
個々が抱えているソースコードに対する問題についても、
そこに関しては、
エンジニアに対して好きなことをやっていいと思うわけですよ。
そうすると、
個々が抱えているソースコードに対する問題に向き合ってみるとか、
最近流行りのこのアーキテクチャーを試して、
アーキテクチャーを試すのはちょっとデカすぎるけど、
フレームワークを試すとか、
そういうことができるので、
そういうのをシステム化している会社は結構いいなと思った。
なるほどね。
なんかそのシステム化した、
なんか自分も過去に似たような仕組みがある会社に行ったこともあるけど、
なんかその仕組みを一番最初に作った人を、
めっちゃゲストに呼んで話を聞いてみたい。
なるほどね。
一番最初のステップとして、
多分それをやるためには、
まあその期間は会社によって違うだろうけど、
2週間、例えばクォーターごとに2週間くれみたいな。
2週間事業を止めるけど、
2週間事業を止めるだけの価値がこの期間にありますみたいなのを、
まあ多分、まあどうだろうなわかんない。
いろんな政治をしている会社とかもあるのかもしれないけど、
会社とか経営が本質的にそれを理解してくれてないと、
そのどっかのタイミングで、
なんかそうだね、
なんか止まっちゃったりしうると思うんでね。
例えばその前者的に、
こんなビジネスイシューが出てきて、
もう機能開発めっちゃ優先しなきゃやばいみたいになった時に、
なんかその圧力に負けないだけの説得力を、
その仕組みに持たせる必要があると思ってて、
で、なんかそれを、
なんか遂行できた、
まあその技術顧問先の会社の人とか、
27:00
他の会社の人にコツを聞いて、
真似して、
4月から自分のチームに入れたい。
どうやってるんだろうな。
まあでも、ねまい強く説明してるんだろうなとは思うけど。
そうね。
なんかそれがそもそもそんなに入る会社っていうのは、
そんなに大きな問題は起きてないのだろうと思っちゃったりもするんだよね。
そもそものエンジニアリング文化があるってことだから。
なるほどね。
確かにな。
確かに。
それもそうやな。
こういうポッドキャストを通して、
会社を回してる偉い人たちに、
啓蒙していかなきゃいけないですね。
このポッドキャスト、会社の偉いさんが聞いてるかどうかはまた別問題。
いやー、ちょっとそうだね。
もうちょっと、
そうだね。
ちょっと成長していきましょう。
頑張ってポッドキャスト。
社長にも届くようにね。
社長にも届くように。
スタートアップ界隈のCEOたちに。
ね。
まあでもそうだな。
そういう仕組みはいいよな。
いやー。
試そう。
試そう。
試そうっていうか、
いや、試す話は、
実は社内、
社内っていうか僕のチームであったんですけど、
忙しくてできてなかったんで、
やっていきたいな。
うん。
そうなんだよね。
忙しいから後回しにしようってものが基本的には不在になっていくので、
うん。
まあ本当は忙しくない程度に働くというのが、
一番いいはずなんだけどな。
そうだね。
もう耳が痛いね。
そんなハードワークしてる。
自分で言いながらね、
自分も忙しいので。
なんか忙しいとその、
マインドシェアとらえるのが良くないよね。
なんか、
物理的な時間で、
多分、
私もそうだと思うけど、
なんか、
月30時間残業してますとか、
そういう話ではないと思っているんだけど、
やっぱその、
なんかゆとりがないと、
その、
自分のマインドシェアが、
目先の仕事に取られ続けてしまって、
なんかふとした時に、
あ、これやってねみたいな、
ふうになりがちだなと思うからやっぱ、
ゆとりが惜しいですね、きちんと。
なんかね、多分よく勘違いされてる話は、
あの、スクラム開発でその、
2週間とかをワンスプリントにして、
うん。
回すじゃないですか。
うんうん。
あれはもちろんその、
生産性を最大限に高めるための仕組みでもあり、
その、
工場的に今どれくらいのベロシティなのかっていうのを計測して、
それに応じたポイント数のチケットを振って、
チケットやタスクを振っていくという仕組みだけど、
あれの本質は多分その、
30:02
まあ、
積んどいたチケットがスプリント内に消化できたら時間が空くわけじゃないですか。
うんうんうん。
その時間は好きに使っていいよってことが、
僕は本質だと思うんですよ。
なるほど。
うん。
なるほどね。
そうすると、
チーム全体としては、
一定のポイント数のタスクが消化できてるから、
ちゃんとやるべきトゥールーバー進んでるじゃないですか。
うんうんうんうん。
なんだけど、余った分っていうのは、
そこに次のスプリントの新しいタスクは詰めないので、
手が空いてるなら好きなことやっていいよっていう風な、
ゆったりしたっていうかその、
うんうんうん。
何でもいい時間だと思うんですよ。
なるほどね。
そういうのを積み重ねていって、
余剰時間が生まれたらそこでその、
ちょっとした付際を返してみるとか、
普段手がつけられないことをやるみたいな。
うんうんうん。
なるほど。
面白い、面白いなあ。
なるほどっすね。
なんか面白い話だなって思ってて、
何でかっていうと、
僕が今まで、
そのチームで、
なんかまあいろんな形があったけど、
やってきたスクラム開発では、
それをやったことがなかったなと思って、
なんか、
余ったら次のスプリントに詰んだりしてた。
でもなんかそれって、
なんだろうな、
スクラムっていうフレーマークの、
まあフレーマーク分かんないな、
皆さんがどの教科書を読んでスクラムしてるのか分かんないけど、
なんか俺が知ってる、
アジャイルサムライとかですよね、
スクラムブートギャンプとかも、
めちゃくちゃ有名なテンプレート本とかには、
なんかそういう仕組みってない、
ないっていうか、
そういうことしましょうみたいなの書いてないのかなって思ってて、
見逃してたら俺がアホでしたって話なんだけど、
一方でなんかその仕組みを自分たちの意識で入れたっていうのが、
まあなんか今の話の本質な気がした。
なんかちょっとずつ編成していくために、
このチームでどういう仕組みで入れていきましょうかみたいなので、
技術コモン先はキャンプって形だし、
私の昔のチームではその余った時間を充てるっていう。
この話はどっちかというと、
なんか僕が勝手に個人的にやってた話だから、
過去にいたチームで正道化した話ではないけど、
まあきっかけはGoogleとかが言ってる20%ルールの話だよね。
業務時間の20%は自分の興味関心の高いことに使っていいっていう。
あれを聞いたときに、
ちょうどスクラムをやっていて、
これってそのベロシティがちゃんと取れていて、
そのスプリントの上で消化すべきポイント数を消化したら、
もう自分でタスクが積まなくていいことだよなってことに気づいて、
それで余った時間を作って、
そこでいろいろやり始めたっていう。
なるほどね。
33:02
面白いな。
一つの回答やね。
定常的に負債返債に取り組むとか、
一周に向け合う時間を作る一つのハックな気がする。
まあそれでも負債はやっぱり貯まるので、
やっぱり負債を貯めないっていうことはやっぱりできない。
まあ疑心みたいな問題だからね。
コードを書くと疑心がついて、それがなんか溜まっていくので、
どこかでその棚を押し的に返さなきゃいかんっていうのは発生するんだけど、
貯めない努力はやっぱ必要で、
貯めない努力とはやっぱり返し続けることなのではという。
めっちゃ綺麗に、
なんか俺の中では結構綺麗に構造化された気がする。
負債は読まれますと。
まあなんか能力とか立ち回りによってその負債の賞味期限を伸ばすことはできるが、
まあ基本的には全て負債。
まあちょっと極端な言い方だけど、負債なので。
じゃあなんかそれをどう返却するかみたいなことを考えたときに、
まあ貯めるスピードを進めるためにちょっと打ち返すっていうのをやろうねっていう話と、
まあそれでも多分いつかは貯まるタイミングがあるから、
そのタイミングを伸ばさずにまたノルシアしましょうっていう感じですね。
確かにな。そう貯めるスピードを遅くするっていうのはめっちゃ大事だよな。
そうね。賞味期限を伸ばすためにもそれはやった方がいいんだと思うわ。
うーん。
それはあるな。
何も考えてなかったら病で負債になるからな。
あとよくある、まあまとまった上で話すと、
多分負債のサイズにもいろいろあって、
手付ければすぐ返せるちっちゃいやつと、
時間をがっつりアーキテクチャレベルで検討しなきゃいけない大きな負債っていうのがあるから、
多分それぞれの着手する時期が多分全部決まってて、
ちっちゃいのはさっき言った余剰時間でやればよくて、
でっかいのはそれこそクォーター単位で着手すべきかどうか判断するみたいな、
そういう風になるんじゃないかなと個人的には考えてるこの頃でございますね。
なるほどですね。
いやー、明日からまた元気に働けそう。
そうね。
いやー、生まれたり増えたりする前提で取り組むマインドはすごい大事な気がするな。
経営層には絶対負債は生まれるんです。
しょうがないんで、定期的に返す必要がありますと、
あなたたち…
今のちょっとカットカット。
了解。
36:02
まあみたいな感じで、はい。
いいな、ちょっと派生して別の話も言語化していきたいが、
まあ今日はこんなところですかね。
はい。
いやー明日から元気に、
まあ元気に負債返済するぞって言うとちょっと語弊があるけど、
まあ明日からも元気にソフトウェア開発やっていきましょうって感じですね。
そうですね、バランスよくやっていきましょうという感じで、はい。
ではでは、じゃあ皆さん、
負債返済苦しんでる方、DM待ってます。
DM待ってんだね。
返すかわかんないけど。
返すかわかんないけどね、そうだね。
返すかわかんない。
じゃあそんなところで今日は負債返済を話をしました。
はい。
ではでは、さようなら。
ごきげんよう。
ごきげんよう。
