DevOps時代のテスト自動化カンファレンス 冬の陣 に行ってきた
DevOps時代のテスト自動化カンファレンス 冬の陣 に行ってきた
日時:2014年01月28日 13:00-17:20
場所:秋葉原 富士ソフトアキバプラザ5Fホール
主催:アイティメディア株式会社@IT編集部
https://itmedia.smartseminar.jp/public/seminar/view/572
まとめ
あまりメモ書きの精度がよくないので、まず先にまとめ。
所感
講演された４社中３社が自動化支援ツールのデベロッパー側だったため、自社の導入事例というよりも顧客の自動化に携わってきた経験、また自社製品を利用したプロセス最適化の提案例などコンサル的な視点な内容を聞くことができた。
どの会社の方も自動化を導入することでで得たい最終的な効果を洗い出す長期的な視野と、プロセスとして定着させること（属人化しないこと）の継続性を説いていた。
確かに「Jenkins入れれば最適化できる！」「とりあえず静的解析するようにしたから品質が改善する！」というようななんとなくでの利用が多かったため、単純な自動化スキルよりも改善対象となるプロセスの詳細な問題分析と深い理解が重要だと感じた。
自動化成功の秘訣
目的の明確化、プロセスとしての定着がカギとなる。
目的の明確化
- 現在の課題（欠陥検出率なのか、リグレッション工数、スモーク工数なのか） ＊欠陥検出率の向上を目的としても本質的にはテストケースの低品質なので自動化しても効果がない。
- 退屈かつ単純なエラーをなくす
- システムの信頼度を上げたい
プロセス化に向けたテスト自動化チームの立ち上げ＋プロジェクトリーダーのコミット
* 自動化の専門家を育成（ツール＋専門家）
* メンテナンスできるチーム
* 長期視点で計画を実行できるチーム
テスト工程にかぎらず自動化を行う上で一番重要となるのが、「自動化を導入してどのような効果が得られるのか・得たいのか」を明確する重要性を指摘されていた。
「アジャイル」、「継続的デリバリー」などのように「自動化」も往々にしてバズワードとなる危険性が極めて高い。
「何のためにやるのか」をリードできる人がいないとつまづく自動化することでビジネスのどこにメリットが生まれるのかを明確にしないといけない。
例えば、「テストに時間がかかっている」ならば何が原因で時間がかかっているのか。 そのようなことまで踏み込んでいかないとツールは選べない。
ツールデベロッパーからすると、 ユーザーがツールの導入を目的にしている場合が多い。ロードマップとして、ツールを利用して何を実現したいかをわかっていないことが多い。
そして、一人が自動化を推進・実施しても意味が無い。プロセスにならない個人依存だといずれ廃れてしまう
失敗しないテストツール選びとは
ボトムアップで自動化をすると予算ができない。だからまずOSSで始めるのはいいアプローチだと思う。プロジェクトのプロセスを全て網羅、定着支援をできるのが、 商用ツールのメリット。
２，３人程度の開発テーマならOSSで十分。 しかしメンバーが１０人以上を超える場合や社内標準化を視野に入れると運用コストが増大、商用ツールを利用したほうが（有償サポートがあったほうが）低コストになることが多い。定着支援など総合的なサービスはOSSには無い商用ツールの大きなメリット。
自動化に適したテストの選択
- 複数回行うテスト（回帰テスト）
- クロスブラウザテスト
- 頻繁に仕様が変更されない機能のテスト
- データエントリ系のテスト（入力項目やデータ量が多い）
- パッチリリース時に定期的に行うテスト（リグレッション）
- 演算や計算を伴うテスト（機能テスト。SAPのログインテスト）
以下は各講演のメモ。散文注意。
リクルートSUUMO流DevOpsの捉え方と実践
IT企画部 内田明徳
HWベンダー、SIer、ベンチャーを経験。
リクルートでは、じゃらん・ゼクシィ・SUUMOなど担当。戦後処理のタイミングでアサインされることが多かった。
DevOpsはバズワード。ITサービスのリリースサイクルを加速させる。
落とし穴：開発・運用がともにスピード偏重になる。しかし品質も重要である。
サービスがダウンしてはいけない。セキュリティの脅威も身近になっている。
品質要求が高いシステムにDevOpsは必要ない…？/品質要求が高いシステムにはDevOpsは適用できない？
落とし穴：ツールの導入自体が目的化する
どのツールを選ぶか＜いつ 何のために導入するのか
Solutionはプロダクトアクトではない、課題解決を提案しなければいけない。
課題は環境によって千差万別である。
何の課題を解決するのか？課題の「設定」が重要である。
- エッセンス１：異なる目的をもつ組織間のコラボレーション
- エッセンス２：全ての部門でビジネスの変化に敏感になる
- エッセンス３：開発・運用の見直し
SUUMO流の捉え方
OpsDev。Ops先行ではないのか
OOD。運用を先に考えるべきではないのか
背景：住まいカンパニーの成り立ち
リクルートが事業別に分社化。「住宅事業」部分が住まいカンパニー。
提供サービスはスーモ。住まい探しブランドでは国内最高の認知度。
スマホ・Web・フリーペーパー、書籍、展示場などで情報を提供している。
ネット利用者は930万UU。
リクルートのビジネスモデルはスーモに限らずマッチングサービス。
複雑化したシステム構造
- 情報誌時代は品質重視
- システム統合・拡張を繰り返し、ぐちゃぐちゃ
着任時のIT組織
請負
開発と運用が曖昧
品質よりもスピード重視
だが実態は運用軽視
カイゼンに対する意識が向上し、やっと次のステージに。
トレンド変化１：ITの範囲の拡大。
トレンド変化２：クラウドの浸透
保守のサポート切れに伴う更改が減った
トレンド変化３：小さく出して磨く
世の中からフィードバックを得る
スピードと品質＋変化への対応力が必要！
次世代IT戦略
新標準の作成と移行
xyz構想
既存xからスピード重視のYは継続的デリバリー、クラウド,
品質重視のZはロードマップ開発、おんプレ
サービスライフサイクルマネジメント
計画的に作り直し、徐々に個別ｰ>全体最適に進化させる。
エンハンスを超えたあとは安定保守のためルールの定着。
アナリスト機能の強化
ビジネス目的の分析により、「小さな作り物」で実現する。
自前システムと外部技術の使い分けを行う。
作り方の憲法（Rule of Dev）は出来た。
どうルールを維持、継続していくか（Ops）
Opsの変質に対応する。
Devの現場力学としてのDo。
OpsとしてのCheck.Act。
Dev主体からOpsのありきへ
重要なのはOpsの地位の見直し。Planの際に運用・保守をプランニングすることが大事。
運用設計の進化系
リリース後「どう過ごすのか」が重要になってくるのではないか。
運用というよりも活用といったほうが良い。
DevOpsがくれた気付き
それは文化と向き合うこと。
アメリカのセミナーではカルチャーなどに向き合う内容があった。
日本でもそれは重要だと思われる。
ビジネス変化、IT文化に対応するためにプロセス、組織、構造、ツールなどがある。
まず何に対応するために導入するのかを考えなければならない。
スーモでは
スピード・品質を進化させつために。
ビジネスの変化に対応するために。
DevもOpsも仕組みの背景を理解し一緒に磨く。
個別に工夫する・迷う時間を減らし、お互いクリエイティブな仕事に専念できる。
それがイノベーションの源泉になる。
各社で作りたい文化は異なる。
What, When Whyを議論し、仮説検証するプロセスを回すことで文化は作れる・変えられる。
→DevOpsもAgileに作れる！！
DevOpsが求めるスピードと品質を両立するためのテスト戦略はテスト戦略はどうあるべきか。
日本IBM株式会社 ソフトウェア事業 ラショナル事業部
ソフトウェア・ビジネスにおけるDevOpsの役割
DevOpsの必要性
ビジネスの目標を達成するためにDevOpsが必要。。。だがなぜDevOpsなのか？
「アジャイル」より「DevOps」はお客様から運用・本番までをカバーできる。
迅速に開発する。から迅速に開発・デリバリーする。へ。
DevOpsによるソフトウェアライフサイクル
デリバリーにより、実際にアプリを使った上でのフィードバックが得られる。 フィードバックにもとづき、私情が求めるものを的確にとらえたアプリの開発・運用ができる
DevOpsにおけるテストに求められるものと課題
DevOpsでは以下の問題が顕著になる。
ソフトウェアの品質担保：ビルド数が急増、テストの増大・環境の多様化。結果の評価
テストスピードや効率：計画通りのテスト実施、テスト環境の順番待ち、リリースサービスが完成する前の実施。
テスト資産の効率的な作成・メンテナンス、効率的なテスト環境構築・運用
DevOps時代のテストはどうあるべきか
以下に数多くのビルドをテストするか
効率的なテスト自動化
多様化する環境にいかに対応するか。
環境のバリエーションテストの効率化
- デバイス・OS・ミドルウェアが異なる環境下でのテストを効率的に自動化
テストの待ち時間をいかに短縮できるか
リモートシステム上のサービスの仮想化 * 開発者が自由にテストできる環境の提供。エミュレーション環境の作成。 * 中間層、基幹システム上のサービスの完成前でもテストが可能に。アプリケーション品質向上の早期化で開発期間も短縮できる。
単体テストでの品質が向上する。結合時の障害を削減できる。
テスト資産をいかに効率よく作成・メンテできるのか
- 使いやすい統合開発環境上でコーディングなしでサービスを仮想化。
- 実際のトランザクションを記録してスタブを作成→効率的なリグレッションテストの実施。
- インた～フェース定義ファイルからスタブを作成→新機能テストにも迅速に対応
- 利用可能なリソースを最大限に活用。
- テストに利用可能な実システムとスタブを併用し、必要なデータだけを追加作成
- 実システムによるテストが必要な状況にも柔軟に対応可能。
仮想化システムをはさみ、クライアント側に意識させずに最適な実システム・スタブの切り替えを行う。
テスト環境構築・運用をいかに効率化できるのか
- テストのための設定変更を最小限に。
同じ環境設定えテスト資産作成とテスト実行が可能
proxy設定の変更のみで、スタブのOn/offを簡単に切り替え。
テストにおける課題への対応策一覧。
ソフトウェアの品質担保
数多くのビルドをいかにテストするか？
→効率的なテスト自動化
多様化する環境にいかに対応するか？
→環境のバリエーションテストの効率化（テスト自動化）
テストのスピードや効率の向上
テストの待ち時間をいかに短縮できるか？
→リモートシステム上のサービスの仮想化
テスト資産をいかに効率よく作成・メンテできるか？
→コーディングなしでのサービスの仮想化
→利用可能なテストリソースを最大限に活用（サービスの仮想化）
テスト環境構築・運用をいかに効率化できるか？
→最低限の設定変更によりテスト環境構築・運用時のミスを防止（サービスの仮想化）
DevOps実践のためのテスト戦略
DevOpsのテストにおける課題は「自動化」「サービスの仮想化」により迅速・継続的に対応
ただし。。。
効果が局所的になりがち
リリースが目指すビジネス目標とのつながりが不明瞭。
リリースされるアプリケーションが必要な品質を保つには？
ラショナル使いましょう！
テストの目的
目的は「アプリケーションがビジネス目標を達成できる品質を保つ」ことの確認
その達成のてｍにテスト計画を立案しつつ、チームで共有・実行していく。
テスト計画の立案・共有実行を支援する環境の構築
自動化だけでなく、テストの目的をチームでコミットメントできるようなソフトが必要
その計画を達成するために必要なテストケースの作成、スクリプトの実行、テスト結果のレポート
手動テストもまとめて管理するなど、ビジネス目標を達成するために一元化して全てを管理するソフトウェア
DevOpsがもたらす価値
ライフサイクル全体にDevOpsを拡張することで全体視点からのギャップとボトルネックを解消。
デリバリの加速
フィードバックに迅速・継続的に対応
QCDの最適化。
ソフトウェアライフサイクル全般に渡る「人・文化
コベリティ社内開発チームが挑むテスト自動化と技術革新
コベリティジャパン株式会社
リリースプロセス
一般的なリリースプロセス * 半年おきのリリース * ３ヶ月に次期リリース計画 * リリース直線の６週間の”バードニング”サイクル
リリースを実行するプロセス
- アジャイルプロセス
- 部門横断的なすくらむチーム
- ２週間のスプリント
- メールまたは対面での日時スタンド・アップ
- JIRAとPivotalTrackerを介した進捗管理
- Bugzillaによるバグ管理
- Jenkins-CIによる継続的統合
- 週１回のステータスミーティング
- リリースハードニングでは週に３回
フロントエンドはsalesforceが対応。
デベロップメントテスト
静的解析 手戻りを激減させるテクノロジー
コベリティの製品リリースプロセス
２年前の状況
製品構造概要
インプットされたコードをフロントエンドMdでパースする。
コンパイル後は解析Mdでエミュレーション。
コネクタ（UI）でユーザーに情報提供
２年前のテストアプローチ
フロントエンドと解析のコンポーネントは自動化されたテストでテストされていた。
UI部分が手動テストで行われていた。
- QAプロセスは東ヨーロッパにアウトソース
- 伝統的なQAスキル、開発スキルはわずかもしくは皆無
- 時差
- 言語の壁
矯正への最初の試み
QAと開発の間の境界を取り除く →組織的＋時間的
2011初頭に組織を再編 →開発しながらテストする。ように設定
しかし、結果は期待はずれだった
QAチームはプログラミングに関してトレーニングされておらず、 自動テストを開発するのが困難であった。 時差と言語の壁が存続していた
抜本的な改革 ー人
東欧からカナダ、カルガリーに移動。 →時差は1時間 →サンフランシスから2.5時間のフライト →言語の壁がない
抜本的な改革 ープロセス
テストの自動化に集中する
自動化されたテストにより２つの効果 フィーチャーに期待する挙動の成文化 機能が完成した後のリグレッションの検知
テスト自動化の進捗
UI画面に関しては改造したSelleniumで対応
インフラ
短いテストのほとんどはJenkins上のビルドプロセスの一部として実行 物理100以上、仮想OS200以上でテスト 自社製品を利用して、クリーンコードを維持して自動化
なぜ自動化が進んだのか？
進捗を計測する良い指標が無いことに気づいた →カバレッジはテスト工数に関しては良い指標ではなかった。 →新機能のコードは全体のカバレッジで把握しにくい →開発しながらテストする。ことを牽引する計測可能な基準の欠如
以下のコードに着目した自動テスト開発をガイドする ・新規コード ・リスクの高い部分を特に識別 ・関連の無いコードを除外
コードカバレッジに対するチャレンジ
80%から100%はなかなか進まない
実験
新規のコードと影響を受けるコードにフォーカスしてテストの指標を立てる。 上記の基準だと未テストコードの0.2%しか対象はなかった。
自動テスト開発支援ツール
変更の影響を静的解析ツールの応用で調査。 →優先的にテストすべき箇所を特定
変更の影響解析
社内での経験 ーケーススタディ
1人週で29件のテストを追加→19件のバグを発見できた。 テストを作成した結果、不具合がどれくらい見つかったのかが大事。
インパクト解析を取り入れたテスト自動化ワークフロー
コーディング ユニットテストの作成 コードを解析＋危険箇所にテストを行っているかも確認。 単体レベルで保証。 コードの追加・変更のため、新しいテストが必要かチェック。
まとめ
- クリーンなコードでなければ自動化できない。
- 全てを自動化するのは非現実的
- 高リスク箇所を見極めよ
テスト自動化を成功させる秘訣とは
マイクロフォーカス株式会社
マイクロフォーカス社沿革
現在のITプロジェクトが抱える課題
とくに厳しいのは以下
- 工数の40％が手戻りの作業
これを削減できれば大きなメリットになる。
失敗原因ベスト５
- 顧客のプロジェクトへの関与不足
- 要件定義の不備
- プロジェクトスコープの変化に対応できない
- 変更管理システムの不在
- テストの不備
テスト自動化の動向およびそのメリット
ブラックボックステストにフォーカス
なぜ自動化なのか？ 人手によるテストでは全てのテストを網羅できない。
現在ではテスト回数が多ければ多いほど自動化が必要。今後は必須になる。
テスト自動化を行うメリット
テスト自動化は半年後、１年後を見る必要が出てくる。 未来を見据えるテストが実施できる
テスト自動化によるコスト削減
同じテストが４回以上の場合テスト自動化によるコストが削減される。 １０回テストが行われるプロジェクトでは、トータル約45%の工数削減
テスト自動化の失敗ケース
「方法」での失敗
- リグレッションを１００％を自動化→３割程度で十分（正常系は１００％）
- 手動テストを再現しようとする→スクリプトに頼ることになり変更・メンテに弱くなる
「体制」の失敗
- 担当者の技術不足
- プロジェクト化され、プロセス化に失敗
コードが読めない人がアサインされて失敗
NTTのCOE（自動化専門部隊）
「ツールの選択」の失敗
- ベンダー中心の選択
テスト自動化を成功させる秘訣
目的
- 現在の課題（欠陥検出率なのか、リグレッション工数、スモーク工数なのか） 欠陥検出率の向上を目的としても。。。本質的にはテストケースの低品質なので自動化しても効果がない。
- 退屈かつ単純なエラーをなくす
- システムの信頼度を上げたい
テスト自動化チーム＋プロジェクトリーダーのコミット * 自動化の専門家を育成（ツール＋専門家） * メンテナンスできるチーム * 長期してんで計画を実行できるチーム
一人がやっても意味が無い。プロセスにならないと個人依存だといずれ廃れてしまう
適したテストの選択
- 複数回行うテスト（回帰テスト）
- クロスブラウザテスト
- 頻繁に仕様が変更されない機能のテスト
- データエントリ系のテスト（入力項目やデータ量が多い）
- パッチリリース時に定期的に行うテスト（リグレッション）
- 演算や計算を伴うテスト（機能テスト。SAPのログインテスト）
自動化に際し考え方を切り替える
手動テストは、テスト手順書にもとづいてシナリオを最初から最後まで実行し、 証跡を取得しながら進めていく →いわゆる縦割のテストなので横のつながり（処理）は考えなくて良い
自動テストは、スクリプトの記録工数や再利用性を考えて 共通の画面処理をまとめてスクリプト化する。 →横のつながりを意識してスクリプトをモジュール化し、 それを呼び出すことでスクリプト作成工数を削減できる。
自動化をプロセス化する
プロジェクト化する問題点
- 属人化するとうまくいかない
- 終わりがない
- 開発との連携はテスト自動化の重要な要素
開発プロセスの中に取り入れる。
- GUIアプリ作成時に標準オブジェクトを使用する
- テストケース作成時に手動、自動が判断できる専門家が必要
- テストケースをモジュール化
- スクリプト作成は、オフショア等を活用
- スクリプトを個人管理させずに共有化する。
テスト・ツールの選択
事前評価は必ず行う
テスト自動化ツールは必ずサポートが必要
- 無償ツールなら自社で解決する必要がある
- 有償ツールなら、購入後のテクニカルサポート、FAQサイトが利用可能
- ツールのトレーニングは必須
標準化することになると無償ツールでは対応できない （サポートが必要、トレーニングが必要、全員が一定のスキルを持っていない）
大手企業で自動化を標準化しているところにSelleniumを利用している企業はない。
テスト自動化を成功に導くマイクロフォーカス製品
宣伝
成功事例の紹介ページ
セミナーの案内
パネルディスカッション
テスト自動化にどう取り組むのか
社内文化がない場合は？回答：う
最初は属人化していた。 まずは見える化。市場障害などが漏れた原因分析が大事。 クリエイティブな時間を増やす・品質の統一をできる 属人化とは個人に基準が依存していた、個別最適となっていた機能の知識が属人化。 自動化で「どれくらいの品質でこういうテストの数が。。。」というのが標準が揃ってきた。
体制の重要性・体制化のアドバイス その他３名 まずなぜ自動化をする必要があるのかを明らかにすること。 「何のためにやるのか」をリードできる人がいないとつまづく。 体制の前の意識を持てているかが大事。 自動化することでビジネスのどこにメリットが生まれるのかを明確にしないといけない。
中がどのような要求で出来ているのかを理解していること。 時間がかかる、先を見据えた目標が大事。体制づくり、準備に時間がかかることを予め覚悟しておかないといけない。
だれが始めるのか？運用に入ってからが効果がでてくる。費用対効果がでると実感が出てくる。 NTTは１プロジェクトに４０００万かけて自動化した。でも成功だった。 回帰テストが１６回以上行われることがわかっていたので、開発フェーズから着手した。
自動化するための工数、コストはどうやってクリアしたのか？ コスト効果を計上しても架空の数字になってくことが多い。 まず開発・運用が効果を実感できることが大事。 まず無償ツールなどを利用して「小さく始める」ことで効果を確かめる。
どこをどれだけ自動化すればいいのか？ スーモは２つのポイントがあった。 構造がよく似た特集ページを毎回作るので、そこにsereniumを利用している。 APIの作りから構造化して自動化している。
自動化している人は専門の人がやっている。 マイクロ テスト自動化は専門部隊じゃなくてもできると思う。 開発者がプロセスに自動化を埋め込むことができれば新しいアプローチだと思う。 コベリティ バグを見つけながら。。。というアプローチなので、 毎回レポートを参考にしながらターゲットを絞って行う。
IBMの場合の自動化するポイント データ駆動型はやるべき。コピペミス、手間を考えると。 プラットフォームが多様化しているような製品の場合は自動化がよく効く
バグを指摘されてもPGに響かないような社内文化とは？
バグはかならず入る。ホントはテスター、テストに感謝すべき。 客観的に見る風土、バグと個人を分けて考える風土が大事。 スーモ 開発者がコードを書きたくても本番でバグ多発していて障害対応でいっぱいいっぱいだった。 世の中に出す前に障害を見つけたほうがいい、テストで防げたほうが良いという考え・文化が生まれた。 QA部隊の受け入れテストの基準がうまくできていない。そこも踏み込んで標準化したい。
まずテストケースが重要。 開発者がケースを作成すると必ず漏れが出る。なぜならば要件、外部設計、UIを理解している開発者はあまりいない ファンクションに対しては開発者はできるが、受け入れテストは全体理解をしている人がケースを作成しなければならない。 要件が漏れている、上流設計が甘いと品質が悪くなる
要件を理解しているだけではだめ、どういう実装がされてるか理解できていないと
企画がケース作っても異常系にも漏れがでる。
要件ベースではなく、仕様ベースになっているとその要件と仕様の間に漏れが生まれる。
無料のツールではダメなのか？
目的や状況にもよる。
スタートアップや少人数では無償でいいと思う。
OSSのほうがリッチな機能があるのも事実。
ただ、ロードマップを考えた時には有償のほうが。。。？
定着支援など総合的なサービスは無償ではできない。
IBMが現場に行くと２タイプいる
* 破綻しかけているので教育・コンサル的な部分を含めて導入したい
* 導入考えているので比較したい。
コベリティが現場に行くと。。。
* 静的解析はあまり無償ツールの敵はいない。
性能がいいならば無料でも使いたいだろう。
有償がいいのは、管理面。OSSだとあまり考えられていない。ポイントソリューション
全体のワークフローを考えたときに運用できるのはやはり商用。。。
フォーカスの場合
運用コスト。２，３人ならOSSで十分。
１０−以上を超えると運用コストが一変する。
スーモの場合は
すぐに商用をいれても現場が意味をわからない。
スモールで導入して、商用をほしいというようなニーズが現場に出てからでもいいと思う。
基本的にOSSの使い方はエバンジェリストが頑張ってくれてる
失敗しないテストツール選びとは
ボトムアップで自動化をすると予算ができない。
だからまずOSSで始めるのはいいアプローチだと思う。
プロジェクトのプロセスを全て網羅、定着支援をできるのが、
商用ツールのメリット。
ツールが定着しないパターン
トップダウン、無理やり使っている。現場がの声のでかい人がいうから使う。という状態だと失敗する
現場がしっかりとツールを使う目的、解決したい目的があれば成功する。
道具を導入すること、テスト自動化が目的になってはいけない。
例えば、「テストに時間がかかっている」ならば何が原因で時間がかかっているのか。
そのようなことまで踏み込んでいかないとツールを選べない。
ツールデベロッパーからすると、
ユーザーがツールの導入を目的にしている場合が多い。
ロードマップとしてツールを利用して何を実現したいかをわかっていないことが多い。
Q&A
DevOpsとクラウド、スマートデバイスの関連性は？
クラウドで運用の寿命が長くなっている。
スマートデバイスによって多様化が必要。
そうなると変化につよいDevOpsが関わってくる。
インフラエンジニアがクリエイティブにできるのもDevOps。（chefとかクラウドとかで）
DevOpsが必要な時代になったのは変化が早い、スピードが早いクラウド、スマートデバイス。
ただし、クラウド、スマートデバイスでなくてもDevOpsはできるので。。。
Selenumを使うときはWebドライバで、IDEで使っている人が多いのか？
コベリティ社内ではコーディングしている
スーモもコーディングしている。
ってかこれからの時代QA区の人もコーディングスキル無いとやばいよー
導入するとき
全面的にプロセスにかかわってくるので３年以上の長期的なプロセスを経る。
