はてなキーワード: 検収とは
前職時代の話。
SIerなのだが、受注した高額案件2件に全く手を付けず、納期直前で転職したゴミカス野郎Aがいた。
しかも、引継ぎもロクにせずに出ていきやがった。
顧客が寛大だったから納期を1年延長してもらえたけど、引き継いだエンジニアはその分野で素人なうえ、
結局、専門技術のある自分がその後を引き継いで、バグ直しつつ、継続の仕事を発注してもらってやり続けた。
ただ、さらに最悪な状況になった。
その継続の仕事はAが辞める前に納品したライブラリを使う必要があったのだが、そのライブラリが未完成だっただけでなく、そもそも使い物にならない代物だった。
その時発覚したのだが、Aが納品したプログラムは未完成のものがいくつかあった。
正直、ひど過ぎだ。ゴミカスAだけでなく前職の会社も、発注した顧客も。
顧客のことは詳しく言えないが、本来であれば自分たちでやらなければならない仕事を税金を使って外注しているような業界だと思ってもらえばいい。
プログラムの動作確認なども自分たちで行わないで、Aの報告書を鵜呑みにして検収を出していた。
結局きりのいいところで納品して、自分も転職したのだが、転職後の会社で結局その仕事の継続を受注して、1年かけてようやく完成させた。
もうこの顧客の仕事は引き受けるつもりもないし、ゴミカスAはこの業界から消滅してほしい。
このフレーズにピンときた君は今の多重下請け構造に本当の意味で詳しい人だ。
たとえば、発注者と受注側合わせて100人体制のITプロジェクトがあるとする。今の時代、その100人の内訳はこんな感じだ。
受注者側下請け以下:70人
「発注者社員代替」は、発注者プロパーが本来やる要件定義やレビュー、検収、関係各部門との調整、ベンダーマネジメントなどをやる。たまに発注者プロパーの上長報告も代行する。発注者プロパーは契約事や社内稟議など、真にプロパーでしか出来ない業務しかやらないことが多い。要員の出所は受注者プロパーやその下請けを準委任で行かせることが多いが、最近はPMO専門会社も増えてきてるので、そこから派遣してもらうケースも増えている。
「受注者社員代替」も大体近しい。プロジェクトマネジメントや発注者との交渉などを受注者プロパーに成り代わって行う。交渉相手は発注者の社員代替だったりする。要員の出所は下請けからの準委任や派遣が基本だが、最近はPMO以下割愛。
発注と検収のいたちごっこみたいな仕事に嫌気が差して、入社して2年目からちびちびと転職活動をしていた。
入社して2年目は転職サイトとか転職エージェントとかを使って、もっと手を動かす仕事が良い!みたいな希望で活動した。
何社か応募したけど、採用どころか面接にすら全然届かない。経験も実績もないから、仕様無いと今になっては思う。
でも数少ない面談した企業の方からは「小さくてもいいからWebサービスを作ってみるといい」とか「うちはRails使うことが多いから、Railsわかる人だと嬉しい」みたいな具体的なアドバイスはもらえた。
ちなみにどことは言わないけど、転職エージェントは「年収が下がっていいならすぐに見つかります!」「正社員じゃなくて派遣から始めるのはどうでしょう!?」とか不穏な誘いが多くてすぐに使うのを辞めた。
3年目はもらったアドバイスに従って、仕事の合間に小さなWebサービスを作ることにした。(Railsは使わなかったけど)
流行りのフロントエンドフレームワークを使って、PaaSで公開。テストも書いて、CI/CDもちゃんと整備した。
フレームワークや言語の学習も含めると半年以上かかったけれど、納得のいくものが出来た。
4年目。業務転換があり、ベンダと要件の狭間でストレスが絶頂になった。
この環境から逃げたい、というひどく後ろ向きな理由で転職活動を再開した。
幸い3年目の成果物がある。Twitterの転職タグとかを使って成果物のURLを貼り付けたりすると、5社くらい話を聞いてくれることになった。
驚いたことに、エンジニア業界では有名な会社とかも声をかけてくれたりして、ちょっと有頂天になったりした。
しかしながら結果は惨敗。オンラインのコーディング試験や技術面接に歯が立たず、ほぼ全てがお祈りとなった。
ある企業の面談では、「希望年収の半分くらいなら」と言われたこともあった。この日のことは、未だに忘れられない。
4年目の惨敗を受けて、5年目はしょぼくれていた。
面接で出来なかった問題こそAtCoderなりアルゴリズム本なりで勉強していたものの、「こんなに勉強しないといけないなら、もう現職でいいかな」という思いが大半を占めていた。
なんとなくはてブの技術エントリを読んだり、Qiitaとか面白そうなチュートリアルを手慰みにして時間を潰していた。
そしてそんな折に、知人経由で大手ITを受けてみないかと声をかけられた。
いやいや無茶でしょう、というような有名企業で、自信を喪失していた自分には恐れ多いとしか言いようがない。
とは言え、落ちるだろうから受けない、というのもあまりに後ろ向きな話。
なので、受けるだけ受けることにした。知人の顔を立てる、というくらいのモチベーションである。
内容の詳細は秘密保持の関係から記載できないけど、3年目のサービス開発で学んだ知識と、惰性で技術エントリを読んでいた経験が活きた。
それなりに回答できて、手応えはあった(現職で得た知識とかももちろんあるけど)
結果は通過。そこからあれよあれよと面接ラッシュで、すったもんだありながらも最後は内定。
待遇も満点ではないけど十分な内容で、迷う余地がなかった。強いて言うなら、休みが減るのがちょっとネックかな。
元増田に言いたいのは、一回動くと何かが変わるよってこと。
私が結果としていい転職ができたのは2年目の活動の際に「Webサービスとか作ってみるといい」ってアドバイスをもらえたのがきっかけだし。
ベンチャー企業の人から声をかけてもらえたりするくらい頑張ってるなら、胸を借りるくらいの気持ちで話をしてきたらいいんじゃないかな。
人生の分かれ道は意外なところに落ちていたりするよ
人の不幸は密の味。なによりの大好物は失敗プロジェクトの内情暴露、という増田だ。
さて、今日もいつものようにCOCOAを巡るすったもんだとか https://www.tokyo-np.co.jp/article/87051
ワクチン接種管理システムの納期が2週間とか https://www.nikkei.com/article/DGKKZO69301930Z10C21A2EA2000/
それをおかずにしておいしいご飯を食べながら、年老いた母に向かって上機嫌に語った。日本のITがいかに惨憺たる有様なのかを語った。奴らは失敗したし、これからも失敗するだろう。なぜなら日本はIT技術者を軽視しすぎていて、商社きどりのITベンダーが何か仕事したつもりになってそれでお金を貰える国だからね。といった具合だ。もっともこれは俺が何度も何度も繰り返している社会に対する呪詛で、目新しいところは何もなかった。
「どうでもいい話だね」
と沢庵を口に運びながらふいに母が言った。
「あんたが、過小評価されてようが、どこかのシステムの一つも満足に出来もしない誰かが高給をもらってるとか、そんな話は――」ポリポリと沢庵をかみしめて、飲み込んだ。「――どうだっていい話だよ」
俺はせっかくの上機嫌に水をさされて、少しムッとした。間髪をいれずに母は続けた
「COCOAってのはソースが公開されて、誰でも欠陥を発見できるようになってたんだろ?」
ニュースか何かで知ったらしい。
そうさ、だからCOCOAの欠陥だって、4ヶ月前に発見されてissueとして報告されてた。でも元請けのベンダーも下請けもみんな無視したんだ。
「それは残念だったかもしれないけどね。それもどうでもいい話さ」
そんなことはないだろう、と俺は食後のお茶を淹れながら反論した。
元請けってのは正常に動作するシステムを納品する責任があるんだ。彼らはその責任を果たさなかった。発注者の厚労省だって、検収責任があったのに怠っていた。
「発注者にも元請けにも責任がある。それは道理だね。ただ、私が知りたいのは、あんたの責任さ」
責任?プロジェクトに無関係の、安月給のしがないプログラマの俺の責任?なんだそりゃ?
きょとんとして、母親の目を見た。茶をすすっている皺くちゃの顔が怒りの感情をたたえていることに長年の付き合いのある俺はすぐに気づいた。
「あんたはプログラムがわかるんだろ。あんたは問題の指摘を見てどうしたんだい?」
ギクリとした。俺はそのIssueをgithubで見たわけではなかった。正確にはCOCOAの不具合が明らかになってから、どこからともなくTwitterでまわってきたスクリーンショットを見ただけだった。
「他のプログラマだってそうだ。その指摘は正しかったんだろ?プログラムを見たらそれが正しいことはわかったんだろ?なんで、これはすぐに対応しなきゃいけない。みんなで大騒ぎしよう、とはなんでならかったんだい?そうしていたら、もっと早く問題が解決したかもしれないのに」
俺は黙るしかなかった。正直なところ俺はCOCOAのソースコードすら読んではいなかった。だってXamarinだし、目もくらむような一流企業の年下の若者の書いたコードだし、そもそもアプリは専門外だ。だがそれを母に言って納得させられる自信はなかった。
「それだけの能力がなかったからできなかったっていうなら、仕方ないことさね。それは責められるもんじゃないよ。仕事で請け負ったわけでもないしね」
能力がない、という言葉がまたチクリと俺の胸に突き刺さった。実際のところ、がんばって読み解くぐらいのことはできたかもしれない。GoogleとAppleのドキュメントを読んで、issueの内容を検証する、ぐらいのことだったら出来た可能性もある。
だが、俺はやらなかった。やらなかったから、出来なかったのだ。
プログラムができる人間としてissueが正しいかを検証する責任?
「違う。それは出来なくていいのさ。出来る人がいればたくさんいれば良かったろうけどね。そうじゃない」
じゃあ何?
「このコロナっていう大変な時代に、みんなの命がかかっている大事な話に、『プログラマとして』関わる責任だよ」
ピンとこなかった。俺はコロナ関連のシステムを作っているわけじゃないし、それは他の連中の仕事だ。
「いいかい?私らはプログラムのことなんてさっぱりわからない。エーピーアイってのが何のことかさえよくわからないんだ。あんたにはわかるんだろ?」
「つまりあんたは、私らとは違って物事がようく見えているはずなんだ。私らには逆立ちしたってできっこないことが、出来るはずなんだよ」
で、でも、具体的に何をしろっていうんだよ・・・・・・
「何だっていいさね。あんたの残業が多くて、給料が安いのも知っているから、出来る事なんて全く何もなかったって仕方ないかもしれないね。でも―――」母は目を見開いて俺を真っ正面に捉えた。
「実際に作業をしている当事者をおもしろおかしく冷笑したり揶揄えるほどあんたが無関係だ、とまでは思わないね」
俺は押し黙って下をみるしかなかった。炬燵布団の単調な色合いがくすんで見えている。
「私らはね、これでもあんたたちプログラマに敬意を払ってきたつもりなんだ。給料が安いのだって、可哀想に思っているよ。早くあんたたちがその努力に見合った待遇を勝ち取れたら良い、と本当に思っているよ」
「だけどね、こんな大変な時に、みんなの命がかかっている時に、あんたのようなプログラマーが給料が安いからやる義理はないだの、責任の所在がどうだの、そういう何も生み出さない評論家じみた減らず口を止められないのはどういうことなんだい?そんなことをあんたたちが言う権利は本当にあるのかい?」
「結局のところあんたらは」母は、茶の最後の一滴をすすった「私らの命にすら興味がないんじゃないのかい?」
そんなことは・・・・・・
と反論しようとして、自分が言おうとしていることが何もないことに気づいた。そうじゃないんだ。そうじゃないんだけど・・・・・・とめどない言い訳が続いて俺は口をつぐむしかなかった。
だから本文にも増産に繋がるなら~って書いてるしな
でも時間が経った新品のゲームソフト(パッケージ)はメーカーの売上にならなくね?っていう話よ
引渡しでも検収でも出荷基準でもいいんだけどさ、要するにモノを売ったら売上勘定として計上するわけじゃん
だからメーカー側からしたら小売や問屋に売った前後で売上として計上するわけじゃん。じゃあ売上に計上した後に小売店で在庫があろうかなかろうが一切の関係はないじゃん
直販店だったとしたらまあ、個人客に売った時点で売上に計上するだろうからその限りではないんだろうけどさ
つまりさ、小売店に売れ残ってる新品のゲームソフトを買ったところでメーカーには一切売上にならないからメーカーは喜ばなくねって結論になるのよ
にも関わらず勘違いをして小売店の新品のゲームソフトを買えばメーカーに金が落ちると思ってる人がちょいちょい居てモヤモヤするっていうのが本文なのよ。お分かり?
Android版バグについて開示された文書を少し読むだけでいくつかのデマが分かった。
https://note.com/mugura/n/ncc3c61de39ea で情報開示されたPDFを読むことができる。
議事録側はまだ読んでいない。
最初にHER-SYSの開発のためにパーソルプロセス&テクノロジー株式会社と税込約2億の契約があった。
COCOA開発は原契約を税込約3億へ変更とすることで対応した。
契約変更の時、再委託先を株式会社FIXERの1社から以下5社へ変更する申請がなされた。
厚生労働省 ┗ パーソルプロセス&テクノロジー 2億6771万(税別。以下同様) ┣ FIXER 1億2062万 ┣ エムティーアイ 1615万 ┃ ┣ E社 355万(MTIから) ┃ ┗ D社 41万(MTIから) ┗ 日本マイクロソフト 2201万
株式会社FIXER | 新型コロナ感染者等情報把握管理システムの開発、監視運用、サポートデスクの一部業務、およびサービスの提供 |
株式会社エムティーアイ | 接触確認アプリケーション開発の一部、リリース後のヘルプデスク/運用保守業務 |
E社(MTIからの委託) | メールサポート(日本語/英語) 接触者に対する電話サポート(日本語のみ) |
D社(MTIからの委託) | 初期検収業務の一部、および保守開発準備業務の一部 |
日本マイクロソフト株式会社 | PMO支援、技術支援 |
デマについて
・まず2億から3億の差額約1億がHER-SYS側への繋ぎこみおよびiOS・Androidのアプリ開発に充てられていることになる。アプリ開発が3億のように言うとデマ。
・そして3次請けの位置の2社は業務範囲に開発は含まれていない。「多重請負でたったこれだけに」みたいな図でここの金額が出てきたらデマ。
ここからは憶測や調べ切れていないこと。(議事録側で分かることもありそう)
・COCOAのベースはOSSのCOVID-19Radarで、開発に関してはどこかにOSS利用という線を引いた方が分かりやすい。
・OSS利用を0円発注の搾取とは通常言わないが、今回に限っては、1国1アプリの条件がある中で、6月中旬公開の宣言されて実質納期になったり、
初期の品質批判がコミッターに直撃してリタイアしたところを見ると受託者に近いようにも思う。
https://www.itmedia.co.jp/news/articles/2006/23/news107.html
・開示された文書での契約期間は2020/7/31までだが、それ以降の体制は未確認。
・2020/9/28にiOS版の不具合(通知あるのに接触なし表示)修正のためにアップデートが行われ、その時Android版にエンバグが発生した。
https://www.asahi.com/articles/ASP236SR9P23UTFL00R.html
・政府CIO補佐官(ブクマカ)のツイートでは、EN API自体の制約や、アプリで選定された技術から人材・機材の手配の難しさに言及している。
https://twitter.com/masanork/status/1358207125546127362
https://twitter.com/masanork/status/1358187420492001281
・人材についてはMSがいるのにと思ったが、MSの支援が切れる事情でもあったのだろうか。
・COVID-19Radarでない方のまもりあいJapan(の一般社団法人Code for Japan)は新型コロナウイルス感染症対策テックチーム第1回から参加していたが、採用されないことになったについて根拠が不透明とある。
https://medit.tech/code4japan-not-incharge-of-contact-tracing-app/
・COVID-19Radarの中心がMS社員であったことや、Azure DevOpsなどMS一色の技術選定であったことなどから経緯を訝しむ考察があった。
https://blog.rocaz.net/2020/06/2140.html
https://blog.rocaz.net/2020/06/2171.html
https://blog.rocaz.net/2020/07/2257.html
・そして今回の開示された文書でもなぜCovid-19 Radarが選ばれたのか不明とある。
・選定が不具合と直接関係ないとは思うものの、利用人口少ない技術スタックを選んで人材不足になったなら遠因にはなってる気がする。
時間 | 記事数 | 文字数 | 文字数平均 | 文字数中央値 |
---|---|---|---|---|
00 | 114 | 18562 | 162.8 | 46 |
01 | 35 | 5806 | 165.9 | 34 |
02 | 64 | 12689 | 198.3 | 79.5 |
03 | 45 | 3671 | 81.6 | 48 |
04 | 13 | 737 | 56.7 | 39 |
05 | 14 | 1501 | 107.2 | 84.5 |
06 | 57 | 4009 | 70.3 | 30 |
07 | 48 | 5391 | 112.3 | 55.5 |
08 | 79 | 7362 | 93.2 | 55 |
09 | 126 | 16295 | 129.3 | 49 |
10 | 163 | 16608 | 101.9 | 46 |
11 | 142 | 11898 | 83.8 | 44 |
12 | 140 | 12371 | 88.4 | 47 |
13 | 166 | 14282 | 86.0 | 38.5 |
14 | 252 | 18346 | 72.8 | 35.5 |
15 | 127 | 9970 | 78.5 | 45 |
16 | 148 | 11728 | 79.2 | 40 |
17 | 162 | 14519 | 89.6 | 51.5 |
18 | 180 | 18110 | 100.6 | 50 |
19 | 143 | 22591 | 158.0 | 56 |
20 | 157 | 17095 | 108.9 | 47 |
21 | 170 | 18188 | 107.0 | 47 |
22 | 183 | 19107 | 104.4 | 43 |
23 | 132 | 17261 | 130.8 | 47 |
1日 | 2860 | 298097 | 104.2 | 46 |
タスクバー(6), 水酸化ナトリウム(4), 森氏(7), 2月5日(4), 原田(5), 検収(3), マホト(5), COM(3), 実機(12), マイニング(10), ソル(7), 森(47), 少子(17), ビットコイン(12), ガイ(15), 2021年(12), リンチ(8), 卑屈(10), 少子化(26), オリンピック(36), 不具合(8), 女性差別(14), クンニ(11), マジレス(8), 子育て(28), ✋(8), 経費(7), アパート(11), テスト(22), 開催(17), 不(19), 投資(23), 会議(18), 謝罪(17), 資産(13), 回避(11)
■森の叩かれぶりを見てるとアホらしいなあって /20210206223117(65), ■ /20210207085650(26), ■成功した小市民はどこに向かえばいいのか /20210206142933(20), ■Windowsのタスクバーを上にしてる /20210207143932(20), ■聴くと頭が悪くなる曲 /20210206182035(17), ■中止確定!東京五輪クソかるた ~2021年2月版~ /20210206230031(15), ■【求職】大学辞めて増田で就活します /20210207093448(15), ■付き合ったことがないやつを無意識に差別してくるクソども /20210207023511(15), ■かわいいと言われても反応に困る /20210207140252(14), ■実機テスト、するよね? /20210207131927(12), ■はてな民は自動車メーカーを舐めすぎじゃないか /20210206103725(11), ■2021年版・ド初心者向け仮想通貨投資の始め方 /20210207143934(11), ■独身税の何が悪いのかわからない /20210207180525(11), ■おじさんはいくら叩いてもいいという認識でいい? /20210207191757(11), ■1おくあったらなにする? /20210207140334(10), ■女の性欲 /20210207021742(9), ■最近の若者大人しすぎない? /20210207062052(9), ■森元首相の件に怒りを感じることが出来ない /20210207133707(9), ■任天堂に作ってほしくないゲーム /20210206172343(8), ■なんでみんな男女の平均寿命差に触れないの? /20210207091440(8), ■モラハラ家庭(カースト最底辺の母親)の愚痴がしんどい /20210207121121(8)
なにやらCOCOAの件で、きな臭いことになっているので、釘を刺しておきたいです。
これは長年の業界の慣習です。少なくとも90年代からずっとそうです。したがって何の問題もありません。
個々の企業は本質的に個々の企業のために動きます。そして資本主義の世の中ではカネが全てです。全ては顧客のためであり、そのソフトが社会的にどのような役割を果たしているのかは興味がありません。考えてはいけないことです。そして顧客とは私の会社に発注した会社のことをいうのであって、元請けや実際にそれを使う人のことは私たちには関係がありません。したがって何の問題もありません。
中抜き会社が何もやっていないわけではありません。一般的にいわゆるプログラミングに1ヶ月かかるとしたら、設計やすり合わせテストには、その5倍はかかります。仕様の文面をもらったり聞き取りをして、それを解釈して、私たちの仕様文面に落とし込む、そしてプログラムが納品されたらその検収書をチェックして、わたしたちの検収文面に落とし込む。プログラミング以上に手間がかかる作業です。極端な話ですがプログラミングがたとえ数行でも納品物はキングファイルになります。したがって何の問題もありません。
はっきりいって同じ規模の仕事なら、少なくとも1年、できれば3年ほしいところです。無理な短納期にしたのが問題の本質ではないかと確信します。
https://ssl4.eir-parts.net/doc/3930/yuho_pdf/S100IQ8D/00.pdf
この記事見てそういやはてなって上場してたなってIR情報見たら色々とやってて面白かった
はてなブログの有料プランの他はアフィリエイト広告がほとんどみたい
経緯がわからないけど一部のアドネットワークの接続が停止されていたが収益は堅調
BtoBストック型ビジネスとしてCMSである「はてなブログMedia」を展開
はてなブログMediaは企業がオウンドメディアを作成できるCMSだが
このCMSを採用したメディアが74件だったのが102件まで増えたとのこと
「受託サービス」とサーバ監視サービスの「Mackerel」など
Webマンガサービスに特化したマンガビューワ「GigaVIewer」を開発(受託でなく自社サービス?)
こちらは集英社など11サービスで搭載されWebマンガのデファクトを目指して売上は堅調
またKADOKAWAの依頼で「カクヨムの収益還元プラットフォーム」「魔法のiらんどのリニューアル」などを開発してすでに検収済み
Mackerelはエンジニアなら知ってると思うけどなんか堅調らしい
BSとかPLの読み方がわからんから今後はわからんが、はてブ以外にも色々やってるのがわかって面白かった
増田なんか多分数あるうちのサービスでIR的に結構どうでもいいんだろうなって感じがした
ということでおやすみなさい
エンタープライズITの世界を紹介する。これから業界に入る若者は参考にしてほしい。
エンタープライズのITはこんなツリー構造になっている。下層にいくほど枝分かれする。層の深さや枝分かれの多さはプロジェクトの金額による。このあたりの闇は増田でも多く語られている。たとえ天下のGAFAでも1次請けやIT部門の下に入る。昔はオラクルやIBMだったのがAWSやAzureに代わっただけで構造的には同じだ。
それではカネの流れと利益構造を説明していこう。増田のメインターゲットである下層から説明する。
この層はIT会社ではなく人材派遣会社といっていい。n次請けはn-1次請けに人材を派遣するので以下の構造がある。
例えば、月単価100万円の人を10人派遣すると売上は1,000万円になる。この売上を営業やコーポレートといった連中と社内で取り合うわけだ。だから給料を上げるには単価と作業時間を上げるしかない。
n次請けの営業はn-1次請けと単価を交渉する。単価は派遣対象のスペック(経歴書)で決まる。単価を上げるためのキーワードはだいたい決まっていて、チームリーダーとかクラウドとか入れておけばいい。あと、作業時間は無駄に多い方がいい。自動化で作業時間を減らすやつはバカだ。君の残業代は売上から出ている。
n次請けにいる人に告げる。さっさと転職しろ。AWSに転職したら給料3倍だ。
この層は人材プール会社になっている。大企業は資本金や信用調査などを満たせない零細企業と直接取引ができない。2次請けは大企業と零細企業の間に入り、需要に応じて人材を売る役割を果たす。あと、キチガイみたいなやつが入らないようにフィルタするとか、派遣されてきた人が突然バックれた時に代わりを探すことも大事な付加価値だ。
例えば、月単価50万円の人を80万円で紹介すると、売上は80万円、利益は30万円になる。給料を上げるには安い人材を高く売ることが重要だ。そのためには2次請け社員がチームリーダーとなり、n次請けの安い作業者でチームを作ればいい。作業者の人数を増やせば売上は伸びる。リーダーができないやつはクビだ。
2次請けにいる人に告げる。現職はいい待遇だと思っているだろうが、外の世界を見ろ。
この層は大企業だ。2次請けやハードソフトベンダを統合してシステムを納品する。一括請負契約の場合はリスクバッファの役割を負う。開発が炎上してもIT部門は痛みを負わない代わりに、マージンでガッポリ儲ける仕組みだ。
実際には、IT部門が出したRFPに対して工数を見積もり、価格を提示する。受注できたら開発に取り掛かり、納品と検収を終えたら売上が立つ、という流れになっている。コンペの場合は見積工数にかかわらず提案価格を大幅に安く出すこともある。また、受注してから売上が立つまで数年かかる場合もあるため、資本力が勝負だ。ハードウェアやパッケージ製品、クラウドを一緒に販売する場合もある。
給料を上げるには出世することだ。出世するには仕事を増やして安い人材を高く売る必要がある。
重要なのは流行りの商材でIT部門を釣って仕事を取ることだ。RPAやAIなどのバズワードがなぜ人気なのか理解してもらえただろうか。開発は2次請けに任せればいい。お前の単価はいくらかわかっているか?
1次請けにいる人に告げる。リストラに備えろ。潰しの効かない仕事を続けていると転職できなくなる。
IT部門は、ユーザ部門から受託した企画を具体化し、ベンダをコントロールしていくことが主な任務になる。あとは負債化したシステムの運用管理をやっていく。
IT部門はコストセンタなのでコスト削減が評価される。また、トラブルでシステムが止まると社内から批判を浴びるため品質管理が評価される。
負債化したシステムは細々とメンテしていくしかない。ハード保守が切れるタイミングで大規模更新を計画して実績をアピールだ。
ただし、IT部門はポストが限られているので出世するには社内政治が重要だ。出世の見込みがないなら転職しろ。
ユーザ部門は新しい企画を立てて経営層から承認をもらい、ITを使って収益を得ることが仕事だ。あるいは費用を削減することが仕事だ。
ユーザ部門はコンサル会社に企画書を作らせて、営業やマーケティングなどの他部門と要件を調整し、遅くて融通の利かないIT部門のケツを叩くことが任務だ。
だがよく考えてほしい。IT部門と多重下請のケツ叩きに無駄な時間を使うより、自分たちがベンダと組んで一緒に企画、開発、運用を進める方が効率的かもしれない。今日の企画を来週にリリースできたら最高ではないか。小さくリリースして学びを得て改善していく。
http://b.hatena.ne.jp/entry/s/headlines.yahoo.co.jp/hl?a=20190729-00000074-mai-sctch
このニュースがバズった後、ニュースにも出ていない問題が議会で追及されていたので、滋賀県議会のページ(令和元年9月定例会議(第9号~第15号)-09月30日-04号)をもとに、一部読みやすく編集してみた。