タグ

受託に関するwasaiのブックマーク (7)

  • 「納品のない受託開発」の先にある「エンジニアの働きかたの未来」

    4. http://www.sonicgarden.jp/ AWSとソニックガーデン •  社内ベンチャー創業からのMBO •  Rubyによる富豪的プログラミング •  持たざる経営でリモートワーク •  納品のない受託開発のインフラ AWSのおかげで会社やれてます

    「納品のない受託開発」の先にある「エンジニアの働きかたの未来」
  • 不具合の数が幾つ以上だと、裁判で瑕疵と判断されるのか

    連載目次 前回に続いて、納入したシステムの不具合を瑕疵(かし・欠陥)と裁判所が判ずる材料がどのようなものであるかについて説明する。前回は、仮にシステムに不具合があっても、それをベンダーが早期に補修するか代替案を提示するなど、専門家として果たすべき責任を果たしていることが認められれば瑕疵とは判断されず、ユーザーの損害賠償も認められないという趣旨の判例について説明した。 もちろん裁判所は、不具合にまつわる外的な要因だけを見て、損害賠償の対象となる瑕疵であるかを判断するわけではなく、不具合の内容もよく吟味している。今回は、裁判所が注目するポイントを説明しよう。 契約の目的に照らして判断した事例 まずは、以下の判例を見ていただきたい。 【事件の概要】(東京地裁 平成16年12月22日判決より抜粋して要約) あるユーザー企業がベンダーに販売管理システムの開発を委託したが、納入されたシステムには以下に

    不具合の数が幾つ以上だと、裁判で瑕疵と判断されるのか
  • 泥臭い受託開発Dev love関西

    泥臭い受託開発Dev love関西 - Download as a PDF or view online for free

    泥臭い受託開発Dev love関西
  • [2015年問題5]脱受託へ向かう気鋭のIT企業、成功のための4つの法則

    受託の連鎖から、新たなビジネスに乗り出した企業たち。チャンスをつかんだ取り組みから、成功のための4つの法則が浮かび上がる。 従来のビジネスを捨てることにはリスクがあり、時間やコストもかかる。それでも先が見えない現状から抜け出し、新たな展望を切り開こうとしている。 「たとえプログラマー技術力があっても、今のIT業界ではそれに見合った報酬が得られない。であれば、自らプロダクト開発に乗り出した方が良いと考えた」。大阪と東京に拠点を持つIT企業、クロノスの山大常務取締役は力を込める。 2002年創業のクロノスはIT受託を主力としていたが、2008年のリーマンショックで受託の仕事が急減し、「IT受託への依存は危ない」と社内の危機感が高まった。加えて、人月見積もりに基づくIT受託や技術者派遣に頼っていては、高いスキルを持つ技術者に給与で十分報いることができない。顧客常駐型の仕事が多く、多様な働き方

    [2015年問題5]脱受託へ向かう気鋭のIT企業、成功のための4つの法則
  • 「システム・インテグレーション崩壊」のすすめ - ベテランIT営業が教える「正しいITの使い方、営業の使い方」

    「システム・インテグレーション崩壊」は、時間の問題です。むしろ積極的にSI事業者自らが、この創造的破壊に取り組んでゆくことが、最良の生き残りの選択肢ではないかと考えています。 SIビジネスの課題は、Pay for Time (人月単価の積算で金額が決定するビジネス)であるにも関わらず、成果保証(瑕疵担保責任)を負わされることです。

    「システム・インテグレーション崩壊」のすすめ - ベテランIT営業が教える「正しいITの使い方、営業の使い方」
    wasai
    wasai 2013/07/21
    打開策書いてあるけど、大手SIやユーザ自体がそれをやる気ないからなぁ…
  • 受託開発脳から自社開発脳へ切り替えの7つの壁

    velc: これ、思ったより大変でした。 自分含め、うちにいるメンバー全員、 これまでの経歴では受託開発をメインにやっていたため、 自社サービス開発の経験はかなり少なかったです。 でも、ヴェルクでは、受託開発をしつつ、 時間を作って色々と作っていこう、というスタンスのため、 起業直後から色々と企画を考えていました。 でも、受託開発脳から自社開発脳への切り替えは思った以上に苦労しました。 要件定義等でお客さんと一緒に要件を考えたりしますが、 最終的に「やりたい事」を持っているのはお客さんになります。 要件定義の前の企画やグランドデザインと言った分野は お客さんの戦略に沿ったものになります。 だから、最終的には、誰かが答えを持っている事が殆どです。 そのため、ゼロからそれを考える事があまりないんですよね。 いざ、ゼロから自分たちで企画を考えようと思った時、 いろいろと壁がありました。 1.

    受託開発脳から自社開発脳へ切り替えの7つの壁
  • 受託の話をしよう

    受託は自分のサービスを作るためのつなぎ、とか、いろいろなスタイルを目指すのは別に良いんですけど、こういうことは理解しておくと良いかもしれない。 1.受託とサービスの両立が難しいのは、「当月の稼ぎ」と「明日の稼ぎ」の両立が難しいから。 もし同じオフィスに、デスマ的な顧客案件と、まだ数ヶ月以降に儲かるかわからない案件をやってるグループが共存していたらどうなるか。 顧客案件グループは徹夜で毎月の納期を間に合わせる。 サービスグループは、そこまで追いつめられてないから、割と普通に帰れる。 とした場合に、心の平静を保てるか。 僕はかつてそういう状況のサービス側の立場にいて、目の前で崩れて行くデスマプロジェクトを助けられない立場にいたのが辛かったのです。 会社としても、両方のビジネスに賭けているいるのだから仕方ない部分もあるんでしょうが、現場の立場としては、いやいや全部止めて目の前の問題、解決しようよ

    wasai
    wasai 2012/02/22
    ぴんと来たので後で読む
  • 1