「ベンダ」を含む日記 RSS

はてなキーワード: ベンダとは

2020-10-03

[]2020年10月2日金曜日増田

時間記事文字数文字数平均文字数中央値
0013623396172.038.5
01607379123.063.5
02153267217.857
0393920435.677
04112211201.041
0562611435.237.5
06171777104.544
07222693122.448
08656612101.738
09919820107.948
102081852689.138.5
111741594991.745.5
121611485092.238
1310617425164.433
14119858372.140
151601279380.038
1611513576118.141
1713014387110.744.5
181431182982.737
199613986145.745
2011914844124.736
2116216570102.339
2215517593113.537
2315747783304.453
1日2437302380124.141

本日の急増単語 ()内の数字単語が含まれ記事

日本学術会議(13), 学問の自由(5), 砂嵐(3), フェイルオーバー(3), ナスダック(3), 東証(22), ぐぎ(5), ベンダ(4), アイコラ(4), PostgreSQL(3), CIO(3), 滋賀県民(3), 長男(11), スパム(23), 子作り(10), 産め(8), post(14), 1%(8), 産ま(13), 再婚(6), 毒親(18), ユーチューバー(6), トランプ(19), 産む(14), 名誉(10), 学者(11), 京都(14), 弟(12), m(14), 子育て(20), 会議(15), 出産(19), 育て(22), 障害(23), 離婚(21), 育っ(15), 完璧(13), 土地(12)

頻出トラックバック先 ()内の数字は被トラックバック件数

子供作るときどんな覚悟だった? /20201001170719(60), ■取り返しのつかない人間職場に来た /20201002023509(30), ■滋賀県って可哀想だよな /20201002002113(28), ■ストレスが溜まると配偶者を虐めてしまう /20201001091449(11), ■俺は男だが(こう書いてもきっと女扱いされる)、増田原住民は女に厳しい /20201002151539(10), ■日本人について(真剣な話) /20201001124407(10), ■東証システム障害と同時刻に発生したごく小規模な障害との戦い /20201002003926(9), ■東証障害について東証従業員立場から /20201001221611(8), ■モテない4年間だった /20201001182448(8), ■そこそこ儲けてるイケメンにどう勝てばいいの? /20201002210238(6), ■嫁がありとあらゆるメニューに隙あらば餡を混入しようとする /20201002101427(6), ■世界はそれぞれにあって、それぞれの苦悩に声を上げればいい /20201002132507(6), ■ITエンジニア東証CIO賛美がマジで気持ち悪すぎる /20201002175434(6), (タイトル不明) /20091002221208(6), ■anond20201002103921 /20201002104059(5), ■anond20201001170719 /20201002105043(5), ■ /20201002204549(5), ■同性の恋人がめちゃくちゃ可愛いのでノロケを聞いてほしい /20201002012613(5), ■自宅で首吊りできる場所は案外無い /20201002174148(5), ■29歳高卒フリーターSES就職することを決意 /20201002205304(5), ■深夜の増田良すぎる /20201002015239(5), ■セックス茶化すな /20201002095024(5), ■ /20201002184044(5), ■はてブって左に偏りすぎじゃない? /20201002103727(5)

2020-10-02

anond:20201002003926

5GHz帯だと、国内ベンダしか対応してない感じの5.6GHz帯しか屋外利用が許可されてないんだけど、屋内に設置した機器同士で屋外を通る形で通信するのはどうなんだろうね?

問題本質を考えたらNGなんだろうけど。

ちなみに2.4GHz帯なら問題は全くないです

anond:20201002005259

ITでは「ミント味のガムを製造することを認めてよいかどうか」を決めるのはエンジニアであり、そしてエンジニア実装言語仕様書を読んでいるだけで、更にその仕様書半導体ベンダが決定し、加えてその仕様書も主にカリフォルニア辺りの国立大学発明言語化しただけのものだ。

ベイエリアから流れてくる電波をキャッチするアンテナがあればよかった幸せ時代は終わってしまったということか・・・

事業が分かるエンジニアがいない

https://b.hatena.ne.jp/entry/s/www.timakin.com/posts/hacker-and-suits/

IT技術者のイメージ確立した頃のITというのは基本的技術収益性を決定していた。ビジネス人間からすれば「おかしなこと」で、普通に考えれば顧客が何を求めているか問題だ、という意識があったはずだ。

例えば、(フォードの速い馬車という意味ではなく)顧客ミント味のガムを求めていることが判明したとする。当然、ミント味のガムを製造すれば儲かる! のだが、ITでは「ミント味のガムを製造することを認めてよいかどうか」を決めるのはエンジニアであり、そしてエンジニア実装言語仕様書を読んでいるだけで、更にその仕様書半導体ベンダが決定し、加えてその仕様書も主にカリフォルニア辺りの国立大学発明言語化しただけのものだ。つまりITにおいては、顧客が何を言おうと、経営者が何を提供したくとも、カリフォルニア国立大学研究室学生が決めたルールに逆らうことは許されなかった(経営者的糖衣構文を使わずに言えば、実際に技術的に不可能)し、商業的に成功するプロジェクトとは「ルールの中で安価に実現可能もの」と「顧客が欲しているもの」の共通部分のみを的確に選んで提供することができたプロジェクトだけだった。「技術が分かる経営者」とは、現時点の最新のルールを深く把握し、損益にどう出るかイメージを掴みながら商品企画を選べる経営者だった。

ただ僕も不思議だったのは、3[他部署を巻きこみプロジェクトを推進できる]にいるエンジニアですら「事業がわかる」エンジニアとしての評価を得られないケースがあると言うことです。ユーザーにいいものを届けたいし努力をしているつもりだけど、膨大な負荷がかかっているし経営層は何もわかってくれないということで、奥歯を噛み締めながらその場を乗り切っている方は少なくないのかな、と思います

これはまさに「技術収益性を決定するのは、本来おかしなこと」という経営層の理解と、「現世で現実的可能かどうかが最優先」というエンジニア間の乖離ではないだろうか? 経営層は顧客価値提供して対価を受け取りたいのであり、学術的な努力目標を数多く達成したいわけでは、本来はないのだ。だから部署を巻き込んで膨大な負荷を受け止め新しい技術的知見を得ても、まったく意味がない。過去技術的な制約を解除することには大きな意味があった。今はそうでもない。高い技術それそのものによる金銭価値は少なくなったのだ。その結果、顧客が支払う金銭を最大化する製品設計価値は上昇したし、そもそもから低くはなかった。

そして、もちろん実行力も大事なのですが、彼らとの共通言語を持った上で会話ができる、具体的には採用方針を考えたりビジネスの状況を踏まえた塩梅での技術選定をしたり、さらには企業の将来像を共に議論するというある種の机上のフェーズですら、彼らは欲して止みません。それさえできれば多少の評価が得られるというのが、隠れた事実のように感じています(もちろん、それが良いとは言ってません)。視座が4にあるだけで相当な評価を得られるということですね。当然議論してるとしばらくしたら人事や社内管理事業ブラッシュアップ、営業など、全ての方面で駆けずり回ることにはなるのですが。

となると、自らのキャリアに集中したい、技術力への危機感がいい意味で強いエンジニアであればあるほど例の三大美徳に殉じた方が技術者として成長するし、それで評価を獲得できる会社転職するのが良い、となります。そして経営からしてもそういうタイプの人だと同じレイヤー議論をしてくれることへの期待値が高くないので、自然と「事業をわかって」くれないタイプだと見做して配置換えを行います。全てではないですが、こうした負の循環によって過剰にテックリードがいる組織が僕の頭にぼんやりかぶことがあります

「優れたエンジニアは汎用的な問題解決能力が高く、その能力を是非とも経営でも生かしてほしい。あとは興味を持ってくれる人がいるかどうかだけなんだ…」という意見経営層が漏らすパターンはこっち寄りです。そしてあくま個人の嗜好性の問題なので、解決難易度が非常に高く、共通解も存在しません。1つ目の問題のように配置換えで多少解決できることではありません。

以上のような理由から経営層はエンジニアにも「事業をわかって」欲しいと思いながら、その期待値を高く設定することができずにいるという印象を受けました。

まとめると、既存製品の改修にしろ製品企画しろ採用企業内の人員配置しろサプライヤや親会社との折衝にしろ、まず収益性KPIに選び、検討項目を洗い出し、貪欲裏付けを持って改善するエンジニア能力を活かしてほしいという話だ。顧客からの売り上げを最大化する商品企画ができないエンジニアが多い、それが要点だろう。この文章にはエンジニア経営者言語が疎通しない理由が詰まっている。話の要点を短くまとめていない。要点をまとめないことを要求している。要点を省いている。だから技術的な制約と戦うエンジニアには通じないのだ。正直に企業顧客からの売り上げで成り立っている。だからできれば商品企画の段階でも収益性第一企画進行が出来る奴が欲しい。そして社内外を問わずオジサンが求めているのは常に出会いだ。だから収益の話をグダグダ伸ばせること、酌ができることは必須だ」と言えばいいのだ。


昭和はそれで済んでいたはずだ。いつから日本語はこんなに空疎になった?

2020-10-01

東証障害について東証従業員立場から

はじめに

立場

今回の障害概要

記者会見https://www.youtube.com/watch?v=ACFLlMXhlWg などでみられる)および、社内報の一部から得られた情報をもとにしている。

暫定対処

個人的な疑問点

ここまでの説明を聞くと、論理的には、NASハード障害時は手動で切り替えることで、システム全体再起動不要で、売買停止の事態は招かれない、ということになる。そこまではいいが、ではなぜ今日それを実施しなかったのであろうか。この点は記者会見で2回ほど質問されていたと思うが、東証側は正面からは答えなかった。

個人的感想

追記 (2020-01-02)

記者会見において配布された資料について

JPXのウェッブサイトに公開された。https://www.jpx.co.jp/corporate/news/press-conference/index.html 経由で https://www.jpx.co.jp/corporate/news/press-conference/nlsgeu000004zjwb-att/20201001_J.pdf

感想等の追加

SIer からベンチャー転職したが SIer は悪くなかったかもしれない

新卒SIer に入った。

大学時代プログラミングをかじったら楽しくて、これを仕事にできたらいいなと考えて IT 業界を志望し、

でも Goole とか Amazon とかのイケてる企業に入る実力も到底なかったので、とりあえず大手SIer に入った。

研修を終えて某大企業に常駐して働くことになったが、労働環境はひどいものだった。

IT ベンダが集まるベンダ部屋みたいなところにぎゅうぎゅうに押し込まれていた。

PCディスプレイは当然 1 枚しかなく(プログラミングするには 2 枚ほしい)、メモリも足らず、

セキュリティ問題からネットには繋がらなかった。何か調べるとき自分携帯を使う必要があった。

新卒でもいきなり下請け企業のメンバが下についたが、ペーペーの私から見ても信じられないくら能力が低く、その人たちのフォローでも時間が取られた。

そうでなくてもプロジェクト山火事のように燃え続けていたため、仕事量はあまりに多く、だいたい毎日終電まで働いていた。

実際の残業時間は当然のごとく毎月 120 時間をゆうに超えていたが、法律上申告できない部分はサービスとしていた。

ある時、客先のマネージャーに、「このタスクいつ終わるんだ?」と言われ、

私は「(無理して)2週間くらいです」と答えた。 1 週間でやれ、と言われた。

私に残された手段は、1 日で 2 日分働く以外になかった(当時はいい子だったので、バックレるなど考えられなかった)。

終電ではなく逆方向の"始発で帰る"ようになった。シャワーだけ浴びに家に帰って、1 時間くらい寝てすぐ出勤した。

それでも 1 週間ではタスクが終わらず、そいつから罵声を浴びせられることとなった。

なぜこんな頑張っているのに怒鳴られなければいけないのかと、その日は帰りの終電に乗りながら世の中の理不尽さに泣いた。

その後もしばらくハードプロジェクトをいくつか経験したが、

数年経って、たまたま割と余裕のあるプロジェクトに移ったので、積もりに積もった会社への恨みを晴らすときだと思い、転職活動をはじめた。

ハードすぎるとき転職活動をする余裕など到底ないのが皮肉ものである

自身技術力が磨けそうで、魅力的なプロダクトを作っていそうなスタートアップ企業を受けて、内定をもらった。

辞めると言ったときには偉い人たち含め、いろんな人から引き止められたが、聴く耳は持たなかった。

皮肉なことに、上記の厳しい環境でも死ななかった経験からサイヤ人のように戦闘力が高くなっており、評価が高かったらしい)


スタートアップ転職し、前みたいなひどい労働環境はなくなった。

同僚も概して優秀だし、給料残業がない分は下がったが、もともとそんな金は必要ないので問題はない。

しかし、今となっては SIer はそこまで悪くなかったかもしれない、と思ってしまう。

なぜかというと、今の会社プロダクトがあまりにクソだと知ってしまたからだ。言ってしまえば "この世に必要のないもの" だった。

現在の弊社が掲げる誇大広告に騙され、入社して内情を知るまでは見抜けなかった。うかつだった。

この世に必要ないプロダクトを作るのは苦しい。自分が世の中に貢献しているという実感が持てないから。

ベンチャーなので営業にも行ったりもしなければならないのだが、その時に「うちの製品は素晴らしい」と思ってもない嘘をつかなければいけないのも苦しい。良心の呵責を感じる。

SIer にいた頃を思い返してみると、作っていたものは世の中に明らかに価値を生み出している大企業の、明らかに必要システムだった。

もちろん、SIer だって世の中に必要ないシステム(誰にも使われないシステムとか)を作っているケースもあるのを知っているが、概して数は多くないのではと思う。

今の会社黒字化など到底無理そうなので、潰れる前に転職しようと思っているが、SIer に出戻るのも悪くないかなと思わないでもない。喉元過ぎれば熱さを的なやつ。

まぁ SIer よりも外資イケてる企業に行けるならその方が良いし、誰かいきなり 10 億円くれたりしたらもっと良いのだけど。

2020-06-26

面倒なだけか?

勤め先で導入している基幹業務システム国内大手ベンダ製で、質問作業依頼は専用サポート窓口を通すことになっている。

サポートメールを送るとすぐに確認電話があり、迅速に対応してくれるから非常に助かる。

のだが、先輩氏や上司氏はサポートを通さず営業さんやSEさんを捕まえて対応させようとする。現場の人だっていきなり尋ねられても困るだろう… 突然じゃわからないこともあるし、対応する順番や優先度もあるし、今日作業内容だってもう決まってるだろうし。

「人と対面して人に話をするほうが早い」という意識がどこかにあるのかな。あと言質がないと気が済まない的なやつとか。

以前はサポート窓口がなく作業依頼はSEさんを捕まえるしかなかったこともあるらしいから、その名残なのかもしれないが…

2020-06-19

anond:20200619010140

しかに気になるけど、かといって受注できる国内ベンダは他にあるのかしら…

2020-06-16

オワコンSIerについて①

今朝、某ブックマークサイトにて大手SIerにおけるクソ設計書について少しばかり話題が盛り上がった。

SIerシステム開発方法や、所謂炎上案件」というのは具体的にどういうことなのか、できる限り思い出して書いてみたいと思う。

ちなみに、私は通称SE」で、SE歴は3年。

所属したプロジェクトは3件で、1つ前に所属したプロジェクトコロナ騒動の直前の2020年1月である

これを読んでいる人の中には、私よりも玄人SE、もしくはPMいるかもしれない。

手持ちのサンプルが少ない故に「ちげーよ!」ということもあるかもしれないが、そこは大目に見ていただけると幸いだ。

まず、ITに携わるシステムとはいえSIerベンチャーWeb系は規模と客層も違うし、開発手法も違うと思われる。

開発手法というのは、「ウォーターフォール(各工程最初から着実に終わらせる手法)」、「アジャイル(短い機能追加を繰り返していく手法)」が一般的にも有名だと思う。

開発手法には「ウォーターフォール」のさらに上の「メテオフォール」というのがある。本気の炎上アジャイルのようにウォーターフォールする開発という意味だ。

(何を言っているのかわからいかもしれないが、私も何を言ってるのかわからない。https://eiki.hatenablog.jp/entry/meteo_fall

多重下請け所属しているSEが「メテオフォール」をかけられたら、もう刃傷沙汰にでもならないと逃げられないと思っていい。

炎上案件SIerの客層は、金融系・公共インフラ系がほとんどだ、7割そうだろう。(※適当

自社開発系はさておき、受託Web系やパッケージベンダ系の客層は、小規模案件プロジェクトもある程度あると思う。

金融公共インフラ系はべらぼうに規模がデカい。馬鹿みたいな工数が掛かる。

基本的計算式は以下の通り。

要件定義設計開発UT結合テストシステムテストユーザー受け入れテストシステム移行】 +追加要件開発(保守運用)。

大雑把に言うと、「ちょっと顧客情報DBを参照してWebに表示させるシステムが欲しい」として受注した場合、約4000万円がお会計となる。

現行システムリプレイスだとしても、2000~3000万円はかかる。高い(※謎仕様の現行システムだと炎上不可避案件となりさらに膨れ上がる)

当然、数千万案件となるとプロパー社員では人手が足らなくなる。

すると登場するのが「派遣社員SES)」あるいは「下請け」というシステムだ。

会社によって異なるが、だいたい4~9割が「派遣」や「下請け」の割合となっている。

それでも工数不足になってしまったプロジェクトは、そこから鬼出勤をカマす。

納期を過ぎたらさあ大変、開発経費・損害賠償SIerの自腹になってしまう。

というのが、ここまでがSIer説明

それで最初に書いた「ウォーターフォール」ってのは何なのか?ってことになる。

ウォーターフォール」=「各工程要件定義設計テスト)で客の承認を得て合意を握った上で着実にマイルストーンを固めていく」

「何のために固めるのか?」=「手戻りを起こさないため(白目)、責任押し付けられないようにするために」

じゃあどんな手法で?なぜ工数が膨らむのか?

と、ここまで前置きを書いて疲れてしまったので、続く。

駄文失礼。

anond:20200615195109

2020-05-15

役所の電算システム

保育所運営とか税金とか介護保険システムGoogleとかアップルが作ったらどうなるんだろう。

国内の昔からあるベンダは(金額によるけど)無駄な動きが多かったり気が利かなくてモヤモヤする。紙帳票で出力したリストもう一度同じシステムで一件ずつ叩いてフラグ立てていくとか、もうちょっとどうにかならなかったのかっていうのが多くて多くて。

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

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

2020-01-23

ベンダからシステムが一次納品されて受入試験してるんだが品質が低すぎるというか一度も総合テストしてないっぽいレベルで低い

機能によっては単体テストすらしてないんじゃと疑う箇所もある

なんなんだコレwww

2019-07-06

7payのセキュリティ審査って何をやってたんだろうか

ここ連日騒がれている7pay。

パスワードリセットリンク送付先のメールアドレスに対して設計上の問題脆弱性が発覚して大変な事態に発展しています

昨日の会見では社長ITリテラシ不足が露呈したり、サービス継続が表明されたりして、いわゆる「祭」の様相を呈しています

また、会見内で「セキュリティ審査実施した」と明言がされました。

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

セキュリティ審査実施していたにも関わらず、何故今回の問題が見逃されたのか。

非常に稚拙な推測ですが個人的に考えられる可能性をまとめてみようかなと思います

セキュリティ審査とは

その名の通り、サービスローンチ前に実施する、脆弱性問題がないか審査の事・・・だと解釈しました。

審査」というとISMS辺りを連想しちゃいますね。

一般的には脆弱性診断とかセキュリティ検査とも呼ばれています。私はこちらの呼び方の方がしっくりきます

以後脆弱性診断と記載していきます

実施した」とはいっても、どういった内容を実施たかはわかりません。

ただ、7payは「一般に公開する」「お金を扱うサービス」になるため、ガチガチ脆弱性診断を実施すべきでしょうし、実際に実施したのではないかと思います

通常、脆弱性診断というと、以下のような項目があげられると思います

抜け漏れあると思うけど、大体どこのセキュリティベンダーでも上記のような項目を診断しているんじゃないかなあと思います

詳しくは各ベンダの診断内容のページを見てみると更に詳しく載っています

LAC、CyberDefence、NRIセキュア、ブロードバンドセキュリティスプラウトなど。

ただ、今回の脆弱性診断が外部ベンダ実施されたのか、内部で実施されたのかはわかりません。

以下、推測をつらつら書いていきます

外部ベンダ発注したが、コスト削減のために対象を削りまくった

脆弱性診断はモノによりますが、診断内容をマシマシにするとエラい額が掛かります

Webサービス診断は見積もり方法が各社違ったり、ツールを使うか手動とするかによって金額も大きく変わってきます

また、数量計算ベンダによってまちまちです。ページ単位であったり、画面遷移単位であったり、SPAであればAPI単位であったり、複合での計算だったりします。

お願いすれば見積もり時にステージング環境で動いているWebサービスクロールして、各ページの評価を付けてくれるベンダもあります

規模と見積もり内容にもよりますが、100~200万といったところでしょうか。

スマホアプリ診断は一本幾らという場合が多いような気がしますね。相場としては50万~100万程度でしょうか。

プラットフォーム診断も内容によるとは思いますが、大体100万くらいかなあと思います

これ以外にWebSocketを使っていたり、別のサービス連携していたりするとその辺りの通信も含まれてくるのでまた金額は上がる可能性もあります

Webサービス200万、スマホアプリ(iOSAndroid)100万*2、プラットフォーム100万とすると、500万円掛かるわけですね。

脆弱性診断をするだけでこれだけのお金が吹っ飛んでしまうわけです。

そしてこれをそのまま発注するかと言われると、多分しないでしょう。

セキュリティお金が掛かる割にリターンが少なく、目に見える結果が必ず出てくるとも限りません。

経営層は中々首を縦には振らないでしょう。

会見でも明らかになったことですが、社長ITリテラシはあまり高そうにありません。

こうなると脆弱性診断の稟議を通すのは中々容易ではなかった可能性もありそうです。

また7月1日に間に合わせたようなところもあるっぽい(?)ので、開発側に資金を全振りしていた可能性もあり、診断に費用を掛けられなかったのかもしれません。

いずれにせよ、全く実施しないのはまずいし重要そうな部分だけピックアップして実施しましょうという話にはなるでしょう。

削れるものをあげていってみましょう。

例えば、iOSスマホアプリ実施しなくても良いかもしれません。iOS上で動くアプリは確かサンドボックス構造になっているはずで、ローカルに何かしらのデータを持っていても外部からアクセスは基本不可であるためです。確か。

そもそもスマホアプリ自体不要かもしれません。7payのサービスへのアクセスインターフェイスとしてのアプリしか提供していないのであれば、取り扱うデータほとんどないと考えられるためです。そのため、スマホアプリAndroidのみ、もしくは両方実施しなくても大きな問題は発生しないのではないかと思います

・・・この辺り私の勘違いというか、「最優先でやるべきだろjk」といった考えがあれば指摘ください。

プラットフォームも、ベンダによります実施しなくとも良いとも思います

ベンダ説明でも、主にポートスキャンをして、空いているポートに対してtelnetで色々したりするといった説明がなされたと思います

Webサービスなら443と、空いていても80くらいしか外部には公開していないので、これは実施しないという選択をしても不思議ではないと思います

サーバコンフィグも、DocumentRootがおかしいとか致命的な設定ミスをしていない限りは見てもらう必要はないでしょう。

そもそも構築手順等はノウハウもあるでしょうし、わざわざ見てもらう必要性はほとんどないわけです。

ワイドショーでは「不正海外IPからで、国外からアクセス許可していた」事が取り上げられていましたが、例えプラットフォーム診断をしていても、この辺りは指摘されなかった可能性があります

実施していればもしかしたら備考レベルでの注意や、口頭で「国内のみに留めておいた方がいいかも」といったことは伝えられたかもしれませんが、「利便性」という観点から実行されることはなかったんじゃないかなと思います

Webサービスですが、ログインログアウト処理は必須でしょう。また、新規登録情報変更、退会処理も重要です。

パスワードリセットどうでしょうか。正直これも重要です。なので、ベンダに依頼するにあたってはここも診断対象としていたはずです。

ところで今回の件では協力会社について様々な憶測が飛んでいますが、NRI説が結構人気みたいです。

ただ、NRIにはNRIセキュアというセキュリティに特化した子会社存在しています

もし脆弱性診断をするとなった場合、そこを使わないという手はあまり考えられません。そもそも発注時にそれを見越して診断費も開発の見積もりに含まれているのではないかと思います

ただし、セブン側が「脆弱性診断はこちら側で発注します」と言っていれば話は別です。

NRIセキュアは診断費用が高いらしいので、コストダウンするために別ベンダに診断部分のみ発注する可能性はあります

別のベンダ発注したことで、抜け落ちた可能性はゼロではないかもしれません。

また、NRIセキュアが実施する場合においても、「ここは抑えておいた方が良い」という機能毎やページ毎にランク付けした資料セブン側に提出することと思われますが、どこを実施してどこを削るかの最終的な判断セブンに委ねられます

考えられる事としてはパスワードリセットの処理を診断対象外としたことですが・・・そうする理由もわからないので、うーん・・・

ただ、こうして対象を削りまくることで100万程度、もしくはそれ以下まで診断費用を抑えることができます

特定ベンダと、ツールを用いた定期診断を実施してもらう契約をしていた

この可能性もあるのかなと思います

使ったことはありませんが、SecurityBlanket 365というサービス自動での定期診断が可能なようです。

ライセンスやどういった動き方をするのかはいまいちわかりませんが、ベンダ逐次依頼する脆弱性診断よりかは安く済むはずです。

ただ、自動診断となると設計上の不備やそれに伴う問題は検出できないはずです。

ツールの手が届く範囲での、XSSPoC、ヘッダの有無など、ごく一般的脆弱性診断になると考えられます

でも手軽そうで安価っぽいなので、これで済ませていても不思議ではないです。

セブン内部でツールを用いた診断を実施していた

脆弱性診断ツールOSSのものもあればベンダ販売していたり、SaaS提供しているものもあります

OSSならOWASP ZAPやw3afがWebサービスの診断が可能です。また、phpcs-security-auditなど、ソースコードを解析し脆弱な箇所がないかを診断するものもあります

ちなみにWebサービスに対する診断を「DAST」、ソースコードに対する診断を「SAST」と言ったりします。

有償のものとなると、DASTは先程のSecurityBlanket、AppScan、Nessus、Vex、VAddyが挙げられると思います

SASTになると、RIPS TECH、Contrast Securityなどでしょうか。

上記のようなツールを用いて、セブン内で脆弱性診断を実施することでセキュリティの知見を高めたり、内部で完結させるための動きを取っていたかもしれません。

こういった動きは結構色んな組織で見受けられます。外部の手を借りずに診断ができれば、関係者間の調整も楽ですし、それと比べると費用も安く済みますからね。

ただし、社内のエンジニアに任せる事になるため、片手間になってしま可能性があります

また、ツール使用方法についてのノウハウは溜まるかもしれませんが、それとセキュリティの知見が溜まるかどうかは別の問題としてあると思います

・・・とは言ってもセブンにはCSIRT部隊ちゃんとあるんですよね。

https://www.nca.gr.jp/member/7icsirt.html

『7&i CSIRT は、7&i グループCSIRT として設置され、グループ企業に対してサービス提供しています。』と記載があります

また、『7&i CSIRT は、7&i HLDGS. の組織内に専任要員を以て設置され、インシデント発生時の対応だけでなく、インシデント発生の未然防止にも注力しています

グループ企業情報システム部門と連携し、7&i グループ内で発生するインシデントに対する未然防止のための調査分析リスク情報の共有、ならびにインシデント対応活動を行なっています。』

という記載もあるため、今回の7payも、7&i CSIRTが動いてセキュリティ関連のチェックをしていたのではないかと思います。「情報システム部門」とはありますが。

組織図上にはありませんが、デジタル推進戦略本部の下か、リスクマネジメント委員会情報管理委員会のどこかに所属しているんじゃないかと思われます

日本CSIRT協議会にも名を連ねているわけですし、CSIRTメンバー専任要因ともありますし、セキュリティ関連の技術知識は十二分にあると思うんですよね。

なので、内部でツールを使って実施していたからといって、こんな重大な不備を見逃すというのはちょっと考え辛いなあ・・・と思います

会見内で言われた二段階認証検討事項に上がらなかったのかなあ・・・と。

まあ、今でも機能しているのであれば、の話ではありますが。

で、これを書いている最中に気付いたのですが以下のようなリリースが出ていたんですね。

https://www.7pay.co.jp/news/news_20190705_01.pdf

これを見ると内部のCSIRT機能していなかったか力不足判断されたかどちらかになるのかな・・・と。

実際はどうだかわかりませんけど・・・

診断を実施したがどこかで抜け落ちた

これも有り得る話かなあ・・・と。

関係者が多いと情報共有にも一苦労です。

開発やベンダCSIRT部隊情報共有したとしても、POが忘れていたとか、伝えたつもりが曖昧表現で伝わっていなかったとか・・・

ベンダ実施して指摘事項として伝えていたけど、いつの間にやら抜け落ちていてそのままサービスイン・・・というのもシナリオとしては考えられますね。

問題認識していたが上申しなかった/できなかった

7payは社内的にも一大プロジェクトだったはずで、スケジュールも決まっている場合、余計なことを物申すと手戻りや対応時間を取られることになります

そういった事を許さな空気が出来上がっていると、まあ中々上には上がってきづらいです。

これも十分にありえる話ですかね。ないといいんですけど。

セキュリティ審査自体が、情報セキュリティ基本方針個人情報保護方針に沿った内容かどうかを確かめただけだった

どうしても『審査』という言葉に引っかかっています。『検査』ならまだわかるんですが。

そこで思ったのですが、情報セキュリティ基本方針個人情報保護方針を元にしたチェックリストのようなものセブン内にあって、それを埋めた・・・みたいなことを「セキュリティ審査」と言っていたりするのかなと思ってしまったんですね。

でもこれはセブンペイの社長個人情報保護管理責任者ということで、ISMSPMS等で慣れ親しんだ単語である審査』を使っただけかもしれません。

そもそもそれで終わらせるなんて事ないでしょう。セブン程の企業・・・

そもそもやってない

大穴ですね。いやこれはないと思いますよ。あったら大問題じゃないですか・・・

というわけで、なんとなく「こうだったりして・・・」みたいな事をつらつら書いてみました。

そういえばomni7で以下のお知らせが上がっていましたね。

https://www.omni7.jp/general/static/info190705

『定期的にパスワードを変更いただきますようお願い申し上げます。』とのことです。CSIRTはもしかしたらもう機能していないのかもしれないですね。

もしくはわかりやす対策提示しろと言われたのかもしれません。それなら仕方ないんですけど。

パスワード定期変更を推奨する因習はいつ消えるんでしょうか。

以上。

以下追記 2019-09-08

一部typoとか指摘事項を修正しました(役不足力不足 etc)。

ついでに時間経ってるけど追記します。もう誰も見ないでしょうけど。

所詮「人のつくりしもの」だよ

監査なんて取り揃えた書類通りになっているかどうかなので、監査受けているかセキュリティ的に大丈夫ってことじゃないよ

そんなに監査が万能なら監査できるくらいの人が作り出せば完璧になるはずだろ

ちゃんと読んでいただけましたか?全文通して私の主張が「監査をしっかりやれば防げた」という意味と捉えられているのでしょうか。そんなに分かりづらい文章を書いた覚えもないのですが・・・

一番上でも記載していますが、私は今回の7payの「セキュリティ審査」は、「脆弱性問題がないか審査の事」、つまり脆弱性診断」を指していると仮定して本エントリを書いています

そういう意味で、ここで私が指している「審査」と貴方が指している「監査」は似て非なるものです。字面は少し似ていますがね。

監査貴方記載する通り「ある事象対象に関し、遵守すべき法令社内規程などの規準に照らして、業務成果物がそれらに則っているかどうかの証拠収集し、その証拠に基づいて、監査対象有効性を利害関係者に合理的保証すること」です。

貴方の言う「監査」に近いことは「セキュリティ審査自体が、情報セキュリティ基本方針個人情報保護方針に沿った内容かどうかを確かめただけだった」の見出し部分で触れていますが、それで終わらせているわ Permalink | 記事への反応(2) | 05:48

2019-06-09

anond:20190608215207

分散させると何かと大変じゃない?ネットワークの設定とかマシン側の設定とか、自動化したとしても初期設定は絶対手間でしょ。

ライセンスとかベンダに払う保守費とかもかさむだろうし、スループットめっちゃ上げたい、可用性めっちゃ高めたい、とかの特別事情がなければ1台でいいと思う。

というか「コスパ」ってなんだよ。非機能要件、明確にした方がいいと思う。

2019-04-13

anond:20190405004215

元増田です。

しばらく見ないうちにプチバズってたのでちょっと驚きました。

はてブ言及コメントも拝見し、いろんな意見があって面白かったです。

否定的意見の中で代表的ものについて、いくつか反論(補足?)しておこうかな、と。

記事と違って完全に私個人主観の話なので、NTTに勤める人の一般的価値観ではないことはあらかじめ言っておきます

退職しない」ではなく「退職できない」の間違いでは

無能から転職できないんだろ」みたいなニュアンスですね。半分正解、半分不正解といったところでしょうか。

そもそも失職や転職ストレスを一生味わいたくないから今の会社を選んだので、転職してやっていくためのスキル経験を積む必要性を感じていません。

少々自分語りになりますが、私の父は私とは真逆仕事第一で家庭を顧みず、中小企業勤務で倒産転職を繰り返した人でした(いまも働いているけど)。

加えてギャンブル好きなのでたまの休みパチンコに行ってしまうため、家計は火の車で、家に借金取りが来るから知人の家に避難するなんてことも割と日常茶飯事。

そんな父を反面教師として育ったためか、物心ついた頃から仕事はほどほど、家庭と趣味に生きよう」と決めていました。

実際に就職したり家庭を持ってみて、この判断は正解だったと思っています

私は器用ではないので、妻との夫婦生活子供の世話や将来に向けた教育投資、加えて自分趣味も充実させようとすると、とてもじゃないけど仕事のことを仕事中以外に考える暇も余裕もありません。ましてや転職なんてもってのほか

私にとって仕事は完全に金を稼ぐ手段であって、それ以上でも以下でもないのです。

もし退職するとしたら、そこそこ軌道に乗ってきた副業(というか趣味たまたま金になっている)がさらに伸びて、その収入資産運用だけで死ぬまでやっていけるフィナンシャルプランが完成した場合ですね。

かなりリスクを避けたい性格なので、今の会社で定年まで勤めた場合生涯賃金の倍額くらいの収入が得られるプランじゃないと辞めないと思いますけど。

NTTが一生安泰だと思っているのは甘い

そうですかね。ここは学生時代からかなり吟味した結果なので、割と自信をもって「大丈夫」と言えます

一番安定している公務員は、副業禁止を始めとする縛りが強すぎて却下しました。収入世間イメージよりだいぶ低いですしね。

次に挙げたのがインフラ系で、最後まで迷ったのが鉄道会社、電力会社、そして通信会社でした。

いずれも産業革命レベルの発展が無い限り業界自体は安定です。加えて各企業大株主構成(というか国や自治体資本がどの程度あるか)、財務諸表などを加味して選びました。

最終的にNTT(所要5社)が就職候補に残り、その内2社にエントリーして内定をもらった結果、茸に行くことに決めました。ここが潰れるとき日本の終わりだと思ってます日本が終わったら自分も終わりでいいかな、と。

コーディングしない奴が開発職やエンジニアを名乗るな

出ました。コーディング至上主義です。特にSNSでは「コーディングできないSIer vs プログラマー」みたいな話がウケますね。

システムを世の中に出すのに必要仕事コーディングが全てではないですよ、としか言いようがありません。パン屋必要なのはパン生地をこねて焼く人だけでは無いですよね。

ちなみに私自身は学生時代コーディング経験がありますが、社会人になってから仕事コードを書くことはありません。

外部設計はもちろん内部設計レビューバグが出てログ解析する際の一次切り分けにソースコードを見たりするので、一応関わっている開発プロジェクト言語知識はあります

数年前に開発部に異動してきてから業務時間中に学んだものであって、業務時間外にわざわざ勉強したりはしていません。

私は自分のことをエンジニアだとは思っていませんし、一生開発業務をやるわけではなく「今は開発職」というだけです。

そもそも弊社は3~5年周期で社内異動を繰り返す(いわゆるジェネラリスト育成)ため、深く狭い知識より広く浅い知識を身に着けるスタイルになります

PowerPointシステムグランドデザインを書ければ、あとはBP仕様書に落とし、ベンダが作ってシステムが出来上がる

・tableauで分析データを出せれば、あとはコンサル改善案を出してくれる

Prottプロトタイプを作れれば、あとはデザイナーデザイン仕様に落とし込み、ベンダが作ってWebサイトが出来上がる

ちょっと大げさに言えば、部署は違えど弊社のプロパー仕事はだいたいそんな感じです。だから自分で手を動かすことにやりがいを感じる人には向きませんよ、と言ったのです。

給料は悪くなくてもつまらない仕事をするのは嫌だ

私が一番驚いたのは、想像以上に仕事やりがい人生における重きを置いている人が多いことです。

弊社にいると、管理職含めて「仕事あくま仕事、家庭や趣味が最優先」な人が大半なので、かなりカルチャーショックでした。

私はとにかくコスパ重視の人間なのですが、今の収入と労力のバランスは最高だと思っています

もちろんもっと勉強して資格を取ったりガンガン外部で活動して人脈を作って高給の企業転職すれば、収入は多くなりますが、私にとってそれはコスパが悪いのです。

今以上に安定している企業は無いであろうという理由もありますが、加えて私生活時間犠牲にすることへの抵抗が大きい。

「年間300時間残業してワークライフバランスとか社畜かよ」というコメントもあったので、ちょっと気になって昨年度の労働時間を調べてみたところ、残業込みでざっと1900時間

まぁ上を見ればきりが無いですが、そんなに長くは無いかなと思います。今の生活基盤を維持するには、それくらいは仕事に費やさないと罰が当たるんじゃないかと。

あと、こればかりは個人差が大きいと思いますが、私はもともといっぱいいっぱいの状態で何かをし続けるのがとても苦手なので、ゆるゆるの環境が好きなのです。

からスキルの高い人たちが集まり切磋琢磨しあって互いを高め合う、ちょっと勉強サボるとおいていかれてしまう、そんな環境はたとえ高給でもお断りです。

弊社はだいたいどの部署でも勤務中の脳ミソの平均CPU使用率20%くらいで仕事が回るので、理想的です。

私は人生もっとも頑張る期間を高校生の3年間と決め、予定通りそれを終えました。

現役で国立大合格し、自分学費を稼いで大学院まで進み、失職や転職ストレスに悩まされないホワイト企業に進む。これで人生の基盤が完成した、と喜んだものです。

今はその基盤の上で、自分趣味や家庭生活育児教育とやることが盛りだくさんなので、基盤の変更やアップデートにかけるコスト時間)は持ち合わせていません。

なお、一応仕事も世の中にそれなりにインパクトを与えるものサービス提供し、フィードバックを得られるので、仕事自体やりがいも皆無というわけではありません。

仕事でかかわる社内外の人も良い人が多くて、その点もとても満足しています

最後

今より給料が多く、今より労働時間が短く、それでいて一生潰れない会社に、ローコスト転職できるチャンスが来ない限り、転職することはないでしょう。

そしてそんなことはあり得ないとわかりきっているので、私はNTT退職しません。

2019-03-21

anond:20190321104659

現場担当者自分判断マクロ作ったりするのはアリだと思うんだけど

それをズルだという謎の風潮が一部であるのをネットで見るたびに笑いが止まらない。

ぜひ我々ベンダにお任せいただきたい。

お仕事を簡略化するためのマクロいくらでも書かせていただきますよ。

もちろんスペシャリストによる本格実装なので安心安全です。

ぜひこの機会にRPA導入をお手伝いさせていただければと存じます

目安としては自動化したい担当者様の業務内容1件あたり10営業日前後でご提供できればと考えております

スムーズ作業を進めるために各担当者様には自動化したい内容をあらかじめまとめて頂き、そして弊社エンジニアの前でその業務を実演、撮影をいたしまして、それをもとにRPA導入について検討してご提案させていただきます

また毎日ステークホルダー全員を同席の上で進捗報告、方針確認等させていただければと存じます

システム仕様変更によってRPA動作しなくなった場合、そちらはアフターサービス契約による対応とさせていただきアフターサービス基本料とは別に別途工賃を頂戴いたします。

仕様の変更次第によっては対応できない場合もございますのでご了承願います

なお、弊社への丸投げは必ずメテオフォールになって失敗するので絶対に許さない所存ですので最後まで毎日お付き合いいただきます

くらいの意気込みでセールスしたい。

1件あたり200~300万円くらいとれないならやる意味がない。

2019-01-29

総務省無差別侵入調査がマズい点

いつ、どこへ、どんな調査をするのかという透明性がない
セキュリティベンダに依頼する場合であれば「どんな調査を」「いつ」「どこに対して」行ったのかを明確にさせることができてログとの対照もできるが、総務省のこれは調査段階では相手に通知なく行うのであるからこれができない。情報公開請求へのハードルの高さを考慮すると「公開させることができない」と見るべきである。この種の公開を積極的にさせるには政治介入有効であるわけだが、とりわけ今の内閣特有事情として情報公開政権が極めて消極的であることはこの問題性に拍車をかける
損害を回復するのが難しい
上記の点にもよるのだが、問題が発生したとき損害賠償請求については、セキュリティベンダ民間企業への損害賠償請求に比して国賠訴訟を戦わねばならないのでハードルがずっと上がる。

まあ要は不透明なのが一番不味くて誰が総理大臣でもこれやられたらたまらんのだけど、とりわけ今の内閣政府運営の透明性向上にまるきり興味がないので余計にたまらんという話

2019-01-09

37歳童貞ですが毎日が早すぎます

まさに光陰矢のごとし

昔の人は良い事を言います

来週火曜にリリース機能がありますが一つも試験をしてません

ワオ

明日中に全て検証してベンダに連絡しつつ管理簿をややこしい更新をしないとなりません

2019-01-02

変更に強いアーキテクチャみたいな話は、大抵の場合単一アプリケーション対象議論されている

それはそれで有意義なんだが、社内には数百から数千のアプリケーションが絡み合ってて、これらを別々のベンダ情シス担当ユーザ部門担当が開発や運用してるから何か変更しようとすると影響調査から修正テストやらで工数が爆発して身動きが取れないってことに悩んでる企業は多い

アプリケーションが1つだけ変更に強くてもどーにもならんの。全部書き換えるのに100年ぐらいかかっちゃう

2018-12-14

メールでやたらと恐縮を使うベンダさんが送ってきた仕様書にも恐縮恐縮と書きまくっていた

短的に!書くの!仕様書は!

恐縮いらないの!

機能だけ!サラッと!書くの!

2018-11-29

anond:20181129000623

民度の高い部署にいられるようで運がいい。

部署によってカラーが異なるのは5年もいれば分かるとは思うが、場所や時期によっては毎日会議室からベンダを詰める怒号が聞こえていたこともあるよ。研究所でもね。今どきはめったにないとは思うけど、ないわけでもないだろう。

大きい会社なので、外部の人も内部の人でさえもどこに触れるかによって印象はだいぶ異なるんだろうな、とは思う。

2018-11-05

Cisco Systemsの終わり

Cisco Systemsを知っているだろうか。スイッチとかアクセスポイントとかのネットワーク製品を手がける米国大企業だ。

実は日本でも企業向けのシェア50%近く、10年前から「もうCisco時代は終わる」と言われ続けていたがしぶとく残っている。

だが、そんなCiscoも今度こそ終わりを迎えそうだ。

発端となったのは一年前、Cisco製品ソフトウェアライセンスの新たな管理形態を発表した。

簡単に言うと、Cisco機械で動かすソフトウェアライセンスインターネット認証するというものだ。ちょうどWindows XPライセンス認証のように。

何が問題になるかというと、ネットワーク世界インターネットは極めて親和性が低いのだ。あまり想像がつかないと思うが、例えばスイッチルーターファイアウォールといった機械は、インターネット接続されていないことがままある。

例えば、データベースサーバー接続するスイッチセキュリティのためインターネットと直接接続しないというようなことは、割とどこでもやっている。なので、この馬鹿げたアイディアはすぐに撤回されるだろうといった予想が我々業界人感覚だった。

最近Ciscoは最も普及しているスイッチで、新しいライセンス形態のみをサポートするソフトウェアを発表した。

どんな影響が出るだろうか。まず、金融機関などのミッションクリティカル系がCiscoを使うのをやめる。金融は止めたときの影響が大きすぎて、わざわざインターネット接続してライセンス認証するより他の機械を入れたほうがリスクが少ないと判断される。

これを見て、多くのデータセンターCiscoを使うのをやめるだろう。なぜなら他のベンダ機械ミッションクリティカル系が使えるのであれば、わざわざCiscoを使う必要もないから。また、みんな高いCiscoを使うのを、本当はやめたがっている。

例えばCisco Systems製品が主にIAサーバーで動くとかなら、インターネット認証もやむ得ないだろう。でも、この会社はもともとハード屋だ。なぜ買ったものを動かすのに、インターネット認証必要なんだか理解に苦しむ。

資格のために百万単位で使った企業が失速するのは悲しいが、一度痛い目を見て目を冷ましてほしい。

2018-09-13

仕事では完璧にしようとか考えず動く程度に適当に作ればいい

面倒な上司がいろいろ文句をつけてくる

意味不明ものが多いし何かとケチつけないと気がすまない性格から面倒なことを一々と

直接のユーザから意見なら多少は変でもそのユーザ必要としてるなら納得できるし、イライラすることもない

依頼があったわけでもないのに謎の基準文句をつけてくる

社内でそんなことこだわったところで実際には気にされないことが多いのにだ

まだデザイナーデザインについてこうした方がUXいいねみたいなことをいうならわかる

専門の人の意見だし

そうでもないのに何かと文句をつけてくる

増田なのでwebで例をだそう

CSS すらまともに使いこなせずマージンもパディングもないような酷い作りのものしか作らないのにソッチのほうが良いという

色は red, green, yellow と標準のペイントのデフォルトカラーかよというような色を指定してくる

#fcfcfc や #0a0a0a なんて使おうものなら白と黒しろ

max-width を指定せずに画面の端から端まであるようなものがいいという

そのわりにグラデーション無意味につけたがる

一部例じゃなく本音が出たがまぁいいか

今の時代アプリサービスを全く見てないのか?としか言えないようなセンス

自社サービスなんて手を出したらこれは酷いと話題になりそうなもの

見た目にあまりこだわれない社内用サービスしか作ってないからと言って、その他サービスをみてる人からすれば明らかに

残念なしか時代遅れなものが良いと思ってる

しかデザインに限ったことではないがまだ序盤の時点で言っておけばいいものの完成後にいまから変えるなんて難しいのが

わかりきってるようなときになってからああしろこうしろ言い出す

先に書いたようにユーザ要望ならまだ仕方ないと言えるがなぜこんな無意味なことに付き合わなければならないのか


わりと自分完璧主義なところもあるので作るならちゃんと作ろうとしてるんだが

こういうのを相手にしないといけないせいで結局グチャグチャになってくる

色のバランスレイアウトを考えたところで一瞬でそのバランス無意味になるようなことになる

プログラムだって全然関係ないものを無理やり入れ込まないといけないようなことになることも多い

疎結合だとかグローバルをつかわないとかそういう作りやすくするためのことをしていても

それが維持できないような無茶で無意味な指示が出る

根本的に変えたり対処するためのものを作るとかすればなんとかできなくはない

しかしそんな時間はないので結局ひどい作りになるしかない

過去プロジェクトでもそういうのが多いか自分で作るのくらいは扱いやすくしたいと考えていたのだが

過去のもこういう経緯で酷いものになっていったのかなと思う


過去に言われたものだと速度を優先だとか言って自分で作ったものよりは遅くするなと言う

そしてそのコードは本人でしか読めないような酷いものだった

しかしながら関数は使わずコピペだわforeachなどは使わずループ変数を使って地道にやるなどメンテナンス

できる気がしないが速度においては早いと言えるもの

当たり前のようにグローバル変数がいっぱいあるしライブラリ使用箇所はカスタマイズするための仕組みがあるのに

ライブラリ自体をどんどん書き換えていく

便利で読みやすいような書き方だと速度的にはそれに劣る

だがわざわざそんな扱いづらいし見づらいコードは書きたくない

そんなに速度にこだわるなら勝手に一人で機械語でも書いてろよって思う

しかし速度に加えてメンテやすしろという

どちらか取捨選択すべきものなのに両方みたせとか無理なことを言う

ちなみに便利なライブラリは基本無駄が多い遅いものからライブラリ頼みのベンダはクソだとか

能力がないだとか言っていた


そういえば昔先輩社員仕事したときには変に凝ったものとか必要以上に作り込んだりはしないほうがいいとか

言っていてそれなりに手抜きでさらっと一応は動くようなものを作っていた

私はそういうやり方が嫌いだったのだが今ではこういう環境に長くいた結果仕事のものにこだわって作り込んでも無駄

ということがわかってそうなったのかなと感じた

自分でもサビ残休日無償出勤してまでいいものにしようと努力はしていたが謎の指摘に合わせていると

愛着もなくなってきたし後は適当に済ませてしまおうかなという気持ち

ちゃんとした自分なりの完璧ものを作ろうとするなら仕事ではなく趣味で作ってるツールライブラリ

やればいいかと思う


作ったもの次第でユーザが集まる自社のウェブサービスパッケージ商品ゲームなどは作り込む方が

良いと思うが先に値段が決まって受注して作るようなものだと最低限の要望さえ満たしていればあとは

どうでもいい

しろ不便な方が改修依頼が来て稼げる

さらには綺麗で完璧な作りで大抵の想定できる改修は1日とかからないようなものに仕上げるよりも

どこ変えればいいかや影響範囲すらわからいくらいモノのほうが実作業時間が多いのでそれだけ請求できる

先に作り込むメリットがない


ストレスが溜まってきたので発散がてら書いてみたけど疲れてるのかわりと分かりづらい文章になった

けどまぁいいか

そろそろ転職でもしたいなーと考え始めた










2018-09-12

セキュリティクラスタに対する愚痴1

連中が非常に気難しい、偉そうな特権階級ぶっている部分が昔から嫌いだった。

なおかつ身内びいきや馴れ合いが酷いので、閉鎖したコミュニティ形成しており

新規参入者などは、今いる身内を経由しての紹介でしか生き残っていけない。

勉強会や集まりに参加して仲良くなろうとしても、連中の中では既にコミュニティが出来上がっているから仲良くなる隙も無いのである

最近は嫌気が差してきて、交流すら絶ってしまった。

彼らは自分の気に入らないことがあるとすぐSNS晒し上げて犯罪者のごとくボロクソにけなすという行為が多々見られる。

例、専門家を語る人がズレた発言をすると吊るし上げる。ベンダミス政府の甘い対応を目にすると蛇蝎のごとく叩きまくる

最近では「ホワイトハッカー」という呼び方にすらけちをつけ始め、『俺たちはそんなクソダサな名前で呼ばれたくないからやめろ』みたいなことを言い始めた。

いいご身分だなと思う反面、そんなくだらないことで熱くなれる人たちが同業者なのだと思うと悲しくてならない

いくら技術力が高かろうが、こういう連中とは仕事をしたくないなという愚痴

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