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
もふもふなエンジニアの心得/mofmofinc-engineer-knowledge
Search
Atsushi Harada
October 31, 2019
Business
0
7k
もふもふなエンジニアの心得/mofmofinc-engineer-knowledge
mofmofの開発チームレンタルで提供する価値について。
もふもふのエンジニアに必要な基礎的な考え方。振る舞いの仕方について。
Atsushi Harada
October 31, 2019
Tweet
Share
More Decks by Atsushi Harada
See All by Atsushi Harada
モジャイリーンな事業開発/mojilean-business-development
harada4atsushi
0
320
スクラムとモジャイル/scrum-and-mojile
harada4atsushi
0
7.3k
リーン・スタートアップとMVP/lean-startup-mvp
harada4atsushi
0
25k
リーンキャンバスの作り方/how-to-make-lean-canvas
harada4atsushi
0
8.4k
見積もり/agile-estimation
harada4atsushi
0
67k
振り返り/agile-looking-back
harada4atsushi
0
20k
インセプションデッキの作り方/how-to-make-inception-deck
harada4atsushi
0
9k
mofmof inc. 会社紹介 for 採用/mofmofinc-informatioin-for-recruiting
harada4atsushi
3
53k
Other Decks in Business
See All in Business
Japan Open Chain White Paper
gugroup
0
240
株式会社ispec 会社紹介資料
emikamihara
0
5.9k
Japan Open Chain ホワイトペーパー
gugroup
0
290
KRAF Impact Report 2024(English)
kraf
0
180
LayerX AI・LLM Division Deck
layerx
PRO
0
1k
Sales Marker Culture book
salesmarker
PRO
6
25k
株式会社カオナビ】会社紹介資料 for business / kaonavi/introduction-for-business
kaonavi
0
110
合議で決めたいわけではないけれど、 集合知で助けてほしい。_pmconf_2024
tomosooon
1
5.1k
株式会社miibo|採用デック
natsumidnx
0
150
【エンジニア職】中途採用向け会社説明資料(テックファーム株式会社)
techfirm
0
4.2k
ログラス会社紹介資料 / Loglass Company Deck
loglass2019
7
250k
Canary Inc. Company Deck
canaryinc
0
40k
Featured
See All Featured
Rails Girls Zürich Keynote
gr2m
94
13k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.1k
Designing on Purpose - Digital PM Summit 2013
jponch
116
7k
How GitHub (no longer) Works
holman
311
140k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
32
2.7k
How To Stay Up To Date on Web Technology
chriscoyier
789
250k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
17
2.3k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
2
170
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
29
2k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
169
50k
Designing Experiences People Love
moore
138
23k
Put a Button on it: Removing Barriers to Going Fast.
kastner
59
3.6k
Transcript
もふもふなエンジニアの⼼得 mofmof inc.
クイズ • このトレーニングの終了時にクイズを出題します • 回答できるようにしっかり聞いていてください
Why How What
WHY なぜ開発チームレンタルをやるのか
なぜ開発チームレンタルをやっているのか • かつて代表・原⽥がSIerで開発の仕事していた時代の話 • ⽇々、顧客の怒号が⾶んでいる • 「こんな機能誰が使いこなせるんだろう」という機能を作ら なければならなかった • ちゃんとつくったのに「これじゃ使い物にならないよ」と⾔
われた • 作ることは好きだったが、どうしてこの仕事はこんなにも不 ⽑なことが多いのだろうかと感じていた
なぜ開発チームレンタルをやっているのか • 「価値がある」と感じられるものづくりをしたい • つくったもので⼈に喜んでもらいたい • ⼀労働⼒ではなく、主体となってものづくりする仕事がした い
従来型の受託開発はなぜうまく⾏かないのか • 「要件定義」という仮説の上に計画し、計画通りに作ること を正とするから • 仮説の誤りが⾒つかった時、時間的・コスト的にそれを是正 する余地が圧倒的に⾜りないから • 顧客はビジネス的な価値の実現を求めているのに対し、ベン ダーは成果物の完成を⽬指しているから
開発チームレンタルはどう良いのか • 仕様変更がいつでも何度でも出来るため、仮説が誤っていた ときの修正がしやすい • 仕様・バグの線引が必要ないため、責任範囲を定めるための ⼯数が必要なく、純粋に開発に注⼒できる • エンジニア⾃⾝が、仕様について提案し議論に参加すること が出来る
• 結果、成果物を完成することではなく、プロダクトの価値を 実現するためのものづくりが可能になる
プロダクトの価値とは何か • システムが完成さえすれば価値が実現される、というのは誤 解 • 価値とは、プロダクトの周辺の⼈間が喜んでいるという状態 である。例えば、 • ユーザーは、そのプロダクトを使って嬉しいか? •
サービス提供者は、プロダクトを提供してビジネス的メリット を得られるか?(わかりやすいのは利益)
開発チームレンタルは何を提供するのか • 資⾦もビジネスアイディアもあるのに、つくり⼿だけが⾜り ない企業が、早く・確実に市場にプロダクトをリリースする ことが出来ること • 開発プロジェクトに発⽣しがちな本質的でない問題をおさえ て、継続的にプロダクトを成⻑させていけること • プロダクトの価値を実現するために、仮説から試⾏錯誤しな
がら機能に落とし込んでいけること
価値のある失敗をする • ビジネス的メリットの実現を保証することは難しい • ビジネスとして成⽴するかどうかはプロダクト以外の要因にも 依存するため • 新規事業の成功率は10%未満、基本的にほどんど失敗する • 出来るだけ早く正確に、定義した仮説を具現化し、市場に問
うこと • 結果、失敗だったとしても、仮説が早く検証された事実には ⼗分価値がある
HOW もふもふなエンジニアの振る舞い
技術⼒の⾼さだけでは価値のある仕事は出来ない • mofmof inc.では技術⼒が⾼いのは当然であり、基礎能⼒で ある • 技術⼒の⾼さと、提供できる価値の⼤きさは正⽐例しない • 価値を提供出来る⽅法を⾝につけていなければ、提供できる 価値を⼤きく出来ない
• その⽅法論の⼀つが、スクラムやアジャイルである
ただ⾔われた通りに作らない • 開発業務の中では、プロダクトオーナーからつくって欲しい 機能が渡される • なぜその機能が必要なのか、ユーザーをどのように幸せにす るか、機能の⽬的にフォーカスして設計すること • 機能の⽬的が満たせれば作り⽅にはバリエーションがある •
よりよい実現の仕⽅を考え提案すること
理解の溝を積極的に埋める • 顧客(プロダクトオーナー)は開発のスペシャリストではない • 従って、欲しい機能を的確に伝えられるとは限らない • 抽象的で曖昧な仕様は、⾃ら具体化するように働きかけるこ と • 判断を仰ぐ必要がある場⾯では、相⼿に決めさせるのではな
く、選択肢を提⽰し、⾃⾝が推奨する案を⽰すこと
仕様変更は学習の成果である • 仕様が変わるということは、学習の結果、よりよい形に気付 いたということであり、プロダクトを成⻑させる機会を得た ということ • 仕様変更を否定することはプロダクトの成⻑を否定すること • リリース近くの仕様変更だったしても、やれるかやれないか は別として、それ⾃体は歓迎されるべき
リスクは早く検知して伝える • システム開発は不確実性との戦い • リスクは早く検知して、出来るだけ早く顧客に伝えること • 伝える際には必ず対応策をセットで伝えること • 顧客が気付くより早く気付いて、先回りして⼿を打つことが 信頼につながる
クイズ