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.1k
もふもふなエンジニアの心得/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
330
スクラムとモジャイル/scrum-and-mojile
harada4atsushi
0
7.3k
リーン・スタートアップとMVP/lean-startup-mvp
harada4atsushi
0
25k
リーンキャンバスの作り方/how-to-make-lean-canvas
harada4atsushi
0
8.5k
見積もり/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
Fake “Agile” is the Norm: How to Instill Agility, not Agile Practices
johannarothman
PRO
0
1.3k
フォロワーシップ、ビジョン共有の重要性を学べる「部課長ゲーム」
chibanba1982
PRO
0
990
「スクラムマスターしているけど、 上手くできている気がしない」からの脱却!チームへ影響を与えられるスクラムマスターになるために
rakuraku0615
1
2.5k
危機管理コンセンサスゲーム「船長の決断 カード版」
chibanba1982
PRO
0
400
コンセンサスゲーム「砂漠からの脱出 オンライン版」
chibanba1982
PRO
0
420
サステナビリティレポート2024
hamayacorp
0
310
心理的安全性をテーマにしたチームビルディングゲーム「ベストチーム」
chibanba1982
PRO
0
540
営業疑似体験ゲーム「ヒアリングチャレンジオンライン版」
chibanba1982
PRO
0
150
コンセンサスゲーム「砂漠からの脱出 カード版」
chibanba1982
PRO
0
980
技術広報の集い #5 LT 資料 2025 年挑戦したいこと
n0mzk
0
180
コンセンサスゲーム「無人島での出来事」
chibanba1982
PRO
0
410
株式会社gecogeco 会社紹介資料
gecogeco
2
2.5k
Featured
See All Featured
Building Applications with DynamoDB
mza
92
6.2k
Testing 201, or: Great Expectations
jmmastey
41
7.2k
The Cult of Friendly URLs
andyhume
78
6.1k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
BBQ
matthewcrist
85
9.4k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Done Done
chrislema
182
16k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Embracing the Ebb and Flow
colly
84
4.5k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.9k
Raft: Consensus for Rubyists
vanstee
137
6.7k
Transcript
もふもふなエンジニアの⼼得 mofmof inc.
クイズ • このトレーニングの終了時にクイズを出題します • 回答できるようにしっかり聞いていてください
Why How What
WHY なぜ開発チームレンタルをやるのか
なぜ開発チームレンタルをやっているのか • かつて代表・原⽥がSIerで開発の仕事していた時代の話 • ⽇々、顧客の怒号が⾶んでいる • 「こんな機能誰が使いこなせるんだろう」という機能を作ら なければならなかった • ちゃんとつくったのに「これじゃ使い物にならないよ」と⾔
われた • 作ることは好きだったが、どうしてこの仕事はこんなにも不 ⽑なことが多いのだろうかと感じていた
なぜ開発チームレンタルをやっているのか • 「価値がある」と感じられるものづくりをしたい • つくったもので⼈に喜んでもらいたい • ⼀労働⼒ではなく、主体となってものづくりする仕事がした い
従来型の受託開発はなぜうまく⾏かないのか • 「要件定義」という仮説の上に計画し、計画通りに作ること を正とするから • 仮説の誤りが⾒つかった時、時間的・コスト的にそれを是正 する余地が圧倒的に⾜りないから • 顧客はビジネス的な価値の実現を求めているのに対し、ベン ダーは成果物の完成を⽬指しているから
開発チームレンタルはどう良いのか • 仕様変更がいつでも何度でも出来るため、仮説が誤っていた ときの修正がしやすい • 仕様・バグの線引が必要ないため、責任範囲を定めるための ⼯数が必要なく、純粋に開発に注⼒できる • エンジニア⾃⾝が、仕様について提案し議論に参加すること が出来る
• 結果、成果物を完成することではなく、プロダクトの価値を 実現するためのものづくりが可能になる
プロダクトの価値とは何か • システムが完成さえすれば価値が実現される、というのは誤 解 • 価値とは、プロダクトの周辺の⼈間が喜んでいるという状態 である。例えば、 • ユーザーは、そのプロダクトを使って嬉しいか? •
サービス提供者は、プロダクトを提供してビジネス的メリット を得られるか?(わかりやすいのは利益)
開発チームレンタルは何を提供するのか • 資⾦もビジネスアイディアもあるのに、つくり⼿だけが⾜り ない企業が、早く・確実に市場にプロダクトをリリースする ことが出来ること • 開発プロジェクトに発⽣しがちな本質的でない問題をおさえ て、継続的にプロダクトを成⻑させていけること • プロダクトの価値を実現するために、仮説から試⾏錯誤しな
がら機能に落とし込んでいけること
価値のある失敗をする • ビジネス的メリットの実現を保証することは難しい • ビジネスとして成⽴するかどうかはプロダクト以外の要因にも 依存するため • 新規事業の成功率は10%未満、基本的にほどんど失敗する • 出来るだけ早く正確に、定義した仮説を具現化し、市場に問
うこと • 結果、失敗だったとしても、仮説が早く検証された事実には ⼗分価値がある
HOW もふもふなエンジニアの振る舞い
技術⼒の⾼さだけでは価値のある仕事は出来ない • mofmof inc.では技術⼒が⾼いのは当然であり、基礎能⼒で ある • 技術⼒の⾼さと、提供できる価値の⼤きさは正⽐例しない • 価値を提供出来る⽅法を⾝につけていなければ、提供できる 価値を⼤きく出来ない
• その⽅法論の⼀つが、スクラムやアジャイルである
ただ⾔われた通りに作らない • 開発業務の中では、プロダクトオーナーからつくって欲しい 機能が渡される • なぜその機能が必要なのか、ユーザーをどのように幸せにす るか、機能の⽬的にフォーカスして設計すること • 機能の⽬的が満たせれば作り⽅にはバリエーションがある •
よりよい実現の仕⽅を考え提案すること
理解の溝を積極的に埋める • 顧客(プロダクトオーナー)は開発のスペシャリストではない • 従って、欲しい機能を的確に伝えられるとは限らない • 抽象的で曖昧な仕様は、⾃ら具体化するように働きかけるこ と • 判断を仰ぐ必要がある場⾯では、相⼿に決めさせるのではな
く、選択肢を提⽰し、⾃⾝が推奨する案を⽰すこと
仕様変更は学習の成果である • 仕様が変わるということは、学習の結果、よりよい形に気付 いたということであり、プロダクトを成⻑させる機会を得た ということ • 仕様変更を否定することはプロダクトの成⻑を否定すること • リリース近くの仕様変更だったしても、やれるかやれないか は別として、それ⾃体は歓迎されるべき
リスクは早く検知して伝える • システム開発は不確実性との戦い • リスクは早く検知して、出来るだけ早く顧客に伝えること • 伝える際には必ず対応策をセットで伝えること • 顧客が気付くより早く気付いて、先回りして⼿を打つことが 信頼につながる
クイズ