「RFP」を含む日記 RSS

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

2020-06-08

anond:20200608000032

よく「対等に見てない」とか揉めるけど、結婚できない人って結婚を(対等な?)異種族とか他業種とのビジネス上の契約だと思ってんだよね。で、RFP出して笑われて終わる

2020-03-28

アジャイルってなんだっけ?

システムの作り逃げはなぜ起こるのか - novtanの日常

アジャイルって「テストに通るだけのクソコード量産体制」じゃない? 

ウォーターフォールが良いとは言わんが、デザインパターンと、ドメイン単位での分離をやるには、ある程度の設計必要だよ。

アジャイルにせよプロトタイプにせよ本来時間効果お金で買う為の手法なのだが、

なぜかこれらの手法効果コストメリットがあるというアホな技術者発注者蔓延しているのが原因かと。

時間お金がほぼ全て

RFP以前に、そのシステムで何をしたいのか明確にできず「いい感じでやってくれ」としか言えないような組織

アジャイル? 安くて速い? それで行こ!」な経営では、企画失敗の連帯責任すら負わされる。逃げるべし。

細かくイテレーション回して検証していくのがアジャイルだと思ってけど違うの?

2020-03-09

頭の悪いひとが面倒

自己紹介ときに「●●会社の▲▲です。SEしています。」と言われても意味が分からない。

当然、SEとはIT関係仕事でその中でも比較プロジェクト全体を見たり上流工程をこなす奴らのことをそう呼ぶことは知っている。

基本的製造はしないため管理側に近いが、製造側でもあるという中間的な位置であることも知っている。

●●会社というのも、コーポレートサイト程度であはるが存じ上げている。

じゃぁ何が意味が分からないのかというと、自己紹介を受ける前段階で、そういうことが出来る人間であることの前情報を得ているのである

まり、私はお笑い芸人風俗嬢と打ち合わせをしている覚えはないのである

ならば、「SEしています」という自己紹介無意味すぎて逆に何らかの意味があるのかと考えてしまう。

しかもだ、「SE」は会社によって定義が違いすぎる。取り敢えずSEという役職にしている会社だってある。

自己紹介の一発目にして打ち合わせ以前から得ている「IT関係従事していてシステムを作れるか調達できる人」以上の情報こちらに渡していないのである

ここまでくると、5歳児以下かもしれない。「今日ね、パパの絵を描いたの〜」って言われるほうがまだ背景が推測できるだろう。

さて、相手が本当に5歳児であれば可愛げがあり児童労働法律禁止されていると嘆くところだが、今回の相手は見た目で40歳ぐらいのおじさんである

倫理上や道徳上、人を見た目で判断してはいけないとは思うが、どうあがいても40歳ぐらいのおじさんである博士課程に進んでいないと仮定した場合、成人して20年程度は働いていないとまずいはずであるため、20前後業界経験があるはずであることを期待している。

まり、もし、おじさんが自分の同じ考え方や脳みそを持っているならば、おじさんからは『20経験したうえで、今、自己紹介をしている相手は、自分が分かっていることを再度いう必要がある人間である』という謎の見下し姿勢が読み取れる。

バカにされるには構わないし、バカを演じた方が良いことを充分に承知している。

しかし、もし相手バカを演じているのであれば、相手によれば失礼な発言すぎるということで怒らせかねないと思う。

更に、SEといえば何とかなる程度の相手しか仕事をしてこなかったという深読みすらできるため、相手に信用されにくくなる恐れがある。

では、逆にベスト自己紹介は何だったのだろうか。

おそらく、「やっていること」と「やってきたこと」を具体性を損ないすぎない程度に簡易的に説明することだろう。

まり「●●会社の▲▲です。システム要件定義RFP作成の手伝いなどしてまして10年ぐらいの経験があり、その前はコードを書いてました。」ぐらいだろう。

「●●会社の▲▲です。SEしています。」ではないはずだ。


SNSテレビ番組、身内を初めとして頭の悪い人間散見され、ただでさえイライラしているのに、

面倒だと感じさせるような、頭の悪い人間目的の打ち合わせをしなければならないことが非常に腹立たしい。本当に、面倒だったし、私のハゲがより進行したことだろう。

まずは、怒ったりしないで冷静に打ち合わせができた自分を褒めたい。

そしてそんな境遇に陥ることにいたった自分の頭の悪さを嘆きたい。みつお

2020-02-03

エンタープライズITの光と闇

エンタープライズIT世界を紹介する。これから業界に入る若者は参考にしてほしい。

エンタープライズITはこんなツリー構造になっている。下層にいくほど枝分かれする。層の深さや枝分かれの多さはプロジェクト金額による。このあたりの闇は増田でも多く語られている。たとえ天下のGAFAでも1次請けやIT部門の下に入る。昔はオラクルIBMだったのがAWSAzureに代わっただけで構造的には同じだ。

それではカネの流れと利益構造説明していこう。増田のメインターゲットである下層から説明する。

n次請け

この層はIT会社ではなく人材派遣会社といっていい。n次請けはn-1次請けに人材派遣するので以下の構造がある。

例えば、月単価100万円の人を10派遣すると売上は1,000万円になる。この売上を営業やコーポレートといった連中と社内で取り合うわけだ。だから給料を上げるには単価と作業時間を上げるしかない。

n次請けの営業はn-1次請けと単価を交渉する。単価は派遣対象スペック(経歴書)で決まる。単価を上げるためのキーワードはだいたい決まっていて、チームリーダーとかクラウドとか入れておけばいい。あと、作業時間無駄に多い方がいい。自動化作業時間を減らすやつはバカだ。君の残業代は売上から出ている。

n次請けにいる人に告げる。さっさと転職しろAWS転職したら給料3倍だ。

2次請け

この層は人材プール会社になっている。大企業資本金信用調査などを満たせない零細企業直接取引ができない。2次請けは大企業零細企業の間に入り、需要に応じて人材を売る役割を果たす。あと、キチガイみたいなやつが入らないようにフィルタするとか、派遣されてきた人が突然バックれた時に代わりを探すことも大事付加価値だ。

例えば、月単価50万円の人を80万円で紹介すると、売上は80万円、利益は30万円になる。給料を上げるには安い人材を高く売ることが重要だ。そのためには2次請け社員がチームリーダーとなり、n次請けの安い作業者でチームを作ればいい。作業者の人数を増やせば売上は伸びる。リーダーができないやつはクビだ。

2次請けにいる人に告げる。現職はい待遇だと思っているだろうが、外の世界を見ろ。

1次請け

この層は大企業だ。2次請けやハードソフトベンダ統合してシステムを納品する。一括請負契約場合リスクバッファ役割を負う。開発が炎上してもIT部門は痛みを負わない代わりに、マージンでガッポリ儲ける仕組みだ。

実際には、IT部門が出したRFPに対して工数見積もり価格提示する。受注できたら開発に取り掛かり、納品と検収を終えたら売上が立つ、という流れになっている。コンペの場合見積工数にかかわらず提案価格を大幅に安く出すこともある。また、受注してから売上が立つまで数年かかる場合もあるため、資本力勝負だ。ハードウェアやパッケージ製品クラウドを一緒に販売する場合もある。

給料を上げるには出世することだ。出世するには仕事を増やして安い人材を高く売る必要がある。

重要なのは流行りの商材でIT部門を釣って仕事を取ることだ。RPAAIなどのバズワードがなぜ人気なのか理解してもらえただろうか。開発は2次請けに任せればいい。お前の単価はいくらかわかっているか

1次請けにいる人に告げる。リストラに備えろ。潰しの効かない仕事を続けていると転職できなくなる。

IT部門

IT部門は、ユーザ部門から受託した企画を具体化し、ベンダコントロールしていくことが主な任務になる。あとは負債化したシステム運用管理をやっていく。

IT部門コストセンタなのでコスト削減が評価される。また、トラブルシステムが止まると社内から批判を浴びるため品質管理評価される。

給与は上げるには出世することだ。こういう方法がある。

負債化したシステムは細々とメンテしていくしかない。ハード保守が切れるタイミングで大規模更新計画して実績をアピールだ。

ただし、IT部門ポストが限られているので出世するには社内政治重要だ。出世の見込みがないなら転職しろ

ユーザ部門

ユーザ部門は新しい企画を立てて経営から承認をもらい、ITを使って収益を得ることが仕事だ。あるいは費用を削減することが仕事だ。

ユーザ部門コンサル会社企画書を作らせて、営業マーケティングなどの他部門要件を調整し、遅くて融通の利かないIT部門のケツを叩くことが任務だ。

だがよく考えてほしい。IT部門と多重下請のケツ叩きに無駄時間を使うより、自分たちベンダと組んで一緒に企画、開発、運用を進める方が効率的かもしれない。今日企画を来週にリリースできたら最高ではないか。小さくリリースして学びを得て改善していく。

ユーザ部門はどんどん稼いで出世してくれ。

2019-12-14

[][][]Ruby on Rails書籍勉強する前に

テレワーク

リモートワークを採用している日本のテクノロジー企業のまとめ

リモートワーカーへの公平な支払い

ttps://b.hatena.ne.jp/entry/s/portalshit.net/2020/05/28/paying-remote-employees-fairly



Ruby

Ruby基礎文法最速マスター

Ruby入門 (全26回) - プログラミングならドットインストール

https://try.ruby-lang.org/

技術面接で出された問題

ttps://b.hatena.ne.jp/entry/s/blog.agile.esm.co.jp/entry/2016/10/03/150625



Rails

Railsの教科書

Railsをはじめよう - Railsガイド

Ruby on Rails5 | プログラミングの入門なら基礎から学べるProgate

Ruby on Rails 5入門 (全28回) - プログラミングならドットインストール

Ruby on Rails チュートリアル:実例を使ってRailsを学ぼう - Michael Hartl (マイケル・ハートル)

Ruby on Rails ガイド:体系的に Rails を学ぼう

ttps://railsguides.jp/



MVP

良い文章家を雇う Getting Real by 37signals

ttps://bit.ly/3brDHxw

プログラミング学習アプリケーション開発の間にある高い壁を乗り越える方法

これから作ろうとするアプリケーション動作を一つ一つ小さなステップに分解して言語化していくという作業です。自分言葉説明できないシステム言語化できないシステムは作れません。

ttps://note.com/xhack/n/n8ee34d2dc176



MVP(Minimum Viable Product:仮説を検証することができる最低限のプロダクト)

リーン・スタートアップ エリックリー

ttps://www.amazon.co.jp/gp/product/4822248976

『なぜ、あなた仕事は終わらないのか』

もしも、10日で仕上げるタスクであれば、2割に当たる2日間で8割終わらせるつもりで取り掛かるのだ。

ttps://type.jp/tensyoku-knowhow/skill-up/book-summary/vol15/



とにかく雑に作れ - 東京工業大学エンジニアリングデザインプロジェクト - Medium

ttps://b.hatena.ne.jp/entry/s/medium.com/titech-eng-and-design/%E3%81%A8%E3%81%AB%E3%81%8B%E3%81%8F%E9%9B%91%E3%81%AB%E4%BD%9C%E3%82%8C-2f87cc00eb85

Things that are complex are not useful, Things that are useful are simple.

Mikhail Kalashnikov

複雑だと役に立たない。何よりも単純であることだ。

ミハイル・カラシニコフ 史上もっとも大量に製造され拡散しているアサルトライフルであるAK-47」の設計

完成に漕ぎ着けるのは、

付け加えるものがなくなった時ではなく、

取り除くものがなくなったときである

Antoine de St. Exupery

イノベーションは全てのことに対してイエスと言うことじゃない。それは最も重大な機能を除いて、全てにノーと言うことだよ。

ttps://bit.ly/2JzCggZ



成功の鍵「ピボット」 スラックミクシィ共通点

ttps://www.nikkei.com/article/DGXKZO99252990U6A400C1X12000/



見積もりRFP提案依頼書)

見積り根拠出してくれっていったら、金くれって言われたよ

何社かシステム屋呼んで、こっちのやりたいことをいって、概算金額出させてた。この時出てきた金額が350万~2200万。

ttps://b.hatena.ne.jp/entry/s/anond.hatelabo.jp/20131003212934

3社に依頼したソフトの開発の見積金額唖然

数日して、上のように見積もりが来ました。

 A社は...900万円

 B社は...400万円

 C社は...100万円

これは、まったく同じFAXを送って、同じ説明をした結果です。

ttp://www.teoria.co.jp/10to493/002kikka/kika05.html



リンク

6 of the top 10 @ycombinator companies (by valuation) were built using Ruby!

ttps://twitter.com/mhartl/status/1179561691857616896

ttps://prograils.com/posts/top-10-famous-sites-built-with-ruby-on-rails

Ruby on Railsの事例まとめ(海外有名サイト編)

ttps://b.hatena.ne.jp/entry/s/skillhub.jp/blogs/176

Ruby on Railsの事例まとめ(日本有名サイト編)

ttps://b.hatena.ne.jp/entry/s/skillhub.jp/blogs/177



スタートアップでのプロダクト開発はRails必要十分

スケーラビティがとか、拡張性がとか、モノリシックアーキテクチャは柔軟性がないんじゃとかいう声が聞こえてきそうだが(もっとも僕も前はそう思っていたのだが…)、

こんな技術的な美しさやなんちゃらビリティなんてものスタートアップにおける開発速度の重要性に比べたらなんの意味もないものである

ttps://medium.com/@reoring/4a92508bd170

最近PMFする前にアーキテクチャにこだわりすぎる事故をよくみる。

PMFする前のプロダクトなんて動けばなんぼなので、Railsで汚くてもいいかゴリゴリ書いて、最低限のJSをつけるだけでよい。

リリースするまで6ヶ月かけるというのは事故で、3週間ほどを目安に企画からベータリリースまでいくべき

ttps://twitter.com/wyvernMurai/status/1024150618288472064

マネーフォワードCTOが考えていること(2020年3月

Ruby on Railsは、現時点で、新規サービスを立ち上げる開発生産性が最も高いと判断しています。0-1のステージにおいて最も効果的であり、多くの場合は1-10でも有用です。ただし10-100のステージでは、デメリットが見えはじめますしか10-100のサービスにおいても、Ruby on Railsの利用範囲ゼロになることはないと考えています

ttps://moneyforward.com/engineers_blog/2020/03/31/cto-message-202003/

スタートアップWebアプリつくるなら、Railsアプリ分割せずAPIモード使わずシンプルにつくれ。

最初WebpackerとES6で必要になるまでFWつかうな」

ttps://twitter.com/daaaaaai/status/1154207078715498496

A Modern Web Application With Rails

ttps://medium.com/rubyinside/a-modern-web-application-with-rails-da3deb48014c

JavaScriptフレームワークはもうこりごり

HTMLCSSJSが私のフレームワーク

ttps://postd.cc/zero_framework_manifesto/

ほとんどのスタートアップにとって、マイクロサービスはよい選択ではない

ttps://www.infoq.com/jp/news/2020/06/monolith-decomposition-newman/

Istioがマイクロサービスからモノリシックアプリに変化。その背景とは

ttps://b.hatena.ne.jp/entry/s/thinkit.co.jp/article/17540

さよならアーキテクチャ議論

1. 事業成功に占めるアーキテクチャという要素の小ささ

2. チームでの共通認識を作るコスト

3. レイヤー分けという行為のものへの疑問

売り上げは全てを癒すけど、アーキテクチャは全ては癒してくれないんですよ。

ttps://note.com/timakin/n/n02f6be6aa0bf

スーパーFatControllerだし、設計もめちゃくちゃだけど100万人以上に使ってもらえて、そこそこ利益も生み出した

ttps://bit.ly/2CxT7To

Twitter創始者

Ruby on Railsを使って2週間で最初の動くバージョンを作り上げた

ttps://bit.ly/2KdcKim

Ruby on Rails10分で作るTwitterもどき

ttps://bit.ly/2KVdAl8

時間ツイッターサービスを作ろう! – KRAY Inc.

ttps://b.hatena.ne.jp/entry/s/kray.jp/blog/twitter_service_in_1hours/

「1人で6時間で作った」 Twitter匿名質問「Peing」人気、月間2億PV超えへ

ttps://bit.ly/3b7qyIz

Railsは終わらない」と私が言う理由

Railsの真価は Web開発に必要基本的機能が全て揃い、その機能全てがローカル動作してテストを書く仕組みが存在することにあると考えています

ttps://qiita.com/alfa/items/3a23f32fd905e3ded0d8

Go で同じくことをやるのは難しいというのが試した結果の結論でした。例えば Rails サーバーからメールを送るなら ActionMailer を使えば一瞬でできますが、Go ではそこまでの速度は出せません。

ttps://www.wantedly.com/companies/wantedly/post_articles/193633?utm_source=t.co&utm_medium=share&lang=ja

僕らがRailsで戦い続ける理由

ttps://speakerdeck.com/toshimaru/why-we-use-ruby-on-rails

それでもRails選択する3つの理由 - pblog

ttps://ppworks.hatenablog.jp/entry/2015/02/19/223552

僕はずっとRails使ってますが、別にRailsにこだわってるわけではないのでもっと良い技術があれば普通に移行すると思います

ただ移行するためには今持っているRails資産経験など全てを超えてなお移行したほうがメリットある場合に限るので中々そういうものは少ないかな、、、と

ttps://b.hatena.ne.jp/entry/twitter.com/_sesere/status/953120084666433537

今は分かりませんが、数年前まではphprubyと同じ事をしようとするとソースコード量が3倍近く必要でした ソースが短ければバグが発生し辛いですし、ミスもかかる時間も減る と言うことで僕はruby、、、と言うよりrailsをおしま

ttps://b.hatena.ne.jp/entry/twitter.com/_sesere/status/928170730893619200

Railsセミナー面白かった。 スタートアップ企業社長PHPを捨ててRailsを選んだ理由エンジニアの安定性というのが、今回聞いた中では一番心に残った。

エンジニア視点ではなく、経営視点で考えたら、ボトルネックは必ず人だからだよな。

ttps://b.hatena.ne.jp/entry/s/twitter.com/poepoe49091/status/762141005432750080

スピードに対してごちゃごちゃ言うなら C じゃなくアセンブラで書けばいい。

それをなんで C で書いてるのかって言えば、 それはもちろん「コードがわかりやすい」とか、「早く書ける」って のが理由だろう。

そして、Ruby は C よりわかりやすいし速く書ける。 ということは、「C よりも Ruby」というのは非常に自然選択では ないだろうか?

ttp://i.loveruby.net/ja/ruby/why.html

Cで書くと2日かかる。実行時間は0.1秒

Rubyで書くと1日かかる。実行時間10秒(Cの100倍)

と、すこし極端な仮定を置いてみると、どっちが得でしょうか。

ttps://jp.quora.com/naze-ruby-ha-hokano-gengo-to-kurabe-te-osoi-node-shou-ka

Railsアプリケーションを、Heroku上で1分間125,000リクエスト対応できるようにスケーリングする

ttps://postd.cc/scaling-rails-to-125-000-requests-per-minute-on-heroku/



2017年Railsが学ぶ価値のあるフレームワークである理由は何ですか?

回答者David Heinemeier Hansson(デイヴィッド・ハイネマイヤーハンソン)、Ruby on Railsクリエイター、Basecamp創設者 & CTO

ttps://jp.quora.com/2017年-Railsが学ぶ価値のあるフレームワークである理由は/answers/129556088

RubyRails学習ガイド2019年

ttps://magazine.rubyist.net/articles/0059/0059-Ruby-Rails-Beginners-Guide.html

Rails2019年「あり」か? 統計を調べる

ttps://techracho.bpsinc.jp/hachi8833/2019_01_25/68846

Rails2019年「あり」か? Rails長所と向いている用途

ttps://techracho.bpsinc.jp/hachi8833/2019_01_29/68871

Rails2019年「あり」か? Rails短所と不向きな用途、他の選択肢など

ttps://techracho.bpsinc.jp/hachi8833/2019_01_31/68875

Ruby on Railsの作者より:高まった生産性仕事を余計にこなすためではなく自分の将来に向けて使おう

ttps://b.hatena.ne.jp/entry/s/himazublog.hatenadiary.org/entry/20080927/1222445526

Railsの基本理念 : Railsの生みの親が掲げる8つの原則

ttps://postd.cc/rails-doctrine/

Ruby on Rails: DHHインタビュー

Railsにある20%のソリューション問題の80%を解決できるようにしています

ttps://kdmsnr.com/translations/interview-with-dhh/

DHHはどのようにRailsコントローラを書くのか

ttps://b.hatena.ne.jp/entry?url=http%3A%2F%2Fpostd.cc%2Fhow-dhh-organizes-his-rails-controllers%2F

ShopifyにおけるRuby on Railsで速いコードを書く方法

ttps://b.hatena.ne.jp/entry/s/medium.com/@teruhisafukumoto/how-to-write-fast-code-in-ruby-on-rails-at-shopify-70668edc47b1

Railsアプリ設計

ttps://speakerdeck.com/sinsoku/railsapurifalseshe-ji

Ruby on Railsの正体と向き合い方

ttps://b.hatena.ne.jp/entry?url=https%3A%2F%2Fspeakerdeck.com%2Fyasaichi%2Fwhat-is-ruby-on-rails-and-how-to-deal-with-it

Railsエンジニアのためのウェブセキュリティ入門

ttps://b.hatena.ne.jp/entry/s/www.slideshare.net/ockeghem/ruby-on-rails-security-142250872



経験からRuby on Railsを学んで仕事につなげるまでの1000時間メニュー

ttps://qiita.com/saboyutaka/items/1a8c40e105e93ac6856a

あなたマスターしたのはいくつ? Rails習得するために必要技術要素の一覧

ttps://qiita.com/jnchito/items/063e332cbe3023f52f93

素人Webサービスを作ってみて分かった9つのこと

Webアプリ想像以上に複雑だった

ttps://el.jibun.atmarkit.co.jp/rails/2011/09/web9-1e8b.html

3年弱でゼロからフルスタックエンジニアになるまでにやったこと - 自分攻略していく記録

ttps://b.hatena.ne.jp/entry/s/diary.shuichi.tech/entry/how-to-be-fullstack

プログラミング独習するには10年かかる

ttps://www.yamdas.org/column/technique/21-daysj.html

railsのdefaultでは用意されていない考え方や設計リファクタリングについてのリンク

ttps://qiita.com/tos-miyake/items/8dffb16273726f538d49

プログラミングに関する法則原則一覧

ttps://qiita.com/hirokidaichi/items/d6c473d8011bd9330e63

「一つのことを、うまくやれ」

ttps://ja.wikipedia.org/wiki/UNIX哲学

The Twelve-Factor App (日本語訳)

ttps://12factor.net/ja/

Goの父」ロブ・パイクの「プログラミング5カ条」にネット上で話題

ttps://b.hatena.ne.jp/entry/s/gigazine.net/news/20200817-rob-pike-5-rules-programming/

ジョエルテスト

ttps://bit.ly/3fTUsmf

Joel on Software(ジョエル・オン・ソフトウェア) あなた絶対すべきでないこと(スクラッチから書き直す)

ttps://urashita.com/archives/3782

優秀なエンジニア5人は二流の1000人を完全に凌駕する:Rails Hub情報局エンジニアライフ

ttps://b.hatena.ne.jp/entry/s/el.jibun.atmarkit.co.jp/rails/2011/06/51000-6676.html

ビル・ゲイツさら過激で、「優秀な旋盤工の賃金は平均的な旋盤工の数倍だが、優秀なソフトウェア・プログラマーは平均的なプログラマーの1万倍の価値がある」

ttps://blog.tinect.jp/?p=64985

ブルックスの法則

遅れているソフトウェアプロジェクトへの要員追加

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://b.hatena.ne.jp/entry/s/gigazine.net/news/20171005-superboss/

「弱いつながり」理論でいうと、SNSでつながる友だちは、それこそFacebookの友だちが3,000人規模で、国内スタートアップ経営者なら、たいていの人に直接または1hopでつながることができる。

ttps://techplay.jp/column/366

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

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

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

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

内製、ペアプロ、属人化対策全体最適

人材会社資産として残らないが仕組みは会社資産として永遠に残る

ttps://www.amazon.co.jp/dp/B010JM64M6/

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

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

リモートモブプログラミングという働き方

ttps://blog.cybozu.io/entry/2020/02/28/080000

ジョイインク (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://www.amazon.co.jp/dp/4822273784

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

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

ttps://twitter.com/yoppymodel/status/1227445967215120386


選択の科学 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/



真のPermalink | 記事への反応(2) | 18:35

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)

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

 
ログイン ユーザー登録
ようこそ ゲスト さん