DevOps時代におけるクオリティ・エンジニアの重要性 （前編）
はじめに
お久しぶりです。@numehaです。前回の投稿から約半年間が経過しました。AKB48のあっちゃんさよならライブ生中継を見ながら書いております。
「DevOps時代」なんて目を引くタイトルにしてみたものの、ただの思いつきの投稿です。はい。
とあるメーカで働いている私の体験談や思いを一部フィクションを交えてお届けしたいと思います。何かフィードバックいただけるとこれからの活動の参考になります。よろしくお願いします。
DevOpsって
DevOpsはムーブメントだ！なんて言われていますね。このスライドの説明が一番わかりやすいですね。
そうそう。わかるわかる。。。。
ん。いや、ちょっと待てよ。私は未熟者なのでまだピンときていないのですが、何か違和感がありますね。
開発と運用の垣根がなくなるのだけど責任は異なるの？お互いのことをわかった上で取り組もうということなのだろうけど、そもそもこれ系の話は開発と運用だけに限った話ではないですよね。多少の壁がありながらもうまくお互いのことを理解するのはある意味当たり前の話でみんな苦しんでいる話だと思います。
歩み寄りもしないで一方的に否定から入るなんてもってのほかですね。
そんなこんなで最近もやもや考えながら日々仕事をしているわけですが、自分の中の勝手な定義としては、
何事もDevOpsな態度で取り組め！
これならピンとくるんだな。
相手を責めない、押しつけない、信頼しあう。相手がいてこその自分なのだから。
クオリティ・エンジニアって
一般的にはテスト・エンジニア？ということが多いのでしょうか。呼び方はどうでもよいのですが、あるソフトウェアの品質を最優先に考えて行動しているエンジニアのことです。
そんなのDeveloperであれば品質のこと考えてやってるよ、という声が聞こえてきそうですね。
「最優先に考える」
というところが重要だと私は考えています。
Developerであったら、何かを設計する、開発するということに注力することでしょう。今であればテストが重要だというDeveloperは多いと思いますが、「品質を最優先に考える」ことはかなり難しいでしょう。
また、運用のことも理解して開発をすることが求められていますが、それは意識だけではどうにもならない能力を要することだと思います。
（最優先に考えなくてもソフトウェア開発に重要なことを全て均等に完璧に考えられるスーパーマンだらけの組織は除きますがねw）
というわけで、
クオリティ・エンジニアはDeveloper、Operatorと協力して、品質の高いソフトウェアをリリースしてお客様にビジネス価値を届ける。それぞれが注力して取り組んでいるところの穴を埋めるような、そんな役割として活動するメンバーが重要だと感じています。
DevOpsの議論では、品質関係の話が軽薄な印象を受けます。品質の話は、開発と運用と同等またはそれ以上に難しいことだと私は思います。
だって人間だもの
話がそれますが、なんでクオリティ・エンジニアの役割が必要かと思った理由について少し。
私は長い間Developerとして活動してきましたが、いくら自分がたくさんのテストコードを書いても、いけてる設計だと思っても、たくさんのレビューをしても、思わぬバグを踏むことがあります。
そしてそのバグはリリース直前やリリース後に運用してみて発見されることもありました。
Developerにとってこんな悔しいことはありません。そのときは、なんで事前に発見できなかったのか、自分を責めて責めて枕を濡らした日もありました（言い過ぎましたw）。
そこで発見されるバグは例えば単純なマージミスのときもあるし、テストコードの漏れ、運用環境でしか発見されない問題もあり様々です。
また、ソフトウェア自体ではなくそれをデプロイした実行環境の設定ミスにより思わぬトラブルを踏むこともあります。
OperatorもDeveloperと同じことです。人間なのだからミスだって検討不足のことだってあるんです。
そんなこんなで、開発を最優先に考えるDeveloperと、品質・テストを最優先に考えるクオリティ・エンジニア、安定運用を最優先に考えるOperatorを定義して、お互いが協力して活動すればうまくいくのではないかと思ったのがきっかけです。
協力するということが重要で、お互いが相手のことを考えて行動しなくては意味がありません。
クオリティ・エンジニアは、とにかくビジネス（お客様）視点で、リリースするシステムの品質を向上させることが一番の仕事です。Developerの設計指針や仕様に関して検討段階から参加し、意識を合わせる必要があります。Operatorが運用する環境を理解してテストを実行する必要もあります。
こうすることにより、従来からあるすでに出来上がったもののバグ出しテストにはならず、戦略的に早期にテストを行うことができるようになります。
早期にクオリティ・エンジニアとテスト戦略について議論を重ねることで、バグをなるべく作りこまない開発を意識的に行うことができるようになります。
後編では、そんなクオリティ・エンジニアが取り組むいくつかの事例を紹介したいと思います。
参考
![【送料無料】ウェブオペレーション [ ジョン・アレスポー ]](http://hbb.afl.rakuten.co.jp/hgb/?pc=http%3a%2f%2fthumbnail.image.rakuten.co.jp%2f%400_mall%2fbook%2fcabinet%2f4934%2f9784873114934.jpg%3f_ex%3d300x300&m=http%3a%2f%2fthumbnail.image.rakuten.co.jp%2f%400_mall%2fbook%2fcabinet%2f4934%2f9784873114934.jpg%3f_ex%3d80x80) 【送料無料】ウェブオペレーション [ ジョン・アレスポー ] |
デブサミ2012に行ってきたよ
Developmers Summit 2012に行って来ました。
残念ながら二日目の午後からの参加でしたが、皆さんどれも素晴らしい発表で刺激を受けてきました。
一つ言えることは資料だけでは絶対にわからない。生の声を聞くことで感じることはたくさんある。
今後も色んな勉強会やイベントに参加しようと思いました。
自分も近い将来もっと大きくなったら100人集めるられるくらいになれるといいなぁ。
印象に残ったセッション、行けなかったセッションを自分用にちょーーー簡単にまとめてみました。
まず、衝撃を受けたのが@kakutaniのアジャイルマニフェスト ディケイド
前々から知っていたし、資料は色々みたことはあったのだけど生で見るのは初めて。
何がびびったって、登場しただけで観衆から拍手。
スティーブ・ジョブズかよwww
Nature of Softwareとは考えれば考えるほど深い。
そして、あの語れる能力はすごい。自分の中のベストスピーカー賞でした
そして、@kwappa, @regtan, @yoshioriのFrom Legacy to Agile ～レガシー開発からアジャイル開発へ～
自分が一番共感できたセッション。最後までいれなかったのが残念でしたが、この資料以外にも現場の話を色々と聞けてよかった。レガシー開発は自分の部署の周りでもあることなので、皆にも聞いて欲しかったなぁ。
コードが人についてしまうのは本当によくないと思っていて、書いた人以外もメンテできるように進めていくことが大事だよなぁと自分の今の仕事と重ねて聞かせていただきました。語り口調も好きでしたw
合わせて読みたい↓
テスト書け、問題を根性で解決するな、人殺す以外なら何やってもいい、失敗を引きずるな」デブサミで僕が話したことの簡単なまとめ
三周まわったおれたちのアジャイル
View more presentations from kwappa
レガシーの現実
View more presentations from regtan
そして、@kohsukekawaのContinuous DeliveryとJenkinsアブストラクト
これは聞きたかったけど行けなかった。会社休めばよかったんだよ絶対。
資料がまだ上がっていないようですね。
検証済みマージの話は興味があるのでWEB-DB買えってことねw
その他、興味深い資料がたくさん。
まだ全部見切れていませんが、今日のところはこのへんで。
View more presentations from Dai Fujihara
Devsumi2012 倉貫講演資料
View more presentations from Yoshihito Kuranuki
【17-A-2】 10年後も通用する開発環境の秘訣 ＜デブサミ2012＞
View more presentations from Tomoharu Nagasawa
Developer summit2012
View more presentations from Oracle Fusion Middleware
「ユーザエクスペリエンスのためのストーリーテリング」を読んだ
はじめに
どうも皆さんこんばんは。@numehaです。2011年も残すところ後わずかですが、いかがお過ごしでしょうか。
私は既にお休みを貰っていて、なんと13連休なんです。頭が腐りそうですw
という訳で、本を読みました。実はこの本、スクラム道場.08に参加させていただいたときに、@kawagutiさんに運良く頂いた本なんです。ブログ書くのが条件でしたので書きますよー。
と言っても、UXについては全くのド素人だし、ストーリーテリングって何なの？って感じの前提知識ゼロの私が読んだ感想ですので、参考になるかわかりませんが、1ユーザの意見として受け取って頂けたら幸いです。
読んだ本
これ。
何でもいいからモノを作っている人は全員読んだほうがいいんじゃね。と思うくらい良本です。
（特にうちの会社の人はマジで読んでほしーー。）
 ユーザエクスペリエンスのためのストーリーテリング |
ひと通り読んでみて
とても読みやすく、自席の横に常においておきたい、そんな本です。特にストーリーの作り方や使い方については、実践してみないとピンとこない点があったので、実践して読み返す、これを繰り返すといいのかなと感じました。
ストーリーテリングって新しい手法なのかな？とはじめは思っていたのですが、そうではなくて情報を共有する手段の一つなんですね。情報共有ってチーム内ではうまくいくことが多いのだけど、チームを超えて共有をしようとすると途端にうまくいかなくなりませんか？私は最近特にそういうことが多くてほんと困っていました。
その時は確か、偉い人に新しいアイデアをプレゼンする場面だったのですが、全く伝わりませんでした。
「言ってることはわかるけど、それでユーザの行動はどう変化するの？」
まぁ、そんな感じでフルボッコでしたw
今思えば、その指摘はその通りで、ストーリーテリングが出来ていなかったんです。
本の言葉を借りれば、オーディエンスの頭の中にストーリーが作られていなかったということです。
ストーリーテリングとはストーリーを単に語るだけではなく、オーディエンスがストーリーを作るための情報を提供してあげることです。オーディエンスの視点や先入観に合わせて変える必要があります。そのへんが難しいなぁと思っていたのですが、ちゃんとCHAPTER10の「ストーリーを共有する」に書いてありますので、読んでみてください。
自分はこの本でいうと「技術系のオーディエンス」になるのですが、確かに実現性を無視したストーリーを聞かされたときにはイライラしますね。「何夢みたいなこと言ってんだ！コラ！」とかw
それって、うまくストーリーになっていなかったのと、フィードバックをストーリーに反映して、それを繰り返しやっていなかったからなんでしょうね。一回で完璧なストーリーなんて出来るわけないし、何回もやることでそのギャップが埋まっていくことでしょう。
最後になりますが、自分が思ったストーリーテリングの一番の利点、それは
「ユーザのゴールについて共通理解を持てる」
ことだと思います。
少なからず、何かしらのモノを作っている人は、「これって誰のために作っているんだっけ？」と思ったことはあると思います。しかもそれが、経営、企画、開発、営業の人が違う認識だと悲劇的です。
その溝を埋めてくれるのが、ストーリーテリングなのでしょう。
少しずつかもしれませんが、実践していこうと思います。
関連資料
わかりやすい資料でしたので、載せておきます。
ぼくのかんがえたSoftware Test & Quality
はじめに
メリークリスマス。@numehaです。昨日はB'zのライブに行って来ました。品質は最高でしたw
Software Test ＆ Quality Advent Calendar 2011の25日目です。トリです。
本エントリーでは、B'zのライブがいかに品質が高いのか、ではなく、ぼくのかんがえたSoftware TestとQualityに関して、熱くるしい思いを皆にぶつけてみようと思います。温かいご意見お待ちしております。
私とテストと、時々、品質
私がテストの勉強を始めたのは2009年頃でした。それまでは「スパイク」のみで、テストなんてものはなく、ある程度動くコードだけでした。その時はそれで良かったんです。なぜならアイデアを形にし、それが有用であるのか検証することが目的だったからです。その動くコードに問題があっても誰も困りません。お客様は、新しいシステムのイメージが出来ればいいんです。品質なんて求めていませんでした。
が、しかし、それからプロダクトコードを書くようになり、テストが必須になりました。なぜテストが必須なのか？それは、そのプロダクトがお客様のビジネスに影響するものだったからです。問題があったらお客様が困ります。それが2009年です。
その時に初めて気がついたことがあります。
「お客様によって品質の定義が変わる」
ということです。今思えば当たり前の話ですが、当時の自分にとっては大きな気づきでした。
テストの目的って何だ
既にテストの分類については、多くのかたがエントリーされていますね。特に、元同僚の@ikasam_aのこちらのエントリーは凄く良いエントリーですので、是非皆様も読んでいただきたいと思います。（タイトルもパクらせていただきましたw）
皆様は何の目的でテストをしていますか？
テストという大きなカテゴリで議論をすると人によっては衝突してしまうことがよくあります。それは開発者テストの話なの？QAテストの話なの？まぁそんな感じです。
けど私は、テストの目的だけはもしかして同じなのでは？と思っています。
その目的とは、
「お客様に自信を持ってリリースすること」
です。
例えば、開発者テストは開発者が開発を円滑にするためのテストとよく言われますが、それは目先の目的であって新の目的は違うのかなと思います。もしも本当に「リリースすること」とは全く関係のないテストコードなのであれば、それは不要なテストであると考えています（言い過ぎかなw）。いくら、小さなメソッドの単体テストであろうともそれはリリースするためにやっているはずです。
リリースに関係のないコード（例えば、前述したような「スパイク」で開発したコード）に、テストは必要ないと思います。もしもこのようなケースでもテストをするのであれば、これこそ開発者のためのテストではないでしょうか。
だから私は、テスト設計を行うときにはお客様の事を一番に考えています。まずお客様とは、誰なのかはしっかりと決めることは原則です。それはエンドユーザなのかもしれないし、開発者なのかもしれません。
それを踏まえて、こういうことをお客様がやったらどうなるか、こういうときに問題はおきないのか徹底的に考えます。それが単体テストであろうが結合テストであろうが全てのテストに共通しています。
それを具体的なテストケースにして全てが通ったプロダクトには自信を持てると思います。お客様がどのように使っても問題なく動く！！そういう自信です。
そういう自信をもってリリースするために私たちはテストをするべきだと思います。
品質って何だ
皆様の品質の定義とは何でしょうか。どういうソフトウェアが品質が高いといえるのでしょうか。
バグが0件だ。カバレッジが100%だ。障害発生率がx%以下だ。。。
本当にこういう条件を満たしたら品質が高いのでしょうか。
残念なことに、私の身近でもこのような話を聞くことがあります。そして、それをリリースの完了基準にすることがあります。本当に残念です。
そんな完了基準になったらもう最悪です。開発メンバーがバグを0件にすることが目標になり目的になり、気がつくと本質的なことを見失ってしまいます。
バグは0件になったけど、うちらって何のために開発してたんだっけ？まぁそんな感じです。
また、品質保証（監査）部門がいる会社は、品質の解析に時間をかけ、解析レポートを要求され、本質的である品質を上げる時間を奪うことが多いように感じます。
お客様は品質の解析レポートなんて求めていません。
お客様がそのプロダクトを利用して、
「ビジネス価値を上げられるのか」
それだけだと思います。
例が悪いかもしれませんが、私は昨日のB'zのライブに行ってとても満足しました。音と映像のタイミング等、何度もテストして品質をあげていったことでしょう。
私はそのライブに17000円(8500円×2枚)を払いました。私にとってそれだけの価値があるからです。
「品質を決めるのはお客様」
なんです。
いくら、開発者が完璧なコードを書こうが、品質保証部門がテストをしようが、お客様が品質が悪いと思えば悪いのです。バグがあってもお客様がそのプロダクトでビジネス価値をあげられれば品質が高いと言えるでしょう。
プロダクトによってお客様も品質基準も変わってきます。そのプロダクトのDoneの定義を決めることが重要です。そうでなければ、過小品質や過剰品質を生むことになると思います。
小さく、早く、そして簡単に
さて、ここまでテストと品質について書いてきましたが、皆様これで品質が高いソフトウェアをリリースできるでしょうか。
う〜〜〜ん。。。難しいですよね。
こうやれば、間違いなく品質が高いソフトウェアをリリースできます、なんてそんな魔法みたいな方法なんてないのです。
ただ、私が最近特に意識していることがあります。
それは、
「小さく、早く、簡単にリリースする」
ということです。
小さく
これは、リリースする単位をできるだけ小さくするということです。
例えば、Webアプリケーションがリリース対象だとすると、提供する機能に優先度をつけて、全て完成してからリリースするのではなく、優先度順に最小単位でリリースするということです。もしも10の機能をリリースするときに、1週間毎に細かくリリースする場合と、2ヶ月に1度リリースする場合どちらがいいでしょうか。
もしもリリースが1度だけなのであれば、お客様がビジネス価値を上げられない可能性が高まります。私も経験があるのですが、お客様にリリースしたときにすぐにクレームになったり、そんな機能いらないからこの機能が欲しい、みたいなことがありました。
やっぱり人間なので、使ってみると想像と違っていたり欲がでることは当然だと思います。
もしも1週間毎にリリースされたものを利用していたとしたら、いきなり10の機能の評価でなく、1つの機能の評価になります。そうすると、クレームが小さい意見となり、開発予定だった機能が不要になりお客様にとって重要な機能の開発が増えるかもしれません。
それは、お客様から
「継続的なフィードバックを得ている」
からということになります。
継続的なフィードバックは、品質を高める手法です。前述した通りですが、いくら開発者が良いと思っていてもお客様の意見が品質に直結します。
もしも、お客様との間にフィードバックループを作れないのであれば、仮想的なお客様でもいいので利用してもらうことが重要です。
小さくリリースするためにリリース計画をするのも一つの技術であると私は考えています。
早く
これは、リリースを極限まで早くするということです。
早くできない理由は、前述したリリース単位が大きいのも1つでしょう。その他にもいくつかあると思いますが、手動テストが多いとリリースは遅くなります。
私の経験談ですが、QAテストのために派遣を雇い、膨大なテスト仕様書を書き、それを全て手動でテストをしていた時期がありました。テストを全て行うのに1ヶ月もかかりました。もちろん1回でテストが終わるはずもなく、テストが終わるまでに3ヶ月を要しました。
開発が完了してからQAテストをするという完全なWFってやつですw
その時の1番のミスは、膨大な手動テスト仕様を量産してしまったことです。その時は、後にこれが多大な負債になるとは考えていませんでした。それからというものこの手動テスト仕様は、類似製品にも利用されるようになり、ベースとなる仕様として位置づけられたのです。
このままでは、リリースが遅くなる一方です。そこで、私は徹底的な自動化への移行を推進しました。その仕様の約70%を自動化しました。この自動化への移行の作業の大変さは想像を絶していました。初期の開発中に自動化への努力を行なっていれば、このような苦労は少なかったと思います。
リリースを早くするには、開発の初期段階からテストの自動化環境を整え、手動テストはなくす努力をすることです。プロダクトの性質によっては完全に自動化することは難しいものもあります。これは逆転の発想で、設計時に自動テストができるように設計しておくことが重要です。もちろん理想論ですが。
簡単に
これは、「早く」と類似しているのですが、本番環境にリリースするまでに簡単に実現できていることです。
それは、テストだけでなく、ビルドとテストとデプロイを完全自動化することが最善の策です。要するにデプロイ・パイプラインを作り、ワンクリックでリリース可能な状態にするということです。
この辺の話は@ryuzeeさんの資料が素晴らしいので読んでみることをお勧めします。
私が取り組んでいるデプロイ・パイプラインは、テスト環境構築→モジュール単体テスト→モジュール結合テスト→ステージング環境にデプロイ→リリーステスト ってな具合です。
ここまで自動が進むと人的ミスがほとんどなくなります。手動が入ると、デプロイ1つにしても間違ったモジュールをデプロイしてしまった、なんてことは日常茶飯事です。そういう時間って無駄の何ものでも無いんですよね。そして、それが手動だとある特定の人しかできないということが多いです。その人に負担がかかってしまい、本当に良くない状態と言えるでしょう。
後回しにしがちなデプロイ・パイプラインは早期に実現しておくことがいいと思います。これは開発者にとってもお客様にとっても重要なことだと言えます。
終わりに
今回は、ソフトウェアテストと品質について、わたしの考えを経験談を踏まえてエントリーさせていただきました。
この手の考え方に正解はないと思います。ただ、それを強い信念を持ち突き進められるか、関連するメンバーが全員納得して進められているのか、それが重要です。
例えば、私が今回エントリーした内容を全て実現できていたとしても、関連するメンバーがYESと言わなければ会社や組織としてうまく機能しないでしょう。それを根気よく周りに浸透させることがまずは必要だと思いますし、私もそのような努力をしています。
開発者もお客様もHappyになれる仕組み作りを皆で目指しましょう！！
