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.6k
もふもふなエンジニアの心得/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
390
スクラムとモジャイル/scrum-and-mojile
harada4atsushi
0
7.9k
リーン・スタートアップとMVP/lean-startup-mvp
harada4atsushi
0
26k
リーンキャンバスの作り方/how-to-make-lean-canvas
harada4atsushi
0
9.1k
見積もり/agile-estimation
harada4atsushi
0
72k
振り返り/agile-looking-back
harada4atsushi
0
21k
インセプションデッキの作り方/how-to-make-inception-deck
harada4atsushi
0
9.8k
mofmof inc. 会社紹介 for 採用/mofmofinc-informatioin-for-recruiting
harada4atsushi
3
55k
Other Decks in Business
See All in Business
ビジネス職中途採用向け会社説明資料_2025.2.pdf
zozobusiness
0
230
Scrum Inc. Japan Company Introduction
scrumincjp
0
7k
生成AIとデザインリサーチが融和する未来(RESEARCH Conference2025)
hynym
PRO
0
220
(8枚)GROWモデルで目標達成する技術 部下育成の基本
nyattx
PRO
0
1.4k
提案レベルを上げてみたら、私の『提案』が『進捗』になっていた件
natty_natty254
26
16k
ログラス会社紹介資料 / Loglass Company Deck
loglass2019
11
440k
Leveraging Guest Podcasting to Boost SEO & Build Your Brand
brandonleibowitz
1
170
ele&company_companydeck
eleand
0
470
社内請負スクラムから脱却する〜複雑性に適応するスクラムチームの作り方〜
yasuhirokimesawa
1
120
株式会社10X - Company Deck
10xinc
89
1.6M
Vorsicht, Autopilot! Bewusste Produktführung im AI-Zeitalter
arnekittler
0
120
MagicPodを使い倒すメドレーの活用術 / How to utilize of MagicPod
medley
1
110
Featured
See All Featured
4 Signs Your Business is Dying
shpigford
185
22k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.2k
Agile that works and the tools we love
rasmusluckow
331
21k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
Statistics for Hackers
jakevdp
799
220k
Facilitating Awesome Meetings
lara
56
6.6k
How GitHub (no longer) Works
holman
315
140k
Large-scale JavaScript Application Architecture
addyosmani
514
110k
A Tale of Four Properties
chriscoyier
160
23k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Thoughts on Productivity
jonyablonski
70
4.9k
Why Our Code Smells
bkeepers
PRO
339
57k
Transcript
もふもふなエンジニアの⼼得 mofmof inc.
クイズ • このトレーニングの終了時にクイズを出題します • 回答できるようにしっかり聞いていてください
Why How What
WHY なぜ開発チームレンタルをやるのか
なぜ開発チームレンタルをやっているのか • かつて代表・原⽥がSIerで開発の仕事していた時代の話 • ⽇々、顧客の怒号が⾶んでいる • 「こんな機能誰が使いこなせるんだろう」という機能を作ら なければならなかった • ちゃんとつくったのに「これじゃ使い物にならないよ」と⾔
われた • 作ることは好きだったが、どうしてこの仕事はこんなにも不 ⽑なことが多いのだろうかと感じていた
なぜ開発チームレンタルをやっているのか • 「価値がある」と感じられるものづくりをしたい • つくったもので⼈に喜んでもらいたい • ⼀労働⼒ではなく、主体となってものづくりする仕事がした い
従来型の受託開発はなぜうまく⾏かないのか • 「要件定義」という仮説の上に計画し、計画通りに作ること を正とするから • 仮説の誤りが⾒つかった時、時間的・コスト的にそれを是正 する余地が圧倒的に⾜りないから • 顧客はビジネス的な価値の実現を求めているのに対し、ベン ダーは成果物の完成を⽬指しているから
開発チームレンタルはどう良いのか • 仕様変更がいつでも何度でも出来るため、仮説が誤っていた ときの修正がしやすい • 仕様・バグの線引が必要ないため、責任範囲を定めるための ⼯数が必要なく、純粋に開発に注⼒できる • エンジニア⾃⾝が、仕様について提案し議論に参加すること が出来る
• 結果、成果物を完成することではなく、プロダクトの価値を 実現するためのものづくりが可能になる
プロダクトの価値とは何か • システムが完成さえすれば価値が実現される、というのは誤 解 • 価値とは、プロダクトの周辺の⼈間が喜んでいるという状態 である。例えば、 • ユーザーは、そのプロダクトを使って嬉しいか? •
サービス提供者は、プロダクトを提供してビジネス的メリット を得られるか?(わかりやすいのは利益)
開発チームレンタルは何を提供するのか • 資⾦もビジネスアイディアもあるのに、つくり⼿だけが⾜り ない企業が、早く・確実に市場にプロダクトをリリースする ことが出来ること • 開発プロジェクトに発⽣しがちな本質的でない問題をおさえ て、継続的にプロダクトを成⻑させていけること • プロダクトの価値を実現するために、仮説から試⾏錯誤しな
がら機能に落とし込んでいけること
価値のある失敗をする • ビジネス的メリットの実現を保証することは難しい • ビジネスとして成⽴するかどうかはプロダクト以外の要因にも 依存するため • 新規事業の成功率は10%未満、基本的にほどんど失敗する • 出来るだけ早く正確に、定義した仮説を具現化し、市場に問
うこと • 結果、失敗だったとしても、仮説が早く検証された事実には ⼗分価値がある
HOW もふもふなエンジニアの振る舞い
技術⼒の⾼さだけでは価値のある仕事は出来ない • mofmof inc.では技術⼒が⾼いのは当然であり、基礎能⼒で ある • 技術⼒の⾼さと、提供できる価値の⼤きさは正⽐例しない • 価値を提供出来る⽅法を⾝につけていなければ、提供できる 価値を⼤きく出来ない
• その⽅法論の⼀つが、スクラムやアジャイルである
ただ⾔われた通りに作らない • 開発業務の中では、プロダクトオーナーからつくって欲しい 機能が渡される • なぜその機能が必要なのか、ユーザーをどのように幸せにす るか、機能の⽬的にフォーカスして設計すること • 機能の⽬的が満たせれば作り⽅にはバリエーションがある •
よりよい実現の仕⽅を考え提案すること
理解の溝を積極的に埋める • 顧客(プロダクトオーナー)は開発のスペシャリストではない • 従って、欲しい機能を的確に伝えられるとは限らない • 抽象的で曖昧な仕様は、⾃ら具体化するように働きかけるこ と • 判断を仰ぐ必要がある場⾯では、相⼿に決めさせるのではな
く、選択肢を提⽰し、⾃⾝が推奨する案を⽰すこと
仕様変更は学習の成果である • 仕様が変わるということは、学習の結果、よりよい形に気付 いたということであり、プロダクトを成⻑させる機会を得た ということ • 仕様変更を否定することはプロダクトの成⻑を否定すること • リリース近くの仕様変更だったしても、やれるかやれないか は別として、それ⾃体は歓迎されるべき
リスクは早く検知して伝える • システム開発は不確実性との戦い • リスクは早く検知して、出来るだけ早く顧客に伝えること • 伝える際には必ず対応策をセットで伝えること • 顧客が気付くより早く気付いて、先回りして⼿を打つことが 信頼につながる
クイズ