1. DevOpsお悩み相談室 ∼カイゼンの文化を組織に根付かせるために∼ 2016年7月29日 吉羽 龍太郎 [Ryuzee.com] / 永瀬 美穂 [産業技術大学院/YEAH GO] / 安井 卓 [MonotaRO] / 原田 騎郎 [アトラクタ]
2. 本セッションの趣旨 ✤ 事前にオンライン上で募ったみなさんのカイゼンにおけるお悩みに対して パネリストが回答をしていくセッションです ✤ 多くの質問を頂きましたので、その中から多くいただいたものを中心に取 り扱っていきます ✤ 時間の都合で全部ご紹介できない場合があるかもしれません…
3. パネリストの紹介 永瀬美穂 安井 卓 原田 騎郎 吉羽 龍太郎 アジャイルコーチ 産業技術大学院大学特任准教授 YEAH GO 受託開発の現場でWebアプリケー 株式会社MonotaRO 株式会社アトラクタ 代表取締役 Ryuzee.com クラウドコンピューティング、 DevOps、インフラ構築自動化、ア ションエンジニア、プロジェクトマネー ジャーとしての経験を重ね、2009年 頃より所属組織でのアジャイルの導 入と実践を通じ組織マネジメントを 行う。現在は顧客へのアジャイル導 入支援、教育研修、コーチングをし ながら、産業技術大学院大学で教 を執っている。 執行役 IT部門長 ソフトウェアエンジニア。2001年よ り VA Linux Systems Japan や OSDN にて Slashdot Japan（現スラ ド）や SourceForge.JP（現 OSDN）を立ち上げ、日本でのオー プンソースの普及の一翼を担う。 2010年楽天に転職し、検索システム の開発・運用を行う。2014年に株式 会社MonotaROに転職し現職就任。 アジャイルコーチ、ドメインモデラ、 サプライチェーンコンサルタント。 認定スクラムプロフェッショナル。 外資系消費財メーカーの研究開発を 経て、2004年よりスクラムによる開 発を実践。ソフトウェアのユーザー の業務、ソフトウェア開発・運用の 業務の両方を、より楽に安全にする 改善に取り組んでいる。 ジャイル開発、組織改革を中心にオ ンサイトでのコンサルティングとト レーニングを提供。認定スクラムプ ロフェショナル（CSP） / 認定スク ラムマスター（CSM） / 認定スクラ ムプロダクトオーナー（CSPO）。 Developers Summit 2016ベストス ピーカー(1位)。
4. CASE1：カイゼンより安定が重視されてしまう ✤ 営業部門の案件管理のＩＴ化に取り組んでいます。 改善よりも安定重視、新しいことを覚えるのが嫌だ、新しいことをしてト ラブルになるのが嫌だ、不便でも何でも今のままでいい。という考え方が 強く、Excel管理から脱却できないのですが、どのように進めたらよいで しょうか？ コンサルティング / 開発エンジニア
5. Training within Industry ✤ 米国旧陸軍省、戦時労働力委員会の作成した、 企業内トレーニングプログラム
7. Job Methods / 改善のやり方 ✤ E - やめる - Eliminate ✤ C - 一緒にやる - Combine ✤ R - 順序を変える - Rearrange ✤ S - シンプルにする - Simplify
8. CASE2：問題解決が後回し ✤ メンバーが発言できる場や時間を設けることで問題を発見し、具体的にど うするかを考えるようにしています。いろいろな問題は出てきますが、ク リティカルではない問題は後回しにしがちで結局未解決のまま時間が過ぎ ることがあります。どのように取り組んでいけばよいでしょうか？ 受託・SI / 開発エンジニア / リーダー・マネージャー
9. CASE3：カイゼン内容の周知 ✤ チーム内で改善をすすめるために、Skypeのチャット機能を使って改善内 容や参考URLを、チームに伝えていますが、改善内容が周知できたか分か りません。改善が周知できたかどうかをどのように確認すれば良いでしょ うか？ コンサルティング / 運用エンジニア / リーダー・マネージャー
10. CASE4：組織の「復元力」 ✤ 頑張ってカイゼンした成果が、担当替えで離れたとたんゼロに戻ってしま うという「組織の復元力」との戦い方（例：SVN/Git＋Issue管理ツール ＋CI→日付フォルダ＆タイムスタンプ＋Excel課題管理＋人力ビルド）を 教えてください。 「引継ぎをきちんとする」（やっても効果なかった）や「転職する」以外 の前向きな回答をお願いします。 事業会社 / 開発エンジニア / リーダー・マネージャー
11. CASE5：カイゼンしやすいチーム？ ✤ 開発部門のカイゼンを進めているのですが、チームメンバーが自分の仕事 にしか興味を持たなかったり、短期的なゴール以外の活動を自ら制限して しまったりすることがあります。このような人たちをどのように巻き込め ばよいですか？またみなさんがほしい最高のチームとはどんなチームです か？ 受託・SI / 開発エンジニア / リーダー・マネージャー
12. CASE6：カイゼンの進め方 ✤ カイゼンを進める上で以下のような課題があります。どうしたらよいでしょ うか？ ✤ 開発と運用部門が別れた縦割り組織で、改善の範囲や速度が限定 ✤ ビックバンな改善を周囲から望まれること（失敗する可能性が高い） ✤ 小さな連続的な改善によって成功体験を重ねつつ、変化し続けること の重要性が理解されにくい ✤ 変化を受け入れない層に対してのフォロー 事業会社 / 運用エンジニア / リーダー・マネージャー
13. 流れが価値を生んでいるかを 価値を生み出すよどみない 流れができている • 仕事を安全かつ簡単にこ なせる • 時間、リソース、エネル ギーに余裕がある • 新しい流れを作れないか 確かめる: 新しい流れ をつくる • スピードを落とす / 止まる 漏れを 止める • プロセスがどう動いている かを観察する • 必要ならプロセスを足す • 効果に注目する • 効率は気にしない 考える時: • 非連続的プロセスの変更 • 製品の定義の変更 流れをよどみなく: 流れを よどみなく • 妨害をとりのぞく • 必要な入力を減らす (リソース / 手間 / 時間) • • • • ここでは効率が大事 ムダ取り 品質やアウトプット量はそのままで 品質をあげようとしたり、アウトプッ トを増やそうとしない
14. CASE7：経営と現場の期待値が違う ✤ 現場は体感できる効果や継続性を重要視したカイゼンを望みますが、一方 で、経営/管理層は見える形=短期的な成果(主にプロセスや数字の軌跡)の カイゼンを望む傾向にあります。最初は良いのですが、最終的に目的がブ レ始めどちらも中途半端になってしまうことがあります。現場ではトライ アンドエラーがやり辛くなったり、疲弊していくため、カイゼン文化が根 付かずカイゼンが単にタスクとなってしまいます。現場と経営のそれぞれ にとって良いアプローチや体験はないですか？ また、カイゼン文化が浸透していない風土の中でカイゼンを継続していく ためのコツや面白いアプローチやエピソードがあればお聞かせください。 受託・SI / 非エンジニア / リーダー・マネージャー
15. CASE8：スクラムの定着方法 ✤ 開発プロセスをカイゼンするためにスクラムを導入しましたが、みんななん となくこなすだけになっており、カンバンや朝会も形骸化しています。今の やり方はうまく回っているようにも見えますがが、みんなにもっと真剣にス クラムに取り組まないといけないと思ってもらうにはどうしたら良いですか？ ✤ 現状では、スクラムマスターという役割の人がおらず、チーム内にスクラム について深く理解している人はいません。またマネージャーはいますが、他 の業務に追われてスクラムがうまく機能するような取り組みは行えていませ ん。この状況でうまくいかせるには、一度、開発者の中から誰かをスクラム マスターにする、といった取り組みが必要でしょうか？ 事業会社 / 開発エンジニア
16. CASE9：カンバンを習慣化するには？ ✤ カンバンをやり始めてもなかなか習慣化できないのですが、何かよいアイ デアがあれば紹介してください。 いまは以下のような課題があります。 ✤ 付箋化しにくいタスクがある ✤ 更新してくれない（レビュー後にDoneに移動してくれない） ✤ リモートワークとの共存が難しい 事業会社 / 開発エンジニア / リーダー・マネージャー
17. CASE10：サービスの部分障害の把握方法 ✤ サーバーの設定を変更したことで、Webシステムの一部の機能が使えなく なってしまう問題が起こったことがあります。たとえばWebページ自体は 閲覧できても、フォームやアクセス解析など一部のみで問題が起こると発 見が遅れてしまいます。どのようにすれば機能単位の機能停止を早く発見 できるでしょうか？ コンサルティング / 運用エンジニア / リーダー・マネージャー
