🔍

JaSST'20 Kyushuに参加しました!~基調講演編~

2020/11/25に公開

JaSST'20 Kyushuに参加しました。
http://www.jasst.jp/symposium/jasst20kyushu.html

今回は、和田 卓人(t_wada)さんの基調講演"質とスピード"と、ロッシェル・カップさんの招待講演"サーバントリーダーシップを身に付けましょう!"の二本立てでした。

当日のTogetterはこちら。
https://togetter.com/li/1625626

全部まとめ終わってから書こうとするとたぶん一生書かないので、できたところから出していくStyle。
ということで基調講演編です。

質とスピード~ソフトウェア開発の典型的な誤解を解く~

資料は何度か見たことがありましたが、実際に講演として聞くのは初めてです。

  • 質とは何か?
  • 質とスピードはトレードオフなのか?
  • 質及びスピードとトレードオフになるのは、本当は"何"なのか?

といった内容を順序だてて話されていて、すんなりと理解することができました。

あらぶる四天王が現れた!

アジャイルサムライ P.86 より

  • 時間
  • 予算
  • 品質
  • スコープ

与えられた時間に対してやるべきことが多すぎる場合、"品質を犠牲にする"?

品質を犠牲にすればスピードを得られるか?

  • 短期的に生えられる
  • 中期的には逆効果になる
  • 長期的には致命傷になる

短期/中期の境目は?
ここでいう品質とは?

ここでいう品質とは?

"品質とはだれかにとっての価値である --Gerald Weinberg"
"ilities" ※たくさんある
"狩野モデル" ※当たり前品質と、一元的品質(性能品質)

今日は、(お客様から)見える品質と見えない品質に分けて考える

  • 外部品質と内部品質
  • 利用時の品質と製品品質
  • 機能要件と非機能要件

内部品質と外部品質

品質を犠牲にするときに、外部品質と内部品質のどちらを犠牲にするか?
-> 内部品質が犠牲になりがち
内部品質は結果ではなく原因であり、いいソフトウェアが備えているべきもの

質とスピード -> 内部品質とスピード

スピードのために、どのような内部品質を犠牲に捧げたのか?
Maintainability : 保守性
└ Testability(テスト容易性)
└ Understandability(理解容易性)
└ Modifiability(変更容易性)
開発者が掌握できる領域なので、犠牲になりやすい(自らの選択で犠牲に捧げることができる)品質
-> 犠牲3兄弟

質とスピード -> 内部品質とスピード -> 保守性とスピード

今はスピードを優先して後からやろう!

  • 後でクリーンにすることはない
  • 市場からのプレッシャーは止まらない
  • 競合他社に追い抜かれないためには、これからも走り続けるしかない
    また次の機能、またまた次の機能・・・コードをクリーンにすることまで手が回らず、崩壊が始まる
    いわゆるデスマーチ、疲弊しきった現場へと・・・†

荒みきったコード

テストを書く時間がない、先を急ぐ・・・爆弾処理のようなリリース(動いているか確信が持てない)
Edit & Pray(祈る🙏)
えらいひと「今は大事な時期だからスピード優先で、コードの質は下げても構わん」
会社が存続している限りスピード優先 -> 真に受けるとクソコードしか存在しない会社になる

保守性の低さがもたらすもの

一つ一つの変更に余計な時間がかかる
-> 外部品質に影響が出てくる

品質を犠牲にすればスピードを得られるか? --> 保守性を犠牲にすればスピードは得られるか?

スピードを落とせば保守性は上がる?

クイック & ダーティの神話
与えられた開発期間から柔軟に汚さと速さの選択はできない

保守性とスピードはトレードオフなのか?

"保守性とスピードはトレードオフではない"
急ぐためには品質を犠牲にすることが必要だし、いいものを作るには時間をかけるしかない
時間をかければいいものが出来上がると思いがちだが、早い人は早い
初心者は時間をかけてやってもいいものはできない

トレードオフと考えるのは典型的な誤解

トレードオフではないと語っている例

品質を犠牲にするのは効果的なcontrol方法ではない。品質は制御変数ではない
品質を高めることで、deliveryが高速になることが多い
品質基準を下げてしまうと、deliveryが遅くなり、予測できなくなってしまう
短期的にも長期的にも、崩壊したコードを書くほうがクリーンなコードを書くよりも"常に遅い" -- Bob Martin

コードを書く速さと、コードのきれいさに関連がある
品質を高く保っていた「にも関わらず」速いのではなく、高く保っていた「からこそ」速いのだ

スピードから質への影響はどうか?

手戻っている時間は学びを生まない。品質を下げるという判断は学びの速度低下を許容すること
リードタイムが増加すると、仮説検証プロセスが回らない
リリース -> 仮説検証 -> リリース -> 正解を探す
プロセスを回すと、より望ましい、競争力のあるソフトウェアが作れる

質がボロボロ -> ちゃんと動かない -> やる気をそぐ -> たちが悪い!!
質vsスピードという二律背反の関係は、局所的なものでしかない
片方を犠牲にした場合、知らぬうちに もう一つも犠牲 にしている
※ 質、品質・・・本や文脈によって、何を指しているのか読み解くのが大事

質とスピードを図る4つのキーメトリクス

  • リードタイム
  • デプロイ頻度
  • MTTR(平均修復時間)
  • 変更失敗率

リードタイム:コードが書かれてから出荷されるまでの時間

企画からではなく実装から(スタート地点が測りづらい。正確にメトリクスを図るために、意図的にリードタイムの幅を狭めている)

MTTR(平均修復時間)

問題発生してから回復されるまでの時間を図る
早く回復するのであれば、この品質は高いと判断される
デプロイはどの程度自由にできるのか?
プロアクティブな品質だけでなく、リアクティブな品質
プロダクトの高い品質を得るために大事である

リードタイムとデプロイ頻度 : flow効率とresource効率

たくさんのことを同時に調整しようとする
複数のことを同時に調整しなければならないので、会議やら定例やらが増える

4つのキーメトリクス : 2019年の調査

エリート/ハイパフォーマー/ミディアムパフォーマー/ローパフォーマーへのSurvey
エリートほど時間が短く、失敗率が低い
ローパフォーマーでは、極端に数値が悪化する

  • 開発速度と品質はトレードオフの関係ではない
  • 組織間の差はかなり大きく、さらに開いている(2016 - 2019)
  • 圧倒的な差は継続的デリバリやDevOpsへの組織的な投資の差

短期/中期の境目は?

  • Tactical (ガンガン行こうぜ!)
  • Strategic(ちゃんと設計する)
    設計をちゃんとすると、開発スピードが上げられる
    短期と中期の境目は思ったより手前である

内部品質を上げなくても、問題がでるときには自分はいないし・・・と目を背ける。内部品質を上げることは道徳や矜持の問題?
-> 内部品質への投資の損益分岐点は3年後とかではなく 1ヶ月以内に現れる
  短期/中期の境目は1ヶ月

スピードを取ろうとして質を捨てることは、1ヶ月後には逆効果になる
内部品質への投資の受益者は自分たち自身。道徳や矜持の話ではなく、損得の話である
-> 自分事として内部品質をとらえる

質とスピードを聞いて、改善した事例

キャディ株式会社
https://caddi.tech/archives/1614

リファクタリング用のリソースを純増したわけでは無く、Sprint内の20-30%を投資すると決めた
1-2ヶ月経った後は明確にデリバリー速度が高まった

あらぶる四天王のうち、どれを倒すか?

-> スコープを削る
スコープを削り、リリース速度を守る
リリースを延期するとベロシティが測りづらいので、スコープを削ることがおすすめ
スピード及び質とトレードオフされるのは、 メンバーの成長とその成長のために必要なfeedbackや学習の時間 である

Q&A

※ライブ回答されたものだけ

1

組織の変化が必要と考える。組織が大きいほど限界を感じる
大きな組織に対して今回の発表をどのように生かせばいいか?
そのような組織に生かした事例があれば

  • 個人レベル
    • 切磋琢磨する、自分のレベルを上げていく
    • 良い仕事を素早く行うことができるようになっていく
  • 組織レベル
    • 組織への伝播はしづらい
    • プロダクトの意思決定層に話が刺さればぐっとくる
    • 組織へは事例推し
    • 4つのキーメトリクス エリート~ローパフォーマー・・・自分の組織がどこに属すか?

日本人を動かす言葉「もうみんなやってますよ」※劇薬注意

2

損益分岐点が1ヶ月とあるが、人数など定量的な関係があるか?
アーキテクティング: いつ、どれだけ?

  • ソフトウェアシステムが大きくなるほど、前払いのアーキテクチャ設計から受ける恩恵は大きくなる
  • 小規模(1万行)のソフトウェアシステムでは、前払いのアーキテクチャ策定からはほとんど恩恵を受けられない
  • アーキテクチャ設計に少ししか投資しないと強烈なしっぺ返しが来ることが予想される
  • アーキテクチャに投資すればするほど、必要な手直しは少なくなる

感想

実際にコードを書く業務ではないものの、刺さる(耳の痛い・・・)話が多かったです。
"質とスピード"なので、質vsスピード・・・と思いがちですが、実際には質とスピードはトレードオフではなく、質が高いからこそ早く提供できるというのが、データで示されていて納得感がとてもありました。

いまのソフトウェアは、たくさんの変更が高速で行われるからこそ、内部品質を上げることを大事にしていく必要があると感じました。
また自分自身も継続的デリバリやDevOpsの知識をもっと広めていきたいな~と思います!

ミステリで伏線を回収していくような、ぱーっと目の前が開けるような講演で、すごくおもしろかったです😊

Discussion