projects-and-solutions - プログラムをコーディングしない理由は？

Question

悪魔の支持者を演じましょう。ソリューションをコーディングするのではなく、高価なパッケージを購入するように経営陣に与える理由は何でしょうか。

score 25 · Accepted Answer

購入するのが安い。
ドメインが既存の開発者に馴染みがない場合
リスクのレベルが許容できないほど高い場合
時間の重要性。

結局のところ、すべてが何らかの形でポイント1に要約されます。

score 11 · Accepted Answer

単純; 自分で作成するための総所有コスト（TCO ）がパッケージのTCOよりも大きい場合に購入します。（自分で作成するTCOを確実に計算する方法は、読者に残された演習です;-)）

それほど単純ではありません。ソフトウェアがコアビジネスである場合、またはソフトウェアが独自のセールスポイントである場合のDIY。あなたはあなたの脳やあなたの心を外注したくありません。

score 2 · Accepted Answer

非常によく似たプログラムがすでに存在します。あなたが楽しみ/学習目的のためにそれをしているのでない限り

score 2 · Accepted Answer

コンポーネントを購入する利点: - 開発するよりも購入する方が安いかもしれません - (場合によっては) そのチームはそのコンポーネントを開発するノウハウを持っていません。そのため、そのノウハウを収集する時間は法外です - メンテナンス費用はサプライヤーに転嫁されます

欠点 - コンポーネントのライフサイクルを制御できない (新しいリリースがいつ作成されるか、どのような修正を行う必要があるかなどを含む) - 適応/統合の作業が必要になる場合があります。- 統合の問題により、パフォーマンスが低下する可能性があります。

score 2 · Accepted Answer

私はこれのかなりの数の例を見てきましたが、それは 2 つに分かれていると思います。まず、メッセージングミドルウェア、データベースなどの「コモディティ」ソフトウェアがあります。これは通常、常に購入されています。それが私のビジネスの絶対的な核心でない限り、私は座って独自の非同期メッセージングシステムを作成することは決してありません。第二に、付加価値の部分がありますが、これはかなり違うと思います。

私は金融の仕事をしていますが、さまざまな金融市場商品のリスク/予約/バックオフィス機能を実行するいくつかのベンダーシステム (Murex、Summit、Sophis など) があります。これらを選択することは、2 つの理由から危険だと思います。

第一の理由は、あなたはソフトウェアの面で競合他社より一歩先を行っているわけではなく、独自の価値を追加していないため、どのくらいの価格を請求できるか、またはいくら請求できるかという点で「底辺への競争」になるだけです。あなたが取ることができるリスク。

2 つ目の理由は、ソフトウェア開発者の観点からはより重要なことですが、ベンダーのシステムが今はあなたに合っているかもしれませんが、2、3 年後にはあなたに合わないかもしれません。その上にビジネスを構築し、それが突然変化した場合、または必要なときに変化しなかった場合、あなたは空虚なままになる可能性があります. または、会社が倒産したり、市場から撤退したい場合、2 つの選択肢があります。それを購入するか、すべてのシステムをゼロから書き直すかです。

付加価値ベンダーシステム (典型的な例としては、Murex、Sophis、Summit など) を必死に止めて、独自のシステムを作成しようとしている企業の数を数えきれませんでした。

付加価値のためのベンダーシステムに対する補足的な議論は、コンサルタント/請負業者は通常、はるかに高価であるということです. ここでは、上級の c# コンサルタントを 1 日 x00 ポンドで利用できます。ベンダーシステムの経験を持つコンサルタントは、約 20 ～ 25% 多くなります。

score 2 · Accepted Answer

私は彼らに本当の理由を教えます（私が実際に働きたい会社にいたと仮定すると、つまり、PHBに奴隷にされたのではなく）。通常、これは「これがあれば仕事をより早く終わらせることができます。私の時間はあなたにとって非常に価値があります」です。

しかし、もっと役に立つのは、「ソフトウェアにお金を払いたいという状況がいつ発生するか」という質問であれば、次のとおりです。

問題のソフトウェアが、会社が収益を上げるコアコンピタンスではない場合。非ソフトウェア企業の場合、同じことですが、「会社」の代わりに「部門」があり、「お金を稼ぐ」の代わりに「その存在を正当化する」. というわけで、パッケージを入手しようとしています。問題は、高価なものを入手するかどうかです。

その場合

適切な無料オプションが存在しない場合、または機能が優れているために高価なソフトウェアが無料よりも優れている場合、(自分でバグを修正する必要がないため) TCO が低くなる、などなど。

または:

パッケージが単なるソフトウェアではなく、ホストされたサービスである場合、サービスをインストールするために誰かをトレーニングし、サービスを維持するために 24 時間年中無休で全人をオンコールしておく組織にとってのコストは、「高価」よりもさらに高くなります。パッケージ。これは TCO の別の部分ですが、ソフトウェア自体のコストがどちらの方法でも同じであっても適用されます。

最初のポイントが意味することは、ゲーム会社は独自の IDE を作成するべきではなく、Web アプリ会社は独自のコンパイラーを作成するべきではなく、銀行のソフトウェア部門はオフィスアプリケーションを作成するべきではないということです。ゲーム、ウェブアプリ、トレーディングソフトウェアなど、実際に締め切りがあるものを書くよりも、それを行う方がよい. 明らかに、いくつかの例外があります。非常に小さなスクリプトまたは Web アプリケーションが必要な場合は、必要な機能を備えた市販のものを見つけるよりも、それを作成する方が簡単な場合があります。

2 番目のポイントでは、「より良い」とは、組織によって意味が異なります。機能が同等であると仮定すると、部門に Linux オタクが大勢いる場合、Linux オタクがいない場合よりも無料のオプションの方がおそらくプラスポイントが多く、問題のパッケージの SLA も必要です。「パッケージ」が開発をサポートするだけでなく、フリーでない製品にコンパイルされる場合、GPL のようにフリーなソフトウェアは明らかに役に立ちませんが、MIT のようにフリーなソフトウェアはおそらく役に立たないでしょう。大丈夫。等々。

score 1 · Accepted Answer

非常に単純化されていますが、次のうち最小のものを選択してください。

自作ツールの場合: cost = (task_execution_time * uses * $/user-h + tool_development_time * $/dev-h
購入したツールの場合: cost = task_execution_time * uses * $/user-h + tool_purchase_price
ツールなし: cost = task_execution_time * uses * $/user-h

cost は、実行task uses回数のコストです。task_execution_time は、オーバーヘッドを含むタスクの実行にかかる (人) 時間です。tool_development_time は、ツールの開発にかかる時間です。

シンプルにするために、多くの変数を省略しています。合わせてさらに追加してください:)

score 0 · Accepted Answer

新しいソリューションの開発にかかるコストと時間は、ソリューションの購入にかかるコストと時間に比べて高くなります。通常、経営陣はこれら2つの要因に非常に敏感です。

score 0 · Accepted Answer

それはより安くなりますが、それはあなたがパッケージが機能する方法に合うようにあなたのビジネス慣行を修正する準備ができている場合に限ります。ビジネス慣行に合わせてパッケージに大量のカスタマイズを実行すると、ほとんどの場合、カスタムアプリを最初から作成するよりもコストがかかり、多くの場合、涙が出ます。

score 0 · Accepted Answer

それは、経営陣が開発者に何をコーディングしてほしいかによって部分的に異なります。

ゲーム開発会社が独自のメールソリューションを展開しているとしたら、それはもったいないことです。才能のあるゲーム開発者は、より楽しいゲーム開発を行うのではなく、独自の SMTP クライアントおよびサーバーシステムをコーディングしています (これは、開発者が雇用されたときに念頭に置いていた可能性のある「ミッションステートメント」の類似性におそらく反することになることは言うまでもありません)。 .

代わりに、小さなユーティリティなどをコーディングしている場合は、価値があるかもしれません。インターンがいる場合、それは彼らに開始させるのに適したプロジェクトになる可能性があります。または、一部の開発者がゲームの物理学にうんざりして飽きて、もっと当たり障りのないことをしたい場合は、しばらくの間それに取り組むことができます.

score 0 · Accepted Answer

自分の車を一から作るとしたら、おそらく非常に高価で現実的ではありませんが、既製の車を購入すると、おそらくはるかに安く、はるかに現実的になります.

同じことがソフトウェアにも当てはまります (ほとんどの場合)。オーダーメイドのコードはすべて、開発するだけでなく、テストしてサポートする必要があります。製品をクライアントの要件に適合させることができれば、一般に、より費用対効果の高いソリューションになる可能性があります。ただし、製品が設計されていないものを要求する一連の要件に靴をはめ込まれた場合、問題が発生すると思います。

score 0 · Accepted Answer

いくつかの理由

このソリューションはコアビジネスプロセスをサポートしませんが、財務、人事、施設管理などのコモディティプロセスをサポートします。競合他社との違いはありません (コアプロセスと非コアプロセスは異なります)。あなたの社内開発スキルは、会社に競争力を与えるソリューションを作成および維持するために、より有効に活用できます。
前者は、ソリューションが既存または将来のソリューションと高度に統合される必要がない場合に適用されます (比較的分離されたプロセスをサポートします)。
社内で開発されたアプリケーションのライフサイクル全体にわたって、保守のための予算や人員を配置する必要はありません。数値はさまざまですが、私が見ていて信頼できる数字の 1 つは、カスタムアプリケーションの初期開発コストはライフサイクルコスト全体の 10 分の 1しか占めていないということです。確かに、これにはエンドユーザーのトレーニング、O/S のアップグレード、統合など、外部から調達したソリューションにも影響するものが含まれますが、最初の価格が 10 倍になると、ほとんどの管理者は一時停止することになります。
前者の特殊なケース:開発、保守、および運用のスキルが不足しているか、組織のボトルネックになっている可能性があります。スキル不足はすべて、十分な時間とお金で満たすことができますが、必ずしも許容範囲内であるとは限りません。スタッフが取得する必要がある追加のテクノロジスキルは、既存のスキルを開発および維持するための時間を短縮することを意味します。多様な技術環境のスキルコストは、線形以上の速度で増加します...
たとえば、Peter が述べているように、20% のコスト超過が成功したプロジェクトと見なされることが多いビジネスでは、予測可能だが高いコストは開発プロジェクトを開始するリスクに勝る可能性がありますが、失敗したプロジェクトには基本的に制限がありません...
Vatine も気付いているように、商用ソフトウェアは現在入手可能であり、インストールとエンドユーザーのトレーニングによって遅れるだけです。確かに、SAP のようなもののインストールは 1 日で完了しません...

これは、ベンダーがかなり安定している場合に適用されます。規模が小さいか、資金力が弱い場合、商用ソフトウェアは社内開発よりもはるかに大きな賭けになる可能性があります。

どのような方法でも、ロックイン効果が得られます。実際に使用されているアプリケーションから移行するのは決して無料ではなく、めったに安価ではありません。

score 0 · Accepted Answer

ソフトウェアを購入する理由はたくさんあります。私の意見では、最も重要なのは次のとおりです。

組織内の知識と専門知識の欠如
市場や法律（税制）の変化に迅速に対応する人材の不足

アウトソーシングの利点:

予算が立てやすい
採用不要、人材育成不要
厳格なサービスレベル契約を結ぶ能力

score 0 · Accepted Answer

つまり、開発リソースが利用可能であれば、X の年間サブスクリプションを置き換えるために 2 倍の 1 回限りの開発コストを正当化できます。また、最終的なソリューションがビジネスニーズを正確に対象としているのに対し、サードパーティのソリューションは正確に一致しないか、追加のサポートや回避策が必要になる可能性があることを意味する場合もあります。これは、私が過去 1、2 年間に取り組んできたプロジェクトに当てはまります。新しいシステムはより正確であり、必要なサポート担当者が少なくて済むという利点があります。はい、優れたソフトウェアは人々を冗長にします。

社内開発は、中核となる会社のソフトウェア、つまりエンティティとして存在できるようにするソフトウェアに対しても行う必要があります。これにより、次にソフトウェアサポート契約またはサブスクリプションが発生したときに、またはそのソリューションによって乾かされることがなくなります。あなたのニーズに完全に適しているわけではありません。

ただし、コア機能を提供しない重要なソフトウェアの 1 回限りのコストは、オラクルにとって莫大な金額であるかどうかにかかわらず、先週までに必要なまともな CMS、CRM、または顧客チケットシステムに対して簡単に正当化できます。

score 0 · Accepted Answer

私が何かを自分でコーディングしたいと思っていて、それを購入する必要があると私の上司が考えたとき、彼は「最高のものを購入し、残りを作成してください」と言いました。

もう 1 つの経験則は、それがビジネスのコアサービスの 1 つである場合は、自分で行うことです。そうでない場合は、アウトソーシングするか、それがコア製品である誰かから購入することを検討してください。とにかく彼らはそれをもっとうまくやるでしょう。

score 0 · Accepted Answer

類推が適していると思います。

あらゆる車を瞬時に 20 mph 速くする最新のレースカーエンジンのアイデアがあるとします。あなたがこれを行うことができたのは、エンジンがより良く機能するようにエンジンを最適化する方法を量子レベルで深く理解しているからです。ただし、フレームやホイールの設計など、他の分野のエンジニアリングスキルは平均的です。これらのスキルを向上させ、ホイール (またはフレーム) を再発明するために時間を費やすつもりですか? いいえ。

代わりに、最高のタイヤを作っている人と、最高のフレームを作っている人とチームを組んで、エンジンを組み合わせます。これにより、サポートインフラストラクチャを提供するのではなく、製品に集中できるため、時間とお金を節約できます。

これはソフトウェアにも当てはまります。必要なツールが非常に複雑な場合は、別の場所から入手してください。製品を作成するためのインフラストラクチャではなく、最終製品の作成に集中したいからです。

projects-and-solutions - プログラムをコーディングしない理由は？

16 に答える 16

Related

Reference