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.4k
もふもふなエンジニアの心得/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.7k
リーン・スタートアップとMVP/lean-startup-mvp
harada4atsushi
0
26k
リーンキャンバスの作り方/how-to-make-lean-canvas
harada4atsushi
0
8.9k
見積もり/agile-estimation
harada4atsushi
0
72k
振り返り/agile-looking-back
harada4atsushi
0
21k
インセプションデッキの作り方/how-to-make-inception-deck
harada4atsushi
0
9.5k
mofmof inc. 会社紹介 for 採用/mofmofinc-informatioin-for-recruiting
harada4atsushi
3
54k
Other Decks in Business
See All in Business
なぜConfluence Cloudだったのか?〜『運用効率と将来性』から見る最適解と、予期せぬ課題を乗り越えた移行のリアル~ / Why-we-choose-confluence-cloud
medley
0
180
大AI時代を長く活躍するための 「コンフォート・ゾーン」の新解釈
mkitahara01985
0
690
セーフィー株式会社(Safie Inc.) 会社紹介資料
safie_recruit
6
350k
ChillStack会社紹介資料
chillstack
0
350
社会の中のわたしの技術 ─ 自分の地図の描き方 #wttjp
yotii23
0
210
事業計画及び成長可能性に関する事項 2025年6月25日
cynd
0
300
LW_brochure_business
lincwellhr
1
58k
AIUX is Agentic UX
kan
0
280
SSP Company Deck
susstap
0
140
tokyo_dbt_meetup_#14_意志ある羅針盤たれ<データサイド>
t_yamaguchi
3
520
M3 Career Culture Deck(セールス&コンサルティング職)
m3c
1
280k
特別講義 理系のための法学入門
seko_shuhei
2
2.2k
Featured
See All Featured
A better future with KSS
kneath
239
17k
How GitHub (no longer) Works
holman
314
140k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
710
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
8
670
Building an army of robots
kneath
306
45k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.9k
Mobile First: as difficult as doing things right
swwweet
223
9.7k
GraphQLとの向き合い方2022年版
quramy
49
14k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Documentation Writing (for coders)
carmenintech
72
4.9k
BBQ
matthewcrist
89
9.7k
Transcript
もふもふなエンジニアの⼼得 mofmof inc.
クイズ • このトレーニングの終了時にクイズを出題します • 回答できるようにしっかり聞いていてください
Why How What
WHY なぜ開発チームレンタルをやるのか
なぜ開発チームレンタルをやっているのか • かつて代表・原⽥がSIerで開発の仕事していた時代の話 • ⽇々、顧客の怒号が⾶んでいる • 「こんな機能誰が使いこなせるんだろう」という機能を作ら なければならなかった • ちゃんとつくったのに「これじゃ使い物にならないよ」と⾔
われた • 作ることは好きだったが、どうしてこの仕事はこんなにも不 ⽑なことが多いのだろうかと感じていた
なぜ開発チームレンタルをやっているのか • 「価値がある」と感じられるものづくりをしたい • つくったもので⼈に喜んでもらいたい • ⼀労働⼒ではなく、主体となってものづくりする仕事がした い
従来型の受託開発はなぜうまく⾏かないのか • 「要件定義」という仮説の上に計画し、計画通りに作ること を正とするから • 仮説の誤りが⾒つかった時、時間的・コスト的にそれを是正 する余地が圧倒的に⾜りないから • 顧客はビジネス的な価値の実現を求めているのに対し、ベン ダーは成果物の完成を⽬指しているから
開発チームレンタルはどう良いのか • 仕様変更がいつでも何度でも出来るため、仮説が誤っていた ときの修正がしやすい • 仕様・バグの線引が必要ないため、責任範囲を定めるための ⼯数が必要なく、純粋に開発に注⼒できる • エンジニア⾃⾝が、仕様について提案し議論に参加すること が出来る
• 結果、成果物を完成することではなく、プロダクトの価値を 実現するためのものづくりが可能になる
プロダクトの価値とは何か • システムが完成さえすれば価値が実現される、というのは誤 解 • 価値とは、プロダクトの周辺の⼈間が喜んでいるという状態 である。例えば、 • ユーザーは、そのプロダクトを使って嬉しいか? •
サービス提供者は、プロダクトを提供してビジネス的メリット を得られるか?(わかりやすいのは利益)
開発チームレンタルは何を提供するのか • 資⾦もビジネスアイディアもあるのに、つくり⼿だけが⾜り ない企業が、早く・確実に市場にプロダクトをリリースする ことが出来ること • 開発プロジェクトに発⽣しがちな本質的でない問題をおさえ て、継続的にプロダクトを成⻑させていけること • プロダクトの価値を実現するために、仮説から試⾏錯誤しな
がら機能に落とし込んでいけること
価値のある失敗をする • ビジネス的メリットの実現を保証することは難しい • ビジネスとして成⽴するかどうかはプロダクト以外の要因にも 依存するため • 新規事業の成功率は10%未満、基本的にほどんど失敗する • 出来るだけ早く正確に、定義した仮説を具現化し、市場に問
うこと • 結果、失敗だったとしても、仮説が早く検証された事実には ⼗分価値がある
HOW もふもふなエンジニアの振る舞い
技術⼒の⾼さだけでは価値のある仕事は出来ない • mofmof inc.では技術⼒が⾼いのは当然であり、基礎能⼒で ある • 技術⼒の⾼さと、提供できる価値の⼤きさは正⽐例しない • 価値を提供出来る⽅法を⾝につけていなければ、提供できる 価値を⼤きく出来ない
• その⽅法論の⼀つが、スクラムやアジャイルである
ただ⾔われた通りに作らない • 開発業務の中では、プロダクトオーナーからつくって欲しい 機能が渡される • なぜその機能が必要なのか、ユーザーをどのように幸せにす るか、機能の⽬的にフォーカスして設計すること • 機能の⽬的が満たせれば作り⽅にはバリエーションがある •
よりよい実現の仕⽅を考え提案すること
理解の溝を積極的に埋める • 顧客(プロダクトオーナー)は開発のスペシャリストではない • 従って、欲しい機能を的確に伝えられるとは限らない • 抽象的で曖昧な仕様は、⾃ら具体化するように働きかけるこ と • 判断を仰ぐ必要がある場⾯では、相⼿に決めさせるのではな
く、選択肢を提⽰し、⾃⾝が推奨する案を⽰すこと
仕様変更は学習の成果である • 仕様が変わるということは、学習の結果、よりよい形に気付 いたということであり、プロダクトを成⻑させる機会を得た ということ • 仕様変更を否定することはプロダクトの成⻑を否定すること • リリース近くの仕様変更だったしても、やれるかやれないか は別として、それ⾃体は歓迎されるべき
リスクは早く検知して伝える • システム開発は不確実性との戦い • リスクは早く検知して、出来るだけ早く顧客に伝えること • 伝える際には必ず対応策をセットで伝えること • 顧客が気付くより早く気付いて、先回りして⼿を打つことが 信頼につながる
クイズ