>@sugimoto_kei: 僕の印象では、ユーザーに受け入れられて大いに売れてたけど、コードが悪くて変更が難しいからダメになった、なんてプロダクトは千に三つくらい。大部分は、ユーザーの琴線に触れることができずに消えていく。コードの変更が難しいのが一番問題、なんてケースは、むしろ成功事例だよ。

>@sugimoto_kei: コードの変更容易性がどうでもいい、という話じゃない。このソフトウェアを是が非でもユーザーに使ってもらいたいと思えば、外部機能や外部品質が気になり、そのために内部構造と内部品質もよくしていこうと動機づけられる。その経路の方がまっとうなんじゃないかなあ。

>@hiranabe: @sugimoto_kei すごくわかる。

>@sugimoto_kei: @hiranabe 「目の前のコードがぜんぜん読めない。いやだ！」って気持ちはよくわかります。ただ、それを、そう言って、じゃあ、どうしていこうかと話にせずに、ビジネス価値がー、といったきれいな話にすり替えている感じがするんですよね。

>@doubledispatch: @sugimoto_kei @hiranabe 設計論の必要性とか保守性って、読みたくない•触りたくない、御神体扱いされる地雷的な実装の時に痛感します。。開発中は、テストしにくいなあ、1人で長期間作業が要求されて分担しにくいなあという時に、感じます。

>負債とか維持費を増やさない方向性の努力で、売り上げを増やすのとは直結しない

>@hiranabe: @sugimoto_kei 人を預かる経営やってみたり、会社の借金した人でないとわからないかもですね。