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
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Livesense Inc.
PRO
April 21, 2014
Technology
61
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
440
28新卒_Webエンジニア職採用_会社説明資料
livesense
PRO
0
110
27新卒_総合職採用_会社説明資料
livesense
PRO
0
6.1k
27新卒_Webエンジニア職採用_会社説明資料
livesense
PRO
0
11k
株式会社リブセンス・転職会議 採用候補者様向け資料
livesense
PRO
0
520
株式会社リブセンス 会社説明資料(報道関係者様向け)
livesense
PRO
1
1.7k
データ基盤の負債解消のためのリプレイス
livesense
PRO
0
650
26新卒_総合職採用_会社説明資料
livesense
PRO
0
13k
株式会社リブセンス会社紹介資料 / Invent the next common.
livesense
PRO
2
70k
Other Decks in Technology
See All in Technology
「顧客の声を聞かなければ何も始まらない」 ── 顧客の声から生まれた『AI返信補助機能』の開発プロセス / AICon2026_shikata_imai
rakus_dev
0
260
文字起こし基盤の信頼性
abnoumaru
0
110
ダッシュボード"開発"について 〜使われるダッシュボードのつくりかた〜
kimichan
0
180
生成 AI 時代にいま一度「問い合わせ」について考えてみる
kazzpapa3
1
110
SREとQA 二人三脚で進めるSLO運用/sre-qa-slo
sugitak
0
1.2k
【公開用】AI_Dev_Ex2026_AI_登壇資料
matsuritechnologies
PRO
1
450
Devsumi 2026 Summer 人もAIも使える共通基盤を事業の加速装置にする~デザインシステム運用に学ぶ組織レバレッジ~ 渡辺 凌央
legalontechnologies
PRO
1
280
[Droidcon Orlando '26] The Android Lens: Applying Mobile Forensics to AI Performance
amanda_hinchman
1
100
ここは地獄!つらい朝会を体験することで、チームとしてのより良い振る舞いに気づくワークショップ / The stand-up meeting from hell in the game industry
scrummasudar
0
210
AIと1000本ノックしてたどり着いた、最速のプロダクト開発 ~toC向けAIエージェントUXを、動く選択肢とAIキャパシティで設計する~
lycorptech_jp
PRO
1
110
Oracle Exadata Database Service on Cloud@Customer X11M (ExaDB-C@C) サービス概要
oracle4engineer
PRO
2
8.5k
OPENLOGI Company Profile for engineer
hr01
1
74k
Featured
See All Featured
Navigating Team Friction
lara
192
16k
Leveraging LLMs for student feedback in introductory data science courses - posit::conf(2025)
minecr
1
320
Statistics for Hackers
jakevdp
799
230k
Exploring anti-patterns in Rails
aemeredith
3
450
Digital Ethics as a Driver of Design Innovation
axbom
PRO
1
350
Visual Storytelling: How to be a Superhuman Communicator
reverentgeek
2
590
For a Future-Friendly Web
brad_frost
183
10k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
35
2.5k
Designing for humans not robots
tammielis
254
26k
Design in an AI World
tapps
1
260
Efficient Content Optimization with Google Search Console & Apps Script
katarinadahlin
PRO
1
730
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
254
22k
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 アジャイル考察。