もぎょ
- 2012年6月29日金曜日
- 2012年6月26日火曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
往復
∧ ∧
( ´・ω・`) oO(・・・・。)
_| ⊃/(___
/ └-(____/
6:00 起床
8:40 出社
9:00 会社到着
24:00 帰宅
25:00 就寝
<⌒/ヽ-、___ oO(・・・・・。)
/<_/____/
( ´・ω・`) oO(・・・・。)
_| ⊃/(___
/ └-(____/
6:00 起床
8:40 出社
9:00 会社到着
24:00 帰宅
25:00 就寝
<⌒/ヽ-、___ oO(・・・・・。)
/<_/____/
- 2012年6月25日月曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
ぶっ飛び3
ファーストサーバぶっ飛び事件の報告が上がってきたようだ。
http://support.fsv.jp/info/nw20120625_01.html
感想としては、「やってしもうたか。(´・ω・`)」といったところだ。
僕も現場の人間だから「ああ~」と思う部分がある。
これ、何か「ソフトウェアにバグでもあったのかな」って思わせるようにゴニョゴニョ書いてあるけど、ようするに「コマンドの打ち間違え」だろ。
ここに書いてある「更新プログラム」って、人が手で打ち込むコマンドを前もってスタンバイしておくだけのシロモノだから「プログラム」などと呼ぶのはおこがましい。
「下準備でミスりました」ってだけなんだから、「コマンドの打ち間違え」と何ら変わらん。
まあ、実際のところ、こういうミスはあり得るんだよな。
僕も経験がある。「あっ!?」と思ったら消えちまった、みたいな。
ウェイトレスが滑って転んで客の頭にホットコーヒーをぶっかけるようなもの。
今回、ここまでの被害になっちまったのは運が悪かったとしか……。
デグレードチェックが甘かったんだな。これも仕方が無い。(´>ω<`)
「対象サーバはAサーバです」って言ってるんだから、みんなAサーバはしっかりチェックするけど、他のBサーバやCサーバはチェックしないのよ。
他の対象外サーバのチェックまでやってたら、時間がいくらあっても足りない。
「どうしてもやって欲しいなら工数を10倍払えよ」ってことになる。
と言っても、普段から値下げ合戦している業界だから、そんなコストはとても払えない。
これは仕方無い。
ただし、これって多分、「午前中に検証環境でテストして、午後に本番適用」とか、それくらいの短期間で一気にやったんだな。一週間くらい様子を見れば気づけた可能性が高かったのに。
きっと、忙しかったのだろう。
我がサービスの場合、「ステージング環境」と呼ばれる検証環境と本番の中間ステップがあって、そこで一週間様子見することになってるから、ここは安心だな。
これはバックアップじゃなくて「コールドスタンバイ」って言うんだよ。(´>ω<`)
バックアップは最初から無かったのだ。。。
まあ、バックアップは出来ないから無かったんだろう。
サーバ規模が巨大になるとバックアップするのも一苦労になる。1日でバックアッププロセスが終わらないくらい負荷も出てくるから、バックアップってのはイメージより難しいのよ。
もちろん、最初からバックアップ負荷を計算して分散設計になっていれば大丈夫だけど、それだどハードウェア等の費用が2倍、3倍になっちまう。予算が無かったんだな。
だが、稼働系と待機系を同時に消したのは痛かった。
しかし、文章を見ると「昔、稼働系だけにパッチを適応して、待機系に適応するのを忘れるという障害があったことへの対応」というのがある。
コレ見ると「あちゃ~」だな。
「問題があるから何か対応しなければいけない!⇒対応したらもっと悪くなりました」
こういうことがあるんだよ。我が社でも沢山ある。
「問題に対する攻撃的姿勢だけが強烈で、改善策を出す能力が無い」って姿勢の人がいると、社内の雰囲気が悪くなって「こんなことやっても無駄だよなぁ」「何もしない方がマシだよなぁ」と大勢の社員が思いつつも、改悪を実行。
結果グダグダ。
よくある話。
以上、僕の感想を言うと、「重過失致死」
トラック運転手が居眠り運転して小学生の列に突っ込むようなもの。
そりゃ過失は過失だけど「100%防ぐ手段を示せ!!」って言われても、う~んってところ。
原発もそうだけど、やっぱ世の中に安全神話なんて無いんだな。(´・ω・`)
http://support.fsv.jp/info/nw20120625_01.html
感想としては、「やってしもうたか。(´・ω・`)」といったところだ。
僕も現場の人間だから「ああ~」と思う部分がある。
原因1:脆弱性対策のための更新プログラムの不具合
脆弱性対策のためのメンテナンスが必要となる都度、メンテナンスのための更新プログラムを作成しており、今回も更新プログラムを作成しています。そのプログラムの記述において、ファイル削除コマンドを停止させるための記述漏れと、メンテナンスの対象となるサーバー群を指定するための記述漏れが発生していました。
これ、何か「ソフトウェアにバグでもあったのかな」って思わせるようにゴニョゴニョ書いてあるけど、ようするに「コマンドの打ち間違え」だろ。
ここに書いてある「更新プログラム」って、人が手で打ち込むコマンドを前もってスタンバイしておくだけのシロモノだから「プログラム」などと呼ぶのはおこがましい。
「下準備でミスりました」ってだけなんだから、「コマンドの打ち間違え」と何ら変わらん。
まあ、実際のところ、こういうミスはあり得るんだよな。
僕も経験がある。「あっ!?」と思ったら消えちまった、みたいな。
ウェイトレスが滑って転んで客の頭にホットコーヒーをぶっかけるようなもの。
今回、ここまでの被害になっちまったのは運が悪かったとしか……。
原因2:メンテナンス時の検証手順
メンテナンスに際しては、検証環境でまず動作確認を行うという手順が定められていましたが、プログラム実行後の動作確認を行う対象は、あくまでも当該メンテナンス対象サーバー群を確認すれば足りるとされていたため、検証環境下で対象サーバー以外に影響が及んだことの確認がないまま、動作確認上は問題なしと判定され本番環境での実施が行われました。
デグレードチェックが甘かったんだな。これも仕方が無い。(´>ω<`)
「対象サーバはAサーバです」って言ってるんだから、みんなAサーバはしっかりチェックするけど、他のBサーバやCサーバはチェックしないのよ。
他の対象外サーバのチェックまでやってたら、時間がいくらあっても足りない。
「どうしてもやって欲しいなら工数を10倍払えよ」ってことになる。
と言っても、普段から値下げ合戦している業界だから、そんなコストはとても払えない。
これは仕方無い。
ただし、これって多分、「午前中に検証環境でテストして、午後に本番適用」とか、それくらいの短期間で一気にやったんだな。一週間くらい様子を見れば気づけた可能性が高かったのに。
きっと、忙しかったのだろう。
我がサービスの場合、「ステージング環境」と呼ばれる検証環境と本番の中間ステップがあって、そこで一週間様子見することになってるから、ここは安心だな。
原因3:メンテナンス仕様
システムを含むデータのバックアップは毎朝6時に取得しております。
しかしながら、脆弱性対策のためのメンテナンスはバックアップをしてあるシステムについても実施しておかないと、メンテナンス実施後にハードウェア障害が発生してバックアップに切り替えた途端に脆弱性対策が講じられていないシステムに戻ってしまうことが過去に発生し、脆弱性対策がなされていないシステムが動き続けていたという反省に立ち、脆弱性対策のメンテナンスに関しては対象サーバー群とそのサーバー群のバックアップ領域に対して同時に更新プログラムを適用するという構造に修正して実施しました。
これはバックアップじゃなくて「コールドスタンバイ」って言うんだよ。(´>ω<`)
バックアップは最初から無かったのだ。。。
まあ、バックアップは出来ないから無かったんだろう。
サーバ規模が巨大になるとバックアップするのも一苦労になる。1日でバックアッププロセスが終わらないくらい負荷も出てくるから、バックアップってのはイメージより難しいのよ。
もちろん、最初からバックアップ負荷を計算して分散設計になっていれば大丈夫だけど、それだどハードウェア等の費用が2倍、3倍になっちまう。予算が無かったんだな。
だが、稼働系と待機系を同時に消したのは痛かった。
しかし、文章を見ると「昔、稼働系だけにパッチを適応して、待機系に適応するのを忘れるという障害があったことへの対応」というのがある。
コレ見ると「あちゃ~」だな。
「問題があるから何か対応しなければいけない!⇒対応したらもっと悪くなりました」
こういうことがあるんだよ。我が社でも沢山ある。
「問題に対する攻撃的姿勢だけが強烈で、改善策を出す能力が無い」って姿勢の人がいると、社内の雰囲気が悪くなって「こんなことやっても無駄だよなぁ」「何もしない方がマシだよなぁ」と大勢の社員が思いつつも、改悪を実行。
結果グダグダ。
よくある話。
以上、僕の感想を言うと、「重過失致死」
トラック運転手が居眠り運転して小学生の列に突っ込むようなもの。
そりゃ過失は過失だけど「100%防ぐ手段を示せ!!」って言われても、う~んってところ。
原発もそうだけど、やっぱ世の中に安全神話なんて無いんだな。(´・ω・`)
- 2012年6月24日日曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
ぶっ飛び2
ファーストサーバぶっ飛び事件はまだ全容が見えないな。
いずれITproとかでも特集が組まれるだろうから、
随時追っていきたい。
それはそうと、今回の件がクラウド業界全体を揺るがすものであるのは確実だな!!
今のIT業界は「クラウド」っていう言葉自体が一人歩きしていて、
意味も分からずクラウドクラウドって言っている人も多い。
実際、クラウドって言葉の定義自体、今となってはハッキリしないものだろう。
クラウドの本当の意味はとりあえず置いておくとして、
僕の思う「クラウド」の特徴として特筆すべき点を挙げる。
それは、
クラウド:複数の企業で1台のマシンを使う。
ということだ。
それに対し、昔ながらの専用機というのは、
専用機:1つの企業で1台のマシンを使う。
となる。
僕はこの違いを重視したい。
今回、確かに大災害になったけど、これは別に
クラウド=脆弱
専用機=強固
って意味にはならんよ。
システムの保守性、完全性、強度は両者全く互角。
だから、「自分もクラウドサービス使ってる。もしかしたら自分のデータが消えるかも。」って思うのは早とちり。
安全性は変わりません。
じゃあ、何が問題なのかっていうと、
専用機をぶっ壊した場合は、その専用機を使っていた企業1社に対し賠償すれば良い。
しかし、クラウドをぶっ壊すと、今回のケースだと5000社に対し賠償となる。
5000社も相手に賠償なんて出来るわけねーだろ!!
つまり、クラウドという技術そのものは別に問題無い。
既にコストが許す限りの精一杯に十分な保守水準を達成している。
逆に言うと、コスト競争で安値合戦をするとそれだけヤバイってことだが、それは置いておいて。
とにかく、十分十分と言いつつ、やっぱり万が一って事がある。
そして、その万が一の際に、これだけ規模が大きくなると賠償が出来ない。つまり、
万が一の際に、会社が責任を負いきれないような巨大な責任を軽々しく背負ってしまう
という、経済的・法律的・政治的な部分に問題があるものだと思う。
じゃあ、どうすりゃいいの?って話になる。
天地がひっくり返っても100%絶対安全ってのを技術的に達成するのは不可能。
どうしても想定外の事態というものはある。
となれば、僕が思いつく対策というのは「保険」だな。
保険会社が企業向けに「クラウド保険」みたいなのを作って、
万が一の際は保険金で賠償出来るようにしておくこと。
鉄道業界だと、鉄道で大事故やらかした時に備えて保険が用意してあるって聞いたことがある。
同じことをIT業界向けにやってくれ。
これをやってくれれば、IT会社は
・お客様のデータは死んでも守ります。
・万が一、死んでも守れなかった場合は、保険金で賠償します。
って言えるだろ。
全く、これから未来が開けるはずだったクラウド商売に、
とんでもない冷や水がぶっかかったもんだぜ!!
いずれITproとかでも特集が組まれるだろうから、
随時追っていきたい。
それはそうと、今回の件がクラウド業界全体を揺るがすものであるのは確実だな!!
今のIT業界は「クラウド」っていう言葉自体が一人歩きしていて、
意味も分からずクラウドクラウドって言っている人も多い。
実際、クラウドって言葉の定義自体、今となってはハッキリしないものだろう。
クラウドの本当の意味はとりあえず置いておくとして、
僕の思う「クラウド」の特徴として特筆すべき点を挙げる。
それは、
クラウド:複数の企業で1台のマシンを使う。
ということだ。
それに対し、昔ながらの専用機というのは、
専用機:1つの企業で1台のマシンを使う。
となる。
僕はこの違いを重視したい。
今回、確かに大災害になったけど、これは別に
クラウド=脆弱
専用機=強固
って意味にはならんよ。
システムの保守性、完全性、強度は両者全く互角。
だから、「自分もクラウドサービス使ってる。もしかしたら自分のデータが消えるかも。」って思うのは早とちり。
安全性は変わりません。
じゃあ、何が問題なのかっていうと、
専用機をぶっ壊した場合は、その専用機を使っていた企業1社に対し賠償すれば良い。
しかし、クラウドをぶっ壊すと、今回のケースだと5000社に対し賠償となる。
5000社も相手に賠償なんて出来るわけねーだろ!!
つまり、クラウドという技術そのものは別に問題無い。
既にコストが許す限りの精一杯に十分な保守水準を達成している。
逆に言うと、コスト競争で安値合戦をするとそれだけヤバイってことだが、それは置いておいて。
とにかく、十分十分と言いつつ、やっぱり万が一って事がある。
そして、その万が一の際に、これだけ規模が大きくなると賠償が出来ない。つまり、
万が一の際に、会社が責任を負いきれないような巨大な責任を軽々しく背負ってしまう
という、経済的・法律的・政治的な部分に問題があるものだと思う。
じゃあ、どうすりゃいいの?って話になる。
天地がひっくり返っても100%絶対安全ってのを技術的に達成するのは不可能。
どうしても想定外の事態というものはある。
となれば、僕が思いつく対策というのは「保険」だな。
保険会社が企業向けに「クラウド保険」みたいなのを作って、
万が一の際は保険金で賠償出来るようにしておくこと。
鉄道業界だと、鉄道で大事故やらかした時に備えて保険が用意してあるって聞いたことがある。
同じことをIT業界向けにやってくれ。
これをやってくれれば、IT会社は
・お客様のデータは死んでも守ります。
・万が一、死んでも守れなかった場合は、保険金で賠償します。
って言えるだろ。
全く、これから未来が開けるはずだったクラウド商売に、
とんでもない冷や水がぶっかかったもんだぜ!!
- 2012年6月23日土曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
白雪
ハニーと映画「スノーホワイト」を観てきたにゃん。
王道的なファンタジーだったな。
誰が観てもハズレが無いようなストーリーだったと思う。
次はディズニーアニメを見に行かなきゃな。
王道的なファンタジーだったな。
誰が観てもハズレが無いようなストーリーだったと思う。
次はディズニーアニメを見に行かなきゃな。
- 2012年6月21日木曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
ぶっ飛び
ファーストサーバで大規模なデータ障害、顧客データが消失
サーバホスティング事業を手掛けるファーストサーバは、提供中の一部のサービスで大規模なデータ障害が発生し、顧客のデータが消失したことを明らかにした。
対象サービスは「ビズ」「ビズ2」「エントリービズ」「EC-CUBEクラウドサーバ マネージドクラウド」および、これらのサービスを利用したオプションサービス。(1)サーバ上にアップロードされたデータ(FTP、ファイルマネジャーなど)、(2)コンフィグレータ設定を含むデータ、(3)メールボックス内のデータ――が消失し、サーバを随時初期化して提供しているという。
http://www.atmarkit.co.jp/news/201206/22/firstserver.html
どひゃ~。
ホスティングサービスなのにデータぶっ飛ばしちゃったんだな。
バックアップも効かないのか。
それは困る。(´・ω・`)
僕が関係している会社の業務で言うところの
・基幹伝送ファイルが全部ぶっ飛び
・全サービスのDBがぶっ飛び
・ファイル掲示板の全ファイルがぶっ飛び
⇒業務続行不能
ってくらいの破壊規模か。
そんなことになったら……、怒られるのう。(´・ω・`)
どうやらこの「ファーストサーバ」って、企業向けが多いようだ。
だから、通販事業を行っている会社で「客から商品を注文して金も受け取ったけど、データがぶっ飛んだので、何の商品を誰に発送して良いか不明になった」「通販サイト自体が完全にぶっ飛んだので、事業が継続不可能になった。」とか、こういう状況になってるらしい。
事業終了、会社解散になるくらいの完全ぶっ飛びだ。
ユーザ数は5万人っつーから、結構な人数の失業者が出現してしまいそうだな。
IT業界にとっては、原子力発電所がメルトダウン起こしたような歴史的災害だわ。
これは困った。(´・ω・`)
- 2012年6月19日火曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
台風
/ / / /
_n_
///|ヾ\ / /
⌒⌒|⌒⌒
/ |∧_∧ / /
|・ω・`)
/ Oと ) / /
しーJ。。。。。
早めに帰って来れて良かったお。
_n_
///|ヾ\ / /
⌒⌒|⌒⌒
/ |∧_∧ / /
|・ω・`)
/ Oと ) / /
しーJ。。。。。
早めに帰って来れて良かったお。
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
競争
佐川急便は21日、業界初となる宅配便の24時間対応の電話集荷サービスを東京都内の一部地域で始める。
午前3時までに集荷の電話をすれば同日中に全国主要都市に配送できる。
ライフスタイルの多様化から都心で深夜帯の集荷要望が相次いでいるのに対応する。
http://www.nikkei.com/article/DGXNASDD190EJ_Z10C12A6TJ0000/
佐川急便が集荷の24時間サービスを始めるらしい。
ヤフオクやっている身としては夜間帯でも集荷してくれるのは便利だと思う。
小型の品物なら自分でコンビニに持っていって発送だけど、
大型だと集荷を依頼せねばならん。
そういう時、仕事で忙しいと平日に対応出来ないから、発送は次の土曜日ってことで今までやってきた。
それが平日に発送出来る様になるわけだ。
非常に助かる。
受け取る側の視点では、夜中にネットで注文した商品が今までより1日早く届くようになるかもしれないな。
しかしこれ、従業員の方は大丈夫なんかって心配になる。
「深夜対応専用のドライバーを5~6人確保」って書いてあるけど、
これって詳しくはどういう意味なんだろう?
『今まで業務に従事してきたドライバーとは別に、新しく5~6人を雇用して、その中から深夜部隊と昼間部隊を編成する。』
って意味ならまだいいけど、
『新規雇用は行わず、今まで業務に従事してきたドライバーから5~6人を深夜に割り当て、残りのドライバーが昼間を担当する。』
だったらドライバー死ぬな!!
僕の予想としては、
『深夜サービスは決まったから、ドライバーを深夜部隊と昼間部隊に分けるシフト制は確定。ドライバーはこれから追加募集するが、人が集まるかどうかは採用活動の進捗次第』
って所かな。
まあ、どっちにしろ、今まで昼間だけ働いていたドライバーが、シフト制で夜も働くようになるってのはほぼ確定だろう。ドライバーキビシス。(´×ω×`)
しかしこれ、ちゃんと実現可能なんだろうな。
「ドライバーが居眠り運転して事故って荷物全損」とか起きるようでは本末転倒だろう……。
SE業界でも似たようなことが起こりがちで、
①目標が最初に決まっている。(例:納期、工数、品質を厳守)
⇒仕事を受注するためにクライアントにリップサービスして、厳しい条件になる。
②目標が決まった後から、それを実現する方法を考える。
⇒条件に無理がありすぎて実現不能という事態になる。
③壊滅。
⇒納期を延期。
⇒工数が足らず赤字。
⇒やっつけで済ませて品質ボロボロ。
まあ、流石に納期、工数、品質、全てがクラッシュしたプロジェクトは今まで体験してねーわ。
精々がどれか1コ犠牲、しかもギリギリ許容範囲内で何とかなってきている。
しかし、世の中には完全クラッシュしてしまうこともあるようだ。
・ユーフィット
・IBM
死ぬ気で働いて働いて働いた結果、
実現出来なくて違約金だの罰金だの敗訴だの、とんでもねえな!!
「実現出来ない公約を出して、とりあえず選挙では票を集める。⇒実現出来ませんでした」
「実現出来ない契約を取り交わして、とりあえず仕事は受注する。⇒実現出来ませんでした」
完全に同じ構図だろ。
牛丼業界もどうせ同じだろう。
「激烈なる値下げ競争をして、何を犠牲にしてでもとにかく客を集める。⇒食中毒。」
とかなるんじゃないかと、マジ心配だわ。
企業年金も利回りが達成不能になって配当減額とかになるし。
世の中みんなこの調子なんだな。
厳しい世の中じゃ。(´・ω・`)
- 2012年6月18日月曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
死の宣告
おっと、戦争チームに『死の宣告』が出たようだ。
マネージャー曰く、
「これ死んだわ」
らしい。
何でも、要件定義に見落としがあって、
予定に入っていない大幅な開発が出現したようだ。
現在は基本設計フェーズなんだが、すでに残業ベースになっている、とのこと。
マネージャー曰く、
「これ死んだわ」
らしい。
何でも、要件定義に見落としがあって、
予定に入っていない大幅な開発が出現したようだ。
現在は基本設計フェーズなんだが、すでに残業ベースになっている、とのこと。
- 2012年6月15日金曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
演説
今日は2年生発表会と言って、
2011年に入社した社員が1年間の成果を皆の前で発表する日だった。
十人十色の発表を終え、最後にその場で一番偉い本部長より、
今後の社員としての心構えを頂く。
(`・ω・´)「諸君らは今までは新人として先輩社員の世話になってきたと思う。」
ふむふむ。(´・ω・`)
(`・ω・´)「しかし、これからは先輩社員を超えることを目標に行かねばならん」
ふむふむ。(´・ω・`)
(`・ω・´)「例を挙げるならば、先日のAKB総選挙で篠田麻里子が言ったように」
台無しぽ。(´・ω・`)
2011年に入社した社員が1年間の成果を皆の前で発表する日だった。
十人十色の発表を終え、最後にその場で一番偉い本部長より、
今後の社員としての心構えを頂く。
(`・ω・´)「諸君らは今までは新人として先輩社員の世話になってきたと思う。」
ふむふむ。(´・ω・`)
(`・ω・´)「しかし、これからは先輩社員を超えることを目標に行かねばならん」
ふむふむ。(´・ω・`)
(`・ω・´)「例を挙げるならば、先日のAKB総選挙で篠田麻里子が言ったように」
台無しぽ。(´・ω・`)
- 2012年6月14日木曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
ウズマスターと
ウズマスターと
殺人システム
ウズマスターと
SE狩り
ウズマスターと
爆裂メガクラッシュ
ウズマスターと
怒りのスペシウム光線
ウズマスターと
最終聖戦の戦士たち
シリーズ化だお。(´・ω・`)
殺人システム
ウズマスターと
SE狩り
ウズマスターと
爆裂メガクラッシュ
ウズマスターと
怒りのスペシウム光線
ウズマスターと
最終聖戦の戦士たち
シリーズ化だお。(´・ω・`)
- 2012年6月13日水曜日
- 2012年6月12日火曜日
- 2012年6月10日日曜日
- 2012年6月9日土曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
生命力
横浜でハニーと香水を見ていたら、
(*^_^*)「ウズさん!!」
(´・ω・`)「おおっ!?」
何と、2年ほど前に退職した一つ下の後輩(女性)だった。
(´・ω・`)「こちらがハニーだお」
(・∀・)「はじめまして」
(*^_^*)「どうもどうも」
まあ、そんだけだ。
しかし、久しぶりに会ったけど、何と言うか、健康的になったような……。
別に元々が不健康だったわけではないのだけど、
僕の記憶よりもふっくらしていて、肌の艶も良くなっていたと思う。
一言で言うと「生き生き」していた。
今はもうSEの仕事はやっていなくて、医療系の仕事をやっているらしいが、
やっぱ仕事を変えたことが影響しているのかな?
僕は昔から家に籠ってゲームとかやってて、そのままSEになったタイプだからあんまり実感無いんだけど、
やっぱSE業界ってのは不健全な世界なのだろうか。
(*^_^*)「ウズさん!!」
(´・ω・`)「おおっ!?」
何と、2年ほど前に退職した一つ下の後輩(女性)だった。
(´・ω・`)「こちらがハニーだお」
(・∀・)「はじめまして」
(*^_^*)「どうもどうも」
まあ、そんだけだ。
しかし、久しぶりに会ったけど、何と言うか、健康的になったような……。
別に元々が不健康だったわけではないのだけど、
僕の記憶よりもふっくらしていて、肌の艶も良くなっていたと思う。
一言で言うと「生き生き」していた。
今はもうSEの仕事はやっていなくて、医療系の仕事をやっているらしいが、
やっぱ仕事を変えたことが影響しているのかな?
僕は昔から家に籠ってゲームとかやってて、そのままSEになったタイプだからあんまり実感無いんだけど、
やっぱSE業界ってのは不健全な世界なのだろうか。
- 2012年6月8日金曜日
- 2012年6月5日火曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
人材
2012年の日本における企業の「人材不足感」は、前年同期比1ポイント増の81%と過去最高値を記録した。世界の平均値である34%と比べると、日本は47ポイント高く、調査対象の国・地域中、日本企業の人材不足感が最も高い値を記録した。
http://news.mynavi.jp/news/2012/06/04/019/
この記事によると、日本企業の80%が人材不足で困っているらしいな。
「うちの会社にはロクな社員がいない」みたいな会社が80%ってことか。
もしくは、世の中で必要とされる人材は全体の20%で、
80%の人はどうでもいい、と読み取ることも出来るな。
中でも、特にエンジニアが不足しているらしい。
ということは、僕みたいなシステムエンジニアも不足しているってことだ。
じゃあ、どんな人材が求められているかというと、
まずエンジニアである以上、「技術力」は言うまでも無いということだろう。
「技術力」を十分に有している上で更に、
・対人力
・チームワーク・協調性
・熱意・モチベーション
・柔軟性・順応性
・不明瞭なことや複雑なことへの対応力
この辺りの力を持っていること。
そして、
・実務経験不足
・給与でのミスマッチ
・企業に対する知識や業界知識がない
といった問題点もクリア出来ている。
こういう人材が欲しいってことだな。
逆に言うと、これらスキルが一通り揃っている人材でなければ、
社会には不要ということか。
う~ん、世の中厳しス。僕は80%の中か。(´×ω×`)
3つくらいで合格にしてくれんかのう。(´・ω・`)
- 2012年6月3日日曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
混入
スーパー行ってきたお。(´・ω・`)
「味付き魚」コーナーに行き、奥にある「ぶりの照り焼き用」に着目した。
その名の通り、ぶりが照り焼き用に味付けしてあって、
焼けばぶりの照り焼き完成という、実に楽ちんなものである。
値段も安くて良い。
今週のどこかでお弁当にしようと思う。
さっそく手を伸ばして、トングで二切れ掴んで、手元の袋に……。
つるっ、ベチャ!!
(;´・ω・`)(あっ!?)
手が滑って、手前の「イカのバジル焼き用」のトレイに落下してしまった。
真っ白いイカバジルのど真ん中に、赤茶色の照り焼きぶりが落下。
(;´・ω・`)(なんてこった……)
とりあえず、本来自分が欲しかったぶりは拾い上げて袋に入れたが、
真っ白だったイカバジルは照り焼きソースに汚染されて赤茶色に……。
(;´・ω・`)(ヤバス……)
……
……
……
……
……
三┏( ^o^)┛<逃走だお!!
三 ┛┓
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
「味付き魚」コーナーに行き、奥にある「ぶりの照り焼き用」に着目した。
その名の通り、ぶりが照り焼き用に味付けしてあって、
焼けばぶりの照り焼き完成という、実に楽ちんなものである。
値段も安くて良い。
今週のどこかでお弁当にしようと思う。
さっそく手を伸ばして、トングで二切れ掴んで、手元の袋に……。
つるっ、ベチャ!!
(;´・ω・`)(あっ!?)
手が滑って、手前の「イカのバジル焼き用」のトレイに落下してしまった。
真っ白いイカバジルのど真ん中に、赤茶色の照り焼きぶりが落下。
(;´・ω・`)(なんてこった……)
とりあえず、本来自分が欲しかったぶりは拾い上げて袋に入れたが、
真っ白だったイカバジルは照り焼きソースに汚染されて赤茶色に……。
(;´・ω・`)(ヤバス……)
……
……
……
……
……
三┏( ^o^)┛<逃走だお!!
三 ┛┓
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
- 2012年6月1日金曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
往復
∧ ∧
( ´・ω・`) oO(・・・・。)
_| ⊃/(___
/ └-(____/
5:00 起床
8:40 出社
9:00 会社到着
22:00 帰宅
23:30 就寝
<⌒/ヽ-、___ oO(・・・・・。)
/<_/____/
( ´・ω・`) oO(・・・・。)
_| ⊃/(___
/ └-(____/
5:00 起床
8:40 出社
9:00 会社到着
22:00 帰宅
23:30 就寝
<⌒/ヽ-、___ oO(・・・・・。)
/<_/____/
登録:
投稿 (Atom)