展望

しかし、会社を辞めるにしても、今後の展望というものを持っていないとマズイ。
転職先の問題だな。

僕は現在29歳で、もうすぐ30歳になる。
となれば、年齢相応の業務に就かなければマズイのだ。
そもそも退職を決断した理由が「異動先の業務内容が過去五年間に積み重ねたスキルに見合っていない」だから、転職先の業務内容はスキルに見合ったものにしないと意味が無い。

そこで問題になるのが「じゃあ、スキルに見合った業務って何なの？」というものだ。
つまり、今後のキャリアプランというものだな。

思えば、今の会社でキャリアプランを真面目に考えたことなど、一度も無かったな。
今の会社には「目標面接」や「育成面接」というものが定期的に行われていて、キャリアプランについて考える動機を持たせようという試みがある。提出する文面に「3年後の自分」「10年後の自分」みたいな項目があって、ここに将来の自分の社員像を記入するわけだ。
上の人が演説においても、「ビジョンを持て」というような話をすることが多い。

しかし、このキャリアプラン・将来像というのは、選択肢が「会社に残る」以外に選択肢無き状態であれば、平凡な会社員が持ち得ることは至難ではないかと思う。
何故かというと、会社員というのは所詮、

・自分の仕事を決めるのは自分ではなく上司である。

という制約に縛られている。
だから、将来の展望を考える意義も薄く、考える意欲も出ない。

実際、僕が粗末ながらも持っていた「Ｗｅｂシステム開発のエンジニア」というキャリアプランは、異動によって無に帰した。つまり、「キャリアプランを持っていても会社内では考慮されない」ということだ。
こういう状況だと「人生はなるようにしかならねえな」という考えに落ち着く。
それが普通のサラリーマンだ。

しかし、転職するとなると、それではダメだ。
転職ってのは選択肢が無限にある。それを自分が活動できる範囲にまで絞り込むためには、キャリアプランが明確になっていないと活動できない。

しかも、面接で話が出来るよう、文言として表現出来るくらいに具体的でなければならない。

さて、困ったのう。(´・ω・`)

理由

会社を辞めることになった最大の理由は『異動』だ。

僕は入社してから5年間、「Ｗｅｂシステム開発」に従事してきた。
当然、持ち合わせているスキルもＷｅｂシステム開発向けになっている。

しかし、5年目の終わり頃に部署で体制変更があって、
僕は携わる業務を異動した。そして現在に至る。

しかし、異動した先である今のポジション……、
どうやら僕の持っている「Ｗｅｂシステム開発スキル」を生かす余地は無いようだ。。。

このポジションにおいては、僕は「スキル無し」も同然。。。

そりゃ異動した先で頑張れば何とかならんことも無い。
しかし、今まで積み重ねた研鑽を放棄するのも、ちょっとな……。

それに、僕の回りには元からその仕事に従事してきた人も沢山いる。一方、僕は新参者で、持っているスキルもその業務に不要。そこから気持ちを新たに頑張っていこうというのは、僕には「新しい課題」ではなく、「無駄」にしか思えなかった。

現在は僕の持っている業務を引き継ぎ中。
異動と言っても不完全な異動だったので、過去のポジションの仕事も残っている。
これを昔の所属だったＷｅｂシステム開発チームの人に引き継ぎ中だ。

現在、昔の所属だったＷｅｂシステム開発チームは人手不足で大変そう。
そこに僕の残作業を被せるわけだから、踏んだり蹴ったりだな。

「じゃあ、お前が元の場所に戻れよ！！」って突っ込まれるところだが、
異動ってのは人事命令だからな。それなりに重いものだと思う。
「異動命令を撤回して僕のポジションを元に戻して下さい！！」みたいなことを言うのは我儘かなぁっと思って……。

だからと言って、辞めてしまうとそれ以上に体制に打撃を与えてしまうのだが、
その変は、僕も自分の将来を考えているので……。

すまんのう。(´・ω・`)

辞め

会社を辞めることになった。

ローズウォーター

ハニーと「海の見える丘公園」という所に行ってきた。

散歩だな。

その公園の中に「えのき亭」という喫茶店がある。
写真は店の中から庭を撮影したものだが、ご覧の通り、外国の庭園風である。
その喫茶店では、入店すると「ローズウォーター」というものが出てくるのだ。

水道水に薔薇の香水を混ぜたようなもの。

以前、氷水の入ったピッチャーにレモンの切れ端が入っている「レモンウォーター」を提供しているラーメン屋があったけど、同じことを薔薇でやるとは。
世の中にはこういうものもあるのだな。

調べてみると、世間ではサプリメント扱いで販売されているようだ。
効能を見ると、「リラックス効果」とかいう辺り、ハーブティーと似ていると思う。
しかし、ハーブティーよりは高給。

味わいや香りも繊細で、ほんの一口を口に含んで香りを楽しむという飲み方だろうか。
カップ一杯飲んでしまうハーブティーよりも上位ランクな嗜好品だろう。

男でもコーヒーや紅茶は飲む。好きな人ならハーブティーも飲むだろう。
しかし、独身野郎で「ローズウォーター」は無えわ。
普通は存在すら知らんだろ。

結婚して出かけるようになると、こういう類の物とも縁が出来るのだな。(´・ω・`)

もぎょ

もぎょ

往復

　　 ∧　∧
　　(　´･ω･`) oＯ(・・・・。)
　 ＿|　⊃／(＿＿_
／　└-(＿＿＿_／

6：00　起床
8：40　出社
9：00　会社到着
24：00　帰宅
25：00　就寝

　　　
　 ＜⌒／ヽ-、_＿_ oＯ(・・・・・。)
／＜_/＿＿＿＿／

ぶっ飛び3

ファーストサーバぶっ飛び事件の報告が上がってきたようだ。

http://support.fsv.jp/info/nw20120625_01.html

感想としては、「やってしもうたか。(´・ω・`)」といったところだ。
僕も現場の人間だから「ああ～」と思う部分がある。

原因1：脆弱性対策のための更新プログラムの不具合
脆弱性対策のためのメンテナンスが必要となる都度、メンテナンスのための更新プログラムを作成しており、今回も更新プログラムを作成しています。そのプログラムの記述において、ファイル削除コマンドを停止させるための記述漏れと、メンテナンスの対象となるサーバー群を指定するための記述漏れが発生していました。

これ、何か「ソフトウェアにバグでもあったのかな」って思わせるようにゴニョゴニョ書いてあるけど、ようするに「コマンドの打ち間違え」だろ。
ここに書いてある「更新プログラム」って、人が手で打ち込むコマンドを前もってスタンバイしておくだけのシロモノだから「プログラム」などと呼ぶのはおこがましい。
「下準備でミスりました」ってだけなんだから、「コマンドの打ち間違え」と何ら変わらん。

まあ、実際のところ、こういうミスはあり得るんだよな。
僕も経験がある。「あっ！？」と思ったら消えちまった、みたいな。
ウェイトレスが滑って転んで客の頭にホットコーヒーをぶっかけるようなもの。
今回、ここまでの被害になっちまったのは運が悪かったとしか……。

原因2：メンテナンス時の検証手順
メンテナンスに際しては、検証環境でまず動作確認を行うという手順が定められていましたが、プログラム実行後の動作確認を行う対象は、あくまでも当該メンテナンス対象サーバー群を確認すれば足りるとされていたため、検証環境下で対象サーバー以外に影響が及んだことの確認がないまま、動作確認上は問題なしと判定され本番環境での実施が行われました。

デグレードチェックが甘かったんだな。これも仕方が無い。(´＞ω＜`)
「対象サーバはＡサーバです」って言ってるんだから、みんなＡサーバはしっかりチェックするけど、他のＢサーバやＣサーバはチェックしないのよ。
他の対象外サーバのチェックまでやってたら、時間がいくらあっても足りない。
「どうしてもやって欲しいなら工数を10倍払えよ」ってことになる。
と言っても、普段から値下げ合戦している業界だから、そんなコストはとても払えない。
これは仕方無い。

ただし、これって多分、「午前中に検証環境でテストして、午後に本番適用」とか、それくらいの短期間で一気にやったんだな。一週間くらい様子を見れば気づけた可能性が高かったのに。
きっと、忙しかったのだろう。
我がサービスの場合、「ステージング環境」と呼ばれる検証環境と本番の中間ステップがあって、そこで一週間様子見することになってるから、ここは安心だな。

原因3：メンテナンス仕様
システムを含むデータのバックアップは毎朝6時に取得しております。
しかしながら、脆弱性対策のためのメンテナンスはバックアップをしてあるシステムについても実施しておかないと、メンテナンス実施後にハードウェア障害が発生してバックアップに切り替えた途端に脆弱性対策が講じられていないシステムに戻ってしまうことが過去に発生し、脆弱性対策がなされていないシステムが動き続けていたという反省に立ち、脆弱性対策のメンテナンスに関しては対象サーバー群とそのサーバー群のバックアップ領域に対して同時に更新プログラムを適用するという構造に修正して実施しました。

これはバックアップじゃなくて「コールドスタンバイ」って言うんだよ。(´＞ω＜`)
バックアップは最初から無かったのだ。。。

まあ、バックアップは出来ないから無かったんだろう。
サーバ規模が巨大になるとバックアップするのも一苦労になる。1日でバックアッププロセスが終わらないくらい負荷も出てくるから、バックアップってのはイメージより難しいのよ。
もちろん、最初からバックアップ負荷を計算して分散設計になっていれば大丈夫だけど、それだどハードウェア等の費用が2倍、3倍になっちまう。予算が無かったんだな。

だが、稼働系と待機系を同時に消したのは痛かった。
しかし、文章を見ると「昔、稼働系だけにパッチを適応して、待機系に適応するのを忘れるという障害があったことへの対応」というのがある。
コレ見ると「あちゃ～」だな。

「問題があるから何か対応しなければいけない！⇒対応したらもっと悪くなりました」

こういうことがあるんだよ。我が社でも沢山ある。
「問題に対する攻撃的姿勢だけが強烈で、改善策を出す能力が無い」って姿勢の人がいると、社内の雰囲気が悪くなって「こんなことやっても無駄だよなぁ」「何もしない方がマシだよなぁ」と大勢の社員が思いつつも、改悪を実行。
結果グダグダ。
よくある話。



以上、僕の感想を言うと、「重過失致死」
トラック運転手が居眠り運転して小学生の列に突っ込むようなもの。
そりゃ過失は過失だけど「100％防ぐ手段を示せ！！」って言われても、う～んってところ。

原発もそうだけど、やっぱ世の中に安全神話なんて無いんだな。(´・ω・`)