Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
プロジェクトのすすめ 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
530
28新卒_Webエンジニア職採用_会社説明資料
livesense
PRO
0
120
27新卒_総合職採用_会社説明資料
livesense
PRO
0
7.2k
27新卒_Webエンジニア職採用_会社説明資料
livesense
PRO
0
12k
株式会社リブセンス・転職会議 採用候補者様向け資料
livesense
PRO
0
540
株式会社リブセンス 会社説明資料(報道関係者様向け)
livesense
PRO
1
1.8k
データ基盤の負債解消のためのリプレイス
livesense
PRO
0
680
26新卒_総合職採用_会社説明資料
livesense
PRO
0
13k
株式会社リブセンス会社紹介資料 / Invent the next common.
livesense
PRO
2
75k
Other Decks in Technology
See All in Technology
Slack上でインフラをトラブルシュートする! Agentic Platform Engineeringの第一歩
teru0x1
5
1.8k
AI 時代のスタートアップエコシステ厶から考究する技術的負債との向き合い方
m3m0r7
PRO
3
2.3k
ユーザー価値を届け続けるためにウォンテッドリーが大切にしている文化
kotaminato
0
180
映像変換サーバーなしで端末内でHLSを生成してライブ配信
hikarusato
0
130
AIエージェントの権限管理 3: Agentic RAG の Fine grained access control 編
ren8k
0
160
時うどん〜Socket.getifaddrsで学ぶネットワーク編 / Tokiudon: The Socket.getifaddrs Edition
coe401_
3
180
バイブコーディング時代のWebアプリ開発入門~Cloud Runで学ぶセキュアなビルドとデプロイ
waiwai2111
1
140
AIによるクリエイティブ生成を行う上での試行錯誤
plaidtech
PRO
0
160
あけおめLINE 傾向とその対策
nasa9084
0
180
すぐできる衛星通信対応 あとは山奥に行くだけ
tatetate55
0
140
【技術的負債conf】事業成長に伴う技術的負債の説明責任とAIによるモニタリング、認知的負債について
i35_267
3
1.8k
2026-09-18 gotanda.sre Terraformで複数環境作ったり、複数Stateに分割したりそれとTerragrunt / Terraform multi envs and multi states
masasuzu
3
650
Featured
See All Featured
Breaking role norms: Why Content Design is so much more than writing copy - Taylor Woolridge
uxyall
1
410
Exploring anti-patterns in Rails
aemeredith
4
510
Bioeconomy Workshop: Dr. Julius Ecuru, Opportunities for a Bioeconomy in West Africa
akademiya2063
PRO
1
360
Navigating Algorithm Shifts & AI Overviews - #SMXNext
aleyda
1
1.6k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.8k
Winning Ecommerce Organic Search in an AI Era - #searchnstuff2025
aleyda
2
2.1k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
50
10k
The #1 spot is gone: here's how to win anyway
tamaranovitovic
4
1.2k
Building Adaptive Systems
keathley
44
3.2k
Automating Front-end Workflow
addyosmani
1369
210k
Discover your Explorer Soul
emna__ayadi
2
1.3k
New Earth Scene 8
popppiees
4
2.6k
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 アジャイル考察。