Soumettre la recherche
Mettre en ligne
育てる!かんばん - bring up Kanban.
•
5 j'aime
•
2,697 vues
Maehana Tsuyoshi
Suivre
at Agile Japan 2015 Sapporo Satellite.
Lire moins
Lire la suite
Technologie
Affichage du diaporama
Signaler
Partager
Affichage du diaporama
Signaler
Partager
1 sur 119
Télécharger maintenant
Télécharger pour lire hors ligne
Recommandé
Eric riesstartuplessonslearned2011 ja20110605
Eric riesstartuplessonslearned2011 ja20110605
Yuki Sekiguchi
QCストリー~問題を解決ための手法
QCストリー~問題を解決ための手法
博行 門眞
To cf e_06_中谷_職場の改革は教育のためのtocから
To cf e_06_中谷_職場の改革は教育のためのtocから
TOC for Education, Japan Branch
問題解決プロセス
問題解決プロセス
Kenichi Nagaoka
スクラム適用報告
スクラム適用報告
Eiichi Hayashi
リーンスタートアップ概論
リーンスタートアップ概論
Itsuki Kuroda
小集団活動(QCサークル)の進め方
小集団活動(QCサークル)の進め方
博行 門眞
新規事業・起業を妨げる「ビジネスモデル症候群」とは
新規事業・起業を妨げる「ビジネスモデル症候群」とは
Lean Startup Japan LLC
Recommandé
Eric riesstartuplessonslearned2011 ja20110605
Eric riesstartuplessonslearned2011 ja20110605
Yuki Sekiguchi
QCストリー~問題を解決ための手法
QCストリー~問題を解決ための手法
博行 門眞
To cf e_06_中谷_職場の改革は教育のためのtocから
To cf e_06_中谷_職場の改革は教育のためのtocから
TOC for Education, Japan Branch
問題解決プロセス
問題解決プロセス
Kenichi Nagaoka
スクラム適用報告
スクラム適用報告
Eiichi Hayashi
リーンスタートアップ概論
リーンスタートアップ概論
Itsuki Kuroda
小集団活動(QCサークル)の進め方
小集団活動(QCサークル)の進め方
博行 門眞
新規事業・起業を妨げる「ビジネスモデル症候群」とは
新規事業・起業を妨げる「ビジネスモデル症候群」とは
Lean Startup Japan LLC
人間と話す: Lean Customer Development (Lean Startup Update 2015)
人間と話す: Lean Customer Development (Lean Startup Update 2015)
Takaaki Umada
アジャイルなマインドで行こう! Web
アジャイルなマインドで行こう! Web
minamo
Itで中小企業の生産性向上2
Itで中小企業の生産性向上2
小島 規彰
解説!30分で分かるLEAN ANALYTICS
解説!30分で分かるLEAN ANALYTICS
しくみ製作所
失敗しないパッケージ導入3
失敗しないパッケージ導入3
小島 規彰
失敗しないパッケージ導入1
失敗しないパッケージ導入1
小島 規彰
よくある質問
よくある質問
Takayuki Yamazaki
Eric Ries at Startup Lessons Learned sllconf 2011 - Japanese Translation
Eric Ries at Startup Lessons Learned sllconf 2011 - Japanese Translation
Kenji Hiranabe
「コンバージョン数を2倍にしてくれ」と言われた時の対処法
「コンバージョン数を2倍にしてくれ」と言われた時の対処法
Tsuyoshi Kaneko
Itで中小企業の生産性向上1
Itで中小企業の生産性向上1
小島 規彰
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
Dai FUJIHARA
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
Rakuten Group, Inc.
DevLOVE関西2012 Drive 講演資料(iBook)
DevLOVE関西2012 Drive 講演資料(iBook)
広告制作会社
ファシリテーション講座 Hlab2012
ファシリテーション講座 Hlab2012
Yasuhiro Yoshizawa
Innvaitionの方法論Ⅳ
Innvaitionの方法論Ⅳ
hiroyuki monma
50代現役SEのつぶやき
50代現役SEのつぶやき
Kenichi Yamada
【Schoo web campus】データ分析、その前にやっておくべきこと 先生 田畑直
【Schoo web campus】データ分析、その前にやっておくべきこと 先生 田畑直
schoowebcampus
アジャイル開発を始めてみませんか?(思い出編)
アジャイル開発を始めてみませんか?(思い出編)
Miho Nagase
Y Combinator & スタンフォード大学「スタートアップの始め方 (CS183B)」受講ガイド - Summary of How to Start...
Y Combinator & スタンフォード大学「スタートアップの始め方 (CS183B)」受講ガイド - Summary of How to Start...
Takaaki Umada
「思い込み開発」からの脱却
「思い込み開発」からの脱却
Takashi Tomizawa
Y Combinator 創業者 Paul Graham からのスタートアップへのアドバイス(スタートアップが迷った時に読む Paul Graham から...
Y Combinator 創業者 Paul Graham からのスタートアップへのアドバイス(スタートアップが迷った時に読む Paul Graham から...
Takaaki Umada
はじめてのアジャイル - Agile in a nutshell
はじめてのアジャイル - Agile in a nutshell
Dai FUJIHARA
Contenu connexe
Tendances
人間と話す: Lean Customer Development (Lean Startup Update 2015)
人間と話す: Lean Customer Development (Lean Startup Update 2015)
Takaaki Umada
アジャイルなマインドで行こう! Web
アジャイルなマインドで行こう! Web
minamo
Itで中小企業の生産性向上2
Itで中小企業の生産性向上2
小島 規彰
解説!30分で分かるLEAN ANALYTICS
解説!30分で分かるLEAN ANALYTICS
しくみ製作所
失敗しないパッケージ導入3
失敗しないパッケージ導入3
小島 規彰
失敗しないパッケージ導入1
失敗しないパッケージ導入1
小島 規彰
よくある質問
よくある質問
Takayuki Yamazaki
Tendances
(7)
人間と話す: Lean Customer Development (Lean Startup Update 2015)
人間と話す: Lean Customer Development (Lean Startup Update 2015)
アジャイルなマインドで行こう! Web
アジャイルなマインドで行こう! Web
Itで中小企業の生産性向上2
Itで中小企業の生産性向上2
解説!30分で分かるLEAN ANALYTICS
解説!30分で分かるLEAN ANALYTICS
失敗しないパッケージ導入3
失敗しないパッケージ導入3
失敗しないパッケージ導入1
失敗しないパッケージ導入1
よくある質問
よくある質問
Similaire à 育てる!かんばん - bring up Kanban.
Eric Ries at Startup Lessons Learned sllconf 2011 - Japanese Translation
Eric Ries at Startup Lessons Learned sllconf 2011 - Japanese Translation
Kenji Hiranabe
「コンバージョン数を2倍にしてくれ」と言われた時の対処法
「コンバージョン数を2倍にしてくれ」と言われた時の対処法
Tsuyoshi Kaneko
Itで中小企業の生産性向上1
Itで中小企業の生産性向上1
小島 規彰
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
Dai FUJIHARA
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
Rakuten Group, Inc.
DevLOVE関西2012 Drive 講演資料(iBook)
DevLOVE関西2012 Drive 講演資料(iBook)
広告制作会社
ファシリテーション講座 Hlab2012
ファシリテーション講座 Hlab2012
Yasuhiro Yoshizawa
Innvaitionの方法論Ⅳ
Innvaitionの方法論Ⅳ
hiroyuki monma
50代現役SEのつぶやき
50代現役SEのつぶやき
Kenichi Yamada
【Schoo web campus】データ分析、その前にやっておくべきこと 先生 田畑直
【Schoo web campus】データ分析、その前にやっておくべきこと 先生 田畑直
schoowebcampus
アジャイル開発を始めてみませんか?(思い出編)
アジャイル開発を始めてみませんか?(思い出編)
Miho Nagase
Y Combinator & スタンフォード大学「スタートアップの始め方 (CS183B)」受講ガイド - Summary of How to Start...
Y Combinator & スタンフォード大学「スタートアップの始め方 (CS183B)」受講ガイド - Summary of How to Start...
Takaaki Umada
「思い込み開発」からの脱却
「思い込み開発」からの脱却
Takashi Tomizawa
Y Combinator 創業者 Paul Graham からのスタートアップへのアドバイス(スタートアップが迷った時に読む Paul Graham から...
Y Combinator 創業者 Paul Graham からのスタートアップへのアドバイス(スタートアップが迷った時に読む Paul Graham から...
Takaaki Umada
はじめてのアジャイル - Agile in a nutshell
はじめてのアジャイル - Agile in a nutshell
Dai FUJIHARA
はじめてのアジャイル
はじめてのアジャイル
Rakuten Group, Inc.
リーンスタートアップ7,8章
リーンスタートアップ7,8章
satomi ikoma
どうすれば小さなチームでも大きな成果を出せるのか
どうすれば小さなチームでも大きな成果を出せるのか
Yoshihito Kuranuki
【第2回DMC】人はなぜストーリーを必要とするのか(中野克平氏)
【第2回DMC】人はなぜストーリーを必要とするのか(中野克平氏)
Rod Izumi
Devlove LeanStartupNight インタビュー演習
Devlove LeanStartupNight インタビュー演習
Takashi Tsutsumi
Similaire à 育てる!かんばん - bring up Kanban.
(20)
Eric Ries at Startup Lessons Learned sllconf 2011 - Japanese Translation
Eric Ries at Startup Lessons Learned sllconf 2011 - Japanese Translation
「コンバージョン数を2倍にしてくれ」と言われた時の対処法
「コンバージョン数を2倍にしてくれ」と言われた時の対処法
Itで中小企業の生産性向上1
Itで中小企業の生産性向上1
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
DevLOVE関西2012 Drive 講演資料(iBook)
DevLOVE関西2012 Drive 講演資料(iBook)
ファシリテーション講座 Hlab2012
ファシリテーション講座 Hlab2012
Innvaitionの方法論Ⅳ
Innvaitionの方法論Ⅳ
50代現役SEのつぶやき
50代現役SEのつぶやき
【Schoo web campus】データ分析、その前にやっておくべきこと 先生 田畑直
【Schoo web campus】データ分析、その前にやっておくべきこと 先生 田畑直
アジャイル開発を始めてみませんか?(思い出編)
アジャイル開発を始めてみませんか?(思い出編)
Y Combinator & スタンフォード大学「スタートアップの始め方 (CS183B)」受講ガイド - Summary of How to Start...
Y Combinator & スタンフォード大学「スタートアップの始め方 (CS183B)」受講ガイド - Summary of How to Start...
「思い込み開発」からの脱却
「思い込み開発」からの脱却
Y Combinator 創業者 Paul Graham からのスタートアップへのアドバイス(スタートアップが迷った時に読む Paul Graham から...
Y Combinator 創業者 Paul Graham からのスタートアップへのアドバイス(スタートアップが迷った時に読む Paul Graham から...
はじめてのアジャイル - Agile in a nutshell
はじめてのアジャイル - Agile in a nutshell
はじめてのアジャイル
はじめてのアジャイル
リーンスタートアップ7,8章
リーンスタートアップ7,8章
どうすれば小さなチームでも大きな成果を出せるのか
どうすれば小さなチームでも大きな成果を出せるのか
【第2回DMC】人はなぜストーリーを必要とするのか(中野克平氏)
【第2回DMC】人はなぜストーリーを必要とするのか(中野克平氏)
Devlove LeanStartupNight インタビュー演習
Devlove LeanStartupNight インタビュー演習
Plus de Maehana Tsuyoshi
Stray sheep #ggjsap 2016 UE4 Team
Stray sheep #ggjsap 2016 UE4 Team
Maehana Tsuyoshi
リモートチームとふりかえり改善フレームワーク
リモートチームとふりかえり改善フレームワーク
Maehana Tsuyoshi
Gadget study 1 at SapporoMIRAIstcafe
Gadget study 1 at SapporoMIRAIstcafe
Maehana Tsuyoshi
KanbanとTHETAとDK2とわたし
KanbanとTHETAとDK2とわたし
Maehana Tsuyoshi
How to put out ideas
How to put out ideas
Maehana Tsuyoshi
大きなチーム、大きな仕事 ~ 大規模アジャイル開発のいま
大きなチーム、大きな仕事 ~ 大規模アジャイル開発のいま
Maehana Tsuyoshi
Kaminend-Agile-WorkShop
Kaminend-Agile-WorkShop
Maehana Tsuyoshi
CLR/H78 CI at iOS
CLR/H78 CI at iOS
Maehana Tsuyoshi
Improvement_process_for_providing_ongoing_value
Improvement_process_for_providing_ongoing_value
Maehana Tsuyoshi
Clrh66
Clrh66
Maehana Tsuyoshi
quanp for iPhone appbank japan tour 2nd in sapporo
quanp for iPhone appbank japan tour 2nd in sapporo
Maehana Tsuyoshi
step by step agile
step by step agile
Maehana Tsuyoshi
clrh58
clrh58
Maehana Tsuyoshi
clrh56
clrh56
Maehana Tsuyoshi
Native Smartphone Development with Ruby
Native Smartphone Development with Ruby
Maehana Tsuyoshi
できる!遺伝的アルゴリズム
できる!遺伝的アルゴリズム
Maehana Tsuyoshi
Plus de Maehana Tsuyoshi
(16)
Stray sheep #ggjsap 2016 UE4 Team
Stray sheep #ggjsap 2016 UE4 Team
リモートチームとふりかえり改善フレームワーク
リモートチームとふりかえり改善フレームワーク
Gadget study 1 at SapporoMIRAIstcafe
Gadget study 1 at SapporoMIRAIstcafe
KanbanとTHETAとDK2とわたし
KanbanとTHETAとDK2とわたし
How to put out ideas
How to put out ideas
大きなチーム、大きな仕事 ~ 大規模アジャイル開発のいま
大きなチーム、大きな仕事 ~ 大規模アジャイル開発のいま
Kaminend-Agile-WorkShop
Kaminend-Agile-WorkShop
CLR/H78 CI at iOS
CLR/H78 CI at iOS
Improvement_process_for_providing_ongoing_value
Improvement_process_for_providing_ongoing_value
Clrh66
Clrh66
quanp for iPhone appbank japan tour 2nd in sapporo
quanp for iPhone appbank japan tour 2nd in sapporo
step by step agile
step by step agile
clrh58
clrh58
clrh56
clrh56
Native Smartphone Development with Ruby
Native Smartphone Development with Ruby
できる!遺伝的アルゴリズム
できる!遺伝的アルゴリズム
Dernier
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
iPride Co., Ltd.
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
Toru Tamaki
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
atsushi061452
Utilizing Ballerina for Cloud Native Integrations
Utilizing Ballerina for Cloud Native Integrations
WSO2
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
CRI Japan, Inc.
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
iPride Co., Ltd.
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
CRI Japan, Inc.
新人研修 後半 2024/04/26の勉強会で発表されたものです。
新人研修 後半 2024/04/26の勉強会で発表されたものです。
iPride Co., Ltd.
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
sn679259
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
Toru Tamaki
Dernier
(10)
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
Utilizing Ballerina for Cloud Native Integrations
Utilizing Ballerina for Cloud Native Integrations
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
新人研修 後半 2024/04/26の勉強会で発表されたものです。
新人研修 後半 2024/04/26の勉強会で発表されたものです。
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
育てる!かんばん - bring up Kanban.
1.
THH 育てる! かんばん RICOH IT SOLUTIONS @sandinist Tsuyoshi
Maehana
2.
失敗してますか? 成功してますか? アジャイルしてますか?
3.
失敗と成功 目的・目標・ゴール 達成 = 成功 未達成
= 失敗
4.
失敗と成功 たくさんの名言が http://matome.naver.jp/odai/2140750220162375801
5.
失敗は成功の素派 “成功を祝うのはいいが、もっと大切なのは失敗から学ぶことだ。失 敗にどう対処するかで、会社が社員の良い発想や才能をどれだけ引 き出し、変化に対応していけるかがわかる。どんな会社にも、ミス をして、それを最大限活かしたことのある人が必要だ” ~ ビル・ゲイツ “何かをしようとした時、失敗を恐れないで、やってください。失敗 して負けてしまったら、その理由を考えて反省してください。必ず、 将来の役に立つと思います。” ~ イチロー
6.
失敗なんてアタリマエ派 “一度も失敗をしたことがない人は、何も新しいことに挑戦した ことがない人である” ~ アルバート・アインシュタイン
7.
失敗してなんぼ派 “チャレンジして失敗を怖れるよりも、何もしないことを怖れろ” ~ 本田宗一郎 “失敗は必要なのです。むしろできるだけ早く、失敗するほうがい いでしょう。小さな失敗を積み重ねることによって、成功が見え てきます” ~
柳井正
8.
負けなきゃ勝ち派 “私の最大の光栄は、一度も失敗しないことではなく、倒れる ごとに起きるところにある。私の仕事は失敗の連続であった” ~ 本田宗一郎 “世の中に失敗というものはない。チャレンジしているうちは 失敗はない。諦めた時が失敗である” ~ 稲盛和夫 “失敗したところでやめるから失敗になる。成功するまで続け たら、それは成功になる” ~
松下幸之助
9.
失敗なんてないんだよ派 “わたしは今までに一度も失敗をしたことがない。電球 が光らないという発見を、今まで二万回したのだ” ~ トーマス・エジソン
10.
成功と失敗 失敗 → 経験・学び
→ 成功 素早く、小さく、失敗する 諦めない 失敗なんてない プロジェクト、チーム、組織、人生
11.
アジャイル agile /ǽdʒ(ə)l¦ǽdʒa l/ 形容詞 1
すばしこい, 身軽な, 敏捷(びんしよう)な. 2 (頭の)回転が速い, 賢い. 3 活発な, 生き生きとした.
12.
アジャイル 形容詞 状態 Do Agile ⃝
Be Agile 度合い
13.
アジャイルソフトウェア 開発 ソフトウェア工学において迅速かつ適応的に ソフトウェア開発を行う軽量な開発手法群の 総称 名詞
14.
私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 2001年 アジャイルソフトウェア開発宣言 http://agilemanifesto.org/iso/ja/
15.
Kent Beck Mike Beedle Arie
van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler http://agilemanifesto.org/iso/ja/ James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas © 2001, 上記の著者たち この宣言は、この注意書きも含めた形で全文を含めることを条件に 自由にコピーしてよい。
16.
・顧客満足を最優先し、 価値のあるソフトウェアを早く継続的に提供します。 ・要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方につけることによって、お客様の競争力を引き上げます。 ・動くソフトウェアを、2-3週間から2-3ヶ月という できるだけ短い時間間隔でリリースします。 ・ビジネス側の人と開発者は、プロジェクトを通して 日々一緒に働かなければなりません。 アジャイル宣言の背後にある12の原則 http://agilemanifesto.org/iso/ja/
17.
・意欲に満ちた人々を集めてプロジェクトを構成します。 環境と支援を与え仕事が無事終わるまで彼らを信頼します。 ・情報を伝えるもっとも効率的で効果的な方法は フェイス・トゥ・フェイスで話をすることです。 ・動くソフトウェアこそが進 の最も重要な尺度です。 ・アジャイル・プロセスは持続可能な開発を促進します。 一定のペースを継続的に維持できるようにしなければなりません。 アジャイル宣言の背後にある12の原則 http://agilemanifesto.org/iso/ja/
18.
・技術的卓越性と優れた設計に対する 不断の注意が機敏さを高めます。 ・シンプルさ(ムダなく作れる量を最大限にすること)が本質です。 ・最良のアーキテクチャ・要求・設計は、 自己組織的なチームから生み出されます。 ・チームがもっと効率を高めることができるかを定期的に振り返り、 それに基づいて自分たちのやり方を最適に調整します。 アジャイル宣言の背後にある12の原則 http://agilemanifesto.org/iso/ja/
19.
アジャイルソフトウェア 開発 4つの価値を大切にし 12の原則を実現に向かう そのためのやり方?
20.
Not 方法論・プロセス 方法論というにはあまりに構造に欠けている スクラム かんばん ふりかえり改善フレームワーク http://alistair.cockburn.us/The+end+of+methodology
21.
アジャイルソフトウェア 開発 4つの価値を大切にし 12の原則を実現に向かう 集団が育つための枠組み
22.
http://www.versionone.com
23.
スクラム
24.
イベントと成果物 2-4週間 24時間 1∼4週間
25.
制約内で価値の高い プロダクトとなるよ うに要求を出す 要求をちゃんと意味 のある成果物として 提供し続ける ちゃんと円滑に仕事 のやり取りができる ようにする 1911年10月24日月曜日 https://speakerdeck.com/nawoto/summary-of-scrum-guide
26.
27.
育てる! かんばん RICOH IT SOLUTIONS @sandinist Tsuyoshi
Maehana
28.
• Tsuyoshi Maehana
@sandinist • at Work: C# -> Ruby -> Objective-C • 基幹系業務システム開発 • リコー北海道 2003 2009 • Web αサービス開発 • iOS App 開発
29.
大きな組織 • 株式会社リコー 1936年2月6日
設立 • 連結売上高 2兆1,956億円 (2014年3月期) • 連結対象子会社・関連会社 223社(2014年3月31日現在) • 連結従業員数 108,195名 (2014年3月31日現在) • リコーITソリューションズ株式会社 • 従業員数 923名(2014年7月1日現在) http://jp.ricoh.com/company/data/
30.
https://theta360.com/
31.
2009 2015 Team オンラインストレージ Web/iOS その他 iOS/Server RICOH THETA iOS
32.
2009 2015 Team 2名 6名 +1 +1 +1
+1 -1 +2 -1 5名
33.
2009 2015 Team 2名 6名 +1 -1 +2
-1 5名 ・全体では6~10チームの大きなチームの内のひとつ ・プロセスや進め方は時とともに変化し続けている ・XP, Scrum, Lean, Kanban +1 +1 +1
34.
・主担当のコンポーネントはあるが横断的 ・各チームが開発を完了させる ・開発基盤や運用保守のチームもある
35.
大きなチーム 大きな仕事 リコーITソリューションズ株式会社リコーITソリューションズ株式会社 前鼻毅前鼻毅 大規模アジャイル開発のいま 大きなチーム 大きな仕事 http://www.flickr.com/tahosock/ アジャイルソフトウェア開発セミナー2013 in 札幌 Aug,
8 2013
36.
要求元 開発チーム 構造 大きな要求の 一覧を一緒に作る
37.
構造 運用監視 インフラ 開発 品質 UX
技術調査 企画 マーケ PO PO L
38.
構造 運用監視 インフラ 開発 品質 UX
技術調査 企画 マーケ PO PO L TL TL TL TL TL TL
39.
大きな 要求 チーム の作業 1ヶ月 デモ 2週間
40.
https://www.atlassian.com/
41.
EMLauncher irc
42.
2009 2015 Team オンラインストレージ Web/iOS その他 iOS/Server RICOH THETA iOS 2014/4/15 物理かんばん導入
43.
タスク管理の変遷 • Excel • 影舞 •
Trac • Pivotal Tracker • JIRA
44.
https://www.atlassian.com/
45.
かんばん •Icebox •ToDo •Doing •Deliver •Accept
46.
ポイント • 大きな組織の中、複数のチームが協働 • プロダクト・サービスのライフサイクルより長いチーム •
いわゆるアジャイルな開発をふつうに行っている環境
47.
かんばん
48.
http://limitedwipsociety.ning.com/photo/formula-kanban
49.
http://leansoftwareengineering.com/ksse/scrum-ban/
50.
かんばん • リーン生産方式におけるカンバン(TOYOTA方式) • 物理的なタスクボードを指すカンバン •
ソフトウェア開発手法としてのカンバン方式(Kanban)
51.
かんばん方式 • スーパーマーケット方式 • 顧客の必要とする品物を、必要なときに、必要な量だけ在庫 •
ジャストインタイム • 顧客である後工程が、必要な部品を、必要なときに、必要な 量だけを前工程に取りに行く
52.
かんばん方式 http://www.toyota.co.jp/jpn/company/vision/production_system/ just.html
53.
かんばん方式 http://www.toyota.co.jp/jpn/company/vision/production_system/ just.html
54.
物理的なボード自体
55.
かんばんシステム • David J.
Anderson によって纏められた理論 • 一言でKanbanを言うのは難しいが、2009年10月時点で は、ソフトウェア開発のフローを見える化し、WIP(Work in Progress=仕掛)を制限することで、顧客価値のスループット を上げ、同時に改善を促す活動 平鍋健児 • 文化的変革がおそらく最大の利点である David J. Anderson
56.
かんばんシステム • 既存のプロセス(バリューストリーム)からスタート • プロセスの変更を強制しない •
量を制限し、流れを良くする • フローと計測から、問題が可視化される • 改善機会を増やせる
57.
David J.Anderson https://www.flickr.com/photos/jimdo_com/8537959610
58.
David J.Anderson https://www.flickr.com/photos/jimdo_com/8537959610 Nov. 2009
59.
https://www.flickr.com/photos/jimdo_com/8537959610 Nov. 2009 Sep. 2014 David
J.Anderson
60.
2009 2015 オンラインストレージ Web/iOS その他 iOS/Server RICOH THETA iOS 2014/4/15 物理かんばん導入
61.
2014年4月
62.
導入の目的 • 可視化のさらなる向上 • タスクの流れの整理、調整 •
異常発見を容易に • 状態の追加、調整 • 計測を簡易に行う仕組みの導入
63.
64.
65.
66.
67.
68.
69.
70.
2014年5月
71.
イテレーションの情報追加 バグレーン廃止
72.
狙い・理由 • イテレーションの残日数と完了項目数を追加 • イテレーションゴール達成できるかどうかを考えや すくする •
バグを区別して管理する必要がなかった • ふつうの課題と同じように対応する
73.
2014年7月
74.
Doneレーンを追加 ParkingLotを廃止し、Assignのレーンを追加
75.
狙い・理由 • チームの作業が完了していることを明示するために Doneレーンを追加 • 次の作業担当を決めることが多かったので、プロセス にあわせて調整
76.
2014年10月
77.
エピックレーン、ドッグフード、リリース待ちを廃止
78.
Blockレーンを追加し、ParkingLot復活 現在のイテレーションレーンを拡大
79.
狙い・理由 • 物理かんばんは完全にチームのもの • チーム境界とかんばんが一致するように調整した •
優先度が高いが、Readyになっていないものをあらわ すためにBlockレーンを追加 • 中断されている、棚上げにしていることを明示するた めにParkingLot復活
80.
半年間 ここまでのまとめ
81.
物理かんばんの利点 • 可視性 • 常にある、視線を向けるだけで見える •
異常がすぐに分かる(物理的制約がある) • プロセスが全員に明確に伝わる • 他のチームにも否応なく見える
82.
物理かんばんの利点 • 可変性 • 皆の目の前で動かせる •
調整しやすい • ベースとしての役割 • 集まる場所 • チームの一体感
83.
物理かんばんの欠点 • 場所をとる • そこにいないと見えない •
電子と二重管理になる • 会社の決まり事との戦い
84.
二重管理 • DRY原則 • 役割が違った •
ストックとフロー • パッと見で必要な情報と、伝えるためや残しておくための 情報は違う
85.
導入の結果 • 可視化のさらなる向上 →
⃝ • タスクの流れの整理、調整 → ⃝ • 異常発見を容易に → ⃝ • 状態の追加、調整 → ⃝ • 計測を簡易に行う仕組みの導入 → ⃝
86.
導入の結果 • 可視化のさらなる向上 →
⃝ • タスクの流れの整理、調整 → ⃝ • 異常発見を容易に → ⃝ • 発見した異常への対処 → △ • 状態の追加、調整 → ⃝ • 計測を簡易に行う仕組みの導入 → ⃝ • 計測した結果の活用 → △
87.
かんばん本読んだ
88.
かんばん本との比較 • ① 品質に集中する •
低い品質は最大のムダ、失敗のコスト • ある程度できてる • ② 仕掛りを減らす • リトルの法則、仕掛りが増えるとリードタイムが長くなる • 作業の割り込みや切り替えはムダ • もともと一人基本1つで、最大2つまで
89.
• ③ デリバリーを頻繁に行う •
顧客から信頼を得る • 頻繁なリリースは品質を高める、暗黙知の劣化を防ぐ • 定期的なリリースはできているが、毎イテレーション ではない。内部リリースコストは安いが、外部リリー スのコストが高い • ④ 要望とスループットのバランスを取る • ゆとりをつくる、たゆまぬ改善を行えるように • 戦略的なリリース物で手一杯になることも かんばん本との比較
90.
• ⑤ 優先順位をつける •
ビジネス価値の最適化 • 優先順位は顧客と調整できている。ビジネス価値の 最適化までは出来ていないのではないか。リリース 後の計測をビジネス判断に活かしきれていない。 • ⑥ ばらつきの要因を解消する • 上級のテーマ、予測可能性を向上する • ばらつかないことなど無い • 書籍の例は保守サービス かんばん本との比較
91.
2014年12月
92.
優先度別レーンの導入(Planed, Normal, Free) 担当をレーンからマグネットへ
93.
課題タイプの見直し(Story, Chore, Fix,
Kaizen) 計測方法の見直し
94.
目的 • 生産性の向上 • ムダの削減(Fix,
Choreを下げる) • 優先度や課題タイプごとの実績を計測する • 計測結果から改善を行っていく • 改善活動を行いやすくする • デリバリリズムをつくる • リリースコストを下げる
95.
背後にある考え • かんばんの3種の改善機会 • Theory
of Constraints (Eliyahu M. Goldratt) • Lean and Toyota Production System • Profound knowledge (W. Edwards Deming)
96.
TOC • The Goal
1984 • 制約条件の理論 • ボトルネックを識別し、管理することによって、全体のスルー プットを向上させる • かんばんの一連の流れから、制約になる資源を見つける。制 約にプロセスを合わせる、補強する。
97.
Lean & TPS •
ムリ・ムダ・ムラの削減 • コスト削減の部分最適に偏るのは間違ったリーン(アンチパ ターン) • 全体最適、価値の最適化
98.
リーンの経済モデル 失敗のコスト、取引コスト、調整コスト
99.
その活動はコスト? • 「この活動が本当に価値を付加するとして、そのための時間 を増やすべきだろうか?」 • 答えがNoならそれは、必要なムダか、不要なムダのどちらか
100.
Profound Knowledge • W.
Edwards Deming • 20世紀で最も偉大な経営科学者としばしば言われる • 統計的プロセス制御(SPC)から品質保証、経営科学まで • かんばんの基礎では、ばらつきがパフォーマンスに与える影 響について取り上げる
101.
ばらつきについて at かんばん本 • Walter
A. Shewhart • 偶然原因によるばらつき 内部要因 • 不可避原因によるばらつき 外部要因 • 内部要因によるばらつきを改善する • 作業項目のサイズ、タイプ、優先度の分類を分けて管理・計 測することによって、ばらつきによる影響を分けて捉える
102.
Joy of Work •
吉田耕作 • デミング博士の直弟子、世界に10人に満たない、デミング/ マスターのひとり • 日本に Total Quality Management (TQM) を広めている
103.
ばらつきについて at Joy of
Work • 異常原因のばらつき • 原因をつきとめ、是正する必要がある • 偶然原因のばらつき • 広範囲の問題、トップマネジメントの責任
104.
ビーズの実験 • 4000個の白いビーズと1000個の赤いビーズを1つの箱のなかに • 1回に50個ビーズをすくい上げる、これが1日の生産量と考え る。4日間繰り返す •
赤玉3個以下という目標はどんなに逆立ちしても偶然でしか得 られない。目標はむしろモチベーションを下げる • 個人個人のパフォーマンスの最大の要因は、偶然以外の何者で もない • パフォーマンスはシステムによって決められており、個人とし てはどうすることもできないものが多い
105.
2015年3月
106.
課題タイプの再見直し 計測方法の再見直し 優先度別レーンから目的別レーンへ
107.
狙い・理由 • 課題タイプの再見直し、リーンのコストモデルと統一 • 計測を書く課題タイプごとにし、優先度別に見るのは 止める •
優先度別レーンによって、仕事の詰まり具合は可視化 されたが、ばらつき別の管理にはあまり効果が感じら れなかった • 優先度よりも目的別(後述)を管理対象の優先におい た
108.
課題タイプ1 • 価値(青) • この課題が完了すると価値が生まれるもの •
複数に分割されている場合もある • 例:機能リリースに関する課題 • 改善(緑) • コストを下げるための出来る活動、チームが嬉しい活動 • 例:CI環境構築、リリースをラクにするための活動、モ ヤっとをスッキリにする活動
109.
• 失敗コスト(ピンク) • なんらかの失敗に対して必要となってしまった作業 •
例:バグ対応、技術的負債の返却 • 取引コスト(黄色) • 直接価値は生まないが、届けるために必要な作業 • 例:リリースのための作業、レビュー、プラットフォーム のアップデート対応 • 調整コスト(オレンジ) • 課題を進めるために必要になる活動 • 例:事前に検討が必要な設計、技術調査、デザイン依頼、 会議招集、外部チームとのやりとり 課題タイプ2
110.
• Business レーン •
ビジネス・POの視点・機能・AWC • Development レーン • コード・技術・開発チームの視点 • Kaizen レーン • チームプロセス・やると嬉しい事・気になることをスッキ リさせる・SMの視点 目的別レーン
111.
• 朝会で1日1改善を話す • よかったことを褒める •
ちいさな改善を継続的に • Kaizenレーンを使う • 気になることや、やったほうが良いことを残す • 取引コストや調整コストを下げる活動を行いやすく プチ改善
112.
背後にある考え
113.
https://speakerdeck.com/nawoto/talk-about-agile-at-developers- summit-2015
114.
技術的負債 https://speakerdeck.com/kentaro/rethinking-technical-debt 意図的な負債は 失敗コストではなく 改善の活動にする (そのほうがモチベも 上がりやすい)
115.
目的→結果(中間報告) • 生産性の向上 • ムダの削減(Fix,
Choreを下げる)→ △ • 見なおしの観点、機会は増えた • 優先度や課題タイプごとの実績を計測する → ⃝ • 計測結果から改善を行っていく → • その時やる課題やばらつきに大きく左右される、長 いスパンで計測する見る必要がある • 改善活動を行いやすくする → ◎ • デリバリリズムをつくる → △ • リリースの工数削減中、もうすこし!
116.
まとめ
117.
• 失敗と成功はひとつながり。成功はひとつじゃない • かんばんは既存プロセスがベースなので、はじめる のが怖くない •
自分たちで工夫し、改善していく文化を育てやすい • かんばんを育てる過程と背後にある考え方について 示した • 改善の3つの機会 • ビジネス側面、技術的側面、チーム環境の側面 そ れぞれが、ともにすべて大切
118.
多くの現場でより良いやり方を育てる助けに 学びを持ち寄って、楽しく、いきいきとさらなる学びへ
119.
Fearless Start with
Kanban to Change the World.
Télécharger maintenant