第5回 開発コストにムダが多いIT業界，解決策は「分離発注」と「分割発注」
第4回では，システム開発プロジェクトで起こりがちなコスト膨張のからくりについて，主にベンダー側の視点から説明しました。 ではユーザー企業は，ベンダーに任せっきりにして，膨れ上がるコストを眺めているだけでよいのでしょうか？あるいは，「絶対に追加費用は一銭も認めないぞ」とベンダーと強硬に交渉して，予算内で吸収するように持っていけばよいのでしょうか？ 今回は，ユーザー企業がプロジェクトを円滑に進め，なおかつコストを最低限に持っていける方法について解説しましょう。 随意契約では，開発コストが高くなる 第1回にも述べたように，システム開発プロジェクトはほとんどの場合，プラント建設で言うところの“改造プロジェクト”に相当します。 “改造プロジェクト”では，ユーザー企業の内部事情を知っている特定のベンダー（既存システムの開発を担当したベンダー）が，仕様を確認するうえでは非常に有利になります。しかし，内部
IT調達に市場化テストを - 雑種路線でいこう
予告.inで考えさせられたこと。電子政府の作り方って他にもやり方があるんじゃねーの、っつーか、足の早い分野じゃ発注しなきゃ仕事はじめないような奴らに作らせている時点で負けだってこと。今回、予告.inに呼応して予告.outが出てくるまで数日だよ。古い仕様書通りに作ったら負けな分野だし、国が予算つけなきゃ関心を持たないような奴にやらせちゃ、その時点で終わってるだろ。 業務系とか、いわれた通りに作らなきゃならない分野もある。けれどセキュリティとか検索とか、moving targetを追っかけるネタで、これまでの年度単位での受発注という時間軸で仕事させちゃいけない。機敏に目標を再設定できる民間でやらないと難しい。今回はid:satoru_netが勝手につくった訳だけど、じゃあ役所は何をすればいいんだろう。たぶん、 政策需要を明確にする かかる分野の技術開発を促す 公共性の高い活動の継続を支援する
いまさらきけない「ドメインモデル」と「トランザクションスクリプト」 - ひがやすを技術ブログ
このネタは、私自身も何度も書いてきたけど、結局意味のある結論になったためしがありませんが、再度考え直してみたいと思います。 「ドメインモデル」と「トランザクションスクリプト」をすごく簡単に説明すると、トランザクションスクリプトとは「アクションより起動される一連の手続き」、ドメインモデルとは「ドメイン内の名詞によって体系化されたモデル」です。 トランザクションスクリプト派は、「トランザクションスクリプトの方が書くのが簡単だし、業務アプリケーションにオブジェクト指向は、ほとんど必要ない」といいます。 それに対し、ドメインモデル派は、「ドメインモデルはオブジェクト指向を生かすことができるのでメンテナンス性が良い」と主張します。 ずっと平行線のままですね。 私は一番最初に「ユースケースと一対一にサービスクラスを設け、ビジネスロジックはサービスクラスに記述する」という主張をしてました。 記念すべき(
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
