  |
はてなキーワード: SIerとは
某大手SIerと共同でアプリ開発することになった。そこで、とあるプロジェクト管理ツールで進捗管理することになったんだけど、先方が
って文句をつけてくる。確認したら、アカウント登録後の確認を行っていないことが分かった。メールに記載されたURLにアクセスすることで、登録確認する奴な。だから、
「アカウント登録後に、登録したメールアドレスに確認メールが届くから、24時間以内にそこのURLをクリックして下さい」
という案内をした。ところが、いつまで経っても奴らはユーザ登録を完了して来ない。たかがワンクリックするだけなのに。このままだと、こっちも仕事が進まないから非常に困る。
一体どうなっているのか聞くと、どうやら「このURLをクリックしていいですか」という許可を上長に取らなければいけないらしい。その承認に2日くらいかかるから、いつまで経ってもユーザー登録ができないらしい。
アホかと思った。本件に限らず、こいつらとの仕事は何かとストレスが溜まることが多い。IT企業なのにとにかく技術力が低すぎるし、それ以前に常識が無い。上の件だって、そんな承認を取ることに何の意味も無いことは小学生が考えたって分かりそうなものだ。
俺も以前は、ネット上で「SIerはクソ」と言われてるのは、一部の人が大袈裟に言っているだけだと思っていたが、全くそんなことは無かった。本当に技術力が低いし、意味の無い仕事で関係者全体の仕事を遅らせている。
オープンソースcURLの作者、某大企業から「24時間以内にこの質問に答えるように」との無礼なメールを受け取る － Publickey について思ったことをつらつらと。
log4shell と呼ばれる脆弱性が 2021 年 12 月にあった。これは Java というプログラミング言語でプログラムする際に、動作のログを記録するのに非常によく使われるライブラリ log4j にとても危険な脆弱性があった。なにがそんなに危険かっていうと
マインクラフトのサーバが乗っ取られたとか被害も有名。詳細は Piyolog さんの Log4jの深刻な脆弱性CVE-2021-44228についてまとめてみた - piyolog あたりを参照。
そんなわけで即座に影響範囲、脆弱性のない新しいバージョンになっているか調べろ！って IT 関連企業はとてもバタバタしていた。
という背景の中、オープンソースのソフトウェアである cURL の作者にとても失礼な log4j の問題に関する質問メールが送られてきて、「サポート契約すれば即座に教えてあげますよ」ってかっこいい返しをして盛り上がっている。
cURL (https://github.com/curl/curl]) はオープンソース(以下 OSS)の通信ライブラリとコマンドラインツール。 Linux などのサーバ上からファイルをダウンロードしたりするのにとてもよくつかわれるライブラリ。
C言語で書かれている。
ライセンス は MIT を参考にした独自ライセンス https://curl.se/docs/copyright.htm]
OSS は基本的に無保証で提供される。そのことはライセンスに明記されている。
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
そんな OSS に対して、
「あなたがこのメールを受け取ったのは、■■があなたが開発した製品を採用しているためです。私たちはこのメールをあなたが受け取ってから24時間以内に、お読みいただいた上でご返答いただくよう要求します」
といった上から目線のメールを開発者に送るというのは、IT 企業として無知にもほどがあるといったところ。加えて log4shell 問題、名前のとおり log4j の脆弱性なので Java でかつ log4j を使ってなければ影響はないのに、C言語でかかれた cURL に問い合わせているので問題を全く理解していない。(Java の j が消えるので log4shell という命名はどうなんだというのは個人的にある。つーか Poodle とか Spectre とかファンシーな名前つけてあそんでんじゃねーとも思う。)
なお cURL はどうやら開発者の Daniel Stenberg 氏が wolfSSL というところを通じて商用サポートを提供しているらしい。 https://curl.se/support.html]
ということで、「サポート契約を結んでいただければ、喜んですべて速やかにお答えしますよ」 というのはネタでもなんでもなく、普通の対応。
そしてブログに書いてある2回目の返信で、David と名前を間違えられたのに対して、Fotune 500 の巨人ということで "Hi Goliath," と返しているのも最高にクールですね。
こういうフローが事前に規定されていて CVE とか問題が検知されると発動する。このときに担当が大丈夫です！って回答するときにエビデンス（証拠）を求められるのだけど、クソな情セキは自社の担当の言葉を信用せず、開発会社からの言質をとれ！って命令するので、くそメールがスパムされるという背景があったりする。（担当が無知だったりイケイケだと、とにかく下請けにやらせればいいというパターンももちろんある）
そして情セキも経営層に報告するのに必要で、経営が0リスク信者だと報告が大変なのはわかる。わかるがそれを説得するのが情セキの仕事やで。
加えて担当レベルになると大手は「そんなん下請けにやらせればいいだろ」ってマインドのところが多く、上から目線かつ丸投げすることが多いように思う。
もちろん担当者はピンキリだからこうとは限らないけど比較的多い印象。
ま、これ今回 Daniel Stenberg 氏が公表したからばずってるだけで、日本でもしょっちゅう行われているし、Hacker News みると海外でも一般的なムーブのようです。 LogJ4 Security Inquiry – Response Required | Hacker News
小さいところは
とかであんまり上から目線でこない感じはするけど、これはあくまで個人の資質なのでやべー人はやべーです。オラオラ系の中小とかやっぱいます。でもこんな細かいことはあんまり聞いてこない。（個人の感想です）
この手のメールになんでカチンとくるのかって言えば
ということで、皆ちゃんと保守・サポート契約して、契約範囲で質問しような！
そして金払ってても相手は人間なんで、お互い敬意をもって接しような！
Public Key でこの件にからめて記載されている奴について
https://www.itmedia.co.jp/news/articles/2201/11/news160.html]
ちな、これ詳しくないんだけど、OSS 作者が 「もうただ働きで支援をするつもりはない。これを機に、私に6桁ドルの年間契約書を送るか、プロジェクトを分岐させて他の人にやってもらうかしてほしい」 というのもよくわからないんだよなぁ。
火事で財産失ってむしゃくしゃしてやったのかなんなのか。人気 OSS になったのに全然金にならんぜ！ってのが辛いのはわかる。が、OSS のライセンス的に支援を義務としてやる必要はないので、そんな義務的になってる報告は無視してええんちゃうんと思ってしまう。今回みたいにサポートフィーよこせみたいなスキームが必要だったのかもしれない。
あと個人開発で、善意でこれ便利だろ？って公開しているものに対して、辛辣な言葉の心ないバグ報告やら改善要望は心には刺さるので辛いのはある。それで辞めてしまう人も居る。
ブコメでフリーライドって書いている人が居るけど、MIT ライセンスでだしてんだから OSS の理念である自由なソフトウェアという意味で、再配布、改変、利用は自由でいいんだよ。イヤなら MIT 以外のライセンスでだせばよい。古くは MySQL の Dual ライセンス、最近の Redis とか Mongo みたいに。
ただ、金欲しいとか大体 Donation 募集したりするとかやってると思うんだけど、そういうのもあったのかなかったのかがよくわからにぃ。ポートフォリオになるので、採用にはつかえるんじゃないのかね？
じゃなきゃ GitHub に Public でコード公開しないと思うんだけどな。いまいちピンとこないのであんまり言及しない。
https://www.publickey1.jp/blog/19/redismongodbkafkaaws.html]
で、商用ライセンスの問題。これ今回のくそムーブの問題じゃないのここに並べられるのに非常に違和感がある。なんか OSS と大企業の対立を煽るようなミスリードを誘っているように感じてしまう。
大手クラウドベンダは OSS のライセンスに則って利用・改変するのは問題がない。つーか儲かってるから金よこせっていうのはちょっと違うんじゃないかなと思う。
オリジナルを開発した会社がリスペクトされず、商業的に儲からないってのは、心情的、道義的、人気的にどうなの？クラウドベンダも金払ってあげれば良いんじゃないの？とは思うよ。（2社は協業したけど）
ただ、オープンソースで公開するということは次のような利点を求めてするこって、それがイヤならプロプラで良いわけさね。
Apache License 2.0 とかのライセンスの OSS として公表しているものの利用をフリーライドと表現するのも、それがなんか嫌儲で Evil ってのはちょっと判断できないかなぁ。
大手が自社でメンテできてしまう（できるようにする）というのは経営戦略であり、開発元がクローズにするってのも経営戦略。罵り合い合戦はちょっとなぁという感じ。
OSS の理念的に改修した分は元のソースにもっとフィードバックしろよってのはあるけど AGPL とかで出してないんだよなぁ。
この辺は賛否両論色々あるので気になったら調べてみて。
以上。ご査収ください。
法務省は４月から、少年院に入所する１８、１９歳に対する職業指導を見直す方針を固めた。
新設の「ＩＣＴ技術科」ではプログラミングなどＩＴの専門知識を学び、国家試験である「ＩＴパスポート試験」を受験できるよう、学習を進める。
少年院の職業指導見直し…木工・手芸・陶芸廃止しＩＣＴ技術新設（読売新聞オンライン）
https://news.yahoo.co.jp/articles/22d019cfc6bc1c6d390ceb07422a41238809dff1
更生支援の名目で少年院出の子を安くこき使うリアル「IT土方」が安値で仕事を取って、同業他社もその値段で勝負せざるを得なくなって、もともと苦しい中小SES / SIerがさらに苦しくなるのかな。まぁITパスポートじゃ何の役にも立たないけど。
プロジェクトが始まる直前ぐらいになんか全体を取り仕切る市場なんちゃらとかって部署が出張ってきた。
始まった途端今までやってくれたベンダーを切って、自社内でズブズブの超大手SIerのNなんとかにコンペもなしに単独発注。
経営への言い分は「不具合が多いから」とかなんちゃら言ってたらしい。（これが後にブーメランになります）
で、結局2サイトあって、リニューアルは2021年の夏ごろ予定していたのが、一つは12月、ひとつは2022年の春予定に遅れに遅れまくっている。
この間に部長からがん詰めされ、遅れたら「なぜ遅れる？」と言われ、残業したら「残業なんか何故する？」と詰められ、鬱って倒れる人まででる始末。
挙句の果てに現場には新しい仕組みが全く共有されないままで、12月のリニューアル分が現場にオープンされたら、それまで普通に使っている機能まで勝手に削られていた。
もうマジで市場なんちゃらのトップは何も分かっていなくて自分の功名心だけで現場潰している。
ユーザ用の機能まで勝手に削っていて、お客さまに告知もしていないのに、サービス劣化している。
今のSIer、超絶大手の癖に、既存サイトのコードもDBも全部提供してもらっている癖に2年もやってて全く解析していなくて、未だに「これってどういう仕様ですか？」「今のベンダーさんに確認してもらいたいです」と逝ってくる始末。
（コードをみて、おまいらが解析しろ、糞高い金払ってるんだから、とマジでいいそうになった）
こんな恥ずかしい状態でそれまでのベンダーさんに相談しても「仕事が終わるって言われてたから、今からヘルプを言われても、もう別案件に入れちゃってます・・・ごめんなさい」と言われる（そりゃそうだ）
更にヤヴァいのが、既存ベンダーさんは同じことをするのに1本ちょっとと言っていた金額が、某Nなんとかは既に片手で収まらないレベルになっている。
もうこれって部長の利益相反か、袖の下もらってるんじゃないのか？と言いたい。
そして、12月にリリースしたサイトはバグがボコボコでてきている・・・
今のベンダーさんが不具合が多いから変えたんじゃないですか？めっちゃ完璧なものが出来るんじゃなかったんですか？とマジで言ってやろうかと思った（言ったら首になるから言えない）
今のベンダーさん、適度に安価で結構な無茶（どうしてもDB直接修正しなきゃいけないとか）もなんとかやってくれてたのに、今のNなんとかは１００％やってくれないだろうし、運用回るのか・・・これ・・・
今のベンダーさんが全部が良い訳じゃなくて、たしかに不具合もあったけど、半分はこっちが超無茶なスケジュールで言ってて、テストらしいテストをしてもらう時間余裕もなかったのもあるけど、上は全部彼らの責任とかって経営にいっているらしい。
機能は劣化するし、サービスレベルは劣化するし、社内では倒れる人間がいるし、上役は良いことは俺の手柄、悪いのは部下の責任、という大和田常務を地で行く人で、さらに案件の内容が某み○ほ銀行状態になっていて、この部署からマジで離れたい。
だれか少しでもいいので慰めてくれ。
VDI（仮想デスクトップ）代替ソリューションの分類や、それぞれの仕組み、検討ポイントなどを解説する本連
載「テレワーク時代のWeb 分離入門」。 第1 回、第2 回でテレワークと Web 分離の方式の特徴を解説しました。
今回のゴール
用途の観点で各方式を分類すると下図のようになりますが、どんな組織にも共通する「おススメの方式」はあ
りません。
（出典：ネットワンシステムズ）
今回は、読者の皆さんが自組織にマッチする方式を選定できる状態をゴールとして、「結局、 どれを選べばいい
のか」という疑問に回答します。
フローチャートで分かる、
VDI 代替ソリューションの分類や、それぞれの仕組み、検討ポイントなどを解説する連載。最
終回は、VDI 代替ソリューションの方式選定における 4 つのポイントを解説して、各方式を比
較します。
（2021 年03 月04 日）
26 →目次に戻る
これまで多くのユーザーと会話してきた経験から、おおよそのケースで次の4 つのポイントに論点が集約されます。
2. データを処理するマシンがローカルマシンで大丈夫かどうか
これらを基に、方式選定に使えるフローチャートを作ってみました。
（出典：ネットワンシステムズ）
「 ブラウジングだけを安全に実行できればよいのか、それともブラウザ以外のアプリも安全に利用させたいのか」
テレワーク用途では、前者でよければセキュアブラウザ方式に、後者でよければそれ以外の方式にふるい分け
できます。Web 分離用途では、前者が仮想ブラウザ方式、後者がそれ以外の方式となります。
27 →目次に戻る
【ポイント 2】データを処理するマシンがローカルマシンで大丈夫かどうか
次に、「 情報漏えい対策をどこまで強固なものにしたいか」という観点での要件です。
プログラムの実行環境が手元のPC となる場合、データも手元のPC に保存されます。つまり、手元のPC を
「 ディスクを暗号化している、生体認証を有効にしている、だから大丈夫」と言い切れるならいいかもしれません
が、「技術の進歩によって将来的に突破されるかもしれない」といった懸念を払拭（ふっしょく）できない場合、仮
想デスクトップ方式やリモートデスクトップ方式のように、遠隔にあるマシン上で作業できる仕組みを導入する必
要があります。
その一方、将来の懸念よりも、例えばコストなど別の部分を重視したい場合は、会社PC 持ち帰り方式（VPN
なお一般的に、リモートデスクトップ方式とVPN 方式はテレワーク用途のみで導入されますが、仮想 デスクトッ
プ方式とアプリラッピング方式は、テレワークと Web 分離、どちらの用途にも利用できます。
【ポイント 3】データを処理するマシンが物理PC で大丈夫かどうか
【 ポイント 2】で「遠隔にあるマシン上で作業させたい」となった場合は、3 番目の検討事項として、業務継続
性を考えるとよいでしょう。
リモートデスクトップ方式の場合、社内の自席にPC が物理的に存在することが前提です。そのため、自席 PC
一方、仮想デスクトップ方式の場合、マシンが仮想化されており、多くの環境において仮想マシンが動作してい
るサーバ群はn ＋1 などの方式で冗長化されています。そのため、非常に強い障害耐性があります。
障害耐性を高めたい場合は、仮想デスクトップ方式がベストです。業務が停止するなどのリスクを運用でカバー
できる場合は、リモートデスクトップ方式を選ぶことになるでしょう。
28 →目次に戻る
【 ポイント 2】で「手元のマシン上で作業させてもOK」となった場合、3 番目の検討事項として、再度情報漏
えい対策について考えます。【 ポイント 2】では、PC ごとデータが盗まれてしまった場合を想定しましたが、ここ
手元のPC でプログラムを実行するということは、つまり「端末の脆弱（ぜいじゃく）性を突いたゼロデイ攻撃
を受けるリスクが存在する」ことです。脆弱性を突いた攻撃を受けると、多くの場合、情報を抜き取られてしまい
ます。
従って、例えば VPN 方式を導入する場合、「EDR（Endpoint Detection and Response）で脆弱性攻撃対
策を実装する」「端末のロックダウン化によってデータを保存させない」「実行できるプログラムを制限する」「屋
外の公衆Wi-Fi を利用できないように制限する」「多要素認証を導入する」などの対策を併せて導入する必要が
あります。
このような徹底した対策を継続して運用できる組織に限っては VPN 方式も有効な選択肢ですが、筆者としては
VPN 方式は安価かつ容易に導入できるので、昨今のテレワーク需要が高まる状況では、多くの組織で上記のよ
うな徹底した対策を取らずに導入してしまったと思います。取 り急ぎの暫定処置としてVPN 方式を導入してしまっ
た場合は、これを機に腰を据えて見直してみてはいかがでしょうか。
• 参考リンク：日本経済新聞「在宅時代の落とし穴 国内38 社がVPN で不正接続被害」
また、国内に限った話ではありませんが、Verizon Communications のレポートによると、やはりVPN トラ
フィックが増加傾向にあるようです。VPN 方式の普及に伴って、悪意ある攻撃者による被害数も増加すると思い
ます。
• 参考リンク：Verizon Communications「Verizon Network Report」
29 →目次に戻る
ここまで、要件をベースとした考え方を記載しました。選定すべき方式が大まかに見えてきたところで、ここか
らはそれぞれの方式を横に並べて、共通の項目に沿って比較します。
この比較によって、方式選定の次のステップとなる製品選定において「見落としがちな落とし穴を見つけて対策
を考える」といった検討を具体的に進めることができると思います。
以降の表の見方を説明しておきます。緑塗りのセルがポジティブな内容、赤塗りのセルがネガティブな内容、黄
塗りのセルはどちらともいえない内容です。また、それぞれの表の下部には、主に赤塗りのセルに関する特記事項
なお単純に、緑塗りセルの多い方式が優れているわけではありません。対象業務の内容やコスト、運用体制、セ
キュリティ、業務継続性など、いろいろな観点からトレードオフで方式を選定することになります。
できる作業
（出典：ネットワンシステムズ）
仮想ブラウザ方式とセキュアブラウザ方式では、例えばファイルサーバの操作といった、ブラウザ以外のアプリ
は使えません。多くの場合、Windows の統合認証など Windows に依存する機能も利用でません。
また、印刷に関しても確認が必要です。製品ごとにサポート内容に差が出るポイントなので、方式選定の次の
30 →目次に戻る
（出典：ネットワンシステムズ）
会社PC 持ち帰り方式（VPN 方式）とリモートデスクトップ方式は、端末のアップデート、故障時の交換など、
端末台数が増えるに従って、それに対応できる人員数を確保する必要があるので、運用コストが増大する傾向に
あります。
その半面、仮想デスクトップ方式は初期コストが高額ですが、メンテナンス対象はマスター OS のみであり、仮
VDI の運用ナレッジが豊富なSIer に依頼することで、作業内容の質を落とさずにコストを圧縮できる効果が期
待されます。
（出典：ネットワンシステムズ）
仮想ブラウザ方式やアプリラッピング方式、セキュアブラウザ方式は、「 Web ページが正常に表示されるかどう
か」などの動作確認を、あらかじめ実環境で実施しておく必要があります。この動作確認は、運用フェーズにおい
また、特に仮想ブラウザ方式は、「 ブラウザタブを開き過ぎるとサーバ基盤の負荷が高騰して Web ページの閲
覧速度が急激に低下する」といったサイジング関連のトラブルが発生しやすくなります。
31 →目次に戻る
（出典：ネットワンシステムズ）
マルウェア対策については、会社 PC 持ち帰り方式（VPN 方式）やリモートデスクトップ方式、仮想デスクトッ
プ方式は、EDR やアンチウイルスソフトの導入などが別途必要です。一方、仮想ブラウザ方式やアプリラッピン
グ方式、セキュアブラウザ方式は、「 利用終了後に環境ごとデータを削除する」「 exe 形式のファイルの実行を禁
重要情報の盗聴については、リモートデスクトップ方式や仮想デスクトップ方式、仮想ブラウザ方式（画面転送
型）は、画面転送型なので、暗号化通信が仮に復号されたとしても、実データが盗聴されることはないという強
みがあります。
最後に、不正アクセスについては、多要素認証システムと組み合わせるなどの対策がどの方式でも必要です。
ログインに関わる操作が増えることで利便性は低下しますが、昨今の状況を鑑みると、多要素認証の導入は必須
といえます。
おわりに
これで 3 回にわたる連載は終了です。いかがだったでしょうか。
セキュリティと利便性はトレードオフの関係にありますが、筆者は「仮想デスクトップ方式」と「仮想ブラウザ
仮想デスクトップ方式と仮想ブラウザ方式は、「 導入によってセキュリティレベルを大きく低下させることはな
い」という点が最大のポイントです。その上で、仮想デスクトップ方式には「従来のクライアント OS と同じよう
に利用できる」という汎用（はんよう）性の高さがあり、これが他の方式より優位な点となっています。一方、仮
想ブラウザ方式は、用途が限定されるものの、ユーザーにとっては利便性が高く、初期コストの観点では仮想デス
もし日本でTech企業に入るとすればどこがいいですかね？あと2年で卒業なので、そろそろリサーチを始めようと思っています。
尚、某国立大でCSを履修しており、大抵の会社であれば難なく入れるかなと考えているのですが。
前回: https://anond.hatelabo.jp/20211224013035
調達した資金も少なくなり、経営陣が焦っている様子が分かるようになった
それと同時に社内の雰囲気はどんどん悪くなっていった
バグだらけでまともに使えない
スーパーエンジニアを雇っても仕様がおかしいからこうなるのは必然だった
対して社内の雰囲気は最悪
コーディングも決して早くは無いが徐々に進んでいるようだった
「Markdownで書くのが今風だ」
と言われていたが「自分用のメモです」と言ってコツコツ書いていた
まあ、誰も見る事ないけど邪魔にもならないから良いかと黙認されていた
プログラマだ。
売上は毎年1500万を越える。
お客さんからの信頼は厚い。
週に最低3本は電話がかかってくるぜ。
うちの会社で社員教育を真面目にしているのは、ぶっちゃけ俺くらいだ。
教育といっても新人なんて当然いないから、社内のイマイチ仕事ができない暇そうな(本人は忙しいつもりらしい)人を2人くらい適当に貰ってきて、イチからプログラミングやチーム開発や顧客対応やドキュメント作成を教えるって感じだ。
なんとか自走できて自律成長できるプログラマができあがるって寸法だ。
このように俺は売上以外の面で会社に貢献している。
俺偉い。
最近都市圏ではプログラマ(それともITエンジニアと呼ばれたいか?)の給料がうなぎ登りらしい。
うらやましい限りだ。
でも俺はそんなお前らに、本当に売上立てているのか?と問いたい。
会社の売上を均等割するんじゃねーぞ。
お前の売上だ。
いくらだ。
せめて800万は越えてるか?
だとしたら哀れだな。
これは例年の最低売上だ。
俺すごいだろ。
そうなんだ。
俺スゲーしたいだけでこの増田を書いたんだ。
別にお前らがうらやましいわけじゃない。
いや、うらやましいんだけど。
そもそも俺べつに偉くないしな。
なのに偉そうなこと言ってゴメンな。
思わずね。
吐き出したくなったんだ。
さっき教育頑張ってるって言ったじゃん。
チュートリアル用のリポジトリ作ったり、トレーニング用のプロジェクト作ってチーム開発の真似事したり。
みんな転職していったんだ。
さわやかな笑顔で。
ニコニコしながら。
なぜか涙が止まらないんだ。
