やはり俺の「質 v.s. スピード」はまちがっている。 #eof2019 - 名前考えるの苦手

2019/10/31(金)に開催されたEngineering Organization Festival 2019 で @t_wada さんの「質とスピード」という講演を聞き、とても感銘を受けたのでメモ。 品質とスピードはトレード・オフの関係にある。どちらを優先するか？要バランスだ。 そう思っていた時期が私にもありました。 けど、そんなことはなかった！ ■追記 個人的な捉え方としては、 プロダクトを漸進的に成長させ、仮説検証ループするスピード上げようとすると、犠牲にした保守性があとで(意外とはやく1ヶ月後には)足枷になる。 保守性(テスト容易性、理解容易性、変更容易性)が低いとリードタイムが延びてスピードがどんどん落ちていくループをまわせなくなる。ってことかな、と思う。 スピードを上げようとしたのに、意外とはやくスピードが上がらなくなるジレンマ。 @t_wadaさんのスライド 素敵なグラレ

[name-25137412]

安易にトレードオフだと考えちゃダメってのは激しく同意だけど、質もスピードもMAXなんて道はないので、QCDのバランスで考えるべきなのは変わらないと思う

[sujoyu]

品質のレベルによる。0% - 50%くらいまではスピードと品質は一緒に伸びると思うけど、90% - 100%では品質を上げれば確実にスピードは落ちる。銀行システムの品質を普通のWebサービスに求めないでしょ。

[koogawa]

スピード優先しながらも高い品質のコード書いてくる人と一緒に仕事すると考え方も変わるわよね

[t-wada]

講演レポート誠にありがとうございます。説明不足の部分を追記して講演資料を公開しました https://speakerdeck.com/twada/quality-and-speed

[sen47]

現状を変えるためにどうしたらいいのかが示されてないのでもやもやする。無能エンジニアが品質に時間をかけるようにしても時間かけないで有能エンジニアならできる！って言われたらどうしたらいいの？としか言えない

[udonj]

とはいえ時間は無いわけで。

[HolyGrail]

ほんとこれ…。スピードを理由にテストを書かない（あるいは仕様変更に伴うfailケースを修正しない）という選択を選ぶエンジニアがいてカルチャーショックを受けたんだよな…。

[babandoned]

二項対立的な発想や思考に流れがちだが、その延長線上には対立しかない。いまユーザーに必要な最小限の「質」が一体何か、どれくらい必要なのか、スピードも保守性もすべてテーブルに並べた上での議論が必要だと思う

[otihateten3510]

って信じたいんだろ？　／俺の答えは「トレード・オフの関係にあるけど、トレードすることは無い」　昔ブログに書いた

[ono_matope]

それ。プロジェクトが成長しても開発ベロシティを減衰させないのが「良いコード」の定義。/「品質は実質無料」は『ピープルウェア』の引用かな。

[kitos]

“質とスピードはトレードオフではない”

[toritori0318]

“「質とスピードはトレードオフの関係にある」は大きな誤解です”/ これ

[northlight]

そう信じたいってのと現実は違うよなあ・・

[honma200]

本当はPDCAみたいに回すものかもねー。品質というか、どっかで仕様を作り込む段階があると思う

[Balmaufula]

世の中には4種類いる両立できる人、片方は排他になるもの、両方ゴミな人。俺は最後だった

[t10471]

SLOを99%から99.999%にすると工数はめちゃくちゃ上がると思うけどなー

[inouetakuya]

めっちゃシャウトしたいやつ “まとめ「質とスピードはトレードオフの関係にある」は大きな誤解です”

[anigoka]

急がば廻れ（◀納期という通行止め

[sdkd6611]

納期がまずある。クオリティがどうであれ、とにかく言われたものを満たす何かを作る。そしてとりあえず納品し、瑕疵対応として要望を取り込んでいく。これが、お客さん的にも内部で通りがよいみたい。悲しいなぁ。

[n314]

クラスと型をしっかり設計せずに連想配列で済ませちゃう的なことかと思ったらテストの話か。テスト盛り盛りのFizzBuzz Enterprise Editionよりテスト無しの10行FizzBuzzの方がいい。

[xorzx]

身の丈にあった選択ですよね。仕事なんで。

[Bosssuke]

スピードを上げるためにの仕様にするのが一番スピード出る

[takamii228]

いい話(血反吐)

[akabekobeko]

見積もりとスケジュール管理がおろそかなのと「スピード = 急ぐ」という勘違いが不幸を呼ぶのだと考えてる。スピードは見積もりに対する成果であり、先に立つものではない。

[oteguro]

メンバー全員が自身のベストなコードを書くと仮定して、誰にどれをやってもらうかでスピードの最適化はできると思ってる。個々人で得意な所や能力の違いは有る。専門性ができてしまうトレードオフはあるけれど。

[iamnihontaro]

スピードを優先しつつ、顧客に刺さるか分からないモノを手当り次第作るから後々困るんだと思ってる。『スピード優先×手広く』ではなく『テスト書く×絞る』で結果的に鋭いベクトルが出るんじゃないですか。

[dgen]

トレードオフが無いわけじゃなく、トレードオフした結果が悪くなるだけの話だった。犠牲にしたところが足を引っ張るのは最初からわかってるでしょ。要はバランスだな（要はバランスおじさん

[Lagenaria]

典型的なスピード重視のコーディングって、類似機能のコピペを多用して極力新しいコードを書かない事だと思う。結果として汚くなる事が多いけど（関係ない機能のコメントや、不要な処理の断片等）。

[sashiharajp]

永遠の課題

[perl-o-pal]

人月が換算できないのも広まってほしい。

[Yoshiya]

やっぱりWeb系って特殊だと思う。

[plantkart]

Nice Story

[NOV1975]

最後に量的なものに還元されるであろう領域の質と、設計やルールや仕組みなどの質って根本的に概念が異なるもので、後者を無視して前者の質を上げる行為が一番無駄なんだよなあ。

[augsUK]

品質とスピードのトレードオフは、完璧主義気味な人に言われることが多いと思うので、メンテナンス性が大きく損なわれるレベルの話とはまさにレベル付けが違うのでは？スピードが必要以上に遅い人の方が多い印象

[s1180087]

“ 2019 / 9 (3)”

[heaco65]

今いる会社は全体的に「とりあえずローンチして整えて」って言ってくるしそれがデフォになってる いいのか悪いのかは別として気持ちが休まらないのは確か

[mather314]

良い学び。局所的・短期的にしか利用しない使い捨てのコードならまだしも、保守が必要なサービスで最初から品質を犠牲にするべきではない。

[ysync]

ゾーンに入ってる時はそんな問答すら意識外なので問題無い。

[tamaso]

とはいえ、仕事・ビジネスは、まず「納期」を守ること優先だし。

[gabuchan]

できる人は両立できる。じゃあできない人は？という問いには「質」と答えれば良いんじゃない？時間かけてもいいからやってもらったりペアプロするなり教育して育てればよき。