設計品質vs開発速度

suin・読者6万人『サバイバルTypeScript』公開中！ @suin

借金があっても経営が上手くいく会社もあるし、借金は借り入れた瞬間から資産になるし、それを効果的に使えれば事業の進展を早められます。 技術的負債も同じだと思います。いい借り入れ方ができれば、事業に貢献できる。負債ゼロが常に正解だとは言い切れないと考えます。 twitter.com/little_hand_s/…

松岡@ログラス/DDD,アジャイル @little_hand_s

質問箱にエモい投稿があったので皆さんの回答を募集してみたいと思います。この投稿にリプライしてもらえたらリツイートしますので、皆さんのご意見をぜひ！ pic.twitter.com/Pme505cgQD

2020-11-01 09:58:51

miya_masa @MI_YA_U_CHI

作りきりですぐに捨てるソフトウェアなら一番早いやり方で良いのでは？と思っている。 ただ、僕は簡単に見えるプロジェクトでも始めから良い設計を考えてやっておかないと、プロジェクト後半の仕様変更とかに耐えられないリスクあるからちゃんと考える。 そのリスクって読めないし。 twitter.com/little_hand_s/…

KanekoYoshiki @necoak444

品質、スピードだけでなく、ボリュームも考慮必要と思います。全員が始めから良い設計出来るわけはないので、その限られた開発者の許容範囲を超えるボリュームがくると破綻する。そうなると全体として破綻させないために、薄く広くと、特定機能に注力するしかないかと。 twitter.com/little_hand_s/…

GTO@アヘ顔Wピース @tachikoma_gto

@little_hand_s テスト(駆動)は、モジュールの使いやすさや正しさに対する迅速なフィードバックによって、品質と開発速度を同時に高めると思います。 過剰なテスト、つまり不安が減らないようなテストはこのようなフィードバックに資することがなく、純粋に開発を圧迫するでしょう。

T.MOTOOKA @t_motooka

データベース（データモデル）の設計が悪ければ、どんなに良いプログラム設計も上手く機能しませんし改善も困難です。こういったことから、新製品開発の場面では、データモデル設計は本気で取り組み、情報セキュリティ面はそこそこ取り組み、それ以外の部分は速さ最優先にするのが良いと思います。 twitter.com/little_hand_s/…

非実在naka aki @naka_aki_spl

@jxmtst @little_hand_s こんばんわ。俺もwadaさんの話を思い出しました。誤解というか、損益分岐のタイミングが「え？もはや？それじゃビジネス的に見て(も)品質さげる意味ないじゃん？」というくらい早く来てしまう。 あとソフト作りって品質を「自在に」手加減できない印象があります。誤って下げ過ぎになりがち

nikkie / にっきー @ftnext

思うに答えはYesです（良い設計、良いテストは会社を幸せにする） すでにスレッドに上がっている、t_wadaさんの質とスピードを支持します twitter.com/ftnext/status/… 会社が幸せになったことを実感するためにも、設計力を上げるための努力を積んでいきたいですね（実力以上の設計はできないので） twitter.com/little_hand_s/…

nikkie にっきー @ftnext

スライドだけ拝見していた『質とスピード』t_wadaさんをNTTCom Digital Forum 2020で聴講 ・保守性（質）を高めればスピードは上がる。スピードを下げても保守性は上がるわけではない（自分の技術力以上のコードは書けない） ・内部品質（保守性）への投資の損益分岐点は1ヶ月以内→自分たちの得になる

2020-10-16 01:13:34

BlueTone焼肉食べたい @bluetoneinfo

@little_hand_s QCDのどこに価値があるか？ に尽きると思う。 何を価値とするかは、時と場合により判断。 ぱっと見同じ事でも、状況が変われば判断は変わる。

みずき@PjM, PdM学び中 @mizzsugar0425

テストがない・仕様書もない・作った人いない・理解しにくい・変更しにくい設計のソースを変更しようとしたら、壊れるの怖くて変更にとても時間がかかった経験があります… もっと早く終われば他のこともすぐ出来るのにのびのびになって、お客さんの要望にすぐ答えられずビジネスチャンスが… twitter.com/little_hand_s/…

がる @gallu

「基本はバランス」なんだとは思う。 んだけど「良い設計」って「そこそこコストかけてやらないと伸びないスキル」だから、短期はともかく中長期で考えるんなら「コスト度外視とまでは言わないにしても、よい設計寄り」にしておいたほうがよいってケースは多いと思う。 あと「負債には利子がかかる」ｗ twitter.com/little_hand_s/…

vis @visyeii

@little_hand_s まずは対象の優先度を設定してテスト＆実装する ・安全に関わる機能 ・ドライバ・スタブ機能 ・他案件にも流用出来る機能 後追いで ・テスト記述は省いてもテスト追加がなるべく簡単なコードにしておく ・バグ指摘されたときにテスト追加しながら修正する テストを書き切れる工数が欲しい…

下地恵太郎@graphql-rubyで開発中 @k_mishige

技術的負債以上のコストかどうか、未来の結果を比較することは出来ない気が。 その上で、経験則的に大変なことになるから良い設計しようって言ってのは見るけど、良い設計し過ぎたわ〜みたいなのはない気が。 予算内で問題起きてないんだから話題にならない？ twitter.com/little_hand_s/… twitter.com/little_hand_s/…

金子 広大 @kanekokoudai

だからこそ、先んじて学ぶことが大事なだろうなぁと思ふ。 何を学ぶべきかも分かりづらいけれども、組織の中で多くの人が様々なことを学び、コストを先に払っておくことは可能だと。 twitter.com/little_hand_s/…

大せんせい(クソゲーと戦うチベットスナギツネ) @NekozeDaisensei

@little_hand_s 個人的な意見ですが、良い設計やテストを省略したことで得られる開発速度というものは無いと考えています。 あくまでもそれで得られるのは、現在以降の時間の前借に過ぎず、どこかの工程でその負債を清算しなければならないと思います。

大せんせい(クソゲーと戦うチベットスナギツネ) @NekozeDaisensei

@little_hand_s なのでビジネス的にスピードが重要なのであれば、リリースするスコープを小さくすることで対応するのが必要なことだと考えます。

takezaki @stakezaki

僕も同じ考えでDDDは自己満足だと思っています。不要です。テストは必要ですがケースによっては後回しになる場合があります。blog.vte.cx/%E3%83%95%E3%8… twitter.com/little_hand_s/…

🐳ログラスCTO/坂本龍太/SaaSスタートアップ/RyutaSakamoto @http204

返済可能な技術的負債なのか？を判断するのは、質の高いコードを書くよりも圧倒的に難しい。 twitter.com/little_hand_s/…

銀狐 @SilberfuchsHK

結局後々自分らの首が絞まっていくし、良い設計の方が実は開発工程全体で見ると高速だと思う twitter.com/little_hand_s/…

右近忠重 @ukontadasige1

そもそも後続の開発速度を上げるのが良い設計なので。。。 スタートアップフェーズで許される「コード品質より速度を優先する」というのはリファクタリングをしない、くらいなのでは？ まあ、自身のスキル不足の言い訳に使っている人も多くいると思いますが。 twitter.com/little_hand_s/…

こやま🐢育児パパ&システムエンジニア @rudolf134

品質とコストの板挟みに合う事は良くありますね。 品質を取るかコストを取るか、0か1かの議論になりがちですが、限られたコストの中で、重要な所はしっかり設計し、重要では無い所はサクッと作ってすぐ捨てるのが良いと思います。 twitter.com/little_hand_s/…

しじみ @shijimigaimate

興味深い。 twitter.com/little_hand_s/…

t2kob @t2kob1

オーバーエンジニアリングを避けるのが大前提かな。 そしてその基準は組織・予算・納期・人などによって変化する。だからそのバランスを見極めることがテックリードに求められると思う。 もしもユニットテストのレベルでオーバーエンジニアリング扱いされるなら、現実的な選択肢は転職しかないかも... twitter.com/little_hand_s/…

非実在naka aki @naka_aki_spl

@jxmtst @little_hand_s 量をこなす作業って、その作業の量を減らせば、それにリニア(?)に対応して「手抜きされた製品(=廉価版)」が生まれる感じがします。 しかしソフト作りは作業でなく所謂「すべては設計」なので、リニアな質の落ち方をせず、すごく不連続でタイミングが読めない制御困難な「落ち」かたをする感じ。

非実在naka aki @naka_aki_spl

@jxmtst @little_hand_s ものすごく頑張ればソレすら制御可能になるのかもしれません。しかし、そこまで頑張るほどの「コスト」をかけてしまうと、そもそも廉価版を作りたいという意図にたいして本末転倒になってしまう。 だから、「ほどほどに手を抜く」ことなんて「できない(むずかしい)」 そう感じてます＞ソフト

𝙯𝙤𝙙𝙞𝙖𝙦 @zodiaq

私は、急激にそちら方面の情報を部下からぶち込まれ、自らも色々情報を漁るうちに、もはやテストは開発者が心おきなくリファクタリングするために書くものであって、「品質を上げるため」は目的と手段を取り違えてるのでは、と勘違い（?）し始めて、部下にあきれられている。 twitter.com/little_hand_s/…