  |
はてなキーワード: ベンダとは
エンタープライズ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部門と多重下請のケツ叩きに無駄な時間を使うより、自分たちがベンダと組んで一緒に企画、開発、運用を進める方が効率的かもしれない。今日の企画を来週にリリースできたら最高ではないか。小さくリリースして学びを得て改善していく。
ここ連日騒がれている7pay。
パスワードリセットリンク送付先のメールアドレスに対して設計上の問題で脆弱性が発覚して大変な事態に発展しています。
昨日の会見では社長のITリテラシ不足が露呈したり、サービス継続が表明されたりして、いわゆる「祭」の様相を呈しています。
また、会見内で「セキュリティー審査を実施した」と明言がされました。
https://www.asahi.com/articles/ASM745HHHM74ULFA01Y.html
セキュリティー審査を実施していたにも関わらず、何故今回の問題が見逃されたのか。
非常に稚拙な推測ですが個人的に考えられる可能性をまとめてみようかなと思います。
その名の通り、サービスローンチ前に実施する、脆弱性や問題がないかの審査の事・・・だと解釈しました。
一般的には脆弱性診断とかセキュリティ検査とも呼ばれています。私はこちらの呼び方の方がしっくりきます。
「実施した」とはいっても、どういった内容を実施したかはわかりません。
ただ、7payは「一般に公開する」「お金を扱うサービス」になるため、ガチガチな脆弱性診断を実施すべきでしょうし、実際に実施したのではないかと思います。
通常、脆弱性診断というと、以下のような項目があげられると思います。
抜け漏れあると思うけど、大体どこのセキュリティベンダーでも上記のような項目を診断しているんじゃないかなあと思います。
詳しくは各ベンダの診断内容のページを見てみると更に詳しく載っています。
LAC、CyberDefence、NRIセキュア、ブロードバンドセキュリティ、スプラウトなど。
ただ、今回の脆弱性診断が外部ベンダで実施されたのか、内部で実施されたのかはわかりません。
以下、推測をつらつら書いていきます。
脆弱性診断はモノによりますが、診断内容をマシマシにするとエラい額が掛かります。
Webサービス診断は見積もり方法が各社違ったり、ツールを使うか手動とするかによって金額も大きく変わってきます。
また、数量計算もベンダによってまちまちです。ページ単位であったり、画面遷移単位であったり、SPAであればAPI単位であったり、複合での計算だったりします。
お願いすれば見積もり時にステージング環境で動いているWebサービスをクロールして、各ページの評価を付けてくれるベンダもあります。
規模と見積もり内容にもよりますが、100～200万といったところでしょうか。
スマホアプリ診断は一本幾らという場合が多いような気がしますね。相場としては50万～100万程度でしょうか。
プラットフォーム診断も内容によるとは思いますが、大体100万くらいかなあと思います。
これ以外にWebSocketを使っていたり、別のサービスと連携していたりするとその辺りの通信も含まれてくるのでまた金額は上がる可能性もあります。
Webサービス200万、スマホアプリ(iOS、Android)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というサービスは自動での定期診断が可能なようです。
ライセンスやどういった動き方をするのかはいまいちわかりませんが、ベンダに逐次依頼する脆弱性診断よりかは安く済むはずです。
ただ、自動診断となると設計上の不備やそれに伴う問題は検出できないはずです。
ツールの手が届く範囲での、XSSやPoC、ヘッダの有無など、ごく一般的な脆弱性診断になると考えられます。
でも手軽そうで安価っぽいなので、これで済ませていても不思議ではないです。
脆弱性診断ツールは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は社内的にも一大プロジェクトだったはずで、スケジュールも決まっている場合、余計なことを物申すと手戻りや対応に時間を取られることになります。
そういった事を許さない空気が出来上がっていると、まあ中々上には上がってきづらいです。
これも十分にありえる話ですかね。ないといいんですけど。
どうしても『審査』という言葉に引っかかっています。『検査』ならまだわかるんですが。
そこで思ったのですが、情報セキュリティ基本方針と個人情報保護方針を元にしたチェックリストのようなものがセブン内にあって、それを埋めた・・・みたいなことを「セキュリティー審査」と言っていたりするのかなと思ってしまったんですね。
でもこれはセブンペイの社長が個人情報保護管理責任者ということで、ISMSやPMS等で慣れ親しんだ単語である『審査』を使っただけかもしれません。
そもそもそれで終わらせるなんて事ないでしょう。セブン程の企業が・・・。
大穴ですね。いやこれはないと思いますよ。あったら大問題じゃないですか・・・。
というわけで、なんとなく「こうだったりして・・・」みたいな事をつらつら書いてみました。
そういえばomni7で以下のお知らせが上がっていましたね。
https://www.omni7.jp/general/static/info190705
『定期的にパスワードを変更いただきますようお願い申し上げます。』とのことです。CSIRTはもしかしたらもう機能していないのかもしれないですね。
もしくはわかりやすい対策を提示しろと言われたのかもしれません。それなら仕方ないんですけど。
以上。
一部typoとか指摘事項を修正しました(役不足→力不足 etc)。
ついでに時間経ってるけど追記します。もう誰も見ないでしょうけど。
ちゃんと読んでいただけましたか？全文通して私の主張が「監査をしっかりやれば防げた」という意味と捉えられているのでしょうか。そんなに分かりづらい文章を書いた覚えもないのですが・・・。
一番上でも記載していますが、私は今回の7payの「セキュリティ審査」は、「脆弱性や問題がないかの審査の事」、つまり「脆弱性診断」を指していると仮定して本エントリを書いています。
そういう意味で、ここで私が指している「審査」と貴方が指している「監査」は似て非なるものです。字面は少し似ていますがね。
監査は貴方の記載する通り「ある事象・対象に関し、遵守すべき法令や社内規程などの規準に照らして、業務や成果物がそれらに則っているかどうかの証拠を収集し、その証拠に基づいて、監査対象の有効性を利害関係者に合理的に保証すること」です。
貴方の言う「監査」に近いことは「セキュリティー審査自体が、情報セキュリティ基本方針と個人情報保護方針に沿った内容かどうかを確かめただけだった」の見出し部分で触れていますが、それで終わらせているわ Permalink | 記事への反応(2) | 05:48
元増田です。
しばらく見ないうちにプチバズってたのでちょっと驚きました。
はてブや言及コメントも拝見し、いろんな意見があって面白かったです。
否定的な意見の中で代表的なものについて、いくつか反論（補足？）しておこうかな、と。
元記事と違って完全に私個人の主観の話なので、NTTに勤める人の一般的な価値観ではないことはあらかじめ言っておきます。
「無能だから転職できないんだろ」みたいなニュアンスですね。半分正解、半分不正解といったところでしょうか。
そもそも失職や転職のストレスを一生味わいたくないから今の会社を選んだので、転職してやっていくためのスキルや経験を積む必要性を感じていません。
少々自分語りになりますが、私の父は私とは真逆の仕事第一で家庭を顧みず、中小企業勤務で倒産や転職を繰り返した人でした（いまも働いているけど）。
加えてギャンブル好きなのでたまの休みもパチンコに行ってしまうため、家計は火の車で、家に借金取りが来るから知人の家に避難するなんてことも割と日常茶飯事。
そんな父を反面教師として育ったためか、物心ついた頃から「仕事はほどほど、家庭と趣味に生きよう」と決めていました。
実際に就職したり家庭を持ってみて、この判断は正解だったと思っています。
私は器用ではないので、妻との夫婦生活、子供の世話や将来に向けた教育・投資、加えて自分の趣味も充実させようとすると、とてもじゃないけど仕事のことを仕事中以外に考える暇も余裕もありません。ましてや転職なんてもってのほか。
私にとって仕事は完全に金を稼ぐ手段であって、それ以上でも以下でもないのです。
もし退職するとしたら、そこそこ軌道に乗ってきた副業（というか趣味がたまたま金になっている）がさらに伸びて、その収入と資産運用だけで死ぬまでやっていけるフィナンシャルプランが完成した場合ですね。
かなりリスクを避けたい性格なので、今の会社で定年まで勤めた場合の生涯賃金の倍額くらいの収入が得られるプランじゃないと辞めないと思いますけど。
そうですかね。ここは学生時代からかなり吟味した結果なので、割と自信をもって「大丈夫」と言えます。
一番安定している公務員は、副業禁止を始めとする縛りが強すぎて却下しました。収入も世間のイメージよりだいぶ低いですしね。
次に挙げたのがインフラ系で、最後まで迷ったのが鉄道会社、電力会社、そして通信会社でした。
いずれも産業革命レベルの発展が無い限り業界自体は安定です。加えて各企業の大株主の構成（というか国や自治体の資本がどの程度あるか）、財務諸表などを加味して選びました。
最終的にNTT(所要5社)が就職先候補に残り、その内2社にエントリーして内定をもらった結果、茸に行くことに決めました。ここが潰れるときは日本の終わりだと思ってます。日本が終わったら自分も終わりでいいかな、と。
出ました。コーディング至上主義です。特にSNSでは「コーディングできないSIer vs プログラマー」みたいな話がウケますね。
システムを世の中に出すのに必要な仕事はコーディングが全てではないですよ、としか言いようがありません。パン屋に必要なのはパン生地をこねて焼く人だけでは無いですよね。
ちなみに私自身は学生時代にコーディング経験がありますが、社会人になってからは仕事でコードを書くことはありません。
外部設計はもちろん内部設計のレビューやバグが出てログ解析する際の一次切り分けにソースコードを見たりするので、一応関わっている開発プロジェクトの言語知識はあります。
数年前に開発部に異動してきてから業務時間中に学んだものであって、業務時間外にわざわざ勉強したりはしていません。
私は自分のことをエンジニアだとは思っていませんし、一生開発業務をやるわけではなく「今は開発職」というだけです。
そもそも弊社は3～5年周期で社内異動を繰り返す（いわゆるジェネラリスト育成）ため、深く狭い知識より広く浅い知識を身に着けるスタイルになります。
・PowerPointでシステムのグランドデザインを書ければ、あとはBPが仕様書に落とし、ベンダが作ってシステムが出来上がる
・tableauで分析データを出せれば、あとはコンサルが改善案を出してくれる
・Prottでプロトタイプを作れれば、あとはデザイナーがデザイン仕様に落とし込み、ベンダが作ってWebサイトが出来上がる
ちょっと大げさに言えば、部署は違えど弊社のプロパーの仕事はだいたいそんな感じです。だから、自分で手を動かすことにやりがいを感じる人には向きませんよ、と言ったのです。
私が一番驚いたのは、想像以上に仕事にやりがいや人生における重きを置いている人が多いことです。
弊社にいると、管理職含めて「仕事はあくまで仕事、家庭や趣味が最優先」な人が大半なので、かなりカルチャーショックでした。
私はとにかくコスパ重視の人間なのですが、今の収入と労力のバランスは最高だと思っています。
もちろんもっと勉強して資格を取ったりガンガン外部で活動して人脈を作って高給の企業に転職すれば、収入は多くなりますが、私にとってそれはコスパが悪いのです。
今以上に安定している企業は無いであろうという理由もありますが、加えて私生活の時間を犠牲にすることへの抵抗が大きい。
「年間300時間も残業してワークライフバランスとか社畜かよ」というコメントもあったので、ちょっと気になって昨年度の労働時間を調べてみたところ、残業込みでざっと1900時間。
まぁ上を見ればきりが無いですが、そんなに長くは無いかなと思います。今の生活基盤を維持するには、それくらいは仕事に費やさないと罰が当たるんじゃないかと。
あと、こればかりは個人差が大きいと思いますが、私はもともといっぱいいっぱいの状態で何かをし続けるのがとても苦手なので、ゆるゆるの環境が好きなのです。
だから、スキルの高い人たちが集まり切磋琢磨しあって互いを高め合う、ちょっと勉強をサボるとおいていかれてしまう、そんな環境はたとえ高給でもお断りです。
弊社はだいたいどの部署でも勤務中の脳ミソの平均CPU使用率が20％くらいで仕事が回るので、理想的です。
私は人生でもっとも頑張る期間を高校生の3年間と決め、予定通りそれを終えました。
現役で国立大に合格し、自分で学費を稼いで大学院まで進み、失職や転職のストレスに悩まされないホワイト企業に進む。これで人生の基盤が完成した、と喜んだものです。
今はその基盤の上で、自分の趣味や家庭生活、育児に教育とやることが盛りだくさんなので、基盤の変更やアップデートにかけるコスト（時間）は持ち合わせていません。
なお、一応仕事も世の中にそれなりにインパクトを与えるものやサービスを提供し、フィードバックを得られるので、仕事自体のやりがいも皆無というわけではありません。
仕事でかかわる社内外の人も良い人が多くて、その点もとても満足しています。
今より給料が多く、今より労働時間が短く、それでいて一生潰れない会社に、ローコストで転職できるチャンスが来ない限り、転職することはないでしょう。
現場の担当者が自分の判断でマクロ作ったりするのはアリだと思うんだけど
それをズルだという謎の風潮が一部であるのをネットで見るたびに笑いが止まらない。
お仕事を簡略化するためのマクロをいくらでも書かせていただきますよ。
ぜひこの機会にRPA導入をお手伝いさせていただければと存じます。
目安としては自動化したい担当者様の業務内容1件あたり10営業日前後でご提供できればと考えております。
スムーズに作業を進めるために各担当者様には自動化したい内容をあらかじめまとめて頂き、そして弊社エンジニアの前でその業務を実演、撮影をいたしまして、それをもとにRPA導入について検討してご提案させていただきます。
また毎日ステークホルダー全員を同席の上で進捗報告、方針確認等させていただければと存じます。
システムの仕様変更によってRPAが動作しなくなった場合、そちらはアフターサービス契約による対応とさせていただき、アフターサービス基本料とは別に別途工賃を頂戴いたします。
仕様の変更次第によっては対応できない場合もございますのでご了承願います。
なお、弊社への丸投げは必ずメテオフォールになって失敗するので絶対に許さない所存ですので最後まで毎日お付き合いいただきます。
くらいの意気込みでセールスしたい。
1件あたり200～300万円くらいとれないならやる意味がない。
まあ要は不透明なのが一番不味くて誰が総理大臣でもこれやられたらたまらんのだけど、とりわけ今の内閣は政府運営の透明性向上にまるきり興味がないので余計にたまらんという話
米Cisco Systemsを知っているだろうか。スイッチとかアクセスポイントとかのネットワーク製品を手がける米国の大企業だ。
実は日本でも企業向けのシェアは50%近く、10年前から「もうCiscoの時代は終わる」と言われ続けていたがしぶとく残っている。
だが、そんなCiscoも今度こそ終わりを迎えそうだ。
発端となったのは一年前、Ciscoは製品のソフトウェアライセンスの新たな管理形態を発表した。
簡単に言うと、Ciscoの機械で動かすソフトウェアライセンスをインターネットで認証するというものだ。ちょうどWindows XPのライセンス認証のように。
何が問題になるかというと、ネットワークの世界とインターネットは極めて親和性が低いのだ。あまり想像がつかないと思うが、例えばスイッチやルーター、ファイアウォールといった機械は、インターネットに接続されていないことがままある。
例えば、データベースサーバーを接続するスイッチをセキュリティのためインターネットと直接接続しないというようなことは、割とどこでもやっている。なので、この馬鹿げたアイディアはすぐに撤回されるだろうといった予想が我々業界人の感覚だった。
最近、Ciscoは最も普及しているスイッチで、新しいライセンス形態のみをサポートするソフトウェアを発表した。
どんな影響が出るだろうか。まず、金融機関などのミッションクリティカル系がCiscoを使うのをやめる。金融は止めたときの影響が大きすぎて、わざわざインターネットと接続してライセンス認証するより他の機械を入れたほうがリスクが少ないと判断される。
これを見て、多くのデータセンターがCiscoを使うのをやめるだろう。なぜなら他のベンダの機械でミッションクリティカル系が使えるのであれば、わざわざCiscoを使う必要もないから。また、みんな高いCiscoを使うのを、本当はやめたがっている。
例えばCisco Systemsの製品が主にIAサーバーで動くとかなら、インターネット認証もやむ得ないだろう。でも、この会社はもともとハード屋だ。なぜ買ったものを動かすのに、インターネット認証が必要なんだか理解に苦しむ。
意味不明なものが多いし何かとケチつけないと気がすまない性格だから面倒なことを一々と
直接のユーザからの意見なら多少は変でもそのユーザが必要としてるなら納得できるし、イライラすることもない
社内でそんなことこだわったところで実際には気にされないことが多いのにだ
まだデザイナーがデザインについてこうした方がUXがいいねみたいなことをいうならわかる
専門の人の意見だし
そうでもないのに何かと文句をつけてくる
CSS すらまともに使いこなせずマージンもパディングもないような酷い作りのものしか作らないのにソッチのほうが良いという
色は red, green, yellow と標準のペイントのデフォルトカラーかよというような色を指定してくる
#fcfcfc や #0a0a0a なんて使おうものなら白と黒にしろと
max-width を指定せずに画面の端から端まであるようなものがいいという
今の時代のアプリやサービスを全く見てないのか？としか言えないようなセンスだ
自社サービスなんて手を出したらこれは酷いと話題になりそうなものだ
見た目にあまりこだわれない社内用サービスしか作ってないからと言って、その他サービスをみてる人からすれば明らかに
しかもデザインに限ったことではないがまだ序盤の時点で言っておけばいいものの完成後にいまから変えるなんて難しいのが
わかりきってるようなときになってからああしろこうしろ言い出す
先に書いたようにユーザの要望ならまだ仕方ないと言えるがなぜこんな無意味なことに付き合わなければならないのか
わりと自分が完璧主義なところもあるので作るならちゃんと作ろうとしてるんだが
こういうのを相手にしないといけないせいで結局グチャグチャになってくる
色のバランスやレイアウトを考えたところで一瞬でそのバランスが無意味になるようなことになる
プログラム側だって全然関係ないものを無理やり入れ込まないといけないようなことになることも多い
疎結合だとかグローバルをつかわないとかそういう作りやすくするためのことをしていても
それが維持できないような無茶で無意味な指示が出る
根本的に変えたり対処するためのものを作るとかすればなんとかできなくはない
過去のプロジェクトでもそういうのが多いから自分で作るのくらいは扱いやすくしたいと考えていたのだが
過去に言われたものだと速度を優先だとか言って自分で作ったものよりは遅くするなと言う
しかしながら関数は使わずコピペだわforeachなどは使わずループ変数を使って地道にやるなどメンテナンスが
できる気がしないが速度においては早いと言えるものだ
当たり前のようにグローバル変数がいっぱいあるしライブラリの使用箇所はカスタマイズするための仕組みがあるのに
便利で読みやすいような書き方だと速度的にはそれに劣る
だがわざわざそんな扱いづらいし見づらいコードは書きたくない
そんなに速度にこだわるなら勝手に一人で機械語でも書いてろよって思う
どちらか取捨選択すべきものなのに両方みたせとか無理なことを言う
ちなみに便利なライブラリは基本無駄が多い遅いものだからライブラリ頼みのベンダはクソだとか
能力がないだとか言っていた
そういえば昔先輩社員と仕事したときには変に凝ったものとか必要以上に作り込んだりはしないほうがいいとか
言っていてそれなりに手抜きでさらっと一応は動くようなものを作っていた
私はそういうやり方が嫌いだったのだが今ではこういう環境に長くいた結果仕事のものにこだわって作り込んでも無駄
ということがわかってそうなったのかなと感じた
自分でもサビ残や休日に無償出勤してまでいいものにしようと努力はしていたが謎の指摘に合わせていると
愛着もなくなってきたし後は適当に済ませてしまおうかなという気持ちだ
ちゃんとした自分なりの完璧なものを作ろうとするなら仕事ではなく趣味で作ってるツールやライブラリで
やればいいかと思う
作ったもの次第でユーザが集まる自社のウェブサービスやパッケージの商品やゲームなどは作り込む方が
良いと思うが先に値段が決まって受注して作るようなものだと最低限の要望さえ満たしていればあとは
どうでもいい
むしろ不便な方が改修依頼が来て稼げる
さらには綺麗で完璧な作りで大抵の想定できる改修は１日とかからないようなものに仕上げるよりも
どこ変えればいいかや影響範囲すらわからないくらいモノのほうが実作業時間が多いのでそれだけ請求できる
先に作り込むメリットがない
ストレスが溜まってきたので発散がてら書いてみたけど疲れてるのかわりと分かりづらい文章になった
けどまぁいいか
そろそろ転職でもしたいなーと考え始めた
ITベンダの俺の職場のパソコンがとにかく低スペックなのである。予算がないだのなんだのいいながらちっとも買ってくれないのである。2018年も半分以上過ぎているのに、メモリは4GBしか乗ってないし、画面も狭いノートパソコンが、ただあるだけである。
会社は働き方改革を推進している。定時で帰らなければならない。作業を効率化して、生産性を上げて。もちろん、会議を削ったり、タスクの優先度をつけたりして生産量を上げる努力はしている。でも開発効率はなんともならない。だってパソコンが重いんだもの。でもパソコンは買ってくれない。
とかくフリーズするのである。rails s でデーモンを立ち上げてChromeでみたいし、インスペクタでDOMも解析したいんだけど、そうするとフリーズするのである。もちろんRuby Mineなんてない。買ってもらえないし、あっても動かないからである。
新技術も使ってみたいのである。できればdockerなんかも使ってみたい。CI組んでみたい。でもパソコンが耐えないのである。
同時にスマホアプリ開発は死ぬのである。Android Studioを立ち上げると、パソコンが。とまるのである。
動かない場合はどうするか。
ひたすら「待つ」のである。
ブラウザがとまると、要するにスワッピングしてるんだけど、そうすると数分待たされる。もちろんSSDなどでなくHDDだ。スワッピングならまだいい。パソコンがフリーズしていたら、さらに待たされる。そもそも画面に反応がないので、スワッピングしてるんだかフリーズしてるんだかわからない。とりあえず再起動するしか方法がない。
なぜパソコン、ひいてはエンジニアの環境に投資しないのだろうか。環境が整えば、1日に1時間は効率化できる。ざっと30万の投資としても、2ヶ月程度で損益分岐点に達する。精神面でいってもエンジニアは安心・満足するし、そうすると意欲的な開発ができる。使える技術の幅が広がることは管理職にとってもメリットがあるはずだ。こんなに簡単な判断をなぜ会社はしないんだろう。
我々はどうも苦労がどこかで報われると思っているようだ。これだけ苦労しているのだから、いずれなにかよいことがある。今苦労しておけば、明るい未来が待っている。贅沢しないのだ、敵だから。欲しがってはいけない、勝つまでは。
富豪的環境でなく貧者な環境で開発していると、最新環境でなくレガシー環境で開発していると、IDEでなくEmacsで開発していると、そのうちその努力は報われると思ってしまうのである。
競合は常にいろんな最新兵器を使っている。鎖国している俺の職場からは何も聞こえない。聞こえないフリをしている。攻め入られても竹槍でやりかえせばいいのだ。だから、今のこの環境で頑張る意味はあると。
警告は JS:Includer-BJQ [Trj] で、JavaScriptによるトロイのリンク埋め込みの判定だ。
ウイルスバスターなど、トレンドマイクロ社の製品でも遮断されるという報告がある。
警告はJS/CoinMiner.AEで、トロイのうち、仮想通貨マイニングスクリプトの判定だ。
しかし、念のためにオンラインURLスキャナーに掛けてみると、
https://virusdesk.kaspersky.com
共にSafe/clearの判定なのである。
rescan.proではHTTPエラー403以外SAFEとの事だが、そもそも403食らって何故スキャン出来るのか？
炎上しているので嫌がらせ登録された可能性もあるが、ユーザーのpostだけでブラックリスト入れるほどユルイセキュリティベンダもない筈だ。
ニュース解説 - 日本郵便がハード保守契約を全面見直し、ITベンダーの反発は必至：ITpro
冗長構成ってのは、方系が故障したときにもう一方が動作しているから問題ないという仕組み。つまり、もう一方が稼動している最中に元の方を直せなかったら業務が止まる。この業務停止時間の影響を抑えるために冗長構成は組まれる。欧米は業務が止まっても顧客は許すし職員は諦めて酒飲み始めるのが許容される文化。日本はサービスが10秒切れたらクレームがくる世界なんだぞ？その世界で堂々と「壊れたのだから仕方ない」といえるような会社と仕事だけが冗長構成いらんといえる。
クラウド使えばいいとか、仮想化すれば大丈夫とか、果てにはVMWareを使うからとか言う人まで出てくる始末。不思議なコメントを抽出。
id:z1h4784 日本郵政 の社内インフラはvSphereのHA構成になってたりするの？であれば確かに可能かもしれない。ただそんな話は全然聞かないんだよなあ…。
vSphereのHAが何だか知ってる？VMWareがHA構成かどうかとその下のハードウェア構成がどう組まれているかはぜんぜん別の話だぞ？
id:s025236 "ハードが故障した際に1週間放置してみた。「それでも業務に全く支障が出なかった」"←これ不要なハードな気がしてならないのだけどハードの見直しが先では
ハードが何を意味しているか想像できてる？RAID組んでるうちの1本が壊れたのを放置してたけど偶然もう別のディスクは壊れなくて問題なかったとかいうレベルなんだけど理解できるだろうか？
id:sakidatsumono いっそクラウド化すれば
クラウドを使えば障害対応から逃れられるとか夢見ちゃってませんか？インフラってそんな単純な世界じゃないですよ？
転職かぁ
スルガ銀行のシステム開発にかける覚悟が表れたのが、日本IBMとの訴訟です。同行は基幹システムの開発を日本IBMに依頼しますが、契約通りに開発できなかったとして'08年に損害賠償を求めて提訴しました。
これまで日本企業の多くはシステム会社に対して要求された額を唯々諾々と支払ってきましたが、スルガ銀行はその悪習にも風穴を開けたんです。
判決は、日本IBMがスルガ銀行に約42億円を支払えというものでした。これで他のシステム会社も、スルガ銀行には開発費をふっかけられないと思い知ったことでしょう。その結果、システム開発費は他行より安くなっているはずです」（前出・加谷氏)
スルガ銀行には開発費をふっかけられないと思い知ったことでしょう。その結果、システム開発費は他行より安くなっているはずです」（前出・加谷氏)
いや、むしろ高くなってるだろ。この案件はパッケージ使って安価に作りましょうってスタートしたが、そのパッケージではスルガの要望に全部は沿えないってのが判ってきて、仕切り直しが泥沼化して契約解除なのだから、次のベンダーは(見えていない)リスク分を多めに積むようになるでしょ。ふっかけたのがばれたんで、金返せとかじゃ全くないし。(泥沼の中で色々やらかして不信感持たれたとかもあるようだけど)
今回の京都市の例もそうだけど、システム開発には地雷多すぎで当初見積もり金額で一括受託は無理ありすぎるよなぁと。その辺りのリスクをユーザとベンダが納得する形でうまく扱える契約形態が一般的にならないものかと妄想中。米国にはいろんな契約形態があるっぽいが良くは見てない。ベンダーのスキルが～とかユーザーのシステムに関する知識が～とかもあるがその辺は置いておく。小さなプロジェクトだとSESでアジャイル系ってのが一番良いのだろうけど。なんか良いのないですかね～、正直大手SIerも新規ではぶっこきまくってるから欲しいはずなんだけどなぁ。まぁ、下請けに被せてるから良いっすと思ってるかもだが。
http://itpro.nikkeibp.co.jp/atcl/column/14/346926/101101158/
Q1.役所の仕事なんて全国でほぼ一緒なのに、なんで自治体ごとに別のシステムを作るの？
A1.地方自治体の事務や財務について法律で決まっているのは大枠だけだよ。
それを実務≒内部規定に落とし込むのは各役所ごとなので大枠は似てても実務プロセスは全然各役所で違うよ。例えば同じ業務でも独自の語彙があったり、下手すると同じ語で市町村ごとに意味が違ったりするよ。
Q2.なんで新規で作らないの？
A2.80年代ぐらいにやったよ。その結果が政令市クラスに残ってて今回京都市が更新しようとしてるような、メインフレーム上のシステムだよ。
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が汎用機の付属品みたいについてって、困ったらオペレーターとして介入して動かしていたみたいだよ。
そうやって現場感覚バリバリでやっているので、オペレーターしか知らないプロセスがあったりするよ。
マイグレーション開発では総合テスト中にそういう隠しプロセスが「発見」されたりするよ。こわいね。
上記の通り仕様書がないことも多いうえ、システム課に限らず市役所の人員は基本ローテーションするよ。
導入当初の担当者が残っていることは珍しいし、30年も前に導入した汎用機のことなんてここ10年に入った職員にはわからないよ。
Q7.なんで入札にしたの？ 現行ベンダに指名してやらせたほうが良くない？
A7.金額がでかいから、たぶんどこの市役所でも入札案件だよ。
随意契約（随契）は無理だし、入札業者を発注者が指定する指名競争入札は談合の温床になってたから最近はあんまりやらないよ。
（裏技としてRFPを指名したいベンダーに書かせて公募型指名入札にしたり、RFPの段階でハードを全部特定ベンダで型番まで指定するというのがあるけど、公になると多分問題になるよ。こわいね）
Q8.じゃあ役所は悪くないの？
Q8.悪いよ。
入札案件はRFPで書かれた各項目をどれだけ満たすかの技術点と、価格点で決まるよ。点が高ければだいたい自動的にそのベンダーに決まるよ。
なので、技術点の項目に現行システムの調査にかかる項目を入れるとかして、現行機の開発・保守ベンダが高得点を取れるようにしておけば価格勝負してくるベンダーをはじけた可能性はあるよ。
もちろん現行の会社に嫌われて逃げられたとか、役所が現行の会社をめっちゃ嫌いになって声をかけなかったとかもあるかもしれないけれど、可能性は低いと思うよ。
A9.ここまで述べたようにこの手のマイグレーションは火薬庫だよ。火を噴いても爆発しなければラッキーぐらいなので、強いて言うなら入札したことが悪いよ。
A10.前にマイグレーションをやったことがあるSEだよ。もうやりたくないよ。今は転職してSIerじゃなくなったからやらなくてよくなったよ。うれしいね。
しょぼいSEだからここに書いたことは個人の体験に基づく参照情報だよ。一般的じゃないことを言ってたり、間違ってたら教えてもらえると助かるよ。
(2017.10.13 追記）
Q3がかぶっていたよ。恥ずかしくてなきそうだけどブコメに番号で言及してくれている人がいるから忍んでそのままにするよ。
あと、「オープン化」の定義が違くない？という指摘があったよ。確かに増田が間違っていたので、記事の主旨から外れるけど補記するよ。
メインフレームは本文で述べたようにOSからハードまでメーカー謹製なので独自仕様のカタマリだよ。
これに対しPCサーバは標準規格で作られているよ。こういう標準規格に基づくサーバをオープン系と呼ぶよ。
独自規格でクローズしたコンピュータから、そうでないオープン系に移行するからオープン化なのであって、専用線とかは関係なかったよ。半可通な知識で語ってしまったよ、ごめんね。
京都市で火中にいるシステムズさんのサイトの解説がこの増田よりも分かりやすくて正確だから気になる人は見てほしいよ
http://www.migration.jp/column/column01.html
完全に余談だけどオープン系のx86サーバに移行しても、システムはそんなにオープンにならなかったりするよ。
H系に頼むとDBが拝承DBになったり、Fに頼むとシステム管理が全部SystemWalkerになったり、要するにベンダ独自のミドルに入ってがっつりロックインされたりするよ。
アップルのジーニアスって、あまりジーニアスだと感じた事がない。
スペシャリストという肩書きの人も、会話中の早い段階で諦めを感じてしまう。
こちらがわからない事はわからない、というのでは、時間の無駄で、
それならあなたのフィルターが邪魔になるので直接こちらから問い合わせした方がいい、と内心思う。
結局、海外のフォーラムに書き込みして訊いてみるのが一番早いのは、
アップルの場合は、なんていうか雰囲気とドヤ顔でごまかしているようにしか見えないんだよね。
わざわざ予約して時間作って行っても、ドヤ顔の客と店員の高い意識の雰囲気は私には暑苦しい。
でも、そんなアップルストアが好きな人も多いのも理解はしている。
ちなみに、マイクロソフトは、チャットでそのまま話を聞いてくれて解決も早かった。
PowerMacで漢字トークを使って、ResEditでリソースフォークをいじりつつ、
RealBasicでプログラムを書き、HyperCardスタックを作って遊ぶ。
暇つぶしにMKLinuxをインストールしたりしてた、過去のパワーユーザにとっては、
歴代で一番好きな好きなノートパソコンは、PowerbookG3。
ジョブズが戻ってきて、人気の出たスケルトンで5色のiMacは好きでなかった。
Palmを持って、iPod第三世代にLinuxをインストールしてお茶を濁したりしてた頃、
VAIOとクリエを持っていた回りの人間は現在は皆、iPhoneとMacBookAirを持っていて、
表面に変なシールを貼っている。
