読者です 読者をやめる 読者になる 読者になる

CROSS2015のメモ

CROSS2015に参加してきたので、メモを残しておきます。

参加プログラム

概要

一度きりのシステムのテスト対策
  • パネラー
    • セッションオーナー: 和田 卓人 / タワーズ・クエスト株式会社取締役社長
    • スピーカー: 鳥居 剛司 / 株式会社バスキュール
    • スピーカー: 成田 伸一郎 / JAXA (宇宙航空研究開発機構)
  • 概要:スペースシャトルの打ち上げやテレビ連動システムのように一度きりしか本番が行えず・完璧なシミュレーションもできないシステムで「成功させるために」どのように対応しているか、どのような苦労を払っているかの話
  • TV 連動プラットフォーム 「M.I.E.S」(鳥居)
    • TVで行われるクイズやアンケートをリアルタイムにTVコンテンツに反映させるプラットフォーム
    • アクセスが大量に発生しスパイクが発生する可能性がある。如何にディスポーザブルな設計にするかが重要
    • f:id:numeha:20150201102134j:plain

    • スパイクに関しては、失敗しないようにある程度視聴率等から見積もった上でテストをする
    • 負荷テスト・ツールは自作。50万人を超えたら参加できないようにする等のリスクヘッジも考慮している
    • その他の機能テストは一般的なモノ
    • f:id:numeha:20150201102140j:plain

    • テストの優先順位は、リスク表を作って判断する。問題が発生した時の被害、対処方法から費用対効果を出して、期間内でできることをやる。これを繰り返すことで知見が溜まっていく
  • はやぶさ 2 の機体制御 (成田)
    • 概要
    • f:id:numeha:20150201102145j:plain

    • 宇宙に飛ばすこと自体がテスト

    • 全てを事前にテストすることはできないし、飛ばさないとできないこともある。そういう状況なので予測や解析が重要。しかし、地上でできることは全てやる
    • 実環境でしかできないことは実績数で評価する。要するに枯れたものしか利用しないということ
    • 大きなミッションは2つ。宇宙と地球を往復することと、宇宙でサンプルを取ってくること。これを満たすためのテストは、レビューと技術的な要素から判断する
送りバントでもCTO
  • セッションオーナー: 園田 剛史 / ビズリーチ 執行役員 カンパニーCTO
  • 概要:そこそこエンジニアがコツコツ仕事をしたら気づいたらCTOに。5年の間に組織は350人に急成長し、現在は100名近い開発組織のCTOを務める。これからのマーケットがエンジニアに求めることや、市場価値の高いエンジニアになるコツ、ビズリーチのエンジニアリングについての話
    • ビズリーチの前の外資系の会社での話。本人はリストラされていないが、周りがリストラされた話

      • 事業はお金を稼がなきゃダメ
      • 戦力外、価値を出さないとクビ
      • 戦力外でなくてもクビになることもある
      • f:id:numeha:20150201102150j:plain

    • ビズリーチでは3番目の社員だったが、他の人達がモンスター級のエンジニア

    • 会社の成長やエンジニアの数によって求めることがかわっていく
      • 3~10人: 全員がフルスタックエンジニア
      • 10人〜30人: 全員が作ることには変わりないが、ステークホルダーが増えるので調整業やシステムの負荷に耐えられるものが求められる
      • 30人〜100人: フルスタックから役割分担にシフトする
      • 100人〜300人: エンジニアの評価基準が必要になる
    • ビズリーチでは、ITエンジニアは事業にコミットすることを求めていて、評価制度上もそれを加味したものとしている
      • 具体的にはエンジニアスキルとビジネススキルの2軸評価で、エンジニアスキルのみの評価を上げることはできず、両方あって評価が上がるという形を取っている
    • 周りがモンスター級で技術的な引き目を感じることもあったが、モノを作ることはできるという自信がついた。突き抜けられたからこそ、マネージメントに専念できる
    • スペシャリストでも生き残れるが、ほんの一握り
    • CTOの視点は経営視点、経営層とのつなぎ役、開発組織のマネジメント
    • 何を作るべきか、マーケティング視点のエンジニアを求めている
今こそ語るエンジニアの幸せな未来
  • パネラー
  • 概要:新しい技術が生まれては消えていく変化が非常に激しい世界で、常に新しい世界を切り拓いてきたエンジニアである登壇者達が、これからの世界でITエンジニアがいかにして成長していくべきか、これからどのようにしていけばよいか、これからはどんな幸せな未来が待っているのかについての話
    • 「働きやすさ」と「働きがい」
      • 「働きやすさ」は会社が提供するもの、「働きがい」は自分で見つけるもの
      • マネージャは「働きがい」を奪ってはいけない。それを考えられない人をマネージャーにしてはいけない
      • f:id:numeha:20150201102154j:plain

    • 今のスキルセットにない内容や、今後必要になりそうなスキルが身につくほうが当然やりがいはある
      • 好きにやらせてくれればいいかというとそういうわけでもない。社員としてはみ出される感じがあるし、やりがいにもならない。
    • 35年定年説について
      • 家族がいると腰が重くなる。給料よりはやりがいを選ぶ
      • Web企業は転職しやすい。プロ意識の高い業種は転職しやすいということ
      • 技術が社内限定的だと転職できなくなる。かわりに年収はだすという方針だが、リストラされることもある
      • 70歳でもコンパイラ書いている人もいる
      • 結論としては35才定年説は特にない
    • 転職するかしないかは置いておいたとしても、転職できる準備はしておいたほうがよい
WebエンジニアはIoTをどうあつかえば良いのか
  • パネラー
    • セッションオーナー: 岡島康憲 / 岩淵技術商事株式会社 / 株式会社ABBALab
    • スピーカー: 椎野 孝弘 / ヤフー株式会社
    • スピーカー: 高萩 昭範 / 株式会社Moff
  • 概要:Webエンジニアを中心にWebビジネスに関わる人間は「IoTサービス」「ハードウェア」の企画を求められる時期ではないか?または、そういった分野に興味を持ち始める時期ではないか?そこで、現在ハードウェアビジネスを通じて「IoT」や「ハードウェア」に触れている人間をパネラーとして招き「WebエンジニアはIoTをどうあつかえば良いのか」と題したディスカッションを行う
  • f:id:numeha:20150201102158j:plain

    • IoTは抽象的な言葉であり、具体的に細分化して議論が進んでいる
      • Connected Car
      • Connected Home
      • Connected Human
      • Wearable またはM2M
    • IoTのプラットフォームはすでに二極化されている
    • IoTの商品規格は2つの視点がある
      • 既存製品にアドオンで価値を出すか
      • ゼロから新規の製品を作るか
    • ハードは作る必要があるものは作る。それ以外はスマートフォンで代替でもよい。要は何を実現したいのかが重要
    • 現状はスマートフォンを介してデータを連携しているが、それを介さずに直接ハード同士が自律的に通信を行う世界がくる
    • ビジネスについて、儲ける方法はある
      • 例えばハード、アプリ、データで儲ける
      • バレーボールの選手のジャンプ練習管理デバイスを売るスタートアップがある。それ自体は無料だが、選手達のデータを管理するアプリは有料になる
      • ウェアラブルで健康状態を管理して、保険料と組み合わせたビジネスに展開するなどもある
      • ドライバーの特性や位置情報から高速の広告をリアルタイムで変更したりすることも考えられる
    • IoTの開発はWebの開発と変わらない。車のデータを扱うAPIもある

おまけ

デブサミ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

参考