特別セミナー「アジャイル品質とソフトウェアパターン」参加レポート

告知ページ

特別セミナー「アジャイル品質とソフトウェアパターン」 2月22日 | Reliable Software Engineering, Washizaki Laboratory

講演1：アジャイル開発へのソフトウェア工学的アプローチ：イテレーション期間と学習ワークショップ

スライド

アジャイル品質セミナー・アジャイル開発イテレーション・学習 from Hironori Washizaki

www.slideshare.net

経緯

• 水曜日に台湾でソフトウェアパターンの国際会議が開かれる
• 今週台湾に来るんだったら、日本にもお越しいただいてセミナーを開こう！（2週間前）
• 非常にHotな品質とアジャイル開発について学んでいく

はじめに

• アジャイル開発に関連する領域について取り組んでいるので、それについて紹介する

動機付け

• アジャイルは科学不足
  • 他のプロセスに比べて
• Cynefinフレームワークより
• 横軸…解放が既知かどうか
• 縦軸…問題が複雑か単純か
• 第1象限…グッドプラクティス
  • アジャイルのよくある導入場所
• 第2象限…突発・創発(Emergent)
  • 一番厄介
  • アジャイルの本来の場所
• 第3象限…新規（の研究）

• 第4象限…ベストプラクティス

  • アジャイルのよくある導入場所

• 本来扱うべきところと実際に扱う場所が異なっているのではないか

• プラクティスなものに対して科学的裏付けをして、境界条件や本来のアジャイル開発の場所に持っていくプラクティスを探ってみるべき

• まだそこまで出来ていないので、地道に行っていく

• 科学的に出来ないのか

  • イテレーション期間を長く取るべきか短く取るべきか
  • ワークショップが有用なのか

• イテレーション期間について必要ない部分をバッサリ切ってモデル化する

• 机上の（計算機上の）シミュレーションを行ってきた結果
• 要求の不確実性大→イテレーション期間を短めに
• 要求間の依存関係複雑さ→イテレーション期間を眺めに

講演2：ソフトウェア信頼性予測のプロジェクト進行中の動的な活用

ソフトウェア信頼性モデルとアクションを結びつける

• 信頼性モデルの利用

• 開発の最後、振り返りが主な利用シーン

• 状況のモニタリング

• CIツール

• R言語

• 異常の検知

• 信頼性モデルの解釈とアクション

欠陥と信頼性

• 欠陥数の予測について
• 信頼性に対して、欠陥を十分に発見できたかどうかを評価する基準
• 欠陥数を予測し、取り除くべき欠陥数を定める
• ソフトウェア信頼性モデル
• どれだけテストを行えばよいか、リリース時期を測ったりする

• 発見した欠陥を累積として日毎、週ごとに測定

• 開発における問題

• 欠陥を十分に発見できているか

• 予測される欠陥数に対して今どれだけ欠陥を見つけたか

• リリースに間に合うか判断できない

• 開発のスコープ決定を支援
• テスト工数、計画の支援

CIツールとリポジトリシステムを用いた欠陥数予測

• Jenkinsを用いて自動的に欠陥数を取得する
• R言語を用いて欠陥数を予測する

リリース時期の分析

• アジャイルに近い開発スタイルであるオープンソースプロジェクトを対象にリリース時期を分析
• 信頼性モデルをリリース毎に分割

予期せぬ状況の発見

動機付け

• ソフトウェア信頼性モデルが不一致になる場所がある
  • なぜそのようなことが起きるのか？
• 期待を超える時期が発生する

欠陥をテストフェーズで分類

• 継続的に問題が発生
• いくつかの問題が再発生したので、開発者がテストを止めて他のテストを再開させた

まとめと今後

• 今後は欠陥のデータベースを作りたい

質問

• 未解決な欠陥については研究の対象にしていないのか？
• していない
• 是非とも、対象にして欲しい
• PMが欠陥の理由を説明できない
• 比率を見て、どんどん欠陥が減っていっているか

• 見つかった欠陥をいつ修正されているかも研究の対象にしているところ

• バグの影響範囲や重要度、優先度は取り入れているのか

• 今回の研究では対象にしていない
• バグの重複についてはフィルターをかけている
• ユースケースで95%修正でリリースとしているが、残っているバグがクリティカルならばリリースできない

講演3：QA to AQ(Agile Quality): Being Agile at Quality

発表スライド

http://www.washi.cs.waseda.ac.jp/wp-content/uploads/2016/02/QA2AQ-Waseda-2016-.pdf

自己紹介

• Joseph Yoder

トレードオフ

• ユーザビリティとセキュリティなどトレードオフになったりする
• バランスが大切

リーン開発

• トヨタはLeanを実行している

アジャイルとは

• アジャイルはマインドセット
• アジャイルはフィードバックループ

非機能要件

• 非機能要件をユーザーストーリーでどのように表すか

• 非機能要件とかも重要なのに、スケーラブルだから大丈夫…？

• QA→QC

• プロセス管理

• 色々なパターンに当てはまるかどうか

• バリアをいかに壊すか

• 文化、言語、様々なバリアがある

  • QAが敵と考えられたりする

• アジャイルチーム

• QAの60%はユニットテストに

• Tearing Down the Walls: Embedding QA in a TDD/Pairing and Agile Environment

• Test early

• Automate "easy" test

• Qualify Loadmap

• Qualify the Backlog

• Quality Checklists

• Quality Splints

• Monitor Qualities

• Usabilityをどうやって計測する？

• "Quality Debt related to Technical debt."

• SteveMcConnell https://kev.inburke.com/kevin/the-best-ways-to-find-bugs-in-your-code/

Agile Quality Benefits

• Visibility
• Effectiveness
• Architectual Risk

Being Pragmatic

• Do the Agile

• Be the Agile

• No Planning No Design...Sometimes calls Agile

• Lot's of upfribt planning... Transitional Waterfall

• Ultimate Agile Stories

質問

• Agileの品質モデルはどのようなものがあるか
  • ウォータモデルならV字モデルがあったりするが…
• Valueが出るようにすれば良い
• Being Agileがなれば良い

• Vモデルでも良いが、改善させていくことが大切

• Test Baseをどのようにゲットするか

• Agile Manifestによる
• ドキュメントはValue
• Agile StoryがValueになる
• catalog, method

パターン一覧

• 障壁の解体
• アジャイルプロセスへの品質の組み入れ
• 本質的な品質の発見
• アジャイル品質シナリオ
• 品質ストーリー
• 測定可能な値やシステム品質の特定
• 折り込み品質
• アジャイルな着地点
• 着地点の再調整
• 品質目標の合意
• システム品質ダッシュボード
• システム品質ラジエータ（可視化する仕組みを用意する）
• ロードマップの品質検討
• バックログ上の品質検討
• 品質チャート
• チーム全体
• 品質に焦点をあてたスプリント
• 品質保証プロダクトチャンピオン
• アジャイル品質の専門家
• 品質のモニタリング
• アジャイル品質保証テスター
• 品質に関する作業負荷の展開
• 品質熟練者の備考
• 品質主義者とのペア

『時代の変遷と共に変わるテスト〜IoT世界に求められるテスト〜』参加レポート #jasst

自己紹介

二木

• セキュリティ屋の立場
• デベロッパーの方には嫌われる立場
• 最近はクラウドのセキュリティをやっている

吉澤

• 日本(にっぽん)電気
• デバイス経験が多い
• IoTの下支え中心
• 最近は品質向上活動
• IoTは何をテストするのかよくわからなかった

辰巳

• ソフトウェアの検査
• SQuBOKに関わっていたり
• テストの歴史的な話
• 昔からテストをやっていた人からの意見を言いたい

IoTの定義

• インターネット上のサービスと接続されたデバイスあるいは相互接続されたデバイスによって実現されるサービス
• デバイスとサービスは他の組織が提供することを相互接続して利用することがある

keynoteより

• ハッカーがハンドルから手を話しても自動操作しているのを使うことで事故を起こさせる
  • ジープ
• ISOでも3層ドメインになっている
• 入り組んだサービスについてもISOでモデリングされている

• デバイス側もどういうふうにやり取りするのかはISOやIECでモデリングされている

• これらからどんな課題があるのか

二木

• ジープのハッキングした人達はセキュリティのメンバー

• ジープをバラバラにしてファームウェアを解析することで、セキュリティホールを発見してしまった

• 色々な管理項目が増える

• 例えばアイデンティティ管理とか
  • いっぱいありすぎて蜘蛛の巣のようになる

近未来のIoTワールド

• Cloudブローカーみたいにサービスブローカーが出てくるかも
• デバイスとサービスのひも付けの間にデバイス管理をするレイヤーが挟まるだろう

雲の上から見たIoT

• IoTもサプライチェーンを構成していくだろう
• IoTは閉じた世界ではなくなるだろう
  • ワイパーを動いているかどうか見てその地域の天気を調べる仕組みとかしている
• 想定を超えた使われ方をしていくかも
• セキュリティ屋の心配事

吉澤

• デバイス側から話す
• デバイスに求められる機能は3つ
  • センサ
  • アナライズ
  • アクチュエータ
• 従来は限られた世界でちゃんと動くこと
  • お約束に従ってちゃんと動くことを保証すれば良い
• IoTになっていくことで、効率化しないと大量のデータを処理できないのではないか
• それとともにセキュリティも気をつけなければならない
• 得体のしれないものとつながる脅威
  • 外からの脅威によって
  • バルス
• 内部の脅威
  • 保証されない
  • 意図しない年数使われる

テスト

• 今まで以上に一つ一つがきちんと動いていることを保証する（十分性の保証）
• 今まで以上に行わなくてはならない
  • セキュリティ
  • 大量データや環境などを含めた組み合わせテスト
  • 通信制の確保
  • データをチェックする境界線
    • 自分はどこまでテストすれば良いのか

二木

• どこまで想定外を排除できるか
• 自分のところはきちんとテストする
• 仕様にこういうデータは入ってこないんだからチェックしなくて良い！と言われた
• セキュリティも製品やサービスの一部だという意識を
• 脆弱性は基本的にはバグである。
• パフォーマンスや運用に影響をあたえるものが脆弱性である
• 設計時にセキュリティ機構を組み込む
• 実装時のバグ潰し
  • APIに対する異常な取り扱いに対する体制のチェック
• 500エラーで返されるとしめた！（サーバーエラーになっている可能性あり）と思う
• リスクの高い使われ方を如何に潰していくか（サーキットブレーカー）
• APIを使ってごっそり抜かれないように、必要以上のところへのアクセス制限をかける
• 大量データを抜けないかどうかもテストの観点

辰巳

• ビジネスの観点からアプローチを披露して欲しい（松岡）
• つながった上でIoTをどうやってやるのかという観点
• 使う側/活用する側のシステムのテスト

課題

• テストの対象の見極め
  • 上位から見て着目すべきところは？
• ビジネス視点での評価
  • IoTはビジネスチャンスとして考えた時に、テスターとしての役割は？

課題解決のために

• テスターが持つべきスキル/素養
  • テクノロジーの知識、ビジネスドメインの知識
  • レイヤーの理解、APIの知識
• テスト技術の研究成果の活用
  • 例えば、コンポーネントTesting技術の適用とか
• つなぐための標準化、規約化への関与
  • テストのための仕組みも標準の中に取り込む
    • テスターからの積極的な提言が必要
• 組織的な取り組み
  • テスターの専門分化
    • より深くやるテスターが必要になる
  • デベロッパーとテスターの役割分担の追求
• テスト環境、標準化検証環境の整備
  • テストラボ
  • 標準検証スイート
• テストのエコシステム
  • オープンイノベーション的テスト連携モデル

Jon

• 二木さんが提案していた脆弱性とかを悪いことする人達はお金になるので一生懸命研究すると思うので、頑張ろうとするでしょう

• スペースシャトルのような巨大アプローチの中でどういう風にしたら良いと思うか

• 過去の大型案件を考えると、小さなエリアに分けてそれをだんだん組み合わせてやる

• テストは何階層もあり、デバイス、メーカー、ドメイン、政府のテストがあると思う
• 製品レベル（モバイル）、ネットワーク、IT、クラウド、全てを組み合わせてIoTのテストになる
• プロセスレベル、プロダクトレベルなど、各レベルで標準化しなければならないが、策定までには時間がかかるだろう
• フェールセーフのためのサーキットブレーカーを入れるのは良いことだと思う
• IoTの世界においては、大型のシステムでは故障に直面すると思う。
• ユーザーがデバイスに接続方法が様々あり、全てのレベルでテストベッドが必要
• IoTと一口で言っても、サイバーと物理的な世界でのものなので、生命にも関わったりすることがある

松岡

• 脆弱性はバグなのか、バグでないのか
• 私は二木さんと吉澤さんの両方の経験を把握している
• 脆弱性はバグと捉えている
• バグではなく仕様上の欠陥ということもある
  • 上位から降りてきたもののフォーマットが自分が用意しているフォーマットと全然違ったことが

吉澤

• 「標準」が今は無いが、標準を使って複数テストすると思うが、標準を使わなくなった世界ではどうするか？
• 困りますね
• 標準があれば一つ一つ確認はできる
• ただし、標準があっても、捉え方が違ってしまうと希望通りの性能が出せるか微妙ではある
  • 現に上の人と下の人で変わってきてしまうと思う

辰巳

• 標準化はまだまだこれからだと思うが、プロジェクトは進むよね？その上でどうすれば良いのか？ビジネス側では何を見れば良いのか
• おそらくTry and Errorでやらなければならない
• お客様に迷惑がかからないように
• 検証とかで抑えていかなければいけない
  • こういう時にテスターの出番かも
• OSが安定していない時に、どういう風に回避しつつ運用で安定していくか考える
• IoTの世界なので、膨大なパターンが有る中では難しいかも

Jon

• アメリカ政府には沢山のカウボーイがいました
• フロンティアだよと言いたいんだろう（松岡）

松岡

• マイクロソフトのOSのVerUpを抑えるようにした回避策とかはある
• ビジネス面から見れば、確かに回避策のアプローチを取らなければならない
• 大きな塊の中でどうやってテストをやっていく時に、どういう形で担保するようなテストをシステムレベルでやれば良いのか

Jon

• 私がおすすめするのは、色々なものを組み合わせてテストする方法
• アメリカでの面白い取り組みとして、大規模なしくみを自動テストで保証するために多くの組み合わせで保証した
• まだまだ我々も学習中ですが、それが役に立つと思う

松岡

• 標準化、規格化について、
• セキュリティはまだまだ進んでいないのでは？

二木

• 一部、セキュリティに関しての動きはあるが、一つの形を作るのは難しい
• 個別の分野ごとにセキュリティの規格が定まってくるのではないか

吉澤

• 標準が変わったら？
• やり直し。仕様の中に紛れ込むので難しいところはあるが

Jon

• やり直しという考え方は正しいと思う
• Agileという考え方が重要

松岡

• reworkも含め、テストも進めていかなければならない
• IoTのテストをするときに、どんなことをrequirementする必要があるか

Jon

• 時間、場所、コンテキスト、コンテントに関する認識をした上でテスターはやらなければならない

吉澤

• ソフトウェアの設計でちゃんと対応していれば良い。
• 標準が次々に変わるとわかっていれば、その部分についてだけテストを変えることは良いことだと思う

まとめ

• Jonが言ったように、IoTが動く仕組みやそれに伴う制約をきちんと理解し、標準が変わる変わらないも認識した上で、IoTのテストを頑張らないといけない
• 個別のテストの話として、脆弱性をテストする基本的なテクニックはやっていかないといけない
• 責任分割点は難しいが、サービスを提供して、満足させるところがどこまでなのかを可視化できるかどうか
  • 可視化されるためのテスト
• お金に関わる話なので、ここまでは大丈夫という線引をしなければならない
• 今後のプロジェクトの中で、一つの指針としてここでの話を活用して欲しい

辰巳

• 自分の思いは問題解決のためにというところ
• IoTはチャンスではあるので、テスターとしての腕を磨いて欲しい

吉澤

• 松岡さんから可視化が大事、そのためにテストがあると言っていた。その中でJonのリストが役立つ。

二木

• どこまでやれば良いか？とよく聞かれるが「リスクベースで考えましょう」と答えている
• どんなインパクトがあるか
  • 医療系や車では人命に関わる
  • 個人情報に関わる
  • 繋がっているデバイスの数

Jon

• IoTが訪れる間、発生する変化に楽しんで欲しい

質問

標準化について。IoTは新しい技術が出てきてChangeすると思うが。標準化と変化、どちらが速いと感じているか

• 標準の問題は合意形成に時間が掛かるということ。かなりの遅延が怒ると思う
• 製品の標準化は自然淘汰が多いので、時間がかかる
• だから、「変化を楽しめ」というメッセージを言った

変化を楽しんでいる間、よくわからない状態でやるテストとしてユースケースで攻める、組み合わせをオートメーションする手法があると言っているが、ユースケースを元にしたSearch Based Testingということか？

• 組み合わせテストの背景としては自動化のレベルを上げたい

品質保証部、テストチームの振る舞いが気になっている。IoTだと正解が分からないことになっていくと思う。その場合、開発と一緒のチームとして動くべきか？

• 開発も品質保証もテストもオペレーション部隊も上位においては統合すべきだと思う
• 多くの人は慣れ親しんでいないと思うが（Jon）
• 是非セキュリティの人も入れて欲しい。
• 開発畑から来たセキュリティの人が適任だと思う（二木）
• DeveloperとTesterの関係について。開発部門がテストも含めて自信をもってつくる。Testerがそれをさらに確認する。それが最近はAgile Testingになったりする。
• 新しいことをチャレンジしなければならないが、それで別部門を作って、きっちりやる部門と挑戦する部門で分かれてやっていくことが必要なのではないか（辰巳）

『テストプロセス改善技術から探るテストの"改善"とは』参加レポート #jasst

テストプロセス改善

登壇者の紹介

• 薮田
  • TPI NEXTの立場から
• 増田
  • ISO/IEC 33063の立場から
• 西
  • ノンモデルのプロセス改善の立場から
• 足立（モデレータ）
  • SaPIDの立場から
• 池田（モデレータ）
  • TMMIやTPIを導入支援した立場から

テストプロセス改善技術のこれまで

• まだまだテストプロセス改善は実施されていない
• ただし、最近発表が増えてきている

TPI NEXT(薮田)

• 自己評価とそれに基づく自己解決
  • 他人に見せても何も分からない
• 評価軸はプロセスではない
  • 独自に選定した16個のキーエリア
• ビジネス主導である

ISO/IEC 33063(増田)

• 国際標準であること
  • 認証はこれから？
• アセスメントモデルから…
  • 何のプロセスにあっているの？
    • ISO/IEC/IEEE 29119-2
  • どれくらいあっているの？
    • ISO/IEC 33020

ノンモデルのプロセス改善

• TQM
• 品質管理を一生懸命すると頭が良くなる
• TQMはマニュアルではない
• 人の数、会社の数だけTQMがある
• 理解して適用するのではなく、自分の会社なりにTQMを進化させることが大切

ソフトウェアテストの現状（海外の人から言われること）

• 日本は品質の高い会社があるんだからソフトウェアでもやればいいじゃないか
• なんで海外のプロセス改善を買ってくるの？

TQMの思想

• 思想を理解せずにツールボックスとして使っていることが多い
• 全ての質を上げることがTQMの思想
  • お客様が如何に喜びを感じるか
  • 品質第一
    • 品質をきちんと上げれば、コストが減るはず
    • 最初にコストを下げると、品質が下がるコストが増える
  • 改善
  • 全員参加
  • 「何が嬉しいのか？」を常に問う
  • おかしなことの原因をパターン化して共有する
  • 未然防止
    • まだ出会ったことの無いものを防ぐ
  • 管理は技術である
  • 次工程はお客様
• 品質管理が「まずはメトリクスを決めよう」という人は信用しなくて良い
• プロセスを見るな、問題を見ろ

技術を導入する際の注意点や難しさにどう対応して行ったら良い？

薮田

• TPI NEXTはプロセスだけではない
  • ISO/IEC 33063はプロセスのみだけど
• TPIは訳がわからなかった
  • ゴルフのキーエリアをやってみたらようやく分かった
• キーエリアを無手勝流でやってみると、えらく金と工数がかかる
  • だったらTPI NEXTとかのフレームワークに乗せれば良いじゃん
• 合わない所があったらカスタマイズする
  • カスタマイズした結果、それぞれの会社ごとで別々のプロセスになる
• プロセス改善モデルと言われると、プロセスを定義して改善するようになっている。プロセスは決められているの？
  • プロセスは定義していない。
    • TPIのPをプロセスと訳しているのは良くないと思う
  • あくまでもテスト改善

増田

• ISO/IEC 33063はプロセス改善モデル？
  • あくまでもアセスメントモデル（評価モデル）
  • ISO/IEC/IEEE 29119-2を用いている
• ISO/IEC/IEEE 29119-2以外に追加しているものはあるか？（教育とか）
  • STATIC TEST PROSESSの部分とか…

池田

• TMMiは？
  • こういったことをやりなさいという話だけはしているが、具体的な進め方は会社ごと
• ISO/IEC 33063はISO/IEC/IEEE 29119のプロセスを守れと言っている。
  • つまり、ISO/IEC 33063とTPI NEXTは相容れないもの
• 導入の中はTMMiとTPI NEXTは同じように進んでいく
• 実際の仕事の進め方は直接的に書かれていない
• TMMiはISO/IEC 33063よりはTPI NEXTに考え方が近い

アンケート

• 実際のプロセス改善を行おうとしている
  • 5%ぐらい
• プロセスに関する業務をしている
  • 半分
• 自分だけでなんとかしようとしている
  • 少ない

会場内の質問・悩み

難しい

• 余計なことを考えずに質問に1個1個応えるだけで良い
• 1時間ぐらいでできる
• チーム間での違いなどを議論すれば良い
• それは、俺達困っているかも？と気付きが出るということか？
  • チーム間での違いから議論が湧き上がる。それでも1日ぐらい
  • チェックリストに付けて議論しようよ、と伝えたい

見積もりができない、説得できない

• 反対派が多い、改善へのモチベーションがない
  • 困ってないんじゃない？ならいいじゃん
  • 押し付けが起きている？
• 他プロセスへの改善にどう繋げるのか分からない

プロセス改善に至るまでに時間がかかる

• プロセスを標準化したほうが良いよね？というコンセンサスを取るのが大切
  • それがないと改善のモチベーションが無いことに繋がる
• 開発のプロセスから考えていって、最後の方にやってテストプロセス改善に繋がる

テストだけ改善しても打開できないことが多い

• とんがっていてもみんなに同意してもらえない
  • こういうモデルがあるから…というのはだいたい否定される
• 何に困っているのかまずは出し合ってみるのが大切
  • みんなで話せるようになって初めてモデルや手法の話が出てくる

忙しいし、どーせテストだし、みたいに思っている人にどうやって壇上に上げれば良いのか？

• 困っていることを見つけてあげる
• 困っている人だけ？想いが熱い人だけ？熱くない人も入れたほうが良いの？
  • 人格による。
• 場を作るのがとても大切
• 人間は環境を与えると勝手に動き始める

テストの改善とは

薮田

• いつも会場からの質問のようなことに悩まされている
• 抽象的な話を推進するときに、言葉で説明するのは無理
• 実物を見せる以外に手は無い
• まずは自分の頭の中だけでやってみる
• ふふーんと思った上で、隣の人とかに広げていく

増田

• 上司への説得の材料をもらいにこのセッションに来たと思う
• それに答えられたか不安

西

• 不良品の検査結果から分析して、良いやり方を標準化している
• ソフトウェアは仕事のやり方さえすれば
• 役に立たないテストケースの山を見て、どうしてこのテストケースがダメで、ということを分析すべき
• 本当はテスト漏れを見るべき

• テストの網羅できる実感が無いよねから始めると良い

• 現場ではテストを知らない人が多いので、その人達への話をきっかけ

テストプロセス改善技術研究会

• 現在、設立に向けて準備中

『いつどこをテスト自動化するべきか』参加レポート #jasst

はじめに

• メーカーとコンサルでアプローチが違ってくると思うが、発表者2人の経験を元に話す。

テスト自動化とプロジェクトの成功について

• テスト自動化を成功したつもりだったが失敗した。
• テスト自動化の成功定義、テスト自動化の目的がメンバーや上司と意見が一致しないはず
• テスト自動化の成功を定量的に示す

定量化って難しい

• メトリクスを取ろう→150個作ってしまった
• 真剣にやったがために目的が見えなくなる
• 絞り込むのは必ず行う。
  • データはいくらでも取れるが、目的から導かれるデータは3個ぐらいになる

失敗例

• 開発が遅れている→テスト期間を短縮→テスト自動化しよう
• 「QEだろ、なんとかしてくれよ」と言われた
• 前回はテスト期間が短かった→最初からテスト自動化しよう！→何をやりたいのか深く考えずにコンサルに頼ってしまったから失敗した
• テスト自動化だけでなく、テスト全体や製品全体のことを考えていなかった

成功させるために

• 本当に今自動化が最適な解決策であるか議論しよう
• 調整が必要な人を握っておく
  • 決済権者やCS担当者を味方にする
    • CSは本番と最前線で戦っている
• 利害関係者と自動化による改善のKPIを合意する
• 最小限の領域で提案する
• みんながハッピーになるようにすることが大切

テスト実行以外の自動化

• テスト進捗とか合格率とか
• 開発期間が伸びてテスト期間が短くなる状態でテストを回すには、集計とかは自動化しておくべき

テスト自動化しやすい活動は？

• ビルド自動化やデプロイ自動化
  • ビルドは一人でもできる
• スモークテストスイート
  • ゲームのようにランダム実行が多いものでも、全実行でヌルポが起きないかどうかだけでも効果が高い
• マネーパススイート
  • 決済関係
    • お金が関わる部分は重要

• 不具合駆動

  • 欠陥の偏在
    • 『ソフトウェアテストの7原則』より

• 「全部大事」とか開発者は考えがち

• リスク駆動型で考える

• スキルによって左右されるテストケースは自動化しづらい

いつ自動化を始めるべきか

• アップアップの中でやっていくのではなく、できることなら最初から
• 自動化の仕方を考える前に見える化する仕組みを考えた方が良い

• 自動化すると不具合がいっぱい見つかる→開発者が不具合の修正にかなり多くの時間をとられる→不具合をスクリーニングする仕組みを考える

• ISOやJISも読むと良い

• ソースコードを読むことも自動化する人にとっては重要

• お客さんの制約の中でも達成できることを探す

質問

テストの進捗と合格率はわかるが、スクリーニングの仕組みとテスト分析とテスト設計の仕組みを教えてほしい

• テストのスクリーニングについて
  • テストの結果、テスト実行者が間違っているとか手順書が間違っているかもしれないという状態で、それを開発者に投げると、「自動テストの品質が悪い」と言われる。
  • インシデントの中から故障だけを開発者に伝える作業を行う。

テスト自動化した後でやったほうが良いことは？

• テスト設計の自動化をしたい
• テストスクリプト作成の自動化はできると思っている
  • フォーマットに従って。
• KPIをきちんと見直す
  • ROIではなく時間短縮が多い
• 空き時間が出た時に全体最適化を考える

期待値のコントロールの仕方について

• 初期は過剰の期待を持たれがち
• 最小限が小さすぎると効果ないと言われたり
• テスト自動化しやすい箇所をやる
  • SeleniumIDEでやってみて短期的な目的を達成したり
• その後、テスト自動化の成功の定義を見直す

『テスト自動化エンジニアやそのキャリアパスってなんだろう？』参加レポート #jasst_ta

はじめに

• テスト自動化自体にフォーカスを当てることが多いが、このセッションでは人に焦点を当てる

自己紹介

浅黄

• 色々と経験してきて、品質って大事だなと思えるようになってきた
• 10数年前に商用ツールを使ったのが自動化のきっかけ
• OSSに偏ってきた（ココ数年）
• 技術開発部に所属

後藤

• 7年前にIT系に入って負荷分散システムを作る
• 検証って面白いと考えるようになってベリサーブに転職
• 実務レイヤーではなくマネージメントレイヤー

玉川

• コンピュータサイエンスを大学で学んでいた
• 最初の6年間は開発していた
• 自動テストやCIの知見が溜まってきた
• 技術開発部に所属
• 自動化エンジニアを育てるために教育もしている

松尾

• 院までコンピュータサイエンスを学んでいた
• 新入社員の頃からテストに興味を持つ
• 分散ネットワークなどを学んでいた
• 2年前からクックパッドに転職
• 今はモバイルアプリ中心
• プロセス全般を見ているが、モバイルの自動化も学んでいる
• モバイルの開発やnginxなどのサーバーサイドの開発もしている

山口（モデレータ）

• Yahooでアジャイル開発やテストをしている

Ajenda

• テスト自動化エンジニアとは？
  • どんなことをする人ですか？
  • どんなスキルを持つ人ですか？
  • どんなマインドを持つ人ですか？
  • どういうキャリアパスで、自動化エンジニアになるのでしょうか？
  • テスト自動化エンジニアになったあとのキャリアパスってどうなるのでしょうか？
• 会場からの疑問

テスト自動化エンジニアはどんなことをする人ですか？

浅黄

• 時代と共に変わってきている
• 商用ツールの頃は、商用ツールを使える人＝テスト自動化エンジニアだった
• 負荷テストやセキュリティテストのパターン網羅などをやれる人
• 最近はテスト工程だけでなく、運用工程でも活躍する人
• リグレッション部分を上手に自動化する
• CI系のリリースまでの自動化する人も含めて自動化エンジニアである
• 色々なお客さんの言う「自動化をやりたい」といっても意味がそれぞれ違う
• ベストプラクティスをとるのか、今の最適を取るのか
• スクリプトを書ける人
• 手動テストを自動テストにするときに、システムを構築するうえに、自動化しやすいように変換するスキルも必要

後藤

• 後藤さんはマネジメントの立場から、テスト自動化エンジニアはどういう人を指している？（山口）
  • 浅黄さんと同じく、ツールを使える人をそうだと思っていた
  • 自動化は手段であり、もっと包含的に品質を理解することが必要
• 自動化というよりも課題解決？（山口）
  • 結果的に全員幸せになれるようにする

玉川

• 玉川さんは自動化を提供している立場として、テスト自動化エンジニアはどういう人を指している？（山口）
  • 最初は自動化と受けたら、「自動化しなきゃ」にフォーカスが当たっていた。
  • 今は「テスト設計をしなきゃ」にもフォーカスが当たっている。
• 自動化アーキテクトと自動化エンジニアと職種を分けている
  • アーキテクトは課題解決まで考えている

松尾

• 松尾さんはサービサーの立場として、テスト自動化エンジニアはどういう人を指している？（山口）
  • 最近まで、自動化エンジニアは自分一人だけだった
  • ゴールはサービスを届けるために改善していく
  • エンジニア全員が改善していく
  • ボトルネックを改善するために何らかの部分を自動化していく
    • モバイルの場合は、GUIの確認に時間がかかっているのでリリースサイクルに合わない状態だった
  • サイクルに合わせるために自動化していく
  • 今はだんだん安定したテストを回すようにしていく
  • UNIT単位まで踏み込んでテストパターンを開発者にも伝えている
• 自動化エンジニアがいるのではなく、もっと広い意味でのエンジニアが沢山いるということ？（山口）
  • UNITテストを書くのはそれぞれの開発者
• 自動化に特化したエンジニアはいない
• アーキテクチャに特化した人がテスト自動化エンジニアという肩書きになっているのかもしれない

山口

• 松尾さんの他の人は、テスト自動化エンジニアと言えるような職種の人はいますか？

浅黄

• そんなに多くはない。品質を良くしようと言うために自動化を使う人がいる
• 「テスター」という言葉は好きでないが、テストエンジニアとなったときに色々なところを見なくてはいけないと思う
• オールマイティになんでも見よう

後藤

• 明確な職種はいない
• 意思表示をした上で、自動化に興味のある人を集めている

山口

• 結構幅広いですね。

テスト自動化エンジニアはどんなスキルを持つ人ですか？

浅黄

• テストは手動でやっているところにとって、自動化をやりましょうとなったときに色々なことをやる。
  • 自動化用にテストを抽出する
  • 環境の事前設定をする
  • 自動化システムを構築する
  • ツールの知識がある
  • スクリプティング技術がある
• 観点として、常に回し続けるための仕組みは考えておかないといけない
  • CI的な観点を
• テストというよりもエンジニアリングに近い人？（山口）
  • STARに入って思ったのが、プログラミングスキルがすごい必要だと感じている
  • 社内でも勉強会をしてスキルアップを図っている

後藤

• 開発経験がある、開発に抵抗がない
• テスト自動化で何を解決するのか聞き取るコミュニケーションスキル
• 成果の可視化のスキル
• 決まった後に、環境構築や、ツールの適切な選択ができる
• 問題解決に方向を持っている
  • 何が嬉しかったんだっけ？と方向を考えておかないと、カオスな状況になる

玉川

• Shiftさんは職種が2つに分かれているようですが、その中で自動化エンジニアの職種に求めるスキルは？（山口）
  • スクリプトをきちんと作れる人
  • 開発出身でなくても、開発が好きな人
  • 最初はスクリプチティングから始まって、その後にCIで
  • 自動化は知らないけど、開発はしてましたという人は自動化エンジニアになれる
• 問題解決については自動化エンジニアには求めない？（山口）
  • テスト設計して意図した内容を回しているか重視している
  • それ以上だとアーキテクトになる

松尾

• コーディングのスキルよりもシステム全体に俯瞰できる人
• 自分達の管理できないところに何があるのか
• 閉じたところでやった時にこの部分はテストできて…
• コーディング技術はあればハッピーだが、システム全体を見れるスキルが必要
• テストエンジニアはかなりのスキルが必要
• 90年代のテストは開発者から上がってくる人しかいなかった
• 何が問題なのか見つけて、設計できる人が良い
  • それは今の自分の理想でもある

浅黄

• 松尾さんはエンジニアリングのスキルはそこまで必要じゃないと言われたが、浅黄さんはどう思いますか？（山口）
  • 納得してしまった
  • 自分はツールを使えることから始まっていたので
  • 全体像を掴むスキルが必要
  • やらなくちゃいけないところが多い中で、抽出することが大事
  • 「ここがまずいよね」と感じられるスキル
  • 全体を持っていないといけないと納得した
• 昔は開発上がりの人が自動化エンジニアになっていた？（山口）
  • SQuBokの第1版ぐらいの時代だと、開発でしかできなかった
    • その頃は生まれていなかったので…（松尾）
• 昔、「この人はバグを見つける→それを自動化できればなぁ…」と思っていた
• いまだとバグを見つけるテスターがいるので、テストエンジニアにしたい

質問

• 問題を掴む際に、対象のことやテストの観点を知らないと、掴むことができない。機能の部分は良いが、非機能の観点は自動化エンジニアのスキルとして持つべきか？

松尾

• モバイルアプリだとパフォーマンスが悪化していることは気にしなければいけない
• どこをどういう手段で計測し続けるかみたいな形を考えている
• 非機能的なところについても後回しにしたことで事故になったりする
• 自動テストの傍ら計測していくようにしている

techlife.cookpad.com

• 外に任せられることは外で

浅黄

• 負荷テストをいっぱいやってきていて、OSSで自動化するときの役立ったりしている
• どこに問題が潜んでいるか観点を持っていることで、機能テスト側の技術も広がる
• ツール主体できたので、ツールを使った結果、何を見えるのかを考えておく必要がある

テスト自動化エンジニアはどんなマインドを持つ人ですか？

• ここまではテクニカルな話が多かったが。
• スキルの話だけだと、「スーパーマンか」と思えるようになっているけど

浅黄

• 諦めないこと
• やれる手法は色々ある
• 固執し過ぎると、テスト自動化することが目的になってしまう
• 自動化ハイになったり、失敗するところを避けて自動化したりする人ができる
• 探究心がある人
• バッサリ捨てる決断がある人
• 柔軟性のある人

後藤

• 浅黄さんの意見とほぼおなじ
• 物事を中長期的に粘って行うこと
• 新しいものが好きな人

玉川

• 共通して言えるのは、お二人と同じ
• 第三車検証として、お客様を支える
• コーディングスキルを持って新しい製品を作りたいというと合わない
• 綺麗にしたい
• 開発が変更すると、エラーとの戦い。それを楽しめる人

松尾

• 最後だと大体言われつくされる…
• 物事を潤滑にする人は適任かもしれない
• プロセスを楽にできたら良いなぁと思う
• プログラマーは怠惰であるというところに対して向かっていく

山口

• 皆さん、粘り強さが必要と言っている
• マインドを持っていない人に対して、育てること、ケアすることはあるのか？

後藤

• 前を進んでいる人が良い背中を見せる
• 辛いことが多い中で、価値を届けたことで得られることとか、頼られるように
• 背中を見せている人がいるということですね？（山口）
  • 最近います

玉川

• チームの定例会議で、自動化チームではアーキテクトの人に若手向けに話している
• シニアの人がプレゼンテーションを作っているわけでなく、若手にもメリットを伝えるプレゼンをするようにしている
• 背中を見せるというよりも指導しているということか？（山口）
  • 私が指導、太田さんが背中を見せるようにしている

どういうキャリアパスで、自動化エンジニアになるのでしょうか？

浅黄

• あまりバリエーションは無いと思う
• 私はプログラマから入ってきた
• テスター、テストエンジニアから自動化エンジニアになる
• いきなり自動化エンジニアになるようなことも取り組んでいるが、なかなか難しい
• 自動化エンジニアとしてスクリプトを組めるとかは覚えれば良い
• 1年も必要ない
  • 改善に向けた…とか考えると数年かかる

後藤

• ゼロからのスタートメンバーがいるが、スクリプトを書けるのは半年ぐらいでできる
• 手動テストから入って「自動化できたらな」と考えられると良い
• 実装者じゃない人になるまでの期間は？（山口）
  • テストを1,2年、テスト自動化エンジニアとして2,3年ぐらいでなれる

玉川

• スクリプト書くだけであればそんなに時間はいらない
• 今年、新卒が2人入ってきたが、1年でテスト設計と管理とスクリプトを組むぐらいはできた
• 指示を受けるならできる
• アーキテクトはなかなか難しい
• 開発は元々できていて、自動化のエッセンスを持って急成長した例もある
• スクリプト以外のテクニカルな部分も必要
  • CI構築時のスクリプトとか

松尾

• 自分もどうなっていくのか、自分はどうなれば良いのか？と疑問に思う
• 大学の頃は、大学の授業とか研究だからコードを書くということはあった
• 入社後、コードを書けるなら開発に行っていた
• テスト系の勉強会に出て知見を蓄えた
• 若干プログラマ、若干テスターから来ている
• テストエンジニアの定義は今からだんだん狭義な状態になっていくはず
• 今ならスクリプトを書いているとかいう人も含めて自動化エンジニアになっている
• 「ちょっと書ける」というのはテストコードのこと？（山口）
  • WEBアプリだとテストコードを書けるに加えてプロダクトコードも書けるぐらい

玉川

• 「コードを書ける」というのは松尾さんと同じぐらいのイメージ？（山口）
  • 基本的にはテストコードも書ける
  • 松尾さんが言っている「ちょっと」は私が求めている1年目のスキルではない

浅黄

• 自動テスト＝キャプチャーアンドリプレイが多い
• これは、「ちょっと書ける」には当たらない
• 実際にコーディングが出来る、開発の技術が少しあるぐらい
• テスト設計も構築もスクリプトも出来るようになったばかりの人は、自動化のことしか出来ない
  • シナリオ的な書き方もしくはユーザー敵、機能網羅とか書き方が変わってくるが、それぞれに対応できていない

テスト自動化エンジニアになったあとのキャリアパスってどうなるのでしょうか？

松尾

• 未来を語るネタがない…
• どのくらい先を考えるかによって違うが…
• 生み出そうとしているサービスが嬉しいのかどうかを判定できるシステムをやろうと思えばできるはず
  • 人工知能を使ってたり
    • Gooleの例もある
• 非機能的な部分も評価する方面があると思う
• 方法論とかもひっくるめて？（山口）
  • はい。ただ、何十年先でしょうか…

玉川

• アーキテクトになった人のキャリアパスは？（山口）
  • 尖ったところを突き詰める。
    • いまだとラッパー程度だが、ツールを1から作り上げるぐらいまで
  • 領域をあえて狭くしているが、広げていってスーパーテストコンサルタントになるのも良いかも

後藤

• テスト自動化エンジニアを経た先は、ゴールが無いところなので、退職するまでずっと勉強
• コンサルになる道に近づける場所だと思う

浅黄

• テストアーキテクトの道はあるようで無い
  • スペシャリストを目指す
  • もしくはゼネラリストを目指す
• 検証分野はAIに置き換えられるのかなと思っている
• 新しい技術を構築できるという意味のスペシャリストを
• テストの自動化というよりは全体の自動化を
• それはどれくらいでできるようなものか？（山口）
  • AIが人間を上回ると言われる頃には
• 自分達で活用する。
• テストというよりはサービスをイメージする

松尾

• スペシャリストの方向とゼネラリストはどういう仕事に繋がる？（山口）
  • ゼネラリストはテストコンサルに繋がると思うが
  • スペシャリストとしては、A/Bテストエンジニアリングのような、領域に特化した（やることに対して）の人が出てきたりするのでは
    • ユーザー企業には必要とされている
• なんでも相談のります、解決担当？（山口）
  • 役割が広まっているが、エンジニア全員が得意分野が一緒ではないので、それを補完するように

浅黄

• 自動化エンジニアって、対象のソフトウェアのアプリに対して領域のスペシャリストもありと思うが、広く浅くではなく、深く狭く、深くが何本もあるように
• テストコンサルの中で深いことを持つ人もいる？（山口）
  • コンサルタントではなく、アーキテクトとしてツールを見ていくこととか
  • 狭く深くは方向としてはあるが、仕事として見えにくいかな？と

質問

• 構成要素のことをよくわかっていくとできる細やかなテストとブラックボックスの二つがあると思うが、セキュリティのテストとかはセキュリティを詳しいからできると思う
• プラットフォームをよく分かっている人にストレステスト
• 構成要素にやたら詳しい人に対してのキャリアパスはあるか？
• こういうことができる人、というのがキャリアパスになるのか？

松尾

• サービスとプラットフォームで分かれて開発者が分かれているので、テストエンジニアもあると思う

玉川

• 今回は第三車検証の人が多いので話題になっている
• 構成要素はお客さんに合わせてでは無いと思うが詳しいにこしたことはない。
• 色んな所にいっていると、その会社でキャッチアップする必要がある
• スペシャリティを持っていることは重要だが、そこだけだと潰しが効かない
  • ゼネラリスト的な要素を持っている上でスペシャリストとしてあると良い
• 着眼点を持ったサービスがあれば…

浅黄

• 昔は何かの技術に特化したイメージだと、このツールができますというアピールはあった。
• ツール特化だと、ツールのバリエーションはあっても良いが、それを売りにしちゃうと

質問

• ツールとか、ツールのスクリプトは具体的には？

浅黄

• Jmaterとか、Selenium WEBDriverとか
• QTP、Silktestのスクリプトが書ける人
• 大体はキャプチャーアンドリプレイなので

アンケート

• テスト自動化エンジニアですという人は？
  • 1/3から半分ぐらい

質問

• 特化したエンジニアがあるとするならば、一人で仕事するのが普通なのか？分担してやっているか？

松尾

• 一人で黙々とやるのは無い。話しながらする

玉川

• 手動のテストと自動のテストは分かれて行う
• バックグラウンドを共通の理解として持つ

質問

• 今回、自動化エンジニアになりたいということは分かったが、なりたくなるような動機があれば？

後藤

• エンジニアって良いなと思うことが市場価値を高めることになる

Microservices Casual Talks パネルディスカッション参加レポート #microsvc

イベントページ

connpass.com

モデレータ

• 高井直人
• みんなのウェディングCTO
• 今日の話はちょっと厳しかったのでは？
  • 個々の事例を話すと細かい話になって自分のところに当てはまらない
  • アーキテクチャの話だと抽象的すぎて…

• オライリーさんの本はよくわからない

• 基本的に会場からの質問に答えていく形式

質問

• 開発環境をするときに、依存するサービスを立ち上げなかったりしないとデータを入れていくとか面倒くさくなったりしないのか？

吉川

• クックパッドでは動作確認環境がある
• そこにdeployしたものをつなげたりする
• 共通の環境に繋げる
• データはどうするのか？（by 高井）
• 共通のデータベースを使っている
• プロダクションのSlaveを使うことで、ほぼ本番同様のものを使う

前板

• canariaを使う
• 本番に出る前に動作確認をする

大谷

• AWSでは、大前提で個々でオーナーがはっきりしている
• stagingとかがあって、パイプラインがあって、canariaでdeploy
• プロダクションで、一つだけdeployして様子見してみるとか
• development→stagingの環境

質問

• localでの環境では開発しないのか？

大谷

• なるべくDockerのイメージとかでできると楽

高井

• コンピューティングは無料に近いのでいくらでも動かせれば良いじゃん

大谷

• Netflixはシングル環境

前阪

• 最近だとクラウド環境
• 15インチのmac book proを担ぐのは辛い

質問

• 1サービスのチームの規模、1マイクロサービスあたりのチームの規模、サービス間のコミュニケーションコストはどれくらいか。

大谷

• GILTの話
• チームを変更しないといけない
• 5〜10人でマイクロサービスが100個とかを分けると破綻する
  • ここらへんが理解されづらい
• AWSだとマイクロサービス毎のチーム
• 全体を把握するのが難しい
• 5人ぐらいが良い（two pizza ルール）
• 200個とかのサービスに分かれたりすると、複数のマイクロサービスを束ねたりする
• Amazonの基本的にはNo Meeting
  • APIに従うだけ
• データベースのアクセスポイントは開発者に公開しない
• 大きなプロジェクトは横串
• お前のことなんか知らねーよ的なことになっている
• 日本に合うかどうかは気になること

高井

• アジャイルと近い考えで、やったことがある人とない人で理解が違うかも

吉川

• チームによりけり
• 2人や3人で1つのサービスを見ている
• 基盤系のサービスの場合、4人で5つのサービスを見たりする

アンケート

• マイクロサービスを運用している人
  • ちらほら

質問

• deploymentの質問。1サービス1VM、EC2をいっぱい立てるとか、1VMに複数サービスを置くとか色いろあると思うが、それらに対してメリット・デメリットがあるか？

吉川

• クックパッドだと環境によって分けてる
• 本番環境の場合、1つのサービスにELBは1つ
• テスト環境だと同居している
  • 同居することでリソースを食い合う
  • ただし、テスト環境ではそこまで気にならなければ、管理が複雑にはならない

高井

• 如何にResirienceを確保するかを考えるときにMicroserviceが出てきたと思う
• Availability Zoneが落ちても良いかどうかとか

前阪

• それぞれの最適解が異なる
• いきなり100点を求めることではない

高井

• 組織の要求に合わせてプラクティスを考える

質問

• UIレイヤーのサービス、複数のビジネスドメインが入っている時に、誰がUIを作るのか
• 例えば、カレンダーとか検索とか複数のサービスで使ったりするが

大谷

• AWSではConsoleが各サービス・チームで違う
  • 例えばS3とEC2で違う
• AWSはUI/UXはすごい弱い
  • 最近は良くなってきている
• 一つのマイクロサービスのデメリットとして、全体のUIを横串で通さないといけないが、それが難しい
• APIごとで分かれると、利用者で使いづらい

前坂

• UI/UXの専門チームがいる
• 開発者がそこを触れることはない
• JSON APIがスタンダードになると、UI/UXで変わらなくなる
• 将来的にはemberになるのでは

吉川

• クックパッドはフロントエンドからバックエンドまでやる
• 横串のエクスペリエンスは、それ専門のチーム（ユーザーファースト室）がある
• 原則はそこのチームが作ったフレームワークに乗っ取る

質問

• 認証に関する質問。
• 認証のレイヤはどこでどうするか

大谷

• AWSは認証の部分のマイクロサービスでチームがいる
• セキュリティのスキルがある人が頑張っている
• 統一化するようにしていく
• 業務から入ると難しいのかな
• この部分の実装のスキルセットを持っていない時にどうしようとか

佐藤

• Microsoft(Azure)では、REST API経由で
• 認証用のサービスを作っている
• 中の仕組みもOAthとか
• 各サービスがAPIを呼んで認証する

高井

• APIゲートウェイとかで一番最初に解消するということか。

佐藤

• Azureも1つのサーバーを共有している

吉川

• 次期クックパッドの認証を社内で話している
• コアになる認証を持って、全サービスが問い合わせる
• 現状だと無理が出てきている
  • 固有のセッション管理とか
• ユースケースが色々
  • 住所とかの個人情報と匿名性の高いもの
  • 会員とか、一見さんとか
• 中央集権的な認証を廃止して、サービスごとに認証をdeligateする
• 認証の要求レベルが変わる

質問

• Reactive アーキテクチャとMicroserviceアーキテクチャの違いや関連は？

大谷

• マイクロサービスで分けていくと、1 to 1のコミュニティは無理があって、10msが10個あると100msで成り立たない
• 1by1でキューでやると成り立たない
• イベントの入り口のところで必要なのは同期の入り口と非同期の入り口、エンドポイントに対してsubscribeする
• 興味が有るところにsubscribeしておけば良い
• 出口の部分がそのように連結している
• 絵で書かないとここらへんの説明は難しい

質問

• AWSの中でのmessagingシステムはどうやって？

大谷

• 要件によって違う
• AWSのメータリングは、30日後にバーンと出ていたりしていた。
  • これはReactiveではなかったから
• 安全なドカン
  • 1日毎、30秒毎とかものによって違うが、順番通りに出ていることが大事
• 非機能的な要件が結構ある

高井

• 月次バッチや日時バッチがドカンになるということですね

質問

• サービスの依存性の把握について
• このサービスを止めたりすると、どこに影響が出るのか把握しにくくなるのでは？

吉川

• Pactが呼び出し関係をグラフィカルにしている
• Trace loggingでリクエストの流れを追ったり、呼び出し元からの流れ

高井

• ソリューションとして出すのか？

大谷

• GoのOSSである
• シミュレーションの段階で予見できるのが大事
• 前のコンポーネントに戻すときにそういうものが大事になる
• dependencyのコントロールするものが必要になると思うが、世の中には浸透してきていない
• 入り口と出口は把握しておく必要がある
• ハンドメイドで大変になっている

佐藤

• Azureは現状では手動管理になってしまっている。
• Service Fabricでも現時点では無いので、今後に期待したい

高井

• 運用者視点のものが多くて、アプリ開発者は気にしたくないが、気にしなくてはいけない

Yet Another Talk on Microservices #microsvc

イベントページ

connpass.com

Microserviceの話

• 難しいのはどの帽子を被るべきか
• アーキテクチャはサービスによって変わっていく
  • 最初から100万人に向けて作るとかは良くない
  • 100万人のユーザーを作る前にチームは解散するでしょう
• 今日の正解は明日の不正解
  • プロダクトに求められる要件は変わっていく
  • 最初から設定を固定化する必要が無い
• そういう意味でこの本は本当に素晴らしい

キラキラネーム現象

• マイクロサービスを行う中でのあるある
  • 好きに名前をつけることができる
  • プロジェクトに愛着もつく
• 今まで務めている会社だとアメリカだとコードネームドリブンになる
• 日本の会社は真面目な名前を付けがち

会話例

• 新人に説明するときに、ドキュメントを読んで勉強してコードを書いて開発すると、質問が生じる
• 先輩に質問すると、「それはFujisanからくるんだよ」「これはRokkousanにPostするんだよ」「それはTsukiが見てくれるんだよ」

Fastlyの場合

• スキー好きなので、一つ一つの山の名前がついたりする

モニタリング

• 全てのサービスはいつフェールしてもおかしくないので、フェールしても大丈夫なようにする

Fastlyでは

• DATADOGを使ってる
• NewRelicを使ってもいる

開発環境

• 人数が増えれば増えるほど、何かが壊れたりする
• かつ柔軟であるようにしなければいけない
• どこにいても開発ができるようにしなければならない

皆さんの日常ってどんな感じ

• 網羅的に全てのパーツに手をいれることはあるか？
• ある瞬間の興味の対象が限られている
• ただし、サービス間の依存関係があったりする
• トラブルシュートをするのはバカらしい

Fastly

• VM上にLXCｓを載せる
• PC内でほぼ本番内の環境ができる
• 開発環境はセットなので、誰かがどこかを変更している
• 更新したらテストが動かなくなったり
• 外部要因によって泣かされる
• 開発環境をメンテしている専門のチームがいる

マイクロサービスとテスト

• correctnessをテストする
• 外部サービスとの連携をテストするのはトリッキーになる
• Rubyの場合、Mochaがあるが、まだ足りない
  • リクエストとレスポンスを取得する仕組みとか
• カセットのデータのメンテが大変
• マイクロサービスは気を使うことが増える
• earlyのサービスはそこらへんも行う必要はない

Testing Resiliency

• そのマイクロサービスはどこで動いている？
  • 開発者にとってはどうでも良い
• モノリシックな場合は別に良い
• Test the extra mile
• よくあるのがネットワーク障害とか、外部要因とのバグ

Shopify

• toxiproxy
• ネットワーク環境を監視できるgem
• これでResiliencyをテストできる
• 色々な通信対象をテストできる
• Building and Testing Resiliency Ruby on Rails

CHAOS MONKEY

• 本番環境でわざと落とすプログラム
• CHAOS ENGINEERING
  • AWSのリージョンを落とした上でサービスがへっちゃらであることを証明する

自転車置き場

• パーキンソンの凡俗法則
• 例えばデータフォーマット
• チームによって考え方が違ったりする
• JSON:APIで解決
  • APIのRESPONCEのスタンダード

Polyglot Environment

• polyglot
  • 複数の言語を使っている
• Fastlyは色んな言語を使っている

Fastlyの歴史

• 既存のCDNに不満があって、自分で作るように
• アメリカで上手く行ったのでイギリスへ
• C言語とPerlが得意言語
• Fastlyの黎明期はC言語とPerl
• 様々なサービスを作ったが、それらを同じ言語で行うのは効率が良くないので、それぞれのサービスで分割して様々な言語に

適切な言語

• マイクロサービスの心理として、適切な言語とテクノロジーを活用することが大事
  • レンダリングするような場所はスクリプト言語とか
• 必然的にマイクロサービスになった

柔軟なデプロイメント

• ロールバックによって自分のコードが本番から一時的に消える（ロールバックに巻き添えを食らう）ことがあるはず
• モノリシックなアプリケーションの一番のデメリット
• システム全体としては迷惑をかけないのでカオスにならない
• Fastlyは各チームでデプロイしている
• 最初はほとんどchefでやっていた

コンウェイの法則

• Fastlyは多い
• その中で分割する

まとめ

• よく考えてアーキテクチャを作ろう
  • アーキテクチャに流行りはない