SlideShare a Scribd company logo
社内スタートアップによる組織の成長に
伴い発生する痛みとその解決策について
!
∼スクラム&顧客開発&リーンスタートアップ導入∼
Recruit Holdings
黒田 樹 @i2key
自己紹介
• 黒田 樹 ( @i2key )
• 全世界でシリーズ累計950万DLされているアプリ
(cameran)全体の技術責任者。開発したり、採用したり、
プロセス考えたり、予算考えたり、CTOみたいな何か。
• 社内スタートアップから社外へのスピンオフを目指し精進
中。
コンテキスト調整
• 受託開発文脈ではなく、自社サービス文脈。
• 目的はサービスを契約(QCD+Scope)にあわせて開発するので
はなく、サービスの成長にコミットすること。成長とは機能追
加ではなく、売り上げへの貢献、ユーザー数の拡大、つまり
は、事業の持続可能性の創出へのコミットである。凄い機能を
高いコストをかけて開発したとしても、それに貢献しないので
あれば意味がない。であれば、その機能は開発しないほうがよ
い。ヒト・カネ・ジカンは有限。
• そのパラダイムでお話をします。例えば、スクラムにおいても、
各プラクティス導入の優先順位がそれにより大きく変わります。
20分の発表なのに、テンションあがって
100枚作ってしまったので、
1分5ページの速度で行きます!
結構ページ飛ばすので後で読んで下さい!
スピード注意!!!!
• cameranというアプリにおける組織拡大に
伴い発生した数々の問題とその対処方法につ
いて発表します。
第一部 ヒットからカオスへ


突然の大ヒット。
全ての連鎖の始まりがここに。
!
第二部 師との出会い


恩師との出会い。
そして我々は本当のスクラムを知る。
!
第三部 俺たちはリーンだ!


様々な師達に教えを受け、
リーンスタートアップを会得
そして、自分達のプロセスに昇華
第一部 ヒットからカオスへ


突然の大ヒット。
全ての連鎖の始まりがここに。
!
第二部 師との出会い


恩師との出会い。
そして我々は本当のスクラムを知る。
!
第三部 俺たちはリーンだ!


様々な師達に教えを受け、
リーンスタートアップを会得
そして、自分達のプロセスに昇華
•・ プロジェクト開始時の体制


• プロデューサー
• エンジニア(サーバ)
• エンジニア(iOS)※常駐外部パートナー
• デザイナー
• チームは、メンバー全員の打ち合わせで全ての課題が解
決できる規模だった。
• ウォーターフォールではない、アジャイルのような何か。
省略
大ヒット御礼!!!!
広告・ブースト無しで、
リリース3日で50万DL
10日で100万DL
※今回はヒット後の組織成長の話なので、
そのヒットを作り込んだ過程は省きます
(結果的に後から振り返るとものすごく顧客開発してました)
突然の大ヒットにより、このままイケソウな兆しを
感じた上層部は、更に追加投資することにした。
!
元々、地道に検証しながら進めて行こうとしていた
画像SNS化計画をその資金でフルスロットル開発す
ることが決定。※2ミリもリーンじゃない。
超特大開発の


幕開け
開発規模大きいし、
まずは・・・
エンジニア増加!!
今度はディレクターネック
ディレクター増加!!
今度はディレクタがアライ
アンスに手が回らない
アライアンス担当増加!!
デザイナもデザイナも!
エンジニアも、もっと!!
どうなるか・・・
ちょw体制wwwwwwwww
プロデューサー
デザイナ
エンジニア
Before
アライアンス
デザイナ
エンジニア
ディレクター
プロデューサー
Lead Engineer
Server Engineer
iOS Engineer
Android Engineer
After
\(^o^)/
何が起きるのか・・・??
• 目標に対する成長スピードの鈍化
• やるべきことに着手できていない焦り
• 日々発生する最優先タスクに振り回される現場。最優先の中の最優先と
か・・・。
• 毎日行われる進 会議というなの大検討会&それに浪費される時間
• 伝言ゲームによるコミュニケーションコストの肥大化
• プロデューサー - エンジニア間の発注者-受注者的関係性
• プロデューサー - エンジニア間の関係性の悪化(ギスギスする)
• 技術的負債の山
• 日々詰み上がるバグの山を解決するだけで時間が過ぎていく。
• 現場まで降りてこない方針。価値観。文脈。だから現場判断出来ない。
コミュニケーション①
Lead Engineer
Server Engineer
iOS Engineer
Android Engineer
Engineer team
プロデューサー ディレクター
プロデューサー team
①この仕様ってこ
れでいいのかな?
②ちょっと確認し
てみますね
③ここの仕様で質問
きたのですが、こう
回答していいすか?
④じゃ、それで。
⑤あざーす!
⑥うお・・・wこれインパクト
でけえ・・。サーバエンジニア
以外にも影響でるな・・・。
⑦りょーかいで
す・・・
⑦りょーかいで
す・・・
伝言ゲーム
コミュニケーション②
Lead Engineer
Server Engineer
iOS Engineer
Android Engineer
Engineer team
プロデューサー ディレクター
プロデューサー team
①この機能なるは
やでいれよ!
②ワイヤー作って
調整しますー
③仕様理解しました。各エン
ジニアにディスパッチして工
数の見積もりを依頼します。
④全部やったら1ヶ月くらいか
かるね。(今やってるの全部
手をとめたらね)
④うーん、2週間くらいか
なぁ。(今やってる開発作
業はどうなるんだろ・・・)
⑤現在着手中のもあると思う
ので、バッファ詰んで1.5ヶ月
にしましょう。そう伝えます。
⑥1.5ヶ月ですね。
了解です。
⑦了解です。この間依
頼した機能はまだ出来
上がらないのかな。
ボトルネック
コミュニケーション③
Lead Engineer
Server Engineer
iOS Engineer
Android Engineer
Engineer team
プロデューサー ディレクター
プロデューサー team
①あそこの機能結構やっつけで作っ
たのでリファクタリングしてコード
品質上げましょう。ついでにフレー
ムワークのバージョンもあげましょ
うか。
②いいっすねー!やりま
しょー!1週間くらいあればで
きそうですね!
③技術的負債を解消するためのタス
クがあることを知らない。
知らないとこで


タスク作成
コミュニケーション④
Lead Engineer
Server Engineer
iOS Engineer
Android Engineer
Engineer team
プロデューサー ディレクター
プロデューサー team
①競合が新機能い
れた、やばい、こ
れなるはやで!
②ワイヤー作って
調整しますー
③仕様理解しました。各エン
ジニアにディスパッチして工
数の見積もりを依頼します。
④前回依頼あった実装まだ全
然おわってないのに・・・。
見積もりコストかなりかかる
し・・・。2週間くらいかな。
④1週間くらいかな。
⑤(リファクタリング対象と実装箇
所が被るので、リファクタリングを
実施してから、本タスクは着手しま
しょう。)実装には2週間くらいあ
れば。
⑥2週間ですね。了
解です。
⑦了解です。この間依
頼した機能はまだ出来
上がらないのかな。
知らないとこで優先付け
コミュニケーション⑤
Lead Engineer
Server Engineer
iOS Engineer
Android Engineer
Engineer team
プロデューサー ディレクター
プロデューサー team
①このバグやばい!
なるはやでなおし
て!!!
②そんな重要なバグなのでしょ
うか?了解です。最優先で対
処します。
③了解です!すぐになおしま
す。暫定対処は、すぐだけど、
本格対処は結構工数かかりそ
うだなー。
④今回は本格対処まで実施したいの
で、時間結構かかります。暫定版は
明日リリースします。
⑥了解です。
どんなバグでも最優先対応
コミュニケーション⑥
Lead Engineer
Server Engineer
iOS Engineer
Android Engineer
Engineer team
プロデューサー ディレクター
プロデューサー team
①まだ新機能がリ
リースされない。
何やってんだ!! ②そんなこといわれても、何
でもなるはやじゃないすか。
③こんなに毎日終電や徹夜し
てまで頑張ってるのに、なん
で怒られなくてはならないの
だろう・・・・
ギスギス・・・\((^^oo^^))/
今なら言える失敗
• スケーラブルな組織設計でないのにスケールさせてしまった。管理
能力の高いチームは自らチームの成長を抑制するか、その代わりに
管理キャパシティをスケールさせる。
• バニティメトリクスに支配されていた。表面上のMAUを稼ぐのは人
を増やしてパワーを掛ければ稼げる(ので、人を増やしてしまう)
• プロジェクト計画の方法論、サイクル、カレンダーが無い
• 仕事の優先順位決定のメカニズムが無い
• 明確に定められたバグトリアージとトラッキングが無い
• コミュニケーションチャネル設計が無い
第一部 ヒットからカオスへ


突然の大ヒット。
全ての連鎖の始まりがここに。
!
第二部 師との出会い


恩師との出会い。
そして我々は本当のスクラムを知る。
!
第三部 俺たちはリーンだ!


様々な師達に教えを受け、
リーンスタートアップを会得
そして、自分達のプロセスに昇華
師
USスタートアップの現場で使われている
本当のスクラムを
導入するためにメンターとして
500Startupsのメンター
でもあるJames Levine氏を師として招く
やりたいこと。これへの対処
チームを昔のように小さくする。


みんなで顔を合わせれば
問題は大抵解決するような規模に。
エンジニアをとりまとめるような


エンジニアリーダーロールを廃止する。


全エンジニアが直接プロダクトオーナーと
コミュニケーションするようにチームをフラット化する。
仕事の見える化


タスクおよびそれの規模感の見える化により、
優先付けやトレードオフが機能するようにする。
iOSエンジニアからScrumチーム化
Lead Engineer
Server Engineer
iOS Engineer
Android Engineer
Server Engineer
Android Engineer
iOS Scrum team
Lead Engineer
兼務
旧Engineer team
旧Engineer team
Scrum Master
プロデューサー ディレクター
PO team
Product
Owner
Sub PO
旧プロデューサー team
iOS team
Product
Backlog
Lead Engineerが1st
Sprintのスクラムマス
ターに。
1ヶ月かけてiOSチームをScrum化
その後1Sprint伴走
• Scrumの説明(概要)
• Scrumチームの役割決め(PO、SM、etc)
• Scrumの説明(詳細)
• ProductBacklog作成(PO&SM)
• Grooming
• scrumに関する全ての打ち合わせに参加
• PlanningMTG、DailyStatus、Grooming、(ReviewMeeting)、Retrospective
!
• 1週目 Scrum説明概要1h & 詳細2h
• 2週目 PProductBacklog作成 + FAQ
• 3週目 Grooming + FAQ
• 4週目 Planning実施(伴走開始)
スクラム始めるアルアル
• 見積もりを相対値でやらないといけない
• プランニングポーカーしないといけない
• インセプションデッキつくらないといけない
• ベロシティを計測しないといけない
• タスクはユーザーストーリーでかかないといけない
• みんな自己組織化しないといけない
んなこたぁーない!
プロジェクトのコンテキストにより、
必要なプラクティスは変わるし、型にはめたって意味ない。
最初こんなのどれもやらなかった。
今回のケースで大事なこと
タスクの優先順位付け
ザービスをグロースさせるために、
リソースが適した優先順位で
優先すべき箇所に使われている状態を作ること
価値の順番
• 優先順位付けが出来ること
• そのために、見える化が必要
• タスク全て見える化
• 休み、会議、定常業務、スプリントタスク
• 見積もり
• 日付でいいのよ。無理に相対値見積もりしないでよい。それはチー
ムの練度があがってからでよい。まずはタスクを見える化し、優先
順位付けが機能し、スプリントを回すことが大切。
• 優先順位付けするサイクル・リズムが必要
• プランニング、デイリー、レビュー、レトロスペクティブ
http://www.acunote.com
開発タスク管理
全てのタスクは理想日にて見積もり。
1スプリントの稼働日の合計を出し、
それに合わせてスプリントバックログ
にタスクを入れていく。
!
相対値見積もりは実施していない。
以下の2つにわけて固定のタイムボック
ス化しバグ対応コストを管理。
・将来発生する作業の予約
・既知のバグ修正
バグ対応タイムボックス内で優先順位順
にバグを改修していく。
!
開発タスクとバグ対応タスクに割く、時
間の割合はプロダクトオーナーが状況に
応じてバランスをとる
バグ対応コスト管理
ミーティングコスト管理
全てのミーティングをコスト管理。
!
何時間もかけたミーティングを行うと、
このスプリントで作ることが出来る機能
が減ることを意識させる。
!
振り返りにて、ミーティングを減らす方
向にバイアスがかかる。
休暇予定管理
全ての見積もりが稼働日換算なので、
有給をとる日は、コストとして扱う。
このやり方を
サーバチーム、Androidチームへ、スケール
サーバーエンジニアをScrumチーム化
Server Engineer
Android EngineerLead Engineer
兼務
Scrum Master
Server Scrum team
旧Engineer team
iOS Scrum team
Scrum Master
PO team
Product
Owner
Sub PO
iOS team
Product
Backlog
Server team
Product
Backlog
スクラムマスター
交代
Lead Engineerが1st
Sprintのスクラムマス
ターになり、スクラム
ウェイを伝達していく。
AndroidエンジニアをScrumチーム化
Android Engineer
Scrum Master
Server Scrum team
Android Scrum team
iOS Scrum team
Scrum Master
PO team
Product
Owner
Sub PO
iOS team
Product
Backlog
Server team
Product
Backlog
Scrum Master
Android team
Product
Backlog
スクラムマスター
交代
スクラムマスター
交代
Scrumチーム間の連携のためScrum of Scrums
Scrum Master
Server Scrum team
Android Scrum team
iOS Scrum team
Scrum Master
PO team
Product
Owner
Sub PO
iOS team
Product
Backlog
Server team
Product
Backlog
Android team
Product
Backlog
Scrum Master
Scrum
of
Scrums
スクラムマスター
交代
スクラムマスター
交代
スクラムマスター
交代
バグトリアージ
• バグに対する対応の考え方を変えた。
• 災害医療での1次切り分け。クリティカルかどうかだけの切
り分けを毎日15分くらいで実施。参加者は各スクラムチーム
から1名ずつの計3名。
• 切り分けロジックに従い、バグの優先付けをし、各自スプリ
ント内のタイムボックスで対応する。クリティカルはPO相
談の上、即時対応。
• バグ管理はYouTrackを利用。※理由は宗教的にJetBrains製
品が好きだから。
リリースカレンダー
• リリースの考え方を変えた。
• リリースのタイミングは自動的にやってくる。例:第2週水
曜、第4週水曜。
• そのやってきたタイミングで何をいれるか。
• しかしアライアンス等の影響でリリース日を別途固定する必
要もある。ー>まずは期限優先で作り、技術的負債を次のス
プリントで解消できるように交渉することをルール化した。
http://doda.jp/engineer/it/guide/001/19b.html
参考:「技術的負債」の返済ルールを作る 株式会社ドワンゴ清水氏
その結果
• PO目線
• 働き方のリズムが出来る
• エンジニアの状況がみえる
• 自分のオーダーの規模感が知れる
• エンジニア目線
• タスクがどんどん詰め込まれることが無くなった
• なんでも最優先。がなくなった
• スカンクワークではなく技術的負債対策に臨める
学び
• スクラムを入れたから解決するのではなくて、見える化が進
むので結果的にアクションを打てるタイミングがはやくな
り、問題を小さい段階で早期解決出来る。
• サービスの成長にコミットした瞬間、そのゴールに向かうこ
とが大切になるため、本に書いてある通りのことを全部やろ
うというプラクティス厨にはならなくなる。
• 価値観も大きく変わる。限られたリソースをどう有効に使う
か。これが全てになる。その目線がそろった状態から、各種
プラクティスの導入を行うことが大事。
現在では
• スクラムマスターは持ち回りの当番制
• 全員がスクラムマスターを出来るようになっているため、
各自が自走出来る状態になっている。
• 結果的に、スクラムマスター専業の稼働は減る。
• 自己組織化が進む。
• 振り返りから、プルリク駆動開発の実施やSlack+hubotに
よるChatOpsも実施。プランニングポーカー等各種プラク
ティスも後から導入。
ひとときの平穏
しかし・・・
元々の課題だった
成長スピードの鈍化が
改善されない・・・
そもそも・・・
今やっているタスクは本当に
成長に寄与するものなのか
ここで残り1100分なら
良いペース
第一部 ヒットからカオスへ


突然の大ヒット。
全ての連鎖の始まりがここに。
!
第二部 師との出会い


恩師との出会い。
そして我々は本当のスクラムを知る。
!
第三部 俺たちはリーンだ!


様々な師達に教えを受け、
リーンスタートアップを会得
そして、自分達のプロセスに昇華
新たな問題
• プロダクトバックログに起票されるタ
スクが本当にやるべきことなのか。や
るべき理由はあるのか。
• もっと効率よく出来ないのか
• そのタスク(機能)をリリースしたあ
との効果はタスク(機能)毎にわかる
のか。結果から学びを得ているのか。
リーンスタートアップとか
顧客開発って考え方があるらしい
めっちゃ本読む
• スタートアップマニュアル
• アントレプレナーの教科書
• リーンスタートアップ
• 顧客開発モデルのトリセツ
• RUNNING LEAN
• LEAN UX
• LEAN Analytics
• リーン開発の現場
可能な限り1次ソースの師達に教えをこう
• リーンスタートアップ&顧客開発:500 startupメンター
ジェームズ氏
• グロースハック : AppSocially Founder 髙橋雄介氏
• Design Thinking : IDEO社
• LEAN UXワークショップ:Janice
• 数々の海外スタートアップファウンダーによるケーススタディ
可能な限り1次ソースの師達に教えをこう
新たな価値観
• 小さくトライして小さく失敗し、学ぶこ
と(成功するのではなく失敗の確率を下
げる)
• リスクに対する失敗コストを最小化する
こと
• 全ては仮説であり、それらを1つ1つ検
証すること
• 仮説に対して、効果的な検証方法を考え
行うこと
以下の流れでリーン化
• ビジネス仮説について
• 現状把握のため、顧客開発の流れに沿った現状把握を実施。
ビジネス仮説をリーンキャンバスへの反映。実証できてい
ることと、出来ていないことを明確にする。リスクの高さ
を元に実証すべき優先度をつける。
• プロセスについて
• Build-Measure-Learnサイクルの実現。Buildのカオスを
スクラムで改善したので、次にMeasureを対象に改善。
(今まではMAUやDL数という全体指標でしか確認してい
なかったのでノイズが大量にのっていた)
顧客開発に則って現状の理解をする。
それをリーンキャンバすにまとめる。
やるべきことをやる、既に実証済みのことと、
そうでないこをををとを明らかにする
• 顧客セグメントを明らかにする
• 市場タイプを選ぶ
• 顧客との関係
• キーパートナー
• 売上/プライシング
• 顧客理解
• トラフィック/競合分析
• チームでの情報共有とキャンバス更新
• 顧客の行動測定
• アドバイザリーボードメンバーの選定開始
まだ実証出来ていない仮説に対して
リスクの高い順に優先順位をつけて実証していく
ccaammeerraannのリーンキャンバスは


非公開です。ごめんなさい!!!
実証済
実証済
実証済
実証済
構築→計測→学び
開発(スクラム)と同じようにビジネス側もリズムを作る
Scrumで改善
これから改善したいところ
スクラムの各タスク(機能追加)
の効果(結果)を正しく計測する
• 元々MAUやDAU、AARRRについてはウォッチを
していたが、ファネル分析やコホート分析は見てい
なかった。全てのサマリでみていたため、直接何が
数値に寄与したのかはわかり難い状況だった。
• 検証ポイントまでのUIの問題をファネル分析で発見
• A/Bテスト(スプリットテスト)&コホート分析
https://www.leanplum.com
A/BテストプラットフォームとしてLeanplumを採用
計測例
•仮説
• CameranのSNSアカウント登録率が悪い。現在他
人の投稿はログインユーザーにしか見えない。アカ
ウント非所持者にも見えるようにすることでSNSの
UXを事前体験・学習させるとアカウント登録率があ
がるのはないか。
•MVP
• ログイン不要で他人の投稿を閲覧出来る機能を工数
あまりかけずに、ユーザ数%対象に実装・計測。
•学びたいこと
• SNSアカウント登録率の上昇。及び、既存機能への
悪影響度。
実装した機能毎にコホートxA/Bテストを行い、
様々なトレードオフを意識して判断する。
http://www.localytics.jp
全体の指標モニタリングのために
Localytics採用(GAの代わり)
リリース後はコホートで対象バージョンの
リテンション等を計測。この画面は7日間継続率。
※サンプルデータです!
構築→計測→学び
Scrumで改善
これから改善したいところ
ファネル分析・コホート分析の
計測装置導入で改善
より効果的な学びを得るには?
Janice氏による
LeanUXワークショップ
リーンスタートアップとは科学的アプローチというけれど、
その場合、実験の計画の思考プロセスは逆。
こうじゃなく 実際の思考プロセスは
こう考えて計画する
①仮説
②何を学ぶのか
③必要なデータは?
④どうやって計測する?
⑤必要なものは?
⑥どう構築するか?
思考プロセス
①仮説
②何を学ぶのか
③必要なデータは?
④どうやって計測する?
⑤必要なものは?
⑥どう構築するか?
(MVP案1)A/Bテスト
(MVP案2)ティザーページ
(MVP案3)ユーザインタビュー
思考プロセス
⑥どう構築するか?
(MVP案1)A/Bテスト
(MVP案2)ティザーページ
(MVP案3)ユーザインタビュー
もっとも効果的に学びが得られるMVPはどれか選択する
・費用対効果
・期間
・工数
・この検証方法により回避できる将来のリスク
・この検証方法により逆に発生する将来のリスク
思考プロセス
⑫仮説を調整する
⑪学ぶ
⑩データを元に検証
⑨計測する
⑧完成したMVP
⑦構築する
(MVP)A/Bテスト
実証プロセス
http://www.slideshare.net/aerodynamic/mvp-canvas
この一連の思考プロセス・実証プロセスを
髙橋さんとフォーマット化!
http://www.slideshare.net/aerodynamic/mvp-canvas
仮説
何を学ぶのか
仮説実証に
必要なデータ
条件
MVP構築に
必要なコスト
仮説実証に
必要な時間
回避/発生する
将来のリスク
結果と、得た学び
MVPのタイプ
・紙プロト
・インタビュー
・A/Bテスト
・動くデモ
etc
何を作るのか
どうやってそのMVPで実証するのか
スクラムとかLeanCanvasとか
MVPCanvasとか色々でてきたから
最後に整理
Lean Canvas
<ビジネス仮説>
MVP Canvas
<仮説検証MVPの設計>
Product Backlog
<MVP構築タスク>
Out of
Building!!!
MVPがインタビューの場合
MVPがエンジニア稼働必要な場合
改善タスク
・改善目的A/Bテスト
・計測装置導入
メンテナンスタスク
・技術的負債解消
・OSバージョンアップ対応
・バグ対応
アライアンスタスク
直接仮説検証には
関係ないけど
サービス維持に
必要なタスク
Lean Canvas
<ビジネス仮説>
MVP Canvas
<仮説検証MVPの設計>
Product Backlog
<MVP構築タスク>
顧客
発見
顧客
実証
顧客
開拓
組織
構築
Problem
Solution
Fit
Product
Market
Fit
Pivot
学んだこと
• 全てのプロセスへのインプットは仮説であり、仮説を立てる力がすべて
• 仮説の質があがれば、どんどんゴールに近づく。
• 仮説の質をあげるには、その業界・ドメインに誰よりも詳しくなること。
顧客開発をすること。24時間サービスのことを考えること。常に課題意
識を持つこと。そういう生き方をすること。当たり前だけど再確認。
• リーンスタートアップはあくまで仮説がある前提で、それを科学的+アー
トに実証する方法。だから、リーンスタートアップをやったからといって
成功するわけではないよ!あくまで、失敗による損失を小さくする方法。
バーンアウトしていく資金の中、無駄を省き切り詰めてリスクを取り除い
ていく方法。
• 今も昔も変わらず、これやるだけで成功するなんて方法はない。
学んだこと
Lean Engineer
価値:仮説検証サイクルの速度を上げること
コミット:サービスの成長
生産性:仮説検証できた回数/時間
Not Lean Engineer
価値:開発をやりきること
コミット:開発の完遂
生産性:Step/時間
エンジニアの働き方が変わる
ご清聴ありがとうございました!

More Related Content

What's hot

資金調達入門“以前” スタートアップが資金調達の前に考えること
資金調達入門“以前” スタートアップが資金調達の前に考えること資金調達入門“以前” スタートアップが資金調達の前に考えること
資金調達入門“以前” スタートアップが資金調達の前に考えること
Takaaki Umada
 
正しいものを正しくつくる
正しいものを正しくつくる正しいものを正しくつくる
正しいものを正しくつくる
toshihiro ichitani
 
Design Sprint 概要 / デザインスプリント概要
Design Sprint 概要 / デザインスプリント概要Design Sprint 概要 / デザインスプリント概要
Design Sprint 概要 / デザインスプリント概要
Takaaki Umada
 
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
Masahito Zembutsu
 
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjugフロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
 
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
Yoshiki Hayama
 
君にグロースハックはいらない
君にグロースハックはいらない君にグロースハックはいらない
君にグロースハックはいらない
Takaaki Umada
 
逆説のスタートアップ思考
逆説のスタートアップ思考逆説のスタートアップ思考
逆説のスタートアップ思考
Takaaki Umada
 
スタートアップの戦略&ビジネスモデルの考え方
スタートアップの戦略&ビジネスモデルの考え方スタートアップの戦略&ビジネスモデルの考え方
スタートアップの戦略&ビジネスモデルの考え方
Takaaki Umada
 
スタートアップの"共同創業者"を選ぶ技術
スタートアップの"共同創業者"を選ぶ技術スタートアップの"共同創業者"を選ぶ技術
スタートアップの"共同創業者"を選ぶ技術
Takaaki Umada
 
スクラム再入門
スクラム再入門スクラム再入門
スクラム再入門
Minoru Yokomichi
 
チームワーク、努力、勝利 / スタートアップのチームワークとコミュニケーション
チームワーク、努力、勝利 / スタートアップのチームワークとコミュニケーションチームワーク、努力、勝利 / スタートアップのチームワークとコミュニケーション
チームワーク、努力、勝利 / スタートアップのチームワークとコミュニケーション
Takaaki Umada
 
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
Itsuki Kuroda
 
フロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkanフロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkan
Itsuki Kuroda
 
Design Sprint ガイドブック v2
Design Sprint ガイドブック v2Design Sprint ガイドブック v2
Design Sprint ガイドブック v2
Takaaki Umada
 
あなたのチームの「いい人」は機能していますか?
あなたのチームの「いい人」は機能していますか?あなたのチームの「いい人」は機能していますか?
あなたのチームの「いい人」は機能していますか?
Minoru Yokomichi
 
Let's design MVP #devlove #leanstartup
Let's design MVP #devlove #leanstartupLet's design MVP #devlove #leanstartup
Let's design MVP #devlove #leanstartup
Itsuki Kuroda
 
DAOの定義と仕組みについて.pdf
DAOの定義と仕組みについて.pdfDAOの定義と仕組みについて.pdf
DAOの定義と仕組みについて.pdf
ssuser27ade9
 
ゼロからはじめるプロダクトマネージャー生活
ゼロからはじめるプロダクトマネージャー生活ゼロからはじめるプロダクトマネージャー生活
ゼロからはじめるプロダクトマネージャー生活
Takaaki Umada
 
事業が対峙する現実からエンジニアリングを俯瞰する #devlove
事業が対峙する現実からエンジニアリングを俯瞰する #devlove事業が対峙する現実からエンジニアリングを俯瞰する #devlove
事業が対峙する現実からエンジニアリングを俯瞰する #devlove
Itsuki Kuroda
 

What's hot (20)

資金調達入門“以前” スタートアップが資金調達の前に考えること
資金調達入門“以前” スタートアップが資金調達の前に考えること資金調達入門“以前” スタートアップが資金調達の前に考えること
資金調達入門“以前” スタートアップが資金調達の前に考えること
 
正しいものを正しくつくる
正しいものを正しくつくる正しいものを正しくつくる
正しいものを正しくつくる
 
Design Sprint 概要 / デザインスプリント概要
Design Sprint 概要 / デザインスプリント概要Design Sprint 概要 / デザインスプリント概要
Design Sprint 概要 / デザインスプリント概要
 
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
 
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjugフロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
 
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
 
君にグロースハックはいらない
君にグロースハックはいらない君にグロースハックはいらない
君にグロースハックはいらない
 
逆説のスタートアップ思考
逆説のスタートアップ思考逆説のスタートアップ思考
逆説のスタートアップ思考
 
スタートアップの戦略&ビジネスモデルの考え方
スタートアップの戦略&ビジネスモデルの考え方スタートアップの戦略&ビジネスモデルの考え方
スタートアップの戦略&ビジネスモデルの考え方
 
スタートアップの"共同創業者"を選ぶ技術
スタートアップの"共同創業者"を選ぶ技術スタートアップの"共同創業者"を選ぶ技術
スタートアップの"共同創業者"を選ぶ技術
 
スクラム再入門
スクラム再入門スクラム再入門
スクラム再入門
 
チームワーク、努力、勝利 / スタートアップのチームワークとコミュニケーション
チームワーク、努力、勝利 / スタートアップのチームワークとコミュニケーションチームワーク、努力、勝利 / スタートアップのチームワークとコミュニケーション
チームワーク、努力、勝利 / スタートアップのチームワークとコミュニケーション
 
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
 
フロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkanフロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkan
 
Design Sprint ガイドブック v2
Design Sprint ガイドブック v2Design Sprint ガイドブック v2
Design Sprint ガイドブック v2
 
あなたのチームの「いい人」は機能していますか?
あなたのチームの「いい人」は機能していますか?あなたのチームの「いい人」は機能していますか?
あなたのチームの「いい人」は機能していますか?
 
Let's design MVP #devlove #leanstartup
Let's design MVP #devlove #leanstartupLet's design MVP #devlove #leanstartup
Let's design MVP #devlove #leanstartup
 
DAOの定義と仕組みについて.pdf
DAOの定義と仕組みについて.pdfDAOの定義と仕組みについて.pdf
DAOの定義と仕組みについて.pdf
 
ゼロからはじめるプロダクトマネージャー生活
ゼロからはじめるプロダクトマネージャー生活ゼロからはじめるプロダクトマネージャー生活
ゼロからはじめるプロダクトマネージャー生活
 
事業が対峙する現実からエンジニアリングを俯瞰する #devlove
事業が対峙する現実からエンジニアリングを俯瞰する #devlove事業が対峙する現実からエンジニアリングを俯瞰する #devlove
事業が対峙する現実からエンジニアリングを俯瞰する #devlove
 

Viewers also liked

新規事業・起業を妨げる「ビジネスモデル症候群」とは
新規事業・起業を妨げる「ビジネスモデル症候群」とは新規事業・起業を妨げる「ビジネスモデル症候群」とは
新規事業・起業を妨げる「ビジネスモデル症候群」とは
Lean Startup Japan LLC
 
10分でわかったつもりになるlean start up ~リーンスタートアップって何ですか?~
10分でわかったつもりになるlean start up ~リーンスタートアップって何ですか?~10分でわかったつもりになるlean start up ~リーンスタートアップって何ですか?~
10分でわかったつもりになるlean start up ~リーンスタートアップって何ですか?~
圭 進藤
 
大組織の中でのリーン
大組織の中でのリーン大組織の中でのリーン
大組織の中でのリーン
Taro Kawai
 
つくらない ものづくり ~明日からできるリーンスタートアップ~
つくらない ものづくり ~明日からできるリーンスタートアップ~つくらない ものづくり ~明日からできるリーンスタートアップ~
つくらない ものづくり ~明日からできるリーンスタートアップ~
圭 進藤
 
What is and isn't lean startup
What is and isn't lean startupWhat is and isn't lean startup
What is and isn't lean startupTaro Kawai
 
MVP CANVAS
MVP CANVASMVP CANVAS
LEANSTARTUPアンチパターン #devlove #leanstartup
LEANSTARTUPアンチパターン #devlove #leanstartupLEANSTARTUPアンチパターン #devlove #leanstartup
LEANSTARTUPアンチパターン #devlove #leanstartup
Itsuki Kuroda
 
バリデーションボードを使って新サービス開発をやってみた
バリデーションボードを使って新サービス開発をやってみたバリデーションボードを使って新サービス開発をやってみた
バリデーションボードを使って新サービス開発をやってみたYouki Takai
 
Impact Mapping
Impact MappingImpact Mapping
Impact Mapping
Kenji Hiranabe
 
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB
Itsuki Kuroda
 
デザイン思考のためのアイスブレイク
デザイン思考のためのアイスブレイクデザイン思考のためのアイスブレイク
デザイン思考のためのアイスブレイク
Masanori Kado
 
「ビジネスモデル症候群」 グラフィック版
「ビジネスモデル症候群」 グラフィック版「ビジネスモデル症候群」 グラフィック版
「ビジネスモデル症候群」 グラフィック版
Lean Startup Japan LLC
 
はじめてのリーンスタートアップ
はじめてのリーンスタートアップはじめてのリーンスタートアップ
はじめてのリーンスタートアップ
Lean Startup Japan LLC
 
UXでプロダクトを、チームを、ネクストステージに。
UXでプロダクトを、チームを、ネクストステージに。UXでプロダクトを、チームを、ネクストステージに。
UXでプロダクトを、チームを、ネクストステージに。
Kunihiro Okamura
 
実践リーンエンタープライズ(20161027)
実践リーンエンタープライズ(20161027)実践リーンエンタープライズ(20161027)
実践リーンエンタープライズ(20161027)
Masanori Kado
 
20140211ピクト図解 ビジネスモデルの8パターン
20140211ピクト図解 ビジネスモデルの8パターン20140211ピクト図解 ビジネスモデルの8パターン
20140211ピクト図解 ビジネスモデルの8パターン
I Ueno
 
Blueprint+: Developing a Tool for Service Design
Blueprint+: Developing a Tool for Service DesignBlueprint+: Developing a Tool for Service Design
Blueprint+: Developing a Tool for Service Design
Andy Polaine
 
C#でわかる こわくないMonad
C#でわかる こわくないMonadC#でわかる こわくないMonad
C#でわかる こわくないMonad
Kouji Matsui
 
新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi
新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi
新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi
Itsuki Kuroda
 
10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
10+ Deploys Per Day: Dev and Ops Cooperation at Flickr10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
John Allspaw
 

Viewers also liked (20)

新規事業・起業を妨げる「ビジネスモデル症候群」とは
新規事業・起業を妨げる「ビジネスモデル症候群」とは新規事業・起業を妨げる「ビジネスモデル症候群」とは
新規事業・起業を妨げる「ビジネスモデル症候群」とは
 
10分でわかったつもりになるlean start up ~リーンスタートアップって何ですか?~
10分でわかったつもりになるlean start up ~リーンスタートアップって何ですか?~10分でわかったつもりになるlean start up ~リーンスタートアップって何ですか?~
10分でわかったつもりになるlean start up ~リーンスタートアップって何ですか?~
 
大組織の中でのリーン
大組織の中でのリーン大組織の中でのリーン
大組織の中でのリーン
 
つくらない ものづくり ~明日からできるリーンスタートアップ~
つくらない ものづくり ~明日からできるリーンスタートアップ~つくらない ものづくり ~明日からできるリーンスタートアップ~
つくらない ものづくり ~明日からできるリーンスタートアップ~
 
What is and isn't lean startup
What is and isn't lean startupWhat is and isn't lean startup
What is and isn't lean startup
 
MVP CANVAS
MVP CANVASMVP CANVAS
MVP CANVAS
 
LEANSTARTUPアンチパターン #devlove #leanstartup
LEANSTARTUPアンチパターン #devlove #leanstartupLEANSTARTUPアンチパターン #devlove #leanstartup
LEANSTARTUPアンチパターン #devlove #leanstartup
 
バリデーションボードを使って新サービス開発をやってみた
バリデーションボードを使って新サービス開発をやってみたバリデーションボードを使って新サービス開発をやってみた
バリデーションボードを使って新サービス開発をやってみた
 
Impact Mapping
Impact MappingImpact Mapping
Impact Mapping
 
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB
 
デザイン思考のためのアイスブレイク
デザイン思考のためのアイスブレイクデザイン思考のためのアイスブレイク
デザイン思考のためのアイスブレイク
 
「ビジネスモデル症候群」 グラフィック版
「ビジネスモデル症候群」 グラフィック版「ビジネスモデル症候群」 グラフィック版
「ビジネスモデル症候群」 グラフィック版
 
はじめてのリーンスタートアップ
はじめてのリーンスタートアップはじめてのリーンスタートアップ
はじめてのリーンスタートアップ
 
UXでプロダクトを、チームを、ネクストステージに。
UXでプロダクトを、チームを、ネクストステージに。UXでプロダクトを、チームを、ネクストステージに。
UXでプロダクトを、チームを、ネクストステージに。
 
実践リーンエンタープライズ(20161027)
実践リーンエンタープライズ(20161027)実践リーンエンタープライズ(20161027)
実践リーンエンタープライズ(20161027)
 
20140211ピクト図解 ビジネスモデルの8パターン
20140211ピクト図解 ビジネスモデルの8パターン20140211ピクト図解 ビジネスモデルの8パターン
20140211ピクト図解 ビジネスモデルの8パターン
 
Blueprint+: Developing a Tool for Service Design
Blueprint+: Developing a Tool for Service DesignBlueprint+: Developing a Tool for Service Design
Blueprint+: Developing a Tool for Service Design
 
C#でわかる こわくないMonad
C#でわかる こわくないMonadC#でわかる こわくないMonad
C#でわかる こわくないMonad
 
新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi
新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi
新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi
 
10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
10+ Deploys Per Day: Dev and Ops Cooperation at Flickr10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
 

Similar to 社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創

Odstudy 20120225 エンジニアのための提案力向上セミナー
Odstudy 20120225 エンジニアのための提案力向上セミナーOdstudy 20120225 エンジニアのための提案力向上セミナー
Odstudy 20120225 エンジニアのための提案力向上セミナー
kumi_shiki
 
CEDEC2015講演 チーム開発をスムーズにするために
CEDEC2015講演 チーム開発をスムーズにするためにCEDEC2015講演 チーム開発をスムーズにするために
CEDEC2015講演 チーム開発をスムーズにするために
Takafumi Ikeda
 
コンセプトから実現へ 〜 仮説検証型開発のポイント〜
コンセプトから実現へ  〜 仮説検証型開発のポイント〜コンセプトから実現へ  〜 仮説検証型開発のポイント〜
コンセプトから実現へ 〜 仮説検証型開発のポイント〜
Takeshi Kakeda
 
【Sgt2016】Agile人材の評価とキャリアプラン
【Sgt2016】Agile人材の評価とキャリアプラン 【Sgt2016】Agile人材の評価とキャリアプラン
【Sgt2016】Agile人材の評価とキャリアプラン
Ryota Inaba
 
最新事例にみるサービスデザインという新潮流(I・CON2014)
最新事例にみるサービスデザインという新潮流(I・CON2014)最新事例にみるサービスデザインという新潮流(I・CON2014)
最新事例にみるサービスデザインという新潮流(I・CON2014)IMJ Corporation
 
関西匠塾
関西匠塾関西匠塾
関西匠塾
Hagimoto Junzo
 
[デブサミ関西2013]チケット駆動で プロジェクトチームを加速せよ
[デブサミ関西2013]チケット駆動でプロジェクトチームを加速せよ[デブサミ関西2013]チケット駆動でプロジェクトチームを加速せよ
[デブサミ関西2013]チケット駆動で プロジェクトチームを加速せよ
グロースエクスパートナーズ株式会社/Growth xPartners Incorporated.
 
【参観レポート】Lean startupnight real startup dialog
【参観レポート】Lean startupnight   real startup dialog【参観レポート】Lean startupnight   real startup dialog
【参観レポート】Lean startupnight real startup dialogTsutomu Chikuba
 
サービス改善はログデータ分析から
サービス改善はログデータ分析からサービス改善はログデータ分析から
サービス改善はログデータ分析から
Kenta Suzuki
 
1から学ぶスクラム
1から学ぶスクラム1から学ぶスクラム
1から学ぶスクラム
Keisuke Izumiya
 
非IT企業がWEBサービスやアプリを 新規開発するときの課題と解決方法 〜開発編〜
非IT企業がWEBサービスやアプリを 新規開発するときの課題と解決方法  〜開発編〜非IT企業がWEBサービスやアプリを 新規開発するときの課題と解決方法  〜開発編〜
非IT企業がWEBサービスやアプリを 新規開発するときの課題と解決方法 〜開発編〜
ATTEND biz
 
Ci&T Anti-Software Factory Pattern
Ci&T Anti-Software Factory PatternCi&T Anti-Software Factory Pattern
Ci&T Anti-Software Factory Pattern
Yoshiyuki Ueda
 
アジャイルマネジメントとは?
アジャイルマネジメントとは?アジャイルマネジメントとは?
アジャイルマネジメントとは?
Kiro Harada
 
コンサルビジネスで収益拡大する方法
コンサルビジネスで収益拡大する方法コンサルビジネスで収益拡大する方法
コンサルビジネスで収益拡大する方法
伊藤 剛志
 
Vantan shinsuke miyaki_upload
Vantan shinsuke miyaki_uploadVantan shinsuke miyaki_upload
Vantan shinsuke miyaki_upload
Shinsuke Miyaki
 
Redmineをつかったスクラム開発のはじめの一歩
Redmineをつかったスクラム開発のはじめの一歩Redmineをつかったスクラム開発のはじめの一歩
Redmineをつかったスクラム開発のはじめの一歩kiita312
 
【チームガイドライン】業務設計コンサルタント
【チームガイドライン】業務設計コンサルタント【チームガイドライン】業務設計コンサルタント
【チームガイドライン】業務設計コンサルタント
Flyke1
 
PWC 第4回スライド(111120)
PWC 第4回スライド(111120)PWC 第4回スライド(111120)
PWC 第4回スライド(111120)zoesuke8592
 
受託の会社が調達せずに自社サービスを立ち上げ事業として成立するまでの企画・開発・サポート・マーケティング
受託の会社が調達せずに自社サービスを立ち上げ事業として成立するまでの企画・開発・サポート・マーケティング受託の会社が調達せずに自社サービスを立ち上げ事業として成立するまでの企画・開発・サポート・マーケティング
受託の会社が調達せずに自社サービスを立ち上げ事業として成立するまでの企画・開発・サポート・マーケティング
Yusuke Tamukai
 

Similar to 社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創 (20)

Odstudy 20120225 エンジニアのための提案力向上セミナー
Odstudy 20120225 エンジニアのための提案力向上セミナーOdstudy 20120225 エンジニアのための提案力向上セミナー
Odstudy 20120225 エンジニアのための提案力向上セミナー
 
CEDEC2015講演 チーム開発をスムーズにするために
CEDEC2015講演 チーム開発をスムーズにするためにCEDEC2015講演 チーム開発をスムーズにするために
CEDEC2015講演 チーム開発をスムーズにするために
 
コンセプトから実現へ 〜 仮説検証型開発のポイント〜
コンセプトから実現へ  〜 仮説検証型開発のポイント〜コンセプトから実現へ  〜 仮説検証型開発のポイント〜
コンセプトから実現へ 〜 仮説検証型開発のポイント〜
 
【Sgt2016】Agile人材の評価とキャリアプラン
【Sgt2016】Agile人材の評価とキャリアプラン 【Sgt2016】Agile人材の評価とキャリアプラン
【Sgt2016】Agile人材の評価とキャリアプラン
 
Business designer
Business designerBusiness designer
Business designer
 
最新事例にみるサービスデザインという新潮流(I・CON2014)
最新事例にみるサービスデザインという新潮流(I・CON2014)最新事例にみるサービスデザインという新潮流(I・CON2014)
最新事例にみるサービスデザインという新潮流(I・CON2014)
 
関西匠塾
関西匠塾関西匠塾
関西匠塾
 
[デブサミ関西2013]チケット駆動で プロジェクトチームを加速せよ
[デブサミ関西2013]チケット駆動でプロジェクトチームを加速せよ[デブサミ関西2013]チケット駆動でプロジェクトチームを加速せよ
[デブサミ関西2013]チケット駆動で プロジェクトチームを加速せよ
 
【参観レポート】Lean startupnight real startup dialog
【参観レポート】Lean startupnight   real startup dialog【参観レポート】Lean startupnight   real startup dialog
【参観レポート】Lean startupnight real startup dialog
 
サービス改善はログデータ分析から
サービス改善はログデータ分析からサービス改善はログデータ分析から
サービス改善はログデータ分析から
 
1から学ぶスクラム
1から学ぶスクラム1から学ぶスクラム
1から学ぶスクラム
 
非IT企業がWEBサービスやアプリを 新規開発するときの課題と解決方法 〜開発編〜
非IT企業がWEBサービスやアプリを 新規開発するときの課題と解決方法  〜開発編〜非IT企業がWEBサービスやアプリを 新規開発するときの課題と解決方法  〜開発編〜
非IT企業がWEBサービスやアプリを 新規開発するときの課題と解決方法 〜開発編〜
 
Ci&T Anti-Software Factory Pattern
Ci&T Anti-Software Factory PatternCi&T Anti-Software Factory Pattern
Ci&T Anti-Software Factory Pattern
 
アジャイルマネジメントとは?
アジャイルマネジメントとは?アジャイルマネジメントとは?
アジャイルマネジメントとは?
 
コンサルビジネスで収益拡大する方法
コンサルビジネスで収益拡大する方法コンサルビジネスで収益拡大する方法
コンサルビジネスで収益拡大する方法
 
Vantan shinsuke miyaki_upload
Vantan shinsuke miyaki_uploadVantan shinsuke miyaki_upload
Vantan shinsuke miyaki_upload
 
Redmineをつかったスクラム開発のはじめの一歩
Redmineをつかったスクラム開発のはじめの一歩Redmineをつかったスクラム開発のはじめの一歩
Redmineをつかったスクラム開発のはじめの一歩
 
【チームガイドライン】業務設計コンサルタント
【チームガイドライン】業務設計コンサルタント【チームガイドライン】業務設計コンサルタント
【チームガイドライン】業務設計コンサルタント
 
PWC 第4回スライド(111120)
PWC 第4回スライド(111120)PWC 第4回スライド(111120)
PWC 第4回スライド(111120)
 
受託の会社が調達せずに自社サービスを立ち上げ事業として成立するまでの企画・開発・サポート・マーケティング
受託の会社が調達せずに自社サービスを立ち上げ事業として成立するまでの企画・開発・サポート・マーケティング受託の会社が調達せずに自社サービスを立ち上げ事業として成立するまでの企画・開発・サポート・マーケティング
受託の会社が調達せずに自社サービスを立ち上げ事業として成立するまでの企画・開発・サポート・マーケティング
 

More from Itsuki Kuroda

大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
Itsuki Kuroda
 
カネとAgile(大企業新規事業編) #rsgt2021
カネとAgile(大企業新規事業編) #rsgt2021カネとAgile(大企業新規事業編) #rsgt2021
カネとAgile(大企業新規事業編) #rsgt2021
Itsuki Kuroda
 
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
Itsuki Kuroda
 
大企業アジャイルの勘所 #devlovex #devlovexd
大企業アジャイルの勘所 #devlovex #devlovexd大企業アジャイルの勘所 #devlovex #devlovexd
大企業アジャイルの勘所 #devlovex #devlovexd
Itsuki Kuroda
 
カネとAgile #RSGT2018
カネとAgile #RSGT2018カネとAgile #RSGT2018
カネとAgile #RSGT2018
Itsuki Kuroda
 
Leanstartupをリーンにヤル #リーンスタートアップ
Leanstartupをリーンにヤル #リーンスタートアップLeanstartupをリーンにヤル #リーンスタートアップ
Leanstartupをリーンにヤル #リーンスタートアップ
Itsuki Kuroda
 
結果的に組織がAgileな状態であること #agile #scrum #leanstartup
結果的に組織がAgileな状態であること #agile #scrum #leanstartup結果的に組織がAgileな状態であること #agile #scrum #leanstartup
結果的に組織がAgileな状態であること #agile #scrum #leanstartup
Itsuki Kuroda
 
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkanリーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan
Itsuki Kuroda
 
LEAN STARTUP OVERVIEW
LEAN STARTUP OVERVIEWLEAN STARTUP OVERVIEW
LEAN STARTUP OVERVIEW
Itsuki Kuroda
 
エンジニアが成長のエンジンになる日 #devsumi #natsumiC7
エンジニアが成長のエンジンになる日 #devsumi  #natsumiC7エンジニアが成長のエンジンになる日 #devsumi  #natsumiC7
エンジニアが成長のエンジンになる日 #devsumi #natsumiC7
Itsuki Kuroda
 
LEANSTARTUPの現場 #leanstartup
LEANSTARTUPの現場 #leanstartupLEANSTARTUPの現場 #leanstartup
LEANSTARTUPの現場 #leanstartup
Itsuki Kuroda
 
リーンスタートアップ概論
リーンスタートアップ概論リーンスタートアップ概論
リーンスタートアップ概論
Itsuki Kuroda
 
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove 社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
Itsuki Kuroda
 
Social.framework&Account.framework #twtr_hack
Social.framework&Account.framework #twtr_hackSocial.framework&Account.framework #twtr_hack
Social.framework&Account.framework #twtr_hack
Itsuki Kuroda
 
Play勉強会資料(MTLブログ用)
Play勉強会資料(MTLブログ用)Play勉強会資料(MTLブログ用)
Play勉強会資料(MTLブログ用)
Itsuki Kuroda
 
女子中高生とTwitter4J #twtr_hack
女子中高生とTwitter4J #twtr_hack女子中高生とTwitter4J #twtr_hack
女子中高生とTwitter4J #twtr_hackItsuki Kuroda
 
学生向けAndroid勉強会(入門編)
学生向けAndroid勉強会(入門編)学生向けAndroid勉強会(入門編)
学生向けAndroid勉強会(入門編)
Itsuki Kuroda
 
Nfcハッカソン発表資料
Nfcハッカソン発表資料Nfcハッカソン発表資料
Nfcハッカソン発表資料
Itsuki Kuroda
 

More from Itsuki Kuroda (18)

大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
 
カネとAgile(大企業新規事業編) #rsgt2021
カネとAgile(大企業新規事業編) #rsgt2021カネとAgile(大企業新規事業編) #rsgt2021
カネとAgile(大企業新規事業編) #rsgt2021
 
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
 
大企業アジャイルの勘所 #devlovex #devlovexd
大企業アジャイルの勘所 #devlovex #devlovexd大企業アジャイルの勘所 #devlovex #devlovexd
大企業アジャイルの勘所 #devlovex #devlovexd
 
カネとAgile #RSGT2018
カネとAgile #RSGT2018カネとAgile #RSGT2018
カネとAgile #RSGT2018
 
Leanstartupをリーンにヤル #リーンスタートアップ
Leanstartupをリーンにヤル #リーンスタートアップLeanstartupをリーンにヤル #リーンスタートアップ
Leanstartupをリーンにヤル #リーンスタートアップ
 
結果的に組織がAgileな状態であること #agile #scrum #leanstartup
結果的に組織がAgileな状態であること #agile #scrum #leanstartup結果的に組織がAgileな状態であること #agile #scrum #leanstartup
結果的に組織がAgileな状態であること #agile #scrum #leanstartup
 
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkanリーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan
 
LEAN STARTUP OVERVIEW
LEAN STARTUP OVERVIEWLEAN STARTUP OVERVIEW
LEAN STARTUP OVERVIEW
 
エンジニアが成長のエンジンになる日 #devsumi #natsumiC7
エンジニアが成長のエンジンになる日 #devsumi  #natsumiC7エンジニアが成長のエンジンになる日 #devsumi  #natsumiC7
エンジニアが成長のエンジンになる日 #devsumi #natsumiC7
 
LEANSTARTUPの現場 #leanstartup
LEANSTARTUPの現場 #leanstartupLEANSTARTUPの現場 #leanstartup
LEANSTARTUPの現場 #leanstartup
 
リーンスタートアップ概論
リーンスタートアップ概論リーンスタートアップ概論
リーンスタートアップ概論
 
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove 社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
 
Social.framework&Account.framework #twtr_hack
Social.framework&Account.framework #twtr_hackSocial.framework&Account.framework #twtr_hack
Social.framework&Account.framework #twtr_hack
 
Play勉強会資料(MTLブログ用)
Play勉強会資料(MTLブログ用)Play勉強会資料(MTLブログ用)
Play勉強会資料(MTLブログ用)
 
女子中高生とTwitter4J #twtr_hack
女子中高生とTwitter4J #twtr_hack女子中高生とTwitter4J #twtr_hack
女子中高生とTwitter4J #twtr_hack
 
学生向けAndroid勉強会(入門編)
学生向けAndroid勉強会(入門編)学生向けAndroid勉強会(入門編)
学生向けAndroid勉強会(入門編)
 
Nfcハッカソン発表資料
Nfcハッカソン発表資料Nfcハッカソン発表資料
Nfcハッカソン発表資料
 

社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創