「システム開発」を含む日記 RSS

はてなキーワード: システム開発とは

2021-06-20

システム障害が起きると「現場を責めるのは間違い」っていう人いるけど

現場もろくでもないシステム開発したり運用してるんだから同罪でしょ

この「現場は悪くない上層部が悪い」っていう価値観の人って一定数いるけど

なんなんだろうね

2021-06-16

みずほのあれ

https://togetter.com/li/1731325

なんつか、構図COCOAと同じだよね。

ワンオフシステム開発運用はもはや経営のものと同一と言っても過言でないのに、経営陣はもはや何か得体の知れないものとして扱っていて、誰も触れようとしないんだよね。軽視されているとかいレベルじゃなく、無視

下手に問題解決に動こうもんなら揚げ足取られて気がついたら自分責任取らされて死ぬ解決させても評価されない。そんな現場で誰が利用者のことを考えるかね…

ウケる

2021-06-12

今までの尽力に対する感謝と、君への今後のアドバイス

https://anond.hatelabo.jp/20210610184501

文面からおそらく弊社の、しかも関わりのある事業部なのだろうと想像した。そういう意味ではまずは今までご苦労様。

その上で一言アドバイスさせてくれ。

自己紹介

まず自己紹介からしよう。私は主に公共向けのSEをしている部長相当職(社内ではある固有名詞で呼ばれている)だ。社内の製品は一通り把握している自負はあるので、よっぽどマイナーものでなければおそらく君のところの製品も触ったのではないだろうか。

社内の開発環境について

開発に必要があるなら申請を出せば普通に入手できるし、Git普通に使っている。正直なことを言おう。そんな小さいことで辞めたのか?と思ってしまった。35歳で主任(これもある固有名詞で呼ばれてたんじゃないか?)ということはそもそも開発者なんてフェーズはとっくに過ぎてマネージメントを任される頃のはず。これはたとえ製品開発の事業部だったとしてもそんなに変わらない。それなのにその視座の低さがとても気になったよ。概して若いコーダー顧客メリットが0であるような単なる自己満足としてGithubの利用やDockerを使いたがるが、悪いけどそのまま大人になってしまった感じを受けた。開発環境の優劣というのはそんな低レベルな話ではなく、上流工程での品質の作り込みがしっかり行われているかとか、品質管理KPIがしっかりされており、そのKPIに対するPDCAが回っているかとか、人月単価を適正に管理競争力のある製品を作る予算管理ができているかといったことのほうがよっぽど重要

年収について

弊社はあくまでも「ものづくり」「エンジニアリング」の会社であって、「コーダー」の会社ではない。そのためDockerだのGithubだのMavenだのといった要素技術に対してそんなに価値を認めてないんだよね。もちろんそういった技術で儲けようとしているWeb系の企業がたくさんあるけれど、年収を比べてみれば結局どっちの市場評価が高いのか、よくわかるんじゃないかな。「ものづくり」で大事なのはあくまでも顧客要求を満たすことで、それはDockerだのGithubだのMavenだのを使うことととは次元の違う話だし、市場価値が高いところにコミットしてそうでないところを適正に管理しているからこそその年収が出せるものだと思ったほうがいい。今の年収と同じ水準でモダン 笑な環境転職したじゃないか反論されそうだが、転職市場は前職の年収ベースになるので結局君の実力ではなく弊社の実力が評価されただけなんだよね。そこは謙虚になったほうがいいと思う。

君の失ったものと見えてないないもの

まずシステム開発は「ものづくり」ということが見えていない。「ものづくり」というのは単にコードを書くというだけでない(君はそこにフォーカスしすぎて、その環境の悪さだけが目についたように見えた)。市場要求に対して適切に答えてるのが命題であり、技術は単なる手段ということを忘れてはいけない。プログラミングというのは手段である技術のたった一要素に過ぎない。そういう徹底的な顧客志向日本メーカーは長いことやってきており、高い生産性を実現してきたし、社員にもその精神を学んでほしいという一心ビジネスを動かしている。だが、最近IT系企業は「ものづくり」ではなく技術目的にしているところが多いよね。MacGithubとか言ってる層は特にその気が強いと思うのだが、君は結局そこに行ってしまったようだ。

これからの行動の指針のアドバイス

以上を踏まえておじさんから一つだけアドバイス。今のWeb系がやっていることは所詮大昔の技術を再発明しているだけであり、本質的価値が薄いということ自覚した上で本当に顧客が欲しい物を作るということを忘れないでほしい。例えばDockerなんて大昔からLinuxが持っている機能の寄せ集めだし、Gihubなんて本質的にはファイル名に日付を管理するのと変わらない。弊社に関して言うと、AWSなんていってるけど所詮VMだし、弊社はハードウェアレベルでより高い技術を持っている。AI企業は専用AI個別案件ごとに作っているが、弊社は汎用AI世界で初めて開発した。でもそれらを積極的宣伝はしていない。なぜか?それらは単なる手段から。むしろお客様へのソリューションという形で宣伝していて、結局顧客ビジネスフォーカスしているんだよね。だからこそ利益が出せ、年収も高いというわけ。なので、再度いうが、本当に顧客が欲しい物を作るということを忘れないでほしい。

2021-06-11

平井大臣がNECに対して脅すよう指示したという朝日新聞報道について

朝日新聞記事より 平井大発言

https://www.asahi.com/articles/ASP6B73PZP67TIPE01M.html

デジタル庁はNECには死んでも発注しないんで、場合よっちゃ出入り禁止にしなきゃな。このオリンピックであまりぐちぐち言ったら完全に干すからね、一発遠藤おっちゃんあたりを脅しといた方がいいよ。どっかさ、象徴的に干すところを作らないとなめられちゃうからね。運が悪かったってことになるね。やるよ本気で。その、やる時は。払わないよNECには。基本的には。」

以下、平井大記者会見(令和3年6月11日)より

https://www.youtube.com/watch?v=8pYykq-C8Ug

----

平井大

一部、私自身の発言報道されているということに関して、私のほうから発言させていただきたいと思います

契約の変更によって、NECとの契約を解除したのは、同社が開発運用保守担当していた顔認証連携システムであり、海外から一般観客を想定した機能でありました。

海外から一般観客の受け入れを行わないとの方針となったこから、もともと契約事業遂行に影響を与える大きな環境変化があった場合は、協議を行い解決を図るという条項があり、それに基づいて受注者と協議合意したものだと考えています

今回のオリンピックアプリに関して言えば、すべてサービス提供が終了時点でお金を支払いするという請負契約という形になっています。ですからまだ現時点でも国が費用を払っているわけではなくて、フルスペックオリンピックを開催した場合にその費用はその終了時点で払うという、普通システム契約とは少し違う形態になっているということでございます

私自身としてはですね、国民血税をお預かりする立場として国民目線調達無駄をなくしていくという強い気持ちを持っておりまして、今回の契約見直しに関しても可能な限り契約金額圧縮するため、担当担当責任者には何度か打ち合わせを行っていろいろ指示を出したということだと思います

で、報道されている音声データについては、その中の一部ではないかと私思いますが、まあ誰に対してしゃべったかということで言いますと、まさに幹部中の幹部二人まあ10年来私が一緒に仕事をしてきた仲間でございますので、まああの非常にラフ表現になったなとは思います

表現はやっぱり不適当だなと思いますが、今後気を付けていきたいと思います

ただし私自身はその契約現場にいるわけではなく直接ベンダー契約について話すという立場ではありません。ですから、このような契約を進めるにあたっては担当者が強い気持ちを持っていないと、なかなかそのコストを削減するということはできません。それだけ今回の発注リスクがある発注でしたから、まあそのある意味金額も高いし、そういう状況の中で今回のそのいろいろなサービスを縮減するということですから、ここは国民立場になって物事をやっぱり考えるというのが私の一番のスタンスですので、やっぱりこの事業は各ベンダーさんにとっても大きな利益を出すというような類のものではないはずだという風に思っておりまして、そういう意味で強い覚悟国民立場になって交渉するということを幹部二人に強い口調で申し上げたことが、今回表現が不適当であったという風に思います

からは以上です。

質問朝日

改めてですけれども、やはりIT担当する大臣としてですね、業者に対する優越的地位にあると思うんですけれども、そちらにおいてですね、非常に大臣が内部で言ったことはいえかなりプレッシャーになるのではないかと思うんですけれども、その点はいかがでしょうか。

平井大

今までね、私自民党でもそのIT調達に関していろいろ今までも政府のいろんな問題点過去指摘してきた中で、どちらが優越的な立場にあるかというというのは皆さんこれ本当によくわからないケースのほうが多いですよ、実際。ですからある意味一社入札が多いであるとか金額が高止まりしているという指摘を受けるというのは、やはり政府発注能力がないということなんです。そういう流れの中で今回デジタル庁というものを創設して、自らがちゃんとその要件定義をできてそしてフェアな発注ができるようにしたいという思いですから、今のご質問に関してはですね、私はそのようには思っていないし、私自身がその企業に言っているわけではなくて、長年一緒に働いているスタッフ過去もいろいろそういう問題を私が指摘しながら自民党にいるときも一緒にやっていたメンバーに対しては、強い表現というか強い覚悟で臨まないと国民の望む結果にならないからということで、直接業者さんに話すということはないし、担当者も私の表現をそのまま相手に伝えるような方々では全くないので、それはもう10年一緒に仕事をしておりますから、私の極端な表現ぶりを受けて強い覚悟交渉なさったという風に思います

朝日

政府調達において業者が非常に強いということで大臣がこの任に、IT大臣として着かれていると思うんですけれども、やはり脅しておいたほうがいいなどという話はですね、乱暴という次元を超えているのではないかと思うんですけれども。

平井大

これね、要するに幹部二人に対して内部の会議で指示をした表現、だからその表現は不適当だという風に言っているじゃないですか。私は業者に対してそんなそのままそういう表現を使っているわけでもなくて、彼らも、要するに指示を受けた二人も、大臣はやっぱりここはなんとしてでも下げたいんだなという意味理解はしてもらったと思いますが、言い方は皆さん大人ですからその表現でやっているはずがなくて、ですから私の幹部職員に対する表現の仕方が不適当であったということは認めますが、対外的にそんなことを誰も業者の方に言っているわけでもなく、私はその指摘は当たらないと思います

朝日

わかりました。それじゃあ値下げに関しては大臣発言の影響はなかったという認識ですか。

平井大

値下げに対してというのは、誰かの発言金額が変わるというものではなく、要するに契約変更というのは両者の合意がどっかの時点で合理的にできてくるということで、それぞれ法律的にも問題のない契約に落ち着くということだと思います

朝日

しつこくて申し訳ないですが、再度確認しますが、交渉にあたっていた職員の方からですね、脅すようなやり取りがあったということはなかったと

平井大

え、なに?

朝日

その、交渉にあたっていた職員達が業者側を脅すような文言はなかったと。

平井大

普通ね、そういう大人契約でもう10年来やっているプロ中のプロの皆さんが、そんなことで金額が下がるなんて思っていませんよ。

朝日

わかりました。

質問毎日新聞

関連質問で、音声データを聞くとですね、デジタル庁はNECには死んでも発注しないんで、場合よっちゃ出入り禁止にしなきゃなとかですね、一発遠藤おっちゃんあたりを脅しておいたほうがいいよと、結構シリアスな口調で発言をされているんですけれども、そもそもこの辺の40秒50秒のデータを聞いていると、すごいNECを敵視しているように感じるんですけれども、これって交渉に入る前に発言をされているんですよね、例えば協議が不調になっていたからはっぱをかける意味で言ったのか

平井大

あのね、交渉の内容の金額とか途中経過っていうのはなかなか表に言えることではないんですよ。ないんですが、さっきもお話しましたが、その幹部二人に対してはですね、いままでも相当いろんな指示といいますか、10年来いろんな問題に取り組んできた仲ですので、私の言いぶりをそのまま受け取るような立場人間ではありません。そのうえで言いますと、NECさんとはですね、マイナンバーの顔認証であるとか、今まで実証実験もたくさん一緒にやらせていただいていますし、ほんとに国と一緒に顔認証いろんなところでも実装しておりますし、強い信頼関係でご協力をいただいているということは事実です。ですので、ある意味、国がこういう状況になっているときに、金額的なものも協力してくれるはずだという、長いお付き合いといいますか、国の実証実験等々、とか、マイナンバー等々でも大変な協力をいただいているということを考えれば、今回も協力をしていただけるのではないか。ただ、この話は音声データにならないとNECさんに対して伝わる話ではないので、今回こういうものが表に出てしまった以上、ある程度誤解のなきよう話す必要があるかもしれないなと今考えております

質問日経BP

契約の話なんですが、一般的にですね、リスク業者に負わせるということはですね、これリスクを考えてベンダーが値段が上がるという意味において、必ずしも長期的には金額を下げることにはならないのではないか、今回のようなリスクの事例に対して果たしてベンダーさんの契約ゼロにすることはふさわしいのかどうか、そのあたりのお考えをお伺いできますか。

平井大

システム発注にあたっては可能な限り仕様を確定し、開発期間を十分に確保することによって、コストっていうのは出てきますよね。今回の場合は、開発期間は異常に短いしかも、国家的大プロジェクトであるということで、結局すべて動かした後の結果が問われるという意味リスクという話をしました。

で、システム自体っていうものはそんなに難しいものを作っているわけでは今回ありません。ただ規模が大きいということと、要するに、多くの方々がフルスペックで参加されると来られるわけで、そういう意味では、大変、つまり要件が完全に固まっていないというところですね。そこのところがリスクということではないでしょうか。普通はこんな発注はないんですね、よくよく考えてみると。なかなかこのような形の発注というのは、こういうオリンピックみたいな時以外にこのような、それ以外はちょっとなかなかこういう発注というのはないと考えます。まあ、特異なケースの発注だと思います

日経BP

一般論としてはこういう環境の変化で起こった想定外契約見直しというのは、必ずしもベンダー側が責任を持つ(平井大臣:いいや違いますよ)、ような契約は必ずしも望ましいものではないと。

平井大

それはもうもちろんかかった費用とかそういうものに関しては、お支払いするんで、今回だって結局38億か、38億はお支払いするわけです。38億お支払いしてその範囲でやれることはやっていただくということなので。ただ、やっぱり会社っていうのは、売上計上したり、会社経営っていうものがあるわけじゃないですか、当初計上してた売り上げの半分になっちゃうわけですから、そういうのはリスクだと思います。損を被れなんていう話は一切しているわけじゃありませんから

日経BP

ごめんなさい、追加になるんですが、NECに関してはまあゼロになったということで、今回リスクを丸被りした形になるとは思うんですが。

平井大

というより、これ請負契約で、要するに海外に来る人たちの、要するに顔認証ということ自体を全部やめちゃったわけですから。ですよね。これ用に何か作ってくれという発注ではないので。いやこの話はさー、我々合意している話で、特段問題ないと思っているんですね。要するに合理的判断して両者がそう思ったからこの金額になっているということだと思います

日経BP

わかりました。あのちょっと追加で、念のためもしお伺いできれば、NECとの交渉はどういう形でNECは条件を飲んだ形になったのか。その経緯は、現場の方から

平井大

ただね、こういう交渉の経緯というものは、あまりオープンにすべきものとも思えないんですよね。各社の競争力に関わる問題でもあります。ですから、最終的に私は交渉現場に一切立ち会っておりませんけれども、交渉の経緯というようなことに関してはおそらくそれは説明できないんだと思います

質問朝日新聞

今の関連になるんですけれども、NECはですね、1月契約してから少なくとも5月31日までは人を貼り付けてきているわけですからゼロっていうのはちょっと極端ではないかな、という風に思うんですね。で、やっぱり大臣がおっしゃっているようにですね、契約をきちんと仕様を決めて、透明な契約をしていくっていうのがデジタル庁の大きな狙いの一つだと私も思ってそれは素晴らしいことだと思っているんですけれども、その趣旨からいってどうなのかというあたりをお聞かせいただけますか。

平井大

かかった費用があってそれを国に請求したいということであれば、請求していただければいいんです。今回は要するにゼロでいいということだからゼロなんですねということです。

朝日新聞

それが交渉事で決まってくるというあたりがですね、ちょっと透明性があるのかなと。でさっきの質問もあったように、そういうことになってくると、国との契約をするとですね、どうしても高値の、要するにリスクに備えておかないといけないという発想も出てくるんじゃないかなという風に。

平井大

あの普通発注ではですね、もっと明確な要件定義をして発注をするのでそういうことは起きないと考えます

特にデジタル庁の場合は、発注、今までは外部の方に要件定義まで発注するっていうまあ丸投げと言われる批判をさんざん受けてきていましたが、我々はそれをやる気はないので、きっちりと要件定義こちらでやったうえで発注すると。ですからデジタル庁発足後はこのような発注絶対にしたくないという風に考えています

朝日新聞

要するに、もともとの契約問題があったというご認識という

平井大

というかね、問題があったというよりも、こういう異常な事態システム開発というものに関して言えば、なかなか普通出来ることではありません。で、今回、オリンピック自体がどの規模でやるのか、もしかしたらやらないかもしれないというようなマスコミ報道を思う方もいらっしゃったと思います

そのような中で事業を受けるということですので、通常の発注とは違うと、いう風には考えますが、問題があったかどうかということでいえば、やむを得なかったのではないかと思います

質問テレビ朝日

全体的な確認なんですけれども、先ほど大臣10年来の付き合いのある幹部二人に対する強いざっくばらんな口調で発言があったということだったんですけれども、会議自体には、他にもたくさん出席されていた方がいるかと思います会議自体がどういう状況でどういう雰囲気の中で行われたのかっていうのを大臣のほうから説明をいただけますか。

平井大

それよくわからないんですよね、正直言って。ただ、私もですね、本件に関して普通大臣がこんな契約の内容に口出すことはないんですけれども、特に国民の関心事でもあるし、まあ野党の皆さんから高いという指摘もあるのでここはまあ幹部檄を飛ばすということで、二人はおりましたので、現場で直接話をしました。

ただその時の会議の音声がどこまで共有されているとかそういうことを私知らないので、今お答えしようがありません。

----

2021-06-01

anond:20210601152019

増田

この度は、弊社社員の不始末によりお客様に多大なるご迷惑をお掛けし慙愧に堪えません。

お詫びとして本システム開発者のハメ撮り動画をお送りさせていただきたく存じます

つきましてはこちらにお名前とご住所をご記入ください。

2021-05-26

東京五輪について新型コロナ感染症ばかり気にしているが

暑さ対策とか、ボランティア不足とか、解決したんだっけ?

あと、ちょっと前までシステム開発要員も募集してたけど、完成する目処は立っているの?

2021-05-21

anond:20210113102650

どうして製造業アメリカほど高度にならなかったのか←ダウト民生用製造業日本一強やろ。スイッチ全員買えた?トヨタ車買ってないの?軍事産業につかうロケットミサイルの話なら軍事産業宇宙産業ほぼほぼ存在しないから無理ですけどね

電子計測機器アメリカから買ってきたものを使って、国産できなかった←ダウト島津製作所田中さんガスクロマトグラフィーなど。

シミュレーションソフト国産できなかった←ダウト電車でGO

大規模なシステム開発用のモデルシミュレーションソフト国産できなかった←ダウト。大規模ならソフトじゃなくてハード問題だろ。

技術情報の発信するメディアが弱いのか←ダウト。タダでよませてたらそれこそ中国が全部もっていくだろ

2021-05-20

政治案件システム開発で最優先されるのは何か

それは、お偉いさんのメンツを守ること。

それさえ出来れば、ポンコツシステムで人が1万人死のうが詐欺に遭おうが現場が大混乱になろうがどうでもいい。

メンツを守るのは何かというと、納期遵守。

それが政治案件というものだ。

ワクチン予約システム朝日毎日が名指しで悪とされたのは、防衛省竹中平蔵メンツを丸潰ししたからだ。日経が名指しされていないのは、報道の工夫でメンツしまでには至らなかったからだ。

お偉いさんのメンツが最優先。何が正しいかではなく、誰が正しいか?何のためではなく、誰のためか?

そういう考え方が出来ない連中は政治案件に関わらないほうがいい。先日バズった秘書検定合格出来るような頭の柔軟さが求められる。

anond:20210519214122

一年から」論もシステム開発という面では若干事後諸葛亮なんだよな。自治体主体での接種で厚労省は進めてるので、国主体の接種を想定した予約システム開発発注できない。そこを動かせ、というのはもはやシステムより業務問題だし。

一年から」論で唯一いえるのは、最終的な接種完了自体は国も把握する必要があるので、接種券番号の発番は国が国民に割り当てる、ぐらいかなぁ。接種券番号は自治体コード+自治体内で一意な10桁だけど、後半の10桁で例え1桁チェックデジット入れても国民全員に一意な数振れるので。ただこれも国外から帰国や出生による番号の追加もあり得るので、結構業務がめんどくさくなるよな。

2021-05-19

anond:20210519154007

その通りだが、バグがあったら何が起きるかと言うのは設計段階で考慮する

バグがあったら他人お金が盗めてしまうとか命に係わるというものであれば徹底的に設計段階で潰すし、仮にバグがあってもそういう悪影響が極力出ない、かつ万が一出てもリカバリーできるように設計し、その通りに実装出来ていることをテスト確認する

そうでなければそれなりの設計レベルにとどめる。バグによる悪影響を何処まで見るかと言う話だ

例えば書籍だったらたまに乱丁があるが乱丁ゼロにするような対処は行わず乱丁本を取り換えるというアナログ運用で済ます

システム開発はそういうもの

2021-05-18

anond:20210518231515

悪かったのはシンプルで、国が国民単位の接種券番号を採番するなり、自治体に事前に採番させた上で国に提出させる運用としなかったこと。去年の自治体での接種業務フローを考える段階や。

逆に大規模接種の決定~システム開発運用開始のタイミングで出来ることないわ。それを分かってるので、名のある有識者はみんなそこの仕様については黙ってる。

anond:20210518195624

バイオレンスのもの

あんなところにいたら気が狂う。

システム開発は社内開発に限るわ。

地方自治体システム開発

ワクチン予約の一件で思い出した。箇条書きにする。


なんか他にもたくさんあるけど、身体拒否してきたので止めとく。誰か続き書いて。

anond:20210518093310

接種番号の形式は、遅くとも去年の12月には定められていて、その時点でこのシステムはつくられる予定さえなかった。

https://www.mhlw.go.jp/content/000714248.pdf

なので、それも無理よ。

なんなら、このシステム開発開始時点で、券面印刷終わって送付してたろうし。

やるなら、接種番号と、対応する仮パスワード自治体入力させて、別途送付するとかだけど、

かなりの工数と混乱を生むだろうね

「まともな予約システム作らせるのなんて楽勝」と言ってる奴は自分が作れるの?

おっとおっと言ってるのは「予約システムを作れ」の方じゃねえぜ?

「予約システムを作らせる」の方だ。

まりは、「役所書類としての、システム開発の仕様書政府の思いつきにより超速攻で提出)」だからな?

出来るか?

仕様書wwwだってよwwww」「帰ってママおっぱいでも吸ってな」「マニュアル通りにやっていますというのはアホの言うことだ!」なーんてゲラゲラ笑いたいなら勝手にすりゃいいが、それを口にするならもうこの案件で何か言う権利は無くなるぜ?

役所税金でやる仕事ってのはつまりはそういう事だからな。

それともなにかい

「形にさえなりゃいいんだ」「仕様書なんて適当でいい」「意思決定なんて滅茶苦茶でいい」「会計監査だってコロナだったからで通っちまえばいいんだ」かい

マジかい

俺はそんなの嫌だぜ?

車検に出した車に対して「いい感じにしときましたんで、まあいい感じっすからこんな感じで料金くださいよ。マジいい感じに仕上がってるんで」と言われたらよぉ……俺はもうそんな会社は使わねえぜ?

国が税金でやってる仕事なんだから意思決定クレバーじゃねえと。

そうなるとやっぱマトモな仕様書必要になるわけだが、自民党だか厚生労働省だかが支持率低下回避のために適当に吹いた戯言の尻ぬぐいで速攻で仕様書作れって言われても俺なら無理だね。

そもそも何を作らせたいんですか」って聞いちまうよ。

どうせ上の奴らは「いい感じにだよ。馬鹿かテメーは」って頭の悪いヤクザみたいなこと言うんだろうよ。

そんな中でとにかく納期に間に合わせるために作ったら、そりゃクソみたいなもんを提出することになるだろうよ。

そしてそれを見て作らされた会社も当然のように「え?無理?もうゴミ出すわ」ってゴミ出してきて、それ受け取る側も「もういいわ知らん」でゴミを通すんだろうな。

でもそれを攻めるのは俺には出来ねえわ。

上がゴミなのが全て悪いんだからよ。

まり俺達が真に怒るべきは作るのに関わったチンケな雇われ公務員なんかじゃなくて、その裏で糸を引いた竹中平蔵ってわけ。

体重箱の隅をつつく奴のせい

新型コロナワクチン接種もさ、政府優先順位と余った時の優先順位ちゃんと示せばいいのに現場任せ。

でもやらない理由もわかる。野党とかの重箱の隅つつく奴らのせい。「○○の時はどうするんですか?」って奴。

システム開発とかでもよくある。疑問として提示するのはとても良いし、専門分野からの指摘は時に大きな不具合発見する手立てにもなる。でも、そんなのはほんの一握り。

大半は気にしなくてもいいレベル些細な内容を指摘してご満悦した上で、それがハッキリしないと決して先に進ませないようにする。大概無能クズ。でも決済権とか持ってるバブルの粗大ごみ

まずは医療従事者、次に老人、余ったら公務員、それでも余ったら老人以外。優先すべきは公平性よりワクチンの期限。

ほんと数%レベルイレギュラーとか現状気にしても仕方ないでしょ。それこそワクチン副反応死ぬ確率気にするレベル。だから与党支持率が下がっても野党支持率も上がらないし、ゆたぽん父親税金無駄使いしようとするんだよ。これじゃ誰も選挙行かないよね。

2021-05-17

ワクチン予約のシステム納期ありきのクソプロジェクトあるあるすぎ

https://anond.hatelabo.jp/20210517201151

あれさ、少なくとも東京会場側のサイトは、最初ボタンに「認証」って書いてあんだよね。

端的に言って、認証も何もしてないんだから嘘なんだよね。

んで、取れる手立てはいくつもあると思うんだけどさ、

  1. ドメインについて(なんでmrso.jpドメインなのよ、厚労省ドメインじゃだめなんか)
  2. 市区町村コードについて(6桁だけど、これは既知の情報無効な番号は弾ける)
  3. 誕生日について(なんで1歳でも予約できんだよ、これは後述するが弾いてるものもある)
  4. 一番下のコピーライトについて(自衛隊東京 予約システムというタイトルなら、一番下にも入れとけよ)

最初に書いとくと、できるチェックはしてるんだよ。

例えば、「現在入力桁数:4桁」みたいなチェックはしてんだよ。これはわかりやすい。頑張ってる。

んでな、2月31日みたいな存在しない日付についてはエラーになってる。

からエラー画面を見せないっていうんでもない。

入力された内容に誤りがあります入力内容をご確認下さい。」ってちゃんとわかりやすくでるんだよ。

でも、令和2年生まれとかが予約画面に進めるんだよね。そこは誕生年で弾けって。

まあ、割と無理やりな感じでライセンス表記もさせてるからさ、たぶんこれ、コード書いてるの1人とか2人とかじゃねえの?

https://www.vaccine.mrso.jp/js/app.js.LICENSE.txt

何が言いたいかって言うとさ、これって、納期がクソなシステム開発のあるあるじゃね?

ドメインどうするとかさ、仕様に至る前の段階の話じゃん。何の調整もされてないんじゃないのこれ。

年月日で、65歳未満が予約する際にはエラーを出して弾くようにするとかさ、こんなん何人かのチームでやってりゃ間違いなく誰か指摘するだろ。

「これって、65歳以上の方が対象ですよね?最初登録時に弾いたほうが良くないですか?」みたいなさ。

「これ、XXXX理由で接種券番号の仕様がもらえないのはわかりましたけど、市区町村コードは既知ですよね?」とかさ。

まり、「ああもう何言っても無駄だわ余計なこと言うとこれは俺の責任にされて俺の会社仕事になるわ言われたことだけやるわ」って状態じゃん。

市区町村コードPDFだってさ、珍しくもこれちゃんコピペできるPDFじゃん。そのチェックもしてないんだぜ。

https://www.soumu.go.jp/main_content/000730855.pdf

(つまり、桁数が分かるようにせよとか、桁数があってるかのチェックをせよ、みたいなのは仕様に書いてあったか言われたんじゃねーの)

(そして、市区町村コードから市区町村を引いて画面に表示せよ、とは仕様に書いてなかった)

こんなん、あるあるすぎて現場に同情する。

どう考えても調整をする人間がまともに調整して、まともな権限持ってる人間仕様を詰める時間で2日もあって、プロトタイプ作ってレビューして確認して、テストしてで、仕様が固まってて一ヶ月もあったら絶対できるやつじゃん。もっと納期でも仕様が固まってりゃできるやつ居るだろ絶対

(イキったTwitterなら(仕様が固まってりゃ)半日あったら実装できて、3日もあったら試験も終わる、とかいうやつ見つかるぜこれ)

まり、できてないのは「仕様確認して、まともな仕様を練る」時間がないから。

あとこれ、全スルーしてるから当日落ちなかったんじゃないんだよね。

めんどいから詳細言わないけど、「キャンセルできるようには作ってある」んだよね。ちゃん登録はしてるし、登録情報とのチェックはしてる。キャパのチェックもしてるし。(既報の情報ちょっと変えると誰でも確認できる)

個人的には、たぶん1人がコーディング、1人がデザイン、1人がインフラ兼QAって3人位のチームで3日くらいでゴリゴリ作ったんだと思うけどな。

この仕様グダグダっぷり(ドメイン名とかを見ると明らかに関係者間で整理、調整がなされていない)みるに、きっちり落ちずにスケールもしくはピーク負荷読みきったのは天晴なんじゃねえのかな。訴えられない範囲内での仕事はきちんとしているという意味で。

広報的にも多分誰も何の権限もなく何の調整もされてないだろ。

またあっちこっちでテキトーな事言う広報通してない発言がしばらく出るんじゃねえの。

もうあれだと思うな。

建築基準法みたいな法律作って縛るのが早いと思うわ。そういう法律あるとその法律には従って発注するから

まあ実際の橋作るのですら適当情報発注かけやがるからな。

(なお、ブコメにもよくいるけど役所との契約は全国から募らずに、割と地元に金を落とすかどうかって観点ポイントになったりするから、今から似たよーなシステムを土日に作って壊してして慣れといて地方契約握ってそうなIT屋にあたりつけとくと、またぞろ色んな理由パンピー向けの予約システムがそこここで発注かかるからリモートで曾々々孫受けとかでお仕事が受注できる可能性が微レ存

anond:20210517233340

少なくともこの件においては「簡単アプリ」じゃないからだよ。

「内部に突き合わせるためのデータさえ揃っているなり受け取れれば」あるいは「データの有無を他システム自治体システム宛)にAPI介して照会できれば」経験あるシステム開発者ならだれでも設計できるぐらいに単純だけど、それがないか簡単じゃなくなっている。

自分簡単に出来そうなことで、でもそうなっていない場合はたいていは見えていない制約事項なり要件があると思ったほうがいい。自分他者が「簡単ことなのにできない」と思わないためには。

2021-05-13

anond:20210513092742

情報ありがとう

ワイの意見としては、どの自治体も9割方にたようなことやってんやから

それらを統合して、その分のリソース

本当に必要ローカルルール用のシステム開発に割けるんじゃないか、って話よね。

1割は根本的にローカルしか対応できんから

9割もローカルでやる、っていう正当性にはならんやね。

2021-04-24

anond:20210423234432

SIer年功序列だよ。中の人になって長いので、その理由について書いておく。

理由

SIerは、成果を評価するための「見る目」を持っておらず、持つ理由もないから。

おっと「お前の居酒屋でのくだ巻きなんか聞きたくねーんだよ」と言われないように、少し背景を書いておく。

業務内容の比較が難しい

SIerはざっくりいうと、IT技術について、色んな会社からアウトソーシング業務を請ける会社だ。流石にそれは理解しているよね。

では、例えばこの2人のどちらの評価を高くすべきだと思う?

「前者」がいい?単にプロジェクト管理担当がうまくやっただけじゃない?

後者」がいい?その技術は今後稼げるの?

異種格闘技戦のように、せめて直接対決すれば評価もできようが、直接評価する機会は基本的にない。

これはプロジェクトの中のメンバー評価でも、ここまで極端ではないが同じようなことが言える。

DBスペシャリストWEBアプリプログラマーのどちらをどう評価する?という話が出てくる。

SIer製品開発で稼ぐ企業ではない

WEBベンチャーとかはなんでスター技術者に高給を払うの?」という疑問があるかもしれない。

自社製品、自社サービスを開発する企業のうち一部は、技術力が

となる。「人への投資=売り物への投資」になるケースが生じうるわけだ。

雑に言うと、

技術力不足でしょぼいアプリを作ってしまい、会社がまるっと倒産するぐらいなら、

技術力が優れた年収1千万人間数人雇うぐらい安い、というケースも有りうるということ。

一方で、SIerは、

という「人売り」ビジネスだ。

大規模な受託案件も、詰まるところは「人売り」の比率が大きい。

商材としてみた人間は、大して投資せずとも莫大な売上を立てることができ、際立って優秀だ。

必要になれば、下請けから引っ張ってくれば良い。

しかも単価も月数十万〜と、超高額である

人の「売り買い」であれば、かなり安定して利益が出る。

からビジネスとなったら、手堅く稼ぎの大きい「人売り」がSIer実態なのである

(「人売り」がチートすぎて、まともな製品開発が割に合わなさすぎる、というのが日本IT業界課題、と見ることも出来る)

一部のWEBベンチャー技術力にカネを払うようになったということ自体、新しい流れだと思ったほうが良い。

他業種を含めて、技術力を評価してお金を払うことは、日本では当たり前のことではなかった。

年功序列給料総額を抑えるため

不動産営業保険営業だとの世界では、売上成績トップクラスになると、若くとも超高額の収入を得ているケースが散見される。

営業担当者の能力が、明らかに売上と直結しているからだ。

一方、SIerはどうかというと、「人を売る」商売であるだけでなく、よりチームワークが求められる。

営業一人でもプロマネ一人でもエース技術者一人でも売上は立たない。

そのため、ある程度一人ひとりのメンバー評価し、報酬の分配を行う必要がある。

さて、年功序列の良いところは、給料を抑えられるというところにある。

一定の期間忠誠心を示し、かつそこそこ以上の成果を残した社員に対して、昇格で報いることがポイント金銭ではなく)。

これにより、長く所属するほど得、となるので、短期的な金銭報酬我慢させることが可能になる。

実際には、世代ごとに社員が分断されているため、40代以降になった後、

稼げなくなったタイミングリストラを行うことで、先延ばしした支払いまで含めて抑制することが出来る。

「若手が優秀」であれば、なおのこと年功序列給与総額を抑え込みにかかるのが、企業としては合理的選択なのである

最後

情報工学の院卒のキャリアSIerに来てしまったとして、この現状にどうお付き合いすべきか。

悩ましいのは、このひとのレベル。見たところ、学歴はあるとしてもそこまで技術力があるように読み取れないんだよね。。。

ひとまとまりアプリシステム自分で作れるレベルなら会社出ろと言えるんだけど、新人研修課題をあっさり解けるという程度のレベルだと、早い人には1〜2年位で実力的に追いつかれちゃう、という現実があるよ。

大企業新人は、飲み込みが早いので、あまり舐めないほうが良いです。

自分なら・・・

という考えで行くかな。転職するかどうかは、その後考える。

anond:20210424153352

そういう人は完全にSI向いてると思うんだけど、システムがわからない人が要件定義した結果糞システムができあがるのが日本システム開発の問題なので、プログラミング自体は細かいスキルなのでどうでもよいけど、サーバーとかネットワークとかクラウドとかシステム関連の技術に全く興味を持てないのであれば、せっかく優秀な頭脳日本のために活かすという観点ではやめておいて欲しいかなと思う

anond:20210423234432

自分一社目がまさにそんな会社だったのでガチアドバイスを。

もう 20 年以上前になるが本当に状況が似ていて、メーカー系のグループ会社2000 人規模の SIer親会社仕事ばかり、新卒100 人超、コーディングはしない、ビジネスマナーから始まる超絶ホワイト研修半年、などなど。

ちなみに言い当てると、月収が 22 万程度で、6月には寸志が 10 万ほど出る。年功序列で毎年少しずつ給与が上がるが、40 歳で課長、50 歳で部長になっても夢のある金額にはならない。そもそも上には謎の名ばかり役職がもりもりあって、部下無し管理職すらいる、そんな感じじゃない?

自分場合その会社就職したのは安定感を求めて、ではなく「この業界にいてどこの仕事が一番自分に合っているか俯瞰して見たいから」だった。ネットで調べたりまあ卒業生に話を聞いたりとかしたところで、学生身分では絶対に見えない部分があるという確信があったので、一社目は言わば仮面浪人気分で、二社目で本気の就職をするつもりでそもそも入った。それを目的とすると、大手 (あるいは中堅) SIer というのはとても良い立場で、うっかり壮絶ブラック職場を引く事も無く、ちっちゃなベンチャー井の中の蛙になる事も無く、業界全体を俯瞰し、どこにどんな仕事があるか、何を避けるべきか、その中で自分がやりたい事は何か、自分がやりたい仕事はどこにあるか、などを見ることが出来る。

結局二年半ほどその会社には勤めて、大手の何が駄目か、何が良いかを学び、駄目なところを一応変えようとしてみたりもして (*)、その後、Web 系の自社サービスをやっている小さなベンチャー企業プログラマとして転職をした。この初めての転職の時点では「何を避けるべきか」「何を優先すべきか」などが二年半の経験で明確になっていたので、面接時にそれらをちゃん質問する事が出来た。また「面接官のずるいムーブ」も的確に見抜いて、会社から選ばれると同時に会社を選ぶ立場面接に臨みとても良い会社を引くことが出来た。

本気の就職をした二社目では、今も交流が続き師と仰ぐ素晴らしい上司に恵まれて、システム開発イロハから学ぶことが出来たし、五社目になった今でも時に一社目の経験が ── 避けるべき事例としてではあるものの ── 役に立っているので、遠回りでは無くあれは必要な二年半だったと自信を持って言える。

ただ技術的な知識を学び力を付けるという意味においては、一社目は全く役に立たなかったと言って良い。その点については自分自身担保する必要があるけれど「安定感は会社に与えられるものではないです。自身技術力が担保するものです。」と言い切る増田にあれこれ言うのは野暮だろう。

以上を踏まえて、合計 5 社、足かけ 21 年 IT 業界で働き続け、転職スキルアップを契機にやれる事や給与を増やし、今なお現役のプログラマとして外資系 IT 企業で日々コードを書いている自分としては、1 ヶ月で判断して転職してしまうのは勿体ないよ、と言うアドバイスを送りたい。今の立場を最大限に生かして業界知識を蓄え数年後の転職につなげるのは、増田人生にとって大きなプラスになりうるはずだ。

(*) 日替わりで誰かしゃべる部全体向けの朝礼で、根回しなどもちろん無く、今の会社の仕組みの何が駄目か、どうしたら良くなるかを提案したところ、後で直属の課長から呼び出され「お前、部長から呼び出されるところだったぞ。おれが代わりに謝っておいたやったからな。」などと謎の恩を売られ色々と察した思い出。

2021-04-09

システム開発メタファー弱者男性論を考える

物事は違う角度から見ると色々と発見があるものだ。

本稿では弱者男性論をシステム開発メタファーで捉えることで凝り固まった見方をほぐす事を目的とする。(特にはてなにはシステム開発に親しみ深い人も多い筈だ)

特にそれが「解決策なしの問題化であることをまずは示したい。

解決策の不在は問題の不在を意味しない

弱者男性論に対する反応を見ていると、弱者の訴えや社会的問題化と、解決策の提示がセットだと思っている様な反応に出くわすことが多い。

「つまりあてがえ論でしょ?」と言う早とちりが頻出するのもこのせいだろう。「結局何が欲しいの?」「どうしたら救われるの?」と言った反応もよく見られた。

酷いものだと「弱者男性問題解決できない、だから問題ではないのだ」と言わんばかりのコメントも見られた。

例えば以下のブコメ欄でも、(比較的穏当なものもあるものの)一足飛びに解決の困難さに言及し「無理だ」「意味が無い」と早々に結論付けてしまう様なコメントが多い。(増田解決策に言及していないにも拘らず、だ)

https://b.hatena.ne.jp/entry/s/anond.hatelabo.jp/20210408101204

 

しかしよく考えてみて欲しい、システム開発を行う際、例えばバグ票を起票する時に「解決策」を書くだろうか?それは必須だろうか?

そう、システム開発メタファーで考えた途端、この問題に対する視界は目薬を差したようにクリアになる。

そもそも解決策」は必須ではないのだ。まずはバグを報告する事、問題問題化する事、必要なのはそれである

弱者男性にまつわる問題実存的だとか解決困難だとか、まずは考えなくていい、まずは問題化する事、解決策に頭をひねるのはその後である

急いで解決策を出そうとするから「あてがえ論」なんて奇論が出てくる、そんな事をする位なら、解決策はまず考えずに問題化だけしておけばいい。

解決策が無い事は、問題が無い事を意味する訳では無いのだから

 

解決策不在の不快

しかし「問題解決策はセット」と人々が捉えたがる事には理由がある。単純に不快なのだ

解決策の見つからない問題、というのは世の中当たり前にいくらでも存在するが、そうした問題意識し続けるのは不快だ。

システム開発においてタスクバグ等の起票はそのような不快さを問題解決モチベーションへと変換する方法論でもある訳だが、当然それは社会問題にも応用できる。

そしてそうした社会問題に対する反応も、弱者男性問題に限った話では無い。

最近では車いす利用者乗車拒否問題で顕著だが、問題を提起した人には解決策の提示を求める声やそのジャッジが押し寄せる事に成る

仮にもし、件の問題に対してJR側に取れる有効解決策が無かったとしても、それは問題が無い事を意味するだろうか?

当然NOである解決策が見つからくても問題存在するし、その解決策を考えるのは問題提起側だけの義務ではない。社会全体で考えるべき事だ。

社会問題を目のまえに吊るされるのは不快だろう、解決策が見当たらないなら猶更だ、けれどもそれは必要不快さであり、性急に解決策を求めて「無理だ」と結論付けるべきではない。

 

未来アップデート、と考えて見る

しかしそうは言っても、女性差別等の差別の方が問題だし、リソースは有限だ、解決策の見当たらない問題無視するしかない」と思う人も居ると思う。

そういう人には、弱者男性問題は今から未来に求められる事になるアップデート、だと考えて見る事をおすすめする。

現在社会バージョンが2.10ぐらいだとしよう。

例えばフェミニズムはこれを女性差別偏見解決した3.10まで持っていこうとしている。

そして3.10から更に弱者男性問題も(今はまだ誰も思いついていない方法で)解決した4.15があると考えて見る。

フェミニズムのやりたい事は2.10→3.10アップデートだ。

そしてその延長線上には3.10→4.15のアップデートがある。

どうせいつか求められる事に成るアップデートなのだ。(時が進めば3.10も「古臭い価値観」に成ってしまう)

「2.10→4.15のアップデート飛ばしすぎだ、リソースが足りない」という意見は分かる部分も有る。しかしだからこそ、来たる3.10→4.15のアップデートに備えて、「弱者男性問題」というバグ票を起票だけしておくのはどうだろうか?

3.10→4.15のアップデートはまだ未来の話かも知れない、しかしその問題を今から捉えておく事は出来るし、早めに起票しておく事にリスクは無い筈だ。

 

今はまだ弱者男性問題解決したり、彼らを救う有効方法は無いかもしれない、

けれどもそれを問題だと今から認識し、問題化しておく事は未来アップデートの為に有益なはずだ。

2021-04-03

anond:20210403100336

要はよく言う「年度末だから予算使い切らなきゃ! 次年度予算が少なくなる!」が公会計は強烈なんや各部署がそれなので「システム開発必要で期間が2年かかります耐用年数は5年でその利用を見込んでるので、支払のため再来年度は予算を増額で~」というと民間企業なら「実質5年分だね」として分割して費用を計上するので払う現金があれば通る(複式簿記発生主義減価償却)が、公会計だと「再来年に計上だね」(単式簿記現金主義)となり、利用部署のその年度の予算増額が必要になる。ただ歳入は基本的に限られてる(税金)し、赤字にできない(いわゆる赤字国債は発行する際の条件があって、システム開発は含まれない)各部署の予算使い切りもあるので通りづらいんや。トップダウン(知事なり内閣)があればまた変わるけどな。

なんかここ数年変えたい!と言ってる人も総務省やら知事によく見るので、状況は既に変わってるのかもしれんが。

anond:20210403094614

一つだけ言っておくと、デ通サはライフサイクルコストは高いで。SaaSPaaSと違って、新規に自社・自治体専用にスクラッチで開発するのに使ってる間は必ず相応の費用がかかるし(メンテナンス費用というわけではなく、開発費も乗っかった月額で)。

民間企業システム導入で使うにはメリットそこまで大きくない。固定資産に計上されないので、減価償却せずにすむぐらい。公会計予算の繰り越しがしづらかったり複数年度(システム開発期間)にまたがった高額の予算獲得がしづいから、必要とされるだけや。

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