Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
アジャイルと品質
Search
bayashi
February 14, 2020
Technology
1
1.1k
アジャイルと品質
社内の技術者コミュニティ向けにアジャイルと品質について語りました。持論多め。
bayashi
February 14, 2020
Tweet
Share
More Decks by bayashi
See All by bayashi
エンジニアとして関わる要件と仕様(公開用)
murabayashi
0
390
個人事業主型開発からの脱却
murabayashi
13
9k
スクラムフェスを支える配信の仕組み
murabayashi
1
520
締切とはなにか、どういう効果があるのか #scrummikawa
murabayashi
0
1.2k
商用アプリケーション開発基本のキ
murabayashi
0
220
(新米)エンジニアリングマネージャーのしごと #RSGT2023
murabayashi
11
11k
Active Recordについてわかったことを説明するよ
murabayashi
0
310
話を聞き出す技術
murabayashi
43
47k
フィヨルドブートキャンプ ドリンクアップ用会社紹介資料
murabayashi
0
350
Other Decks in Technology
See All in Technology
AWSサービスアップデート 2024/12 Part3
nrinetcom
PRO
0
120
あなたの知らないクラフトビールの世界
miura55
0
100
技術に触れたり、顔を出そう
maruto
1
130
東京Ruby会議12 Ruby と Rust と私 / Tokyo RubyKaigi 12 Ruby, Rust and me
eagletmt
3
810
深層学習と3Dキャプチャ・3Dモデル生成(土木学会応用力学委員会 応用数理・AIセミナー)
pfn
PRO
0
450
OPENLOGI Company Profile
hr01
0
58k
My small contributions - Fujiwara Tech Conference 2025
ijin
0
1.3k
生成AI × 旅行 LLMを活用した旅行プラン生成・チャットボット
kominet_ava
0
150
チームが毎日小さな変化と適応を続けたら1年間でスケール可能なアジャイルチームができた話 / Building a Scalable Agile Team
kakehashi
2
210
あなたの人生も変わるかも?AWS認定2つで始まったウソみたいな話
iwamot
3
810
ゼロからわかる!!AWSの構成図を書いてみようワークショップ 問題&解答解説 #デッカイギ #羽田デッカイギおつ
_mossann_t
0
1.5k
.NET AspireでAzure Functionsやクラウドリソースを統合する
tsubakimoto_s
0
180
Featured
See All Featured
We Have a Design System, Now What?
morganepeng
51
7.3k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.9k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Building Your Own Lightsaber
phodgson
104
6.2k
Faster Mobile Websites
deanohume
305
30k
Bash Introduction
62gerente
610
210k
Docker and Python
trallard
43
3.2k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
Automating Front-end Workflow
addyosmani
1366
200k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
230
52k
Transcript
アジャイルと 品質 村林慧 2020/2/14 技術者コミュニティイベント
自己紹介 アジャイル好き、仕事する の嫌い 大学でソフトウェア検証系 の研究室にいました 今はアジャイルをやったり やらなかったり 村林慧
想定するターゲット • アジャイルってなんとなく知ってるけど、食指が動かない • 適当に開発するイメージがあって、いけ好かない • アジャイルって品質悪いんでしょ?
アジャイルとは
定義はAND集合 アジャイルソフトウェア開発宣言 スクラム XP リーン 注 : もっとたくさん手法はありますが、図のわかりやすさのためにこの3つに絞らさせていただきました。ごめんなさい
使われ方はOR集合(感がある) アジャイル スクラム XP リーン 注 : もっとたくさん手法はありますが、図のわかりやすさのためにこの3つに絞らさせていただきました。ごめんなさい
アジャイルとは(今日の文脈) • 短い期間に区切って、繰り返し開発するよ • 得た知識を、次のタイミングで生かすよ • 作ったものはどんどんリリースするよ • 自分たち(現場)でプロセスやツールを決めてくよ •
新しい技術、新しいやり方、どんどん取り入れるよ
今日のテーマ
アジャイルって品質悪いの?
そもそも品質とはなんだ
V&Vとか • Verification • 決めた仕様に合致しているかどうか • Validation • ユーザの意図通りに動いているかどうか
狩野モデルとか • 当たり前品質 • 一元的品質 • 魅力品質 • 無関心品質 •
逆品質
色々あるけれど 今回は
品質特性と絡めてお送りいたします • 機能性 • 信頼性 • 効率性 • 移植性 •
使用性 • 保守性
アジャイルの どういう特徴 によって どういう品質特性 が変わるのか
よく聞く話 • そもそも試験しないんでしょ? • ドキュメント書かないんでしょ? • 場当たりな開発するから、全体の設計ができず品質が悪い • 最初に要件決めずに走るから要件漏れが多い •
新しい技術どんどん使うから不安定 • 色んなところに継続的に手を入れるからデグレがやばそう • 試験工程が区切られてないから品質評価が難しい
場当たりな開発するから、 全体の設計ができず品質が悪い 保守性が悪い
半分本当半分嘘 放っておいたらそうなります ただ何度も繰り返し変更を加えるアジャイルにおいて、 保守性(解析性や変更性)は生命線 だから健康的なチームではソースコードを書く かなりの時間をリファクタリングに使います →常に最良のアーキテクチャにするために投資 リファクタリングそんなにやってデグレやばそうに関しては 「色んなところに継続的に手を入れるからデグレがやばそう」のところとかぶるので今は割愛
個人的にアジャイルの 好きなところ
開発初期 開発中期 開発終盤 開発が進むにつれて知識が増えていく
開発初期 開発中期 開発終盤 その知識を活用しながら開発していける
設計は最後に行う • ソフトウェア開発は後から分かることが多い • それを随時反映していく • 設計は大事、それを知識十分な状態でやりたい • 良い設計は開発が進んだあとの自分たちの方が詳しいと知っ ているため、最初の設計にそこまで拘らない
(完璧を目指さない) • 最初に設計しないじゃなくて、いつだって設計しなおせるが アジャイルのやり方
持論 ちゃんと保守性を担保するために投資すれば 保守性は良い
最初に要件決めずに走るから 要件漏れが多い 機能性が低い
要件を決めないとは 要件を決めないという言葉に含められたレベル感が 数多の悲劇を生んでいる気がする
このプロダク トは何がやり たいんだ 何作れば いいんだ どうやってこ れ儲けるの… ユーザの抱え る課題は何な んだ
このプロダク トは何がやり たいんだ 何作れば いいんだ どうやってこ れ儲けるの‥ ユーザの抱え る課題は何な んだ
でも…
アジャイルだから 開発できるね
アジャイルだから 開発できるね ではない
じゃあ要件を決めないって • やりたこと、やるべきこともある • ユーザの課題もわかってる • マネタイズの方法もできてる
じゃあ要件を決めないって • やりたこと、やるべきこともある • ユーザの課題もわかってる • マネタイズの方法もできてる でも…
全部仮説よね • 本当にうまくいくかどうかはやってみないとわからないよね • 経験主義 • だからちょっとずつ作って自分たちの仮説があってるかを 確認しながらやっていこう • 間違ってたら方向を修正していこう
マジと真面目 • マジな要件って、モノが出来上がってきて ユーザが使いだしてから出てくる • ドキュメントを見せると、 ユーザは真面目にレビューしてくれる • でもマジじゃない •
早めにモノ作ることでユーザを 真面目状態からマジ状態に素早くシフト
持論 顧客のマジを早めに引き出すことで マジな要件を早めに手に入れることができれば 機能性は良い
新しい技術を どんどん使うから不安定 信頼性が低い
新しい技術をどんどん使うから不安定 • 昔は枯れた技術を使えなんて話がありましたが • 枯れた技術(ライブラリ)の方が怖くてつかえなくない? • (当たり前だけど)新しい技術をどんどん取り入れているのは、 新しい技術を積極的に学習し、採用判断を行って入れている • ただ闇雲に新しいからよい!ってわけではなく、メリットデ
メリットを考えて入れている
品質の世界にも新しい技術、プロセス どんどん入ってきてるよ • 継続的インテグレーション • テスト駆動開発 • カオスエンジニアリング • オートスケール、オートヒーリング
• カナリヤリリース • 色んなテストフレームワーク
持論 信頼性上げるために取捨選択して新しい技術を学び続ければ 信頼性は高い
色んなところに手を入れるから デグレやばそう 全体的な話
それはそう • テストを書け • 自動テストを書くんだ • 自動テストで品質を確認しながら作っていけば怖いものは何 もない • アジリティを確保するために、テストを書くんだ
基本的に • やんなきゃいけないことはやんなきゃいけない • 性能試験もデグレ試験も全部やんないと品質を確認した上で リリースはできない • WFもアジャイルも一緒 • 内容を修正したら、もう一回やり直さないといけない
• WFもアジャイルも一緒 • 内容修正しまくるから、テストもやりまくる →テスト自動化しないとやってらんない
持論 それはそうだから 自動テストに投資をしよう
試験工程が区切られていないから 品質保証ができない 信頼性が低い(確認できない)
実はできるよ品質評価 • メトリクス自体は当たり前だけど、取れる • 過去の類似案件から試験項目数、バグ数、コードの行数とっ てくるのはアジャイルでもできる • 出来ないのはなんだろバグ収束曲線(ゴンベルツ)とかくら い?
じゃあなんで品質保証はできない? • 今みんな頑張ってどんなメトリクスをとってどう判断すれば 品質を保証できるか考えている
• で、みんな気づく • 品質評価はできても、品質の保証(大丈夫です!)って 無理なんじゃないの…? • 今までやってた意味あるって思ってたやつって 実はあんまり意味ないんじゃないの…? じゃあなんで品質保証はできない?
見えない誰かに太鼓判を 押してもらうと人は安心する 品質OKです 品質大丈夫です か?
見えない誰かに太鼓判を 押してもらうと人は安心する まぁどうなるかわからん けど、数字上はヨシ! どうなのかわからんけど、 この人がヨシって言ったか らヨシ!
見えない誰かに太鼓判を 押してもらうと人は安心する まぁどうなるかわか らんけど、数字上は ヨシ! どうなのかわからんけ ど、この人がヨシって 言ったからヨシ! 責任分散モデル
twitter上で誰かが言ってた良い言葉 あなたがスクラムを実践するとき、あなたは困難にぶつかるでしょう。 それはスクラムが困難を生み出しているわけではなく、スクラムが既 存の困難を見つけ出してくれたのです
持論 そもそも品質保証なんて 難しいよ 不安を抱えつつ、 意味のあることをやろう
最後に言いたいこと
そもそもさ • バグが商用で出まくる時ってどういうタイミング? • スケジュールが超やばい • メンバのスキルが足りてない • 製品知識が足りない •
顧客が仕様コロコロ変えてきて、プロジェクトが火を噴いた • そもそも、試験してない(できなかった) • スケジュールの逼迫でわけのわからないメンバが朦朧としつつ試験し て「試験全部通りました!」
そもそもさ • バグが商用で出まくる時ってどういうタイミング? • スケジュールが超やばい • メンバのスキルが足りてない • 製品知識が足りない •
顧客が仕様コロコロ変えてきて、プロジェクトが火を噴いた • そもそも、試験してない(できなかった) • スケジュールの逼迫でわけのわからないメンバが朦朧としつつ試験し て「試験全部通りました!」 プロセス関係 ない!
アジャイルの魅力 • 理想論でなく、現実解 • 現場で起きていることをありのまま受け入れる • その上でより良いやり方を模索する • 不安を抱えつつ、前に進んでいく
None