Upgrade to Pro — share decks privately, control downloads, hide ads and more …

アジャイルと品質

bayashi
February 14, 2020

 アジャイルと品質

社内の技術者コミュニティ向けにアジャイルと品質について語りました。持論多め。

bayashi

February 14, 2020
Tweet

More Decks by bayashi

Other Decks in Technology

Transcript

  1. アジャイルと
    品質
    村林慧
    2020/2/14 技術者コミュニティイベント

    View full-size slide

  2. 自己紹介
    アジャイル好き、仕事する
    の嫌い
    大学でソフトウェア検証系
    の研究室にいました
    今はアジャイルをやったり
    やらなかったり
    村林慧

    View full-size slide

  3. 想定するターゲット
    • アジャイルってなんとなく知ってるけど、食指が動かない
    • 適当に開発するイメージがあって、いけ好かない
    • アジャイルって品質悪いんでしょ?

    View full-size slide

  4. アジャイルとは

    View full-size slide

  5. 定義はAND集合
    アジャイルソフトウェア開発宣言
    スクラム
    XP リーン
    注 : もっとたくさん手法はありますが、図のわかりやすさのためにこの3つに絞らさせていただきました。ごめんなさい

    View full-size slide

  6. 使われ方はOR集合(感がある)
    アジャイル
    スクラム
    XP リーン
    注 : もっとたくさん手法はありますが、図のわかりやすさのためにこの3つに絞らさせていただきました。ごめんなさい

    View full-size slide

  7. アジャイルとは(今日の文脈)
    • 短い期間に区切って、繰り返し開発するよ
    • 得た知識を、次のタイミングで生かすよ
    • 作ったものはどんどんリリースするよ
    • 自分たち(現場)でプロセスやツールを決めてくよ
    • 新しい技術、新しいやり方、どんどん取り入れるよ

    View full-size slide

  8. 今日のテーマ

    View full-size slide

  9. アジャイルって品質悪いの?

    View full-size slide

  10. そもそも品質とはなんだ

    View full-size slide

  11. V&Vとか
    • Verification
    • 決めた仕様に合致しているかどうか
    • Validation
    • ユーザの意図通りに動いているかどうか

    View full-size slide

  12. 狩野モデルとか

    当たり前品質

    一元的品質

    魅力品質

    無関心品質

    逆品質

    View full-size slide

  13. 色々あるけれど
    今回は

    View full-size slide

  14. 品質特性と絡めてお送りいたします

    機能性

    信頼性

    効率性

    移植性

    使用性

    保守性

    View full-size slide

  15. アジャイルの
    どういう特徴
    によって
    どういう品質特性
    が変わるのか

    View full-size slide

  16. よく聞く話

    そもそも試験しないんでしょ?

    ドキュメント書かないんでしょ?

    場当たりな開発するから、全体の設計ができず品質が悪い

    最初に要件決めずに走るから要件漏れが多い

    新しい技術どんどん使うから不安定

    色んなところに継続的に手を入れるからデグレがやばそう

    試験工程が区切られてないから品質評価が難しい

    View full-size slide

  17. 場当たりな開発するから、
    全体の設計ができず品質が悪い
    保守性が悪い

    View full-size slide

  18. 半分本当半分嘘
    放っておいたらそうなります
    ただ何度も繰り返し変更を加えるアジャイルにおいて、
    保守性(解析性や変更性)は生命線
    だから健康的なチームではソースコードを書く
    かなりの時間をリファクタリングに使います
    →常に最良のアーキテクチャにするために投資
    リファクタリングそんなにやってデグレやばそうに関しては
    「色んなところに継続的に手を入れるからデグレがやばそう」のところとかぶるので今は割愛

    View full-size slide

  19. 個人的にアジャイルの
    好きなところ

    View full-size slide

  20. 開発初期 開発中期 開発終盤
    開発が進むにつれて知識が増えていく

    View full-size slide

  21. 開発初期 開発中期 開発終盤
    その知識を活用しながら開発していける

    View full-size slide

  22. 設計は最後に行う

    ソフトウェア開発は後から分かることが多い

    それを随時反映していく

    設計は大事、それを知識十分な状態でやりたい

    良い設計は開発が進んだあとの自分たちの方が詳しいと知っ
    ているため、最初の設計にそこまで拘らない
    (完璧を目指さない)

    最初に設計しないじゃなくて、いつだって設計しなおせるが
    アジャイルのやり方

    View full-size slide

  23. 持論
    ちゃんと保守性を担保するために投資すれば
    保守性は良い

    View full-size slide

  24. 最初に要件決めずに走るから
    要件漏れが多い
    機能性が低い

    View full-size slide

  25. 要件を決めないとは
    要件を決めないという言葉に含められたレベル感が
    数多の悲劇を生んでいる気がする

    View full-size slide

  26. このプロダク
    トは何がやり
    たいんだ
    何作れば
    いいんだ どうやってこ
    れ儲けるの…
    ユーザの抱え
    る課題は何な
    んだ

    View full-size slide

  27. このプロダク
    トは何がやり
    たいんだ
    何作れば
    いいんだ どうやってこ
    れ儲けるの‥
    ユーザの抱え
    る課題は何な
    んだ
    でも…

    View full-size slide

  28. アジャイルだから
    開発できるね

    View full-size slide

  29. アジャイルだから
    開発できるね
    ではない

    View full-size slide

  30. じゃあ要件を決めないって

    やりたこと、やるべきこともある

    ユーザの課題もわかってる

    マネタイズの方法もできてる

    View full-size slide

  31. じゃあ要件を決めないって

    やりたこと、やるべきこともある

    ユーザの課題もわかってる

    マネタイズの方法もできてる
    でも…

    View full-size slide

  32. 全部仮説よね

    本当にうまくいくかどうかはやってみないとわからないよね
    • 経験主義

    だからちょっとずつ作って自分たちの仮説があってるかを
    確認しながらやっていこう

    間違ってたら方向を修正していこう

    View full-size slide

  33. マジと真面目

    マジな要件って、モノが出来上がってきて
    ユーザが使いだしてから出てくる

    ドキュメントを見せると、
    ユーザは真面目にレビューしてくれる
    • でもマジじゃない

    早めにモノ作ることでユーザを
    真面目状態からマジ状態に素早くシフト

    View full-size slide

  34. 持論
    顧客のマジを早めに引き出すことで
    マジな要件を早めに手に入れることができれば
    機能性は良い

    View full-size slide

  35. 新しい技術を
    どんどん使うから不安定
    信頼性が低い

    View full-size slide

  36. 新しい技術をどんどん使うから不安定

    昔は枯れた技術を使えなんて話がありましたが

    枯れた技術(ライブラリ)の方が怖くてつかえなくない?
    • (当たり前だけど)新しい技術をどんどん取り入れているのは、
    新しい技術を積極的に学習し、採用判断を行って入れている

    ただ闇雲に新しいからよい!ってわけではなく、メリットデ
    メリットを考えて入れている

    View full-size slide

  37. 品質の世界にも新しい技術、プロセス
    どんどん入ってきてるよ

    継続的インテグレーション

    テスト駆動開発

    カオスエンジニアリング

    オートスケール、オートヒーリング

    カナリヤリリース

    色んなテストフレームワーク

    View full-size slide

  38. 持論
    信頼性上げるために取捨選択して新しい技術を学び続ければ
    信頼性は高い

    View full-size slide

  39. 色んなところに手を入れるから
    デグレやばそう
    全体的な話

    View full-size slide

  40. それはそう

    テストを書け

    自動テストを書くんだ

    自動テストで品質を確認しながら作っていけば怖いものは何
    もない

    アジリティを確保するために、テストを書くんだ

    View full-size slide

  41. 基本的に

    やんなきゃいけないことはやんなきゃいけない

    性能試験もデグレ試験も全部やんないと品質を確認した上で
    リリースはできない
    • WFもアジャイルも一緒

    内容を修正したら、もう一回やり直さないといけない
    • WFもアジャイルも一緒

    内容修正しまくるから、テストもやりまくる
    →テスト自動化しないとやってらんない

    View full-size slide

  42. 持論
    それはそうだから
    自動テストに投資をしよう

    View full-size slide

  43. 試験工程が区切られていないから
    品質保証ができない
    信頼性が低い(確認できない)

    View full-size slide

  44. 実はできるよ品質評価

    メトリクス自体は当たり前だけど、取れる

    過去の類似案件から試験項目数、バグ数、コードの行数とっ
    てくるのはアジャイルでもできる

    出来ないのはなんだろバグ収束曲線(ゴンベルツ)とかくら
    い?

    View full-size slide

  45. じゃあなんで品質保証はできない?

    今みんな頑張ってどんなメトリクスをとってどう判断すれば
    品質を保証できるか考えている

    View full-size slide


  46. で、みんな気づく
    • 品質評価はできても、品質の保証(大丈夫です!)って
    無理なんじゃないの…?
    • 今までやってた意味あるって思ってたやつって
    実はあんまり意味ないんじゃないの…?
    じゃあなんで品質保証はできない?

    View full-size slide

  47. 見えない誰かに太鼓判を
    押してもらうと人は安心する
    品質OKです
    品質大丈夫です
    か?

    View full-size slide

  48. 見えない誰かに太鼓判を
    押してもらうと人は安心する
    まぁどうなるかわからん
    けど、数字上はヨシ!
    どうなのかわからんけど、
    この人がヨシって言ったか
    らヨシ!

    View full-size slide

  49. 見えない誰かに太鼓判を
    押してもらうと人は安心する
    まぁどうなるかわか
    らんけど、数字上は
    ヨシ!
    どうなのかわからんけ
    ど、この人がヨシって
    言ったからヨシ!
    責任分散モデル

    View full-size slide

  50. twitter上で誰かが言ってた良い言葉
    あなたがスクラムを実践するとき、あなたは困難にぶつかるでしょう。
    それはスクラムが困難を生み出しているわけではなく、スクラムが既
    存の困難を見つけ出してくれたのです

    View full-size slide

  51. 持論
    そもそも品質保証なんて
    難しいよ
    不安を抱えつつ、
    意味のあることをやろう

    View full-size slide

  52. 最後に言いたいこと

    View full-size slide

  53. そもそもさ
    • バグが商用で出まくる時ってどういうタイミング?
    • スケジュールが超やばい
    • メンバのスキルが足りてない
    • 製品知識が足りない
    • 顧客が仕様コロコロ変えてきて、プロジェクトが火を噴いた
    • そもそも、試験してない(できなかった)
    • スケジュールの逼迫でわけのわからないメンバが朦朧としつつ試験し
    て「試験全部通りました!」

    View full-size slide

  54. そもそもさ
    • バグが商用で出まくる時ってどういうタイミング?
    • スケジュールが超やばい
    • メンバのスキルが足りてない
    • 製品知識が足りない
    • 顧客が仕様コロコロ変えてきて、プロジェクトが火を噴いた
    • そもそも、試験してない(できなかった)
    • スケジュールの逼迫でわけのわからないメンバが朦朧としつつ試験し
    て「試験全部通りました!」
    プロセス関係
    ない!

    View full-size slide

  55. アジャイルの魅力

    理想論でなく、現実解

    現場で起きていることをありのまま受け入れる
    • その上でより良いやり方を模索する

    不安を抱えつつ、前に進んでいく

    View full-size slide