アジャイルとDevOpsの品質保証と信頼性
このブログエントリは日本信頼性学会論文誌 Vol.42, No.2, 2020年3月号に寄稿した「アジャイル/DevOps開発における品質保証と信頼性」という解説論文の転載です。
(品質管理研究会でこの解説論文の内容をもとにした特別講義を来年実施します。ご興味ある方はぜひご参加ください。)
---
概要
1.はじめに
ソフトウェア開発の国際競争力強化のため,アジャイルやDevOpsなどのソフトウェア開発手法を導入するチームが増えている1).顧客のフィードバックにもとづいて機能開発を反復するアジャイル開発や,クラウドや自動化などによりソフトウェア開発プロセス全体の生産性を改善するDevOpsを導入することで,グローバルでのビジネス環境の変化に素早く対応可能なソフトウェア開発が実現できることが知られている2) 3).
アジャイル/DevOpsを導入するチームが増えている一方で,アジャイル/DevOps導入について品質面での懸念を抱えているチームも多い.アジャイル/DevOpsには品質保証に関する手法が一見すると少ないため,アジャイル/DevOpsは品質を軽視しているとの誤解が少なくない.また今まで慣れ親しんだウォーターフォールと考え方が異なるため,ウォーターフォールで培った品質保証や信頼性の知見をそのままアジャイル/DevOpsに適用することは難しい場合もある. アジャイル/DevOpsを効果的に導入するためには,その特徴にもとづいて実施していくことが重要である.
アジャイル/DevOps開発の特徴は,分割されたスコープに対し短い開発サイクルの中で小刻みなフィードバックループと改善活動を繰り返すことである.そのためQAテストとしての品質保証の役割は依然重要であるが,収集可能なメトリクスの特徴は異なる. また開発サイクル全体を見通し素早くテストを実施する必要があるため,自動テストやプロセスの品質を適切に設計し自動化していくことが重要となる.さらにテストの実施時期を前倒し/後ろ倒しすることで,開発から運用までの一連のプロセスの中で継続的にテストを実施しフィードバックを獲得する. またアジャイル/DevOpsの信頼性では,レジリエンスエンジニアリングと共通する考え方が多い.
本稿では,アジャイルからDevOpsへの発展の流れを述べた後,その特徴について特にウォーターフォールとのプロセス面での違いを述べる.次にアジャイル/DevOpsにおける品質保証と信頼性の特徴として,①QAテストとメトリクス,②素早いテストと開発サイクル,③継続的なフィードバックと④レジリエンスの4つを挙げ,それぞれの特徴について事例を交えながら解説する.
2.アジャイルとDevOpsの発展と特徴
2.1 アジャイル/DevOpsの発展アジャイル開発は,90年代後半に出てきたスクラム,XP(Extreme Programming),などの手法の提唱者たちにより,2001年にアジャイル宣言が書かれて生まれた2).日本においては2000年代後半より普及し始め,日次ミーティング,ふりかえりなどのスクラムの手法や,単体テスト自動化,継続的インテグレーション(CI)などのXPの手法の適用率が高い1).
アジャイル開発はその後,XPのCIなどの手法がクラウドなどの運用面の自動化技術と融合し対象領域を運用へと広げていく中で,継続的デリバリーそしてDevOpsへと発展していった3).その過程で,トヨタ生産方式(TPS)を源流とするリーン開発の影響も受けており,開発から運用までのプロセスを自動化によって改善することがDevOpsの1つの主目的となっている.ソフトウェア開発のプロセスでは,開発,品質保証,運用が別のチームによって分業されることが多かったが,これらの組織をまたいだプロセス改善のため特に大企業が積極的に導入している4).
2.2 アジャイル/DevOps開発の特徴
アジャイル開発の特徴は,要求(スコープ)を分割し,少しずつ素早い開発を繰り返し実施していくことである2).ウォーターフォールではソフトウェア開発工程を分析,設計,実装,テストの順に開発する.そのため,プロジェクトが終了するまで動くソフトウェアが完成しない.一方アジャイルでは要求を分割し,2週間から3ヶ月程度の短い開発サイクルを繰り返しながら徐々に開発していく.そのため,動くソフトウェアを徐々に積み上げていくことができる.開発期間を通し,動くソフトウェアに対する顧客のフィードバックをもとにした改善活動が可能になる2).
DevOpsでは品質保証や運用も対象にして,アジャイルよりもさらに短い開発サイクルを繰り返す4) 5).これはDevOpsがトヨタ生産方式(TPS)を源流とするリーン開発の影響を受けていることも理由の一つとして考えられる.「10+ deploys per day」の言葉に代表されるように,一日に何度も品質保証や運用作業を実施する.短い開発サイクルの中で,単体テストや受け入れテストのテスト結果や,運用作業やリリースの結果を小刻みにチームにフィードバックすることで,アジャイルの改善活動をより効果的にする.
3.品質保証と信頼性の特徴
ここまでみてきたように,アジャイル/DevOps開発には
- 分割されたスコープ
- 短い開発サイクルの繰り返し
- フィードバックループにもとづいた改善活動
の3つの特徴がある.
これら3つの特徴は品質保証や信頼性にも影響するため,アジャイル/DevOpsでは品質保証や信頼性においてもウォーターフォールとは異なる考え方が必要になる.もちろん品質保証自体はアジャイル/DevOpsでも重要であり,ソフトウェア品質の評価メトリクスやテスト自動化の技法などではウォーターフォールと共通で活用できる手法も多い.一方で,特に短い開発サイクルでフィードバックを繰り返すプロセス面での違いは顕著であり,アジャイル/DevOpsでは大きく考え方が変わっている.
アジャイル/DevOpsでの品質保証と信頼性についてウォーターフォールとの比較を
- ①QAテストとメトリクス
- ②素早いテストと開発サイクル
- ③継続的なフィードバック
- ④レジリエンス
の4つの特徴から紹介する.
特徴①: QAテストとメトリクス
アジャイル/DevOpsでも,ウォーターフォールと同様にQAテストとしての品質保証の役割は依然必要となる5).短い開発サイクルを繰り返すアジャイル開発では製品出荷の頻度が多くなるため,品質保証チームがQAテストの結果にもとづきしっかりとした出荷判定をしないと,不具合の市場流出のリスクが高まる.
ただしアジャイル/DevOpsでは現場の課題の見える化をメトリクス活用の主目的としていたり,収集可能なメトリクスの特徴がウォーターフォールと異なっていたりするため,メトリクスの取り扱いには注意が必要である5) 6).
特徴②: 素早いテストと開発サイクル
アジャイル/DevOpsは短い開発サイクルを繰り返すため,品質保証も短期間,高頻度での実施が求められる.そのため品質保証の生産性の改善活動がアジャイル/DevOpsの重要な要素の一つとなる4).自動化を通し,テスト実行やテストレポートなどのテスト工程をソフトウェア化することで,品質保証が素早く実行可能になる.
また,さらに短い開発サイクルのDevOpsでは,実装工程と運用工程をつなぐ品質保証はボトルネックになりやすい7).アジャイル/DevOps開発では,品質保証工程が詰まるとバグ修正や運用作業で待ち時間が発生し,開発工程全体に影響を及ぼしてしまう.実装工程や運用工程を含めた品質保証工程のソフトウェア化による生産性の改善が必要となる.
特徴③:継続的なフィードバック
アジャイル/DevOpsにおける品質保証活動では,チームに対する継続的なフィードバックを重視している8).顧客のフィードバックと同様に,テストや本番稼働中のシステムからのフィードバックにもとづいた改善活動を,プロジェクト期間中継続して実施する.
継続的なフィードバックは品質保証活動を前倒しする「シフト・レフトテスト」と,後ろ倒しする「シフト・ライトテスト」に分類することができる9). 「シフト・レフトテスト」では品質保証活動の一部を開発の初期から開始しバグの情報などを適宜フィードバックする.また「シフト・ライトテスト」には本番稼働中のシステムで新旧異なるバージョンのソフトウェアをユーザーに実際に使用してもらい比較する「ABテスト」などの手法が含まれる.
特徴④: レジリエンス
アジャイル/DevOpsの信頼性では,レジリエンスエンジニアリングと共通する考え方が多く,監視や対応,学習のためのフィードバックを重要視する傾向がある.シフト・ライトテストに含まれる「カオスエンジニアリング」や「カナリアリリース」は本番稼働中のシステムからシステム障害について継続的にフィードバックすることで,システム障害について組織的に継続的な学習することや,迅速な検知と対応の枠組みを提供する9).
次章からはこれら4点の特徴についてそれぞれ詳細な解説と事例の紹介をする.
4.QAテストとメトリクス
4.1 QAテストとしてのアジャイル品質保証
アジャイル/DevOpsにおいてもQAテストとしての品質保証の役割は依然重要となる.アジャイル/DevOpsでは短い開発サイクルを反復するため製品出荷の頻度がウォーターフォールに比べ多い. 品質保証チームがQAテストとしての役割を確実に果たさないと,不具合が市場に流出するリスクが高まってしまう.アジャイル開発向けの品質保証の枠組みとして,スクラムに受け入れテストと品質テストを組み込む「QA to AQ」というパターンが提案されている10).
アジャイル開発の導入では生産性の向上が期待される一方,品質が低下するという懸念もあるが,アジャイル開発でも十分な品質保証を実施していることを示している事例もある.
NECの事例では,スクラム,XPとウォーターフォール向けの品質管理技法である品質会計を組み合わせることで,出荷後バグを発生させないことを達成している11).この取り組みでは,スクラムのスプリントレビューでのスプリント完了基準に基づく完了評価とスプリント中の品質管理技術者による品質確認を中心とした軽い仕組みによって,開発工数も1/2程度に改善している.
筆者のチームでは,アジャイルプロジェクトでシステムテストを全面的に自動化する際に,ウォーターフォールで培われた品質評価のメトリクスであるテスト密度,バグ密度によって評価した12) 13).IPAの提供する業界標準と比較することで,ウォーターフォールで実施されている品質保証と同程度のテストを自動化できていることを確認した.6章で詳述するが,この事例ではバグ修正にかかる日数を5日から2日へと60%削減している.
4.2 アジャイル品質保証のメトリクス
アジャイル開発では,コードカバレッジ(ソースコードに対するテストの網羅率)や欠陥数などウォーターフォールと共通のメトリクスがある一方,独自のメトリクスも提案されている.ストーリーポイント,ベロシティなどはアジャイル独自のメトリクスである5).
アジャイル開発でのメトリクス活用の主な目的は,プロジェクト管理ではなく現場の課題の見える化と改善活動の促進である6).例えばバグメトリクスを時系列で見える化することでプロジェクトの後半で多くのバグが検出されていることに気づき,テストの網羅率の向上などの改善活動に繋げることができる.また品質ダッシュボードはコード品質を見える化することでチームがコード品質を保つことをサポートする5).これらのメトリクスによる見える化は,6章で詳述するチームへのフィードバックであり改善活動を促進する.
アジャイル開発では短い開発サイクルを繰り返すため1回の開発サイクルの中では対象となるデータ量が少なく,メトリクスのバラツキが大きくなる.そのためチームをまたぐような標準適合度合いの評価などでは統計的な分析手法が使いにくい5).
その一方で,アジャイル開発では開発サイクルを繰り返すため,時系列のメトリクスを開発サイクルにまたがって測定することが可能になる7) 12).そのためチーム内の開発サイクルをまたいだ変化についての統計的な分析がアジャイル開発では得意である.
アジャイル開発では,ウォーターフォールで培われた品質保証の技術をそのまま適用できない場合もある.ウォーターフォールの出荷判定で利用される信頼度成長曲線は,品質保証期間中にソースコード変更がないことを前提として収束する特徴を持つが,アジャイル/DevOps開発ではソースコード変更と品質保証が並行して実施されるため収束しない12).
5.素早いテストと開発サイクル
5.1テストのソフトウェア化による素早いテスト
アジャイル開発では短い開発サイクルを繰り返すため,品質保証も短期間,高頻度で実施することが求められる.自動化などを活用し,テスト要求分析からテストレポートまでの一連のテスト工程を素早く実施する.
テスト自動化はテストの実行時間を短縮するための一般的に知られた手法である.アジャイル開発では単体テストから受け入れテストまで異なるテストレベルのテストを自動化する.ただし,アジャイル/DevOps開発では繰り返し自動テストを保守したり実行したりするため,ソフトウェアとしての自動テストのアーキテクチャ設計も重要となる14).
自動テストの実装は手動テストに比べより多くの時間やコストがかかることが指摘されている6).特にテスト自動化を始めたばかりの組織や,繰り返し開発における自動テストコードの保守ではより多くの時間がかかる.そのため,振る舞い駆動開発やデータ駆動テストやなどの手法を用いてテストの習得性や保守性を適切に設計することが重要である14).
また,毎回異なるテスト結果をもたらすFlakyテストは,テスト実行のたびにテスト結果を人間が確認する手作業を生じさせるためテストの生産性に悪影響を及ぼす14) 15).並行して実行するテストの相互干渉を防ぐためのテストシナリオやテストデータの独立性,テスト環境起因の問題を解決するためのテスト環境の信頼性,テスト結果調査のためのエラー追跡性などの自動テストの品質をソフトウェアとして作り込むことでFlakyテストによるテスト実行の効率悪化のリスクを軽減することができる.
近年では,単純な定型作業であるテスト実行だけでなく,今まで人間が行なっていたテスト設計やテスト結果の確認などの知的活動が必要な作業のソフトウェア化も,機械学習やAIを活用することによって進められている15) 16).
5.2 DevOpsでの開発サイクル全体のソフトウェア化
アジャイルよりさらに短い開発サイクルを繰り返すDevOpsでは,品質保証工程の改善はより大きな意味を持つ.特にDevOpsの場合,品質保証はDev(開発)とOps(運用)をつなぐ位置に存在するため,品質保証単独ではなく開発プロセス全体を見通したプロセスの改善とソフトウェア化が重要となる.
DevOpsではプロセスの分析手法として,リーン生産方式の技法の一つであるバリューストリームマッピングが知られている17).バリューストリームマッピングはTPSで使われていた手法をもとにしており,開発や品質保証などのステークホルダー全員でプロセスを可視化し,プロセスに潜むムダを見つけ出す.特にチーム間でのタスクの受け渡しや承認が必要な部分に手作業や手待ちのムダが存在することが知られている4) 17).
また,筆者のチームでは,開発,品質保証とDevOpsチームにまたがるプロセスのムダをQC七つ道具により分析し,ソースコード変更後から出荷までの一連の手作業とテストを自動化することで解決した7).この事例ではテスト環境への不具合流出が原因で,品質保証チームの生産性だけでなく実装やバグ修正などの開発チームの生産性まで下がっていた.特性要因図,散布図などのQC七つ道具を利用し根本原因を特定し,出荷やテストなどの手作業を自動化した.その結果,障害件数を66%,バグ修正日数を80%削減した.DevOpsでの自動化は,手動で実施していたプロセスのソフトウェア化に他ならない.プロセスに求められる品質をソフトウェアの品質特性として設計,実装することで開発サイクル全体の生産性を改善する.
バリューストリームマッピングとQC七つ道具はどちらも日本の製造業に源流があるプロセス改善の手法である17) 18).DevOpsの場合,ウォーターフォールと比べむしろこれらの手法との相性は良い7).1つ目の理由は,DevOpsによってソフトウェア開発は製造業と同じように定型的な工程を何度も繰り返すようになったことである.品質保証の実施頻度が少ないウォーターフォールに比べプロセス全体の最適化のインセンティブは高い.また,前述の通りDevOpsではプロセスのメトリクスが開発サイクルをまたいで測定できるため,時系列では分析対象のデータが多くなり統計的なプロセス分析手法を適用しやすい.
6.継続的なフィードバック
アジャイル/DevOpsでは,開発サイクルを通し小刻みなフィードバックを獲得するための手法が数多く提供されている9).これらの手法はテストの観点から継続的テストと呼ばれており,開発の早期の段階からフィードバックを獲得するための「シフト・レフトテスト」と,本番稼働中のシステムからもフィードバックを獲得するための「シフト・ライトテスト」によって構成される.
6.1 シフト・レフトテスト
テスト活動を前倒しする「シフト・レフトテスト」では,品質保証活動の一部を開発の初期から開始することで,プロダクトの改善やバグ修正に必要なフィードバックを開発の早い段階から獲得する8).そのためフィードバック獲得の仕組みを適切に設計することの重要性が指摘されている8) 19).
三菱電機の事例では,プロジェクトの初期からフィードバックを獲得したいGUI部分の開発にアジャイル開発を適用している19).フィードバック獲得について「誰から?」「どんな?」「どうやって?」を事前に設計することで,インターフェースの矛盾やユーザビリティ,システム仕様の不整合についてのフィードバックを早期に獲得することに成功している.
「シフト・レフトテスト」の中の継続的インテグレーション(CI),継続的デリバリー(CD)などの手法は,既存機能を壊すバグであるリグレッションバグを早期に発見,フィードバックするための仕組みである.自動化したテストを日次などのペースで継続的に実行することで, リグレッションバグに関する小刻みなフィードバックを実現する.そのため,開発者はリグレッションバグやバグ修正の結果をソースコード変更直後に知ることができる.
筆者のチームではシステムテストを自動化する継続的システムテストを導入した12) 13).継続的システムテストでは自動化したシステムテストを毎日継続して実行しテスト結果をフィードバックする.そのため4章の図4で示すように,システムレベルのリグレッションバグを開発期間中も継続して発見することができる.実装を終えソースコード変更をレポジトリに追加した翌日に混入されたバグのフィードバックを得られるため,特にバグ修正の期間を改善することができる.筆者の事例ではバグ修正にかかる日数を5日から2日に改善した.
6.2 シフト・ライトテスト
テスト活動を後ろ倒しする「シフト・ライトテスト」では,リリース以降の本番稼働中のシステムからもフィードバックを獲得する9).レジリエンスと関係の深い「カナリアリリース」と「カオスエンジニアリング」は次章で詳述するため,ここでは「ABテスト」と「モニタリング」を紹介する.
「ABテスト」では,本番環境の実ユーザーに2つのバージョンのアプリケーションを使用してもらい,クリックや商品の購入といったユーザーの実際の行動につながったかを示す顧客転換率(CVR)などを比較する.ユーザーインターフェースのユーザービリティやゲームの甘美性など主観的な評価が大きな割合を占める分野で特に利用されている.
「モニタリング」では,本番環境から得られたメトリクスをフィードバックとして機能やシステム拡張計画を改善する.開発した機能はリリース後,要求分析の際の事前の想定とは異なる使われ方がされることがある.想定と実際の使われ方のギャップから,次に開発したり改善したりする機能を分析する.システム拡張計画も想定とのギャップが出やすいため,リソース使用率などから適宜改善する.
7. レジリエンス
アジャイル/DevOpsでは,信頼性の中でも特にレジリエンスを重要視する.レジリエンスでは,「予測」「監視」「対応」「学習」の4つの基本能力からなる枠組みで,障害などの事象から学ぶ組織を設計する20).短い開発サイクルの中でのフィードバックを重要視するアジャイル/DevOpsでは,特に障害についての継続的な学びを実践するシフト・ライトテストの中にレジリエンスの考え方と共通するものがある.
7.1 カオスエンジニアリング
カオスエンジニアリングでは,障害を引き起こすようなテストを本番環境で意図的に実施する9).長期間障害が発生しないと,そのこと自体は喜ばしいが,障害に対する能力を組織が忘れる弊害が生じる.そうすると,いざ障害が起きた時に検知したり復旧したりといった迅速な対応ができなくなってしまう.本番環境で意図的に障害を引き起こすようなテストを継続的に実施することで,障害の検知方法や復旧方法について定期的にフィードバックを獲得,学習することができる.
DevOpsではシステムアーキテクチャを,すべての機能が単一のシステムとして設計されるモノリシックなものから,小さい多数のシステムへ移行するマイクロサービス化が進められている21). モノリシックなシステムの場合,障害影響範囲はシステム全体におよびやすいが,マイクロサービスでは障害の影響範囲をシステムの一部に限定することが可能になる.こういったシステムの耐障害許容性をカオスエンジニアリングはテストする.もし問題が見つかった場合は設計にフィードバックし改善する.
7.2 カナリアリリース
カナリアリリースは,シフト・ライトテストのもう一つのレジリエンスの仕組みである.新旧2つのバージョンを本番環境で稼働させ,新バージョンに徐々に移行しながら新バージョンに問題がないかどうかフィードバックループを回しリリースする9).
カナリアリリースでは新バージョンに徐々に移行するため,新バージョンに問題があった場合の影響範囲を限定できる.システム全体を一度にリリースするとユーザー全体に影響を及ぼしてしまうが,小規模なユーザーから徐々に新バージョンをリリースすることでフィードバックを獲得し,問題があった場合の影響範囲をコントロールする.
カナリアリリースの名前には「リリース」とついているが,本番環境でのテスト手法として捉えることができる.テスト環境では環境の制約が原因で実施が困難なテストを限定的な影響範囲の下,本番環境で実施していると考えられる.そのため一般的なテストと同様に, カナリアリリースの最中に監視する項目をリストアップし,それぞれの監視項目の期待される値を定義する.カナリアリリースの最中は実際の値と期待される値を比較し,パスすればその移行工程を終了し次の移行工程へと進む.
筆者の組織では,ビジネス上クリティカルなユーザーシナリオの成功率やシステムレスポンスの遅延などを監視項目として定義し,リリース中に監視している.筆者の組織ではカナリアリリースを導入することで,システム全体に影響を及ぼす深刻な障害だけでなく,限定的な障害も削減することができた.カナリアリリースの監視項目の定義と監視を通し本番環境のシステムの振る舞いを学習することで,バグの作り込みそのものを減らすことができる.
8. おわりに
本稿ではアジャイル/DevOpsの品質保証と信頼性について特徴と事例を紹介した.アジャイル/DevOpsでは短い開発サイクルを繰り返し,フィードバックによる改善活動を促進する.そのため,依然QAテストとしての品質保証は重要であるが,それに加えて,開発サイクル全体を見通した素早いテストの実施や,開発サイクルの早期から本番稼働環境までを含めた継続的なフィードバックループの獲得が重要である.アジャイル/DevOpsを通した日本のソフトウェア開発競争力のさらなる向上を期待する.
参考文献
- (独) 情報処理推進機構:アジャイル型開発におけるプラクティス活用事例調査 調査概要報告書(2013. 03)
- 平鍋健児:変化を味方につけるアジャイル開発, SEC journal,11,No.3, pp.22-25(2016. 03)
- 榊原彰:開発と運用の融合-DevOpsの波-, IBM PROVISION, No.75, pp.26-31 (2012. 10)
- 川口恭伸ら:楽天でのエンタープライズアジャイルとDevOps -Dev/Test/Ops 三位一体の自動化-, 情報処理学会デジタルプラクティス, Vol.7, No.3, 243-251(2016. 07)
- 誉田直美ら:アジャイル品質保証の動向, SQuBOK Review 2016, Vol.1, pp.1-10 (2016. 09)
- 荻野恒太郎:楽天のアジャイル開発とメトリクス事例,SQiP 2016, E2 講演&パネルディスカッション資料(2016. 09) https://www.slideshare.net/kotaroogino/sqip2016 (2020年01月06日現在)
- 内藤史郎ら:QC七つ道具を利用したDevOpsプラクティスの導入による開発とテストの生産性改善, SQiP 2019, C1-1(09)
- 永田敦:プロダクト部門での品質保証担当の振る舞い アジャイル開発の場合, JaSST `16 Tokyo, C5-1 (2016. 03)
- 辰巳敬三:ソフトウェアテストのニューノーマル~テストの新たな常態・常識~, VERISERVE NAVIGATION, Vol.13, pp.06-11 (2018. 03)
- Joseph W. Yoder el:QA to AQ -Patterns about transitioning from Quality Assurance to Agile Quality-, Asian PLoP 2014, (2014. 03)
- 誉田直美:俊敏さを実現する新しい情報システム開発―エンタープライズアジャイルを中心にー, 情報処理学会デジタルプラクティス, Vol.7, No.3, 218-225(2016. 07)
- 荻野恒太郎:継続的システムテストについての理解を深めるための開発とバグのメトリクス分析, SQiP 2014, A1-3, (2014. 09)
- 荻野恒太郎:安心なサービスの品質改善を実現するための継続的システムテスト, 15-B-11先進的な設計・検証技術の適用事例報告書2015年度版(2015. 11)
- 荻野恒太郎:“素早い”テスト実践法, 日経SYSTEMS, 2017年8月号, 特集2 pp.50-57 (2017. 07 )
- John Micco: Advances in Continuous Integration Testing @Google, JaSST `18, A0, http://jasst.jp/symposium/jasst18tokyo/pdf/A1.pdf(2020年01月06日現在)
- Tariq King: AI-Driven Testing a new era of test automation, JaSST `19, A0, http://jasst.jp/symposium/jasst19tokyo/pdf/A1.pdf(2020年01月06日現在)
- 牛尾剛:日本のDevOps変革を促進するバリューストリームマッピング, https://gihyo.jp/dev/column/01/devops/2017/value-stream-mapping,(2020年01月06日現在)
- 安達賢二ら:日本におけるソフトウェアプロセス改善の歴史的意義と今後の展開, SQuBOK Review 2016, Vol.1, pp.11-24 (2016. 09)
- 細谷泰夫:斥候としてのアジャイルプロセス活用の提案, SPI Japan 2012, (2012)
- 小松原明哲:個人と組織のレジリエンスを高める, 人間工学, 2013年49巻Supplement号2S1-1, pp.S58-S59, (2013. 06)
- レン・バスら:DevOps教科書, 日経BP社 (2016. 06)
個人の経歴2019年バージョン
講演・執筆活動
カンファレンス講演等(日本)
- QC七つ道具を利用したDevOpsプラクティスの導入による開発とテストの生産性改善 (SQIP2019)
- 「アジャイル・テスト自動化導入の勘所」(特別講演 JaSST'Tokai 2018)
- 「アジャイル・自動化時代のテストの現場のリアル」(クロージングパネル モデレータ)(JaSST'Tokyo 2018)
- 「アジャイル開発におけるメトリクスの活用 (パネルディスカッション) 」[発表スライド](SQiP 2016)
- 「DevOpsから見たテスト自動化と価値の見える化」(JaSST' 関西 2016)
- 「三位一体の自動化で壊せDevとOpsの壁」(デブサミ2016)
- 「継続的システムテストについての理解を深める為の開発とバグのメトリクス分析(再演)」(SQiP 2015)
- 「継続的システムテストについての理解を深めるための開発とバグのメトリクス分析」(SQiP 2014)
- 「システムテストの自動化による大規模検索プラットフォームの開発工程改善」(JaSST' Tokyo 2014)
カンファレンス講演等(国外)
執筆関連
- 「QC七つ道具を利用したDevOpsプラクティスの導入による開発とテストの生産性改善」【共著】(経験論文 SQiP 2019)
- 「変革の軌跡 世界で戦える会社に変わる"アジャイル・DevOps"導入の原則」へのDevOps事例「楽天のDevOpsエンジニアのストーリー」の寄稿 (2017)
- 「楽天でのエンタープライズアジャイルとDevOps」(情報処理学会デジタルプラクティスVol.7 2016)
- 「安心なサービスの品質改善を実現する為の継続的システムテスト」(IPA 先進的な設計・検証技術の適用事例報告書2015年度版)
勉強会での発表
- 「データとQC7つ道具を利用したDevOpsプラクティスによる生産性改善」(楽天テックミートアップ#2 データで切り拓くソフトウェア品質の未来 ,【共著】,2019)
- 「人事がDevOps研修を作っちゃった話~恐れ知らずのブルドーザー改革~」(DevOps Days Tokyo 2019)
- 「~ilities Test Automation」(ICST2017 Unofficial Meetup 【共著】, 2017)
- 「オフショアテストチームが、テスト自動化チームとして生まれ変わった物語」(第4回Seleniumユーザーコミュニティ勉強会, 2016)
- 「楽天の品質改善を加速する継続的システムテストパターン(再演)」(エンタープライズ勉強会 2016年2月セミナー)
- 「楽天の品質改善を加速する継続的システムテストパターン」(システムテスト自動化カンファレンス2015)
- 「Rakuten and Microsoft talk DevOps in Real World 」(楽天テクノロジーカンファレンス2015)
- 「誰がテスト自動化をするべきか?」(楽天テックカンファ前夜祭, 2014)
- 「継続的システムテストについての理解を深める為の開発とバグのメトリクス分析(再演)」(第21回カフェソフトウェアクオリティ, 2014)
- 「Data Driven Development」(システムテスト自動化カンファレンス2013 LT)
- 「リーンキーワード駆動型漫才」(DevLove現場甲子園2013完結編)
- 「Software Engineer in Test @ 楽天の検索基盤開発の現場」(DevLove現場甲子園2013)
- 「検索基盤開発のための結合テスト環境の自動化」(第6回テックヒルズ, 2013)
勉強会企画
- 楽天テックミートアップ#2 データで切り拓くソフトウェア品質の未来 企画, 2019
- Test Engineers Meetup #3 企画手伝い, 2018
- Docker Meetup Tokyo 2017 企画手伝い, 2017
- ICST2017 Unofficial Meetup 企画手伝い, 2017
- Test Engineers Meetup #2 企画手伝い, 2017
- Tokyo DevOps 2.0 Meetup 企画, 2017
- Test Engineers Meetup #1企画, 2016
- カフェソフトウェアクオリティ第24回 企画, 2015
- テスト自動化の社内勉強会企画, 2015
- 楽天テックカンファ前夜祭, 2014
書籍関連・インタビュー・ブログ記事など
- 「DevOps 時代の採用面接 - Test Automation」(個人ブログポスト, 2019)
- 「アジャイルもテスト自動化も当たり前?! ~AIがテスト設計をする日が来るかも~ - Test Automation」(個人ブログポスト, 2018)
- 「特集2 "素早い"テスト実践法」(日経SYSTEMS8月号,2017)
- 「ITエンジニア新図鑑:テストエンジニアについてのインタビュー」(日経SYSTEMS 5月号, 2017)
- 「DevOps時代のテスト要求分析」(個人ブログポスト, 2016)
- 「DevOpsについてのインタビュー」(日経コンピュータ2016年11月10日号)
- 「DevOps事例提供」(エンタープライズアジャイルの可能性と実現への提言, 2016)
- 「Rakuten DevOps Evidence January」(2016)
- 「DevOpsインタビュー:第1回 楽天さんのDevOpsについて聞いてみた」 (2015年)
- 「"グローバル化"と"コミュニケーションとアジャイルとテストエンジニア"」(Ultimate Agile Stories Iteration 5, 2015)
- 「アジャイルテストのテスト設計の話」(個人ブログポスト, 2015)
- 「継続的システムテスト」(個人ブログポスト, 2014)
資格
- JSTQB Advanced Level テストアナリスト (2017)
- JSTQB Advanced Level テストマネージャー (2015)
- JCSQE 初級 (2014)
- JSTQB Foundation Level (2014)
- プロダクトオーナー(2014)
コミュニティ
- QA4AIコンソーシアム メンバー/設立発起人 (2018~)
- ソフトウェア品質管理研究会 研究コース4 アジャイルと品質 副主査 (2019~)
ソフトウェア品質シンポジウム2019でQC七つ道具とDevOpsの経験論文の発表します
2019年09/11(水)~13(金)に東洋大学で開催されるソフトウェア品質シンポジウムで、QC七つ道具とDevOpsの経験論文の発表をうちのチームメンバーがします。
この経験論文は、一言で言えば
- QC七つ道具とDevOpsをやってみた
という内容です。この経験論文の意欲的な点は、QC七つ道具という古典的なツールを持ち出すことで、
- アジャイル開発の歴史の中でのDevOpsの位置付け
- アジャイルからDevOpsへの変化によって品質保証の何が変わるのか
- ソフトウェアプロセス改善の歴史の中でのDevOpsの位置付け
を紐解こうとしている、つまりDevOpsという最近の流行りのプラクティスを品質というエンジニアリングの視点で考察している点です。あと、流行としての意味合いが強いDevOpsも、こういうエンジニアリングの視点でまとめたら論文になるんだよ、という一つの指針になるかもしれません。
本番の発表では、論文に入りきらなかったスライドも入れる予定ですので、ご興味のある方は是非シンポジウムにもお越し下さいませ。
07/04(木)19時〜のRakuten Tech Meetup 2が楽しみ #rtechconf
2019年07月04日(木)19:00〜、「データで切り拓くソフトウェア品質の未来」をテーマにミートアップを開催します!
今回のミートアップは、ソフトウェア品質、スクラム、DevOps、テスト自動化、レビューなど多岐に渡る領域のスペシャリストが「データ」を軸に議論するのが魅力なんです。以下開催概要抜粋。
ソフトウェアの品質改善の活動に、従来のQAから得られる品質のデータに加え、開発や運用から得られるデータ、またリードタイムや生産性など時間に関連するデータなど、様々なデータが活用されるようになりました。これは
- 継続的な開発を前提とするアジャイル開発が当たり前となり、時系列データも利用可能になったこと
- DevOpsが普及することで、QAだけでなく開発から運用までの一貫したデータが利用可能になったこと
が理由として挙げられます。
これらの新たに利用可能になったデータを活用し、ソフトウェアの品質のみならず、プロセスやチームの生産性、従業員の職務満足度などの改善にも取り組む企業が増えています。また、これらのデータを蓄積することで、AIによるQAの自動化などを始める企業も出てきました。
このミートアップでは、データにもとづくソフトウェア品質改善のアカデミックなアプローチである実証的ソフトウェア工学の最新動向や、アジャイルやDevOpsなどの現場でのデータ駆動な品質改善活動の事例をご紹介します。また、ラウンドテーブルでは、これらのトピックについて参加者と一緒になった議論をします。
前回のブログエントリで概説した通り、DevOpsを通してテストやリリース活動がソフトウェア化され、プロダクト品質だけでなくアーキテクチャとプロセスの品質の一体となった改善活動が鍵となってきています。これに加え、Value Stream Mapping上での、分析からリリースまでの一貫したデータが得られるようになり、特にスピードやリードタイムなどの生産性の改善も重要になってきました。(前回のブログエントリは以下をご参照ください。)
このDevOpsでのデータを鍵とした改善活動について、業界のエキスパート達と議論します。ご興味のある方のご参加をお待ちしております!
DevOps時代のアーキテクチャ品質特性とプロセス品質概論
はじめに
DevOpsという言葉は2008年に誕生した。その概念は2015年頃日本でも再注目され、これまでDevOpsに有用な技術や文化の変革について議論されてきた。このブログエントリでは、DevOpsがアーキテクチャとプロセスに与えた影響についておさらいしたのち、DevOpsに必要なアーキテクチャの品質特性とプロセス品質を一覧で示す。
DevOpsがアーキテクチャとプロセスに与えた影響
DevOpsの意義
プロダクト開発では、要求分析からリリースまでのサイクルを回し顧客からフィードバックを素早く得ることで、プロダクトの品質を素早く継続的に向上することが重要だ。これを達成するため、「要求分析」「設計」「実装」「テスト」「リリース」などのバリューストリームマップに含まれる工程の生産性を改善し、リードタイムを短縮する手段を、DevOpsは提供する。下記の図で黄色の線で示された、要求分析からリリースまでのフローのリードタイムを改善するため、各工程の生産性を向上する。
各工程の生産性改善のためのDevOpsの2つのアプローチ
各工程の生産性を向上するため、DevOpsの技術的なプラクティス郡は2つの共通のアプローチをとる。それは
- 各工程の手作業をソフトウェア化することで、それらを素早く、正確に、安全に、繰り返し実行可能になものにする。
- (上記の1.の結果、)各工程のアウトプットについて、特に、問題があった場合にそれを素早く発見、修正するフィードバックループを作る。
1.には、クラウドやInfrasutructure as Codeによるリリース作業や復旧作業のソフトウェア化、テスト自動化によるテスト実行作業のソフトウェア化などが含まれる。繰り返し実行する手順を自動実行できるようにしたり、システムの状態をコードで定義できるようにしたりすることで、各作業をソフトウェアとして管理できるようになる。
2.には、テスト作業のソフトウェア化によって実装工程のアウトプットであるソースコードの問題を素早くフィードバックするCI/CDや、リリース作業のソフトウェア化によってリリース工程のアウトプットである本番環境の問題を素早くフィードバックするカナリヤリリースなどが含まれる。上記の図に青の線でこのフィードバックループを示す。
手作業のソフトウェア化とフィードバックループが意味するもの
DevOpsのプラクティスによる手作業のソフトウェア化とそれによるフィードバックループは、すなわちDevOpsがシステムのアーキテクチャーと開発のプロセスに織り合わさって変化をもたらしていることを意味する。
システムのアーキテクチャ面では、プロダクトの外部品質だけでなく、ソースコードを容易に変更したり、テストやリリース作業を容易にソフトウェア化するための内部品質の重要性が増している。テストやリリース作業を容易にソフトウェ化することが可能なように、プロダクトを設計する必要がある。
また、ソフトウェア化するテストやリリースなどの手作業は、それそのものがソフトウェアでありプロセスでもある。そのため、それぞれの作業をについてソフトウェア面の品質特性と、プロセスの品質を組み合わせて考慮する必要がある。
次の章から、DevOpsで特に重要なアーキテクチャの品質特性とプロセス品質を一覧する。
DevOpsのアーキテクチャ品質特性
プロダクトの変更容易性(実装作業)にまつわる品質特性
ソースコードの保守性 | プロダクトのソースコードは素早くなんども変更可能か?コードの可読性や、単一責任などのクラス設計は適切か? |
サービスやコンポーネントの独立性(*1) | 1つのサービスやリリースなどの変更を入れる際に、他のサービスやコンポーネントにも変更を入れる必要があるか?変更の影響は限定されているか? |
データの結果整合性(*2) | 複数のサービス間で共有されるデータには、どの程度の整合性が求められるか?結果整合性の場合、上記の独立性は担保できるか? |
テスト作業のソフトウェア化にまつわる品質特性
テスト結果の取得容易性 | システムへのリクエストやアクションの結果を期待結果として定義できるか?また、その結果をシステムから容易に取得可能か? |
テスト結果判定の自動化容易性 | テストの期待結果をコンピュータにも理解できる形で定義可能か?またテストの合否をコンピュータが判定可能か? |
テスト実行の並行性 | 複数のテストケースを並行して実行することは可能か?テストケースやテストデータは独立か? |
テスト実行の冪等性 | テストケースは繰り返し実行しても同じ結果が保証されるか?テストの事前準備や事後操作がテストデータの冪等性を担保するか? |
自動テストの結果の信頼性 | テストのカバレッジは十分か?テスト環境は適切か?テスト実行ごとに異なる結果を返すFlaky Testの数は最小化されていか? |
自動テストのレポートとログの判断容易性 | テストレポートとログから素早くテスト結果を判断できるか?テスト失敗時に素早く調査可能か? |
リリース作業のソフトウェア化にまつわる品質特性
サービスやコンポーネントの独立性 |
(*1)と同じ |
複数バージョンの共存性 | 本番環境などで、複数のバージョンが共存可能か?バージョン間でI/Fなどの互換性はあるか? |
リリース・リカバリ手順の冪等性(*2) | リリース手順は繰り返し実行しても同じ結果を保証するか? |
インフラの廃棄可能性(*3) | 既存のインフラを廃棄しても、同じものを再現可能か? |
リリース影響の制御容易性 | リリースの影響をフィーチャーやユーザーセグメントなどの単位で制御可能か? リリースの影響範囲を段階的に制御可能か? |
リリースやリカバリ結果の判断容易性(*4) | リリースの合否の判断は容易に可能か? 判断に必要なシステムログやアプリケーションログは容易に取得可能か? |
システムの復旧や運用作業にまつわる品質特性
システムの耐障害許容性 | 単一のシステムの障害が、他のシステムに影響を及ぼしたり、新たな障害を引き起こしたりしないか? |
リリース・リカバリ手順の冪等性(*2) | (*2)と同じ |
インフラの廃棄可能性(*3) | (*3)と同じ |
システムのスケーラビリティ | アプリケーションやデータベースは独立性が担保されており、容易にスケールアウトすることが可能か? |
リリースやリカバリ結果の判断容易性(*4) | (*4)と同じ |
エラーログの判断容易性 | エラーログから障害は素早く検知可能か?影響調査や原因調査を素早く行うのに対し、妥当なログが得られるか? |
DevOpsのプロセス品質
実装工程の品質
ソースコード品質 | 実装工程の成果物であるソースコードの、コード行数、複雑度、コピペコードの割合などの技術的負債の量 |
実装工程で作り込まれた不具合数 | 実装工程で作り込まれた不具合数(テスト工程、リリース工程で発見した不具合数と市場に流出した不具合の総数) |
テスト工程の品質
自動テストの品質 | テスト工程の成果物である自動テストの、テストケース数、カバレッジ、実行頻度およびFlaky Testの割合 |
自動テストの所要時間 | テスト準備、実行、およびテスト結果の調査にかかる時間 |
テスト工程での不具合発見率 | 不具合の総数に対する、テスト工程で見つかった不具合の割合 |
テスト工程での不具合修正時間 | 実装とテストの工程やチームをまたぐ、テストによる不具合の発見から修正、再テストによる修正確認までの時間 |
リリース工程の品質
リリースの品質 | リリース工程の成果物である自動リリースの、デプロイ頻度、リリース成功率および失敗時の影響制御割合 |
リリースの所要時間 | リリース準備、リリース作業、および事後確認にかかる時間 |
リリース工程での不具合発見率 | 不具合の総数に対する、カナリヤリリースで見つかった不具合の割合 |
リリース工程での不具合修正時間 | 実装、テストとリリースの工程やチームをまたぐ、リリースによる不具合の発見から修正、再テストによる修正確認および再リリースまでの時間 |
障害復旧時間 | 開発と運用チームをまたぐ、障害発生から検知、調査と不具合の修正やホットフィックスのリリースまでの、障害発生からリカバリするまでの時間 |
運用・保守作業時間 | インフラチームとDBチームなど、複数のチームをまたぐ運用・保守の作業時間 |
まとめ
DevOpsがアーキテクチャとプロセスに与えた影響を概説し、DevOpsで重要なアーキテクチャの品質特性を工程・作業ごとに一覧で示した。DevOpsのプラクティスを通して生産性を改善するには、これらのアーキテクチャの品質特性とプロセス品質を考慮し、アーキテクチャとプロセス両面から改善活動を行うことが重要だ。
エンジニアが人事のちょっとしたカイゼンの話を見つけて世の中に送り出しちゃった話3/3
前回の続き
社外発表をしてみて
前々回、前回と「エンジニアが人事のちょっとしたカイゼンの話を見つけて世の中に送り出すまで」の話を書いた。このシリーズ最終回の今回は、エンジニアコミュニティ発表未経験の人事の相方が、実際に発表してみた後の振り返りについて書く。今回は、DevOps Days Tokyoのワークショップで体験してきた「Fun! Done! Learn!」で振り返りをした。Fun! Done! Learn!は楽しく振り返りやろうぜ!ってことだと思います(多分)。
Fun! Done! Learn!
1時間ほどのFun! Done! Learn!の結果出てきた振り返りアイテムは
- ①今までのカイゼン活動を誇れるようになった(Fun!, Learn! and Done!)
- ②結果として色々いいことが!(Fun! and Done!)
- ③発表内容の工夫(Learn! and Done!)
の3つに大きく分類できた。赤い付箋が人事の相方から出たもので、黄色い付箋が僕から出たものだ。
ここでは、人事の相方がエンジニアコミュニティでの発表で得たものや気付いたものをカテゴリごとに紹介していく。
①今までのカイゼン活動を誇れるようになった(Fun!, Learn! and Done!)
JaSSTやDevOps Daysで発表する前は、エンジニアコミュニティ発表未経験の人事の相方は、
- 人前で話すことじゃないと思っていたのに…
- こんなの参考になると思ってなかったのに
と考えていた。
だが、実際に発表してみたら、
- 感動された
- 勇気をもらったって言われた
というフィードバックを、発表を聞いた人たちから得ることができた。
そういったフィードバックから、
- 努力した事例→人の参考になる、影響を与える
- けっこうすごいことやってたって気付いた
- 自分が勇気をあげられると気付いた!
- 参加だけより発表した方が楽しい
という気づきがあり、
- やってきたことを誇れるようになった
- 自信がついた
という効果が本人にあったようだ。
②結果として色々いいことが!(Fun! and Done!)
エンジニアコミュニティでの発表により、フィードバック以外にも色々嬉しいことがあったようだ。
- Slideshareにアップロードした。3000 views
- ツイッターフォロワーふえた
- 知り合いふえた
のように、発表がきっかけでコミュニティで新しい人との繋がりを持つきっかけになったみたいだ。
また、
- Agile Japan実行委員にさそわれた
なんていう、次の機会に繋がるものもあり、
- 人前で話すのがさらに好きになった
みたいだ。
③発表内容の工夫(Learn! and Done!)
前回解説したエンジニアコミュニティでの発表の工夫についての振り返りも出た。
- 伝えたいメッセージを意識して話した→間、強弱が自然とできた
- 悩んでる人を想定して話した
- 具体的事例を盛り込んだことでよく伝わった
- 写真とか図とかSNSの投稿とか具体的な感じ
- コンウェイの法則を見せることで問題が明確に
- Fealess Changeとからめて説明してよく伝わった
- Fealess Change(あるもの)→ブルドーザー(オリジナル)の流れがよかった
エンジニコミュニティでの発表の工夫は最初はちょっと敷居が高く感じるが、実際に色々と工夫してみことで学びがあるみたいだ。
おまけ:Fun! Done!Learn!について思ったこと
今回、Fun!Done!Learn!を振り返りの手法として使ってみて、「自分たちのやっていることを肯定的に捉え、チームや個人のマインドセットや行動のいいところを探し出すのに効果的な方法」だなと思った。
「エンジニアコミュニティでの発表」を「Done!」することが、「参加だけより発表した方が楽しい」や「やってきたことを誇れる」などチームや個人の「Fun!」や、「努力した事例→人の参考になる、影響を与える」などのLearnに繋がっていることが振り返りからわかった。
今回この振り返りは発表の後に行ったため、「Done!」→「Fun!, Learn!」の向きの影響が多かったが、スライドの準備段階や発表の練習段階では、「Fun!→Done!」や「Learn!→Done!」向きの影響が増えるかもしれない。
ともあれ、「Fun!」「Done!」「Learn!」の3つの要素が織りなすサイクルが、チームの健康状態をよくするんだなってことを感じた。
まとめ
この3回のブログエントリでは、人事の相方のちょっとしたカイゼンの話を見つけて世の中に送り出した話を書いた。気づいていないだけで現場のちょっとしたカイゼンの物語はあなたの現場にもきっとあるはずだ。エンジニアコミュニティでの発表をまだ経験したことない人も、是非挑戦してみて欲しいと思う。
エンジニアが人事のちょっとしたカイゼンの話を見つけて世の中に送り出しちゃった話2/3
前回の続き
ちょっとしたカイゼン物語をエンジニアコミュニティに送り出す
身の回りのちょっとしたカイゼンの話を見つけたら、次はどんな勉強会で、どんな構成で発表するか考えるだろう。でも、エンジニアコミュニティでの発表って、ちょっと敷居が高いと思われているかもしれない。
実際、JaSST'18 Tokaiの発表スライドとDevOps Days Tokyoの発表スライドを作っていているときも、エンジニアの僕は無意識にやっていることでも、人事の相方は「???」となる、エンジニアコミュニティ独特のお作法がいくつかあった。
ここでは、人事の相方と一緒にスライドを作る中で気が付いた、エンジニアコミュニティ独特のお作法を、これからエンジニアコミュニティでの発表を目指す人向けに4つのポイントとして紹介しようと思う。
①発表の位置付け
自分の発表が、コミュニティや今までの技術の発展の中でどういう位置付けなのかを明確にすることは、発表の意義をみんなに知ってもらう上で一番重要だ。こう書くと難しいことのように感じるかもしれないけれども、要は、「みんなXXについて課題を感じているよね?そのXXについての解決方法YYを考えて実践してみました」っていうように、自分の問題意識とアプローチを明確にするってことだ。
ここでいう問題意識は、「アジャイルや自動化をチームに導入したいけど色々大変」とか、「自動化を進めたいけどチーム間でのコラボレーションが大変」といったような身の回りでありがちなもので最初は十分だ。いま自分が困っている課題は、実は世の中の多くの人が同じ課題感を抱えている可能性がある。その課題を実践的に解決する話は、きっとエンジニアコミュニティの他の人たちにとっても価値がある。
②発表内容のエンジニアリング的な納得感
お作法ってほどではないけれども、「もうすでにコミュニティの中で正しいと信じられていること」から実践してみたり、発表スライドを始めてみたりするのはオススメのテクニックだ。エンジニアリングコミュニティの中では今までの歴史や積み重ねの中で、なんとなく「エンジニアリング的に正しい」と信じられていることがある。
もし、そういう事柄があるのならば、発表スライドの一番最初にその話を紹介すると、「ああ、あの(みんなが正しいと信じてる)プラクティスを実践したのね」「ああ、あの(みんなが正しいと信じてる)手法を発展させたのね」と納得感を得られやすい。(例:いきなり「ブルドーザー」と言っても「なんじゃそりゃ」とビックリするけれども、いったんみんなの知っているFearless Changeをはさむことで、納得感が生まれるw)
③発表内容の新しい価値とオリジナリティ
もしあなたの発表内容が、例えば教科書に書いてある手法をその通りにやってみただけであったとしても、その実践内容や結果を発表することはコミュニティにとって大きな価値がある。どういう条件の時にうまくいくのか、いかないのか、事例として共有されると、その手法についての実践知がたまり、より深く理解するきっかけとなる。
でも、僕個人としては、そんな事例の中にも少しオリジナルのアイデアがある方が好きかなあ(笑)。教科書的な部分て堅苦しい面があるけれど、「ブルドーザー」みたいなオリジナルのアイデアってやっぱワクワクするのよね。
④その手法はいつでも誰でも実践可能か
もしあなたのカイゼン手法が、誰にでもどんな場合でも実践可能なものならば、多くの人がその手法を実践してみるだろう。より多くの人にとって実践可能な手法はコミュニティにとっても価値が高い。でも、カイゼン手法を誰でも実践可能なモノに落とし込むには少なからず手間がいる。
手法の原因や結果などを構造化したり、ステップバイステップの手順を書き起こしたりすると、より多くの人が簡単に実践できるものになる。パターン化は、より定義された構造化の方法だ。また、その手法を使ってうまくいく・うまくいかないケースの条件なんかも、その手法を実践してみようとする人にとって貴重な情報だ。
「人事がDevOps研修を作っちゃった話」の上記4つのポイント
今回の発表の中で、上記の4つのポイントをどのように作り込んでいたのかを参考までに書いてみる。
JaSST Tokaiの場合 | DevOps Daysの場合 | |
---|---|---|
発表の位置付け |
|
|
発表内容のエンジニアリング的な納得感 |
|
|
発表内容の新しい価値とオリジナリティ |
|
|
その手法はいつでも誰でも実践可能か |
|
|
次回に続く