  |
はてなキーワード: オンプレとは
誤字ではない。
昨年末に緊急経済対策補正予算で出てきたGIGAスクール構想。
全国の小中学生に一人一台パソコンを持たせようという大事業で、国内文教市場の趨勢が大きく変わりかねない一大事だ。
https://www.mext.go.jp/a_menu/other/index_00001.htm
文科省の示す標準仕様ではWindows10、iPadOS、ChromeOSの中からどれかを選べとされていて、Microsoft、Apple、Googleによる激しいシェア争いが繰り広げられる見通しとなっている。
そして、身バレするとたぶん叱られるので、増田でやることにした。
日本マイクロソフト、学校向けに低価格な「GIGAスクールパッケージ」を提供
https://pc.watch.impress.co.jp/docs/biz/1233155.html
これを受けて、巷では「文科省とMicrosoftがつるんでいる」という見方もされているが、これは正しくない。
確かに、現時点で文教市場において圧倒的に高いシェアを獲得しているのはWindowsであり、文科省からは当然事前に打診はあっただろう。
だが、現在出ている標準仕様はWindowsにとって有利とは言えないものになっており、文科省から便宜が図られているとは考えられない。
３つのOSの中で、最もマシンパワーを要求するのがWindowsであり、シェアが高いからこそ、低スペックWindowsの使いにくさも広く知られている。
標準仕様に対するスペック面での批判が多いことからもそれは明らかだ。
さらに、Windowsを快適に管理するには高価な管理ツールを利用する必要があることも、ユーザーは体験として知っている。
それでも、文科省からは他の陣営と同価格帯での勝負を求められており、条件としてはかなり苦しいところからのスタートとなってしまっている。
そんな逆風の中で「シェアを守る戦い」を展開するMicrosoftとしては、他社より先んじて不安やネガティブな印象を払拭しておく必要があった。だからこそ、最初に動いたのだ。
そこにあるのは強い危機感であり、下のリンク先の記事のように野望などではない。
｢教育5万円PC｣に秘めたマイクロソフトの野望。強み捨ててまで教育界を変革できるか
https://www.businessinsider.jp/post-207254
また、この記事ではオンプレからクラウドへの移行が思い切った挑戦のように書かれているが、周知のとおりナデラのMicrosoftはAzureの会社であり、何年も前から総務省と組んで自治体や学校のサーバをAzureでクラウド化させているし、文教向けには積極的にMicrosoft365を売り込んでおり、前からクラウドには積極的だった。
ただ、この記事が全くのでたらめかというと、そうでもない。
強い危機感をもったMicrosoftが切り捨てる決断をしたものがある。
藤原竜也がCMをしているSKY SEAは有名な商品で、ご存知の方も多いと思う。
そのSKYが、学校向けに提供しているのがSKY Menuという授業支援ソフトで、優れた操作性でWindowsの管理負担軽減に役立つので、全国で広く使われている。
一方で、かなり高額なソフトでもあり、学校のパソコン導入費が高止まりする要因の一つとなっており、今回はそこに目をつけられたのだと思われる。
また、機能的にも古き良き一斉授業において先生が子供たちを管理統制するためのものであり、文科省が今後進めたい方向性と合致しないことも大きかったのだろう。
これらはあくまで推測にすぎないが、結果として標準仕様は明確なSKY外しになっている。
SKYも文科省には積極的にロビー活動を行ってきただろうが、どうもこの事態を事前に把握できていなかったようで、大型事業から一方的に排除されて戸惑っているようだ。これまた推測だが、文科省ではなく総務省や経産省の意向が強く反映された結果かもしれない。
MicrosoftとSKYは非常に良好な関係を続けてきたが、そのパートナーを切り捨てる決断をせざるを得ないほど、今回、Microsoftは追い込まれている。
問題は、SKYの日本人向けの使いやすいインターフェースに慣れた学校現場が、どうしたってバタ臭い、Intuneの操作を受け入れられるかどうかだ。
周知の事実だが、現場にはシステム管理をできる人間など存在しない。
人に金をかけなかった分のコストがSKY Menuのコストだったのだが、そこをいきなり切り捨てて問題はないのだろうか。
iPadはタブレットPCの開拓者であり、幼児でも扱える抜群の操作性、軽快な動作、シングルタスクゆえの安全性、AirPlayによる快適な画面転送、豊富なアプリなど、学校現場に適した特性を持っており、かなりのスピードで教育分野に広がっていった。
個人的に使っている先生も多いし、子どもの家庭に転がっている割合も高い。
シェアは2位だが、パソコン教室を除いて一般教室での利用で考えた場合、ほぼ差はないか、上回っているかもしれない。利用される時間で考えらたら、おそらく上回っている。
ただ、今回のGIGAスクールでは、すでにiPadをかなりの数導入している学校以外で、新規にiPadを導入するところは少ないと考えられる。
その理由は、標準仕様が明らかにiPadOSを想定していないからだ。
一応選択肢には入れてあるが、標準仕様の構成ではBluetooth接続ではない物理キーボードを必須としており、4万5千円には到底収まらない。
これでは、すでにこれまで導入してきた財政力に余裕のある自治体以外は手が出しにくい。
これは、おそらく文科省がAppleを好ましく思っていないことによる意図的な仕様だろう。
Appleは文教向けの製品を提供しているわけではなく、あくまで個人向けの商品を使っているにすぎず、クラウドサービスもGoogleやMicrosoftのように文教向けに力を入れているわけではない。一社独占で選択肢もない。文科省の意向にも、全く協力的でない。
こうした背景から、文科省はAppleに有利とは言えない仕様を作ったのだと思われる。
すでにiPadで教育をはじめているところは、そのまま進めるだろうし、一定のシェアは確保するだろう。ただ、新規のシェア拡大は難しく、Appleがどこまで本気で取り組むのも見えてこない。
Chromebookの日本におけるシェアは低い。ここ１～２年でようやく少し広がり始めた程度だ。だが、世界では高いシェアを誇り、特に北米では文教向けパソコンの主流となっている。
世界から大きく乖離していることを気にしている文科省は、ここ最近Chromebookを強く推してきた。
今回の標準仕様に最も適合しているのは、誰の目にもChromebookであり、Googleのために仕様を作ったと言われても全く違和感がない。あの3種類の仕様の中で、4万5千円できっちり使える状態になるのは、Chromebook＋G suiteしかない。
癒着を疑うなら、MicrosoftではなくGoogleだろう。
それがわかっているからMicrosoftは危機感を強めているのであり、また、その反応を引き出すために文科省は不自然なまでにGoogleを優遇したのだと思う。
とにかく、これから新規に導入する場合、自治体の費用負担が最も少ないChromebookが第一の選択肢になるだろう。
Google自身も、ここ最近は日本の文教市場を本気で取りに来ていて、下の記事にあるように EDIXでは凄い人だかりで熱気に満ちていた。
教育現場はChromebookが本命？ 主体的な学びを実現するために、クラウドが欠かせない理由とは
https://www.watch.impress.co.jp/kodomo_it/news/1197938.html
まだ目立った動きは見せていないが、どこまで本気の野心を抱いているのか、それによって信じられないほどにシェアを拡大させる可能性がある。その場合に食われるのは、AppleではなくMicrosoftだ。
GIGAスクールの台風の目になるのは、間違いなくGoogleだろう。
ここまで書いてきたとおり、シェアを守ろうと必死なMicrosoftと、シェア拡大を狙うGoogleの構図が中心で、Appleは、少し離れたところで現在のシェアを維持する形になるだろう。
かなり不利な情勢からスタートしたMicrosoftだが、いち早く動いたことで印象は上向いた。
あとは、低スペックWindows10への不安、SKY抜きになる管理面での不安、最終的な費用面での不安、といった知っているからこその不安をどこまで払拭できるかが重要であり、継続した情報発信が求められる。
一方のGoogleは、知名度の低さや、知らないことによる不安を解消するために、何がどこまでできるかを広く知ってもらう必要がある。
また、Googleのサービスは、わかりやすいUIで一見親しみやすいが、サポートは充実しておらず、必要な情報が得にくい。
Office365とG suiteの両方を管理したことがある人間ならわかってくれると思うが、初見でとっつきやすいのはG suiteだが、情報収集含めて最終的に管理しやすいのはOffice365の方だ。
すでに書いたが、学校現場にはシステムを管理できるような人間がいない。
それを踏まえたサポートが提供できるのかどうか、学校や自治体は価格だけを見て飛びつく前に見極めないといけない。
Chromebookに以前から力を入れてきたチエルのような企業が、そこを補えるようになると面白い。
チエル、GIGAスクール構想の1人1台環境に最適なChromebook活用パックを発売
https://ict-enews.net/2020/02/07chieru-2/
最終的には、Microsoftが50％くらいに落ち着き、Apple30％、Googleは20％くらいまで伸びるのではないかと見ているが、さてどうなるか。
文教市場を押さえることは将来ユーザーの獲得につながるため、各社とも力を入れてくると思われる。
補足→ https://anond.hatelabo.jp/20191205212350
これは退職者アドベントカレンダー2019 (https://adventar.org/calendars/4051) 5日目の記事です。最初は自分のブログに書くつもりでしたが、書いてるうちにどこまで筆が滑っているのかわからなくなったので増田に投げることしました。そしたら余計にタガが外れたのはご愛嬌。
よく見かける「未経験からエンジニアへ！」ストーリーの、あまりなさそうなルートです。よくあるルートのほうはなぜかTwitterで報告して「○○系エンジニア」的な命名をしてから入社その後の動向が闇に葬られているのをかなりの確度で見かけますが、まあ、なんか、いろいろあるんでしょう。逆にそういう成功（？）体験の生存バイアスを強化する情報ばかりあふれていると情報として健全でないように感じます。
といいつつ後日しれっと消えてたらInternetArchivesか魚拓で会いましょう。
この話はここから先はフィクションです。剣も魔法も労基法も出てこないファンタジーです。
地方に潜むフリーターです。好きなvirtual beingsはロボ子さんと東雲めぐさんとれいきらさんです。
これまでは自分のためのプログラムを書き散らすだけで、ITとは無関係のバイトをしてきました。玉掛とフォークリフトなら任せろーﾊﾞﾘﾊﾞﾘ
会社にもぐりこんだいきさつはやや特殊なのでぼやかします。とあるきっかけで知り合った人から誘われました。リファラルです。なお、とあるきっかけはなにかと炎上しがちないわゆるプログラミングスクールなどではないことを防火剤がわりに書いておきます。そんなもんに使う金など無い。
その人のことはあんまりよく知らなかったのですが、CTOとして手伝っている会社のシステム部門で人手を探しているとのことでした。会社のホームページにはリクルートページなど無く、何をやっているかいまいち要領が掴めなかったのですが、ざっくりと自社製のWebアプリ開発をやる感じらしく、内容も聞いた限りでは（自分のスキルと照らし合わせて）そんなにどえらいわけでもない印象でした。ちょうど金もないし無職だし、少し経験でも積んでみるかという気になったので、この際ホームページがDreamWeaverのサンプルを流用したまんまといった細かいところは観なかったことにしました。
面接にいくと社長から「いつからこれるの？」と言われたので「あっこれは」となりましたが、金がなかったので是非もなくそのまま入社の運びとなりました。この頃はプログラム書いて金もらえるなんてサイコーとか思ってました。ちなみにgithubやatcoderのアカウントを書いた職務経歴書は一顧だにされませんでした。
地方の製造業のシステム部門を切り出して別会社にした形態の、創立数年ほどの会社です。自分のほかにもうひとり、社内情シスのようなことをしている方がいましたが、基本的にはサポートが専門な感じでした（ただし肩書は自分と同じでしたが）。紹介してくれたCTOは週に一度のMTGに顔を出すだけということで、実質的に常駐している人間でプログラムが分かるのは業界未経験の自分だけというチャレンジングな環境からスタートしました。なお入社して社内の平均年齢を大幅に下げることになりました。
ちょうど入ったタイミングで情シスの方が抱えている仕事があり、とくにやることもなかったので手伝いました。グループ会社のサイトをスマホ対応させるもので、事情はわかりませんがそれまで他社に制作を委託していたものを自社で運用することにしたとのことです。みてみるとWordPress4でPHP5が動き、Bootstrap3を使ったオリジナルカスタムテーマで運用してきた様でした。もちろん仕様書やローカル環境もあるはずがないのですが、どうせ自分はWebデザインなど知らんのでとりあえず直にheader.phpにviewportを書いてmain.cssにメディアクエリを設定して、ザ・web制作初歩みたいなレスポンシブ対応をしましたが、デザインについて当事者との意見のすり合わせの機会なんかの開発手順はなかったので良しとしました。
入社して2周間ほどのち、社長についてこいと言われた打ち合わせの後日、MTGで「昨日のアレの進捗はどんな感じなの？」と聞かれたことから、いつのまにか新規案件を自分に一任されていることに気づきました。仕様は前日の打ち合わせがすべてだった模様です。要件定義や技術選定・検証のような工程など決まってないので好みで揃えました。趣味と関心からExpress+Mongo+Reactのセットか、触ったことのあるDjango/Railsでざっくりやるか、どうせならDockerも使い時か、こんなときに相談できる同僚やメンターが欲しいなぁなどと考えていたら、CTOがそれまで作っていたやつをみるとPHP+ES5+MySQLだったのでなんだかんだでそうすることになりました。PHPを初めて触り、「これがペラ1のphpにjsもcssもなにもかも書いていくといういにしえのスタイルか…！」と新鮮な感じでやってました。
Windows Server 2012で動いていたサービスをLinuxに移行しました。これは自分が入る前から情シスの方が任されていたのですが、マニュアルに沿ってコマンドを打ちこんではどこかで転け、エラーは読まずにあきらめてCentOSインストールからやり直すということを繰り返していたのを見るに見かねて手伝いました。SSHでPowerShellからマニュアルのコマンドをコピペして実行する方法を教えてあげると目を丸くされました。shellファイルを書いてあげると魔法をみるのような顔で驚かれました。自分が入ってなければどうなっていたんだろうか...
毎日出退時間を規定のEXCELフォーマットに記帳する必要があり、これが非常にめんどくさく無駄に思えたので、自動記述するpython/Goスクリプトを書きました。これは入社して2日目とかだった気がします。しかしここを自動化しても「印刷して人事に提出し、それをもとに人事の方がまたEXCELに書き込む」と知り虚無になったりしました。
これはやったことというか思うところあってプライベートで取り組んだことです。自分の想像していた開発現場との乖離を感じたので、こういうのはFE勉強すればわかるのかもしれないと思って1ヶ月くらいやって取りましたが、得られた知識で会社に活かせそうなものは何一つありませんでした。
チーム開発などという概念は存在せず、「1案件を1人で上流から実装、運用、保守、サポートまですべてやる」という進め方でびっくりしました。手持ちの技術スタックでできる範囲でギリギリなんとかやった感じです。よく転職サイト上で見かける文言で「お任せします」がありますが、これとかも要するに「丸投げ」の換言なんでしょうか。わたし気になります。
自分のように途中からジョインした人に対しての業務移行のシステムがないことから感じていましたが、案の定「誰かが抜けたあとの引き継ぎの機能」も整備されてないことに気づきました。もともとオンボーディングや研修の概念などありません。えらいひとは「そのへんは現場で協力してうまくやって」と丸投げし、すべての作業を自宅でやっているCTOは社内のこうした事情については放任で、いちおう情シスの方がいつのまにかメンター代わりになっていたものの、不明点を尋ねても頓珍漢な返答が多くもどかしかったです。どのサーバでどんなサービスが動いているのかやSSH情報を聞き出すのに苦労しました。こうした不幸と無駄な時間をなくすためにドキュメントを整備しようとしたのですが、頓挫しました。これからも物理フォルダーと社内サーバに散逸した各種の情報は混沌を深めていくのでしょう。gitも無いし。
サーバはオンプレでした。自分はクレカをもっていないためパブリッククラウドを試す機会がなく、ぜひとも触ってみたかったのですが、承認を得るための説明がうまくいかず、結局VBoxでやることになりました。唯一、それまで使われていたVBoxではなくVagrantを導入したのは少しだけ救いでした。どうせ自分しかいじらないのですが。
余談ですがオンプレで面白かったのはHDD増設のために初めてデータセンターなるものに入ったことです。インフラ/ネットワークはまったく分からんしなかなか個人で試せない領域だし縁がないかなと思っていたのですがやはりそこに見える物理層が存在するというのはテンションがあがりますね（断層みたいに言うな）
イキってカイゼン・ジャーニーや情熱プログラマーを買って読んだりもしました。目につくように共同図書のつもりで「ご自由にどうぞ」を添えて自分のロッカーに置いておいたら「私物は持ち帰れ」と言われてしまったので持ち帰りました。
さてお待ちかねメインディッシュですね。
もともと技術やコンテンツの会社ではなく、技術畑の人間がまったくいないことのインプレッションが次第に違和感として強く響いてきました。ITエンジニアとしてやっていくつもりの観点でみると、学習や成長の土壌は無いように思えました。協調関係や信頼がうまく築けず、自分のすべき道筋が不明瞭のままやっていけるほどタフなYATTEIKI精神ではなかったのです。
これは地方の、それもIT気質のあるわけではない、ワンマン経営の中小製造業ならばどこにでもあることかと思われますが、随所に感じるレガシーさに疲れてしまいました。一例を挙げると、毎朝30分に亘り行われる全社清掃（もちろん業務時間外）、社是の復唱、『感謝の言葉をみんなで味わうポエム』の輪読、その感想大会、頻繁に行われる中身のない会議、日報をエクセルで書いてメールで送ったり、出退勤表を毎日エクセルに書いて印刷して事務方に持っていくなどのルーティンがけっこう苦痛でした。
社内のコミュニケーションツールはLINEだったので使い勝手も悪く、会議でchatworkかslackを使いましょうと提案しても誰一人としてそれらの存在を知らず、「勝手にやってくれ」と言われてしまったり。LINE WARKすら知らんやんけ。説明しても「skypeじゃ駄目なの？」と言われたので諦めました。
えらい人の思いつきのたびに方向性が変わり、当人は発言したらそれで全て完了した気になってしまったのか、会議終了後の10分後に「さっき言ったやつまだ出来てないの？」などと言われた時はギャグかと思いました。会議の議事録も誰も見返さないので果たして意味があったのか疑問です。誰かひとりでもmarkdownが書けたり、少なくとも書く気があれば勉強会を開催してHackMDなどを推せたのですが。議事録が機能していないエピソードとしてひとつ思い出しました。開発中に機能追加を下された際に、その挙動は完全にプラットフォームネイティブであり今の技術選定だと作り直しになり、結果納期に間に合わない（し、自分の技術スタックからも遠く外れていたので学習コストも加算）と発言したらその場は収まったのですが、会議終了後に個人メールで「やはり機能はマストだ」と伝えられました。当然それは議事録に反映されることなく、なんかしらんけどそういうことになっているという感じになりました。
初めてのエンジニア職でしたが、社内に開発をる人やマネージャー職は不在で、いわゆる開発現場での流れを学ぶことはできませんでした。少なくとも技術を知らないえらいひとが「俺がスケジュールを立てたからこれに沿ってやれ」と、”開発”と”広告作成”しか書かれていない2週間の計画表をもってくるような現場はシステム開発として正しいのか、 と本能が警告を発していました。
もともと会社は製造業から始まったため、えらい人たちとの見解に齟齬があったのは体感としてあります。同じものづくりといえど設備とマンパワーと時間が線形的に結果に結びつく工場業務と異なり、システムエンジニアリングはかける時間の見積もりも容易でなく、かかった時間が必ずしも結果に結びつかないものである、と言う事実は受け入れられ難く、知識ドメインやマインドセットが異なれば説明も困難です。しかしながらえらいひとは一様に「経営者視点を」の号令で、経営誌を配り、その感想文の提出を義務付けるなど、現場視点を欠いた行動で現場（というか私）を疲弊してました。気づいたらSEO対策や別部署のMTGのためのプロジェクター設定、全PCのwindows updateに伴うドライバの更新の役も同一の職掌として役付けられそうになっていたり（一部は実際に情シスの人がやってた）、It’s not my workなシーンがみられるようになっていました。
そして、よくあることですが、理念と実態が乖離していたことです。世界をよりよくと言いつつ、目先の掛け算を考えてばかりのように思えました。グロースする中で発生しそうなあれこれをすっ飛ばし利益だけを皮算用するのはいいとして、データ量やトラフィックを指摘すると「そこは現場努力でしょう」となるので、世界を良くする前に精神を悪くしてしまい人生で初めて心療内科にいったりもしました。一応グローバル展開を目指しているとしながらサーバからMailerDaemonが飛んできたら「ギャっ英語っ！」と言って読まず捨ててたり、急にサービスが止まった時には激怒して責任の所在の追求を求められたため、草創期にえらい人の個人アドレスで取得してほったらかしにしていたドメインが失効したことが原因と伝えたら「あれはもう読んでいないアドレスだし仕方ない。こういうピンチのときこそチャンスにしようぜ」という謎理論を出されたこともありました。
違和感が確かなものになったのは、外部に提出する資料で社内の数字が異なっているとを指摘すると「こういうのは見栄が大事なんだ」と暗に公文書偽造をほのめかされたことですが、これ以上は闇っぽいので書きません（たぶんどこもやってて罷り通ってる範囲だと思うけど）
総じて、心理的安全性の低さ、そこからくる身動きのとれなさ、ロールモデルの不在、前時代的な風潮、社内文化へのミスマッチと不理解、成長の実感が沸かない不安と不満、それらに伴う摂取アルコール量の異常な増大と過食、といった要因の積み重ねが、ネガティヴな形での退職へと駆り立てることになったのだと思います。まあ、よく知らんうちにリファラルしてるところからして「採用・教育コストを考えてないのでは？」の念はあったのですが。中身がまったく不透明の状態で飛び込んだらそうなるよなぁ、の好例かもしれません。誘われた時はわりと藁にも縋る思いだったのでしかたないね。
現在はスキー場で住み込みバイトしてます。無考えに退職すると年を越せないことに気づきました。
可処分所得・可処分時間いずれも今の方が上なのはちょっとウケます。賃金はふつうに生きていければいいので前職程度でも気にしなかった程度なんですが。いまは映画をみたり積ん読を消費したり、在職時は深いところまで触れなかったPHPをいじったり、生PHPしかやってないことに気づいたのでcakeやったり、あとはweb周辺も久しぶりにキャッチアップしたりしてます。nodeネイティブおじさんなのでFWはangularしか知らないんですよね。vue/nestが面白そうな感じです。あと寮のwifiが談話室限定で窒息しそうだったので、持ち込んでいたラズパイをルータにして部屋まで飛ばしたら隣室の同僚から感謝されたりと活動は多岐に渡ります。
先のことはなにも決まってませんが、ちゃんとエンジニアリングしている組織で開発してみたいなという気持ちがあります。レビューやスクラム、アジャイルなんてのはひとりだと不可能ですし。ですが、やはりそういった会社は日本では都市部にばかり集中しているのでしょう。自分は空気の悪いところには住めないし、案外また辺鄙なところでtechとは無関係のことをしているのかもしれません。ワーホリでも使って海外で大麻栽培でも始めようかなぁ。
巷説に流布する「未経験からエンジニアへ」の言説のたぐいは、どちらかというと技術力よりもコミュ力が偏って高いタイプが生存しがちな雰囲気を感じます。たまにTLに流れてきたのを見かけますが、ああいった立ち回りは自分にはできないしやりたくないなぁと思ってきました。社会の要請ならばそれまでですが。
自分は体系的な情報教育を受けていないどこにでもいる地方高卒で、下手の横好きで趣味プログラムを書いてきたし、続けてるってことはそれなりに好きなんだと思います。得意じゃないけど。んで、こんなのがITエンジニアをしたサンプルというのは見かけないかもなぁと思って投稿しました。光あるところに闇あり。
といいつつ、やっぱり好きなことの結果がおかねになるのはいいよなぁと思った次第です。プログラムを書くのは楽しいけどエンジニアリングは超絶むずい、が雑な総括ですが、今回のことを顛末次第にはする気はないので、どこかに拾ってもらえるよう精進するきもちになりました。
会社のシステムをオンプレ＆オフラインにしてセキュリティを守るとか言ってそう
結局どこまで想定するかだけなのよ。千葉県民だから知ってるけど、そこそこの台風は想定しているよ？
今回はイレギュラー過ぎ。それも台風だから途中から対応できない。行動開始は台風通過後のみ。無理でしょ
鉄塔倒れるな、電線地下にって言うけど、今度は地震が問題になる。設計が問題になる。資材も問題になる。そこまでして房総半島を風速60mにもビクともしない地域にすべき？県民税で
初動が遅いってのも被害を受けた場所が複数ルートがあるような場所じゃないから状況を知るのは遅くなるし、支援が行くのも遅い
場所はあんまりいうとバレるから関東近郊のDCを借りて、酒と食べ物買って飲み食いしながら夜はめちゃくちゃに障害復旧するっていう催し。
こういういわゆる障パを主催している幹事に誘われて初めて参加した。
インシデントバー（インシデントばっかり発生する）とか少しだけ行ったことあって、技術的好奇心があったから参加した。
リビングで適当に酒飲んだりご飯食べてたら、いきなりKubernetesをオンプレに展開したいとか唐突に言い出して、障害パーティーがスタートした。
適当に近くの運用担当とペアになってどんどん運用部屋（ISMSで規定されている）に吸い込まれていく。
1回1時間弱くらいで手順を確認して、コンソールからコマンド打って、復旧確認して休憩して、また近くのダブルチェック担当と障害復旧しに行く。
部屋中に溢れる指さし確認の声がうるさくて眠たくならない。
これまで、無理に安全側に倒す方ではなかったけど、転職イベントとかで口説かれたりして転職するかしないかという駆け引きのコミュニケーションばかりしていた。
この回転寿司のように障害復旧を繰り返す姿はスポーツのような動物園に来たような気がした。
正直、全然酒に酔えなくて全く楽しめなかった。全然技術的達成感を感じなかった
幹事には楽しかったからまた誘ってとか社交辞令を言ったけど、多分もう障害パーティーはいかないだろうな。
ISUCONみたいな絡みが好きみたいな感じで、ああいう作業だけしてる場はある意味人間の動物的な本質なのかもしれないが理解できなかった。
金払ってまで障害復旧はしたくはねーな。
| 時間 | 記事数 | 文字数 | 文字数平均 | 文字数中央値 |
|---|---|---|---|---|
| 00 | 91 | 16414 | 180.4 | 53 |
| 01 | 65 | 4321 | 66.5 | 45 |
| 02 | 80 | 8389 | 104.9 | 47 |
| 03 | 5 | 531 | 106.2 | 132 |
| 04 | 13 | 3729 | 286.8 | 74 |
| 05 | 9 | 883 | 98.1 | 60 |
| 06 | 14 | 2305 | 164.6 | 47 |
| 07 | 43 | 3696 | 86.0 | 44 |
| 08 | 68 | 4893 | 72.0 | 37.5 |
| 09 | 120 | 11902 | 99.2 | 40.5 |
| 10 | 141 | 9510 | 67.4 | 32 |
| 11 | 141 | 12036 | 85.4 | 40 |
| 12 | 133 | 8323 | 62.6 | 37 |
| 13 | 108 | 9428 | 87.3 | 49 |
| 14 | 167 | 7495 | 44.9 | 22 |
| 15 | 132 | 10729 | 81.3 | 28 |
| 16 | 120 | 10646 | 88.7 | 34.5 |
| 17 | 164 | 11796 | 71.9 | 44.5 |
| 18 | 120 | 14812 | 123.4 | 30 |
| 19 | 92 | 9589 | 104.2 | 37.5 |
| 20 | 125 | 9658 | 77.3 | 27 |
| 21 | 123 | 14375 | 116.9 | 42 |
| 22 | 119 | 9105 | 76.5 | 30 |
| 23 | 139 | 11308 | 81.4 | 40 |
| 1日 | 2332 | 205873 | 88.3 | 37 |
バーテン(19), GSOMIA(22), ＧＳＯＭＩＡ(5), バーテンダー(26), EC2(4), 課題図書(5), 送信先(3), 捨象(3), 原稿用紙(9), オンプレ(3), 混線(3), 破棄(31), 日韓(17), バー(18), 報復(9), 韓国(105), クラウド(7), 北(7), 外交(8), 夏休み(9), 反日(9), 聞け(19), 韓国人(14), サーバー(6), 両(6), ロシア(11), 北朝鮮(12), 米(12), モテ(21), 非モテ(13), アメリカ(40), なろう(9), 戦争(25)
■1999年と2009年は大きな違いだったけど、2009年と2019年はそんな変わんない /20190822233353(15), ■息子が妹にセクハラする。 /20190823122351(12), ■普段は敵だけどある時だけ共闘するシーン /20190823165435(11), ■職業・バーテンダー /20190822170940(10), ■ /20190823163251(10), ■幸せなら態度で示そうよ /20190822162044(8), ■anond：20190823152435 /20190823152530(8), ■「メールを送りましたので確認お願いします」という電話 /20190823100719(7), ■コミュ障の会社勤め /20190822194952(7), ■読書感想文は苦手 /20190823120243(7), ■終わり切ったIT業界の今と昔の仕事の仕方の違い～SIからweb系まで～ /20190823153139(7), ■かわいくて素直なら結婚なんて1秒で出来るのに30にもなって独身の主査とか何して生きてんだろ /20190823171309(6), ■人間としての義務教育もできなくて辛いのでアドバイスがほしい /20190823085401(6), ■そうよ私は体操部出身の女 /20190823142842(5), ■温度が出てくる歌 /20190823150142(5), ■しょうがないなあ、のび太くんは。ちょっとだけだからね！ /20190823023102(5), ■彼氏できねえ /20190823231833(5), ■確かに戦争ってのは経済政策としては特効薬なんですよ。 /20190823020333(5), ■韓国が感情的という話 /20190823002214(5), ■ /20190823095043(5), ■会社で仕事中だけど /20190823093450(5)
6547499(1734)
ディレクターサイドが大きいタスクを嫌がる工数が足りないと騒ぐ
リファクタしようにも軽微な改善を積まれまくって開発ができない
イベントを行うもイベントが終わるたびに燃え尽き症候群でエンジニアがやめていく
開発の経営陣は古いシステムをどうしようという話に一切口を出さず新しいシステム・機械学習に夢中
クローズするサービスを残し続ける、保守しなければ無料じゃねーんだよ
DBパンパン、使われていないテーブル多数あるけど怖いので消せない
CTO直下のチームは飽き性で色々なフレームワークを開発し運用チームに渡しまくるせいでもうぐっちゃぐちゃ
マイクロサービスを無理やりしたせいでバージョン違い、ミドルウェアの違いなどで更にカオス
DDDとか会社で誰も回せないし正常に導入できていないのに、推し続ける謎行為（俺たちは勘でDDDをやっている）
主要なサービスと新規事業サービスを乱立するのは良いが、損益点をはっきりさせて撤退する勇気を持つ
オンプレはもう限界だよ、オンプレでもいいけどサーバー構築を1h以内にやってくれ頼む
大規模なリファクタリングを行うために経営陣は今の現場の限界に気づいてくれ、株価見ろよ利益率悪いのが丸わかりだろ・・・
自分たちは弱いことを認めて改善をしていけばいい、全員やめろとは言わないけどもっと運用チームの一番下と経営陣がしゃべる時間を作って生の声を聞いてくれ
エンジニアをイベントごとに巻き込むな、全部任意イベントにしてくれ
エンジニアと営業を同じ制度・ワークフローで処理するのは限界ってことに気づいて
会社のお金の使い方見直しません？その社内イベント本当に必要ですか？
色々と思うところがあったのでここに書きたい。
とか言われて、これが不快だった。
オンプレ環境で働くことは古臭いとでも思われているのだろうか？
クラウドエンジニアは、インフラエンジニアとは種類が違う仕事という認識をしている。
AmazonとかGoogleとかのすごいエンジニアがつくって運用している基盤を、お金払って利用しているわけで、
それを利用するのに癖があるからそのあたりをあれこれするのがクラウドエンジニアなんだと（勝手に）思っている。
だから、クラウドエンジニアにマウントとられる意味わからんなと思っている。
インフラエンジニア不要論とかも時々耳にするようになってきたけど、
オンプレ系(プライベートクラウド含む)の仕事が消滅するわけないと思っている。
自分はオンプレ系しか触ったことがないから、観点が偏ってると思うし、
昨今流行りの機械学習でプロジェクトがぽこぽこ立ち上がっている状況なのだが、一部の人を除き、apt-getで躓いているのは会社にとって損失だと考え、オンプレクラウドのようなものを構築することにした。
グループ全体の規模はそこそこ大きいが、将来単なるアッセンブリー屋になることが目に見えている事もあり（今後20年以内には喰われてしまうという憶測もあり）ネットワーク、Linux、コンテナ、プログラミングが出来る自分が社内の機械学習、引いてはITインフラの民主化、なんだったら外販できるくらいのもの作ってやろうと鼻息巻いて無理やり一人プロジェクトを興すことにした。
まずは既存DHCPサーバ、名前解決ができないDNSサーバからゲートウェイPCを用いてネットワーク的に分離、社内の物理的な設置スペースの問題でデスクトップPCとサーバPCが離れた所にあるため、WireGuardでVPN構築、ゲートウェイPCはそれぞれKea DHCPサーバ、PowerDNSサーバを稼働させ、OpenStack導入検討時に悩んだ鶏が先か卵か先か問題を解決することにした。
上述の通り、システム構築にあたってOpenStackやMAAS,RancherOSなどを検討したが、社内のニーズを「100%」汲みとった上で、次世代のオンプレクラウド（個人的にはエッジクラスタがゆるく繋がるアメーバクラウド？のような呼称があっている気がするが）を構築するにはどれも痛し痒しで何かしら制限がついて回るのは許容できなかった。これは今後5年、特に海外事業所の開発者の事を考えた時には外せない要件だった。
とはいえmiekg/dnsを用いてCoreDNS進化版を作るにはリソースが足りず、BINDを用いるにはSA対応がしんどすぎるため、APIを備えており、今後も進化が見込めるであろうOSS、また必要であれば商用製品や保守サービスが受けられる事から上記2つを選択した。
PowerDNSはさておき、ISC KeaはナウでYANGなLinux YANGに対応しようとしているなど（言いたかっただけ）、世の中のオンプレ環境を塗り替えるためには兎にも角にもAPIゲートウェイが重要だと考えたため、双方が提供しているAPIをうまく吸収するミドルウェア（とちょっとしたAPIサーバ）をGo言語で作成した。
次に世の中のパブリッククラウドやOpenStackなどを触ったことのある開発者はCloud-initに慣れているはずという前提の元、対応コスト勘案の結果、NoCloudで対応しつつ、上記のAPIサーバと連携し、ベアメタルマシン管理した事のある人はわかる、ベアメタルマシン特有の諸問題を解決することにした。
まぁなんだかんだ大企業なのでお金で解決する手段もあるが、そもそも高集積ラック搭載GPUサーバ購入の稟議が通るような会社だったら既にKubernetes導入しているだろうし、俺もこんなことしてない。
脱線したが、上記以外にも検証やバックアッププランとしてAnsible記述などの作業はありつつも、3ヶ月かけてようやく基礎となるインフラ基盤が構築できたため、nuxt.js+goで簡単なフロントエンドサーバを構築し、一人情シスの様相を呈している部下のリソース開放、Calico対応+Kubernetes導入、不安がっている上席が安心できるように、分かりやすい餅を用意しようとしている、というのが現状。
ここまで寝る時間も惜しんでトップスピードを維持したまま頑張ってきたものの、少し限界を感じている。
特にオンプレクラウドは部外者が中々見えてこないものがあり、なんならその見えないものを限界まで吸収できるように、かつ現実的に実現可能なギリギリのラインを狙っているのだが、そもそも周りに相談しようとしても何を言っているのか解説する所から始めないといけない。
覚悟はしていたが、ふとした時にとてつもない脱力感に襲われてしまう。
世の中を切り開いてきた諸氏はおそらく一度はぶつかったであろう、この内なる自分の壁をどのように突破してきたのだろうか？
ひたすら孤独との戦いだというのは頭では理解しているものの、突発的にくるこの脱力感はいかんともしがたい。
