  |
はてなキーワード: AZUREとは
リアルエンジニアのワイがなぜMacでないといけないのかを説明しよう。
Macしかできないことは、WindowsにWSL2があるいま、それただひとつ「iOSの開発」だけだ。たかがiOSというなかれ、今の時代、コンシューマサービス（B2C）を作るならiOS対応は必須なのだから仕方ない。
iOSのアプリ開発ができて、AWS/GCP/Azureにsshログインしてサーバ開発しようとしたらMac「でなければならない」のである。
B2Bのビジネス系ソフトしか作ってない人にはわからないと思うけどね。
なお、単にAWS/GCP/Azureにsshでログインしてvimでぐりぐりとサーバ開発するだけなら、MacよりもWindows WSL2のほうがはるかに優秀だ。
・画面の解像度が高い。一番小さいMacbook Airでも2560 x 1600あるから、デュアルディスプレイにしなくても足りる。sshの画面を4枚開いても全然余裕がある。なおワイの場合、この画面だけでMacを選んでいるといっていい。
・色がきれい。フォントがきれい。ワイはWindowsも（C#開発がどうしてもあるので）使うが、Windowsは画面が汚くてそれだけで非常にストレスになる。
学歴がよくなくて、就職が困難だったので中小 SIer で働いていた。 (プライム案件を取ってこれる分マシらしい)
レキサルティ、レクサプロ、デパスのお世話になって続けてたけど、結局は薬でどうにかできず、辞めてしまった。
参考程度だけど、未経験の人が 300万 をもらうために、どのようなスキルが必要かを、まとめておく。
ちなみにどれくらいプログラムが書けなかったかというと、競技プログラミングで努力しても AtCoder の黄色になれず青色のままってくらい。
AtCoder でいう、初心者から抜け出せないという、要するにセンスがないということなのだけど、そういう人も居そうなので、参考までに。
未経験のプログラマに対して、これだけ要求されるのだから、未経験の人は覚悟するようにという指針を提供したいので書いた。
基本的に、損害を与えた場合には、それを作業者が補填するという誓約書を結ぶ。
要するに、捨て駒として扱って、失敗したら賠償しろ、という事になる。
このことを認識して、失敗しないように振舞ないと、連帯保証人含めて迷惑をかける事になる。
要するに、低賃金で未経験プログラマを案件にノーリスクで送りこんで、稼ぐための手段です。
基本的に PL (夢想家) → PM (御用聞き) → プログラマ という環境なので、プログラマが自分でディレクションして意思決定する必要がある。
例えば、下請けの場合は、PM の御用聞きの結果の WBS に合わせないと、顧客から DM で 瑕疵担保責任がどうとか言われる。
社内開発の場合は、PL の方から直接、長時間の叱責を受けなくてはならない。
そういう不幸を防ぐためにも、自分でディレクションして、PM の決めた実態を反映していない WBS に合わせて作業するスキルが要求される。
基本的に手戻りは個人の過失になってしまうため、手戻りしないように考え抜いて意思決定をする、というのが重要になる。
これこそ、ガクチカと呼ばれる、頑張れますというスキルなので、学生時代に頑張っておけばよかったなぁ。
こう見せたい、こう表現したい、という事を伝えるには、必然的にデザインの知識が必要になる。
創造的思考とデザインは切っても切り離せない概念で、デザインとは創造なのだから、当たり前である。
ソフトウェアアーキテクチャも、ソフトウェア設計も、コーディングもデザインと言えるかもしれない。
顧客と 1:1 で話す事が DM でもボイチャでも突発的に発生するので、いつ、いかなる時でも論理武装していなければならない。
まぁ、顧客であったり PL であったりはキレるのが仕事なので、それに対して理路整然と説明する必要がある。
なんとなく、では納得しないし、すぐ損害賠償請求とかそういう話にいくので、答えられないと持ち帰りますとお茶を濁して、エマージェンシーになる。
後述する設計能力においても、課題を把握するための言語技術(言語化能力)は重要なファクターだと思う。
C/C++ のシステムプログラムはフレームワークが基本的に無いので、自分で概念を整理して、どのような変更、拡張があるかを考えて設計する必要がある。
この能力が弱いと、手戻りが発生しやすくなり、瑕疵担保責任を問われることになる。
読んだ本の中だと、ボブおじさんの本が、やっぱりしっくりくるなという個人的な感想がある。
UDP で送ってくるデータを受けて 24/365 で停止しない WebAPI への繋ぎ込みという簡単な作業があって、振られた。
リークしてはいけないという事で malloc は禁止で、グローバル変数を利用するという変なルールがあった。
Rust で書けばいいんじゃないかなと思ったけど、Rust 書くのもシンドイし、C/C++ で、しんどくて読みづらいコードを書いた。
あとで保守する人が大変そうだけど、そういうルールを決めたのは PL だしね。
なんか、特殊な PCI Express のカードからベンダーが用意している SDK でデータ引っこ抜いて Web API へつなぎ込む部分をやった。
一応、SDK の使い方をパラ見して 1 日で作ったので、別に負担じゃなかったけど、素人にやらせるんなとは思った。
当たり前だが、DB 作って RestAPI を生やすのは現代のプログラマにとって自然にできなければならない。
なので、新規開発のサブモジュールのバックエンドを任せられた。
だが、ORM の癖を把握したり、発行されるクエリを確認したりするのは、疲れる。 SQL を直書きするのはシンドイ。
結局 SQL を直書きすることにしたけど、あまりいい決断ではなかったと思っている。
それ以外は フレームワーク に乗ってしまっていいので、書き捨てる分には楽だった。
最近だと、TypeScript で Prisma 使うのが、型安全でよさそうだなと思っている。
デプロイを EC2 直でやったり ECS にしたりとしていたので、ベアメタルの知識が必要になった。
要するに systemd のいじり方とか、死活監視の仕方とか。
個人的には、クラウド嫌いなので、ベアメタルの方が安心できる。
Bind で権威DNS を管理して、postfix で絶対止めてはいけないメールサーバを管理するとかもあったけど、出来て当然ではある事だし。
未経験プログラマでも、月単価 100 万以上で顧客に請求してるんだから、会社はそりゃ儲けるだろうと思った。
会社が一人前の経験N年のプログラマといったら、その通りに振舞う必要がある。顧客に責任はないのだから。
当たり前だが、Webディレクション、Webデザイン、Webプログラミング, Webマークアップ は、全て作業者であるプログラマの仕事になる。
個人的には、これが分かれている理由が良く分からないけど、分けたい人がいるんだろう。
デザインで、CSSフレームワークを使うと、その色が出るという事で、全部 CSS は手書きしていた。
tailwind が出た現在では使っていればよかったなと思う。
結局、全く分からない中、手探りでデザインし、コードを書いて、顧客に 1 日 5 ~ 10 回リリースするという行為をした。
顧客は大手企業だったので、自社のエンジニアならもっと出来る、と叱責されまくったけど、だったら自社でやればいいじゃんと思った。
一応、今でもサービスは生きていて、ユニークユーザ数は上がっているらしい。
そして、焼き付け刃だったので、 WAI-ARIA を知らず、アクセシビリティへの配慮が足りない事が問題になってしまった。
これはなんとか保守対応にねじ込めたのでトラブルにならなかったけど、瑕疵担保責任と綱渡りだなと思った。
当たり前だが、リリースサイクルを短くしないと顧客はキレてしまうので、CI/CD を整えないといけない。
今は Github Actions とかあるけど、昔は無くて Bitrise が高いからみたいな理由で Azure Pipelines で CI/CD フローを構築した。
もう Multi Stage Pipeline になってるだろうけど、Release Pipeline が GUI からしか設定できないのが辛みだった。
当然だが、デプロイするためには IaC を整える必要がある。
これを知らずに、コンソールでポチポチしていたので、 IaC 出来てない事がバレた時に色々怒られてしまった。
本来はテストも自動テストを整えて、質保証をしてバグを減らさなければならない。
だが、テストを書くという手間を払えなかったので、人力テストしかできなかった。
一応、リグレッションテストを人力でやりまくったので、バグ発見曲線が結合テストでの IF 不一致しかない、という結果にはなったけど
自動化できれば費用が必要じゃなかったから、怠慢だと、責められてしまった。
未経験でも誓約書を盾に、振られた事全部を出来なくてはならない慣習があるので、プログラマはそんなに良い職業じゃないよ。
甘い考えで、プログラマになろうと思っているのなら、考え直した方がいいです。
「企業内システム担当者（SEでもプログラマでもない人）が、何かあったら外注のせいにして責任を逃れられる」
って書かれてて、なるほどなあと思った。
で、これを考察すると、これって江戸時代の武士の支配をしていたメンタルそのものなんだよな。
例えば徳川家の旗を間違えて燃やしちゃったり、雑巾にしちゃったりする。
そしたら領地減らされるとか、最悪は改易（飛ばされる）とか、遠島流刑。
こういう「1%のミスを許さない」っていう精神って、徳川家康が設計したものなんだよね。
家康は将軍を引退してからも実権を握ってたのが13年くらいあって、
息子の秀忠が馬鹿真面目だったってこともあって、「ならぬものはならぬ」みたいな上意下達な文化を作ったんだと思う。
大奥とかの文化も非常にクローズドでがんじがらめで、今の日本に近い文化だよね。
それが260年以上続いた。
江戸以前の戦国時代はその逆で、「勇敢な行動の末のミスであれば武士としてあっぱれである」
みたいな文化だったんだよね。もちろん「勝手な行動は死罪」というのは軍においてはそうであったけど、
基本的にスピードと結果が全ての世界だったから、許されることも多かった。
何より信長や秀吉が好んだのは「臨機応変さ」「勇敢さ」であって、企業でいうベンチャーマインドに通じると思う。
秀吉は朝鮮出兵などで自爆してしまったけど、信長がもし織田政権を長期化させていたら、
楽市楽座とか、重商主義なところも、石高社会の当時の日本としては画期的だったからね。
まあ、家康は偉大ではあるけれども、日本人を停滞させた側面はあっただろうね。
何パーセントかは信長・秀吉のベンチャーマインドが許容される国であっても良かったと思う。
日本人の責任を取りたくない、悪い意味での臆病さが、外注という甘えを生みだして、
で、その臆病さの源泉は何かっていうと、終身雇用にあるんだよね。
アメリカみたいにスキルアップして飽和したら、数年おきにステップアップ転職する、っていう文化がないからね。
一生面倒を見てもらうわけで、ちょっとミスしたら一生居心地が悪くなってしまう。
そんな気持ちが見て取れるよね。
村八分されたくないから、村の外から工事人工を雇うってことなんだろうね。
で、話は戻るけど、多重下請けスキームにおけるエンドユーザー企業にいる、
エンジニアでもない「システム担当者」って結局なんなの？とも思う。
イメージ的には、江戸時代の城の中の座敷で座ってる人って感じ。
めっちゃ座り方が型にはまってる感じの。
「殿中まかりこしまし早漏」とか言ってそうな人（知らんけど）。
何ができるかっつーと何もできないけど、殿中まかりこしまし早漏の言い方はうまい(笑)。
座敷おっさん「うむ！節々のこといっさい任せたぞ！」みたいな。
あとは500人で済む工事を1000人で見積もらせる、金への執着、欲望の深さも大事な素養である。
ちなみに信長は二条城の改修を驚くべき短期間と完成度で仕上げたそうだが、
その時には自分も粗末な服を着て、身分の低い人工たちと身分の差なく語り合い、
トップダウンで進めたという記録が、フロイスによって残されている。
よく考えれば城が立派に早く完成すればいいわけで、
「工事の計画文書、第100版を作りまかりこしもうした」って毎日やるのが目的じゃないものな。
まかりこしもうしたやってる間に城郭を強化したり街道を整備してる。
これは現代でも同じ。最終目的がわかってるのがアメリカの強さ（＝信長の強さ）なんだろうな。
だから日本がExcelポチポチやってる間に、AWSやAzureを作ってしまった。
とはいえ公正取引委員会とかIPAやデジタル庁が、問題を認識して動いているから、風向きは変わっていくかと。
https://xtech.nikkei.com/atcl/nxt/mag/nc/18/020800017/072600752/
未経験でアラサー以上で400万目指すならとりあえずプログラムを書こうという前提は捨ててまずはインフラやりんしゃい
あと基本情報取るくらいなら、情報セキュ・ネスペ・情報処理安全確保支援士の方が、理解しやすいし、使い道あるし、実務で役に立つよ
ITパスポート・基本情報はこれから CS やろうという学生さんが知識詰め込みのために受けるもんだ
あとIT技術者がこの範囲すべてカバーしてたら嬉しいなっていうジェネラリスト養成に命を掛ける日本国と企業の願望
ITワードにまったく馴染みがない or どうしても順序立てて勉強しないと発狂する気質の場合のみ取ってもいいよ
Oracle Master はインフラのみで生きてく場合も後々プログラムやる場合も良い選択だよ
ペーパー得意なら Silver 目指してもいいけど、まずは bronze と SQL だけで良いよ
開発やらないパソコン先生系の社内SEでも、テクニカルサポートでも、インフラ保守でも、意外と SQL・DB は触るし
一部の人が夢見てるデータサイエンティスト()でも SQL 使うし、マーケでも使うかもよ
要はとても潰しが効きます
のんびりパソコン先生という名の社内SEをして暮らしたいなら、AD と Azure の知識はあった方がいい
意外とこの辺に興味が薄い人が多いから狙い目だと思うよ
けどネットワーク・サーバーの知識が皆無だとどこで設定コケてるのか『？』ってなるので
求人で需要が高いのは Intune、 M365Apps あたりだと思うけどとりあえず、
あと、AWS周り
AWSの保守ベンダーやAWS使った開発案件の保守とかやるのでなければ優先度下がるけど
上記に潜り込む訳じゃなきゃ資格は取らなくていいけど AWS 使わないとこないので知識はあった方がいいよ
それから、見栄っ張り or Google Workspace の案件に潜り込むなら試験で問われる内容の割にクッソ高いけど、
なんか Google のグッズ貰えたり、Google のイベント参加できるらしいで？
Microsoft 365Apps と同じく、Google Workspace は使っているとこ多いので、
該当案件に潜り込むのでなければ資格は取らなくていいけど知識はあった方がいいよ
あと何よりも重要な事なんやが、IT技術者って、ガチgeek以外は単なるサラリーマンやぞ
テキトーが許せない人は技術者の適性は高いけどサラリーマンとしての適性は低いぞ
テキトーが許せない人は下手したら罰せられてテキトーが許されない経理や法務の方がおそらく向いてるぞ
※直雇用で社内SE、直雇用で自社サービスの保守・サポート、大手ベンダーの一次案件を想定してます
多重構造になってるところに派遣されるみたいなのは想定していないです
あと悪い人に騙されがちなので立ち回りに自信がなければ出来たらやめといた方がいい気がします
(もちろん絶対ダメってことはないよ。会社持ちで未経験で案件のためにCCNAとらせてくれたり、
CCNP、CCIEとらせてくれたりもあるよ。あとSESから大手ベンダーの直雇用になる人もいるよ
ちょっと前なら400万欲しいなら、
Windows Server (Active Directory) の MCP 取って、CCNA 取って、LPIC1 取っておけばいいぞだったが
Windows Server の MCP 無くなった・・・(？)んだよな(追記：新設されました → Windows Server Hybrid Administrator Associate(AZ-800、AZ-801))
割とまだオンプレミスAD (Active Directory)しかない環境やハイブリッド環境多いと思うが MS は AzureAD と Intune だけ使って！！😡ってやってる
いまは、CCNA と LPIC、それと AWS と Azure の資格ですかね
イメージとしては、クラウド保守ベンダーで働くとか、Microsoft365 のサポートやるとか、社内SE(インフラメイン)とかそういう感じです
ただインフラメインだとなんだかんだ場所に縛られる傾向が強いので(在宅可でも研修時は出社しろとかクライアントのセキュリティ規定が云々とか)
地方だとギリ400万に届かず月収換算32万くらいの可能性もあります
フルリーモートの社内SEやクラウドベンダーの案件は多少なりとも開発経験があることが要件になってたりすることがあるので
プログラムもできるにこしたことはないけど、アラサー以上でこれからエンジニアやるぞーの人はプログラム知識は優先度低いです
言うほど来ないぞ
はいはい、DX、DX、とは思いつつも目安としてはこのくらい出来れば運が良ければ狙えるぞ
https://anond.hatelabo.jp/20220504222630
拠点・事業部立ち上げでインフラ・バックオフィス全部やるか、小さなSIで営業寄りでなんでもやるみたいな感じ
流石にホムペ云々は弱過ぎるがAWS・Azureあたりの資格をとってこの辺読んどくくらいで運が良ければイケるで
http://www.iptpc.com/iptpc_public_samples.htm
もう新規拠点作るのは決まってる・サービス開始するのは決まってる・前任者が失踪したで致し方なしとかあるしな
運は何物にも勝る
でも裏切らないのは実力ですけどね😭
弊社ではその設立当初、というよりも創業者(＝私)が個人事業主だった頃から業務にFLOSSを多用しています。
今回その事例を情報共有するためにエントリを作成いたしました。
従業員50人ほど(学生アルバイト含む)の会社です。ちなみにかなりボカして書きます。
弊社では社内文書をSDGsの観点からペーパーレスに努めており……と表現すると些か格好付けすぎなので正直に言えば個人事業主時代に印刷機複合機のランニングコストがバカにならなかったので物理ペーパーへ出力するのを控えていた運用がそのまま法人化されても続いているだけです。
社内文書として用いられる文書フォーマットはODF形式で統一している……というかコレもまた個人事業主時代にOpenOfficeを活用しており、現在社内で使われている主なオフィススイートはLibreOfficeとなっています。
注意点としては弊社がルールとして定めているのはODFを用いることでありLibreOfficeの利用を強制しているわけではないという点です。
従業員の中にはLibreOfficeを常用せず、AbiWordやGnumericを普段使いしている者も居ます。
弊社は社外とオフィス文書ファイルをやり取りすることが一切なく、オフィス文書ファイルと表現するには正しくないですが社外とはPDFをやり取りするくらいなので何か問題が起きたことが今まで特にないです。
ただ1つ問題があり、弊社はこれまでLibreOfficeを無償で活用させて頂いており、これまでの感謝を示すためLibreOffice Enterpriseへの移行を考えているものの日本国内でLibreOffice Enterpriseを利用するための情報が一切なく困り果てています。
最悪、海外の企業を頼る方法もありますがサポート時間の都合などがあるため可能ならば国内で探したいと考えています。どうにかならないものですかね？
社内では「むしろウチがやったら？」なんて声もチラホラ聞こえますが……。
ちなみに社内デファクトスタンダードのフォントはNoto Sans Japaneseです。一部でTakao(IPA)が使われています。
弊社ではFLOSSを活用しているせいもあって特にOSの縛りを設けていません。何なら経理担当はChromebook使ってます。
社内のOSシェアはChromeOSを含めたLinuxディストリビューションが5割、macOSが2割、残りがWindowsとその他です。
気になるであろう開発環境についてですが、Dockerを用いて開発環境の統一化を計っており、その時々に応じてDockerコンテナを切り替えて開発しています。
Dockerを用いているせいもありLinuxディストリビューションの社内OSシェアが高くなっているのです。
プライベートで従業員は様々なOSを選択しているようです。ゲームとかVRが趣味であるならばWindowsしか選択肢ないでしょうしね。
ちなみに業務用のPCはBYODで購入補助あります。
結局は従業員の現物給与として課税されてしまうだけなので「いくらでも良いけど高すぎるの買うと年収増えすぎて痛い目みるよ？」とは助言してます。
会社はまとまったお金を出しているに過ぎないのでメリットとデメリットがありますよね。
いちいち申請出す方もチェックする方も面倒なのでGNUプロジェクト下ソフトウェアは無申請で利用可としています。
ただし制限は公式リポジトリまたは弊社が安全だと判断しているリポジトリで配布しているバイナリのみという条件が付きます。
どこの会社もそうでしょうけれどもAWSやAzure、GCPなどたいてい大手に置いてますね、予算の都合もあるけれど。
これは弊社が強制しているわけではなく、弊社デザイナーの第1号従業員がWindowsユーザであったので惰性のままWindowsとなっているだけであり、中にはMacで仕事している従業員も居ますし、状況によってLinuxディストリビューション(主にUbuntu)上で仕事しているときもあります。
Linux環境では苦手なIllustratorのAI形式などはSVGやラスター画像に落とし込んでもらって開発者が適用するという運用になっています。
社内では特定の環境へ依存するファイル形式はとことん嫌われる傾向にあります(妙な仕事が増えるから)。
開発者から経理、デザイナーに至るまで弊社従業員はみんなGitが使えます。
ただし使えると言っても全員がCLIからコマンドを打てるわけでなくGUIクライアント上からの操作しか出来ない者も居ます。
主に使われているGitのGUIクライアントはGitKrakenです。
入社時の受け入れ教育でLibreOfficeやGitの指導をすることになっており、全従業員が浅くともGitとは何ぞや？を理解している状態にあります。
ちなみにGitリポジトリは主にGitLabへ置いていてUltimateを契約させてもらってます。
社内にセルフホストしているGitLabサーバもありますが、こっちは従業員が個人開発しているものを投げているようですね。業務にあまり使われていません。緊急時のバックアップと思われるものがちょこちょこありますが。
プロジェクト管理ツールはいろいろと試したのですがOpenProjectへ落ち着きつつあります。
プロジェクト管理ツールの選定は各プロジェクトマネージャへ任せているのですが、旧来からあるRedmineと操作性が近い上にGitLabとの連携も容易でなかなか良いとのこと。
他社とのやり取りにSlackやTeamsやZoomが出てくることもありますが、社内だけで完結する際はたいていElementが使われています。
これは当時インターン生だった弊社の現従業員が若者の熱意と共に持ち込み、サーバを与えたら喜々として運用をはじめたので、それをきっかけに便利だったからそのまま使わせてもらってます。
ぶっちゃけて言えば私個人のこだわりはチャットにありません。従業員が楽しそうに使っていればそれで良いんじゃないかと。
IRCとか持ち出されたら「今どきそれはどうなの・・・まぁ良いけど」って言うかも知れませんが。
会計はFreeeです。特にこだわりはありません。たまたまWebブラウザから使えたのでFreeeとなってます。
残り5%は主に私が出社しているからｗ
社内にサーバがあるので私以外も出社してくることはありますが基本的にコロナ禍以降は全従業員がリモートワークです。
そもそもコロナ禍以前でもリモートワークしてた気がしなくもないのですが当時は3割4割くらいだったでしょうかね？週に何度か出社して来ないが自宅からdoneしてくる従業員が何名も居たので。
タイムカードもElementのbotへ投げると自動的に処理するようになってます……が、実際のところ最後の処理で私が大目に時間を付けてます。打刻を忘れることもあるしね。少ないより良いやろｗ
結局、郵送物(今ならコロナワクチン関連とか)を処理する必要があったりなど誰かしら会社に人が居なければならず、自分でも忘れがちですが創業者なので私が会社に居るよってことで私だけがほぼ出社するという状況になってます。
オフィスの処分も一時期考えたのですが、増員への教育とか考えるとやっぱりオフィスあったほうが良いよなぁなんて思ってそのままです。もしかしたら引っ越しするかも？
1つだけ申し訳ないことがあって、コロナ禍の状況下でどうやって増員したら良いのか教育したら良いのか私の能力を超えていまして現在は新規募集を停止中です。いやホント申し訳ない。
事業が軌道に乗った以降は毎年最低1人は取ろうねと古株と話していたんですが、こうなっては無理だよねと苦笑しあってます。
どうやって世間の同規模中小企業は新人教育やってるのか解らなすぎる。会社に誰も居ないじゃんと。
上場する気も更々ないし無借金なので、のん気にこのままゆっくりと会社を維持していきたいなぁと思ってます。
早くコロナ禍終わらんかなぁ……。
ワイの一番古い増田はDHCP理解してないマン宛のトラバやったで
2018-08-14 anond:20180814213814
Radius も Active Directory も無い世界線どころか、DHCPサーバ側でMACアドレスとIPアドレスの組み合わせを予約しておくことすらできない世界線の増田
最近でも Azure AD なんか導入している企業ないマン、Microsoft365 や Google Workspace は存在しない＋それらと連携させるセキュリティプロダクトは存在しないマン、
AWS や VM や Dockerが存在しない世界線マン、AWS で起動テンプレートを作らないインスタンスを複製しないマン、Debianと契約するマン、
Linus Torvalds を知らないマン、資産管理の意味が理解できないマン、フリーデスクの基本的な運用を知らないマン、基幹システムにアクセスしないマン、
Teamsなどのコミュニケーションツールが存在しない世界線マン、今時は Teams などのコラボレーションプラットフォームに内線を統一する流れなのに
一昔前の BYOD で個人の携帯にアプリで内線を割り当てるどころか固定電話を廃止して携帯定額通話でドヤ顔マン、ユニコーン企業で働いてる設定なのにお局云々マン、
AWSで年収1000万余裕マン＋AWSについての歴史改変マン、既存の不正検知AIプラットフォームは使用せず依頼を受けてサイゲ参考に不正検出システムを作ったマン、
Pythonは仕事は無いマン・・・・・ほか、上げたらキリがないんだわ
とりあえず、時が止まり過ぎ＋IT業界に妙な憧れがあることだけは伝わる
因みになんだがこれやってるのすべて同じ増田なんじゃ無いか？って思ってるよ。文字が文字通り読めない増田
もちろん、だからといって、増田に書き込んじゃダメってことは一切ない。今まで通り好きなこと書いたらいい
その自覚さえあれば、在りし日のVIPがみんなニートという体だったのと同じく、
ワイも増田も
MMMO (M 無教養で M 無能で M 無収入な O オタク) か
まずは、日立のサーバーでのWindows Server 2022への対応からお聞きした。
木村： サーバーにはHA8000VとRV3000の2ラインアップがあります。HA8000VがPCサーバーで、汎用的なサーバーとして、エントリー向けや、HCI、VDIのソリューションなど、いろいろな用途で使われています。RV3000はミッションクリティカル向けです。Windows Server 2022のプレインストール対応は、HA8000Vの全機種で2022年5月を予定しています。
Windowsサーバー市場における日立の強みとして、木村氏は、サポート力を挙げる。
木村： 日立は長年に渡ってプラットフォーム製品の開発を行ってきました。作ってきたからこそ、中身がわかっている技術力があります。できることとできないことを技術者がわかっているので、障害が起きたときや問い合わせのときに、お客様に事実を真摯に伝え、重大な不具合があっても技術力で解決に向けていきます。何かあったときに問題をたらい回しにせず、技術力をコアにしてしっかり対応するサポート力が強みです。
こうした日立のDNAを結実させたサポート商品が「日立サポート360」だ。通常はサーバーのハードウェアからOS、ソフトウェアなどは、それぞれと契約し、サポートを受けることになる。日立サポート360ではこれらをワンストップで受け付け、支援することができる。
広瀬： 窓口が1つになるというのは他社でもありますが、そういう表面的な話だけではなく、複合的な力で問題解決支援にあたれるのが真の価値です。内部で、サーバーからOS、日立ミドルウェア、導入ミドルウェアなど、いろいろな製品の部門の連携がすごく濃密にされているからこそ、複合的な力で問題解決にあたれます。これが本当のワンストップの意味です。
この日立サポート360でWindows Server 2022のサポートにも対応する。日立では、長年のサポート実績により蓄積された技術力により高い自社解決率を誇るという。自社解決率が高ければ、それだけパートナーへのエスカレーションが減るわけで、短期間でのトラブル解決が期待できることになる。
日立のハイブリッドクラウドのソリューション「EverFlex from Hitachi」
木村氏は、日立のハイブリッドクラウド戦略としてEverFlex from Hitachi (以下、EverFlex)ソリューションを説明した。EverFlexは2021年10月にクラウドとのデータ連携ソリューションとして始まり、2022年2月にハイブリッドクラウドのソリューションとして強化された。
木村： お客様がオンプレミスとパブリッククラウドを使うときに、最適なシステム設計にして、コストも最適化していきます。ハイブリッドクラウドの導入には事前にアセスメントやコンサルティングを行うことが大切です。なぜなら、パブリッククラウドを導入することで負担が減るかと思われがちなのですが、ハイブリッド化されることで負担が増えることがあるからです。
EverFlexの特徴の中でも特に「クラウドライクなサービス提供」について木村氏は紹介した。
木村： ハイブリッドクラウドになると保守や運用が煩雑になります。パブリッククラウドとオンプレミスの両方を管理しなくてはならないため、システム管理において両方のノウハウが必要になります。このため保守・運用フェーズにおいて簡単化されずコスト最適化が課題となってきます。それを避けるために、共通化するニーズに応えるようにいろいろと工夫しています。
ハイブリッドクラウドソリューションEverFlex from Hitachi
まず、問い合わせをワンストップ化したり、運用管理を1つのツールで一元化したりすることで、顧客の負担を軽減する。
プラットフォームにおいては、オンプレミスからクラウド接続を可能にしてシームレスにお互いやりとりできるOSが各社ある。Windows Server 2022はまさにそれを特徴としており、同じくAzure Stack HCIも選択肢に入る。
さらに、支払い／利用形態についても、オンプレミスでも売り切りだけでなくフィー型も採用する。こうしたEverFlexの中でWindows Server 2022のユースケースを木村氏は2つ挙げた。
1つめは、運用管理の簡単化の部分で、Azure Portalからオンプレミスを管理できる機能の強化だ。
木村： オンプレミスにエージェントを入れておけば、管理者がAzure Portalだけをさわって、オンプレミスのリソースやイベントの管理も全て一元化できます。これに期待しています。
もう1つはセキュリティの強化だ。
木村： ハイブリッド化が進むと、両方の基盤をネットワークで接続することになります。従来には存在していなかった接続となるため、その部分でセキュリティの強化も進めなければなりません。そこでWindows Server 2022では、Secured-core ServerによってOSそのもののセキュリティレベルが上がっています。TPMと連動する機能によってハードからOSのレイヤーを守り、マルチレイヤーでセキュリティを強化しています。
そのほかにもクラウドライクの取り組みとして2つを木村氏は紹介した。
1つめは「サーバ予備リソース提供サービス」。サーバーを余分に設置し、支払いは電源を入れて使った月だけ発生するというサービスだ。
木村： 迅速でタイムリーにリソースを増強したいときに、クラウドなら自由に構成を変えられます。それをオンプレミスでもできるようにします。クラウドではインスタンス単位となり、ハードウェアの構成はメニューの中から選択することになりますが、オンプレミスでは構成を自由に組む事ができます。まずHCIソリューションから開始しましたが、2022年4月からはそれ以外にも拡大する予定です。
もう1つが「ハードウェア安定稼働支援サービス」。オンプレミス環境のサーバー運用管理を省力化するものだ。
木村： 旧来の保守では、ファームウェアのバージョンアップがあると、技術的にどういう影響があるかを確認して、その都度適用するかどうかを判断する必要がありました。それを提供元が判断するのがこのサービスです。お客様の機器を弊社で管理して、ファームウェアの推奨バージョンの選定や、更新作業などを一括でやります。
サブスクリプションに力を入れる
日立のこれからの注力分野について木村氏は、サブスクリプションに力を入れていくと語った。
木村： 全社的な方針で、サブスクリプションに力を入れていきます。クラウド化で初期投資をおさえるニーズと同時に、オンプレミスも求められています。そうしたお客様のニーズにアラインしていきます。
サブスクリプションやクラウドライクなサービスで管理を簡単にして顧客企業がコストを抑えることで、究極的な目的はその先のDXだと木村氏は語る。
木村： 既存のプラットフォームのコストを最適化させ、浮かせた費用を新たな投資先として、AIやEdgeを活用する新たなデジタルソリューションの領域に向けていくことを支援していきたいと考えています。
そのために木村氏は、よりハイブリッドで使いやすいようなライセンス体系をマイクロソフトに期待している。
木村： 今後ハイブリッド化が進むと、繁忙期にリソースを拡張するといったこともあります。そのときにライセンスが、オンプレミスはオンプレミスで買って、AzureはAzureで課金してと、ハイブリッドで使いづらい体系になっています。将来的にライセンス体系を統一するなど、両方の基盤で使えるような体系になることを期待しています。
また、Azure Portalからオンプレミスを管理できる機能についても、さらなる強化を木村氏は期待する。
木村： Azure Portalからは管理できる範囲に限りがあります。OSから上のリソースやイベントは監視できるのですが、ハードウェアの死活監視や電源管理などは対応していないため、JP1やその他のツールなど、複数のツールを使いこなす必要があります。それらの管理ツールが乱立してしまうと、また管理の手間が増えてしまう。こういったことをオンプレのツールか、Portal側で統一することも期待したいところです。
契約してる1つのサーバで個人ブログとか昔ながらのBBSとかブラウザゲームとか種類が違うサービスをいくつも運営しているけど、サーバの運用方法が流石にレガシーすぎるからもうちょっとモダンな感じにしたいと思ってる。
でも中々抜け出せない。
まず前提としてAWS,GCP,Azureは高いから使えない、同スペックなら適当なVPSの方が圧倒的に安い。
最近流行りのコンテナ構成みたいなのもいくらDockerが昔のVMに比べるとリソース食わないと言っても例えば
「1つのサーバで10個のサービスを相乗りで運営しなければならない」みたいな場合に1サーバ内で何十コンテナ起動みたいなの運用すると流石に相当重くなっちゃうよなぁ。。。
あとnode.jsとかginみたいに1サービスごとに常駐プロセスが増える技術スタックも多分あんまりよくない、必要ポートを管理するのも大変
結局自然と行き着くのは格安VPS借りてLAMP構成作ってVirtualHostで相乗り設定して昔ながらの方法で運用する方法になっちゃう
php+apacheの構成ならアクセスの少ないサービスを何十個運用しようとアクセスがないならそれにリソース食われることがないんだよね、何気にLAMP環境の結構な強みだと思う
もっと良い方法見つけたいし、多分お金かければあるんだろうけど
月2000円以内くらいで多くのサービスを運用したいってなった場合に結局これ以外の選択肢ってなくない？
月1～2万円みたいな額はインフラエンジニア雇う費用に比べると全然安いんだろうけど、ポケットマネー基準だとそうもいかない
https://www.sofia-inc.com/blog/7233.html
情シス（情報システム部）はもういらない？これからの情シスに求められる、あるべき姿とは？
皆さんは情シス（情報システム部）が果たす役割・機能を何だと考えますか？ 全社のIT戦略策定・システム企画、社内インフラやアプリの保守・運用、ユーザーサポートやトラブル対応といったことを思い浮かべる方が多いのではないでしょうか。
しかし昨今、情シスにそのような役割が求められていない、もしくは情シスの業務自体がなくなりつつあることをご存知でしょうか？
今回の記事では、これからの時代の情シスに求められる役割、あるべき姿について説明します。
近年Microsoft AzureやAmazon Web Serviceといったクラウドサービスの台頭により、オンプレミスからクラウドへの流れが起きています。社内に物理サーバーを置いて保守・運用するといった必要がなくなり、ソフトウェアもPaaS・SaaSといったクラウド上で提供されるサービスに代替されるようになってきています。それに伴い、膨大な設備投資費や社内SE（システムエンジニア）の人件費を削減できるようになりました。今後すべてのITリソースの保守が必要なくなるという可能性もあります。
デジタルトランスフォーメーション（DX）が多くの企業で重要課題となっている現代において、企業がIT活用で目指すべきことは、単純にITインフラ・ツールを変革させるということではありません。業務変革・組織変革を伴うような、より大きな次元での変革です。経済産業省も、ITを変えるだけがDXではないと説明しています。
「企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること」
このデジタルトランスフォーメーションの実現を企業が目指すにあたって、情シスの仕事も大きく転換しようとしているのです。次章では、まず従来の情シスの役割について整理・紹介していきます。
DX（デジタルトランスフォーメーション）を推進する上で押さえておきたい3つのステップ
昨今ビジネスの場において、DX（デジタルトランスフォーメーション）という概念が頻繁に取り上げられるようになりま…
これまでの情シスに求められていた役割は主に以下の４つでした。
会社の経営戦略や事業戦略に基づき、システムの企画立案・要件定義をする役割です。社外ベンダーの見積もり検討・選定、およびその後のプロジェクトマネジメントを遂行し、ユーザー部門に対して新しいシステムを開発・提供します。
社内ユーザー部門からのリクエストや業務プロセスの変更に応え、既存システムのカスタマイズなどを実施します。運用・保守によってシステムを安定稼働させ、会社の事業活動を下支えする役割を担います。
自社サーバーやネットワークの構築・運用・保守を行いつつ、セキュリティ対策やデータ保全を実施することで、万が一の事態に備えます。また新技術・製品の導入検討や評価を行って、常に社内環境のサービス向上に努める役割です。
社内ユーザーからの問い合わせ対応・トラブルシューティングを行います。ツールやシステムの導入サポートの他、新卒や転職者へ社内システムの教育を実施することで、社員１人1人の円滑な業務遂行を支援します。
以上が従来情シスに求められてきた役割ですが、現在のクラウド時代において運用・保守業務はその必要性を失っています。また業務システムについても、SaaSなどのクラウド上で提供されるアプリケーションを利用できるようになっており、企業独自でシステムを構築するということは少なくなっているのです。
このような中で、今後情シスには一体どんな役割が求められてくるのでしょうか。次章で詳しく解説していきます。
クラウドで提供される業務システムは、往々にして業務の生産性に関する考え方が先進的であり、しかも随時バージョンアップしていきます。従って「自分の行動にシステムを合わせる」のではなく「システムに自分の行動を合わせる」というのが日常的に求められるのです。
しかし事業部門をはじめとする多くの社内ユーザーは、旧来の業務のやり方に慣れ親しんでいるために、「システムに自分の行動を合わせる」ということに自力で順応するのが容易ではありません。システムを使いこなせないばかりか、新しいテクノロジーに対して抵抗感を覚えてしまうケースもあります。
そこで必要となるのが、自社の業界・事業・業務においてITツールをどうやって活用するかを考え、そのための情報を関係各所へ提供する存在です。これからの情シスには、システムの機能や技術面だけでなく現場の業務プロセスにまで入り込み、具体的なユースケースを提案・サポートすることで、全社的なIT活用を推進する役割が求められています。
また、会社としてDXを推進するうえでは、単にITツールを組織的に活用することだけでなく、同時にチェンジマネジメント（組織変革）を進めていくことが必要です。新しいワークスタイルを実現するためには、職場の文化・風土も変革していかなければなりません。次章ではDXを促進する立場としての情シスの役割について紹介します。
クラウドサービスの台頭でIT部門の仕事がなくなる 企業のIT部門の仕事、と聞いて何を思い浮かべるだろうか。自社の…
DXを促進する情シス（情報システム部）の役割と専門家との協働
デジタルトランスフォーメーションにおいて最も上手くいかないことの１つとして、先進的なITツールに対して個人個人の理解度・受容度が追い付いていけず、会社として変化を受け容れられないことが挙げられます。ツールの機能、業務プロセスへの適用法が分からないことで現場が混乱し、これまでの業務のやり方やワークスタイルから脱却できないといったことがそれにあたります。
これを解決するために必要となる活動が会社のカルチャーチェンジ、社員一人一人のマインドチェンジです。単にITツールの活用法をナビゲートするのみならず、業務プロセスや職場の文化・風土というところまで踏み込んで、ユーザー部門に対して新しいワークスタイルの実現に向けた啓蒙活動を展開していったり、全社的な意識改革に向けたコミュニケーションを展開していったりといった役割がDX推進には不可欠なのです。
しかしこの役割は、専任のDX部門が担おうとしても失敗するケースがあるほど難しいものであり、そもそも経営層が事業戦略におけるITの重要性を十分に認識していなければ到底実現できるものではありません。では、情シスがDXを推進する役割を担っていくためにはどのようなアプローチをしたら良いのでしょうか。
それは情シスが持つIT知識や社内システムへの知見を最大限利用し、経営層を巻き込んで企業を変革する旗振りをしていくことです。ただし限られたリソースの中で上層部や会社全体に働きかけるというのは非常に負担が大きく、失敗に終わる可能性も大いにありえます。そこで１つの解決策となるのが、そういった業務改革・組織改革の支援を行うITベンダーと協働することです。高い技術力と豊富な支援実績を持ったITベンダーが上層部への答申からITツールの全社展開まで幅広く支援してくれます。そして、組織風土変革や社内へのコミュケーションは、自社の人事部門や広報部門が実務として実施していきます。現場部門との協働はもちろんですが、変革を企画する部門と協働することで、より全社的なムーブメントをつながります。
まとめ
以上のように、近年情シス（情報システム部）に求められる役割は大きく転換してきています。従来担ってきたITインフラやシステムの構築・保守・運用業務は不要となり、今後はデジタルトランスフォーメーション（DX）実現へ向けた社内ユーザーへの情報提供・啓蒙活動を行っていくことがその使命となっていきます。
もしあなたが情シスのメンバーであり、従来の役割を脱却できずにいるのであれば、業務改革・組織改革支援を行うITベンダーの活用を検討してみてはいかがでしょうか。
