リファクタリングの原則
中身、どうしましょうかね。短いから、頭からやっていきますか。
ブリーフィングについて。ブリーフィングについてって、この本についてみたいなところを冒頭で話してる話があるんですけど。
そうっすよね。機能開発とリファクタリングデザイン的なことを同時にやろうとか、ましてやデザインを修正するんやっていって、開発を長期間止めるとか、ダメだぞとか、
同時にやるのもダメだし、どっちかにかかりきりになって、なんか長い間が空いちゃうのもダメだよとかっていうのが、最初にこの本、このブリーフィングのネタバレとして書いてますね。
そうですね。今までのソフトウェア開発っていうのは、機能も作ったらその後リライトするとか、デザイン修正のためにわざわざ中断する。
そういうようなことをずっと繰り返してきたから、そうならないようにしましょうねっていうことですね。
そこのブリーフィングについての指名のところで、デザインとか構造を良くするっていうこと自体はソフトウェアデザインって呼んでて、
新しいフィーチャー作るっていうのを開発っていうふうにこの機械翻訳だと言ってるんですけど、ソフトウェアデザインを開発にミックスすることはモノクロの問題の一つではない。
あなたのチームは今日のニーズと明日の機械のバランスを取るために、あなたの判断、視点、構想を必要としている。
詳しくはtidyfirstを参照するかkentbeck.gmail.comまでっていうふうに書いてますね。
え、メールしたら教えてくれるの?みたいな。
仕事待ってるよってことかもしれないね。
そうですね。講演しますよって。
そうそう。
実際言ってることはわかるし、我々もリファクタリングとか、最近で言えばtidyfirst、tidy整理整頓とかって大事だよねって思ってるけど、
上からは早く機能をリリースしてくれっていうプレッシャーが来る中でリファクタリングとかやってます?
リファクターはやってますけどね、一応ね。
ちっちゃい会社なんで、僕がいるのはそんなに。
時間の使い方は自分で決めてねみたいな感じなので。
ただ、全体的に今ある行動をやろうぜっていうよりかは、本当にtidy的な世界観になるのかな。
今から触るここで、ちょっとこれが邪魔だから道筋つけとくぐらいの感じですかね。
それはやってる。
言いながら自分の命が削れていってる感じが今めっちゃしてるんですけど、
まあまあまあ、全然必要な時はやってる。
必要じゃねって思った時にやってるって感じですね。
リファクタリングの時間っていうのを明確にとりますよとかっていう感じではないです。
実際多分時間くださいって言って、なんでってなって一時説明するより、勝手にやってるほうが実際楽だし、
リファクタリングとかtidyとかで言いたかったことのレベル感で考えたら勝手にやっておいてよっていうことになるぐらいの修正なんだろうなっていうのは自分は思ってるんで。
テストコードで、このテストをあんまり今となっては価値がないなっていうものを捨てるとか、
次着手する知らない機能に触らないといけない時とかはテストコードちょっと直してみたりとか、
既存のコードにコメント追加してみたりとか、アレイって書いてあるとこにアレイシェイプで肩書いてみたりとか、
そういうことからちょっとずつ始めていくと後で意外とコードを読むし、頭の中に入るし、意外と効いてくるんだよなっていうのもあったりとかして。
そういうの勝手にやってコードにコメント書いてぶっ壊れることはほぼないと思うので、メタプログラミングしてない限りは。
そういうことから始めていけばゆくゆくは、なんとなくこの辺が肝なんだなとか、この辺にちょっと難しさが集まってんだな、
弱項を直そうとしたらどうすればいいんだろうなとかっていうことがだんだん頭に入ってきて上手にリファクタリングできるようになっていくんじゃないかなみたいなことは最近ちょっと思ってますね。
確かに自分でこういうことなんじゃないかっていう感じでコード書き換えてみると、その機能というか内部実装について理解が深まるっていうのは本当にありますよね。
で大体テスト回したらぶっ壊れて、なるほどここに技があるのねみたいな。そのためにわざわざこのイフがあるのねとかっていうのが気づいたり気づけたりとかして。
だったらじゃあこうした方がいいんじゃないとか、俺だったらもっとうまくできるみたいなことをやっていくと気づいたら上達していくみたいなのは絶対あると思ってるんで。
そうなんですよね。
そういうのは時間くれって言ってもくれないので、勝手にこそこそとやるしかないんだよなっていうのを同時に思ってますね。
どうやってるんでしょうね、確かに。
よく聞く話はあるじゃないですか、いやこれはもうこんがらがあってるんでリファクタリングの時間を取らないと、もう追加するのが難しいですよとかっていう話をしちゃうと結局、
それ今やる価値あるのとか、いやそれより早く出してほしいんだけどっていう抵抗に対立なるなっていう話はよく聞くし、直したいが。
公式に問い合わせると、ノーと言わざるを得ないみたいな。
それをこっちのロジックだけで喋っても相手は、多分こういう時の相手っていうのは早くリリースしてほしい人だから、その人の測れる価値とかで喋らないと通すのはとても難しくなったりするし、
継続的な改善
で多分なんか3ヶ月かけて直さないといけませんみたいな、もうリファクタリングっていうかリアーキテクトだったりとか、ビックリライトみたいな規模だから、
それはそれでまたちょっとリファクタリングっていう名前をつけるんだけども、実際はリファクタリングではなくリライトだよねみたいなことだったりするんで、
それはそれでまたちょっと話変わってくるなっていう気がするから、その辺の言葉を使い分けながらリファクタリングは勝手にテストコードとかコードにコメント書くとか、スペースを入れるとか回帰を入れるとかっていうのは壊れないんで、
どんどんどんどんやるといいんじゃないかなっていうことが自分の中ではあるし、周りと喋っててもそういうふうに結構伝えるようにはしてますね。
あとあれか、最近なのかな、最近かもしれない、最近な気がするんですけど、
ちょっとコードの一貫性っていう意味で言うと、少し一歩二歩ぐらい後ろに下がりそうだなっていう気はしつつ、
次ここら辺のコードが気になった時にちゃんとリファクタリングしやすくしとくみたいな手段を取りがちだなと思ってて、
要するに僕が最近その既存のコードを新機能開発以外のところで書き換えるのって、
自分が今から作ろうとしてるところの足場型と思ってないからちょっと整理整頓したいねなんです、自分のニーズとして。
っていう動機でやってるので、そうすると今例えば○○のベースになってるクラスとかトレートっていうとか、
共有されるモジュールがあるけど、そこを真っ当に直そうとすると大変だから、
ちょっとこっちは一旦リプリケートにして新しいの生やして、自分が今から書くところはそっち使うし、
古い方にはアトリビュートなりコメントなりで、できれば新しい方に移行してねっていうくさびを打つだけ打っておくっていう風なことが多いか。
めっちゃわかる。それやりますね。これ以上副作用を増やさないっていう意味でも。
そう、止血をしたい。
そうそうそう。そういう意味でもこっちはデプリケートにして、今後はこれは使用しないで。
一応こういう別の手段があるから、そっちを取ってねってやるのは本当に自分もよくやりますね。
よくあるんだけど、いろんなモジュールがこれに依存してて、これを剥がすにはあっちとこっちとそっちも直さないといけないみたいなのが出てくると、困ったなみたいな顔になっちゃうんで。
そうですよね。カタパズル的な、うわーってやつとかありますよね。
ありますね。
それで言うと同じことができるものが2つ入ってるので、非常にコードのクオリティっていうのは一瞬というか直すまで永続的に落ちてるんで、
さっき言ったその一貫性っていう意味ですごいダメージではあるんですけど、自分の部屋だけ片付けようみたいな気持ちが最近あるな。
それはチームのサイズとか文化なのかもしれないですけど、昔だったら大っ嫌いなやり方ですね。
まあでも一方で、じゃあそれを放置してもう本当に手に負えなくなるまでそのデプリケートをつけて、同時に同じやり方が2つ存在するっていうのを許さないってやるのも多分やっぱり限界があると思うので、
移行、1年かけて移行しましょうとか、毎月この依存が10個あるんだったら毎月1個ずつ返せば10ヶ月で移行が終わるから、
それを11ヶ月、12ヶ月にしないためにもデプリケートでとってしましょうというのがいい落としどころなんじゃないかなっていう気がします。
そうそう、だからあれなんですよ。Pitchper会議のプロポーザルでまだ採択結果これ収録時点で出てないんですけど、LTEでいろんなデプリケート術みたいなの出してました。
なるほど。そういうことですね。
そういうことです。いや、PHP最近だとデプリケートっていうアトリビュート入ったから、それが一番強いんじゃないのって思ったら、あれはメソッドにしか使えんとか。
あとランタイムで調整的にデプリケートワーニング出るから、なんかひどいオーバーヘッドが出るぞとかね。
なるほどね。
ただ静的解析レベルでやっとくとそれは防ぎるんで、そっちのほうがよくないとか。
確かに確かに。
あといろんなフレームワークがメジャーバージョンアップ前に仕込んでるデプリケートはどうやってたかなとかね。
いいですね、いいですね。
採択されたら話すし、採択されなかったらむすんでしょうね、心の中で。
じゃあリファクタリングについてシャフルポッドキャストでもやりますか、次。
勝手にセカンドシーズン。
セカンドシーズン。
だいぶ脱線しちゃいましたけど、だからあれですよね、機能開発してほしいなーって言うけど、現場の声でよくなんか構造を見直したい、デザインを良くしたいとか、デファクタリングとかっていう話も聞くんだけど、
なんかあれはどういうふうに合理的に理解すればいいんだろうなー的なエグゼクティブ向けっていうこのブリーフィングは言ってますけど、
そういうところにあいつらが言っているのは何でそういうことを言ってて、経済性としてはどうなんっていう話の概要をつかむための書物って感じですね。
そうなんです。なので皆さんこれを読んで、ケイソンにリファクタリングの重要性を解きに行って、ちょっとよくわからなかったですねって言われて帰ってくるのかな。
そしたらケント・ベックにメールする。
まあでも一緒にこういう本だったりとかそのペーパーを読むことによって認識が揃う可能性もあるんで、結構いい武器になるかもしれないって感じはありますね。
なんかね後の方でこう本当に定量化できるかっていうのは別として、モデリングというかどういうふうにコストがバランスしてきた時に、じゃあこっちやろうかっていうのを考えるんだっけ的な話も出てきたりとか。
あとあれじゃないですかね、逆に現場の人、ソフトウェア技術者から見ても、あなるほど今は絶対フィーチャーを頑張った方がいいねっていう自分への忌ましめじゃないですけど、
測る塩ビンとしてちょっといい観点がインストールできるかもしれないし、まあソフトウェア開発者だったら多分タイリーファーストの方がいいかもしれないけど。
あっちの方がね、現場で役に立つテクニックもいっぱい書いてありますからね。
コメントの付け方とかね、ありますもんね確か。
そうそう。
チームの違いと成功
まあ、第1章。
この本の第1章は、たぶん今まで喋ってたことがわかりやすくなるように、2つのチームみたいなものを比較して、うまくいく方とうまくいかない方とやどういう違いがあるのかみたいな、いうようなことを話している章ですね。
章って言ってもね、超短いんですけどね。
何文字ぐらいなんですかね。本当に一瞬ですよね。
ブログボスより短いんじゃないかっていうぐらいな。
そのぐらい。
で、今回この章に載ってるのは、2つのチームっていうのがあって、1つは沈みゆく船っていうタイトルがついてて、もう1方はロケット船、スペースシップとかなんでしょうけど実際は。
っていう風になってて、沈みゆく船っていう方が、たぶん皆さんがいつも見たことあるようなやつで、プロジェクトの最初はすごくいいんだけども、だんだん大きくなっていって、人が増えたりとかしていった中、スパゲティ行動になっていって、
スピードが、人増やしてもスピードが全然上がらないでしまいには沈んでいくみたいなようなチームで、もう1方のチームっていうのは、初期の勢いを維持したまともにどんどんどんどん、たぶんこなれていくからっていうところだったりとかもあるんでしょうけども、
どんどんどんどんスピードアップ、こっちはコードベースは整理されていて、とてもうまくソフトウェア開発をやっているっていうような2つのチームを視覚するっていうところから始まりますね。
うん。なんかこの2つのチームの描写で僕がちょっといいなーって思ったのが、2つ目のチームは自信を持ってビジネスの要素に対応してっていうふうに書いてあって、ちゃんと自分たちのやってることとかこれからやれることについて自信を持てるっていう状態っていうのは素晴らしいなーっていう気はしたんですよね。
えーとその1つ目前者の沈みゆく船の方だと、すごいこと書いてあるもんな、優秀な開発者はタイタニックに乗り込んだような気分になり、救命ボートを探し始め、残ったのはやる気を失った個人の集団であり、みたいな、辛うじて明かりを灯し続けているに過ぎない。
って書いてあって、なんかそのもうモラル、指揮があればどうにかなるじゃないですか、やる気こそ全てなんで。このBotチャンス、やる気こそ成功の秘訣なんでやっぱり。
リプルウェアですね。
だからあれですよね、組織構造とソフトウェアの構造が似るとか以前に、なんか人がやる気を出せる行動とやる気を出せない行動っていうのはあるんで、やっぱり人間とアーティファクトは非常にお互いに関係してくるなーっていう感じがやっぱりするし。
でまぁこの章では、じゃあそういう2つのチームの違いっていう部分で、じゃあ経営者の視点でどういうことやるといいの?みたいな話が書いちゃったはず。
エグゼクティブの役割違いを作成するって書いてますね。ちょっと固いな役が。
ちょっとAIっぽさが出てますね。
ザ・エグゼクティブズ・ロール、このクレーティング・ザ・リファレンスって書いてますね。
違いを作るって、英語噂好きな人で、スポーツ見てるとよく聞く。
確かに、違いを作れる選手ですとか言ったりするな。
それです。
で、この中でやるべきことだよって言ってるのは、リファクタリングの習慣をつけましょうとか、品質ってものが譲れないものですよとか、あと学習とか成長ってものに突進しましょうねみたいな話がざっくりと書かれていて、すげーわかるって思いましたね。
これそうですね、ジョインクで言ってるやつだな、これは。
これもでもまた難しいなと思うのが、成長しろ、学習しろっていうのを、会社のメッセージとして言うのは全然アリだと思うんですけど、トップダウン的に成長しろって言われても、どっちに成長していいんだろうとか、成長ってなんだろうってなりそうだし、リファクタリングの習慣を無理やりつけさせるっていうのは本当に可能なのかなって思ったりしましたね。
リファクタリングの習慣を外活的にやらせるの、どうするんでしょうね。確かにな、なんか部屋が散らかってても気にならない人は気にならないけど、あんた掃除しなさいよって言われても、今やろうと思ってたんだけどなーみたいな、なっちゃいますもんね。
そうそうそう。品質の部分とかね、定量ができるものは定量化してとか、リリースする時に自分たちがどうやったら自信持っていらせるかみたいなところを一緒に言語化するとか、多分そういうワークをすれば品質について一段バグがないっていうことだけでなくて、もう一段深掘りしたものを共通認識持つとかは一緒にできそうだよねって気がするけど。
リファクタリングは難しそうだし、学習とか成長はカンファレンスに行けみたいな話は一個あるものの、勉強してねっていうことと、勉強したことが業務に直接役に立つのは長期的じゃないとわからないってものもあるんだけども、
なんか学習することが目的化しちゃうと、なんか現場で奇遇なんかあいつら楽しくやってるけど成果出てないじゃんみたいなことに下手するとなっちゃうよなーと思ってて、なんかその辺とかもちょっと難しそうだなーって思ったりもしましたね。
すごい素朴で中直的なこと言うと、日々の業務の中からちゃんと内省して学習していってねーなんでしょうけど、難しいですからね、それをやれる環境文化、空気管を醸成することができればいいんでしょうけど。
それができたら苦労しないとか、なんかたぶん別にここで困ってませんみたいなことが導かれそうだよねーっていう気もしますね。
そうなんですよね、それができたら苦労しないというか、本当はそれをやれるようにするために苦労せいいって話な気がするんですけど、誰もそんなこと言ってないってことはさぞ難しいんでしょうね。
そうですね。
なんかね、1日ちゃんとした料理でバランスをとるよりかはやっぱりサプリとかを食べた方が早いので、カンファレンス行こうとか、素敵は買っていいよとかっていうサプリメントを流し点滴をした方が一瞬で健康になれるので、持続的かどうかはまた別としても。
でもエグゼクティブの君たちはそういうことをちゃんと目指して違いを作っていくんだよっていう話と、そうじゃないとね、ロケット船になれずに沈みゆく船になっちゃうよっていう。
結構脅してますね、出だし。
まあ、そしてケントベッカーはそれを見てきたっていう話ですからね。
うん、書いてますね。おとぎ話のように聞こえるか。私はそれを生きてきた。その作成を手伝った。あなたにもできる。
すごいな。
まあ、それはケントベックだからできたのではっていう感じも若干はありつつも、まあでも、まあ多分いろんな現場を見てるだろうから、なんか全部が全部その本当に再現性がないわけでもないんだぞっていうことでもあるんだろうなっていう気はしますね。
そうですね。そこの差分というか、どっちのカルチャーを持ってるチームのほうが本当にビジネスを成長させたかっていうのはある種の結果みたいなところも自分の目で見てきたよっていうことなんでしょうね。
そうですね。っていうのがまあ第一章って感じですね。
ソフトウェア開発の経済
で、まあ多分そのまま投資しろとか、学習とかに投資しろとか、リバクタリング習慣つけさせろとかいう話をしていっても多分、結局それがなんでビジネスにこううまくつながるんだっけみたいなところが多分うんってなるから、
まあ二章にお金がデザインを形作るソフトウェア開発の経済的原動力っていう話が来ているって感じですかね。
なんかここからやっと本編っていう感じですね。ここまでがイントロっぽい。原文と隣のタブで読み比べてるんですけど、まあそうだよな。英語は英語で読んだらわからんってなるし、機械翻訳の日本語見たらこれなんて書いてあったんだろうってなるし。
それは僕の学習が足りてないだけなんで。
この二章での冒頭とかがちょっと面白い問題提起というか疑問を投げかけていて、ソフトウェア開発は原則から切り離されてしまった。競争や貢献利がない中でソフトウェア開発はとても儲かる傾向があるからだ。
今までのソフトウェア開発って物を作るっていうところと、実際それがお金にどう繋がってるかっていうことを思いっきり切り離す業界が成長してきてしまったっていうようなところから始まっていて、確かに言われるとそうだなっていう気が。
今この書いてるコードが一体いくらのお金を生んでるのかとか、それを考えてもしょうがないからっていうのがあるんですけど、考えたことねえなって思いましたね。
1個売ると1000円儲かるからじゃあ100個作りましょうみたいな感じじゃないですもんね、どうしても。
そう。
だしましては内部品質みたいな話になると余計に、高級品になったから高値をつけられますっていう話じゃないと思うので。
結局人月ってお金を数えることになると、じゃあ人を減らしたら安くなるし増やしたら高くなるしっていうことしか我々はお金のことは言えないっていう状態ですからね。
このコードはすごい貴重な金属でできたキーボードでタイピングされてるコードなんで、高い値段で売れますとかじゃないですもんね。
あの人が作った一点物とかそういうのないですからね。
これを書いたプログラマーはすごい、なんだ口飲んで育ったんですみたいなね、知らんがらけなのかな。
じゃあどうやってお金のこと考えましょうかねっていうところで賞味現在価値っていう話が出てきて、より早くお金を得ることはより多くのお金を得ることと同じであるよっていう話が主題として出てくるって感じですね。
これがめちゃくちゃタイリーファーストで出てきた部分ですね。
じゃあ賞味現在価値とはなんやねんっていう話がなるんですよね。
これはどう説明するといいのかなと思いながら、どう説明すればいいんだろうっていうことをちょっと思ってたんですけど、
あれですかね、その早く手に入ることと後から手に入ることをどういうふうに価値計算するといいのかっていうことを計算式というかモデル化したっていうものですかね。
そうですね、どこまでこの比喩につけ合うかみたいな話はあるんですけど、
1日早くデプロイしてユーザーが使っている時間が1日長くなったら、それは売り上げに繋がりやすいよねみたいな話ですもんね。
なので、より早く出したいよねってなるけども、逆に早く出すことを慌ててやった結果、将来のコストがどんどん上がっていくみたいな部分があるので、そことをどうトレードしましょうかねっていう話になってくるっていうところですね。
本当に目の前のことばっかりやりすぎちゃうと、結局5とか1後に素早くリリースするっていうことができなくなってるんだから、結局しっぺ返しじゃないですけど、得してない状況になるよねっていう。
ただ一方で、じゃあ遅く出すと、いやそもそも早くリリースしないとお金が入ってこないってことは、スタートアップとかになると、どんどんランウェイできる期間が短くなっていくっていう問題もあり、
早く出せばいいってことと、どこがちょうどいい場所なのかっていうのを探すのはその状況によって全然変わってくるんで、難しいねっていうことでもありますね。
そうですね。そこら辺でオプションの話につながるような。
そうですね。早く出した結果、取れる選択肢がどんどん減っていく。まだ出していなければ、ユーザーが使っていなければこの機能消せるとか、その機能をもうちょっと拡張性を高くしてからリリースするとか、
いうことが取れる期間を前倒してリリースしてしまったら、データも溜まっていくし、もうこういう選択肢は取れないですよみたいな、ソフトウェアのこういう拡張は無理ですよってなっていくと、
ソフトウェアの選択肢の低下
市場が変わった時に、こういう機能が追加しないと、こういうこともできないとってなった時に、その選択肢を諦めたじゃんみたいなことになっちゃうと、ソフトウェアの価値っていうものが一気に下がってしまうみたいな。
そこら辺がオプション性、オプショナリティが低下してるよねっていうような言い方をしてるか。
そうですね。多分これの繰り返しなんだろうというような気も。
そうですね。要はバランスのバランスって何って話をしてますもんね。
だいたい昔からある有名なプロダクトがあって、でも機能が盛り盛り追加されて、負債があって、オプション性がなくなっていって、新しいスタートアップが出てきて、身動きが取りにくくなってたところを身動きが取りやすいところがどんどん勢いよく成長してって奪っていくみたいな。
でもそれがまた時間が経っていくと、オプション性が低下して、また次のスタートアップが出てみたいないうことを繰り返してるんじゃないかなって思ったりとかもしてて。
それを聞くとユーザーも負債な感じしますよね。儲けを持ってきてくれるから、負じゃないはずなんですけど、身動きを取りづらくするっていう意味では。
そうですね、このお客さんを諦めたらこの機能削れるのに、このお客さんのことをずっとそこに裏切られるっていうか契約が切られるのが怖いから、後者対応してしまうみたいなとかもそういう話ですよね。
かといって、もう十分儲けさせてくださったんで、本社はもうOKですって言って切り捨てるみたいなことを繰り返してると、なんか信用がないですよね。あの会社は裏切るぞみたいな。そういう話じゃねえんだよって。
まあそれぐらい立場が強くなればいいんですけどね。実際は多分そんなことはなかなかないでしょうからね。
でもそこであれですね、生存みたいな話になるか。なんかこの本みたいなやつの中でも書いてあるのが、
難しいですよね。寿命を削りながらソフトウェアの機能を増やしている感じがあるな。
まあそれによって使ってくれてる人が増えてるから、ある意味ではまた寿命が伸びてはいるんだけど、そのオプションとか、本当にこう餌がないから自分の足を食うみたいな。
がしはしないが、しかしお前その長く生きるためにはそれを食ってちゃダメだぞみたいな状態がずっと続くと辛くなっていくねっていうのはありますね。
まあ誰かを活かすためだったら足食うのもいいかもしれないですけどね。
まあでもそういうことをビジネスの視点では考えているということでも、考えているのか考えていかないというところがあるっていうことですよね。
ソフトウェアの設計をしている立場から考えたときに、じゃあこの話でいくとできるだけ早く出せて、かつオプションが拡張性が高いとか取れる選択肢を増やしておくとかいうようなことをしながらソフトウェアを長く生き続けるようにどうやったらできるかってことに実はフォーカスした方がいいんだよねっていうことでもあるってことですよね。
そうですね。
選択肢を取れるようにしておくっていうのは実際は無理なんで。
そうですね。何ともカップリングしてないモジュールっていうのを無限に作り続ければ、いくらモジュール増やしても副作用がないんで。
でもそれだったら使われてないだけになるんで。
諦めたことはやっぱりARとかで文章化されておくと、後の人がそっちの道は諦めてたんだねとか、こういう道筋で諦めたけど、一回遠回りしたらもう一回そっちの道に戻れるんじゃないかとかいうようなことが後々わかったりすると思うんで。
この辺とかを意識しながらやっていくっていうのがいいのかなっていうのをちょっと読みながら感じましたね。
そうですね。将来のオプショナリティを下げるっていうのが不採として現在借り入れようかって話になる気がするなと思ったけど、デザインとフィーチャーっていうのを対立軸で考えるとしたらしっかりしたデザイン作るためにコストかけようよっていうのは、
要するに売上げに繋がるような機能化、明日の売上げに繋がるような、来期とか再来期とかじゃなくて本当に木下の売上げに繋がるような開発っていうから目を背けて、構造とか設計とかみたいなデザインに力を入れるのは、
それはそれで技術的不採をため込まないための頑張りって、それはそれでちゃんとお金稼いでないから、そっちは不採っぽいなっていう気が、在庫を増やしてるのかな、よくわかんないけど。将来の資産価値を高めるために今の売上げを作ってないみたいなそういう雰囲気があり、
技術的不採じゃないことをやるので、すごい経済的にやっぱりネガティブだよねっていう気がしますけど、両方やれって言ってる本だからな。
そうですね。
2章はこんな感じですかね。
そうですね。3章いきますか。
