もふもふなエンジニアの心得/mofmofinc-engineer-knowledge

mofmofの開発チームレンタルで提供する価値について。
もふもふのエンジニアに必要な基礎的な考え方。振る舞いの仕方について。

Transcript

1. もふもふなエンジニアの⼼得
   mofmof inc.
   

   View Slide

2. クイズ
   • このトレーニングの終了時にクイズを出題します
   • 回答できるようにしっかり聞いていてください
   

   View Slide

3. Why
   How
   What
   

   View Slide

4. WHY
   なぜ開発チームレンタルをやるのか
   

   View Slide

5. なぜ開発チームレンタルをやっているのか
   • かつて代表・原⽥がSIerで開発の仕事していた時代の話
   • ⽇々、顧客の怒号が⾶んでいる
   • 「こんな機能誰が使いこなせるんだろう」という機能を作ら
   なければならなかった
   • ちゃんとつくったのに「これじゃ使い物にならないよ」と⾔
   われた
   • 作ることは好きだったが、どうしてこの仕事はこんなにも不
   ⽑なことが多いのだろうかと感じていた
   

   View Slide

6. なぜ開発チームレンタルをやっているのか
   • 「価値がある」と感じられるものづくりをしたい
   • つくったもので⼈に喜んでもらいたい
   • ⼀労働⼒ではなく、主体となってものづくりする仕事がした
   い
   

   View Slide

7. 従来型の受託開発はなぜうまく⾏かないのか
   • 「要件定義」という仮説の上に計画し、計画通りに作ること
   を正とするから
   • 仮説の誤りが⾒つかった時、時間的・コスト的にそれを是正
   する余地が圧倒的に⾜りないから
   • 顧客はビジネス的な価値の実現を求めているのに対し、ベン
   ダーは成果物の完成を⽬指しているから
   

   View Slide

8. 開発チームレンタルはどう良いのか
   • 仕様変更がいつでも何度でも出来るため、仮説が誤っていた
   ときの修正がしやすい
   • 仕様・バグの線引が必要ないため、責任範囲を定めるための
   ⼯数が必要なく、純粋に開発に注⼒できる
   • エンジニア⾃⾝が、仕様について提案し議論に参加すること
   が出来る
   • 結果、成果物を完成することではなく、プロダクトの価値を
   実現するためのものづくりが可能になる
   

   View Slide

9. プロダクトの価値とは何か
   • システムが完成さえすれば価値が実現される、というのは誤
   解
   • 価値とは、プロダクトの周辺の⼈間が喜んでいるという状態
   である。例えば、
   • ユーザーは、そのプロダクトを使って嬉しいか？
   • サービス提供者は、プロダクトを提供してビジネス的メリット
   を得られるか？(わかりやすいのは利益)
   

   View Slide

10. 開発チームレンタルは何を提供するのか
    • 資⾦もビジネスアイディアもあるのに、つくり⼿だけが⾜り
    ない企業が、早く・確実に市場にプロダクトをリリースする
    ことが出来ること
    • 開発プロジェクトに発⽣しがちな本質的でない問題をおさえ
    て、継続的にプロダクトを成⻑させていけること
    • プロダクトの価値を実現するために、仮説から試⾏錯誤しな
    がら機能に落とし込んでいけること
    

    View Slide

11. 価値のある失敗をする
    • ビジネス的メリットの実現を保証することは難しい
    • ビジネスとして成⽴するかどうかはプロダクト以外の要因にも
    依存するため
    • 新規事業の成功率は10%未満、基本的にほどんど失敗する
    • 出来るだけ早く正確に、定義した仮説を具現化し、市場に問
    うこと
    • 結果、失敗だったとしても、仮説が早く検証された事実には
    ⼗分価値がある
    

    View Slide

12. HOW
    もふもふなエンジニアの振る舞い
    

    View Slide

13. 技術⼒の⾼さだけでは価値のある仕事は出来ない
    • mofmof inc.では技術⼒が⾼いのは当然であり、基礎能⼒で
    ある
    • 技術⼒の⾼さと、提供できる価値の⼤きさは正⽐例しない
    • 価値を提供出来る⽅法を⾝につけていなければ、提供できる
    価値を⼤きく出来ない
    • その⽅法論の⼀つが、スクラムやアジャイルである
    

    View Slide

14. ただ⾔われた通りに作らない
    • 開発業務の中では、プロダクトオーナーからつくって欲しい
    機能が渡される
    • なぜその機能が必要なのか、ユーザーをどのように幸せにす
    るか、機能の⽬的にフォーカスして設計すること
    • 機能の⽬的が満たせれば作り⽅にはバリエーションがある
    • よりよい実現の仕⽅を考え提案すること
    

    View Slide

15. 理解の溝を積極的に埋める
    • 顧客(プロダクトオーナー)は開発のスペシャリストではない
    • 従って、欲しい機能を的確に伝えられるとは限らない
    • 抽象的で曖昧な仕様は、⾃ら具体化するように働きかけるこ
    と
    • 判断を仰ぐ必要がある場⾯では、相⼿に決めさせるのではな
    く、選択肢を提⽰し、⾃⾝が推奨する案を⽰すこと
    

    View Slide

16. 仕様変更は学習の成果である
    • 仕様が変わるということは、学習の結果、よりよい形に気付
    いたということであり、プロダクトを成⻑させる機会を得た
    ということ
    • 仕様変更を否定することはプロダクトの成⻑を否定すること
    • リリース近くの仕様変更だったしても、やれるかやれないか
    は別として、それ⾃体は歓迎されるべき
    

    View Slide

17. リスクは早く検知して伝える
    • システム開発は不確実性との戦い
    • リスクは早く検知して、出来るだけ早く顧客に伝えること
    • 伝える際には必ず対応策をセットで伝えること
    • 顧客が気付くより早く気付いて、先回りして⼿を打つことが
    信頼につながる
    

    View Slide

18. クイズ
    

    View Slide