WHY JAPANESE PEOPLE CAN NOT BE AGILE?

WHY JAPANESE PEOPLE
CAN NOT BE AGILE?
2018/07/22(日)
Agile Japan 2018 サテライト＜名古屋＞
名古屋アジャイル勉強会 You&I

ジコ、ショウカイ。
H/N： You&I(読み：ユーアンドアイ)
SNS： @you_and_i
出身：生まれも育ちも名古屋市
年齢： around fourty
本職：商学部出身の職業プログラマ
言語： C++他
所属：プログラミング生放送勉強会名古屋支部長
名古屋アジャイル勉強会
わんくま同盟名古屋勉強会
WHY JAPANESE PEOPLE CAN NOT BE AGILE? 2

ATTENTION
本資料は名古屋アジャイル勉強会
のサイトにて公開致します。
資料の内容について全ての
メモを取る必要はありません。
ワークショップ内容に集中して
頂ければ幸いです。

ATTENTION
各テーブルに１部ずつ、
本資料を印刷したものを
用意しております。
必要に応じて、
資料を見返すのに
ご利用ください。

ATTENTION
質疑応答の時間
を設けておりますが、
もし疑問に思った事があれば、
随時質問して頂いて
大丈夫です。

AGENDA
1. なぜ、アジャイルなのか
2. なぜ、なぜと思わないのか
3. なぜ、ここにいるのか
4. なぜ、まとめるのか

• Agile Japan 2018のテーマは・・・
Why Agile?
• なぜアジャイルに取り組むのか？なぜ自分たち
の組織は変わらなければならないのか？様々な
背景や事情があると思いますし、一人ひとり答
えは異なります。
• また、なぜこの原則は掲げられているのか？なぜ
このプラクティスをやるのか？といった「問い」も、
アジャイルをしっかり理解するためには大切です。

•軽量ソフトウェア開発手法の実践者
達が2001年の2月に米国スノーバード
に集まり、4つの価値と12の原則という
形で、アジャイルソフトウェア開発宣言
が策定されました。
•http://agilemanifesto.org/iso/ja/mani
festo.html

•アジャイル開発を構成するもの
WHY JAPANESE PEOPLE CAN NOT BE AGILE?
アジャイル開発
アジャイル
プラクティス開発
プロセス
開発ツール
プロジェクト
ファシリテー
ション
マインド
トヨタ生産
方式
リーンソフト
ウェア開発
制約理論
(TOC)
ビジネス
アナリシス
10

•アジャイル開発を構成するもの
アジャイル開発
アジャイル
プラクティス開発
プロセス
開発ツール
プロジェクト
ファシリテー
ション
マインド
トヨタ生産
方式
リーンソフト
ウェア開発
制約理論
(TOC)
ビジネス
アナリシス
SCRUM
XP
DAD
SAFe
kanban
git / GitHub
Jenkins
Redmine
JIRA
ふりかえり
朝会
チームビルディング
見える化
自働化
カイゼン活動
なぜなぜ５回
多能工
全体最適化
スパイク
ユーザーストーリー
ペアプログラミング
TDD
継続的インテグレーション
継続的デリバリー
DevOps
Value Stream Mapping
リーンスタートアップ
11

•アジャイル開発のアプローチ方法
http://blogs.itmedia.co.jp/hiranabe/2012/09/rightwing-and-leftwing-of-agile.html
12

•研究社新英和中辞典での「agile」の
意味
•形容詞
1. (動きが)機敏な，はしっこい; 〔…に〕機
敏で，はしっこくて
2. 頭の回転の早い，機敏な，明敏な

•なぜ「agile」開発は機敏なのか
•作業項目が追加されてリリースされるま
での開発サイクルが早い
1. 早く、動くソフトウェアを顧客に提供する
2. 早く、顧客のフィードバックを受ける
3. 早く、チームの状況を知る
4. 早く、失敗する
5. 早く、問題及び原因を見つける
6. 早く、意志決定する
7. 早く、対処・改善する(※要すれば)

確認
•ここまでの説明についてご理解頂けま
したでしょうか？
•表明じゃんけんで理解度をお知らせ
下さい
•グー：お前は何を言っているんだ？
•チョキ：大体理解した。次に進めてOK
•パー：全て理解した。

2. なぜ、なぜ
と思わないのか

•今日はなぜを突き詰めていきます。
•テーマの通りですが、なぜアジャイルを導
入するのでしょうか？
•従来のやり方ではなぜうまく行っていな
いのでしょうか？

•ちょっと皆さんに質問ですが、皆さんの
チームや組織の活動においてなぜ？と
疑問に思う行為がある方はいらっしゃ
いますか？

•改善サイクル手法
•PDCA
1. Plan
2. Do
3. Check
4. Action
•LeanStartupの仮説検証
1. Build
2. Measure
3. Learn

•改善サイクル手法
•PDCA
1. Plan
2. Do
3. Check
4. Action
•LeanStartupの仮説検証
1. Build
2. Measure
3. Learn
← なぜポイント
← なぜポイント

•Measure(計測) 、つまりは予め決めた
何らかのメトリクス(指標)の変動を
チェックする事で、成否判定や状況判
断を行います。
•ベテラン社員の方は、経験的・暗黙
的に上記のような指標を持っていて判
断していますよね。

•また道路の標識だったり、似たものとし
て工場における5S(整理/整頓/清掃/
清潔/躾)活動やKYT(危険予知トレー
ニング)の一環で実施される通路や部
品置き場にラインを引いたりしますが、
これらは正しい行動や状態を明確化
しています。

•開発プロセスにもすぐに異常な状態を
検知できる指標や仕掛けが必要では
ないでしょうか？

1. なぜ、アジャイルなのか(前掲)
•なぜ「agile」開発は機敏なのか
•作業項目が追加されてリリースされるま
での開発サイクルが早い
1. 早く、動くソフトウェアを顧客に提供する
2. 早く、顧客のフィードバックを受ける
3. 早く、チームの状況を知る
4. 早く、失敗する
5. 早く、問題及び原因を見つける
6. 早く、意志決定する
7. 早く、対処・改善する(※要すれば)

1. なぜ、アジャイルなのか(前掲)
•軽量ソフトウェア開発手法の実践者
達が2001年の2月に米国スノーバード
に集まり、4つの価値と12の原則という
形で、アジャイルソフトウェア開発宣言
が策定されました。
•http://agilemanifesto.org/iso/ja/mani
festo.html

•軽量(lightweight)とは何が軽いので
しょうか？
•当然ながら、従来では希に良くある？
試験工程を省いて軽量!?という訳で
はなく、開発プロセスがシンプル且つ単
純明快であるという事です。

27
http://www.extremeprogramming.org/map/project.html

28
http://scrumprimer.org/jp/anime

•アジャイル開発においては、アジャイル
チームのメンバー全員が、チームの状
況を計測する方法を形式的・暗黙的
に理解している事で成り立っています。
•え、ちょっと待って。ウォーターフォールの
場合でも、各担当は役割を理解して
いるし、結果としてやることは変わらな
いのでは？

•日経BP社「業務システムモダナイゼー
ションガイド」P.15 タスク分け
開発工程タスク概要担当
要件定義
機能要件定義製造する機能の一覧化
業務SE非機能要件定義品質目標の作成
基本設計
外部設計画面設計・機能設計
方式設計技術的実現方式の決定アーキテクト
詳細設計内部設計内部モジュール設計
デベロッパー
実装プログラミングコーディング＆デバッグ＆単体試験
テスト
結合テスト機能要件に基づく品質評価
テスター
システムテスト非機能要件に基づく品質評価
※上記の表以外の役割に、PM(プロジェクトマネージャーもいます)

• 開発プロセスと V 字型モデル(同書 P.4)
• 計画型/適応型プロセス(各手法の時間軸は別)
• 計画型:ウォーターフォール型
• 計画型:スパイラル型
• 適応型:アジャイル型
設計実装テスト機能1

•アジャイル開発の場合、
•1チームは10人以下で構成
•早ければ、1イテレーション実施後、動く
ソフトウェアを顧客に見せられ、フィード
バックを受けられる
•各イテレーション実施後のタイミングで、
開発の進め方を柔軟に変えられる

•動画配信サービス大手のNetflixでは、
2010年から障害注入テスト(FIT :
Failure Injection Test)を実施していま
す。
•これは日中の業務時間中にランダム
にクラウドのインスタンスを落とすツール
を動かし、常に障害を発生させる仕
組みです。

•これまでであれば、エラーは起きてはい
けない物として扱われていましたが、シ
ステムが大規模になればなるほど、
様々なエラーが起こりえます。
•いつ起こるか分からないものに対処す
るのは、対策にもコストが掛かるので、
常に発生させてしまうのも1つの考え方
です。またこの手法はセキュリティ対策
においても、有効な手段です。

•開発プロセスについても同じで、自分
が理解していることとそれを実践するこ
とは別物であり、早めに失敗して軌道
修正をかけていく事で、開発プロセス
を成熟させていく事が大事です。

•早く失敗する為の手法を紹介します。
•Premortem Thinking(死亡前死因分析)
•日経BP社「先にしくじる」
•米国心理学者のゲーリー・クライン氏が
提唱するプロジェクトマネジメント手法。
• https://hbr.org/2007/09/performing-a-
project-premortem
•軍事や医療のような「絶体に失敗でき
ない」現場で培われてきた手法。

•Premortem Thinking詳細
•まずプロジェクトが失敗してしまったと仮
定して、何が原因でそうなったのかをリス
ク分析する。
•失敗の原因となる7つの「バイアスの罠」
に対処する。

•Premortem Thinking (バイアスの罠)
1. 現在バイアス
2. オプション選好性
3. 非合理的な信念
4. コンコルド効果
5. 自己中心性バイアス
6. 完璧主義
7. 計画の錯誤

6. 完璧主義
7. 計画の錯誤
ズルズルと
問題を
先延ばしに
してしまう

6. 完璧主義
7. 計画の錯誤
どっちが良いか
決められない

6. 完璧主義
7. 計画の錯誤
勝手な
思い込みで
人間関係を
こじらせる

6. 完璧主義
7. 計画の錯誤
(既に大量の
リソースを投
入しており)
もはや、
引くに
引けない

6. 完璧主義
7. 計画の錯誤
俺たちの
やり方なら
必ず成功
すると
思い込む

6. 完璧主義
7. 計画の錯誤
すべてが
揃わないと
動けない

6. 完璧主義
7. 計画の錯誤
必ず想定外
の事が起こる
(甘い見通し)

•アジャイル開発に限りませんが、開発
プロセスの改善はなぜ？と違和感や
疑問を持つことから始まります。
•なぜ、成功したのか
•なぜ、失敗したのか
•なぜと思うには、今のやり方を理解し
ている必要がありますね。

確認
•ここまでの説明についてご理解頂けま
したでしょうか？
•表明じゃんけんで理解度をお知らせ
下さい
•グー：お前は何を言っているんだ？
•チョキ：大体理解した。次に進めてOK
•パー：全て理解した。

今こうして自分がここにいるのが
良く考えたら凄く不思議で
そこに存在意義を問う
そんな幼い昔の自分の記憶を辿る
Next Life 作詞/作曲:NBGI

•本日は各テーブルのグループ単位で
ワークショップを行いますので、最初に
テーブル内で自己紹介を行います。

•以下の内容でA3用紙に自己紹介を
作成してください。準備できたら1人3
分を目処に自己紹介を行ってください。
1. お名前
2. なぜ今日この勉強会に参加したか
3. 皆さんの所属するチームや組織にお
いて、なぜ？と思ったエピソード(あれ
ば)
WHY JAPANESE PEOPLE CAN NOT BE AGILE? 5115分間

•さて、今回は書籍「リーンシンキング」
で紹介されている「紙封筒」作成ワー
クショップを行います。
•今回は以下の流れでやってみましょう
A) (15分)紙封筒作成のルール決め
B) (7分)封筒作成+(3分)改善
x N回
C) (15分)全体ふりかえり

•紙封筒の作成要件(その1)
1. 付箋紙で作成する事
2. 封ができる事
3. SDカードが入る事
4. 備品は各テーブル1つずつとする
• SDカード/紙封筒
• はさみ
• のり/セロハンテープ

•紙封筒の作成要件(その2)
•封筒作成ワーク事に記録を残してくださ
い。
•このタイミングで表を作成してください。
1回目 2回目 3回目
最初の製品
のデリバリー[秒]
仕掛[個]
完成[個]
受入[個]

A) 紙封筒作成のルール決め
•どのようなルールに基づいて紙封筒を作
成するか、話し合ってルールを作成して
ください。
•作成したルールは付箋紙及びA3用紙
を使って記録に残してください。

B) ルールに基づき紙封筒作成
•最初のデリバリー(完成品)のできた時間
を記録してください。

B) ふりかえり＆改善タイム
•紙封筒作成のふりかえり
•改善提案
•ルール変更した場合は、変更内容を記
録してください

B) ルールに基づき紙封筒作成(最終)
•最初のデリバリー(完成品)のできた時間
を記録してください。
•他のテーブルのやり方を見学します。

C) ふりかえり
•自分達で決めたルールで紙封筒作成
を行ってみて良かった点、悪かった点に
ついて各テーブルでふりかえってください。
• ルールは守られたか？
• 改善できたか？
• 他チームと比較してなぜはあったか？
•またふりかえりで出た意見は、付箋紙に
残すようにしてください。

•各テーブルのふりかえり内容を共有し
ます。
•各テーブルの代表の方はふりかえり内
容について簡単に説明をお願い致し
ます。

3. なぜ、ここにいるのか：補足
•リーンのkanban方式の補足をします
•リーンにおいては、ムダを減らす為とし
て1個流しにプロセスを最適化します。
1回目 2回目 3回目
最初の製品
のデリバリー[秒]
仕掛[個]
完成[個]
受入[個]
この時間が「リードタイム」と呼ばれます。
kanbanは一個流しで作業するので、
どれも同じくこの時間になります。
この値が「スループット」となります。
リーンソフトウェア開発における「未完成作
業のムダ」「待ちのムダ」を表します。

•まとめないと、終わりませんので・・・

•今回のセッションでやったこと
•アジャイルについて
•なぜ、なぜと思わないのか、アジャイル開
発の考え方とPremortem Thinking(死
亡前死因分析)の7つの「バイアスの罠」
の紹介。
•観察眼ワークショップ

最終確認
•今回のワークショップについてご理解頂け
ましたでしょうか？
•表明じゃんけんで理解度をお知らせ下さ
い
• グー
• お前は何を言っているんだ？
• チョキ
• 大体理解した。復習しつつ実践に繋げたい。
• パー
• 全て理解した。早速明日から実践する。

WHY JAPANESE PEOPLE CAN NOT BE AGILE?

Recommended

Recommended

More Related Content

What's hot

What's hot (17)

Similar to WHY JAPANESE PEOPLE CAN NOT BE AGILE?

Similar to WHY JAPANESE PEOPLE CAN NOT BE AGILE? (20)

WHY JAPANESE PEOPLE CAN NOT BE AGILE?