品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？ 和田卓人氏による 「質とスピード」（前編）。デブサミ2020

品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？ 和田卓人氏による 「質とスピード」（前編）。デブサミ2020 ソフトウェア開発のプロジェクトにおいて、リリースに間に合わせるために開発スピードを優先させ、ひとまず質には目をつぶろう、という判断がしばしば行われることがあります。 はたしてその判断は正しいのでしょうか。2020年2月13日と14日の2日間、都内で行われたイベント「Developers Summit 2020」（デブサミ2020）」の和田卓人氏のセッション「質とスピード」は、これを深く考察したものでした。 この記事では、会場に立ち見がでるほど大人気だった本セッションの内容をダイジェストで紹介します。本記事は前編と後編に分かれています。いまお読みの記事は前編です。

[theatrical]

あまり関係ないけど、品質と言う言葉が何を意味するかは、暗黙的に省略された主語によって変わるので、そこを明確にしないと話が通じないと、ワインバーグの本で見た記憶がある。

[yhanada00]

”実際には、コードが汚くて遅い人もいれば、きれいで速い人もいる。つまり人の問題であって、トレードオフの関係ではないんですね。”

[su_zu_ki_1010]

受託開発を主としている人、自社開発を主としている人、維持をやったことがある人、新規開発案件しかやったことが無い人、それぞれで感想が異なりそう。

[t-wada]

先日の #devsumi の講演を publickey の新野さんが詳細なレポート記事にしてくださいました。誠にありがとうございます！

[chintaro3]

コストダウンしか存在意義の無いソフトは、そのソフトによって得られるコストダウン効果以上のコストをかけられないという構造上の問題がある。存在意義から改善しないと絵に書いたモチ

[fumisan]

品質を犠牲にすると短期的にもスピードは得られないでしょ。品質は要件なんだから備えていないソフトウェアなんて価値ないし、品質ないソフトウェア作った時間と手直しの時間かかるし

[perl-o-pal]

時間をかければ品質が上がるものでもないがなあ。

[ntdtks]

「クオリティアップのためゲーム発売を延期します」はよく見かけるが、「品質妥協したので完成スピード早まりました」なゲームは見かけないなぁ・・・。だから犠牲にしてもスピード上がらないのが実情かと。

[daishi_n]

受託でメンテナンス性の高いアプリを書いたら、サービス停止無しに機能更新できて、マスターDBのメンテでほとんど済むようになったけど、機能更新費用は安くなったのでその案件の売り上げは下がったな。

[shinobue679fbea]

品質を犠牲に納期を最優先することで思わぬ価値が生まれることもある。ゲームで言うとメジャー2が有名。

[simomm]

内部品質が中長期の開発速度のために重要。犠牲にしているのメンバーの成長と学習の機会。

[maetes]

おもしろい。何回か読みたい

[peppers_white]

テストがあんまりにも遅いとえらいことになるわけで

[tick2tack]

“つまり保守性と開発スピードというのはトレードオフではないんです”

[laptice]

品質と開発速度は比例し、逆も又然りという話。品質が学習速度や保守速度を向上させ、それによって生まれた時間で習熟や教育、品質にフィードバックできるループが行われやすい。

[sdkd6611]

我々が請け負ってるような客が本気でいいシステムを作ろうとしてなくて開発と一体となってやれてないようなプロジェクトの話はしてないと思います

[digo]

技術的負債の話だと思って読んだ

[onody_onody]

品質とスピードはトレードオフの関係ではない。

[manhole]

品質→内部品質→保守性

[napsucks]

まあこの辺を見かけ上解決して早め早めにヤバさを検知しようというのがアジャイルなりラピッドプロトタイピングなりだと思う

[knjname]

丁寧な動作を高速にやるのが理想なんだよな。コードを直す機会なんて二度と訪れないこともある。

[diveintounlimit]

この人よくコード品質と開発スピードのトレードオフ挙げるけど、必ずしもそうでもないよなぁとよく思う。

[ntstn]

品質が高いほど開発速度も速いような。トレードオフの関係じゃないでしょ。両方技術力の高低で現れる差。

[shoh8]

誰かが犠牲になる

[bucchiz]

スピードを求めるあまりドキュメントを一切残さないシステム作ったことあるけど、その一代で販売終了になったからある意味効率は良かった(けど二度とやりたくない

[kathew]

結局は人の問題、まったくもってその通りなんだけど、スケジュールが過度に短い（本来必要な十分な工数を満たしていない）と想定外への対応の質が落ちる。それは内部品質の劣化に繋がるので、頼むから工数ください

[kuzudokuzu]

多くの問題は次の1項目で説明できる。①人間は馬鹿である。そして次のもう1つの項目のために解決が困難になる。②多くの人間は自分が馬鹿であると認めたくない。

[ene0kcal]

「遅くて汚い、早くてきれいは人による」、というのは真だけど、別の視点からは、"被教育感受性"が高いとビギナーでもチームのトップレベルに一月位で追いつく。少なくても被教育感受性が高い人であれ。

[ledsun]

「教育とスピード」のトレードオフてブコメが、興味深い。なるほど、受託開発ならお客さんは他社人員の教育にお金を払いたくない、自社開発ならスピードのために教育するのは合理的（な、場面もある）、のかな？

[griefworker]

「保守性と開発スピードというのはトレードオフではない」

[raamen07]

速い、遅い、短期的、長期的、低品質、高品質。みんな思っている程度が違うから噛み合わない。

[kujoo]

重い（処理が遅い）のは最適化がされてないからで後々やっていきます！なんてのは信じたらあかんで

[niship_0822]

あとでよむ

[kamayan1980]

なるほど。品質のトレードオフは保守性であり、スピードのトレードオフは教育。

[yood]

同じ様な処理でも実装方法がバラバラ・命名規則が滅茶苦茶・人に読ませる気のないSQL。事前に規約を設定しコードレビューで防げるから、時間とトレードオフは間違いではない。個々への時間配布は無意味だけど

[n314]

期間限定キャンペーン機能をソースにベタ書きせずに構造化してDBもテストも作って綺麗にやると、4回のキャンペーンで元が取れるのかなあ。でも2回目の機能が全く違う仕様だったら意味ない問題もあるような。

[tettekete37564]

「コードが汚くて遅い人もいれば、きれいで速い人もいる。〜〜トレードオフの関係ではないんですね」< トレードオフだよ。綺麗で早い人は単価が高くなければいけない