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
0
46
プロジェクトのすすめ vol.1 #TechLunch
プロジェクトのすすめ vol.1
2012/07/04 (水) @ Livesense TechLunch
発表者:島田 喜裕
Livesense Inc.
PRO
April 21, 2014
Tweet
Share
More Decks by Livesense Inc.
See All by Livesense Inc.
27新卒_Webエンジニア職採用_会社説明資料
livesense
PRO
0
100
株式会社リブセンス・転職会議 採用候補者様向け資料
livesense
PRO
0
15
株式会社リブセンス 会社説明資料(報道関係者様向け)
livesense
PRO
0
1.4k
データ基盤の負債解消のためのリプレイス
livesense
PRO
0
390
26新卒_総合職採用_会社説明資料
livesense
PRO
0
8.8k
株式会社リブセンス会社紹介資料 / Invent the next common.
livesense
PRO
1
27k
26新卒_Webエンジニア職採用_会社説明資料
livesense
PRO
1
12k
中途セールス職_会社説明資料
livesense
PRO
0
250
EM候補者向け転職会議説明資料
livesense
PRO
0
120
Other Decks in Technology
See All in Technology
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
26k
PHP開発者のためのSOLID原則再入門 #phpcon / PHP Conference Japan 2025
shogogg
4
940
CI/CD/IaC 久々に0から環境を作ったらこうなりました
kaz29
1
200
Yamla: Rustでつくるリアルタイム性を追求した機械学習基盤 / Yamla: A Rust-Based Machine Learning Platform Pursuing Real-Time Capabilities
lycorptech_jp
PRO
4
170
「Chatwork」の認証基盤の移行とログ活用によるプロダクト改善
kubell_hr
1
240
タイミーのデータモデリング事例と今後のチャレンジ
ttccddtoki
4
1.6k
OPENLOGI Company Profile for engineer
hr01
1
33k
GeminiとNotebookLMによる金融実務の業務革新
abenben
0
240
LangChain Interrupt & LangChain Ambassadors meetingレポート
os1ma
2
220
生成AI時代の開発組織・技術・プロセス 〜 ログラスの挑戦と考察 〜
itohiro73
1
380
ビズリーチが挑む メトリクスを活用した技術的負債の解消 / dev-productivity-con2025
visional_engineering_and_design
0
200
プロダクトエンジニアリング組織への歩み、その現在地 / Our journey to becoming a product engineering organization
hiro_torii
0
140
Featured
See All Featured
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Why Our Code Smells
bkeepers
PRO
337
57k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
35
2.4k
Building Applications with DynamoDB
mza
95
6.5k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.1k
Side Projects
sachag
455
42k
Code Reviewing Like a Champion
maltzj
524
40k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
720
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
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 アジャイル考察。