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
7.5k
もふもふなエンジニアの心得/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
380
スクラムとモジャイル/scrum-and-mojile
harada4atsushi
0
7.8k
リーン・スタートアップとMVP/lean-startup-mvp
harada4atsushi
0
26k
リーンキャンバスの作り方/how-to-make-lean-canvas
harada4atsushi
0
9k
見積もり/agile-estimation
harada4atsushi
0
72k
振り返り/agile-looking-back
harada4atsushi
0
21k
インセプションデッキの作り方/how-to-make-inception-deck
harada4atsushi
0
9.6k
mofmof inc. 会社紹介 for 採用/mofmofinc-informatioin-for-recruiting
harada4atsushi
3
55k
Other Decks in Business
See All in Business
AI時代における変革の入口-100年後も語られる25年のために- #scrumosaka / The entry point to transformation in the AI era For 25 years that will be talked about 100 years from now
kyonmm
PRO
6
1.2k
SlackでDMを使わない方が いい理由を説明してみた
walkersumida
1
1.2k
株式会社ジグザグ_新規投資家向け資料_2025年7月.pdf
zig_zag
0
2.2k
メタデータ通りの趣旨と進め方
datayokocho
0
190
Meet SYNTHESIS
minateramoto
PRO
0
150
イオングローバルSCM株式会社 会社概要
agscm
0
1k
Speak To QuickBooks Error U.S. Support Contact Numbers: A Step By Step Guide
nepap
0
160
Morght 会社紹介資料_LAST UPDATED 2025.7
morght
1
4k
Feedback in Action
lycorptech_jp
PRO
1
340
株式会社TONIQ 会社説明資料
yukitoniq
0
120
営業職/新卒向け会社紹介資料(テックファーム株式会社)
techfirm
1
850
LW_brochure_business
lincwellhr
1
60k
Featured
See All Featured
Fireside Chat
paigeccino
37
3.5k
How to Ace a Technical Interview
jacobian
278
23k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Become a Pro
speakerdeck
PRO
29
5.4k
Designing for humans not robots
tammielis
253
25k
Documentation Writing (for coders)
carmenintech
72
4.9k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
How GitHub (no longer) Works
holman
314
140k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.3k
A Tale of Four Properties
chriscoyier
160
23k
Code Reviewing Like a Champion
maltzj
524
40k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
Transcript
もふもふなエンジニアの⼼得 mofmof inc.
クイズ • このトレーニングの終了時にクイズを出題します • 回答できるようにしっかり聞いていてください
Why How What
WHY なぜ開発チームレンタルをやるのか
なぜ開発チームレンタルをやっているのか • かつて代表・原⽥がSIerで開発の仕事していた時代の話 • ⽇々、顧客の怒号が⾶んでいる • 「こんな機能誰が使いこなせるんだろう」という機能を作ら なければならなかった • ちゃんとつくったのに「これじゃ使い物にならないよ」と⾔
われた • 作ることは好きだったが、どうしてこの仕事はこんなにも不 ⽑なことが多いのだろうかと感じていた
なぜ開発チームレンタルをやっているのか • 「価値がある」と感じられるものづくりをしたい • つくったもので⼈に喜んでもらいたい • ⼀労働⼒ではなく、主体となってものづくりする仕事がした い
従来型の受託開発はなぜうまく⾏かないのか • 「要件定義」という仮説の上に計画し、計画通りに作ること を正とするから • 仮説の誤りが⾒つかった時、時間的・コスト的にそれを是正 する余地が圧倒的に⾜りないから • 顧客はビジネス的な価値の実現を求めているのに対し、ベン ダーは成果物の完成を⽬指しているから
開発チームレンタルはどう良いのか • 仕様変更がいつでも何度でも出来るため、仮説が誤っていた ときの修正がしやすい • 仕様・バグの線引が必要ないため、責任範囲を定めるための ⼯数が必要なく、純粋に開発に注⼒できる • エンジニア⾃⾝が、仕様について提案し議論に参加すること が出来る
• 結果、成果物を完成することではなく、プロダクトの価値を 実現するためのものづくりが可能になる
プロダクトの価値とは何か • システムが完成さえすれば価値が実現される、というのは誤 解 • 価値とは、プロダクトの周辺の⼈間が喜んでいるという状態 である。例えば、 • ユーザーは、そのプロダクトを使って嬉しいか? •
サービス提供者は、プロダクトを提供してビジネス的メリット を得られるか?(わかりやすいのは利益)
開発チームレンタルは何を提供するのか • 資⾦もビジネスアイディアもあるのに、つくり⼿だけが⾜り ない企業が、早く・確実に市場にプロダクトをリリースする ことが出来ること • 開発プロジェクトに発⽣しがちな本質的でない問題をおさえ て、継続的にプロダクトを成⻑させていけること • プロダクトの価値を実現するために、仮説から試⾏錯誤しな
がら機能に落とし込んでいけること
価値のある失敗をする • ビジネス的メリットの実現を保証することは難しい • ビジネスとして成⽴するかどうかはプロダクト以外の要因にも 依存するため • 新規事業の成功率は10%未満、基本的にほどんど失敗する • 出来るだけ早く正確に、定義した仮説を具現化し、市場に問
うこと • 結果、失敗だったとしても、仮説が早く検証された事実には ⼗分価値がある
HOW もふもふなエンジニアの振る舞い
技術⼒の⾼さだけでは価値のある仕事は出来ない • mofmof inc.では技術⼒が⾼いのは当然であり、基礎能⼒で ある • 技術⼒の⾼さと、提供できる価値の⼤きさは正⽐例しない • 価値を提供出来る⽅法を⾝につけていなければ、提供できる 価値を⼤きく出来ない
• その⽅法論の⼀つが、スクラムやアジャイルである
ただ⾔われた通りに作らない • 開発業務の中では、プロダクトオーナーからつくって欲しい 機能が渡される • なぜその機能が必要なのか、ユーザーをどのように幸せにす るか、機能の⽬的にフォーカスして設計すること • 機能の⽬的が満たせれば作り⽅にはバリエーションがある •
よりよい実現の仕⽅を考え提案すること
理解の溝を積極的に埋める • 顧客(プロダクトオーナー)は開発のスペシャリストではない • 従って、欲しい機能を的確に伝えられるとは限らない • 抽象的で曖昧な仕様は、⾃ら具体化するように働きかけるこ と • 判断を仰ぐ必要がある場⾯では、相⼿に決めさせるのではな
く、選択肢を提⽰し、⾃⾝が推奨する案を⽰すこと
仕様変更は学習の成果である • 仕様が変わるということは、学習の結果、よりよい形に気付 いたということであり、プロダクトを成⻑させる機会を得た ということ • 仕様変更を否定することはプロダクトの成⻑を否定すること • リリース近くの仕様変更だったしても、やれるかやれないか は別として、それ⾃体は歓迎されるべき
リスクは早く検知して伝える • システム開発は不確実性との戦い • リスクは早く検知して、出来るだけ早く顧客に伝えること • 伝える際には必ず対応策をセットで伝えること • 顧客が気付くより早く気付いて、先回りして⼿を打つことが 信頼につながる
クイズ