Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
プロジェクトのすすめ vol.1 #TechLunch
Search
Livesense Inc.
PRO
April 21, 2014
Technology
64
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
プロジェクトのすすめ vol.1 #TechLunch
プロジェクトのすすめ vol.1
2012/07/04 (水) @ Livesense TechLunch
発表者:島田 喜裕
Livesense Inc.
PRO
April 21, 2014
More Decks by Livesense Inc.
See All by Livesense Inc.
Rubyはただの⾔語に⾮ず
livesense
PRO
0
500
28新卒_Webエンジニア職採用_会社説明資料
livesense
PRO
0
120
27新卒_総合職採用_会社説明資料
livesense
PRO
0
6.7k
27新卒_Webエンジニア職採用_会社説明資料
livesense
PRO
0
12k
株式会社リブセンス・転職会議 採用候補者様向け資料
livesense
PRO
0
530
株式会社リブセンス 会社説明資料(報道関係者様向け)
livesense
PRO
1
1.8k
データ基盤の負債解消のためのリプレイス
livesense
PRO
0
670
26新卒_総合職採用_会社説明資料
livesense
PRO
0
13k
株式会社リブセンス会社紹介資料 / Invent the next common.
livesense
PRO
2
72k
Other Decks in Technology
See All in Technology
My broken English still works: speaking at global OSS events
naruoga
0
120
AIにブラウザを触らせて、E2EテストをPlaywrightで書く
koji_kawamura
0
340
属人化を叩き割れ!「制作加速」と「安定化」の矛盾を打破する:8年目プロダクトが辿り着いた「ミスが起こり得ない」アセット制作フローの全貌
gree_tech
PRO
0
120
平文パスワードはログに“残り” ── 肝心の侵入は“痕跡すら残らない”
kuroneko13
0
120
Head First モブプログラミング / Head First Mobprogramming
takaking22
10
12k
自宅NWにISR4331を導入してみた話
okaits
0
120
DDDのエッセンスを取り入れたAIでの開発
ak2ie
0
200
【GCC2026】大規模言語モデルを活用した内製検索サービスの社内展開や業務活用
bandainamcostudios
PRO
0
470
Rust×eBPFでEDRっぽいものをつくる
sunlife3
2
790
猫付きpingコマンドを自作
uyuki234
0
290
AIに持続⼒を与える 判断の⻑期記憶設計
eiei114
1
620
強化学習「理論」入門
enakai00
3
3.6k
Featured
See All Featured
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
287
14k
Music & Morning Musume
bryan
47
7.3k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
4.4k
Automating Front-end Workflow
addyosmani
1369
210k
Ethics towards AI in product and experience design
skipperchong
2
350
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
201
75k
Visual Storytelling: How to be a Superhuman Communicator
reverentgeek
2
620
Principles of Awesome APIs and How to Build Them.
keavy
128
18k
Lightning Talk: Beautiful Slides for Beginners
inesmontani
PRO
2
640
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.8k
Become a Pro
speakerdeck
PRO
31
6.2k
YesSQL, Process and Tooling at Scale
rocio
174
15k
Transcript
プロジェクトのすすめ 第1回(全10回?)
ぷろじぇくととは? • 期限があり、唯一の成果物(モノやコト) を生み出す仕事。 • プロジェクトXのおかげで言葉だけ広 まった。
プロジェクトとは • 人により遂行される • 使用資源の制約がある • 計画され、遂行され、管理さ れる
なぜプロジェクトは失敗するのか? プロジェクトの失敗ポイント • 見込みより売上が少ない • 計画よりもコストがかかっている • 発売時期が遅れた • 発売に間に合わせるため内容が削られた
• ユーザーの評判が悪い • 不具合が発生 • スタッフの満足度が低い、故障者が出た、辞めてしまった など・・・
プロジェクトの失敗ポイントの分類 ・スコープ(コンテンツの範囲)の問題 ・品質の問題 ・コストの問題 ・時間の問題 ・リソース(人員・環境)の問題 ・ビジネスの問題
ビジネスの問題について ビジネスの失敗はリリースしてみないと分 からず、もし他の失敗要因で失敗しても上 手くいってしまう事もある? では他の失敗要因が成功し、プロジェクト は計画どおりだったのに、ビジネスが失敗 するの場合とは?
不十分なデータ分析が機会ロスを生んで いるのではないか? 意思決定をするための材料。 1.過去実施した施策/顧客/収益に関する 「自社データ」 2.生活者の購買意識/行動に関する 「生活者データ」 3.市場や競合企業に関する「市場データ」 4.新聞/書籍/ネット等に公開されている 「公開データ」
不十分な「自社データ」に潜む"落とし穴" まず自社に蓄積されている「1」を活用し、 「課題」「機会」を抽出。 改善仮説の方向性をいくつか打ち出したう えで、「2」「3」「4」「5」 を収集し、最終的な 意思決定を行う。
決定確度が低くなる例 「顧客獲得効率が良くなっている」 ↓ 「顧客獲得施策には問題ない」 しかしそこに大きな"落とし穴"が隠 れている場合がある。
【得られた情報】 【分析結果】 顧客獲得効率が良くなってい る 顧客獲得施策には問題ない × 顧客獲得効率が良くなってい る + 生涯価値の低い顧客
ターゲット設定に問題あり ◦ 顧客数は増えているが、収益 が伸びていない 優良顧客を増やすCRMに問 題がある × 顧客数は増えているが、収益 が伸びていない + 優良顧客の離脱率が悪化して いる 優良顧客を維持するCRMに 問題がある ◦
プロジェクトの失敗ポイントの分類 ・スコープ(コンテンツの範囲)の問題 ・品質の問題 ・コストの問題 ・時間の問題 ・リソース(人員・環境)の問題 ・ビジネスの問題 絡み合う複雑なパラメータ 「これらをうまく制御したい」
問 プロジェクトの初期に立てた計画は最終的にどれ ほどの誤差を生むのか? 当初計画比で1.2倍?1.5倍?それとも2倍?
計画の主な変動要因 ・スコープの変化 -仕様の追加・変更 ・タスク分解のエラー -既知の仕様に対してタスク の洗い出し漏れがあった場合 ・見積もりのエラー -タスク消化にかかる時間を 見誤った場合 ・一日あたりの作業時間見込
みエラー -会議その他で思ったよりも 作業時間が取れなかった場 合など ・人員計画のエラー -思ったより人数を増やせな い -思ったより能力がない -辞められる、故障者が出る ・品質マネジメントのエラー -品質が上がらないので作り 直し ・技術マネジメントのエラー -プログラム的に実現が困 難なので作り直し
変動要因別の変化幅 ・仕様追加でスコープ変更→1.5倍 ・タスク分解のエラー→1.4倍 ・見積もりのエラー→1.3倍 ・一日あたりの作業時間見込みエラー →作業時間-20%=1.25倍 ・人員計画のエラー -思ったように増員できなかった→-20%=1.25倍 -思ったような能力が無かった→-30%=1.4倍 ・品質マネジメントのエラー→1.3倍
・技術マネジメントのエラー→1.3倍
※あくまでも、直感よりも遥かに大きいということを伝えるための計算 なので、その計算方法や数値の精度に対しては目をつむってください それぞれの要因による計画増加分 を掛け合わせてみると・・・ ※それぞれの要因は独立しており、おおよそ直交性 があると仮定します 1.5×1.4×1.3×1.25×1. 25×1.4×1.3×1.3≒ 10倍!!
• 対処1:仕様を35%削減⇒1.54倍の対策効果 • 対処2:人員を60%追加投入⇒1.6倍の対策効 果 ※もちろん人を足したからといって素直に人数分の効果が出る わけではありませんが簡易計算として割り切ります • 対処3:期間を50%延長⇒1.5倍の対策効果 •
対処4:品質を30%妥協する⇒1.43倍の対策 効果 ※品質を下げる事で工数を減らすという意味で単純計算してい ます 1.54×1.6×1.5×1.43≒5.64倍の対策効 果
対処5:月の労働時間を 160時間から290時間にする ⇒1.8倍の対策効果 1.54×1.6×1.5×1.43×1.8≒10 倍の対策効果 めでたしめでたし!! ・・・のはずはない!
まとめると。。。 対処1:仕様を35%削減 対処2:人員を60%追加投入 対処3:期間を50%延長 対処4:品質を30%妥協する 対処5:月の労働時間を80%増やす 見事なデスマーチの完成です結構あ りがちな風景では
希望 膨張 妥協 プロジェクトの正確な予 想なんて不可能
プロジェクトを制御する ことは可能です 予想は難しくても制御 はできる
不確実性を乗りこなす ・事前対策(調査・戦略・設計・計画) -不確実性を減らす ・見通しが悪い部分の調査や検証/実験をしっかりと行う ・作業データを取り、フィードバックをかけて予測精度を向上させる ・計画規模を小さくする -どうせ計画は膨らむのだから最初に目いっぱいコンパクトにする ・設計をなるべく詳細に行う ・リスクの高い要素を予め極力減らす -不確実でも良い事にする
・リスクの高い要素を無くしてても成立する設計にする -その要素が無くなっても商品の価値が下がらない設計にする >トカゲのしっぽとしていつでも切れるようにする ・事後対策(イテレーション) -変化や問題発生にすばやく気づく -変化や問題にすばやく対応する
近頃はアジャイルという言葉が流行っていますが ・・・ 最近の「アジャイル」という言葉の使われ方に違和 感を感じる。
「速い・安い」を実現する「アジャイル開発」 だと言うわけです。 もはや、まるでファストフード。
アジャイルを「速い・安い・旨い」のように表現してい る人は、アジャイル開発に「低コストで速く作れるソ フトウェア開発」を期待をしている。 しかし、実際にはそうはうまくいかない。 トレードオフなしに、何も得ることはないということを 理解すべき。
よくあるアジャイルの誤解 • 仕様や設計なんていらない! • ドキュメントなんていらない! • 計画なんていらない! • 「作って、壊して」を短いイテレーションで繰り返 せば万事解決!
• ウォーターフォールは悪! うんなわけない!!
アジャイルが「楽をする為の免罪符」的に曲 解されて扱われているケースがあるように 思われる。 アジャイルを誤解して導入するとむしろ危 険! ※もちろんちゃんと運用されているケースもたくさんあります
次回 プロジェクトのすすめ2 アジャイル考察。