「RFP」を含む日記 RSS

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

2019-10-24

恋する以前に普通の女がいないという悩み

話題になっていたnoteを読んで思うところがあったので書いてみました。

https://note.mu/minami_it/n/n1653ea6ed29e

■男が求める普通の女とは

恋愛至上主義じゃない

たまに会う女友達恋愛の話ばっかりしてると、またその話してんのかよって思う。ちゃん仕事してるか不安になる。

男性モテたいのであれば、恋愛だけじゃなく、恋愛以外に楽しめる事見つけた方が良い。


潔癖症でない

服で手を拭くとか結構あるし、朝シャンで済ます時とかあるのだけど、シャワー浴びずに布団入るなって真剣な顔で言われ布団から蹴り出された事、僕はあるよ。自分正義があると思ってるのか、めちゃ強気に言ってくるのなんなん。

いや、実際正しいと僕も思う。手はハンカチで拭くべきだし、お布団入る前にお風呂入るべきだけど、そうできない時もあるじゃん。そういう時もガンガン責め立ててくる女性は、ちょっと病的。人の気持ちを考えられない女性なんだなと思う。


・人の陰口を言わない

この前こんなクソな男がいてさ…みたいな話をしない。男女の話でなく、親の教育の話なんだろうけどさ、陰口は良くないって教えられてこなかったのか。キモい男のLINEスクショを撮って、自慢げに見せびらかすのはやめたほうが良い。というか男性がかわいそう。


自分の分は、自分お金出す

男女平等社会になってきたとは思うが、意外とまだいるのが、外食デート代は男が払うべきと考えている人。

自分ご飯なんだから自分の分は払いなよ。


専業主婦願望がない

依存されるのは精神的にプレッシャーになるし、俺の給料安いんだから、稼いでくれ。


・話し合いができる

自分の思い通りにならなかった時に感情論になってしまう人が多すぎじゃないか

感情論になってしまうと話ができない。客観的数字事柄でなく「私はこう思った」という主観が大きすぎる。喧嘩などが起こるときは、意識認識のズレが原因である事が多いのだけど、そのズレを埋めようともせず(埋めるためには客観的視点必要だが)、自分気持ちだけを押し付けてくる。

まずは、相手がどういう事を考えていたか、どういう意図で行動していたかをお互いに知ることから始めよう。


金銭感覚が合う

20-30円安いものを買うために、スーパーハシゴとかするの意味わからん

自分だけでやるならいいけど、僕に買い物頼む時にも適用すんのやめて。別にちょっと高いタマゴ買ってしまっても許してよ。


自分気持ちを伝える事ができる

靴が合わなくて足が痛い時は休みたいと自分から言うべき。男性が推測して提案すべきと考えている人は、受け身体質すぎる。

きっと普段仕事でも、ろくなRFPも書かずに下請け企業提案させているのだろう。


自分計画を立てることができる

自分計画もせず、人任せにしたデートの内容をボロクソに言う女性がいるらしく、びっくりしている。

自分なら毎回完璧デートをこなすことかできると思っているのだろうか?

友達遊んだり、仕事趣味もある中、どれだけデート計画を緻密に立てられるだろうか?

男性に任せきりにせず、2人で計画を立てるのが1番良いと思う。もしくは計画を立てるのが上手い人がやるのが良いと思う。

尊敬できるところがある

それは自慢することではない。見る人が見れば、その人のいいところはちゃんと映っている。むしろ普通にしていて、自分のことをバカにする人とは付き合わなければいいだけだ。むしろ自分はこんなにできるんだぜ、こんなに頑張ったんだぜ」って人の方が端から見てイタイ。何も言わず努力を見せていたらかっこよかったのに、それを自慢しだすなんて。むしろ黙っている方が見ている人がちゃんと褒めてくれるので信じて待っていてほしい。

コンプレックスが強くない

昔の彼女に、どういう芸能人が好きか聞かれて答えたら、別に意識してなかったのに胸が大きい人に偏りが出ちゃった時があって、勝手に拗ねられた。胸が大きいとか小さいとか許容してる男性も多いもので、むしろ問題はそこではなく、過剰にコンプレックスを感じていることがこちらに伝わるとその後の対応が気まずいからやめてほしいのだ。

僕は、地雷を踏まないように、おっぱい小さめな芸能人ラインナップに組み込む事にしたよ。


■なんで普通の女がいないのか?

なんでいないのかっていうと、普通じゃなくて理想からでしょう。あと、男だけでなく女もいないでしょこんなの。

記事を読みながら、自分普通じゃないって言われてるようで気分悪いな、って思ってたんだけど、今回この増田書きながら、こんなの全部当てはまる人なんてほぼいないでしょ、って再確認した。

記事には普通じゃない人が増えてるって書かれてるけど、理想が高くなってるだけだと思うよ。

2019-03-29

10連休RFPとか出すなよ

まさかこの10連休で出すなんて考えてないよね。上流コンサルさん。情シスさん。

IT業界風物詩だけど、ありえない風習なんで。

もしそんなことやる会社がいたら、社名公開してほしい。IT業界団体で動いてほしいな。日本IT団体連盟とか。

2018-03-03

参加してるプロジェクト燃えそうで震えてる

始まるのはまだ先だけど。

顧客から下りてきたRFPを見る限り、担当者自分のとこの業務を半分も理解していない(付き合いはあるのでこちらにも業務知識はある)。

工期も、要求内容に対して明らかに足らない(人増やせばいいって思ってるんだろうが…)。しかし、これはずらせないだろう。

全文中の3割程度は誤記だし…。

燃えるのが目に見えてる。逃げられるなら逃げたいなあ…。

2018-02-13

anond:20180213171933

よくある話だね。

どっちか一方じゃなくてどっちにも原因はある。


RFP顧客と一緒に作っていくものだ、顧客が丸投げであるのなら、

顧客システム開発に対する意識をこの段階で変えなければいけないし、

啓蒙をしていかなければいけない。

上記模範的意見であり間違いではないのだけど、

元増田顧客啓蒙成功したことあるのかな?

もちろん成功例はあるんだろうが、私は見たことないし自分でもそれができたと評価したことがないので単純に興味がある。

文化シャッターが悪い?IBMが悪い?

この界隈って、IT関係の人が多いから、どうしても目線がそっちになるので、

「どうせ顧客が今までと同じにしろ」とか「無理な要求したんだろ」とかの

コメントが多いが、自分は少し違う。

自分も一応エンジニアという職について、上流の仕事をしているが、

この案件あくまで外側から見る限りIBMに落ち度がありそうな気がしてならない。

 

なぜなら自分たちRFPを作って、自分たちで開発しているからだ。

RFPを作っている段階である程度開発の提案の形は見えていたはず。

RFPを作る段階で最上流の要件定義ができるはず。それが全くなされていない。

要求の変更が多かった。とあるが、その時点で最上流のRFPの失敗だし、

その責任IBMにないとは到底思えない。

 

RFP顧客と一緒に作っていくものだ、顧客が丸投げであるのなら、

顧客システム開発に対する意識をこの段階で変えなければいけないし、

啓蒙をしていかなければいけない。

システム刷新業務全体の刷新なのだということに。

だが、それを怠り、言われたままのRFPを作り、何とかできる形で、

作り上げ、RFPを作っていたコネクションでそのまま受注し、

後は開発部門エイヤ!っと丸投げたら、それは失敗するに決まっている。

逆に顧客システム開発に対する認識ギャップRFPの段階で埋められないなら、

その案件下りるべきなのだ

 

赤字が出るとわかっているプロジェクトなのだから

だが、IBMは受けた。受けた以上QCD責任をもたなければならないし、

それが履行されなかったのだから損害賠償は当然となる気もする。

 

だが、一方で、顧客はどうだったんだろう?

IBMがもしそういった働きかけをしていたとしたら、それにどれくらい応じれたのだろう?

システム刷新に対して業務が変わることを極端恐れ、RFPから多くの変更を

強いる形になっていなかったか

そういうところはこれから明らかにしていく必要がありそうではある。

 

だが、現時点ではIBM側に何等かの落ち度があったことは否めないと個人的には感じている。

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になったり、要するにベンダ独自のミドルに入ってがっつりロックインされたりするよ。

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

2017-04-13

[][][][][][][][][]

management

自分より優れたるものを自分の周りに置きし者ここに眠る。カーネギー

会者定離 - Wikipedia

ttps://ja.wikipedia.org/wiki/会者定離

できる人ばかり辞めていく会社研修費用を出すようになったら、さら退職が加速したというお話「人事に聞かせたい」 - Togetterまとめ

ttp://b.hatena.ne.jp/entry/s/togetter.com/li/1170691

従業員トレーニングをして、よそへ行ってしまったらどうするのか」という疑問に対するStanger氏の答えは、「従業員トレーニングをしないで、彼らが会社にとどまってしまったらどうするのか」ということになる。

ttp://japan.zdnet.com/article/35058310/

サイボウズ、離職防止の切り札は「出戻り歓迎」

ttps://s.nikkei.com/2vJsvYx

優れたマネージャー自分より高い給与をもらう可能性のあるポテンシャルの高い部下を喜んで雇う

ttp://b.hatena.ne.jp/entry/www.masafumiotsuka.com/2015/11/the_peter_principle.html

属人化対策

属人化をペアプロでどのように排除するか

ttps://employment.en-japan.com/engineerhub/entry/2019/11/07/103000

ジョイインク (Joy, inc.) のメンローイノベーションズに行ってきた

ttp://kawaguti.hateblo.jp/entry/2017/08/15/095840

プログラマーは全員ペアを組んで仕事をする

ttps://www.slideshare.net/yattom/ss-79372905

ペアプロ 属人化 - Google 検索

ttps://tinyurl.com/y8tkhuhz

1業務に2人を配置して23連続黒字になった秘密

ttps://bit.ly/2MylBjs

コアコンピタンス経営判断技術ノウハウ・開発スピード改善技術顧問・内製化・比較判断基準トレードオフ・ABテスト

事業のコアになる部分は、アウトソースしてはいけない。

ttps://medium.com/@kuranuki/aac6062adfb2

アウトソーシングしてるものを強みには出来ない。

ttps://twitter.com/kuranuki/status/225727331925368832

スキルノウハウが蓄積できる業務はコア業務

ttps://www.noc-net.co.jp/blog/2015/01/column_025/

コア技術の強みは、自社が大切に保持しなければならない。それが、以上に並べた4つの事例からくみとった教訓だ。

ttp://brevis.exblog.jp/26943020/



内製 外注 - Twitter検索

プログラミングとは経営判断の集積である

ソースコードの一行一行は、経営判断のものだ。

どの部分を汎用的につくり、どの部分をやっつけで作るか、そして、どの部分をパフォーマンス優先でつくり、どの部分を可読性優先でつくるか

(中略)

ソフトウェア開発とは、経営意思決定の集積なのだから経営意思決定を外部の会社委託するというのは、「経営を外部の会社にやってもらうようなもの」だからだ。

もっと言うなら、自分会社の今後のビジネスポジションを、他社に決めてもらうようなものからだ。

外注を出された会社は、そのソフトウェア未来に実現するであろうビジネス価値犠牲にして、できるだけ少ないコストで作ろうとする。

ソースコードの一行一行が経営判断のものになる

ttp://fromdusktildawn.hatenadiary.jp/entry/20061003/1159869683

プログラムは全て決断である

ttps://bit.ly/2JzCggZ

ソフトウェア業界特に受託開発業界)は、基本的に正直者が馬鹿を見る世界である顧客が、保守性というソフトウェアの最も重要品質を正しく評価できないという、情報の非対称性存在するからだ」/分かるなぁ

ttps://twitter.com/machu/status/25494063962

モダンな開発環境×技術顧問×内製化」Sansan×日経電子アプリ開発最前線を語る夜

ボタンを1つ追加するだけで2週間。内製化によるスピードアップは必須だった。

アプリ内にボタンを1つ追加するだけで、2週間の開発期間と、数十万円のコストが発生していました。それでは急な仕様変更対応できないし、技術ノウハウも貯まらない。」

ttp://careerhack.en-japan.com/report/detail/525

ネットサービスの肝は、開発にかける額の多寡というよりは、内製化するかどうかにあると思っています

ローンチした後、そこからの追加・改善ものすごいスピードでやらなくちゃいけない。これは、内製体制でないと絶対不可能です。

サイバーエージェント藤田社長が語る技術採用理由/Tech総研

ttps://next.rikunabi.com/tech/docs/ct_s03600.jsp?p=001780

2017年1月ネット証券大手マネックス証券証券基幹システム刷新した。

お客様提供するサービスの開発スピード向上と、ノウハウの社内蓄積、開発コスト適正化目的に、

開発環境も外部のASPサービス利用から内製化に切り変えた。

(中略)

サービス改善新サービスの開発時に、ASPサービス提供会社との会議に費やしていた時間を削減し開発のスピードアップを図ることで、競合他社への競争力を強化したいと考えました。

ttps://thinkit.co.jp/article/12761

システム内製化は、業者に頼むよりずっと難しい

ttp://b.hatena.ne.jp/entry/s/quality-start.in/it-strategy/467

システム内製化度テスト

ttp://d.hatena.ne.jp/forest1040/20101015/1287109777

システム発注社はSI発注するより内部で作った方が幸せになれる理由 - Rails Webook

ttp://ruby-rails.hatenadiary.com/entry/20140818/1408287600

「五年あれば、どんな企業でも内製の体制を築ける」

ttps://twitter.com/kanayang2009/status/129677947572465666

ttps://amzn.to/2ncDXrO

RFP提案依頼書)

即戦力になるような人材なんて存在しない。

から育てるんだ。

スティーブ・ジョブズ



ABテスト デザイン OR ボタン OR 文言 - Twitter検索

B2Cサイト/アプリ外注して成功している会社ってどこ?

外注でもA/Bテストユーザの反応を計測してトライ・アンド・エラーシステム開発ってできるもんなんだろうか。

できるとして、それって内製化した方がずっとクオリティ高くなるんじゃないの?

ttps://twitter.com/fromdusktildawn/status/874796380522336256

「外部委託すると細かい継続的機能改善が遅くなるので、自社採用でかなり優秀な人材ケチらずに採るべきだね。なかなか見つからなくても妥協せずに」ホリエモン

ttps://bit.ly/2QWMsoJ

外注PDCAを回せないという致命的な欠点がある。ITスタートアップ感覚だと外注と内製には天と地ほどの差がある

ttps://bit.ly/2J5UCWQ

銀の弾丸ではないがリーンな開発は競争力の源泉。そのためにはPMFコントロールできる開発チームが必須でそれは内製でしか達成困難。

ttp://b.hatena.ne.jp/entry/363456374/comment/Shin-JPN

Joel on Software - ジョエルテスト

ttps://bit.ly/2vkDd8E

1日1000個のA/Bテストを行う「Booking.com」の開発の裏話を聞いてきました【前編】

ttps://gigazine.net/news/20161002-booking-com-ab-test/

1日1000個のA/Bテストを行う「Booking.com」の開発の裏話を聞いてきました【後編】

ttps://gigazine.net/news/20161002-booking-com-technology/

正解に当たるまで回し続ける!3ヶ月で200回のA/Bテストから得た「意外な結果」とは

弊社のイベント一覧のページなのですが、単なるテキストの羅列のパターンと、リッチレイアウトのものテストすると、いつも必ずテキストの方が勝ちます

社員は全員一致で、リッチな方が見やすくて良いと思っているのですが…。

ttps://seleck.cc/165

海外テック情報局eBayではダサいデザインのほうがコンバージョン率が高かった|gihyo.jp技術評論社

デザイナと口論したいのではなく,見たいのは数字とお客さんの利用例。

そして何がうまくいっているのか突き止めたい。

あんたがありえないほどキレイだ! とか思ってても,何の役に立つ?

ttp://gihyo.jp/dev/clip/01/tech_information/vol69/0003

選択の科学 24種類のジャムを売り場に並べたときと、6種類のジャムを売り場に並べたときでは、前者は、後者の売り上げの10分の1しかなかったのです。

ttps://amzn.to/2I2V1O4

エンジニアでないファウンダーは最大一人まででお願いします | On Off and Beyond

理由1:変更につぐ変更を重ねられるようにする

最近 lean startup なる考え方がはやってますが、これはどういうことかというと、

トライする回数 × 成功率 = 成功

という式で、成功率の方をあげることは不可能なので、トライする回数を圧倒的に増やすのが成功の鍵だ、という発想なり。

ttps://chikawatanabe.com/2010/11/17/technical_founders/

東大合格ランキングは正しいのか?――常に分母は何かを考えよ

コツは、(2)と(3)の両方の“率”を正確に記録し、両方が上がるようにそれぞれ別の施策を立てることである

ttp://bizmakoto.jp/makoto/articles/0705/22/news008.html

何事にも閾値はある。そこに至らなければ、意味がないという数字だ。

「頭のいい人が成功しない理由」という本に、閾値の話があった。

だれもが中途半端にやめてしまう。それでは足りない。閾値を越えない。

閾値を越えない限り、やっても意味はないのだと。

ttps://ameblo.jp/chimu841/entry-10036171360.html

ttps://amzn.to/2Odv25b



技術ノウハウたまるノウハウの社内蓄積)

①内製

内製+技術顧問

技術ノウハウがたまらない

顧問プログラマ

外注

レモン市場情報の非対称性

レモン市場 - Wikipedia

ttp://bit.ly/2qQbadu

フラクタルレモン市場問題建築不動産クラスタ交流会の件その1

ttp://realtor-readyabooks.hatenablog.com/entry/20100515/1273919457

中間業者中抜きすると受発注者はWin-Winになるか?

ttp://ledsun.hatenablog.com/entry/2016/02/28/014851

ttps://ja.wikipedia.org/wiki/情報の非対称性

ttps://ja.wikipedia.org/wiki/逆選抜

取引コスト

ttps://ja.wikipedia.org/wiki/取引コスト

「探索コスト

交渉コスト

監督強制コスト



時給○○○○円、月額○○○万円、

時給制(時間を売る)が生産効率低いのって自明だよなぁ・・相当ボランティア精神ないと時給制で効率よくやろうって気持ちにならないよね

ttps://twitter.com/YamadaQuality/status/955988197976059905

でも拘束時間金額を決めてしまっては効率化を目指さなくなるんじゃないか

ttp://b.hatena.ne.jp/entry/b.hatena.ne.jp/entry/194800390/comment/redhornet96



利益相反エージェンシースラック管理モニタリング時間

エージェンシー・スラック(agency slack)とは、エージェントが、プリンシパルの利益のために委任されているにもかかわらず、プリンシパルの利益に反してエージェント自身の利益を優先した行動をとってしまうこと。プリンシパル=エージェント理論 - Wikipedia


ttp://b.hatena.ne.jp/entry/twitter.com/etomiho/status/872820182883762176

ttp://b.hatena.ne.jp/entry/twitter.com/etomiho/status/872822997106565120

ttp://getlife.hateblo.jp/entry/2013/09/10/015011

見積もり人日工数計算していると、実際にはそれよりも短期間で実装できても見積もり日数になるまで納品を待ったりすることはある。

ttp://b.hatena.ne.jp/entry/357516986/comment/netcraft3

プログラマーは皆、常に秘密や嘘を抱えている

納期よりもかなり早い段階で実際には完成しているにも関わらず、

納期ギリギリになるまで「まだできていません」と発言するのだ。

ttp://d.hatena.ne.jp/totopon114689/20120111/1326266304



モニタリングコスト監視費用

 エージェント利益相反行動をしていないかどうか監視するためのコスト

ボンディングコスト保証費用

 自身の行動がプリンシバルの利益追求にかなっていることを証明するために

 エージェント自らがかけるコスト

ttps://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1212240292

エージェンシーコストとは

ttp://www.nsspirit-cashf.com/yougo/yougo_agency.html



技術顧問・内製化・顧問プログラマー

文系経験からプログラミングを独学で学び外注してたWebサービスを内製化するために勉強したこと - ゼロイチ起業ノート

ttps://blog.zerotoone.jp/entry/2017/03/15/065148



Rails 技術顧問

ttps://twitter.com/search?q=rails%E3%80%80%E9%A1%A7%E5%95%8F

顧問プログラマ再考 - Rails 雑感 - Ruby on Rails with OIAX

ttps://www.oiax.jp/rails/zakkan/rethinking_of_adviser_programmer.html

顧客企業による内製化を支援する

ttps://www.oiax.co.jp/consulting

ITエンジニア採用に欠かせない原則とは (1/5):IT人材ラボ

ttp://b.hatena.ne.jp/entry/s/itjinzai-lab.jp/article/detail/856

ttps://www.slideshare.net/fukumura1/fukuokarubykaigi-medpeer-ver1

開発支援

ttps://everyleaf.com/development-support

【256人がリモートワークで回る仕組みを考える】後編

ttps://www.remotework-labo.jp/2015/10/interview_10/

ttp://cast-er.com/blog/client-interview-masaki-komagata/

内製化に切り替える場合も援助をいたします。

ttp://fjord.jp/commissioned-development/



真の人月商売こそが受託開発産業を救う ― 請負契約ではITプロジェクトは失敗する

ttp://b.hatena.ne.jp/entry/shunichi-arai.blogspot.com/2014/05/it.html



ソニックガーデンとテレワークマネジメント業務提携 〜 働き方改革の実現を支援するシステム『F-Chair+(エフチェアプラス)』提供開始

『F-Chair+』では「働いている時間」と「何をしているか」を同時に管理できる機能を実現

ttps://prtimes.jp/main/html/rd/p/000000001.000022534.html

納品のない受託開発

「納品」をなくせばうまくいく

ttps://amzn.to/2naCphY

43.一括請負しないので、長く続く方が嬉しい

ttps://www.slideshare.net/kuranuki/ss-87706585

お客さんには僕らがどれだけ時間をかけているかは見せません。

ttp://mydeskteam.com/casefile/2171/

毎週何時間働きますよという契約ではない

ttp://gihyo.jp/dev/serial/01/take-evolution-site/0002?page=2

最初は1

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)

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

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