第42回 もっと「余計なこと」を考えよう
IT業界でプロとして活躍するには何が必要か。ダメな“システム屋”にならないためにはどうするべきか。“システム屋”歴30年を自任する筆者が経験者の立場から、ダメな“システム屋”の行動様式を辛口で指摘しつつ、そこからの脱却法を分かりやすく解説する。（毎週月曜日更新、編集：日経情報ストラテジー） 若手“システム屋” 「先輩、ちょっといいですか。住宅販売会社A社のウェブサイト構築の提案案件のことなのですが」 ダメな先輩“システム屋” 「おう、どうした？」 若手 「RFP（提案依頼書）によれば、販売物件を検索できるサイトを構築してほしいということなのですが、ちょっと追加機能を考えてみました」 ダメ 「ほう」 若手 「住宅を買うとなったら、やはり現地現物を見ないと始まらないですよね。だから、住宅購入を検討している顧客に向けて、見学をガイドする機能を持たせたら面白いかと思いまして」 ダメ 「なんか面倒な
第5回 開発コストにムダが多いIT業界，解決策は「分離発注」と「分割発注」
第4回では，システム開発プロジェクトで起こりがちなコスト膨張のからくりについて，主にベンダー側の視点から説明しました。 ではユーザー企業は，ベンダーに任せっきりにして，膨れ上がるコストを眺めているだけでよいのでしょうか？あるいは，「絶対に追加費用は一銭も認めないぞ」とベンダーと強硬に交渉して，予算内で吸収するように持っていけばよいのでしょうか？ 今回は，ユーザー企業がプロジェクトを円滑に進め，なおかつコストを最低限に持っていける方法について解説しましょう。 随意契約では，開発コストが高くなる 第1回にも述べたように，システム開発プロジェクトはほとんどの場合，プラント建設で言うところの“改造プロジェクト”に相当します。 “改造プロジェクト”では，ユーザー企業の内部事情を知っている特定のベンダー（既存システムの開発を担当したベンダー）が，仕様を確認するうえでは非常に有利になります。しかし，内部
kuranukiの日記 - ディフェンシブな開発 〜 SIビジネスの致命的欠陥
Rubyをはじめとするスクリプト言語ではなく、なぜJavaを選ぶのか。 そして、XPをはじめとするアジャイル開発ではなく、なぜウォーターフォールを選ぶのか。 そこには、言語の良し悪しや、開発プロセスの考え方などが理由の中心にあるわけではなくて、SIerというビジネスの仕事の仕方（ビジネスモデル）に起因している。 RubyやXPは、考え方や技術としてはとても良くて、生産性もあがるし、何よりもソフトウェアをクリエイティブに作り上げることができ、利用者にとっても使い勝手がよく、スポンサー（経営者）にとっても経営戦略に沿ったものが手に入り、開発者にとっては何よりも仕事に対してやりがいを感じることができる。すばらしい！・・・・が。。。 しかし、だからといって、誰でもRubyやXPを使って開発をするべきか、というとそうではない。もし、本質を理解しない誰かが、「やってみたいのだが・・・」と相談に来たら、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
一山いくらで人月見積の大手ベンダーを外し始めたユーザー企業のITガバナンス
