告知ページ

togetter

オープニング(吉田 彩奈さん)

https://tech.rakuten.co.jp/assets/img/12cef28181221caf9744fbbfa3995545.jpg

はじめに、主催者の吉田さんから開会のご挨拶がありました。

こちらのバリューストリームマッピングがとてもインパクト強かったです。

本Meetupのテーマ、データに基づいた品質改善活動が表現されています。

(参考)吉田さんが書かれた告知ブログ

なお、本イベントでは「グラレコ部」の皆様により、各セッションのグラフィックレコーディングが作成されました。

リアルタイムにセッションの内容がまとめられていく様は、まさに職人芸でした！

参加メモ

基調講演　ソフトウェア開発活動のデータとアナリティクスの3原則(森崎先生)

開発と運用の境界の希薄化

リリース前もめちゃくちゃ頑張るけど、リリース後も頑張る(適当にリリースして運用でカバー、はダメ)

Web/クラウド　カナリアリリース、β版など

米軍　コントロールサイエンス

自動運転　ペガサスプロジェクト(走行情報データベース)　出荷前だけでなく、出荷後の走行情報も収集する

モデルチェッキング、数学に基づいた検証

CPS　サイバーフィジカルシステムズ　

現実世界から情報を得て、コンピュータ内でモデル化→分析・予測・把握して、現実世界にフィードバックする

主には自動運転

ソフトウェア開発の場合も、CPSと同じ要領で分析＆フィードバックしたい

ただし、ソフトウェアの場合は、そこまで精緻に情報を取れない

人間はソフトウェアより融通が利かない

開発活動のデータとアナリティクスの3原則

情報は適切か

分析・予測の結果、行動に移せるか

行動に合意(協力)を得られるか

(アンチパターンは時間の都合で割愛)

事例1 ソースコード規模遷移による進捗共有

機能ごとにソースコード規模遷移をグラフ化

ツールによりタイムスタンプを取る

これ1時間かかってますね、8時間かかってますね、なぜですか、といった問いかけに使う

事例2 バグレポートの分析

見逃しバグにフォーカスする

レビューで検出できず、且つ修正コストが大きかった欠陥種別

ドメインは金融　大手銀行の外貨有価証券

分析の結果、日付に関する欠陥は優位な差が認められた

利子や利息の開始、時差、祝日、締め日の違いなど

事例3 設計モデルのメトリクス収集

車両制御用Simulinkモデル　モデリング→ソースコード自動生成

ソースコードメトリクスからバグが混入しやすい部分を特定できることは実証されている

設計モデルからメトリクスを取って、同様の傾向がみられるか分析した

結論、同様の傾向がみられた

入出力が多いモデルは欠陥が多い　この情報をもとに、欠陥が予測できる

事例紹介1　エンジニアチームにとって手の届くKPIを考えて、仕事に取り入れてみた(山木さん＆原田さん)

グラレコ：

ドヤれる成果は出ていないが、現状を話す

そもそもの目的：プロジェクト開始からリリースまでのリードタイムを短くしたい

まず現状を棚卸しするため、VSM(バリューストリームマッピング)を作った

VSMに沿って、KGI、CSF(仮説)、KPIを決めた

キーワードは、手戻り、技術的負債、カイゼン

エンジニアにとって安全でないもの、シンプルでないものはリードタイムを伸ばす　残念な手戻りを減らす

KPIは少ないことが理想だが、つい増やしたくなる

月1のふりかえりだとちょっと忘れがち　ふりかえりのタイミングを増やしたい

KPIを取ると、KPIに注意が払われる

グッドハートの法則

メトリクスは注意をひいてしまう　エンジニアは、注意をひかれてしまうとバグが出る

ディルバートのバグの話　(バグに報奨金を与える制度を作ったら、みんながわざとバグを埋め込むようになった)

測定→見える化→行動の変化→CSFの達成→KGIの変化

達成できたら、そのKPIは無くして良い

事例紹介2　デンソーSREにおけるデータ活用とカイゼン(島津さん& 吉羽さん )

スライド：未公開

グラレコ：

デンソーとは？クルマの部品を作っている会社　製造業

MaaS(モビリティアズアサービス)　アジャイル開発センター

「デンソー　アジャイル」で検索してね

データ活用を支えるのは、地味で泥臭い運用である

デンソーSREチームのデータ活用

SREとは　Googleが提唱したロール　要は、運用とソフトウェアエンジニアリングの融合

厳密な定義はない　※企業ごとに微妙に異なる

デンソーSREの場合は

クラウドインフラ構築

性能改善

サービス監視

監視のポイント

可用性　死活監視、エラー監視

性能　

セキュリティ

→デンソーが大切にしている、安心・安全

アラート通知はSlackに集約

AWSでログ収集、メトリクスはZABBIXから飛ばす

アラートのレベルごとにチャンネルを定義している

AWSのベストプラクティスに沿っている

課題対応の事例紹介

事例①　

問題：

対応手順が明確化しているアラート、現状すぐに解決できないアラートが流れ続ける

その結果、アラート用チャンネルを見たくなくなる

オオカミ少年チャンネル

対策：

重要度によってチャンネルを分割

手順が明確なものは、閾値を設けて復旧を自動化

事例②

問題：

デプロイ中にアラートが飛びまくる

対策：

デプロイ時はアラートを止める仕組みを作った

本当に重要なアラートに集中！

肉体的にも精神的にも疲労軽減

今後もまだまだ課題あり

アプリ

ユーザがどの機能をよく使っているかのデータ収集・整理する仕組みの構築

など

製造業のノウハウを生かしていく

事例紹介3 データとQC7つ道具を利用したDEVOPSプラクティスによる生産性改善(内藤さん＆荻野さん)

グラレコ：

データとQC7つ道具

環境は4つ　DEV→QA→STABLE(クライアント様のテスト環境)→リリース

クライアント環境での障害の根本原因分析を実施

フィッシュボーン分析　事象→原因の深堀り

開発の生産性→バグの作りこみ

テストの生産性→バグの見逃し

双方の生産性→バグの修正＆修正確認までのタイムラグ

開発の生産性

環境が十分にない

手動で環境構築

環境不足

対策　→　スケーラブルな環境を用意(Docker,k8s,Jenkins)

テストの生産性

回帰テストのカバレッジが十分でない

散布図　QAでの検出とクライアントでの検出　0.59でそれなりの関係性

対策　→　テストを追加した

開発＆テスト双方の関係におけるの生産性

DEV/QA間の手待ち時間が長い

不具合の修正に40日かかったことも

対策　→　テストの自動化・日次実行

QC7つ道具の使用により、定量的な効果検証ができた

テスト成功率100%にいくまでに半年かかった

ラウンドテーブル1　みんなで語ろうデータと品質(渡邉さん)

グラレコ：

※主に、山木さん＆原田さんの発表内容に対する議論が中心でした

がんばってメトリクスを取るのはおすすめしない

CSFは自分で考えよう(コーチに答えを聞いてはいけない)

達成したら自分が幸せになるKPIを選ぶ

KPIと評価は紐づけていない

月1でふりかえりをしているが、これでも少ないと感じている　悩み中

ラウンドテーブル2　オカシイの引き出し方(風間さん)

レビューして、それでも見逃すことはある？

コレってどうなの？と感じたときに、どう伝える？

周りの全員の反応を観察する

マサカリの投げ方

心理的安全性が必要

忖度している場合ではないような状況では、どんどんマサカリも投げる(例えば、3人くらいのスタートアップ)

(マサカリによる)成長を望まない人もいる

スクラムマスターがバカになって質問する

オライリーさんの言う通り

全体の感想

発表者の皆様、それぞれに苦労をされているのが伝わってきました。

それっぽい数字を目標に設定することはよく見かけますが、

意味のある数字を考えるのはなかなか難しいですね。

原田さんのコメントなどを参考にして、自分の仕事に活かしていきたいです。