タグ

関連タグで絞り込む (1)

タグの絞り込みを解除

システム開発に関するtohokuaikiのブックマーク (6)

  • 「残された時間はあと6年」夏野剛氏が語る、世界と戦うためのBtoBイノベーション - エンジニアtype | 転職type

    2014.05.22 ITニュース スマートデバイスやクラウド技術の急速な発展によって、次々と新たなテクノロジービジネスが生まれている。BtoC市場では、コミュニケーションツール『LINE』やアイコン着せ替えアプリ『CocoPPa』などの国産サービスが海外進出に成功しているが、BtoB市場はどうだろう。 国内市場こそ、2016年に始まるマイナンバー制度やメガバンク各社のシステム更新需要、民間企業のデータ経営へのシフトなどに後押しされ、リーマン・ショック以降停滞していたIT投資が回復基調にあるが、国際市場で日のシステムベンダーの存在感を感じる機会はほとんどない。 ではなぜ、SalesforceAWSのような世界的なBtoBサービスは欧米で生まれ、日からは生まれないのか。 先ごろ出版大手KADOKAWAとの経営統合を発表したドワンゴをはじめ、数々の有名企業で取締役を担う夏野剛氏に、エンタ

    「残された時間はあと6年」夏野剛氏が語る、世界と戦うためのBtoBイノベーション - エンジニアtype | 転職type
  • PR:システム開発をめぐる法的トラブルの事例

    システム開発の現場でプロジェクトマネージャやSEとして経験を積んだ弁護士が、システム開発における法的トラブルの事例を紹介します。紛争解決だけでなく、紛争を事前に回避するためにも、システム開発委託契約書などの契約書を作成したり、交わす際には、事前に専門家に相談することが大切です。法律相談、案件依頼、費用見積依頼は、記事下フォームよりお気軽にお問い合わせください。 2008年3月、スルガ銀行が日IBMに対し、勘定系システムの開発が完成しなかったことなどにより、約111億円の損害賠償請求訴訟が提起され、現在(2009年12月現在)も係争中です。この事件のように、社会的に注目を浴びるような事件だけでなく、システム開発の分野では、以下のような多くの紛争が生じています。 SIベンダXは、ユーザー企業Yに、システム開発を提案した。XYの担当者ベースでは、YがXに開発を委託することがほぼ合意されたが、契

    tohokuaiki
    tohokuaiki 2010/01/22
    ケース1は致し方なしなところもあるなー。担当者の口約束でも約束は約束だし、営業努力と言われればそれまで。
  • 「開発コスト数分の1」という幻想

    システム開発のコストを減らす手法としてオフショア開発を視野に入れる企業が出てきた。だが外部委託によるコスト減という名目だけでは成果に結実しない。稿では、Webサービスを立ち上げた経験を基に、オフショア開発において直面する課題やコスト構造の現実をお伝えする。 わたしが代表取締役を務めるピーポーズはWebサービスの開発をインドに委託している。最初の頃、それを人に話すと「オフショア開発をやっているのですか?」という反応が返ってきて、こちらが面らった。自分たちにはオフショア開発という意識はなく、単に開発を委託している会社がインドにあるという認識だった。いずれにしても、委託側の文化や言語の関係など、オフショア開発には乗り越えなければならない壁があると感じている方も多いはずだ。そこで稿では、小規模な企業がインドの企業にシステム開発を委託する際に生じる課題を、自らの経験を振り返りながら考察する。

    「開発コスト数分の1」という幻想
    tohokuaiki
    tohokuaiki 2009/08/20
    大企業目線
  • @IT編集部のblog : Git!? そんなの学生しか使わんよ

    2009年06月09日21:53 カテゴリ 西村 こぼれ話 Git!? そんなの学生しか使わんよ こんにちは、@ITの西村です。JavaOneの展示会場に出展していた「Perforce」(パフォース)が目にとまりました。プロプライエタリなソースコード管理ツールです。名前は聞いたことがありましたが、実はどんなものかよく分かっていません。Perfoceのサイトによれば、世界中の4700組織で28万人の開発者が使っているデファクトスタンダードということです。ソフトウェア開発者だけでなく、AMDやNVIDIAといったチップメーカーも入っているようです。バイナリの管理もできからという話です。最近はGitやMercurial、あるいはSubversionが話題ですが、プロプライエタリのPerforceのほうがパフォーマンスや機能、スケーラビリティでは優れているのかもしれません。私は思わずブースに近づき

  • 「元請けにこだわる理由」の「いいがかり」についてひとこといっておくか - ひがやすを技術ブログ

    自社のバックオフィスの方が、外注先に対してどんな立ち居振る舞いをしているのかご存じですか? 自社と外注先との間の契約がどのようになっているのかご存じですか? それを目の当たりにしても同じことを言い続けられる自信はありますか? そういうことはスーツ仕事とレッテルを貼って見て見ぬ振りをしてませんか? それでいて業界を変えたいなどといいますか? 業界を変えたいっていってるところから、おいらのことを言ってるとして話を進めるよ。 バックオフィス(この文脈では調達のことかな)の方が、外注先に対してどんな立ち居振る舞いをしているのかは、正直良くわかりません。転職したことがないので、他の会社のことは良くわからないけど、弊社の場合は、調達と外注先が価格や条件の交渉する場に、案件側の人間は立ち入ることはないためです。必要だといわれたらもちろん同席するけどね。 新規取引をさせていただくときの最初の顔合わせに同

    「元請けにこだわる理由」の「いいがかり」についてひとこといっておくか - ひがやすを技術ブログ
    tohokuaiki
    tohokuaiki 2008/10/20
    噛み合ってないな~。結果がリリースとかDL数とかは、元記事が求めてるのとはなんか違うと思う
  • ユメのチカラ: 開発工程を別々に担当してはいけない

    古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。 特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。 よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。 ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。 一度固定した文書は次のフェーズで変更

  • 1