ベンダーロックイン排除のためにオープンという議論 - Nothing ventured, nothing gained.
自治体などの入札においてベンダーロックインを避けるため、特定のベンダーや技術に縛られないようにする。最近、このような方針を掲げる自治体や団体も出始めている。 これ自体は良い方針だが、ここで考えなければならないのが、何をもってオープンとするかである。 Web系であれば、利用者の多いLinuxのディストリビューションにApacheとMySQL、それにPHPやJavaのフレームワークを使うということになるのだろうか。ここのApacheはnginxでも良いし、MySQLはPostgreSQLでも良い。フレームワークもあくまでも例なので正直オープンであればなんでも構わない。 だが、この「なんでも構わない」の部分を明確にしておかないと、実際に調達を行う場合、入札仕様書（RFP: Request For Proposal）が書けないので、どっかでオープンの定義を明確にしないといけない。 その定義の難しさ
第2回 RFP作成には標準的な手順がある
「始めよければ終わりよし」と言いますが，「最初の仕様があいまいなままプロジェクトを開始した」とか「簡単だと思って始めて深みにはまった」という失敗事例を，システム開発ではよく聞きます。これは，“プロジェクト開始の作法”が確立していないからではないでしょうか。 プラント建設のプロジェクトでは，“元請け”である「コントラクター（契約請負業者）」にとっての「プロジェクトの開始」は，オーナー（発注者）から「見積もり引合い書」が来た時です。この見積もり引合い書のことを，「RFP（Request for Proposal)」と呼びます（「RFQ（Request for Quotation）」や「ITB（Invitation to Bidders）」と呼ぶこともあります）。RFPの作成は，プラント建設では常識中の常識です。 RFPを作成する企業は，競争見積もりには参加しない プラント建設プロジェクトのRF
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
