Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
もふもふなエンジニアの心得/mofmofinc-engineer-knowledge
Atsushi Harada
October 31, 2019
Business
0
4.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
120
スクラムとモジャイル/scrum-and-mojile
harada4atsushi
0
4.4k
リーン・スタートアップとMVP/lean-startup-mvp
harada4atsushi
0
12k
リーンキャンバスの作り方/how-to-make-lean-canvas
harada4atsushi
0
5k
見積もり/agile-estimation
harada4atsushi
0
27k
振り返り/agile-looking-back
harada4atsushi
0
10k
インセプションデッキの作り方/how-to-make-inception-deck
harada4atsushi
0
5.3k
mofmof inc. 会社紹介 for 採用/mofmofinc-informatioin-for-recruiting
harada4atsushi
3
32k
Other Decks in Business
See All in Business
バニッシュ・スタンダード採用資料
vstandard
PRO
1
620
【特別版 - データ関連職種】Beatrust 採用情報 | Recruit Info Book
beatrust
PRO
0
190
WindowsコンテナDojo 準備編:コンテナ化推進に関するIBMの取組みご紹介
utsukibm
0
370
異分野の知見を活かす、DevOpsの実践: Learning from Other Fields
kakehashi
1
620
株式会社ライナフ エンジニア向け会社紹介資料
linough
0
210
Ogasahara
ogasahara
0
140
oVice会社紹介資料 / oVice Company Info
ovice
0
18k
株式会社Azoop会社紹介資料
senrimanabe
0
250
新卒入社者向け研修を作ってみた
nulabinc
PRO
1
230
ミラティブ「採用候補者さまへの手紙」/mirrativ letter
hr_team
0
38k
20220425_RPAの概要とWinActorについて
tamai_63
0
1.5k
Connected Robotics
cr
0
730
Featured
See All Featured
A Philosophy of Restraint
colly
192
14k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
498
130k
Web development in the modern age
philhawksworth
197
9.3k
What the flash - Photography Introduction
edds
61
10k
Intergalactic Javascript Robots from Outer Space
tanoku
261
25k
What’s in a name? Adding method to the madness
productmarketing
11
1.5k
Agile that works and the tools we love
rasmusluckow
319
19k
Web Components: a chance to create the future
zenorocha
303
40k
GitHub's CSS Performance
jonrohan
1020
410k
Clear Off the Table
cherdarchuk
79
280k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
29
4.3k
The Illustrated Children's Guide to Kubernetes
chrisshort
14
35k
Transcript
もふもふなエンジニアの⼼得 mofmof inc.
クイズ • このトレーニングの終了時にクイズを出題します • 回答できるようにしっかり聞いていてください
Why How What
WHY なぜ開発チームレンタルをやるのか
なぜ開発チームレンタルをやっているのか • かつて代表・原⽥がSIerで開発の仕事していた時代の話 • ⽇々、顧客の怒号が⾶んでいる • 「こんな機能誰が使いこなせるんだろう」という機能を作ら なければならなかった • ちゃんとつくったのに「これじゃ使い物にならないよ」と⾔
われた • 作ることは好きだったが、どうしてこの仕事はこんなにも不 ⽑なことが多いのだろうかと感じていた
なぜ開発チームレンタルをやっているのか • 「価値がある」と感じられるものづくりをしたい • つくったもので⼈に喜んでもらいたい • ⼀労働⼒ではなく、主体となってものづくりする仕事がした い
従来型の受託開発はなぜうまく⾏かないのか • 「要件定義」という仮説の上に計画し、計画通りに作ること を正とするから • 仮説の誤りが⾒つかった時、時間的・コスト的にそれを是正 する余地が圧倒的に⾜りないから • 顧客はビジネス的な価値の実現を求めているのに対し、ベン ダーは成果物の完成を⽬指しているから
開発チームレンタルはどう良いのか • 仕様変更がいつでも何度でも出来るため、仮説が誤っていた ときの修正がしやすい • 仕様・バグの線引が必要ないため、責任範囲を定めるための ⼯数が必要なく、純粋に開発に注⼒できる • エンジニア⾃⾝が、仕様について提案し議論に参加すること が出来る
• 結果、成果物を完成することではなく、プロダクトの価値を 実現するためのものづくりが可能になる
プロダクトの価値とは何か • システムが完成さえすれば価値が実現される、というのは誤 解 • 価値とは、プロダクトの周辺の⼈間が喜んでいるという状態 である。例えば、 • ユーザーは、そのプロダクトを使って嬉しいか? •
サービス提供者は、プロダクトを提供してビジネス的メリット を得られるか?(わかりやすいのは利益)
開発チームレンタルは何を提供するのか • 資⾦もビジネスアイディアもあるのに、つくり⼿だけが⾜り ない企業が、早く・確実に市場にプロダクトをリリースする ことが出来ること • 開発プロジェクトに発⽣しがちな本質的でない問題をおさえ て、継続的にプロダクトを成⻑させていけること • プロダクトの価値を実現するために、仮説から試⾏錯誤しな
がら機能に落とし込んでいけること
価値のある失敗をする • ビジネス的メリットの実現を保証することは難しい • ビジネスとして成⽴するかどうかはプロダクト以外の要因にも 依存するため • 新規事業の成功率は10%未満、基本的にほどんど失敗する • 出来るだけ早く正確に、定義した仮説を具現化し、市場に問
うこと • 結果、失敗だったとしても、仮説が早く検証された事実には ⼗分価値がある
HOW もふもふなエンジニアの振る舞い
技術⼒の⾼さだけでは価値のある仕事は出来ない • mofmof inc.では技術⼒が⾼いのは当然であり、基礎能⼒で ある • 技術⼒の⾼さと、提供できる価値の⼤きさは正⽐例しない • 価値を提供出来る⽅法を⾝につけていなければ、提供できる 価値を⼤きく出来ない
• その⽅法論の⼀つが、スクラムやアジャイルである
ただ⾔われた通りに作らない • 開発業務の中では、プロダクトオーナーからつくって欲しい 機能が渡される • なぜその機能が必要なのか、ユーザーをどのように幸せにす るか、機能の⽬的にフォーカスして設計すること • 機能の⽬的が満たせれば作り⽅にはバリエーションがある •
よりよい実現の仕⽅を考え提案すること
理解の溝を積極的に埋める • 顧客(プロダクトオーナー)は開発のスペシャリストではない • 従って、欲しい機能を的確に伝えられるとは限らない • 抽象的で曖昧な仕様は、⾃ら具体化するように働きかけるこ と • 判断を仰ぐ必要がある場⾯では、相⼿に決めさせるのではな
く、選択肢を提⽰し、⾃⾝が推奨する案を⽰すこと
仕様変更は学習の成果である • 仕様が変わるということは、学習の結果、よりよい形に気付 いたということであり、プロダクトを成⻑させる機会を得た ということ • 仕様変更を否定することはプロダクトの成⻑を否定すること • リリース近くの仕様変更だったしても、やれるかやれないか は別として、それ⾃体は歓迎されるべき
リスクは早く検知して伝える • システム開発は不確実性との戦い • リスクは早く検知して、出来るだけ早く顧客に伝えること • 伝える際には必ず対応策をセットで伝えること • 顧客が気付くより早く気付いて、先回りして⼿を打つことが 信頼につながる
クイズ