アジャイルと受託開発
先日、永和システムマネジメント社がアジャイルによる受託開発サービスを発表し、話題になっている。多くの人の関心を引いているのは、アジャイル開発手法を取り入れるということだけでなく、その価格の安さだ。一ヶ月あたりの料金は、もっとも安いものでは月々15万円から、もっとも高額なプランでも月々150万円からとなっている。果たしてそんなので儲かるの！？というのが多くの人がいだいている疑問であろう。自分なりに「アジャイルによる受託開発サービス」について分析してみたので語ってみようと思う。なお、本エントリは永和システムマネジメント社が公開されている資料と筆者の推測に基づくものであるので、より詳細で正確な内容は永和システムマネジメント社さんへ問い合せて頂くよう悪しからず了承いただきたい。 採算割れしないのか？筆者の見解では、たぶんしない。何故か？それは一旦開発が終わったらそうそう頻繁にシステムの仕様を変更し
SIerという奇形児と、SIという珠玉の仕事 - GoTheDistance
先日のエントリーがアツいことになっており、初のホッテントリ入りに若干興奮している今日この頃です。同じような問題意識を持っておられる方が多くいらっしゃることがわかり、改めて書いてよかったなぁと思っています。 話の流れは相当グダグダなのですがあのエントリーで表現したかったことは、「アメリカにSIerが存在しないのである」⇒「アメリカは素晴らしいのである」というのが骨子ではなく、いわゆるディフェンシブなシステム開発を強いられているSIerというのは、いわば奇形児のような存在ではないかということです。 改めて、ディフェンシブとは 言わずと知れた名エントリから。 ディフェンシブな開発とは、開発途上のリスクを計画上の時点でなるべく潰し、開発側に発生する利益分を減らさないような開発の進め方をすることを言っている。加えて、この場合、開発側はリスク分はなるべく多めに見積もり金額にいれようとしがちだ。 なぜそ
アメリカにはSIerなんて存在しない - GoTheDistance
知人のmark-wadaさんのBlogからTB。 親子丼的ビジネス奮闘記(4) IT業界構造 SIerなんてものは無い 米国と日本との大きな違いは、米国の企業は基本的に内製なのだ。すなわち、社内のＩＴ部門に開発エンジニアを抱え、そこでシステムの開発から運用を行なう。 ですから、米国のベンダーはそこに製品を供給する役割であり、日本でいうSIerというのはほとんどなく、あっても企業でリソースが不足したらそれを補う役割でしかない。契約にしてもはっきりしますよね。提供されるプロダクトやサービスに対する対価を払えばよいわけで、かかった人月で支払ういう出来高払いのような形態は少ない。日本のようにベンダーやSIerに丸投げして、できてからこんなはずではなかったなんて事態にははじめからならない構造なのだ。 親子丼的ビジネス奮闘記(4) IT業界構造 言われてみれば・・・、っていう感じですが改めて目が鱗です
小野和俊のブログ:人月ビジネス、プロダクト、ウェブのサービス
IT 系の会社の経営者の方と話をしていると、 人月ビジネスをやめて、パッケージやサービスに移行したいという話をよく耳にします。 しかし、半年か一年経ってその後どのようになったのかを聞いてみると、 パッケージやサービスの開発プロジェクトが立ち上がるところまでは行ったものの、 結局は中途半端なものにしかならず断念したという話が多く、 事業内容をスムーズに移行することができたという話はあまり聞きません。 このようなビジネスの転換がうまく行かないケースには、 いくつかの共通点があるように思えます。 第一の関門は、経営陣が、まったく異なるビジネスに対して、 考え方を切り替えられるかどうかという点にあります。 パッケージやサービスのビジネスというのは、基本的に先行投資のビジネスです。 まずソフトウェアを完成させるまでに時間がかかり、 次にソフトウェアが世の中で認知されるまでに時間がかかり、 認知されて
要件定義カード1枚8万円──脱・人月商売宣言 － ＠IT
「1タスク8万円」という価格体系を提示し、人月商売からの脱却を宣言するスターロジック代表取締役兼CEO 羽生章洋氏 「二度と人月商売はしません」──スターロジックは7月19日、都内で開催した自社イベント「StarLogic Conference2007」において、エンドユーザー自身による要件定義に基づき、「要件定義のカード1枚当たり8万円（税別）」という価格体系でシステム構築ビジネスを進めていくと発表した。従来の「人月」に基づく見積もりと比べて、1/3から1/5の価格になるという。 「人月換算でコストを請求する商習慣こそが、SI業界のさまざまな問題の根源。人月から脱却するには、納得でき、分かりやすい価格体系を提示することだ」（スターロジック代表取締役兼CEO 羽生章洋氏）。 低コストにできる理由は、ユーザー自ら要件定義を行い仕様を最初に明確にする点と、実装段階で自動生成により生産性を追求し
1,000万円のサイト構築費を50万円に抑える方法 | Web担当者Forum
ページ受託からビジネス協業への変革 ウェブサイトの構築や運営にかかる費用や制作会社との上手なつきあい方は、常に企業のウェブ担当者の悩みの種だ。ここでは、その直接的なコストを減らし、さらに制作会社が今までよりも積極的にあなたのサイトにコミットしてくれるようにする「レベニューシェア」について解説する。 TEXT：編集部 協力：株式会社コスモ・インタラクティブ ページ単価は昔の基準？まず、企業とウェブサイト制作会社や関係について状況を整理しておこう。 十数年前から、企業はウェブサイト制作会社に「受託」という形でウェブサイトの構築や更新を依頼してきた。コーポレートサイトを数百万円かけて作り、サイトができたら制作会社は企業から渡された内容を元に何ページかのHTMLを作ってアップロードする運用作業を毎月数十万円で請け負うといったスタイルだ。つまり「ページをデザインして作り、納品する」ことが制作会社の仕
駆け出しプログラマーのグループ - hamastaの日記 ___Pythonで学ぶプログラミングの世界___ - デブサミ2007 IT戦記＆はぶにっきの中の人の講演を見たよ
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
業務システムを無償開発し有償ASP方式で提供、いづもが新サービス
アイ・ティ・フロンティアとcgios technologiesの合弁会社いづもは7月21日、カスタム開発の業務システムをASP方式で提供するサービスを発表した。いずもが顧客企業の要求に合わせて業務システムを無償で開発し、それを有償のASPサービスとして顧客に提供する。サービス提供後の仕様変更にも応じる。顧客は、アウトソーシング・サービスのように長期間利用し続ける義務はなく、サービスが不要になればいつでも解約できる。 このASPサービスは、特定の業務パッケージ・ソフトを利用しているわけではないため、あらゆるタイプの業務システムに対応できる。サービスの課金は、開発した業務システムのデータベース・テーブル数、画面数、画面遷移の複雑さなどをベースに設定する。 サービス提供後にシステムの仕様を変更しても、これらの条件に変化がなければサービス料金は据え置かれる。仕様変更に伴うプログラム改変作業は無償で
国産検索エンジンはなぜ必要なのか？--経産省担当者に聞く - CNET Japan
経済産業省は7月、国内の総合電機メーカーや大学など38団体とともに、国産の検索エンジンを開発する「情報大航海プロジェクト・コンソーシアム」を設立する。企業や大学がこれまで研究してきた検索技術やノウハウを持ち寄り、成果物はオープンソースとして広く公開する考えだ。 検索エンジンの分野では現在、Google、Yahoo!、Microsoftといった米国の大手企業が火花を散らしている。この分野で国が音頭を取って研究開発を進める狙いは何なのか。経済産業省 商務情報政策局 情報政策ユニット 情報経済企画調査官で、今回のプロジェクトを推進した立役者である八尋俊英氏に聞いた。 --情報大航海プロジェクト・コンソーシアムを結成した狙いはどこにあるのでしょう。 まず前提として、現在は情報がとにかく山のように沢山あり、その中から必要なものだけをうまく抽出して知識化する技術が求められているということがあります。こ
複雑さに金が落ちる時代は本当に終わるのか？ - アンカテ
RailsやChuraのいけてないところ これは、Ruby on Railsに対する実に的確な批判だと思う。だが、これによって逆にRailsの意味が見えてきたような気がする。 (このエントリ、入口はソフトのやや専門的な話ですが、例によって大風呂敷で、そこから"The World is Flat"の話につながっていくので、できればプログラマ以外の方もおつきあい下さい) Railsというソフト開発ツールの良さは、単に便利とかフルスタック(必要な全ての機能盛合せ)ということではなく、実践的な仕事の流れが背後に想定されていることだ。頭をひねってツールを使いこなすというより、ツール(が想定しているソフト開発手順)に「乗る」という感覚で開発を進めることができる(まさに On Rails)。 だから、Railsの個々の機能の過不足を問題にするのはあまり意味が無い。仮に不足があったとしても、オープンソース
My RSS 管理人 ブログ: 新サービスのネーミングを考えるときに行うべきこと
先日 RSS リーダーの UserAgent の話しを書いていたら追加情報のトラックバックをいただきました。 kokepiの日記 - WEB型RSSリーダのユーザーエージェントと、モバイルのRSSリーダ。 これからは、「情報を集める一番良い方法は情報を発信することだ」と思いますので素晴らしいです。ありがとうございます。 さて、その User Agent の中にまぎれているもので気になるものがあります。 ActiveReader/1.0 (http://underdev/; * subscribers) 実はこれ、フレッシュリーダーを開発しているときのコードネームなのですが、本当はこのまま「Active Reader」という名前でリリースする予定でした（既にドメインなども取得済み）。 ですが、残念ながら（恥ずかしながら）商標でひっかかり断念した、という経緯があります。 さて、これからは個人で
koyachiの日記 - Joshua Schachter(del.icio.us)による大規模アプリケーション構築の注意点
del.icio.us/tag/del.icio.usを眺めていたらFlickrのときみたいに面白い資料を見つけたの紹介します。 Things to look out for when building a large application.というタイトルでサーバーサイドの管理等の話が中心かと思って読んでいたらそれ以外のインターフェース、実装すべき機能、spam対策、アプリケーションを如何に広めるかといった話にも触れていて面白いです。 以下にまとめてみました。 スケーリング 早期の最適化を避ける。SQLでスケーリングするのではなく、データを複数マシンに分散させる方法を考慮すべき。SQLプロファイリング重要。Nagiosがお勧め。 タグはSQLと相性がよくない。インデックシングの仕組みを理解し、その方針を決定する。最初の数ページに限定すれば小規模で高速なインデックスを保てる。 Apache
kuranukiの日記 - ディフェンシブな開発 〜 SIビジネスの致命的欠陥
Rubyをはじめとするスクリプト言語ではなく、なぜJavaを選ぶのか。 そして、XPをはじめとするアジャイル開発ではなく、なぜウォーターフォールを選ぶのか。 そこには、言語の良し悪しや、開発プロセスの考え方などが理由の中心にあるわけではなくて、SIerというビジネスの仕事の仕方（ビジネスモデル）に起因している。 RubyやXPは、考え方や技術としてはとても良くて、生産性もあがるし、何よりもソフトウェアをクリエイティブに作り上げることができ、利用者にとっても使い勝手がよく、スポンサー（経営者）にとっても経営戦略に沿ったものが手に入り、開発者にとっては何よりも仕事に対してやりがいを感じることができる。すばらしい！・・・・が。。。 しかし、だからといって、誰でもRubyやXPを使って開発をするべきか、というとそうではない。もし、本質を理解しない誰かが、「やってみたいのだが・・・」と相談に来たら、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Lancers
IDEA * IDEA
夏のはぶにっき - 脱、人月商売のこと
http://www.dino.co.jp/business/solution/inspection.php
ロングテール時代のSI
http://www.machu.jp/posts/20060201/p01/