デブサミ2014に登壇するまでの軌跡【14-D-5】iOSアプリケーションの継続的デリバリー #devsumi

2014年2月13日、14日に開催されたDevelopers Summit 2014の2日目の14日(大雪の日)に
Developers Summit 2014:【14-D-5】iOSアプリケーションの継続的デリバリー ~エンタープライズ品質のiOSアプリケーションを目指して~というタイトルでお話させていただきました。大雪の中、大変多くの方にご来場頂き、感謝の気持ちでいっぱいです。

当日の資料はこちらです。

当日の僕はこちらですw


Developers Summit 2013

実は昨年も
【14-E-7】[TED] Technology Enterprise Development:Developers Summit 2013に登壇しました。ありがたいことに二年連続の出場になりました。
昨年の登壇記録はこちらですね。Developers Summit 2013に登壇しました。Ricoh UCS for iPad でみる エンタープライズ アジャイル開発 - numeha's blog

昨年の反省

昨年は外のConferenceで話すのがこれが初めてで、自分のことだけでいっぱいいっぱいでした。とにかく、自分の出せる力を出して、自分の世界が変わればいいな、くらいにしか思うことができていなかったと思います。
そのことは、改めて過去のブログを読んでもそう思います。もの凄く反省しました。

デブサミの母こと
IWAKIRI,Akiko / 岩切晃子 (kohsei) on Twitterにも、はじめ公募したときに言われたことなのですが、

「受講者に対してへのお持ち帰りが弱いのではないか?」

でした。今でも忘れません。

まだまだ、来て頂く受講者のためにはなっていなかったと思いますし、何を自分は伝えたいのかということがぶれていたような気もしました。

今年にかけるオモイ

このような反省を踏まえて、Facebookにつぶやいたことがありました。

あと2週間後に迫った、Developers Summit 2014に登壇します。
昨年は、自分のことだけでいっぱいいっぱいでしたが、今年は来てくれる人に、少しでも、一枚のスライドでも、一言でも、何か響けばいいなぁと思いながら、今も準備しております。
全力で挑みます!!! by Naoki Umehara

とにかく、どこでもいいから少しでも受講者のActionに結びつけばいいなという思いで、スライドも一から見なおしました。また、練習もたくさんしました。(ぶっちゃけ45分のプレゼンの練習って難しい)

そして当日

デブサミって不思議なもので、緊張するというよりは、どちらかと言えば、「楽しみ」とか「ワクワク」とかそういう感情になるのですよね。なぜかはよくわかりません。

でしたが、さすがに直前は


こんなかんじになり、胃がキリキリしましたw

あの大雪だったので、受講者の数は少ないかなと思っていましたが、壇上にたったときに見た景色は、ほぼ満席の会場でした。
ビックリというか、とにかく感謝、感謝、感謝でした。

そして、発表が終わって、Ask the speakerルームに移動中に、誘導してくれたタイムキーパーさんから
「聞き入ってしまって、残り時間を出すのをためらいましたーw」なんて、お世辞かもしれませんが、言っていただき嬉しかったです。

Ask the speakerにて

正直、誰も来なかったらどうしようと思っていたのですが、たくさんのかたに来ていただきました。
そこで、
「サプライズでした!」
「感動しました!」
「ヤバかったです。持ち帰って実践します」
「モチベーションあがりました」等等、
たくさんの嬉しい言葉や、具体的な質問も多数頂ました。
昨年の反省が実ったのか実際はわかりませんが、こういう形で受講者から生の声が聞けただけで、やってよかったなぁと思いました。

また、嬉しいBlog記事も目にしました。ありがとうございます。


来年に向けて

さて、来年の目標は何にしようかなと思って、なにかつぶやこうとして未だ躊躇っています。
漠然と思っていることとしては、もっと人に役立つような活動って出来ると思っていて、それが何かはまだよくわかりませんが、
あまのりょー (beakmark) on Twitterからうちで再演して!と言われたので、そこからですかねwww 
とにかく、少しでも世の中に貢献できる人間に成長したいと思っています。

番外編

思いつくままにリスト化していきます

  • 元同僚のMasaki Nakagawa (ikasam_a) on Twitterさんと一緒の舞台に立てて、実はむっちゃ嬉しかったです。厳しいご意見もいただきありがとうございますw
  • 私のセッションの裏で話していた中村 薫 (kaorun55) on Twitterさんが、高校時代の野球部の後輩(私が3年のときの1年)ということを、前日のアンオフィシャルパーティーで本人から言われて、言われても「マジ?」って感じで覚えていなくてマジですいませんでしたw
  • 角征典 KADO Masanori (kdmsnr) on Twitterさんのセッションで僕のプロジェクトの原則の引用と、さらに僕のセッションの告知までしていただき恐縮でした。今後ともよろしくお願いします
  • 拍手で壇上に上がったのは初めてでしたw あれってムッチャ気持ちぃです
  • 開発メンバーもきてくれたのですが、「私達の活動を話してくれてありがとうございました」と言われて、その日はたくさん飲みましたw
  • 昨年は結構ボッチだったのですが、今年は知り合いも増えて話す人がいて、人脈が少し広がったことを感じました。が、控室にmiyagawa-sanが居たのに話かけなかった自分が情けなかったですw オ、オーラが凄くてw
  • 発表がおわって備え付きのケーブルまで持って返ってきてしまったすいませんでした。その後、返しましたから大丈夫だったはずですが。。。
  • 発表中にカメラマンさんが写真を撮りにくるのですが、全然シャッターを押してくれなくて、自分のポーズが悪いのか何なのかよくわからず意識してしまっていたら、よくわからないことを話していた気がします。ごめんなさいw けど、いい写真をありがとうございますw

2014/2/14にデブサミ2014でiOSアプリの継続的デリバリーの話をします #devsumi

お久しぶりです。こんばんわ。@numehaです
いよいよ、明日からDevelopers Summit 2014が始まりますね。

私も2/14の15:15〜16:00で話します。
Developers Summit 2014:【14-D-5】iOSアプリケーションの継続的デリバリー ~エンタープライズ品質のiOSアプリケーションを目指して~

まだこんな感じですが、当日は皆さんの期待に答えられるように「熱く!」語りたいと思っています。

さて、宣伝もかねて表紙だけ公開。

f:id:numeha:20140212205646p:plain

特にiOSの開発やっている人、自動化に興味が有る人、テストに興味がある人には必見ですが、ソフト開発のプロセスの話やチーム形成の話も盛り込んでいますので、ソフト開発をやっている人であればだれでもどこかに刺さる内容になっております。

事前登録していない方でも、事前登録した人が入った後であれば入れる(らしい)ので、是非是非、お立ち寄りくださいませ。

それでは、当日お会いしましょう。

iOS Enterprise & Developers Conference 2013に登壇しました。iOSアプリケーションの継続的デリバリー

2013年11月7日に産業技術大学院大学で開催された、iOS Enterprise & Developers Conference 2013に登壇しました。
その際の資料を公開します。

私のセッションは、B20 「 iOSアプリケーションの継続的デリバリー 〜エンタープライズ品質のiOSアプリケーションを目指して〜」でした。

今回は、弊社の公式Facebookの投稿をしたり、当日に開発している製品のパンフレットを配布したり、何より今回の話を持ってきていただいた、@osamunmunに感謝します。

さて、当日はこんな感じでした。
f:id:numeha:20131107150046j:plain
f:id:numeha:20131107150107j:plain
f:id:numeha:20131112192911j:plain
f:id:numeha:20131107145416j:plain
f:id:numeha:20131107145555j:plain

3,40名のかたに話を聞きに来ていただいて大変嬉しく思っております。そして、その後連絡をいただいた皆様ありがとうございます。

やはり外部でTalkをすると何かいつもとは違う感情をいだくというか、達成感があるというかよくわからない気持ちになります。多分いいことだと思うんだw

何か、これからもお役にたてるように発信していきたいと思っております。

せっかくなので、このネタを元に他のConferenceでもTalkできればいいなと考えています。さて、次はどこかなぁw

Developers Summit 2013に登壇しました。Ricoh UCS for iPad でみる エンタープライズ アジャイル開発

2013年2月14日のバレンタインデーに目黒雅叙園で行われたDevelopers Summit 2013で登壇しました。
その際の資料を公開します。

私のセッションは【14-E-7】[TED] Technology Enterprise Development で、エンタープライズの世界で頑張っている6名の登壇者が約15分間ずつ順番に発表する形式でした。

自分は今年から始まった公募枠に応募してこのセッションに入れて頂きました。岩切さん(@kohsei)!本当にありがとうございました。

このような大きな舞台で、いや小さな舞台でも社内以外で発表したことはありませんでした。
けど、今回のデブサミのキーワードでもある「Action」って本当に重要なことで、何か自分でやらないと何も変わらないんですよね。自分の活動を外に発信しない限り、自分は何も変わらないしダメになると思い、並々ならぬ思いで今回は発表させていただきました。
今回思い切って発表して自分の殻が破れたというか、なんだか清々しい気分です。これからもドンドン外に発信して、プレゼンスを上げていきたいと思います。

さて、自分の発表では「エンタープライズ・アジャイル開発」をキーワードに話をさせて頂きました。
今回のデブサミでの皆様の発表を聞いていても思ったのですが、エンタープライズだからとか、ソーシャルだからとか、スタートアップだからとかほとんど境界線って無いですよね。
何でもそうですけど、

個人やチームが行動を変えて改善できるか

に尽きると思います。
自分の例では、会社の染み付いた常識化を打ち破るためには...自分がまず正しいと思うやり方でやってみる!という話でした。

何かを変えたいと思ったときって、自分がそれを実践する時なんですよね。誰も自分が思ったことはわからないし、自分が正しいと思ったやり方でやってみて成果を出すしかないんです。そのやり方が正しかったら周りは絶対ついてくるし、個人がチームへ、チームからまた他のチームへ広がるはずです。

エンタープライズの世界でアジャイルをやるのであれば、このようにトップダウンではなくでボトムアップでやるしかないと思います。
プロジェクトは同じものは無いし、そのプロジェクトやメンバーによってやり方って異なるし、それを一言でアジャイル開発でやれ!とトップダウンでできるとは思えません。ましてや、それを標準プロセス化とか無理w
自分たちが考えていいと思ったことをやれるチームが沢山広がることが重要なんです。


今回は、自分がおかしいと思ったことの改善を一つ説明させて頂きました。 (残りの4つはまたどこかでw)

ATDD (Acceptance Test Driven Development)

です。

テストって何が一番重要なのかというと、自分達はお客さんの価値をちゃんと提供できているのか、できていないのかがわかるテストだと思います。それがAcceptance Test。受け入れテストです。
いくらTDDで内部構造が素晴らしいものでもそれがお客さんのところに価値をちゃんと届けられているかはわかりません。(もちろん必要ではないという意味ではありません)
ましてや、Acceptance Testをプロジェクトの後半でやってプロジェクトが炎上するとか考えれません。

お客さん使う運用環境
価値を提供できているのかを確認する受け入れテスト
どれだけ早く実行できるかが勝負の分かれ道

なんです。
このようなテストをプロジェクトのはじめから実行できていればプロジェクトは必ずスムーズにうまくいくとチームメンバーが全員確信しました。肌で感じ取ることが重要なんです。

これはあくまで一つのプラクティスなので、もしかしたら同じ事を別のプロジェクトでやっても失敗するかもしれません。そのときは冒頭でもいったように、個人やチームが行動を変えて改善できるかが重要です。
プラクティスはあくまでプラクティスなので、自分たちがいいと考えるやり方でアジャイルな開発ができて、広がることを自分は願っています。

デブサミ万歳!!

リーンカンファレンス2013に行ってきた

リーンカンファレンス2013~ヒット商品を作る仮説検証型開発プロセスとスキル~に行って来ました。
自分の中でのリーンといえば、




くらいなもんです。実際に本を読むだけではダメで、生の声を聞いて少しでも自分の仕事に役に立てばという思いで参加させて頂きました。気になったところだけ箇条書きにしてみます。
資料はまだWebにUPされていないようですが、UPされ次第更新します。


アジャイルからリーンへ、そしてリーンスタートアップ
平鍋健児さん @hiranabe

  • 英和さんでもまだ50%はWF。アジャイルは契約がかなり問題。作ったのに使われないのも問題
  • アジャイルはホールケーキを作るのではなくショートケーキを作れといっているようなもの。過去十年間でようやくできるようになってきた
  • ソフトウェアは目に見えないからKanbanは有効。みんなの成果物はHDDにあるのはダメ
  • The new new product development game
  • なんでこの製品を作るのか、企画の人は最後までみろ。どこから要求がきてどこに提供するのか
  • 顧客開発:お客さんにわかってもらえる機能をどうやって作るのか→スタートアップの手法
  • アジャイル開発とスクラム」本買ってね


リーンが製品開発を改革する
稲垣公夫さん

  • リーンという言葉は1990年から始まった。生産から始まって今はソフトウェア業界まで広がった
  • 日本の製造業はダントツ商品を作らないと生き残れない
  • リーンはイノベーション。無駄取りじゃない
  • 顧客価値を理解していないと全部入りの製品になる。お客さんに聞いても出てくるものではない
  • 顧客価値を深く理解する->脱思い込み思考->仮説を立てて検証する
  • セットベース開発(構想を開発する)。代替案をたくさん出す->トレードオフ曲線。設計空間をせまい領域にしていく
  • 製品開発の最大の無駄は獲得した知識を捨てることだ
  • 製品バリューストリームはチーフエンジニアの役割
  • リーン製品開発でダントツクラブを開発したピンの話->ドライバの調整機能開発していたが、マーケティングギミックになっていた->くだらない機能は付けるな。どうせ使われない->3,4年でトレードオフ曲線ができていた。そのデータからまっすぐ遠くに飛ぶドライバを作った->一回目の試作で目標飛距離達成
  • ダントツ商品を確実に開発する鍵は顧客価値知識と技術知識



TOCを活用したヒット商品開発プロセス
西原隆さん (CCPMの人。お世話になっております。)

  • TOCとリーンの話
  • 売れない商品をCCPMやってもしょうがない
  • 良い製品だけど売りにくい。ほとんどの新製品は消滅していく。事業部で開発して売ろうとしたけど売れない。それをどうするか
  • 営業マンが提案営業できるか。お客さんは強い疑いを持っている。買う気がある態度は見せない。あの機能あるのないのいわれる->営業は開発部門にこの機能がないと言う (Mr.カタログマン)
  • 売り方を開発する。断れないほど魅力的な提案=マフィアオファー

参考

  • BufferManagementにイイネしてね->しました
  • 営業と開発の間に溝がある。ちゃんと提案できていない。組織に問題がある。

バリューストリームがビジネスアジリティを加速する ~リーンアジャイルの海外事例~
市谷聡啓さん @papanda


  • 海外のLean Agileを学ぶ
  • 企画が開発に渡ったら後はお任せが多い
  • そのビジネスには何があればいいのか、それをどのようにデリバリーするのか
  • ストリームの中でどのActionにどれくらいの時間がかかっているのか。何が流れを滞らせルモノは何か
  • ビジネスプロデューサーとシステムのプロデューサーが共通の目標に向かっていくためには現場に仕組みが必要。その一つがKanban。皆が一つのKanbanを共有しよう
  • 参考:http://www.manaslink.com/articles/4535
  • Value Streamとはマップには価値がなくてそこから自分たちが何をしなくてはいけないのかが重要



リーン開発時代に求められるスキルとキャリア
渡辺のぼるさん @noboru2000gt

休憩中ですいません。(略)

アイデアを事業に進化させる企業のサイエンス〈リーンスタートアップ
和波俊久さん

  • ベンチャーがLeanをやり始めた。彼らはLeanを覚えつつある。大企業ヤバい。今すぐやらないと
  • 名言:リーンやらないと死ぬよ
  • 有名になるとあか抜けてくるw 写真が白黒になるとかw
  • 事業計画書を書きなさいから始まるのが典型的->それを逆にしないとダメ
  • アイデアからどうやって製品かするのではなく、アイデアから何を学ぶのかを考える。これも逆
  • 技術サイドから試すときもあれば、ユーザサイドから試してみることもある。自分たちは何を試したいのか、フィードバックループを通して何を得たいのかそこを明確にする。
  • イノベーションの正体は積み重ね
  • Motivationがなくなったら何もやらなくなる。
  • ★過去の成功パターンー>プロセス化ー>常識化 <-これが一番リスクが高い
  • 脱皮しない蛇は死ぬ
  • ゲームチェンジャーの出現兆候:携帯->スマホ市場 自動車->EV
  • カテゴリ名がかわるときは破壊的イノベーションが起きている
  • 時間をかけて失敗したのか、大きくだして失敗したのか。この時間と大きさの軸を小さく短期に
  • ポイントは4つ : 小さく、繰り返す、仮説から、常識を変える
    • 仮説から:ガントチャート、TODOリストはクソ
    • 常識を変える:ものさしを作る

懇親会
色々なかたとお話できてとても有意義でした。名刺交換させていただいた方ありがとうございます。
質疑応答も面白かったです。


(和波さんとのトークより)
トップダウンで浸透させるには、経団連の◯◯さん経由でうちの社長に
「リーンやってる?」
くらいじゃなきゃ浸透しない
ですってw

DevOps時代におけるクオリティ・エンジニアの重要性 (後編)

DevOps時代におけるクオリティ・エンジニアの重要性 (前編)からの続きになります。
どうも。@numehaです。
後編はクオリティ・エンジニアが取り組む事例をご紹介していきましょう。

継続的デリバリーからみる課題

f:id:numeha:20120823214537j:plain

お客様に継続的にビジネス価値をお届けするために私たちはサイクルタイムを減らす方法をひたすら考え、改善し続けなければなりません。一方で、サイクルタイムを減らすだけでなく、他にも考えなくてはならないこともあります。

それは、

システムを修正しながら品質を適切に維持していくこと

です。

極端な例ではありますが、リリースまでに全てが完璧に自動化されたとしても問題を発見できない仕組みであれば全く意味がありません。
ソースコードを修正するもしくは運用環境の設定を変更したことで何か問題が発生した場合、私たちはいつその問題をどうやって発見できるのかが重要なんです。

そんなわけで、私達クオリティ・エンジニアがDeveloperやOperatorをサポートする3つのことを紹介していきましょう。

クオリティ・エンジニアが取り組む3つの事例

私たちは主に以下の3つのことについて取り組んでいます。

  1. リリース基準を規定する
  2. システムのキャパシティを測定する
  3. 環境をテストして監視する

詳細は以下に記載しますが、前提条件として変更に強いテストでなくてはなりません。内部設計に依存したテストであれば、DeveloperとOperatorとかなり密になって活動しない限り追従することが非常に困難になります。

f:id:numeha:20120823215445j:plain

ですので、私たちは品質の外側である外部品質向上に努めることが最善の策であると考えています。内部品質は全てDeveloperとOperatorにお任せということではありません。一番外側の品質を押さえない限り内部品質の強化をしても効率が悪いという意味です。
DeveloperやOperatorが品質確保に向けて行なっていることがより細かいレベルでできるように。そんなことを期待しながら活動しております。

1. リリース基準を規定する

リリースする基準となるテスト仕様を策定し、お客様に提供するビジネス価値を明確にすることがまずは必要です。言ってみれば、これがシステムの仕様になりえるのです。フィーチャー開発をしている人であれば、一つのフィーチャーに複数の受け入れ基準を設けることは実践していることでしょう。
私たちはこのテストをリリーステストと呼んでいます。受け入れテストと同義です。
特徴的なこととしては以下の2つです。
f:id:numeha:20120823221418j:plain
一つ目はとにかくシステムが運用される本番環境と同等の環境でテストをすることです。
ユニットテストであればむしろ逆で環境に依存しないテストコードでなくてはならないと思いますが、リリーステストは違います。お客様が利用するであろう環境で継続的にテストをすることで、Developerを安心させ自信を持ってもらうことができます。
また、本番環境と同等の環境で継続的にテストをするということはデプロイも継続的にされるということです。例えば、開発した内容が運用環境に影響するような修正だとしたら、自動デプロイスクリプトを変更することになることでしょう。こういうときこそDeveloperとOperatorと連携することで、実際に本番環境にデプロイするときのミスや漏れがなくなるはずです。

f:id:numeha:20120823221425j:plain
二つ目はリリーステストファーストです。
前編でも少し触れましたが、開発当初からこれから開発するものがビジネス(お客様)視点でどういうものになるのかを意識合わせすることが重要です。すでに出来上がったものに対してテストをするのではなく、これから作るものに対してテストを一緒に作成するのです。
テストと開発は同時進行し、開発途中でも上述した本番環境と同等の環境でテストを行い、途中経過を全てのメンバーが把握することができます。
クオリティ・エンジニアはDeveloperが開発しやすい環境を整備し、自信がもてるテストコードを書き、Operatorが安心して運用できる仕組みや、デプロイテスト等を継続的に行うことでサポートできるのです。

2. キャパシティを把握する

キャパシティは定義するのが難しい非機能要件と言われるものです。
なぜ難しいかというと、実際にお客さんがいない状態でどのくらいのユーザに利用されるかもわからないのに「100万ユーザ分処理できること」みたいな適当な非機能要件を定義しても意味がないからです。実際に私達も非機能要件はありません。
一般的に機能要件が重視され非機能要件は軽視される傾向にあると思います。
とはいえ、自分たちが開発しているキャパシティを何も把握していないのは健全な状態ではありません。
ですので、まずは計測して自分たちのシステムの特性を把握しましょうというのが一番の目的です。
私たちは、Jenkinsのダッシュボードから簡単に提供しているサービスのキャパシティを把握することができるようにしています。
具体的にはPlot Pluginを利用しています。

f:id:numeha:20120827141508j:plain

こちらもリリーステストと同様に本番環境と同等の環境で継続的にテストを行なっています。継続的に行う理由は、サービスの変更や環境の変更によるキャパシティの変化の傾向を把握するためです。
ですので、今の実力値を把握することができます。あとはここから具体的な非機能要件に落としこんでいくのもよし、あえて非機能要件に落とし込まず、想定外であるシステム特性について優先順位をつけて対応してもよし、ですね。

リリーステストもそうなのですが、このテストで全てがわかるわけではありません。あくまでお客さんが利用する一番外側の品質を向上させるために行なっています。例えば、キャパシティテストの例で言えば、ここで測定された結果はサービスに依存するものなのか環境に依存するものなのかこれだけでは把握することができません。ただし、このテストだけで十分なこともあるしもっと細かくテストをしないといけないものもあるでしょう。

私の考えとしては、細かくキャパシティテストをする戦略をとるよりは大雑把な現状値を把握し、Developerはサービスの改善の準備を行い、Operatorは環境設定の最適化の準備やサーバ増設などの計画値として利用する。それくらいがいいのではないでしょうか。

3. 環境をテストして監視する

さて、上述してきたような継続的なテストとはシステムの監視をしていることと同じです。
f:id:numeha:20120825235150j:plain

私たちはリリース前に行ったテストをオールグリーンにすることだけで果たして十分なのでしょうか。
運用している中で問題が起きることがありますよね。原因は様々かもしれませんが、その異常な状態のときにオールグリーンであったテストを通そうとしてもレッドになるはずです。
ということは、リリース後の運用している状態のときでも継続的にテストをしてシステムを監視してはじめてシステムの品質が保たれるってもんです。

監視というと、データベース、CPU、HDD、メモリ、ネットワークトラフィック、などなど様々なことをやらなくてはいけないと思います。
ただ、監視したものが実際にお客様に影響をおよぼすものなのかそうでないのかを瞬時に把握することは難しいです。

というわけで、これもまた一番外側からの監視になるのですが、上述したリリーステスト、キャパシティテストを本番環境で実行することでお客様に影響を及ぼしているのかそうでないのかを切り分けることができます。

ただ、このようなテストは時間がかかることがあります。監視目的のテストに数時間もかかっては全く意味がありません。
私たちはお客様に提供しているシステムが正常に動作しているのかを少なくとも数分で検知できるように最適化をしてテストを行なっています。このテストを継続的に行うことでお客様に影響を及ぼしている状態なのか安定しているのかを監視することができるのです。

非常に単純な仕組みですが、意外とこれが役に立ちます。お客様が利用する動作を継続的にやっていることになりますから確実性がありますし、複数の動作環境がある場合でも瞬時にサービス群が適切に動いていることを確認することが可能です。

まとめ

前編、後編とまとまりのない文書でしたが、最後まで読んでいただきありがとうございました。
本文の中で、「協力」「連携」と記載することが多かったですが、簡単なようで非常に難しいことです。自分のことだけやるのは簡単です。相手のことを考えて行動するのは一人一人の意識だけでなく、リーダーやマネジャーの理解も必要になります。組織としてどのように行動すれば最適化させることができるのかを皆で議論していくのが良いと思っています。

「個人ではなくチームとして活動する」

自分が最近とても意識していることです。
皆さんのこれからの活動のちょっとした参考になることを祈って。また半年後にw

参考

DevOps時代におけるクオリティ・エンジニアの重要性 (前編)

はじめに

お久しぶりです。@numehaです。前回の投稿から約半年間が経過しました。AKB48のあっちゃんさよならライブ生中継を見ながら書いております。
「DevOps時代」なんて目を引くタイトルにしてみたものの、ただの思いつきの投稿です。はい。
とあるメーカで働いている私の体験談や思いを一部フィクションを交えてお届けしたいと思います。何かフィードバックいただけるとこれからの活動の参考になります。よろしくお願いします。

DevOpsって

DevOpsはムーブメントだ!なんて言われていますね。このスライドの説明が一番わかりやすいですね。

そうそう。わかるわかる。。。。
ん。いや、ちょっと待てよ。私は未熟者なのでまだピンときていないのですが、何か違和感がありますね。

開発と運用の垣根がなくなるのだけど責任は異なるの?お互いのことをわかった上で取り組もうということなのだろうけど、そもそもこれ系の話は開発と運用だけに限った話ではないですよね。多少の壁がありながらもうまくお互いのことを理解するのはある意味当たり前の話でみんな苦しんでいる話だと思います。

f:id:numeha:20120823143512j:plain

歩み寄りもしないで一方的に否定から入るなんてもってのほかですね。

そんなこんなで最近もやもや考えながら日々仕事をしているわけですが、自分の中の勝手な定義としては、

何事もDevOpsな態度で取り組め!

これならピンとくるんだな。
相手を責めない、押しつけない、信頼しあう。相手がいてこその自分なのだから。

クオリティ・エンジニアって

一般的にはテスト・エンジニア?ということが多いのでしょうか。呼び方はどうでもよいのですが、あるソフトウェアの品質を最優先に考えて行動しているエンジニアのことです。
そんなのDeveloperであれば品質のこと考えてやってるよ、という声が聞こえてきそうですね。


「最優先に考える」

というところが重要だと私は考えています。


Developerであったら、何かを設計する、開発するということに注力することでしょう。今であればテストが重要だというDeveloperは多いと思いますが、「品質を最優先に考える」ことはかなり難しいでしょう。
また、運用のことも理解して開発をすることが求められていますが、それは意識だけではどうにもならない能力を要することだと思います。
(最優先に考えなくてもソフトウェア開発に重要なことを全て均等に完璧に考えられるスーパーマンだらけの組織は除きますがねw)

というわけで、

f:id:numeha:20120823144853j:plain

クオリティ・エンジニアはDeveloper、Operatorと協力して、品質の高いソフトウェアをリリースしてお客様にビジネス価値を届ける。それぞれが注力して取り組んでいるところの穴を埋めるような、そんな役割として活動するメンバーが重要だと感じています。
DevOpsの議論では、品質関係の話が軽薄な印象を受けます。品質の話は、開発と運用と同等またはそれ以上に難しいことだと私は思います。

だって人間だもの

話がそれますが、なんでクオリティ・エンジニアの役割が必要かと思った理由について少し。
私は長い間Developerとして活動してきましたが、いくら自分がたくさんのテストコードを書いても、いけてる設計だと思っても、たくさんのレビューをしても、思わぬバグを踏むことがあります。

そしてそのバグはリリース直前やリリース後に運用してみて発見されることもありました。
Developerにとってこんな悔しいことはありません。そのときは、なんで事前に発見できなかったのか、自分を責めて責めて枕を濡らした日もありました(言い過ぎましたw)。

そこで発見されるバグは例えば単純なマージミスのときもあるし、テストコードの漏れ、運用環境でしか発見されない問題もあり様々です。
また、ソフトウェア自体ではなくそれをデプロイした実行環境の設定ミスにより思わぬトラブルを踏むこともあります。
OperatorもDeveloperと同じことです。人間なのだからミスだって検討不足のことだってあるんです。

そんなこんなで、開発を最優先に考えるDeveloperと、品質・テストを最優先に考えるクオリティ・エンジニア、安定運用を最優先に考えるOperatorを定義して、お互いが協力して活動すればうまくいくのではないかと思ったのがきっかけです。
協力するということが重要で、お互いが相手のことを考えて行動しなくては意味がありません。

クオリティ・エンジニアは、とにかくビジネス(お客様)視点で、リリースするシステムの品質を向上させることが一番の仕事です。Developerの設計指針や仕様に関して検討段階から参加し、意識を合わせる必要があります。Operatorが運用する環境を理解してテストを実行する必要もあります。
こうすることにより、従来からあるすでに出来上がったもののバグ出しテストにはならず、戦略的に早期にテストを行うことができるようになります。
早期にクオリティ・エンジニアとテスト戦略について議論を重ねることで、バグをなるべく作りこまない開発を意識的に行うことができるようになります。

後編では、そんなクオリティ・エンジニアが取り組むいくつかの事例を紹介したいと思います。