Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
受託開発について_基礎編_.pdf
Search
Switch Science
February 19, 2025
18
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
受託開発について_基礎編_.pdf
Switch Science
February 19, 2025
More Decks by Switch Science
See All by Switch Science
ゆるトーク #2 PoCを語ろう
rumihirayama
0
38
Switch Science, Inc.
rumihirayama
0
12k
Featured
See All Featured
The browser strikes back
jonoalderson
0
1.8k
Site-Speed That Sticks
csswizardry
13
1.6k
The AI Search Optimization Roadmap by Aleyda Solis
aleyda
2
6.3k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
21
1.7k
Tips & Tricks on How to Get Your First Job In Tech
honzajavorek
1
800
How to build an LLM SEO readiness audit: a practical framework
nmsamuel
2
950
Statistics for Hackers
jakevdp
799
230k
The Cult of Friendly URLs
andyhume
79
7k
YesSQL, Process and Tooling at Scale
rocio
174
15k
Google's AI Overviews - The New Search
badams
0
1.6k
GraphQLとの向き合い方2022年版
quramy
50
15k
Building a A Zero-Code AI SEO Workflow
portentint
PRO
0
780
Transcript
受託開発について (基礎編) 2025/1/24 スイッチサイエンス九頭龍
受託開発とは クライアント (受託元)から開発者(受託先)へ欲しいものを依頼し、開発者はその要望 に忠実な成果物 を作り上げ、クライアントに納品し、クライアントから開発者へ支払いを 行う。そこのクライアントはその成果物を使ってビジネスを行うがその際に発生した問題 については、開発者に瑕疵があれば開発者が補修する義務を負う。瑕疵がなければク ライアント側は泣き寝入りする
受託開発の一般的な課題 - クライアント側 - 何が欲しいか を明確に整理するのが困難 - 自力で作る知識や能力やリソースが欠けているから受託に出すわけで - 原資が必要
- しかも想定よりも割高 になりがち(もし仮にクライアントが自社リソースを十分に持っていれば ほとんどの場合で間違いなくそちらの方が安上がりにできる) - 開発者側 - 要望が通りにくい - クライアントの要望のものを作ることが最優先であり「こっちの方が良いのになぁ」と思いなが らも十分に説得できず押し切られてしまうのが基本 - スケジュールが想定通りになりにくい - クライアント側のビジネスの都合 に振り回されるため、スケジュールの前倒しや分納の要 望、サンプル数の追加などの想定外の対応が頻繁に発生する
クライアント側の「よくあるつまずき」シリーズ
思ったより金がかかる - 市場にある量産品は安い - 初期費用を生産台数で按分している(場合によっては無視している) - 部品を安く購入している - 歩留まりが良い -
リアルな人件費の最低でも2倍(できれば 3倍)もらわないと開発側は容易に赤字 になってしまう - 周辺の間接費や会社そのものの固定費(オフィス家賃など)を考慮する必要がある - きっちり見積もり工数どおりの金額に設定するとあとで柔軟性が利かなくなる(何かあるごとに見積 もりと請求をする手間が発生する) - 瑕疵があった場合は自費で補修することなどが契約書に含まれている - 試作部品はなんでも高い - どんな試作にもセットアップ費用や管理費が隠れている - それらは「(費用)➗(少ない台数)」で計算されるので安いわけがない
(参考)なんとなくの金額感 - 金型費用 - 小さい部品で安い金型だとしても 200万円を下ることはあまりない - モバイル機器程度のサイズでも部品点数が多ければすぐに合計 1000万円は超える -
金型のちょっとした修正ですぐに数十万円かかる - 基板作成 - 部品実装無しの生基板とシルクスクリーンは 10~20万円程度でできる - 実装費用は部品点数が多かったり実装がめんどくさい部品があると一枚あたり 1000円を超えるこ とも珍しくない - だいたい試作なら数十万から 100万円の実費でできることが多い(実装部品はブレが大きいので除 く) - 特急料金というもの - 多くの試作業者は日程短縮のための「特急料金」を設定している。通常の『効率の良いワークフ ロー』を崩して差込対応するための補填金と言える - 金額は業者によってピンキリだが数十万円と思っておくと良い
思ったより時間がかかる - 試作を複数回やってから生産に至る - いきなり量産することはほぼあり得ない - ただ「モノを作る」だけでも時間はかかる - 部品の調達、業者の手配、契約書類の締結、製造ラインの空き具合、輸送など多くの事情の積み上げで日程 が決まる
- 部品のリードタイムは不安定 - グローバルな供給状況に左右される - 「在庫があるならすぐ」「在庫がないと半年先」というようなこともある - 「検証」という時間を忘れてはならない - 「とりあえず動いたー」で納品することはない - CADで線を引くのは工数全体の1/10 - 調査したり、検証したり、レビューして作り直したり。 CADをいじっている「作業時間」よりもよっぽどボリュームが 大きい時間がもろもろ存在する - トラブルは起こる もの - 無駄に楽観しても良いことはない
(参考)なんとなくの時間感覚 - 3Dプリント:数日から1週間 - 生基板作成:1週間から2週間 - 部品実装:数日 - 非常にシンプルなブレイクアウトボードの設計:2~3週間 -
樹脂金型の開発:1.5~3ヶ月
開発者側の「困った相談」シリーズ
PoC用の基板を作って欲しいのですが予算20万円です - 自分で設計して自分で手配しても結構ギリギリ - 開発者の設計工数に対する報酬はどこから出てくるの?
回路図も基板図もあるんで2週間で基板手に入りませんか - 部品在庫が十分にある前提 - 「無検証」で納品させていただくことが前提=品質保証はしない - そうは言ってもあとで揉める ことがあるので正直やりたくない。。。
ある製品アイディアのPoCをやりたくて予算は200万円 - 要件定義が明確でない場合「具体的に何を作るか」までを紐解くコンサル工数 が上 乗せになる(費用として明示するかしないかは置いておいて)期間は1週間では終 わらないし、あまり安くはない - 筐体付きのアイテムの場合、例えば試作品を10台作ったら部品代合計だけですぐ に100万円は超えてしまう。会社としてきちんと利益を取ることを考えたら。。。さて 開発工数にあといくら残ってる?
例の試作品ですが2週間前倒しで2台で良いのでください - 開発プロセスはほぼ直列で進んでいく - 部品入手できた分から順次基板実装なんてしない - 部品が揃ってから - 検査やファームウェア書き込みなどもまとめて流れ作業でやる -
ライン組んだりバラしたりはとても手間 - メカ部品の製造工程も仮に分納にしたとしても 1日2日しか前後しない - ほとんどの工程において2台作るか30台作るかで手間はあまり変わらない - 前倒しできるのは総組立と動作検証くらい - さて何日前倒しできるでしょうか
何度も再見積もりをやり結局ポシャる - 見積もり工数はタダではありません!
「おすすめしたいこと」シリーズ
PoCの台数を作り過ぎない 5~20台が良いところ - PoC用の試作品は量産品と違う - それなりの不良が発生するので PoCで大量にばら撒くと大変なことになる - 耐久性も評価されていないはず。使っている途中できっといくつか壊れる -
PoCに多くの人員は投入されていないはず - サポートに手がかかるし、そもそも PoCは明確な結果を得るために計測や観測、あるいはそれらの データのまとめが必須となるはず。サポートに手がかかるとその工数を割くことができない
市販品の価格は一旦忘れる 多くの市販品は、数千台ではなく数十万台、数百万台作る想定で価格が決まっている。 仮にその台数が発注時にコミットできないのであれば、一旦市場品の価格は忘れるべ き。そうしなければ何も作れない。
品質保証について開発側に丸投げし過ぎない もちろん一定の信頼関係において丸投げ することは構わない。しかし、最終的にユー ザーからの批判に晒されるのはほとんどの場合でクライアント御自身になるということを 理解しておく必要がある。 「どのラインはOKで、どのラインはNGか」これはクライアントが主体的に決めていく こと が好ましい。 そのラインがあまりに厳しい場合、開発者側の提示金額が上がるが、それはある意味で 契約が目的どおりに遂行される上での健全なプロセスだと言える。双方にどこが妥協可
能であるのかを早めに擦り合わせておくことは受託開発の上で非常に重要。