『テストプロセス改善技術から探るテストの"改善"とは』参加レポート #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の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を合意する
  • 最小限の領域で提案する
  • みんながハッピーになるようにすることが大切

テスト実行以外の自動化

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

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

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

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

  • リスク駆動型で考える

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

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

  • アップアップの中でやっていくのではなく、できることなら最初から
  • 自動化の仕方を考える前に見える化する仕組みを考えた方が良い
  • 自動化すると不具合がいっぱい見つかる→開発者が不具合の修正にかなり多くの時間をとられる→不具合をスクリーニングする仕組みを考える

  • ISOやJISも読むと良い

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

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

質問

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

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

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

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

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

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

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

はじめに

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

自己紹介

浅黄

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

後藤

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

玉川

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

松尾

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

山口(モデレータ)

Ajenda

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

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

浅黄

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

後藤

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

玉川

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

松尾

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

山口

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

浅黄

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

後藤

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

山口

  • 結構幅広いですね。

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

浅黄

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

後藤

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

玉川

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

松尾

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

浅黄

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

質問

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

松尾

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

techlife.cookpad.com

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

浅黄

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

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

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

浅黄

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

後藤

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

玉川

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

松尾

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

山口

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

後藤

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

玉川

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

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

浅黄

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

後藤

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

玉川

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

松尾

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

玉川

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

浅黄

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

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

松尾

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

玉川

  • アーキテクトになった人のキャリアパスは?(山口)
    • 尖ったところを突き詰める。
      • いまだとラッパー程度だが、ツールを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のイメージとかでできると楽

高井

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

大谷

前阪

  • 最近だとクラウド環境
  • 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を呼んで認証する

高井

佐藤

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

吉川

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

質問

大谷

  • マイクロサービスで分けていくと、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上にLXCsを載せる
  • 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は多い
  • その中で分割する

まとめ

How Microservices are linked at Cookpad 参加レポート #microsvc

イベントページ

connpass.com

スライド

speakerdeck.com

今回離さないこと

  • 包括的な話

今回話すこと

  • 事例をどんどん話す

どんなサービスから構成されているか

  • 粒度も含め
  • 社内で明確なルールが有るわけではないが以下の3つ。
    • ユーザーサービス
    • ビューサービス
    • 共通基盤
  • 1つの事業ドメインだとあまり価値が無いのかもしれない

ユーザーサービス

  • 「料理を通じて=レシピがあれば良い」というわけでない
    • 料理教室とか
    • 特売情報とか
    • 産地直送便を結ぶサービスとか
  • それに特化した独立したサービスを作る
  • ドメインは隣接しているので、他のドメインを使ったりする
  • よくある機能は共通基盤を活用
  • 大事なことは、逆向きになっても良いようにすること

ビューサービス

  • Backend for frontendsに近い
  • バイスごとに専用ビューを作ることはほぼない
  • OEM版で使われたりする

共通基盤サービス

  • UIもあればAPIのみのものもある

連結方法

  • RESTful Hypermedia API
  • クックパッドのモデルは非常に多い
  • 特定の高負荷なモデルが有るわけではない
    • パフォーマンスの最適化よりも柔軟性重視

Garage

Garage Client

  • xxx-clientが無限増殖しないで済む
  • 特定のサービスを使う時の学習コストがかからない

サービス間通信のコスト軽減/耐障害性

Expeditor

  • 基本的な非同期実行や条件付きの非同期実行、サーキットブレイクなどは搭載されている
  • RESTであるユーザーの情報を複数のサービスから集めたいとかに使える

互換性の担保について

  • サービス間連携をどうテストするか
  • Rubyの会社は型を意識することがあまりない
  • 動くものに対してなんとかしようと考えることが多い

CDC Testing

Pact

  • クライアント側がテストを書いてCIで回す
  • Pactファイルを生成してBlocker側に渡す
  • 自身がそれを実装されているか試す
  • WEB Mockにほぼ近い
  • 後は普通にテストを書くだけ
  • テストした後の生成物は中身が出てくる
  • API側は必要な前処理を用意することで、後はPact側が自動的にテストしてくれる

Rack::VCR

  • 以前導入していた
  • クライアント側が意識しなくてもスタブを用意してくれる
  • API側のビルドが高頻度の場合、クライアント側の検知前にリリースされうる

エラーの追跡

Sentry

  • サービスごとのエラーを集約管理している
  • ただし、サービス間のひも付けはできない
  • リクエストIDを採番する
    • Railsはデフォルトで採番している
  • GarageClientがリクエストIDを次のリクエスト先に伝搬すれば良い
  • Sentryでエラーを検索できるようにしている

Docker

  • 巨大なRailsアプリ以外はほとんどDockerになっている
  • プロダクション環境もDocker
  • 環境依存地のみ環境変数として注入
  • アプリケーションリポジトリに入っている
    • poppetではモジュール管理が複雑
      • インフラ関係者しかできない
  • 手元でミドルウェアを増やすとかもできるように
  • 開発者の自由度を上げる

ビルドパイプライン

  • masterにマージ
  • CIでテスト
  • Dockerのイメージ作成
    • assetなども作っちゃう
  • 自動でデプロイ
  • Chatでデプロイを実行する

Hako

  • デプロイ管理
  • 以前はインフラメンバや基盤メンバが細かく設定を書いていた
  • アプリケーションごとの設定はYAMLで管理

etcenv/etcvault

  • etcdで設定値を管理
  • 特定のカギを持っているインスタンスでしか復号できない

Chat ops

  • Hubotでdeploy
  • 裏ではRundeckで管理
  • デプロイコマンドはアプリケーションに特化しているのでRundexkで管理
  • 基本、Hubotで言えばdeployできる形で統一

バッチジョブ

kuroko2

  • Jobのワークフローの管理
  • 全サービスのJobを一括管理
  • フックして別サービスをKickする
  • サービスの最新のDockerイメージを実行するように
    • 以前だと、ワーカーでサービスごとの構成管理をしていたので、Kuroko用とワーカー用のアプリケーションで管理を別々にしなくちゃいけなかった

組織的な話

技術領域課題共有会

  • 名前とは違い、ざっくばらんな話し合い
    • こういうコマンド毎回打つのだるい
    • ドキュメントどこー
    • 技術的にこのやり方は…
    • こういうのがあったら使う?
    • こういうのまだ使ってる?
      • メンテコストが高くならないように
  • 感覚値がチームによって違うことが把握できる

技術基盤担当

  • 技術基盤に余力があるか、経験のある人がいるかどうかがチームによってバラバラになりがち
  • サービスが大きくなると、どういう基盤があるか分からなくなりがち
  • 各チームに専任の技術基盤担当がいるようにする
    • MTGに参加したり
    • カジュアルな相談に答えたり
    • 必要に応じてガッツリ入ったり

『マイクロサービスアーキテクチャ』とAzure Service Fabric 参加レポート #microsvc

イベントページ

connpass.com

スライド

docs.com

自己紹介

Microservices

  • Microserviceの言葉が出来たのは2011年5月
  • James LewisやMartin Fowler
  • Netflixなどが初期から採用
  • 日本ではクックパッドが初期に採用
  • Sam Newmanが2015/02に書いた
  • ガートナーのテクノロジートレンドにも登場

目次

  • 5章
    • モノシックなアプリをマイクロサービスへ
  • 6章
    • デプロイをマイクロサービスへ
  • 7章
    • テスト
    • E2Eテストをどうするか
    • プロバイダが変わった時にどうすれば
  • 8章
    • 監視の話
    • 複数のアプリへ行く時にどうまとめるか
  • 9章
    • セキュリティ
  • 10章
  • 11章
    • スケーリング
    • 障害について
    • 障害を隠蔽して全体のサービスをストップさせない
  • 12章

マイクロサービスの原則

www.slideshare.net

ModelledAroundBusinessDomain

Automation

  • 最初の3ヶ月は2つ、1年で10個、18ヶ月で60個に
  • どんどん自動化対象が増えていく

HideImpression

  • 実装の隠蔽を行おう
    • 悪い例
      • 同じDBにアクセスしてしまう
      • スキーマの変更が複数のサービスに影響を与える
    • 良い例はサービスの連結をする
  • 顧客とか製品とか、コンテキストが違うので、別々に持ちましょう
  • RDBの共有はやめましょう

分散

  • 全てのものを分散させましょう
  • 人々に自由を与えましょう
  • プログラミング言語・開発スタイルなどなど
  • GILT社は横軸が時間軸、リリース回数が右肩上がりであることが分かる

DUMB-PIPE, SMART ENDPOINTS

  • SOAはデータ管理などをパスで賢くする
  • マイクロサービスはMQのみ

Deploy Independently

  • サービスをどのようにデプロイするのか
  • HOSTあたり一つのサービスを進めている
  • サービスが2つあるときに、InventoryサービスからShippingExpectationsに沿って行っているかテストしましょう
  • コンシューマ駆動契約
  • Pact

Consumer First

  • SWAGGERを使ってサービスのドキュメントをAPI

SERVICE DISCOVERY

  • Hashcorpなどを使おう
  • HumaneRegistry
    • Wikiとかも使って

障害

  • 障害のシナリオ
  • Strangler App
    • レガシーアプリを一気に引退させるのではなく、インターセプトしてあげて行うのがStrangler Pattern
  • リクエストが全部落ちましたとかいう例の話
    • 徐々に速度が遅くなる障害があるアプリで発生
      • スレッドプールが全てそのアプリに
      • クライアントからのリクエストがいっぱい
    • タイムアウト時間を適切にした
    • スレッドプールを各レガシーアプリに持たせる
      • Bulkhead
    • 激しく遅くなるとリクエストしないようにする
    • 時々確認して正常になったらまたリクエストを送るようにする
      • Circuit Breakers

AGGREGATION

  • Elastic serachをする
  • 複数の場所にあったりするのをまとめよう

Azure Service Fabric

  • 今日時点ではプレビュー
  • クラスタ組んでる
  • Stateless and stateful
  • Replicationしつつ
  • 自動的に分散配置してくれる
  • アプリケーションのVersionUpにも使う