「RFP」を含む日記 RSS

はてなキーワード: RFPとは

2017-10-12

この前の学校給食の入札の話と、今回の京都システム入札の話を比較すると、

はてなー対応が極端で草生える

 

給食   → そんな金額で入札した業者が悪い。さっさと打ち切れ

システム → RFPがザルなんだろ。発注者が悪い(または両成敗だ)

 

まだ情報が出てきていない段階で、お前らどんだけシステム業者擁護してんだよ。

これ、業者が悪かったとしても、次は案件採ってきた営業が悪いって言いだすぜ。

京都市が今回失敗したような、自治体システム更新について

http://itpro.nikkeibp.co.jp/atcl/column/14/346926/101101158/

Q1.役所仕事なんて全国でほぼ一緒なのに、なんで自治体ごとに別のシステムを作るの?

A1.地方自治体事務財務について法律で決まっているのは大枠だけだよ。

  それを実務≒内部規定に落とし込むのは各役所ごとなので大枠は似てても実務プロセス全然役所で違うよ。例えば同じ業務でも独自の語彙があったり、下手すると同じ語で市町村ごとに意味が違ったりするよ。


Q2.なんで新規で作らないの?

A2.80年代ぐらいにやったよ。その結果が政令市クラスに残ってて今回京都市更新しようとしてるような、メインフレーム上のシステムだよ。


Q3.メインフレーム汎用機)って何?

A3.みんなが使ってるWindowsとかLinuxとかのOSがなかった時代コンピュータだよ。IBMとかがベンダーごとに作っていてOSベンダー謹製だよ。性能はいいけどメチャ高いよ。

システム内でクローズして専用線以外では他とつながってなかったから、汎用機からPCサーバへの移行を「オープン化」と言うよ。

オープンソースソフトウェアとは全然関係ないよ。


Q3.使いまわしってどうやってやるの?

A3.80年代かに作ったシステムで動いてるCOBOLとかPL/IとかをLinuxとかUnixとかWindows上で動く言語コンバートしてリコンパイルするよ。

DBデータ階層データモデルからリレーショナルDB用にコンバートして移行するよ。こういう開発形態を「マイグレーション」と呼ぶよ。

あと、バッチジョブ制御もJCLという汎用機用の言語で動いているよ。これもそのままでは動かないのでコンバートするよ。

コンバート先はperlだったり、シェルスクリプトだったり、ベンダごとの独自スクリプトだったりするよ。

COBOLとかの実行プログラム移行も大変だけど、帳票の大量印刷はたいていバッチジョブでこなしてるので、JCLの移行もめちゃ厄介で大抵もめるよ。

今回もめたのもバッチらしいね


Q4.80年代のものを使いまわすとか。新規で作ればいいじゃん

A4.お金無限にあればできるよ。今の時代お金があった時代システムフルスクラッチ再開発するととんでもない予算になって市役所内の決裁が通らないよ。

しか汎用機時代の納品は割といいかげんだったのか、仕様書が残ってなかったりするから費用さらにかさむよ。


Q5.そんなんでよく運用できてたな

A5.当時はSE汎用機付属品みたいについてって、困ったらオペレーターとして介入して動かしていたみたいだよ。

そうやって現場感覚バリバリでやっているので、オペレーターしか知らないプロセスがあったりするよ。

マイグレーション開発では総合テスト中にそういう隠しプロセスが「発見」されたりするよ。こわいね


Q6.役所が現行システム資料を出すべきだろうが!

A6.もっともだけど、できないから無理だよ。

上記の通り仕様書がないことも多いうえ、システム課に限らず市役所人員は基本ローテーションするよ。

導入当初の担当者が残っていることは珍しいし、30年も前に導入した汎用機ことなんてここ10年に入った職員にはわからないよ。



Q7.なんで入札にしたの? 現行ベンダ指名してやらせたほうが良くない?

A7.金額がでかいから、たぶんどこの市役所でも入札案件だよ。

随意契約(随契)は無理だし、入札業者発注者指定する指名競争入札談合の温床になってたか最近あんまりやらないよ。


裏技としてRFP指名したいベンダーに書かせて公募指名入札にしたり、RFPの段階でハードを全部特定ベンダで型番まで指定するというのがあるけど、公になると多分問題になるよ。こわいね



Q8.じゃあ役所は悪くないの?

Q8.悪いよ。

入札案件RFPで書かれた各項目をどれだけ満たすかの技術点と、価格点で決まるよ。点が高ければだいたい自動的にそのベンダーに決まるよ。

なので、技術点の項目に現行システム調査にかかる項目を入れるとかして、現行機の開発・保守ベンダ高得点を取れるようにしておけば価格勝負してくるベンダーをはじけた可能性はあるよ。

もちろん現行の会社に嫌われて逃げられたとか、役所が現行の会社めっちゃ嫌いになって声をかけなかったとかもあるかもしれないけれど、可能性は低いと思うよ。



Q9.じゃあベンダーは悪くないのか?

A9.ここまで述べたようにこの手のマイグレーション火薬庫だよ。火を噴いても爆発しなければラッキーぐらいなので、強いて言うなら入札したことが悪いよ。

安すぎる見積もりを出したSEだか営業だかは死んでね。



Q10.お前(増田)は何者?

A10.前にマイグレーションをやったことがあるSEだよ。もうやりたくないよ。今は転職してSIerじゃなくなったからやらなくてよくなったよ。うれしいね

  しょぼいSEからここに書いたことは個人体験に基づく参照情報だよ。一般的じゃないことを言ってたり、間違ってたら教えてもらえると助かるよ。





(2017.10.13 追記)

Q3がかぶっていたよ。恥ずかしくてなきそうだけどブコメに番号で言及してくれている人がいるから忍んでそのままにするよ。


あと、「オープン化」の定義が違くない?という指摘があったよ。確かに増田が間違っていたので、記事の主旨から外れるけど補記するよ。

メインフレームは本文で述べたようにOSからハードまでメーカー謹製なので独自仕様のカタマリだよ。

これに対しPCサーバ標準規格で作られているよ。こういう標準規格に基づくサーバオープン系と呼ぶよ。

独自規格クローズしたコンピュータから、そうでないオープン系に移行するからオープン化なのであって、専用線とかは関係なかったよ。半可通な知識で語ってしまったよ、ごめんね。

京都市で火中にいるシステムズさんのサイト解説がこの増田よりも分かりやすくて正確だから気になる人は見てほしいよ

http://www.migration.jp/column/column01.html

完全に余談だけどオープン系のx86サーバに移行しても、システムはそんなにオープンにならなかったりするよ。

H系に頼むとDBが拝承DBになったり、Fに頼むとシステム管理が全部SystemWalkerになったり、要するにベンダ独自のミドルに入ってがっつりロックインされたりするよ。

オープン化(オープンではない)みたいなことになって面白いよ(面白くない)

2016-11-12

連休前のRFPで、連休開けの提案提出とか。

過重労働問題電通が叩かれているけど、根本的には、クライアント側が業者側に無理な要求をしすぎるのが問題なんだと思う。

IT業界でも、連休前にRFP説明会で、連休が明けてすぐが提案提出だったり。発注する側であることをいいことに、無茶な要求をしすぎ。

過重労働真剣に取り組むなら、こんな不条理おこらないよう、ガイドライン作りに取り組みませんか?厚生労働省東京労働局の皆さん。

2015-05-11

相見積なのも了解してる。

受注確度が低いこともあらかじめ想定済み。

だけど納得いかないのは、提案依頼してきたくせに、提出した提案に対して一切の回答がないということ。

こっちだって忙しい中、ちゃんと時間かけて提案書作ったんだからさ、ダメならダメでも回答くらいしろよ。

それか、RFPに「受注業者の発表は発注書の発送をもって代えさせていただきます」とでも書いとけや。

2015-02-12

http://anond.hatelabo.jp/20150211225021

編プロが口を挟む。

大手さんでよくある形態IT系に例えると

版元=上流プロジェクトマネージャ予算納期とざっくりRFPを書いて編プロ印刷会社お金を回す。終盤で品質チェック(ほぼ主観)することも。

編プロ現場PMSE仕様書と画面遷移図書いて、人集めをして、使用ライセンスとかの管理して、PGの世話をして、デバグして、ビルドデプロイして、プロジェクトを締める。

筆者=PG。書く。

みたいな感じだった。うちのとこは。

あと校閲さんが外注デバッガみたいなもんなんだが、伝統的に版元がお抱えしてたりする。デバッガなんで、企画そのものとかUI画面遷移そのものにはダメ出ししてくんない。それは編プロ仕事かな。あと印刷所&取次iOSアプリで言えばAppleiTS)みたいなプラットフォーマーなイメージ

2014-05-11

SIに入りたい新卒

当方独立系SI文系卒で勤務6年目。

これからSE業界新卒で入ってくる人、転職で入ってくる人へ業界実態スキルについてアドバイス

色々就活生と喋っているが、よく言うことを雑多に記載。

【職歴】

 ・営業社員向けカスタマー管理サービスCRMシステム)構築:1年

 ・中堅企業向け会計パッケージ導入:5年

 ・RFP作成などの上流工程運用保守の下流工程まで経験あり。

【前提】

 ・以下は主にSI企業で上流(要件定義から担当するPM、PLとしてやっていきたい人向けのスキルである

  技術者で食って行きたい人は、全然違うスキル必要なので無視して良い。

必須スキル

 ①コミュニケーション能力

 →何も雑談する力が必要なわけではない。ここでのコミュニケーション能力とは「折衝力、人の輪の中に入っていける力」を指す。

  システムは人が使うものなので、何をするにもまず人と喋って要件を聞き出さないと話にならない。

  技術力があれば良い、と言うのは大きな勘違いで「人に使ってもらえるもの」なので、そこを無視してどんな最新技術を使っても宝の持ち腐れ。

  また、往々にして「システムを導入する=業務をシステムに合わせて変えることが求められる。

  これはパッケージシステム導入に限らず、スクラッチでも同様。その時に「業務を変えたくない」連中が抵抗勢力として現れる。

  そこを説得するものSE仕事。そんな敵の中に飛び込んでいって、説得して、最後には協力してもらうまで信頼を勝ち取らなければならない。

  そんな場でツボを外したことを言おうものなら、相手から無視されて終わる。

  そんなことが起きないための第一歩としてコミュニケーション能力必須

 ②調査能力、つかむ能力

 →この2つはセットで考えたい。近年は技術革新が目覚しいため、全部の技術情報自分で知っているなんて不可能。

  そのためにGoogleなどの検索ツールを活用するが、膨大な情報自分の中でまとめて要点を「つかむ」ことが重要

  細かく知っておくのは専門家領域なので必要ないが、せめて利用しているツールや技術がなんなのかを、

  人に説明できるレベル/類似ツールとの違いを説明できるレベルで知っておく必要あり。

  

 ③1言語以上での構築経験

 →技術力、プログラミング能力必須ではない。上記②の人にやってほしいことを伝えるまでには代用できるからである

  しかプログラマー対峙するときに、相手はプログラミング言語で会話をしてくる(これは誇張ではなく事実

  その時にいちいち②のプロセスで言ってることを調べていては、理解にロスがかかって進まない。

  その時に何か1つでも言語をある程度知っていると、たとえ知らない言語での開発でも言ってることがわかるようになる。

  この感覚は例えが悪いが、ピアノを習っておけば、数年後に違う楽器を触っても上達が格段に早いとか、

  ドラクエをやっておけば新桃太郎伝説攻略スムーズにいく、とかの感覚に似ている。

  土台は同じで表現が違う、ということになるからである

以上が必要必須スキルである

新卒プログラミングやったことがなくても、①・②は社会で鍛えられるし、③は研修OJTという形で経験が積めるから問題ない。

新卒プログラミングやったことある人は、③が経験済みなので、その分有利である

転職場合往々にして即戦力として求められるので、③の経験がないのが大きなネックになる。

巷で言われる業界経験OKとは、③のスキルがない人のことを指すため、

①・②が人より優れてないと厳しい、ということになる。

参考にされたし。

2013-10-09

いずれにせよ貴方はシステム屋にボッタクられる

http://anond.hatelabo.jp/20131005064230

システム屋に不当にボッタクられないための発注者心構え」の増田です。

システム発注業務を舐めきった増田に「ばーかばーか!お前のかーちゃんでーべーそー!」って煽り記事を書きましが、下の記事に、理性的かつ丁寧に諭されてしまいました。憑き物が落ちた気持ちです。

システム屋に不当にボッタクられたくない人のための要求講座 - novtan別館

http://d.hatena.ne.jp/NOV1975/20131008/p1

浅かった自分を恥じて素直に反省し、心を入れ替えて、更に丁寧に煽ろうと思います

聞いて下さい、私の歌を。

●「良い子、悪い子、普通の子」という幻想

良心的な企業なんてのは、存在しません。

利益なんて1銭も要らない。人の笑顔が見られればそれで良い」。そんな奇特偽善者は、営利企業じゃなくて慈善活動団体に身を投じてるはずですから

悪徳企業あなた会社から短期間で多大な金額をボッタクり、良心的との謳い文句の企業は同額を長期間にわたってボッタクろうとする。それだけの違いです。

営利企業が、より多くの利益追求活動に精を出さなければ、株主従業員にとって不誠実です。そうでしょう?

で、利益追求活動ってのは、同じコストが掛かったモノを、上手いことできるだけ高値で売るってことです。

利益そのままで売上額上げればいいじゃん、とか考えるの是非止めて下さいねシステムエンジニアはもう3日も家に帰ってないのです。

●5社に相見積もりを求めた貴方は、内4社に完全なタダ働きを強いるのです

相見積もりをとるってことは、確信的な空振りタダ働きを求めてるって話で。

それが発注側の正当な権利であれば、ボッタクるのは受注側の正当な権利なのでしょう。

だって空振りした相見積コストは、どっかで回収しないといけませんもの。営業人員が1回訪問してペラ2~3枚の見積もり書を1回出すのに3万円のコストが掛かるとして。利益率1%の会社だとしたら、売上ベースで300万円の仕事をこなさないと出せない大金ですよ?

IT 業界会社が5社こっきりだとしたら、1回の受注で回収しなきゃいけない営業コストは(見積もり関連だけで)15万円ってことです。まあ貴方の会社にそっくりそのまま転嫁するのでいいんですけどね。

●役に立たないコンサルタント回避するためのコンサルティング

素人で何もわからいから、導いてくれる専門コンサルに頼る? 馬鹿なの、死ぬの? よいコンサルってのは、よいシステム屋よりも稀有な存在ですよ? 見つけるには相当な努力と、幸運必要です。

膨大なインタビュー時間を拘束されて、誰も読まない資料ぎっしりキングスファイルを文書棚の下の方にしまい込むのがお好きなら、止めは致しません。

コンサルのひとは、しょっぱい過去実績を綺麗に彩る能力にも優れてらっしゃいますので、心に留めておいてください。いっしょに踊ると楽しいですよ、途中までは。12時の鐘が鳴ってパーティーが終わった後に、コンサルの人は残ってませんけど。

もし、もしも、貴方の元まで王子様を無理やり引っ張ってきてガラスの靴を強引にはめこむコンサル出会えたら、その手を握って絶対に離さないように。強くお勧めします。

発注業務で舐めプ死ぬ気ですか? ホント発注業務は地獄だぜ! フゥハハハーハァー

貴方が信じられる人は、誰もいません。

BtoB会社間取引ですから、狐と狸の化かし合いです。ちょとでもスキを見せると、誰も彼も容赦なくたかってくるでしょう。目利きの弱さで騙されるほうが悪いんですよ。美味しいですもんカモネギ鍋。

で、クソみたいなシステム屋にクズシステム掴まされて、その責任を取るのは貴方です。

運用現場から使えない効率悪いって猛烈なクレームを日々受け続けるのも、上司からこんなに沢山会社の金をドブに捨てたんだねって笑顔で人事評価を下げられるのも。

RFP」というキーワードでググって勉強しましょう。

過去に似たようなシステム発注を行った社内人員や同業他社や関連企業に拝み倒して、システム発注のコツや信頼できるシステム屋の情報教えて貰いましょう。できれば発注額も。

システムに関わる予定の社内・社外関係各所の人員にしつこいぐらい話を聞いて、要件漏れがなるべく無いようにしましょう。

経営陣にはシステム化の意義と得られる業務改善効果を丁寧に説明し、ひっくり返されない確かな予算枠を確保しましょう。

繰り返しますが、世知辛い世の中なのです。知識が無いのが罪だとは言いませんが、生け贄台に捧げられる羊です。どれほど言い訳を重ねても、結局は自分を高めないと、誰かに食い物にされるだけなのです。

学んで得た知識や経験は、貴方にとって後々まで幅広く役に経つことでしょう。

●同情と泣き落としは最後にして最強の手段

最後最後は、ウエットなアレですよね。

「私は会社のしもべ・卑しい哀れな犬っころです。このシステムが完成して役に立たないと、会社を首になって、年老いた母親小学生の娘と産まれたての子猫が! 私の見込み違いで、今回は御社に足が出る形になってしまますが、改めて追加予算取って次の発注で回復できるように致しますので、どうか、なにとぞ!」

懐に出刃包丁を忍ばせつつ、ギラギラした目で土下座。最強のビジネスメソッドですよ。

●(おまけ) 良いシステムが作りたいのかい? じゃあ僕と契約して、魔法少女になってよ!

僕達SIerというのは、「何やればいいかよくわかんないんだけどシステム会社を良くしたい」って思っている人をお助けすることも大事仕事です。もっとも、そこまでのレベル会社個人商店の延長に近い中小企業くらいしかもはや残っておりません(システム化の余地が少なく、せいぜい会計給与メールシステムくらいしかない会社)し、あったとしてもお奉行様あたりのターゲットでしょう。

http://d.hatena.ne.jp/NOV1975/20131008/p1

お国が出す RFP絶望することしばしばです。私だけでしょうか?

「何やればいいかよくわからないんだけど国を良くする提案を求める」とか、1行に凝縮できることが、冗長な文で長々と書いてあったり。なんだそれ。

かい意図を直接聞いても、「高度な柔軟性を維持しつつ、臨機応変に対処できるようにしたい」とか大変ふんわりとした回答。

一流大学出て難しい試験合格したデキるお役人さんしっかり仕事しろと思いますが、内情を聞くと決定権を握ってるのが誰なのかわからん状態だったりして、まあそりゃしようがない。

要はその都度行き当たりばったりと言うことですな。そりゃ何割ものシステム調達プロジェクトが失敗するわけだ。

http://itpro.nikkeibp.co.jp/article/COLUMN/20121204/441882/

ネタ元:

http://d.hatena.ne.jp/NOV1975/20131008/p1

2013-05-21

帰宅してまず増田

連休明けから仕事がひどい。それでもこの時間に帰って来られるだけ人並だ。

サーバ構築、クライアント構築、スイッチ設定、ストレージ設定、うんぬんかんぬん。作業だけでも終わらないのに、営業から見積だのRFPだのが飛んできて、巻き込まれる。

とりわけ見積もりの意味がわからない。来季予算取り、なのに、有効期限1ヶ月の見積もりを出して何が得られるのだろう。「ざっくりで」というけれど、出したら一人歩きして、詳細条件でそろって見積もった時と違うとまた怒るでしょうに。だから出したくないんだよ。なんだ「ざっくり、ナルハヤで」とか。意味わかんないよ。そのざっくりの見積もりでもこっちは決済取らなきゃ出せないんだし、知ってるだろ社内の仕組み。ほんと営業はアホか。謝りに行ってもらったり助けてくださってありがとうございますSE部門は奴隷でございます。ああ、もう、これがなくなるだけでどれほど心安らかになることか! 来季なら型番変わってるだろjk。その見積意味あるのか本当に。

今日仕事でした。リクナビネクスト見て寝る。

2011-10-11

無線LAN導入に向けて

おいおい、どうして「プロの提案」を待つ前に「技術要件」をこちらから出すRFPを作らんといかんの?

プロはいえ、現プロに対して失礼じゃない?しかも生半可な知識で。

こちらから出すのは機能要件だけで良いと思うけど。

それを実現する技術をひねり出すのがプロの営業の腕の見せ所だと思うよ。

分かったからお前は口を塞いでろ。無益どころか有害から

2010-08-26

http://anond.hatelabo.jp/20100826162127

RFPに性能要求を入れなかったタコな発注元

クズコードを書いた下請けのクズ

コードレビューもしない下請けの上司

受け入れテストなんて知らないタコな発注元

連携ってこれ?

2010-06-10

http://anond.hatelabo.jp/20100610004157

一端RFPとかで決められている事なんか、ざっくりと忘れて話をします。


セグメント「192.168.1.xxx」のネットと、セグメント「192.168.2.xxx」のネット存在するとします。

マスク「255.255.255.0 (24)」で判定すると、上の二つは、異なるセグメントと判定され、どちらのネットに属しているか判別可能です。

マスク「255.255.0.0 (16)」で判定すると、上の二つは、同じセグメントと判定され、同一のネットに属していると判別されてしまいます。

「192.168.xxx.xxx/16」という括りの上位ネット存在し、その中でさらに「192.168.1.xxx/24」が分割管理されている場合

同一のIPに異なるマスクと言うのは意味があるのかもしれませんが、私が知る狭い範囲では見たことがありません。


本来は以下のように、セグメントの切り方は決まっていますが、そういうことはさっくりと忘れて書いています。

クラスA(マスク:255.0.0.0)

クラスB(マスク:255.240.0.0)

クラスC(マスク:255.255.0.0)

ちなみに、各クラスアドレス範囲も被らないように設定されています。

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん