  |
はてなキーワード: メンテナンスとは
俺がティーンエイジャーになって間もない頃の話だ。
「バイトでもしようと思ってるの」
母は俺たち家族にそう告げた。
「それはまた……どうして？ 別に家計が苦しいわけではないだろう」
「有り体に言って、やることがないの。家事はほとんど機械がやってくれるんだもの。実質的に私がやっているのは、その補助と言ってもいいくらい」
母は専業主婦というやつで、少し前までは大忙しだった。
しかし、現代科学の賜物は母を楽にしていくと同時に、仕事に対するモチベーションも奪っていった。
そして、俺たち兄弟は成長していくと手がかからなくなり、自分で出来る範囲のことはやるようになった。
母が今までやっていたことは徐々に減っていき、自分だけの時間が大きくできたわけだ。
「子供が自立していくことは親として喜ぶべきなんでしょうけど、同時にメリハリもなくなっていくのよねえ」
しかし、そうして出来た時間は中身がなく、ポッカリと空いている状態だった。
「あなたは仕事で夜に帰ってくる。子供達は学校から帰ってきたら友達と外へ遊びに行く。キトゥンは躾ができてる上、子供達が世話するからエサをあげるくらいしかやることがない。自分の身体のメンテナンスだけで、残り時間は潰せないの」
「うーん、なるほど……だけどその空いた時間を仕事に費やさなくてもいいんじゃないか。自分だけの時間なんだから、趣味だとか、もっと有意義なことに使えば……」
「私に必要な“有意義”が、そういうものじゃないってことくらい分かってるでしょ？」
母は無趣味な人間で、やりたいこととやるべきことを直結させた人生を送ってきた。
それで充実していたし、不満もなかった。
以前、センセイがそう言っていたのを思い出す。
だけど、こうも言っていた。
『難点は、常にやるべきこと、やりたいことを追い求める人生になりやすいってところだな。やるべきことがなくなれば、やりたいこともなくなるからね』
まさに母はその体現者だったのだろう。
結局、反対する理由もなかったので、俺たちは母のやりたいようにさせた。
「うーん……丁度いい条件のがないなあ」
入り口近くに貼られた求人紙に目を通していくが、都合のいいものは中々見つからない。
「おや、マスダさん。珍しいところで出会いましたね」
声をかけてきたのはセンセイだった。
「そんなところです。とは言っても、ここに貼られているもので目ぼしいものはなさそうですね。良い条件なのは、既に持っていかれたのでしょう」
「そうなんですか……じゃあ、他のところで探した方がよさそうですね」
「後は相談窓口ですね。ここに貼られているもの以外を見繕ってくれることがあるので。それに期待しようかと」
「へえー、じゃあ私も行ってみようかしら」
母はセンセイと共に相談窓口へ向かった。
とりあえず説明しやすくするために、平成の次の元号を毎回毎回「平成の次の元号」と言ってしまうと面倒なため、「応仁」としてみます。実際の元号は「応仁」にはならないと思いますが、便利なので「平成の次は応仁」だととりあえず思い込んでもらいたいです。
さて、あなたはプログラマあるいはSEになりました。まあ、とにかくソフトウェアの修正をしなければいけない立場になりました。
今回修正するソフトウェアは、他の企業が平成8年に作成したもので、本来は平成15年でメンテナンスを終了するという契約だったようでした。なのでメンテナンスも特にされてはいません。顧客が「使えるのだからいいだろう」ということで長年使い続けてきたものです。しかし、この度改元にともなって、あなたの会社に改元の発注が舞い込みました。
「なんで5月に改元なのに1月に発注するんだ……遅すぎるぞ」とあなたは呆れていますが、仕事は仕事です。諦めて作業にとりかかりました。
あなたはまず、このソフトウェアがどういうものなのかを確認します。取引先が取引先に売るためのソフトウェアのようです。比較的大きなソフトウェアなのでまずどのようなものなのかを確認するのが大変でしたが、あなたはなんとかソフトウェアの全容を理解し始めました。
ここで、あなたは直感的に「平成」となっている部分を「応仁」に変えてみます。
すると今年は平成31年のはずなのに応仁31年となってしまいます。横着をして計算しないとこういうことになってしまうので、まずは内部では平成31年の5/1以降なら応仁元年ということにします。応仁1年ではダメと言われてしまったので、ちゃんと1のときは「元年」に変えます。「元年」のときだけレイアウトが崩れてしまいましたが「平成元年も崩れますよね？」という交渉を行って、なんとか鉾をおさめてもらいました。
さて変更したので、ちゃんと動作がうまくいっているかテストを行います。自動で出力される書類の日付は「応仁元年5月2日 発行」となっています。
すばらしくうまくいっています。テストをしている人（もちろんあなたです！）は心をよくしてそのままテストを続けていました。そうすると「H31 05/02」というものを発見しました。
そうでした。アルファベットの方も変更しなければいけませんでした。先程と同じように平成31年の5/1以降はHではなくOというふうに書き直します。なあんだ。簡単じゃあないか。誰だ難しいと言ったのは。
「平成30年の3年後は応仁3年」という計算もすばらしくうまくいっています。
あなたはこれに気をよくして取引先に納品しました。納品にあたってメンテナンス期間を設けて深夜に出勤し、問題がないかチェックをしました。そうして更新されたソフトウェアが取引先で使われ始めました。
取引先も「いいじゃないか」と言ってそのまま応仁元年5月1日を迎えました。
あなたは驚いてクレームの箇所を確認しました。すると㍻31年5月1日となっている箇所を発見しました。なんとここだけ使われている文字が違ったのです。「㍻」と「平成」は全く違う文字です。あなたは新しく追加された「細い応仁」の文字を使わなければいけません。この前と同じように、ネットから新しく発表された「細い応仁」をコピペして、日付計算だけして終わろうとします。
あなたは「やらかしてしまった」と冷や汗をかいていますが、これでなんとかなるだろうと楽観していました。
するとエラーが出ました！
数時間かかけて調べるとどうやら新しい「細い応仁」は、Unicodeというものを使っていて、Shift JISというものを使っているこのシステムでは使えない文字のようでした。これに驚いたあなたは「Unicodeというのを使わないといけません！」と上司と相談し、取引先と交渉することになりました。結果は「それはダメ。なんとかしてくれ。なお追加予算は出せない」ということでした。
Unicodeを使えるようになってしまうと、文字化けが起こったり不正な文字（入力されるとエラーになる文字）をバンバン入力できるようになります。そうするとまた全部の箇所をひとつひとつ確認することになります。予算もかかるし時間もかかります。取引先が、取引先の取引先とも連携できなくなる可能性すらありました。なので却下されました。でも「細い応仁」でないとダメだということです。
しかたないのであなたはそこの部分のときだけ文字ではなく「細い応仁」の画像を出力するようにしました。これはとても大変な作業でした。何しろ昔のソフトウェアですから、昔のコンピュータの上でも動くように作らなければいけなかったのです。
そのあと㍻と出力のされていた部分を一通りテストしていきました。しかしまだ「㍻」となっている部分がありました。あなたはため息をつきながらそこの部分も修正します。
さあこれでとうとう終わった！あなたは晴れやかな気分で顧客に頭を下げて再度納品しました。もちろん、深夜作業も行いました。
半年後、応仁元年12月5日のことです。あなたは再度クレームを受けました。「平成31年がない！」というのです。
あなたはそんなバカなという顔をしてその箇所を確認します。そこはユーザーに生年月日を選択させる箇所でした。
「平成29年」「平成30年」「応仁元年」「応仁2年」というように元号が並んでいる箇所があり、ユーザーはこの中から生年月日を選ぶようになっています。ここは「平成31年/応仁元年」と書かなければいけない箇所でした。
あなたは「応仁元年」となっていた文字の場所を「平成31年/応仁元年」と書き換えました。するとレイアウトが崩れました。取引先に確認すると「レイアウトが崩れるのはダメ」ということでした。「レイアウト崩れは許容しないとこれは無理」という交渉を行うことになりました。数日間の交渉の結果、なんとか折れてもらうことになりました。
ここに至って、あなたは「改元対応すらまともにできない人」という烙印を押されていて、味方がおらず、だんだんイライラするようになります。
ただその後は特に問題がないようで、あなたは胸をなでおろしました。
応仁2年3月17日。あなたが別のプロジェクトをやっていると「決算の書類が平成31年度じゃなくて応仁元年度になっている！」と言われました。そうです。応仁は5/1から始まったので、応仁2年3月末までは平成31年度なのですね。あなたは「どうでもいいだろ」と一瞬思いましたが、かなり重要な問題だということで、仕方なく修正しました。いままでの経験が生きたのですぐに修正自体は終わりましたが、顧客の場所まで深夜に行ってメンテナンスをしないといけないのだけが大変でした。
あなたはソフトウェアを作った人に「最初から改元のことを考えて作っておけよ」というふうに呪います。しかしこのソフトウェアが作られたのは1996年のことでした。1996年というと平成8年です。そして再掲しますが、平成15年までという契約だったようです。だから改元のことなど考えなかったようです。もしかしたら予算の都合かもしれません。当時はそれよりも2000年問題の方が重要でした。
また、1996年というとインターネットが出始めたばかりのころです。2chもまだ存在していません。パソコンの能力も今の1万分の1だと思ってもらってかまいません。そういう時期に作られたものをメンテナンスするのは大変です。いろいろなものが今と違うし、当時の書類が残っていないこともあります。そもそも今の開発機で動かない可能性もあります。
あなたは今の話を聞いて「改元に伴ってこの他にやるべきことは絶対にない」と言い切れるでしょうか。たぶん、そんなことはないはずです。だって実際の元号は応仁ではないし。
さて、怖い話は終わりです。
改元に伴う修正というのは、これらを事前に調査してすべて変更し確認するということです。「あ、そうでしたッ！」とならないように、プログラマはこれらを事前にやり、確認します。簡単な仕事だと思いますか？だとするとあなたは改元に関するソフトウェアの修正で大儲けすることができます。自信をもってプログラマになってください。
昔からあるソフトウェアは大変ですが、もちろん大変でない企業もあります。そもそも西暦しか使っていない企業がそうです。あらかじめ改元のことを考えていた企業もあります。とくに最近作られたソフトウェアは、そういうことを見越して作られているので変更は比較的容易です。そういう人は「大変だ！」とは騒ぎません。「大変そうだなあ」と静観しています。
ぼくも静観する組なので、実際の大変さについてはよくわかりません。
見た目では確かに「平成」を「応仁」に変えるだけです。それだけなのに騒いでいる人を見ると騒いでいる人がバカっぽく見えます。確かに騒ぎすぎてる人もいて、辟易とする気持ちはわかりますが。
でも、見た目を変えるのは簡単そうに見えますが違います。「異性にモテないなら顔を美形にしろ」と言われてすぐできるものではないのと同じことです。見た目を変えるというのは、見た目を変えるだけでは済まないことも多いのです。
ぼくも静観する組なので、実際の大変さについてはよくわかりません。
でも「大変そうだな」ということはわかってほしいなと思います。
ぼくも静観する組なので、実際の大変さについてはよくわかりませんが。
こんにちは！今日は、年の瀬なので、私が色んな会社のSlackを見てきた中で、こういう傾向があるとその組織はヤバいぞって特徴5点を発表するぞ！
タイトルにある通り、入社して、Slack登録して、その後1時間ぐらいですぐわかることだ！（プライベートチャンネルやDMが多い、ってのは分からないから載ってないぞ！）
え？Slackと組織に関係性がない？まさか〜。『コンウェイの法則』で検索だ！
以上だ！
ちなみに私はこのうち 3 つ以上に当てはまる組織は即抜けることにしているぞ！
嫌な仕事をしている。
本当は嫌じゃない仕事をしていたのだけれど、会社の都合で嫌な仕事をやるようになってしまった。
前はお店の一番奥で、機械と二人でやってた。コツコツやっていく仕事で、機械の調子が悪かったらメンテナンスして、忙しいときは一緒に残業して。気難しい子だったけど、打ち解けてしまえば苦ではなかった。
でも二ヶ月くらい前、5人くらい一気に人が辞めた。このままじゃ仕事に支障が出るっていうんで、社長は業務体系を変えた。人を雇えば済む話なのにね。
その結果、私は受付になった。
お店の玄関から一番近い席になって、やって来るお客さんとお話したり、別支店の社員さんに電話しなくちゃいけない。私は人見知りで口下手で、そういうことが苦手だから、極力人と話さなくて済む仕事を選んで、履歴書送ったのに。話が違うと思いつつも、下っ端の私に何かを意見できるチカラなんて無い。
本当に本当に嫌だったけど、周りの先輩たちが優しく教えてくれるって言うから、一旦仕事を覚えてみてダメだったらその時考えよう。そう思って、新しい仕事を教えてもらった。
がんばった。
そんな中やってきた、繁忙期。
私は私なりにがんばった。
でも、もう誰も優しくない。
でも声をかけて睨まれたりしたら、ポンコツな私はもっとどうすればいいか分からなくなる。
って言われても、どうしようもない。
そりゃ10年以上やってる◯◯さんと、始めて二ヵ月の私じゃ比べものにならないだろうなあ、って思う。それくらいしかできない。
繁忙期だから自分の仕事でいっぱいいっぱいになって、私に気をかける余裕が無いのは分かる。
でも私はもっと余裕がない。
なんだったら、もう優しくしてくれなくてもいい。
ただ(お前なんか、居なきゃ良かったのに)って間接的に伝えられると、酷く心が痛むからできればやめてほしい。
やりたくない仕事
優しくない先輩
上がらない給与
もう何のためにがんばってるのか
分からない。
苦楽を共にしたあの機械は、今年いっぱいで廃棄されるらしい。
仕事の失敗が怖くて夜も眠れない。
ここ一ヵ月はずっと薬を飲んで、やっと眠れる。
そんな仕事辞めちゃえば？って思うでしょ。
私もそう思う。
でも転職する元気も無い。
でもこの苦痛は耐えられないし。
惰性みたいに今日も生きている。
事情はこんな感じ。
今日以降MeCabの辞書をmecab-ipadic-NEologd辞書に切り替える。昨日までのはNAIST辞書だった。メリットは週2回新語が追加されるので、2011年に更新が止まったNAIST辞書に比べて時事ネタに強い。デメリットは固有名詞じゃないものまで固有名詞に分類しようとすること。一長一短あるけれど、メンテナンスが止まった辞書を使い続けるよりは良さそうなので変える。はてなキーワードから新語を探しているそうなので、はてなキーワードを整備すれば精度が上がるかもしれない。
はてなが増田のキーワードページ https://anond.hatelabo.jp/keyword/ を改善してくれればこんなことしないのにと思う。いま久しぶりにキーワードページ見たら表示される単語の数が減ってる気がする。改善しようと手を付け始めたのだろうか?
一応予言しておくけど
2019/01/10前後で「還元は延期します（たとえばシステムトラブルや圧倒的人気のため）」あるいは「とりあえずこれだけ返します」と言って、ユーザーが憤慨している間にしれっと倒産する、と思う。
風説の流布とならないよう、以下の情報とともに各自で調査・判断してもらえれば幸いである。私の誤認識もあると思うのでそこも加味していただきたい。
自分で予言しておきながら「そんな企業倫理に反する結末はさすがにないだろう」とも思う。まぁ空論ゆえに適度に聞き流してもらいたい。
新たなAPK(Androidアプリをインストールするためのファイルのこと)では、セキュリティコードの無限リトライを許可しないようにしたそうだが、問題の核心はそこではない。
名義なしでもよい・3Dセキュアの実装がないなどチェックが皆無だというところが問題である。簡潔に表現すれば、このシステムは拙速の塊であった。
また、12/17に更新されたAPKのパーミッションを見ると、ユーザーからAndroid端末に固有なデバイスIDを得るという操作も行われていないように思う。
いままでは「誰もが無限にトライできていた」のが、「3回トライして無理だったとしても頑張った人だけさらに無限に3回ずつトライできるようになった」ということである。
つまり悪用するのが難しくなっただけで、大変ご愛顧いただいているみなさまは引き続きご悪用いただける。
ANDROID IDを使用している可能性は無きにしもあらずだが、こちらのIDはIDと銘打ってはいるものの再生産が非常に容易でありハッカー視点では無対策と等価である。
一定の知識（プログラマ歴1〜3年程度）のある者がAPKからPayPayのもつAPI(この場合JSONデータを得るためのURLのこと)の解析を行えば、
バージョン更新以前と同様に、総当たり攻撃も非常に容易である。
まぁ「以前はスマホが使える人なら誰でもできた」ということもあり、障壁が高くなったという点は評価できる。問題発覚からそれほど日数が経っていないことも踏まえれば「まぁ」といったところだ。
また、セキュリティに関するガイドラインを全く遵守していない可能性も十分ある（瑣事として取り扱われている可能性もあるが）
これまでPayPayとは関係なく流出したクレカの番号などがPayPayで今後も使い放題であることは、依然として変わりない。設計上の重大な問題が解決されてはいない。
こうした管理方法に関する情報や今後の対策を公表しないということは、社内で事態が異常すぎることが理解できていないか、あるいは理解できた上で隠蔽しているということである。
「うちから流出していない」「お客さまの情報を適切な方法で管理している」としているが、秘匿情報である鍵だけでなく、問題が起こったときにすら管理方法を非公開にするというのは「私たちは金融に携わっていますがセキュリティの知識はありません」と叫んでいるも同然だ。
もしここで3Dセキュアを導入するとなれば改修も大変であり、消費者の疑念も大きく高まる。
こうした実装をした技術者が、一般的な技術者が持つセキュリティに関する知識を持っているということも考えにくい。リリースに及んだ体制も気になるところである。
現実的な落とし所はセキュリティコンサルを呼んでひそかに大改修をし、緊急メンテナンスの告知をもって前触れ無くリリースすることだろうか。ただPayPayのもつ利便性は大きく損なわれる（安全性の犠牲の上にたつ利便性だが）
対応がことごとく場当たり的であり保身にすぎているのであり、そして杜撰である。最初から騙す気だったということはないだろうが、全体的に著しく無能である。
表面的な輝かしさとは裏腹に、内情は火の車なのであろうか。
なにはともあれ、人材不足を強く露呈しており、彼の右にインド人をおき、ハンドルを切り違え、IT後進国の象徴となってしまった（げきうまギャグ）
さらにこの期に及んで「名を売った」ことを良しとしている点は、次々と現れる問題について対処不能・対処不履行とするための布石のように見える。
会社の持つこうした異常なポジティブさとサイコパス性だけは見習うべきかもしれない。
そしてサイコパス的な観点で自己の利を追求する場合「100億を愚民に還元するよりかは倒産してしまって損切りするほうがメリット大」と判断する可能性がある。
今後の度重なる対応を勘案し、「100億がまだPayPayへ融資されていない」のであれば利益を得られないとして「善は急げ」と親会社が撤退するのは極めて合理的であろう。
前回の通信障害でソフトバンクの解約数は1万件といったとこらしいが、全体では3700万件(2014年)契約があるため、要は0.03%のダメージである。
今回の件に関してPayPayがソフトバンクとヤフーの合弁会社であることを知っている人たちはどのくらいいるだろうか。ネット上では多くいるように見えるが全体ではどうだろうか。
あるいは君主論にあるように、今後は打って変わって誠実に対応していき、みっともなくも生き残り、覇権を握るだろうか。唾棄すべきであるが。
我々にできることはそう多くはない。数ヶ月の間明細に目を凝らし、不正利用がないかを検査し、あればカード会社へ連絡し、補償を受けるのみである。
得られた教訓は、誰が悪いとかどこが悪いかとかそういったことではなく、ただ単に「こういう場所で我々は生きている」とということである。あまり気分の良いものではない。
アドバイスどうもありがとうございます。
https://anond.hatelabo.jp/20181218231219
本番サーバには入れないでね
phpMyAdminのセキュリティーって、過去の事例を見ると、あまり高くないようですね？
この手の管理ツールはセキュリティ侵害を受けた場合のダメージが大きいので、インターネットからアクセスできないようにしておくのが基本です。特にphpMyAdminは過去に致命的な脆弱性が何度も発見されており、インターネットにさらして利用するには向いていません。任意コード実行可能な脆弱性の事例もあり、DB以外にもリスクがあります。
内部ネットワークからしかアクセス出来ないようにしておきましょう。レンタルサーバのようなインターネットに孤立したサーバであっても、VPNの経路を作りそちらからしかアクセス出来ないようにしておくようにした方がよいでしょう。
IPアドレスによる制限は次善策です。アクセス元のIPアドレスが固定されており他人と共有していないならそれなりに安全になります。
URLによる隠蔽は外部から攻撃可能な既知の脆弱性をスキャンするようなカジュアルなアタック避け程度にはなりますが、URLは何かと漏洩するものですので、一般にセキュリティ手法と見なされていません。
アクセス制限をした場合でも、認証は必ず設定する必要があります。例えばCSRFのような攻撃にはアクセス制限は無意味です。
phpMyAdminの認証とHTTP認証のどちらを使う方がよいかは使ったことがないのでわかりませんが、HTTP認証の場合BASICではなくダイジェスト認証にしてください。BASIC認証は（ほぼ）生で認証情報が流れますので使ってはいけません。(ブラウザで人が操作する場合以外にはBASIC認証を使わざるを得ない場合もあります）
こんなかんじでしょうか？
まぁでも、単にこの増田は、単に大手男子の攻め方がわかってないんじゃないかな。
気合が見えない(入ってないとは言ってない)ほうが良いんだよ。
実際、増田からは地味に見えてる正社員女子が結婚してるんでしょ？
その地味な感じが正解なんだよ。
