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
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Livesense Inc.
PRO
April 21, 2014
Technology
68
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.
新規商品の開発におけるAIの活用 〜挑戦は人間にしかできない〜
livesense
PRO
0
30
味覇で作るパスタが美味い - 20261001_yabaubuki.dev
livesense
PRO
0
190
Rubyはただの⾔語に⾮ず
livesense
PRO
0
600
28新卒_Webエンジニア職採用_会社説明資料
livesense
PRO
0
180
27新卒_総合職採用_会社説明資料
livesense
PRO
0
7.8k
27新卒_Webエンジニア職採用_会社説明資料
livesense
PRO
0
13k
株式会社リブセンス・転職会議 採用候補者様向け資料
livesense
PRO
0
620
株式会社リブセンス 会社説明資料(報道関係者様向け)
livesense
PRO
1
1.8k
データ基盤の負債解消のためのリプレイス
livesense
PRO
0
750
Other Decks in Technology
See All in Technology
AI時代に求められる優秀なTechLeadの振る舞い
pospome
11
16k
Kiro IDE 入門 (画面の各部から、頼み方、任せ方、戻し方まで) | 目指せ Kiro マスター 02
inariku
PRO
4
180
Gifu WordPress Meetup #200 に向けて、私たちには何ができるだろうか?/ 2026-11-07 Gifu WordPress Meetup
torounit
0
250
長い仕事を任せる (Workflows、クラウドセッション、Kiro Web) | 目指せ Kiro マスター 10
inariku
PRO
3
160
「いつか使う」の「いつか」は来ない 〜AI駆動開発における「作らない」判断について〜
ikki0006
0
180
Kiro 入門 (1 つのエージェントを、どの画面からでも) | 目指せ Kiro マスター 01
inariku
PRO
6
1.4k
Copilot Coworkで「みのるん式」やってみた
minorun365
PRO
2
1.7k
AWS基盤改善を支える 私たちの理念と行動指針
kentosuzuki
0
140
AI時代における医療情報システムのセキュリティ / Security of Healthcare IT Systems in the AI Era
henryofficial
0
130
大江戸Ruby会議でデータベース クライアントの話をするのは 間違っているだろうか
yahonda
1
110
AWS構成から考えるWebセキュリティ ― WordPressの構築経験から考える公開範囲と更新運用【JAWS FESTA 2026 in AKITA】
cscengineer
PRO
2
390
「AIチャットからもできないの?」と言われたら ~業務アプリをMCP対応するときの認証・認可の勘所
oidfj
0
270
Featured
See All Featured
A designer walks into a library…
pauljervisheath
211
25k
技術選定の審美眼(2025年版) / Understanding the Spiral of Technologies 2025 edition
twada
PRO
121
130k
Exploring anti-patterns in Rails
aemeredith
4
560
Testing 201, or: Great Expectations
jmmastey
46
8.4k
Dominate Local Search Results - an insider guide to GBP, reviews, and Local SEO
greggifford
PRO
0
400
The Director’s Chair: Orchestrating AI for Truly Effective Learning
tmiket
1
350
What's in a price? How to price your products and services
michaelherold
247
13k
A Modern Web Designer's Workflow
chriscoyier
699
190k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Leveraging LLMs for student feedback in introductory data science courses - posit::conf(2025)
minecr
1
470
Building a A Zero-Code AI SEO Workflow
portentint
PRO
0
820
How to Align SEO within the Product Triangle To Get Buy-In & Support - #RIMC
aleyda
2
1.9k
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 アジャイル考察。