月額制受託開発「開発チームレンタル」
•Télécharger en tant que PPTX, PDF•
1 j'aime•4,683 vues
従来のように決められたものを、 決められた通りに作る開発のやり方ではなく、 ビジネスの形の変化に合わせて柔軟に作るものを変えていく作り方を実現する月額制受託開発「開発チームレンタル」サービス。 発注者/受注者という関係性を越えて、チームの一員としてビジネス価値の実現のために最良である作り方を選択します。
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à 月額制受託開発「開発チームレンタル」
Similaire à 月額制受託開発「開発チームレンタル」 (20)
Plus de Atsushi Harada
Plus de Atsushi Harada (18)
月額制受託開発「開発チームレンタル」
- 1. Copyright 2015 mofmof inc. All Rights Reserved. 月額制受託開発 開発チームレンタルサービス
- 2. MOFMOF INC.とは • 月額制受託開発「開発チームレン タルサービス • 3日間で実際に動くWEBサービスを 作る「いきなりMVP」 • エンジニア向けポートフォリオ サービス「Peers」
- 3. MOFMOF INC.
- 4. 最近の実績
- 8. 電子書籍販売プラットフォームの事例 • 既にサービスがあり、開発速度をアップするため にエンジニアを追加 • 開発フローの整備と、チームビルディングを支援 • 参画から2ヶ月、チームの運用フローを大きく改善 し、ビジネスサイドとエンジニアサイトの関係性 が向上。現在も継続中。
- 9. 新規事業の悩み 1. アイディアと顧客は持っているけど、開発リソー スがない(足りない) 2. 社内で開発リソースを抱えてしまうことのリスク が大きい 3. 決まったものを作るだけの開発会社しかなく、外 注しづらい
- 11. MOFMOFの開発チームレンタルのメリット 1. ベテランエンジニアが確保できるので、立ち上が りが早く、社内で雇用・教育するコストがかから ない 2. ビジネスに合わせていつでも仕様変更が出来る 3. 最初に全てを決める必要がないため、早い段階で 実際に動くものを確認できる
- 12. エンジニア確保
- 13. エンジニア採用の問題点 • 採用コストが高すぎる • 適性の判断が難しく、スキルミスマッチが発生す る • 採用出来ても社内の文化にとけこめず退職してし まう
- 14. 開発チームを作るコスト（参考） いつ採用 できる？ 本当に 優秀？ 途中で辞め ちゃうチーム内で 分裂 ※平均年収500万円のエンジニアを雇うと仮定 • 採用: 1人獲得単価100万円*3人=300万円 • 給与: 半年間500/2 * 社会保険等1.2 * 3人 = 900万円 • 計1,200万円
- 15. 新規事業に特化した作り方
- 18. 従来の開発の問題点 • 仕様かバグかで揉める • 開発途中での仕様変更が容易に出来ない • ビジネス価値の実現よりも、責任範囲の線引に多 くのコストをかける不毛なやり方
- 21. プロダクトをコントロール出来るメリット • ビジネスプランに合わせて、作るものを細かく変更で きる • 最初に全ての仕様をまとめる必要がないため、ビジネ スが完全に見えている状態でなくてもスタート出来る • 実際に動くものを確認しながら、ビジネスとプロダク トを成長させることが出来る
- 22. 採用テクノロジー
- 23. 従来の受託開発との違い 従来の受託開発 mofmofの 開発チームレンタル 仕様変更 柔軟に仕様変更しづらく、する必要があ る際は、都度再設計・再見積もりが必要 になるため、交渉分コストが余計にかか る 開発中であればいつでも仕様変更 が可能。月額固定なので交渉分のコ ストなどの無駄が発生しない 費用 あとから仕様がブレた際の修正工数を 含むため実際にかかる費用の2〜3倍く らいになってしまう 仕様がブレても月額固定で対応できる ため、バッファ分を含まないので必要 以上の費用がかからない 向いている プロジェクト ・既存プロダクトの完全リプレース ・ライフサイクルの短いもの ・新規立ち上げなど、最初に仕様を決 めることが難しいもの ・長期的にユーザーの反応を見ながら 開発を繰り返す必要があるもの 向いてるスタイル なるべくお任せにしたい、質問に回答す る程度だけで進めたい 動くものを確認しながら最適な形を模索 したい 契約形態 完成責任を負う請負契約 役務提供に責任を負う準委任契約
- 24. 料金 スタンダード プロフェッショナル スターター ビジネス構築 サポート - ◯ ◯ プロダクト開発 (エンジニア１人) ◯ ◯ - 定例ミーティング ◯ ◯ ◯ 金額 60万円/月 70万円〜/月 10万円〜/月 〜備考 ユーザーストーリー出し など、アイディアから事 業の落し込みが出来て いる方向け ビジネス構築と、プロダ クト開発の両輪を継続し て進めたい方向け アイディアから事業の落 し込みがまだ出来ておら ず、開発着手より前の段 階の方向け ・チャットによるビジネス 構築コンサルティング ・ビジネス構築のための 資料提供 ※ エンジニア増員は+60万円〜可能 ※ 料金は税別価格
- 25. 料金について補足 • 稼働時間は規定しません (目安はおよそ1ヶ月分程度) • 本番・検証環境費は別途負担ください • 役務提供に責任を負う準委任契約
- 26. オンデマンドプラン • 開発速度を柔軟にスピードアップ・ダウンできる • 開発した分だけ時間単位で精算 • 必要な時に必要な開発力だけアサインするので遊 休コストが発生しない • 5,000円/1時間(税別)
- 27. プラン例 60万 60万 120万 120万 30万 30万 0万 50万 100万 150万 200万 スタンダード スタンダード +オンデマンド x1.5 x1.5 +オンデマンド 必要な分だけ増減可能
- 28. ご依頼の際のお願い • プロジェクトに参加すること(丸投げ禁止) • 定例ミーティングに参加すること(Skype可) • 問題はチームの責任として互いに対処すること • スコープを固定しないこと • 電話を避けてチャットでコミュニケーション • ツールの使用 Pivotal Tracker, Slack, Github
- 29. 保守運用について
- 30. 月額開発契約休止と保守契約について • 月額開発契約を休止にしている月は、原則、機能 追加・不具合に関わらず開発が出来ません • 運用を継続するためには「保守プラン」を検討く ださい • 少量の開発を継続したい際は、「継続開発プラ ン」を検討ください
- 31. 保守運用プラン 通常プラン 継続開発プラン 金額 ¥30,000/月 ¥98,000/月 + 開発した分だけ(*) システム停止時の 復旧対応 ○ ○ チャットでの問い 合わせ対応 ○ ○ サーバ運用 ○ ○ サーバ脆弱性対策 ○ ○ 定例ミーティング (Skype) - ○ 開発マネジメント 代行 - ○ * 5,000円/h (税別)
- 32. システム停止時の復旧対応 • 障害によるシステム停止時の復旧作業 • システム全体が停止してしまうような致命的な不 具合の修正 • 上記のような不具合を除く個別の不具合について は対応範囲外 • 営業時間中(平日10:00〜19:00)の対応
- 37. 開発マネジメント代行 • ソフトウェアの改修が必要になった場合に、開発マネジメント を引き続き実施します • 保守フェーズでの開発は、mofmofが契約している複数人のリ モートエンジニアが対応します • 作業時間単位に見積もり、開発・精算する方式となります • 作業リソースは一定ではありません。開発ペースにバラつきが でます • スケジュールは確約いたしません
Notes de l'éditeur
- TODO それぞれをアイコン化したい
- TODO それぞれをアイコン化したい
- TODO それぞれをアイコン化したい
- サーバ監視ツールを使うと思うので、ツール利用料は別途お支払いください。
- TODO それぞれをアイコン化したい
- - 使用する技術は固定してます。PHPでは作りません。
- 稼働時間を規定しないので成果で判断してください。目安は半月分くらい。 規定しない理由は、かけた時間 = 成果ではないため。生産性を最大にするための仕組み。 検証、本番環境は直接契約してください。費用は従量課金制です。 x2プランは状況によって対応できない場合があるので早めに相談を TODO - 料金プランを表にする
- 「うちの責任は〜までだからあとは知らないよ」っていう対処をせずに、互いに最善の打開策を探して対処すること スコープを固定してしまうと、責任範囲を明確にするために厳密な文書管理が必要になってしまうため。 また、スコープ通りに作ることが正になってしまい、後から発覚した重要な事柄に対応出来ず、本来のビジネス価値とは無関係に進めてしまう傾向があるため。 週次ミーティングは弊社でお願いします。もっとも価値を提供できる時間は作業している時間。それを再優先したい。月額制でやる以上は移動にかけるコストは全てロスになるため。 ある程度形が出来てきたらSkypeでもOK
- パートナーエンジニアが開発を担当する 10pt前後くらいの開発なら20万あたりでおさまる。
- - 電話問い合わせがあると強制的に作業を中断せざるをえなくなり、お客さまへの成果提供のマイナスになるため。