社内の技術者コミュニティ向けにアジャイルと品質について語りました。持論多め。
アジャイルと品質村林慧2020/2/14 技術者コミュニティイベント
View Slide
自己紹介アジャイル好き、仕事するの嫌い大学でソフトウェア検証系の研究室にいました今はアジャイルをやったりやらなかったり村林慧
想定するターゲット• アジャイルってなんとなく知ってるけど、食指が動かない• 適当に開発するイメージがあって、いけ好かない• アジャイルって品質悪いんでしょ？
アジャイルとは
定義はAND集合アジャイルソフトウェア開発宣言スクラムXP リーン注 : もっとたくさん手法はありますが、図のわかりやすさのためにこの３つに絞らさせていただきました。ごめんなさい
使われ方はOR集合（感がある）アジャイルスクラムXP リーン注 : もっとたくさん手法はありますが、図のわかりやすさのためにこの３つに絞らさせていただきました。ごめんなさい
アジャイルとは（今日の文脈）• 短い期間に区切って、繰り返し開発するよ• 得た知識を、次のタイミングで生かすよ• 作ったものはどんどんリリースするよ• 自分たち（現場）でプロセスやツールを決めてくよ• 新しい技術、新しいやり方、どんどん取り入れるよ
今日のテーマ
アジャイルって品質悪いの？
そもそも品質とはなんだ
V＆Vとか• Verification• 決めた仕様に合致しているかどうか• Validation• ユーザの意図通りに動いているかどうか
狩野モデルとか•当たり前品質•一元的品質•魅力品質•無関心品質•逆品質
色々あるけれど今回は
品質特性と絡めてお送りいたします•機能性•信頼性•効率性•移植性•使用性•保守性
アジャイルのどういう特徴によってどういう品質特性が変わるのか
よく聞く話•そもそも試験しないんでしょ？•ドキュメント書かないんでしょ？•場当たりな開発するから、全体の設計ができず品質が悪い•最初に要件決めずに走るから要件漏れが多い•新しい技術どんどん使うから不安定•色んなところに継続的に手を入れるからデグレがやばそう•試験工程が区切られてないから品質評価が難しい
場当たりな開発するから、全体の設計ができず品質が悪い保守性が悪い
半分本当半分嘘放っておいたらそうなりますただ何度も繰り返し変更を加えるアジャイルにおいて、保守性（解析性や変更性）は生命線だから健康的なチームではソースコードを書くかなりの時間をリファクタリングに使います→常に最良のアーキテクチャにするために投資リファクタリングそんなにやってデグレやばそうに関しては「色んなところに継続的に手を入れるからデグレがやばそう」のところとかぶるので今は割愛
個人的にアジャイルの好きなところ
開発初期 開発中期 開発終盤開発が進むにつれて知識が増えていく
開発初期 開発中期 開発終盤その知識を活用しながら開発していける
設計は最後に行う•ソフトウェア開発は後から分かることが多い•それを随時反映していく•設計は大事、それを知識十分な状態でやりたい•良い設計は開発が進んだあとの自分たちの方が詳しいと知っているため、最初の設計にそこまで拘らない（完璧を目指さない）•最初に設計しないじゃなくて、いつだって設計しなおせるがアジャイルのやり方
持論ちゃんと保守性を担保するために投資すれば保守性は良い
最初に要件決めずに走るから要件漏れが多い機能性が低い
要件を決めないとは要件を決めないという言葉に含められたレベル感が数多の悲劇を生んでいる気がする
このプロダクトは何がやりたいんだ何作ればいいんだ どうやってこれ儲けるの…ユーザの抱える課題は何なんだ
このプロダクトは何がやりたいんだ何作ればいいんだ どうやってこれ儲けるの‥ユーザの抱える課題は何なんだでも…
アジャイルだから開発できるね
アジャイルだから開発できるねではない
じゃあ要件を決めないって•やりたこと、やるべきこともある•ユーザの課題もわかってる•マネタイズの方法もできてる
じゃあ要件を決めないって•やりたこと、やるべきこともある•ユーザの課題もわかってる•マネタイズの方法もできてるでも…
全部仮説よね•本当にうまくいくかどうかはやってみないとわからないよね• 経験主義•だからちょっとずつ作って自分たちの仮説があってるかを確認しながらやっていこう•間違ってたら方向を修正していこう
マジと真面目•マジな要件って、モノが出来上がってきてユーザが使いだしてから出てくる•ドキュメントを見せると、ユーザは真面目にレビューしてくれる• でもマジじゃない•早めにモノ作ることでユーザを真面目状態からマジ状態に素早くシフト
持論顧客のマジを早めに引き出すことでマジな要件を早めに手に入れることができれば機能性は良い
新しい技術をどんどん使うから不安定信頼性が低い
新しい技術をどんどん使うから不安定•昔は枯れた技術を使えなんて話がありましたが•枯れた技術（ライブラリ）の方が怖くてつかえなくない？• (当たり前だけど）新しい技術をどんどん取り入れているのは、新しい技術を積極的に学習し、採用判断を行って入れている•ただ闇雲に新しいからよい！ってわけではなく、メリットデメリットを考えて入れている
品質の世界にも新しい技術、プロセスどんどん入ってきてるよ•継続的インテグレーション•テスト駆動開発•カオスエンジニアリング•オートスケール、オートヒーリング•カナリヤリリース•色んなテストフレームワーク
持論信頼性上げるために取捨選択して新しい技術を学び続ければ信頼性は高い
色んなところに手を入れるからデグレやばそう全体的な話
それはそう•テストを書け•自動テストを書くんだ•自動テストで品質を確認しながら作っていけば怖いものは何もない•アジリティを確保するために、テストを書くんだ
基本的に•やんなきゃいけないことはやんなきゃいけない•性能試験もデグレ試験も全部やんないと品質を確認した上でリリースはできない• WFもアジャイルも一緒•内容を修正したら、もう一回やり直さないといけない• WFもアジャイルも一緒•内容修正しまくるから、テストもやりまくる→テスト自動化しないとやってらんない
持論それはそうだから自動テストに投資をしよう
試験工程が区切られていないから品質保証ができない信頼性が低い（確認できない）
実はできるよ品質評価•メトリクス自体は当たり前だけど、取れる•過去の類似案件から試験項目数、バグ数、コードの行数とってくるのはアジャイルでもできる•出来ないのはなんだろバグ収束曲線（ゴンベルツ）とかくらい？
じゃあなんで品質保証はできない？•今みんな頑張ってどんなメトリクスをとってどう判断すれば品質を保証できるか考えている
•で、みんな気づく• 品質評価はできても、品質の保証（大丈夫です！）って無理なんじゃないの…?• 今までやってた意味あるって思ってたやつって実はあんまり意味ないんじゃないの…?じゃあなんで品質保証はできない？
見えない誰かに太鼓判を押してもらうと人は安心する品質OKです品質大丈夫ですか？
見えない誰かに太鼓判を押してもらうと人は安心するまぁどうなるかわからんけど、数字上はヨシ！どうなのかわからんけど、この人がヨシって言ったからヨシ！
見えない誰かに太鼓判を押してもらうと人は安心するまぁどうなるかわからんけど、数字上はヨシ！どうなのかわからんけど、この人がヨシって言ったからヨシ！責任分散モデル
twitter上で誰かが言ってた良い言葉あなたがスクラムを実践するとき、あなたは困難にぶつかるでしょう。それはスクラムが困難を生み出しているわけではなく、スクラムが既存の困難を見つけ出してくれたのです
持論そもそも品質保証なんて難しいよ不安を抱えつつ、意味のあることをやろう
最後に言いたいこと
そもそもさ• バグが商用で出まくる時ってどういうタイミング？• スケジュールが超やばい• メンバのスキルが足りてない• 製品知識が足りない• 顧客が仕様コロコロ変えてきて、プロジェクトが火を噴いた• そもそも、試験してない（できなかった）• スケジュールの逼迫でわけのわからないメンバが朦朧としつつ試験して「試験全部通りました！」
そもそもさ• バグが商用で出まくる時ってどういうタイミング？• スケジュールが超やばい• メンバのスキルが足りてない• 製品知識が足りない• 顧客が仕様コロコロ変えてきて、プロジェクトが火を噴いた• そもそも、試験してない（できなかった）• スケジュールの逼迫でわけのわからないメンバが朦朧としつつ試験して「試験全部通りました！」プロセス関係ない！
アジャイルの魅力•理想論でなく、現実解•現場で起きていることをありのまま受け入れる• その上でより良いやり方を模索する•不安を抱えつつ、前に進んでいく
murabayashi
koba1t
mapbox_jp
xibuka
sbtechnight
imanolteran
oracle4engineer
ywada526
cembasaranoglu
dongjin
trallard
carmenintech
lara
lauravandoore
panda_program
tmm1
shlominoach
mongodb
3n
jnunemaker
bryan