2019/04/09 に開催された DevOps Days Tokyo 2019 Day1 のイベントレポートです。

●イベント概要
DevOpsDays は世界中で開催されているカンファレンスです。ソフトウェア開発、ITインフラ運用、そしてその境界線上にあるトピックをカバーし、特にDevOpsを実現するための自動化、テスト、セキュリティ、組織文化にフォーカスします。

IT技術を駆使して変化に強いビジネスインフラを実現するスキルを身に着けるために、国内外の最先端の事例とプラクティスを結集します。海外から第一人者を直接招き、ここでしか手に入らない最新情報をリアルタイムで入手出来ます。

最先端のテクノロジの活用法はもちろん、先進企業で必要とされてきた背景までも理解し、正しく組織内に展開するための洗練された知見を得られます。

このイベントが日本のみならず、世界のDevOpsプラクティスを共有できる、意義のあるイベントになれるよう、願っております。

■Welcome to DevOpsDays 2019!

Alex Papadimoulis さん
Sho Sato さん

●DevOpsDaysとは何か？
・100以上の都市で開催
・コミュニティでの運営
・テーマは Inside & Implementetion

●DevOps Benefits
・ビジネスアイデアをより早くマーケットに届ける
・低コストな開発を可能にする
・変化のリスクに適応する

・世界中の企業がメリットを感じている
・DevOpsは公式や回答ではない

●DevOps change
・技術と文化の変化
　　　　DevOpsを実現するために組織を変えていくのではなく
　　　　原則を実行していくことで内部から変わっていくもの

●DevOps is for Everyone
・強大なエンタープライズでも適用できる
・組織のすべての人を巻き込む必要がある
　　　　エンジニアやtechサイドだけでは実現できない
　　　　全員がテクノロジーについて理解
　　　　カルチャーが自然に広がっていく

・シンプルに利用できて、パワフルで柔軟なツールが必要
・組織によって最適な方法は異なる
・テクノロジーとツールが組織を一つにしていく

■スポンサーセッション f5: DevOpsによる最適なアプリケーション配信

・アプリケーションアーキテクチャの移り変わり
　　　　オンプレ -> ハイブリッドクラウド -> マルチクラウド
　　　　モノリシック -> マイクロサービス

・世界で 2.5億のアプリ
　　　　これから x7倍に！

・アプリケーションの課題
　　　　セキュリティ
　　　　パフォーマンス
　　　　安定運用

・これらはトレードオフ
-> 自動化CI/CDプロセス
　　　　担当者によって関心がバラバラ
　　　　f5でサポートします

■スポンサーセッション DataDog: クラウド時代のDevOpsモニタリング

・マイクロサービス化、インフラも分散
　　　　-> モニタリングも分散

・モニタリングの三本柱
　　　　Metcis: スパイクが起きた！
　　　　Traces: なぜ起きた？
　　　　Logs : アプリの中までみて解析

・ホスト、コンテナを俯瞰からドリルダウン
・フレームグラフ x メトリクス x ログ をシームレスに

■Lessons Learned Since The Phoenix Project

Gene Kim さん

ハイパフォーマンス組織を研究してきたが
面白いことに、研究していくうちに結局DevOpsに入っていた。

●DevOpsとはなにか
・Better, Faster, Safer, Happier

●書籍
・The Phoenix Project
・The DevOps Handbook
・LeanとDevOpsの科学
・The Unicorn Project
　　phonixの続編として11月に発売予定

●Downward Spiral
・DevOpsは誰に対しても適用できる
・やらないとひどい目にあう
・技術的負債はうまい表現
・財政的にも影響を受ける
・例えば
　　マニュアルデプロイ
　　コード書くがテストが自動化されていない
　　-> こんな状態に

・デプロイに6ヶ月かかった現場もあった
　　準備の準備
　　リハーサル
・Dev/QA/Opsで戦争が起きた
-> 気持ちも落ちていく

●Business Value of DevOps
・DevOpsレポート
　　3万くらい上がっている
　　ハイパフォーマーとの比較
　　セキュリティの問題は半分くらいの時間で対応できる
　　-> ビジネスに注力できる
　　-> 売上、生産性へ
　　ガバメント、満足度なども x2
・組織内の満足度も高い
　　Net Promoter Score
・安全で迅速に確実にセキュアにゴールや願望を実現する

●Elite と Low Performers の比較
・Deploy Frequency　　 : x46
・Deploy Lead Time　　 : x2,555
・Mean Time to Restore : x2,604

●テクノロジーの企業ではリードタイムが有力なメトリック
・Deployment Lead Time
　　deploys per day: 回数で測る
　　vs
　　lead time: 内部を計測することで状態を把握できる
・開発には2種類の作業
　　Product Design and Dev
　　　　クリエイティブな仕事
　　　　数ヶ月かかる
　　Product Delivery
　　　　自動化できる
　　　　数分で済ませたい
・より早くdeliverすることで、より早くミスから学ぶ
　　どれだけ反復できるか
・deploymentへの恐怖を測るのも良い指標
　　いつでも安心して実施できるのか
　　二度とやりたくないのか

●コンウェイの法則
・Etsy Sprouter
　　2008: Devs / DBAs
　　　　チームが分かれているので同期に時間がかかる
　　2009: Devs / DBAs / Sprouter team
　　　　連携する部分のチームを作った
　　　　がやることが増えて進まない
　　2010: Devs
　　　　一つにまとめた
・組織にマッチするアーキテクチャをつくる
　　承認を不要にできる
　　外部とのきめ細かいコミュニケーション、調整なしで仕事を貫徹できる
　　他のサービスから独立して、いつでもデプロイ、リリースできる
　　環境から独立して、いつでもテストできる
　　業務時間中にわずかなダウンタイムでデプロイできる

●Platformの価値
・開発者を生産的にする
　　Self-Service
　　On-demand
　　Immediacy and fast feedback
　　Focus and flow
　　Joy

●DevOpsはユニコーン企業だけでなく、ホース企業にも適用できる
・様々な企業で成功例が出ている
・TEPとLARBを廃止した賞状
　　新しいアイディアをTEPに書き込む
　　LARBに行って説明
　　検討結果を来月聞く
　　-> こんな体験を残すべきではない

・20%の時間を技術的負債の解消に当てよう
　　税金を払うより、クリエイティブな
　　放って置くと、すぐに税金は100%になってしまう

・変革型リーダーシップのディメンション
　　Vision
　　Intellectual Stimulation
　　Inspirational Communication
　　Supportive Leadership
　　Personal Recognition

・一般的なステップ
　　Features ↑
　　Dept & Risks ↑
　　Defects ↑
　　Quality ↓
　　-> Features ↓

・15-30dでリリースできていたfeatureが
　　3年後には 150-300d かかるように
・MS, Amazonなどでも、負債を返さなければ生き残れない状態になった

・The Feature Freeze / Stand down
　　Features ↓
　　Debt & Risks ↓
　　Defects ↓
　　Quality ↑
　　-> Features ↑

●Five Ideals
1. Locality in our code and organizations
　　コードと組織をチーム内で完結できるように

2. Focus, flow and joy in our daily work
　　Procedural Learning
　　　　生涯学びを蓄積していく
　　On-Shot Learning
　　　　問題を解決するためのワンタイム
　　ops/secのヒトと言われているが、3年前からdevといっている
　　　　infraは好きじゃないことに気づいた
　　　　-> devに集中

3. Enablement of improvement and ahievement
　　GMの工場
　　　　状況
　　　　　　社員がやめていく
　　　　　　品質が低い
　　　　　　エンジンが反対についたり
　　　　原因
　　　　　　手順が整っていなかった
　　　　　　カイゼンの優先順位が低かった
　　toyotaのあんどんコード
　　　　問題が起きた、作業がない などいろいろなタイミングで引かれる
　　　　-> ラインが止まる、スーパーバイザがやってくる
　　　　　　3,500 times / day
　　　　小さな問題でグローバルを止める
　　　　　　そこで止めなければ、下流でより大きな問題を解消
　　　　　　そこでfixしなければ、15秒後にも同じ問題を繰り返す

4. A culture of psychological safety
　　Pathlogical
　　　　情報を隠蔽してしまう
　　　　チーム間の連携がなくなる
　　　　新しいアイデアが潰されてしまう
　　Generative
　　　　セキュリティもみんなの仕事
　　　　クレイジーなアイデアも真剣に考える

5. A ruthless and relentless focus on our customer
　　1600万人のdev
　　facebook, amazon, google などのユニコーンで 15%程度
　　残りの 85% の生産性があがったら何が起きる？

●Q: 技術的負債を返す決定、3年止まる恐怖と戦うには？
　　3年は良い数字 amazon, MS, ebay などでもそうだった
　　市場で生き残るためには、やるしかなかった

●Q: お客さんからfeedbackを取ってくるには？
　　専門外になる
　　ABテスト
　　Leanでも仮説を検証するプロセス

■エンタープライズ企業におけるDevSecOps導入事例（Intro to DevSecOps in Enterprise）

Kyoko Yamada さん

●What is DevSecOps?
・社内外で「トレンドだよね」
・ハイプ・サイクルだとDevSecOpsはすでに幻滅期
・DevOpsを行う上で誰もがぶつかる課題

●セキュリティ診断
・内容
　　・静的解析 SAST
　　・動的解析 DAST
　　・ネットワーク脆弱性診断
・運用
　　リリースまでにすべて実施している
　　開発後に、専門部署に依頼して手動実施
　　リリース直前で診断結果がでるから遅延リスク
・ポリシー変更はすぐにはできない

●What we did
・DevSecOpsのゴール
　　・セキュリティプロセスのトイル削減
・効果が出やすそうな、反復型のDevに注力
・開発チームがすぐに使えるところまで準備
　　CI/CDパイプラインにSAST, DASTを組込み

●手動でのフローとDevSecOpsで比較
・脆弱性検出結果
　　過検知があった
　　手動での切り分けが必要
・リリースまでの時間
　　x4.4

●What did we lean
・Good
　　開発リスクを早期に検出、回避
　　診断までの準備が短時間
　　　　スプリントを重ねるごとに効果が大きくなる
　　開発者のセキュリティスキル向上
　　　　すぐ結果に反映されるのでモチベーションが向上
・Bad
　　手動診断が必要
　　DASTはセキュリティ診断の知識が必要
　　過検知は余計な作業

●What will do next?
・ボトムアップ
　　Developer Friendlyなツール提供で利用者拡大
　　　　動的検査にIASTツール
　　　　ツールの導入障壁を削減
・トップダウン
　　セキュリティチームが診断状況を把握
　　　　ガバナンス強化
　　　　ポリシー改善

■Service Operation Centered Development - サービス運用をまんなかにおいた開発

Mitsuyuki Shiiba さん

●やりはじめた動機
・「それってあっち側の問題なんですよ」と言っていても進まない
・サービスの安定稼働 & サービスを育てる
　　1チームで運用しながら開発、リリース
　　運用と開発はリズムが違うから難しい
　　知識として知っている、と、経験しているの違いは大きい
・運用しにくいシステムはいろいろあるけど
　　知っているのとそれをつくるのはまた別
・サービス運用を真ん中において
　　自分たちの開発と運用を進めることにした

●Development
1. 全部のアラートにすぐ対応しようよ
　　絞らないと自分たちが苦しい
　　　　翌朝で良くない？
　　　　リトライできるのでは？
　　　　勝手にリカバリすれば良くない？
　　LogMessageBuilder
　　Controllerまで引き回すアーキテクチャ
2. このボタン押しちゃダメは初めから作っておこうよ
　　Fool Proof
　　Fail Safe
　　Idempotence
　　　　同じイベントが来ても
　　Decoupled Archtecture
　　　　ユーザ影響が小さくなるように分割
　　Eventual Consistency
3. プロジェクトよりもサービス
　　オフラインでのやり取りも理解
　　納期が迫ると品質を天秤にかけたくなるけど、ダメだよね
　　サービス運用を考えると、書くよりも読む時間が増える
　　メンテナンスしやすく
4. チームの成長に注力
　　ペア、モブ
　　学習セッション
　　毎日実験

●Interaction
1. フォースを感じる
　　他のチームに向けて「なんでそんなに時間かかるの？」と感じる
　　それぞれのチームでいろいろな力学がかかっている
　　チームの中の人に敬意を払う
　　　　やっていることに違和感があっても
　　　　その周りの場が問題かもしれない
2. 曲がり角の先を見る
　　スピードが早いから、目の前に来てから対応では遅い
　　　　ビジネス、テクノロジー、デザイン、組織
　　　　前もって準備しておく

●Q: モブはどんなツール使っている？
・大きいディスプレイ
・モブタイマーで 15分間隔で強制交代
・リモートだとzoomでつないでいる

●Q: 他のチームの人に敵対してしまう人はどうしている？
・お互いの顔が見えると、角が丸くなったり
・正論で攻める必要はないよね

■Behavioral Driven Development in DevOps: beyond the development!

Wederson Soares さん

●CI&T
・ブラジルが本社
・支社は世界中に
・作業環境良いです
　　PSもありますw

●BDD in Development Phase
・技術的、非技術的なチームのコミュニケーションを助ける
・人間だけでは完璧なものはできない
・要件のフォーマットを同じ言語にする
　　ビジネスも開発も
　　ドキュメントだけではなく、動くことに価値がある
・ミスコミュニケーションを解く
　　見方の違いによるもの
　　より良い要件を特定する
・テストの自動化
　　いくつかのツール、成熟度
　　一般的に使われるもの
　　完璧に動かすのを一人でやるべきではない

●Gherkin言語
・Given, When, Thenだけ ※Andも使える
・ストーリで要件を説明
・実装はcucmberなど、言語ごとにいろいろ

●CI&Tでの使い方
・drupal site
　　40ヶ国で利用される
　　同じ国の中で複数の言語が利用されることも
　　ユーザから見て、何も壊れてはならない
　　　　日本のコンポーネントが、他の国のコードを壊してはいけない
・それは可能か？
　　何人もかけてテストすればバグ0もできるかもしれない
　　テスターの軍隊が必要になる
　　　　新しいサイトごとに雇っていたら予算が足りない
・現実の世界
　　人間によるテストだけでは十分ではない
　　受け入れられない人も多い
・問題は起きるもの
　　コンポーネントがつながらないなど
　　remoteチームで開発したものをdeployして結果を知る
　　-> agile、カイゼンいろいろやったが、人間では無理だった
　　ユーザの使い方によっては壊せてしまう

・ソリューション
　　BDD を Behatで
　　回帰テスト
　　メインページのみストーリカードにインテグレーション
　　アプリケーションすべてをカバー
　　visual regression test
・CMS
　　deploy後にユーザが変えられる
　　ユーザよりも先に、こちらが問題に気づかないといけない
　　本番環境は開発環境よりもwild
　　本番のモニタリングが必要
　　　　すべてのサイトを変更なしでクロール
・テストは再利用して、データは変えない
・利用者の観点でテスト
・翻訳のテスト
　　CMSでよく起きる問題だから
　　誰かがコンポーネントを足したのか
・JITで問題を見つけられる頻度で実行

●技術的ソリューション
・docker behat intro.
　　dockerized behat
　　selenium
　　Chrome Headless
・added features
　　24/7で動かし続けている
　　mailで失敗通知
・env
　　AWS T2 Small
　　Ubuntu

●how it works
・docker behat
　　-> client website
　　　　-> different country instances
　　　　　　国の切り替えを簡単に実施できる仕組みにした
　　-> dev team
・ダッシュボード
　　総量と進行状況を可視化
　　リアルタイムに見れていない場合は、mail通知で把握
・結果
　　mail -> 各websiteで翻訳 ときどきねらいどおり動かない
　　3分ごとに 12 web sitesに対応できる様になった
　　　　1 web site で 1h くらいかかっていた
・BDDをCI/CDに統合するのは簡単
・アプリコードとテストコードを一緒に管理

■DevOps accelerates Digital Transformation - 組織でどのようにDevOpsを促進させるのか -

Shingo Kitayama さん

今日はk8sの話しません
デジタルトランスフォーメーションの話です。

●本日お伝えしたいこと
　　あなたのビジネスにKubernetesは必要なのか？

●Digital Transformationとビジネス成果
・日本のDevOps取組状況
　　実践企業: 28.1%
　　技術要素: クラウド、コンテナ

・成果がまだ出ていない企業: 58.6%
　　やっている人は増えたが、ビジネス成果にはつながっていない
　　ツールや技術を活用するだけでなく
　　組織/文化/プロセスを適用することが必要

・ビジネス成果とは
　　顧客価値
　　　　期待する速さ
　　　　求められる品質
　　ビジネス価値
　　　　高い生産性
　　ROI
　　　　ビジネス要求
　　　　製品・サービス改善

・Digital Transformation(DX)とは
　　理想的にはすべてロボットだけど、人がやるところも残るはず
　　競合優位性を保つためによりよいサービスやソフトウェアを
　　ユーザに早く提供すること

・DXで考えること
　　技術 / 人・組織 / プロセス

・費用効果の最大化
　　スピード、品質は一定のレベルを超えると顧客の満足度は変わらない
　　profit sweet spotを考慮して、適切な品質とスピードを定義
　　DXで運用コストの削減を求められている
　　　　文化やプロセスの効率化が必要

・バイモーダルはリソース投資割合
　　SoR: 効率化
　　SoE: 迅速化

・EfficiencyMatrix(This is Lean)
　　プロセスの効率化、リソースの有効活用のマトリックス
　　1. 現状の運用状態を理解
　　2. プロセスを改善する
　　　　空きリソースが必要
　　3. コストを削減する
　　　　トイル削減

●2025年の崖
・このまま放って置くと人材不足、システム老朽化
　　基幹系システム投資: 60%
　　既存改修: 数ヶ月
　　IT人材不足: 43万人
　　既存:デジタル市場: 6:4

・既存システムの課題サイクル
　　技術の老朽化、肥大化、複雑化
　　ブラックボックス化、技術的負債
　　維持、保守に資金が割かれる
　　　　-> 既存システムの見直し
　　経営陣の理解が得難い
　　　　動いているからOK。伝わらない。
　　既存システムへの投資不足
　　不十分なマネジメント

・Accelerateから見るDXの対策
　　変革型リーダーシップを持つ人がいない
　　-> ビジョンと戦略を明確化
　　　　-> 高いケイパビリティを持つために経営者を巻き込む
　　-> デリバリパフォーマンスの見直し

・デリバリパフォーマンスのKGI
　　Speed
　　　　リードタイムの削減
　　　　デプロイ頻度の短縮
　　Quality
　　　　MTTRの短縮
　　　　変更失敗の低減

●RedHat Open Hybrid Cloud戦略
・DX
　　KGI
　　　　リードタイムの削減
　　　　デプロイ頻度の短縮
　　　　MTTRの短縮
　　　　変更失敗の低減
　　変革要素
　　　　技術
　　　　人・組織
　　　　プロセス
・5 Initiative
　　Application Modernization
　　Agile API Integration
　　DevOps
　　Cloud Infra
　　Automation

●DX Step
・DX Assessment
　　KGIの共有状況、レベル感を確認
・Discovery Session
　　目標値を設定
・Education
・Future

●Red Hat Open Innovation Labs
・ワークショップ形式で学べます

●Digital Transformation Assessment
・経営〜開発担当までみんな揃える
・KGI
　　・AsIsを把握
　　・ToBeを認識合わせ
・それぞれの課題を挙げる
　　人・組織、プロセス、技術で分類
　　スピード、品質で分類
・課題の優先順位付け
　　スピード or 品質 どちらが見えやすいか？
　　　　スピードを上げようとすると品質も上がる
　　　　品質を上げようとするとスピードも上がる
・ソリューションの特定
　　技術課題をグルーピング
　　技術の課題 -> 人・組織、プロセスの課題にマッピング
　　関連しないものは再考
・優先順位の特定
　　ユーザ影響、AsIs/ToBeの差
・phase分け

●本日お伝えしたいこと
あなたのビジネスにKubernetesは必要なのか？
-> あなたのビジネスに必要なものは何なのか？

■DevOps with Database on AWS

Atsushi Fukui さん / Yukitaka Ohmura さん

銀の弾丸はないです！

●なぜ難しい？
・変更対象が異なる
　　App: ソースコード
　　DB : スキーマ定義とデータ
・所要時間が異なる
　　App: 数秒〜数分
　　DB : 数時間
・担当者が異なる
　　App: Dev
　　DB : DBA
・変更管理が異なる
　　App: git
　　DB : プロジェクト独自

●モダンアプリケーション開発のすすめ
・特徴
　　ライフサイクル全体にコンプライアンス・セキュリティ
　　マイクロサービス
　　サーバレス
　　モデリング、インフラにコード
　　CI/CD
　　モニタリング

●マイクロサービス化に伴うデータベース分割
・外部参照キー
　　それぞれのデータソースを持つサービスに分割
・共有データ
　　共有データを持つサービスに分割
・共有テーブル
　　個別に分割

●マイクロサービス間のデータ連携
・Read/Writeのパフォーマンスやスケール要件が異なる
　　-> CQRS

●DB変更作業
・Dev.変更要求
　　-> DBA
　　　　-> DevDB / StgDB / ProdDB
・ツールで自動化

●DB変更に伴うリリース
・リリースに伴うダウンタイムの低減
　　外部調停不要のリリースは開発スピード向上に必須
・データベースのスキーマ変更
　　メタデータだけ
　　　　すぐ終わる
　　既存データのコピーを伴う
　　　　データ量に応じて時間がかかる
・既存データのコピーを伴うDDL
　　カラム追加など
　　　　ブロック
　　　　コピー
　　　　切り替え
・手堅くやるには外部調停

●DBスキーマをオンラインで変更
1. DBスキーマ変更を先行
　　古いアプリに影響がない
2. アプリリリース先行
　　影響のない変更ならこれで大丈夫
・オンラインDDL
　　それぞれの製品ごとにある

●一般的な手法
1. テーブル追加して結合
　　カラム追加なしテーブル追加、readはview
2. 予備カラム
3. JSON型

●DBをBlue/Greenデプロイ
・必要になる状況
　　DBが別になる
　　別リージョンになる
　　スキーマ変更が大きい
・主系DBデータのレプリケーション
　　DBの機能でできる
　　切り戻しは困難
・新旧両方のDBをDoubleWriteで更新
　　2フェーズコミットで遅くなる
　　切り戻しはできる
・単一の書き込み点を作る
　　CQRS的
　　アプリが結果整合性でないと難しい

■DevOps導入支援、始めました

Arata Fujimura さん

●何をやったのか
・リーンキャンバス
　　なにはともあれ
・インセプションデッキ
　　なにはともあれ
　　エレベーターピッチ
　　　　AWS DevOpsコンピテンシー認定に裏付けされた実績、ナレッジ
　　　　日本初！
・営業資料作成
　　リードタイム短縮
　　実験の文化
　　3つの道 丸パクリ！w
　　アジャイルのライトウィングとレフトウィング 丸パクリ！w

●二人で始まった
・技術（ツール）支援
・文化（アジャイル開発）支援
　　受託開発案件
　　　　スクラムマスター
　　　　アジャイルコーチ
　　スクラムガイドとのDiff
　　USM
　　VSM

●ハンズオン
・AWS CI/CDハンズオン
・AWS x Mackerel ハンズオン

●わかったこと
・引き合いは多い
・支援はスケールしない

●一番の問題は「分断」
　　支援内容の分断
　　　　Dev vs Ops -> Dev and Ops
　　　　のはずが CI/CDパイプライン と アジャイル開発支援 の分断

●Effective DevOps
　　自動化のことではない
　　アジャイル開発のことではない
　　-> やれてませんでしたw

●気づき
・VSM実施
・ムダなプロセス、改善案の洗い出し
・ボトルネックを見つけて解消
　　隔週の定例承認会議ですねw
・VSMやり直し -> 移動したボトルネックを解消
※当たり前なことに改めて気づいたw

●まとめ
・お客さんのニーズに合わせると、手段が目的化してた
・DevOpsやってなかった
・VSMやろう
-> 無料でワークショップやります！

■Fun! Done! Learn! 〜 実験で学び、学びを喜び、喜びを成果につながるふりかえりを体験しよう！

Jean-Baptiste Vasseur さん
Masashi Arino さん
Tsutomu Yasui さん
Yasunobu Kawaguchi さん

●どうやって Fun! Done! Learn! が生まれたのか？
・2018年 沖縄でコーチが集まって3日間ノウハウ共有
・1日目は遊んだw 2日目は朝からきっちり、ビールのために良い仕事を
・コーチとして
　　何もしないリスク
　　どんな引き出しを持っていれば良いのか
・ふりかえりは、楽しくやってもらえない
　　絵を描いたり工夫していた
　　楽しんでいないと破綻
　　成果を出さないとクビ
　　継続的に学びがないと成長しない
　　-> チームで自己診断できると良い

●なぜいまふりかえるのか？
　　2並走だったから全てはわからない
　　今日ふりかえらないと、楽しかったねーで終わってしまう

●ワーク
・10〜15人くらいでグループをつくる
・スチレンボードで Fun! Done! Learn! ボードをつくる
・DODT に参加して、起きたこと、思ったことを挙げる
・頭に出てきたことを付箋に書いてボードに貼る
・グループの中でシェア
・Fun! Done! Learn! の中を移動させたり、書き足したり
・他のグループを巡る
　　2人残って説明係
　　一定数巡ったら戻って、説明係を交代

参加したグループの Fun! Done! Learn!

■感想

皆さんの一歩ずつカイゼンを積み重ねてきたお話を聞いて、共感と納得を沢山いただけました！

同時通訳を把握する難しさを痛感したので、「英語のまま理解できるようにならなくては！」のモチベーションもいただけました。

カンファレンスの最後にふりかえりのワークショップがあるのは、すてきな構成ですね！学びの定着と広がりを体験できました！懇親会でふりかえりのワークを入れておくとかなら、会話のきっかけにできそうだし、色々なイベントでも参考にできそうですね。

明日もどんなお話を聞けるか、とても楽しみです！！

■Day2の様子