はてなキーワード: 仕様変更とは
拡大表示するとtableの枠線の太さがまばらになって気持ち悪い
線の太さまで変えないでほしい。
せめて全部の枠線を同じ太さにしてくれないかな。
4行に1本だけ太線とかバグかと思ったよ。
以前は125%表示でも枠線の太さが混在するなんてなかったのに仕様変更したのか?
運用監視の現場で週末も心休まらない皆さんこんばんは。一人運用チームです。
さて、世間ではDevOpsだのイケてるクラウド監視ツールだの楽しそうですが、そうでない人もいますよね。
もちろん、「運用チーム(実態は俺1人)」なんてのは、ペイグレードに応じた責任感で粛々と業務を進めて理不尽には応じないのがプロフェッショナルな態度ですが、
お銭を稼がなければ生きていけないのも渡世の世知辛いトコロです。
これから金を生むんだ!という強烈な人間が金を引っ張ってこない限り、コスパの悪いサービスにリソースは割り振られません。
つまり、今もし運用監視体制が限界ギリギリで踏ん張っている場合、拡充される可能性はありません。諦めましょう。
今回のみずほ銀行の調査報告書(2021年6月15日発行分)p114-p116におけるヒアリング結果が悲哀に満ちているのも当然と言えるでしょう。
教訓は、「維持メンテの人員が不足したら、それ以上増えない」というものですね。
維持されている(ように外部から見える)場合、余剰人員は不要なコストです。
さて、みずほ銀行の調査報告書を読むと、今回大ごとになっている「通帳の取り込み」というのは何度か起きていますが、改善されていません。
まあ、やりたくないよね、「障害が起きた時の顧客影響を抑える」なんて後ろ向きな投資。
なお、盛大な怒られが発生した結果、再発防止策として、今回の通帳取り込み5244件のうち4915件をなくせる仕様変更が入りました。
直せないのではないのです。直さないのです。
教訓は、「障害が発生しても、予算を握ってる人に被害が及ばない限り、リソースは降ってこない」というものですね。
過ぎたことは過ぎたこと。いま維持メンテがギリギリのところに新たにリソースが投入されることは基本的にありません。
外圧があれば別ですが。
さて、ここまででわかる通り、いま1人運用やそれに近い運用をしている皆さんに、追加人員は来ません。
リソースは降ってきません。予算は通りませんし、人員は増えませんし、なんなら残業代も出ません。
もうわかりますね?障害は握りつぶしましょう。出しても一つも良いことないんですから。
慢性的に時間がない皆さんに朗報です。実は時間を生む画期的なテクニックがあります。
業務について最初に、毎日1時間を「斧を研ぐ時間」にするのです。
大丈夫分かっています。今あふれんばかりに仕事があって実際あふれているんでしょう?
どうせあふれるんです。あふれさせましょう。どうせ怒られるなら「仕事」したいじゃないですか。
WARNINGやERRORまみれのログが定常的に出ている状態は、たいへんよろしくないです。
握りつぶしましょう。
「そのエラーは概ねもっと深刻なエラーが吐かれるまでは気にしなくて良いヤツ」みたいなのがあるでしょう?
消し去りましょう。痕跡すら残さずに。
そのために、運用監視用のログが必要なら、生成しましょう。その生成途中で握りつぶせば良いのです。
「ドラえも~ん、大量にエラーが出たら処理しきれないよ~」「のび太君それ全部処理するの?」「え?」「え?」
当たり前のことなんですが、人間には概ね4本以下の手しかありません。俺は2本派です。
運用チームの対応者が一人の場合、対応できる時間当たりの処理能力には上限があります。人間はオートスケールしないんで、当たり前ですね。
つまり、「同じようなエラーで同じような処理をしないといけないが、違うエラーメッセージ」というのは、無意味です。
さっき、自分が理解ってるエラーを握りつぶすことを日課にしましたね?
次の段階です。対応できるエラーだけ残して握りつぶしましょう。
もちろん、裏では垂れ流しで大量のエラーログは取っておく必要はあります。見るエラーは一つで良いはずです。だってまずそれ対応するんだもの。
例えば、1人の時に100件のエラーが出ても、3人の時に6000件のエラーが出ても、処理できないことに変わりはありません。
つまり、それは「記録には残すエラー」ですが「対応のトリガーにするエラーメッセージ」じゃ無いんです。
例えば、幸せなことにショートメッセージやメールに自動発砲できる場合、初手だけ発砲して残りは握りつぶしましょう。
飛行機や宇宙船で機長が言うでしょう?事故が起きてアラーム鳴ってたら、アラームを切れって。
アラームは気が付かないと困るからワーワー言うんであって、処理してる最中は邪魔なだけです。
握りつぶしましょう。
多少手荒でも良いんです。エラー即再起動みたいな乱暴な奴でもオッケーです。
思い出してください。リソースは無く、対応するのはあなただけ、維持管理出来て当たり前。
どうせクレームの電話がかかってくるなら、一人一人に真摯に向き合って丁寧に応対するのも良いかもしれません。
身命を賭してクレームに寄り添って慚愧に堪えぬその思いを真剣に伝えましょう。
その間に、システムは自動的に再起動し、他のクレームの電話は保留音を聞くことに飽きてきます。
慣れてくると、鼻をほじりながら「誠に申し訳ございません、今誠心誠意全力で復旧に」と喋りながらチャートを引っ張り出して手順を追えるようになります。
復旧手順RTAチャートの作り方は、珍しく潰しの効く能力になるので磨きましょう。
しっかりとしたチャート、常にチャートを見直す向上心、日々の走り込み、本番での平常心。
出てきたモグラを叩くのではないのです。モグラの出現順序を覚え、練習し、効率良く叩くのです。
さて、最近も陰謀が話題になりましたが、情報を知るものが増えれば握りつぶすことは難しくなります。
人を減らしましょう。
レポートラインは一本に絞り、その障害が起きたことになると給料が下がるタイプを相手に連絡を取りましょう。
うっかりミスからメールのCCから落とすのでも、手順書を作ったときに気が付いたら項目が無くなっていたのでも問題ありません。
残念ながら、その時不思議なことが起こって、連絡先が増えることもあるかもしれませんが、そういう時も諦めましょう。
出来ることは変わりません。
みずほ銀行の場合、A2以下の障害ランクの場合、頭取は別にニュースで初めて情報を知っても良いのです。
システム障害というから、なんか大変なことになるのです。インシデントだの障害だのは無くしましょう。
それは「予定されていた手順」なのです。
納品されたハードウェアには不備があり、雷は落ちてコンセントまで到達し、ケーブルは間違えて刺さり、ココしかないというタイミングで停電になります。
ただでさえ維持メンテの人員が足りてないのに追加機能や新規バッチが走ったりすることもあるでしょう。
チャートです。RTAチャートです。復旧RTAチャートを作るのです。
そのチャートには不足しかないかもしれません。ハードウェア故障→上司に電話、停電→上司に電話、みたいなチャートもよくあることです。電話しましょう。
それは障害ではありません。事前に探しておいたルートを走る競技です。
李下に冠を正さず。
例えカンムリが傾いてると分かっていても、問題になりそうな場所で手をあげてはいけないのです。
繰り返しになりますが、ペイグレードに応じた態度がプロフェッショナルには求められるのですが、お給料はいただきたい。
必要なのは、まず個別最適化です。あなたの仕事を減らしましょう。
余裕が生まれたら「この仕様は修正した方が」とか「週末にバッチあてるなら前の週末に復旧訓練をしましょう」とか言い出せば良いのです。
まあ、次にみずほ銀行が日曜に新規バッチを当てるときに、その2週間前の日曜に頭取を含んだS懸念の緊急対策本部を立てた訓練をするかっていうと、しないんじゃないかな。
つまり、そういうことです。
『ハクスラモンスターズ』とは企業制作と個人制作の悪いとこ取りを目指しているとしか思えないゲームである。
ジャンルは放置RPG。アプリを開いていなくても時間経過でダンジョンを潜ってくれるという優秀なシステムで、私は毎日のように画面に張り付いてダンジョンへの出撃を指示している。
そう、このゲームは放置RPGでありながら手動周回が求められる。なぜなのかといえば、課金機能に『手動周回時のみ周回時間短縮』という神アイテムがあるからだ。この機能が存在している以上、効率を求めるならば手動周回以外の選択はない。さらにいえば、それに加えてもう1つの理由がある。
手動周回と自動周回ではアイテムの取得効率・勝率に著しい乖離が生ずる。
手動で戦闘をすると100回やって100回勝てる。あるいは101回目で負けてしまう事はあるのだろうが、それは余程の低乱数を引いた時くらいで基本的には全戦全勝の状態。このステータスで自動周回を行うと平気な顔して勝率80%という表示をドヤ顔で掲載してくる。
低乱数を引けば負ける、それは間違いない。しかし自動周回で低乱数を引いてしまうとこうなってしまう。作者は『自動周回と手動周回にロジックの違いはありません』などと宣っているが、あり得ない。
確かに戦闘の計算式に変更は無いのだろう、しかし明らかに乱数の偏りがある。逆に上振れが発生すれば本来勝率の低いパーティが連勝できる可能性もあるのだろうけれど、そんな弱小パーティで100回も自動周回させる事なんてあり得ないのだから無いも同然。
こうしてプレイヤー達は今日も手動ボタンを押し続け、隙間時間に出来る事が売りな筈のゲームでそこらのソシャゲと変わらない謎の拘束時間が生じていく。
100歩譲って『手動周回のみ周回時間短縮』が無くなるならそれでも自動周回を行うだろう。低乱数ですらものともしない構築で挑めば乱数の偏りは関係無い。
しかしこの機能は課金であるが故に仕様変更に二の足を踏んでいるらしい。少なくとも買い切りである以上、弱体化や撤廃は許されない。ならば強化するしかないのだけど、周回速度が増加すれば単純にゲームとしてのコンテンツ消費速度が早くなってしまう。最終的にはアプデの感覚も短くすることを求められるし、ユーザーを縛り付ける事ができなくなる……と、作者は考えているだろう。
しかし現状、ハクスラモンスターズは虚無を入手する為のゲームと化している。100回周回して入手アイテム0なんて当たり前(ノーマル装備は考慮外)。有りえないレベルで全てが渋く、そして周回間隔が遅い。自動周回ポチッと押して虚無になるだけならまだいいのだけど、手動周回してる人はどんなメンタルをしているのだろうか。
通常『ハクスラ』と言えばアイテムの強い弱いはさておいて、入手量に関してはこのゲームとは次元が違う。システムにもよるが、装備に一定のランダムオプションが付加されることにより、戦術によって求められるステータスが異なる分だけ抽選の確率を引き上げているのだろう。そちらはそちらでゴミ装備が大半な事がほとんどかも知れないが、少なくとも『無』を取得することは無い。
このゲームにはランダムオプションは無い。二つ名というシステムによるランダム性は存在するが、付与される数値は固定であるため組み合わさった場合の数値も含めて全てが固定されている。それが悪いというわけではない。むしろバランスを取る為には妥当な要素ではあるのだけど……数値が固定されている以上、AがBに勝るという絶対性を覆すことはあり得ない。SSを取ったら終わり。このゲームのコンテンツは理論上有限。故に虚無にならざるを得ないのだろう。
わかる。理屈はわかる。コンテンツの消費を防いで延命をしたいその気持ちはわかる。けれど、どこか優先度を間違っている。コンテンツの消費以前の虚無からの脱落者が溢れかえるのとどちらが良いのか。……たぶん、虚無を切り抜けたヘビー層を飼い殺しにするのが一番コスパがいいんだろうね。
この辺の仕様、あらゆる部分がマネタイズに絡んでいることは容易に推察できる。開発者のtwitterも毎日のように「UIについて学べる本買った!」「わかりやすい!」と勉強熱心であるし、理論に熟知した上で最適な搾取法を知っているのだろう。
しかし、UIについてはほんとどうにかならないのか??本当に勉強してるのか?本当にわかりやすいのか?
ツッコミどころは山ほどあるけれど地味に今気になっているのはモンスターの昇格。モンスターにはランクが有り、ランクごどにレベル上限がある。上限解放するにはゲーム内マネー(またはそれと互換性をもつ課金石)が必要だ。
そして条件を満たし昇格ボタンを押すと、昇格したモンスターの画像がびよよーんと伸び縮みする演出が入り「あっ、なんか強くなったな」と思わせてくれるのだけど……グラフィックは変わらない。
いや、新しいモンスターが加入した時ならまだわかる。けれど昇格は既存のモンスターをグレードアップする行為でありイラストなんて最初から知ってる。というかこれってソシャゲで凸するとイラストが変わったりなんかセリフ言い出す時のテンプレートだよね?これ付けるならAAランクでのイラスト違いを用意したら?そんな資金はないだろうけど。
ゲームの仕組み上、昇格は割と何度も行い得るアクションだ。1回ならちょっとびよよーんとするのを眺めて「ほえー」で済むのだろうが、たとえばDランクのモンスターを育てるならC→B→A→AAと何度も何度も同じモンスターのびよよーんを眺めることになる。
もう一度聞くけどほんとに勉強してる?上辺だけ見て「おっパクろ」とか考えてない?
プログラミングスクールは良くないって話が多いので、人それぞれだよねっていうのと、何もやらないよりは何かしらあるんじゃないかなっていうお話です。
フィクションのつもりで聞いてください。
私は地方で育ち、地元の女子中・女子高・駅弁大学を卒業し、地元のとあるテーマパークに就職しました。
比較的なんとなく生きてきたので、仕事って大変そうだからせめて面白そうな職場を選ぼう、くらいの気持ちでしたがすぐに辞めたくなりました。
toC接客、屋外での勤務、立ちっぱなし、友達と休みが合わない、覚える事が多い、職場が僻地、ダンサーチームの揉め事の仲裁、契約社員組みからの嫉妬、大学生組の惚れた腫れた、田舎特有の異様なゲストの図々しさ・馴れ馴れしさ、どれも好きじゃないやつでした。
まあゲストにイラつく事があっても、それはしょうがないと思ってます。仕事だから。
でもスタッフも、とにかく感情で生きてる人間が多すぎます。私よりずっと大人なのに。
華やかな表舞台とは裏腹に仕事はそこそこハードで、給料の水準も高いとは言えない環境のため、人の出入りが激しく、トラブルを起こしたり、恨み辛みを吐きながら辞めて行く人が多いのもメンタルにきました。
最初に威勢のいい人ほどすぐ腹を立てて辞めていくので、個人的に警戒して距離をとるようにしていました。
理想と現実のギャップが大きいからなのか、彼らの自己評価が高いからなのかわかりませんが、もしかしたら私のように、ドライに仕事はしんどいものだと思ってる方が、色々受け入れられるのかもしれません。
そんなこんなで2年ほど勤めましたが、最後まで職場にも業務にも慣れる事もなく、花形着ぐるみのポジションが空いた事によるダンサーチームの派閥争いの激化に伴って私の神経も擦り切れ、半ば衝動的に仕事を辞めてしまったのでした。
実家に住んでいたので、しばらくはニートしながら次に何をするか考える予定でした。
しかしそんな折、東京に住んでいる祖母が怪我をしてしまい、介護を要する状態になってしまいました。
私は昔から祖母が大好きだったので、喜んで同居と介護の役目を担うことにしました。
祖母とは小学校低学年くらいまで同居していた期間があり、その頃から私の唯一の理解者でした。
私が真面目で、冷めていて、興味を惹かれると他のことが目に入らなくなって、
自分のペースで物事を進めたくて、少し融通が効かずに周りの子達と馴染めなかった頃、
その事に両親はお手上げで「みんなと同じように」「普通に」「お願いだから」としか言わなかった頃、
「あなたはちょっとだけ人より心が大人なんだよ。それでいいんだよ。賢くて真面目なあなたが好きだよ。
でももし疲れたら、周りの子たちと同じくらいには、いい加減で、だらけて、失敗してもいいんだよ」
と、声をかけ、私が「もう大丈夫」と言うまで何十分でも抱っこしてくれた祖母。
祖母のその言葉と、帰ったら祖母が家にいるという安心感で、私は少しずつクラスメイト達と打ち解け、誰かに心を許したり、自分が失敗することも他の人が失敗することも許せるようになっていったのでした。
東京には別の親戚もいたのですが、ペーパードライバーで頻繁に祖母を病院に連れて行くのが難しかったり、仕事の都合だったりで他に候補者もいなかったので、私の立候補には関係者みな渡りに船という感じでした。
母に「おばあちゃんが好きってだけではできないよ。よくわかってないんじゃない?」とも言われたけど、私は祖母に関する事ならちゃんと理解したかったし、自分の想像が及んでいない事があるなら、それも知りたかった。
介護はまあ大変だったのですが、意外と祖母が元気で、怪我の経過も芳しく、家の中の生活においては一人で出来る事が多かったのもあり、私は徐々に暇になっていったのでした。
美術館や博物館が昔から好きで、最初は狂ったように行っていたのですが、お金もそんなにないし、周りに友達もいないので、やや時間を持て余すようになってしまいました。
そこで、一念発起して、噂に名高いエンジニアとやらになろうと思いたち、プログラミングスクールを探し始めました。
テーマパークで働いていた私からしたら、エアコンの効いた部屋で座って作業できて、toC接客をしなくてよくて、給料が高い(らしい)なんて夢の職業だと思っていたのです。
東京での普段は淡白ながら、楽しみ方の選択肢がとても多い生活も肌に合っていて、祖母の介護を終えても田舎には帰りたくなかったので、こっちで就職して帰らなくていい理由を作りたかった、というのもありました。
色々調べて、とあるオンラインがメインのプログラミングスクールに決めました。
祖母の家が都内とはいえ西の方で、交通費も出ないのに電車で都心に通うのは厳しかったのと、祖母の用事が最優先なので時間の都合がつけやすいようにと、グループでやる課題とかがきっと向いてないだろうなと思ったからです。
(今になって思えば、gitの実践的な使い方に慣れられるし、どうせ働き始めたらチームでやるんだから、グループ作業は経験しておくのをおすすめしたい)
ニート期間が短かかったので貯金があまり減っておらずなんとか料金を捻出できたのですが、貯金はなくなりました。
プログラミングスクールでは、まず卒業後どういう職種や働き方を希望するかを聞かれ、それにはどんなスキルが必要か説明を受けながらカリキュラムを決めていきました。
授業は、エンジニア経験のある人とskypeを使ってマンツーマンで、テキストを進めたり、課題をチェックしてもらったり、デバッグを手伝ってもらったり、わからないところを教えてもらったり、実際の開発現場の話を聞いたりしました。
私はなにせ女子校育ちだし、喪女だしで、女性の先生が良かったのですが、女性の先生は数が少ない上にみなさん大変な人気でなかなか予約が入れられませんでした。
平日の日中に授業を受けられるので、働きながらの人よりはずいぶん有利な立場にはあったはずなのですが、できれば同じ先生にずっと見てもらいたいと考えると、なかなか厳しい状況でした。
ですが、一人だけ比較的予定が空いている先生がいました。そう、後の彼女である。
彼女の予約が空いている理由は1回授業を受けたらすぐにわかりました。
早口だし、自分の言いたい事は最後まで言わないと気が済まないし、アイスブレイク下手くそだし、全然笑わないし、癖なのか10分に1回メガネを拭いてるし、説明が長いし、1回説明した事は完璧に理解するはずだと思ってるし、なんか顔が怒ってるし、なんか厳しくて答えをなかなか教えてくれないし。
顔は結構美人なのに、性格きつい人だなあというのが無遠慮な私がもった第一印象でした。
まあでも予約を続けてとれる女性の先生は他にいないし、私も生来かなり真面目な性分だし、授業が終わった時のやけに油断してホッとしてる顔がなんかちょっと可愛いし、実力をつけるには問題ないだろうという事で継続して予約を入れる事にしました。
しばらく授業を受ける事で、だんだんと彼女の態度は軟化していきました。
プログラムも楽しかったし、彼女については保護猫をだんだんと慣らしていくような面白さもありました。
授業は丁寧だし、彼女はフレームワークの細かい内部の挙動や、メソッドのオプションなんかにもかなり詳しく、それらの点では優秀な先生だったので、私の心からはいつしか懸念も不満も消えていました。
そんなある日、パソコンを買い換えたいと思っている話をしたら、意外にも彼女が付き合ってくれる事になりました。
(当時、なんか可愛いという理由で買った、やたらキーピッチのあるVAIOのノートパソコンで作業していたのですが、色々目が開いてきてMacに乗り換える事にしました)
買い物当日、MacとWindowsの違いから丁寧に教えてくれた彼女の私服はダサかったのですが、お礼も兼ねて新宿で居酒屋に行く事になりました。
主に、Windowsで使ってたツール類のMacでの代替品を教えてもらうつもりだったのですが、いつのまにか梅酒2杯で饒舌になった彼女の身の上話を色々と聞かせてもらっていました。
いい提案ができるように新しい技術を家でもたくさん勉強したこと、
いいシステムを作る為にプロジェクトの良くない点はきちんと指摘したこと、
それらを煙たがられて注意を受けたこと、
「女のくせに」って言われたこと、
自分が席を外したタイミングで夕会が行われるようになったこと、
「プロパー+αの人だけの飲み会」にチームの中で自分だけ呼ばれてなかったこと、
社内で待機している時、営業に「女でこんなに売れないのお前だけ」って言われたこと、
新卒もどんどん現場に出ていくのに自分は次のプロジェクトが決まらなかったこと、
「とにかく人が足りないから大歓迎です」って言われた案件でもチームの中で1番最初に退場になったこと、
業界が向いてないのは身に染みてわかったけどプログラミングが好きで今の職についたこと、
授業のリピート率の低さに会社からいつも小言をもらっていること、
SESが辛くて辞めたのに、多くの人が卒業後SESに行くプログラミングスクールの先生をしているということ、
自分のやってる事が人の為になっているのか信じきれていないこと、
SES以外の社内SEとかで転職を考えたけどどこにも受からないこと、
昔から人付き合いが苦手なこと、
親戚のおじさんに一人すごく嫌な人がいること、
成績は悪いが愛嬌のある弟ばかり親が可愛がること、
「いや、まだそんな重い話を聞く関係じゃないですよw」って途中まではいつ言おうかタイミングを見計ってたけど、とうとう言えずに最後まで聞いてしまった。
気がついたら私は泣いていました。それは気持ちがわかってしまったから。
小学2年の春、誰かに一緒に帰ろうと誘われるまで教室で本を開いて待ち、みんな連れ立って帰ってしまいひとりぼっちになった後、仕方なく開いていた窓を閉め、カーテンを束ねていた、その風景を思い出してしまったから。
ああこの人は祖母に出会わなかった私なんだな、と、どうしようもなく理解してしまったから。
私が優秀だと彼女の評価もあがるかもしれないと思って余計にがんばり、無事卒業を迎える事になりました。
プログラミングスクールの卒業生の主な就職先はSESです。(今はわからないけど)
SESについて彼女に色々聞いていたので、客先企業に常駐して、多重下請け上等で、使い捨てで、人売りと呼ばれていて、残業が多くて、無理なスケジュールを押し付けられて、仕様変更が頻発して、現場では肩身が狭くて、theITドカタっていうのは知っていました。(今はわからないけど)
でも私はなんでも知りたかった。彼女のことをもっと知る為に、SESについて身を以て知るつもりでした。
同じ時期に卒業を迎えた人の中には、断固SESを拒否する人も何人かいました。
下請けじゃなくて上流工程ができて経営が安定していてまったり働ける社内SEか、自由で先進的でフットワークが軽くて自社サービスのあるベンチャーがいいのだと。
いやいやいやと、社内SEがそんなにいいものなら、学業が優秀だった人か、SESで優秀だった人から順番に行くでしょうと、
ベンチャーがそんなにいいところなら、すごく優秀な人たちの少数精鋭なんでしょうと。
課題でサンプルのプログラムをいくつか作っただけの私たちがどうしてそんなとこにいけるでしょうかと。
修行のつもりでありがたく、いろんな現場や業界で実戦経験積めよと、1行でも多く実務でコード書けよと、色んなプロジェクトのドキュメントとかプロジェクトマネジメント見て勉強しろよと、SESでもないと逆にそんな機会も無いぞと、そんなことを思っていました。
私の就職先は、2回面接をしただけで、スクール推薦のSESの会社にあっさり決まりました。
祖母は、私が平日フルタイムで働いても差し支えない程度まで回復していました。
彼女とは頻繁に連絡をとったり、遊びにいく友人の間柄になりました。
しかし、実際SESで働いてみると、覚悟していたような環境とは少し違いました。
基本的に自社のリーダーとしか話さない(プロパーが直接メンバーに指示を出すのはダメらしい)し、スケジュール変更や仕様変更もちょこちょこあるけど、その分の残業代もちゃんと出るし、なんだか全体的にいいところでした。(テーマパークと比較するとなおのこと)
彼女が最初に働いた企業が、現場が、時代が、運が、悪かったのだとわかりました。
でも、「あなたのおかげでエンジニアになれて、人生が変わって、嬉しいよ」って、彼女に伝える事はできました。
数年はそのまま穏やかに、繁忙期には激しく、時が流れていきました。
祖母の怪我は完治し、私はそこそこのスキルを身に付け、転職と引越しを検討し初めていた頃でした。
そんなある日彼女から東京を離れるつもりだという連絡が入りました。
彼女は私の卒業後もスクールで先生をしていたのですが、それがあまりうまくいっておらず、だんだんと稼働が下がり、収入も下がり、公共料金や生活費も滞納しかかっているような状況だったそうです。
そして、そのことが親御さんに伝わり、帰ってくるように言われたそうです。
私は彼女の唯一の理解者だったので、私が彼女を幸せにしようと思いました。
彼女に引越し先でのルームシェアと、当面の生活費の負担と、その代わり家事をしてもらう事を提案しました。
しかし問題はお金です。彼女はお金がぜーんぜんないし、私も引越し料金(2人分)とルームシェアできる物件(2LDK以上)の敷金礼金・初期費用を払うのは苦しい状況でした。(実家とかに頼ると、生活できないならこっちに戻ってこいと言われてしまう)
折り悪くコロナの影響が、転職市場や私の現職の稼働に影を落とし始め、「やっぱり私実家に帰るよ」などと彼女が言い出して、これはいよいよヤバイなと思い始めた頃、
事態は急転して、なんとお金問題と転職問題が唐突に片付きます。
みなさまPayCareerさんをご存知でしょうか。企業と面談するごとに3万円もらえる転職サイトです。
そこで数件のスカウトが届き、多額の臨時収入を得られ、トントンと内定を複数頂く事ができました。
みなさま是非PayCareerをお使いください。求職者に寄り添うお心をお持ちの採用担当者のみなさまも是非PayCareerをお使いください。
その後物件探しにも散々苦労するのですがなんとか新居が決まり、私たちはルームシェアを始めることができました。
ある土曜日の晩、ブラックスワンという映画がどんな内容かをよく知らずに、なんともなしに見ていた私と彼女の関係は、日曜日の未明に友人から恋人に変わりました。
私は女子校だったので、女性同士でお付き合いしている人たちを長く近くで見ていた事、彼女は過去の経験から男性に恐怖心を抱いてしまうこと、ここ数年似たもの同士の2人がお互いを助けあって生きてきた事、要因はいくつもあったと思います。
多分お互い、本当のところは男性の事が苦手ないしよくわかっていないだけで、もしかしたら男性と付き合おうと思えば付き合えるのかもしれませんが、この上なく安心できて、優しさを掛け値なしに注ぎあえるパートナーを得られた時、それは問題になりませんでした。
人の寝言って今まで聞く機会がなかったのですが、彼女はすごいはっきりと寝言で喋るので驚いています。
私は転職する時に、自社サービスを持っていて、担当者の裁量で業務委託の採用や発注ができる企業を探していました。
基本的に、作品の評論も作品そのものも「納得させること」「程よく目新しいこと」が大事なのであって、正解だ不正解だという議論は往々にして納得したかどうかなんです。
根本的に間違ってるのよ。
という前提がさ
わかった風に言う人多いけど
までなら部分的に正しいんだけども、じゃあ【言語を獲得したから正確に物事を伝えられてるか?】って言えば、Noですよ。
めちゃくちゃ話し込まないと相手が何がいいたいのかわかんないことなんてどんだけあるのよ?読解力の問題でなく伝え方の問題で
アドバイス罪って言葉を発明した人がいるけど、アレって助言しようという親切心や興味を持つことが悪いんじゃないんですよ。
【的確で参考になる助言】なんてものが世の中にも自分へも少ないのに、助言したがる事自体の頭の悪さといいますか、自分の見えてなさといいますか…それらへの苦言でしょうね
頭が悪いという言い方が正確かはわからんが、わかんないことがある時にググらない人や、わからない概念があるとメンツを潰されたよな顔で聞いてくる人がどれだけ多いか…
わかんないことをググれる人ってちょっとした才能だし、
子どものうちは大多数ができてることがおとなになった途端できなくなる人が爆発的に増える。
助言はしたがるんですよみんな。
でも、調べたり話を聞いて活かすことはできないんです
面白いよね
ちなみにこれ嫌味でもなんでもないです。
そういう人は多いです。
ジョージ「名前もわからない企業に就職しちゃダメってお父さんが言ってた!」
イット系企業「ジョージィのお父さんは賢いね、本当に賢い。僕は新進気鋭のイット系企業ペニーワイズ(株)、君はジョージィ、これでお互いわかっただろ?」
イット系企業「ハロワに行くだって?このオファーを見ないで行くのかい?」
イット系企業「その通り!スキルが無いんだろう?欲しいだろ?」
(躊躇するジョージ)
イット系企業「ジョージィ、ここで経験を積んで別の会社に行くことだってできるさ!プログラミングスクールにも行く必要は無いよ!」
イット系企業「その通りさ!日本で一番求められているIT系人材だよ!引く手数多ってやつさ!」
(手を伸ばすジョージ)
イット系企業「僕の会社に就職したら…一生IT土方だけどね!🤪」
ジョージ「いやぁぁぁぁぁぁ」
〜時が経った〜
薄給で家庭も持てず、元請けのめちゃくちゃな日程変更と仕様変更に悩まされ続けた。
Googleやマイクロソフトのソフトウェアが強いのは技術が高いのは確かだが、その差別要因になっているのは膨大なサーバーだ。
サーバーのハードウェアの規格をオープンにして価格競争にもちこんでいる。
なんで物量で勝負してるかは、高性能なパソコンと1人の天才によって覆されないようにする為だ。
アメリカが強くて欧州が弱いのは、物量を集めるだけの資金がない。
欧州が勝ててない理由はアメリカの法律だ。輸出関係をするとアメリカ法律の面倒くささは分かる。他国に介入するのだ。
GDPRなど欧州の法律が日本にも影響して面倒くささを感じてると思うが、欧州はそれをしないと対抗出来ないのを知っている。
中国もわかっている。
グレートファイヤーウォールを日本にいると馬鹿にするが、既存の貿易障壁がないとどうなるかはわかっていた。
GoogleやMicrosoftが世界中にオフィスを持ち、優秀な人を雇用してるのは、転覆されるような天才を内に取り込む為だが、アメリカだけにオフィスがあると、アメリカに移住したくない人を取り込めない。
もう一つ、世界中に中国系移民がいるということは、海外から得た優秀な知識を中国にもっていけるのと、サービスを世界中で使われるということだ。地政学的リスクばかり話されるが、それだけではない。
鉄道などもそうだが、人口が多いので国内需要を捌く必要があるので、仕方なくやっている面もあるかもしれないが、そのままグローバルに展開できる。アメリカが脅威に感じているのはその辺りだろう。
日本はだが、ソフトウェアは輸入に頼り切ってしまった。内製もそうだが国産出来ていない。
オープンソースをなぜアメリカ政府が放置してるのか?普通に考えれば他国の利益になることは禁止する筈だ。使われた所で脅威にならないと判断してるということだ。
Googleからも沢山公開されるが、公開しても脅威にならないか、自社の利益になるからである。
日本がグローバルに展開出来ないのは、オフィスをアメリカ以外に持てない、どこに置いていいかわからないといった、情報の少なさが1つの要因だ。
日本メディアは海外に向かって日本の技術を発信しない。国内のアクセス数で稼ぐ広告モデルしかない。
Googleが定期的にネットで盛り上がる話題を提供し、Amazonのタイムセールを取り上げ、Appleの噂話ばかり取り上げてしまっている。
オフィスにいながら英語で流れてくる記事を翻訳するだけだったりもする。
アフィリエイトや広告でお金をばら撒かれるのに慣れてしまっている。
人的リソースが国内で枯渇気味なのに、YouTuberやアフィリエイターを目指したり、UberEatsで配達したりしている。個人の自由ではあるのだが、国力は下がって行く。
エンジニア経験20年以上にして、今初めてプログラミングしかしないプログラマーに開発を依頼してる。
自分が悪いのだが、設計書の条件文のコピペミスによる仕様バグをそのまま実装してきてビックリ
「ごめん💦仕様バグだった」
と、伝えたら
「オカシイと思ってたんですよね」
だって…— えび@プログラマー (@ebiebi_pg) January 22, 2021
自分が悪いから何も言えないけど、
「僕達(プログラマー)は設計書の通りにしか作りません」
「設計書の記述ミスであっても仕様変更依頼下さい」
言われましたw
開発チームは同じ部署の人間なんで、もうちょっとフラットに行きたい💨— えび@プログラマー (@ebiebi_pg) January 22, 2021
結構思い切ったねー。まあそれはともかくまだ8か月でしょ?これからだよ。
実際に商用で運用して障害が発生した時にシステムがどう動けばユーザは次のアクションができるか、致命的なエラーにならないためにはどういう順序でどういう情報を残すかとか、改修案件をチョロで対応するにはどういう設計にすべきかとか、作った後でも簡単に手を入れられる部分と商用稼働してからだと手を入れずらい部分の判別だったり、リリースした後に実際に使われる中でのフィードバックから学ぶことって結構あると思うよ。
あと、ERPパッケージを触ってみるのがおススメ。ソースを見るというよりは各種マスタの設定をして触ってみる。多種多様な顧客のニーズに対してプログラム改修なしにマスタテーブルの設定値変更で対応出来るよう工夫して作られているので、設計の参考になると思う。
見積で顧客に突っ込まれるの面倒くさいな、後になって仕様変更対応するの面倒くさいな、障害報告面倒くさいな...etcの面倒くさいを省くためにどうすれば良いかの改善点を日々考えていくことがエンジニアとしてのスキルの向上につながるんじゃないかな。