旅好きおやじの日記 TOP  >  情報システム

プログラムは技術だけでは動かない

ネットワークプログラマである著者が、プログラミングで成功したという武勇伝
を書いた本。

著者が振り返るに、
「頼んだものと違う動きのものが出来上がってきた」
「いつまでたっても出来上がらない」
「安定して動かない」
「性能が出ない」
「仕様変更などの応用が効かない」
「ソースコードを他の人が理解できない」
ということがたくさんあったという。

読み進めてみると、著者はDHCPサーバを我流で自作したという。

エピソードを見てみると、確かにスーパープログラマで売り物になるものを
作る実力があるのは認めるが、凡人プログラマだった私のような技術力の
人間が、この著者を真似ると普通の会社ではクビになるだろう。

あくまで、我流でできて、一人でケツがふける規模のステップ数のプログラム
だからいえるのであって、結局、この人の技術で、たまたま作ったプログムが
動き、売り物になり、お金が稼げたという自慢が全面に出た話でしかなかった。

ただし、プログラマの上を目指す人間にとって、参考になることも多く書かれて
いる。

商品に設定をどうするかといった話や、価格設定を高くするべき製品と、低く
するべき製品の話、知らないことを「知らない」というのは恥ずかしいことだが、
「知らない」ということを恥を忍んで人に聞いて知ることで近道になることもある
という話は、少し心に響いた。



最後まで読んで頂きありがとうございます。こちらを押していただけると嬉しいです!!
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
にほんブログ村 オヤジ日記ブログへ
スポンサーサイト
[ 2017年04月14日 04:35 ] 情報システム | TB(-) | CM(0)

進化する銀行システム

ここ5年はメインフレームでおまんまを食べていたのだが、はっきり言って全容
をつかめていない。

メインフレームと一言で言っても、ハード、ソフト、ネットワークが包含されてい
るため、範囲が広いのである。

メインフレームに対してオープン系のシステムというのは、市販の本があった
り、ググったり、知っている誰かに聞けば知りたい技術にたどり着けるのだが、
メインフレームの場合、市販本はほとんどなく、本があったとしてもわかりにく
い説明書が1つの棚を占有するぐらいの冊数ありとても読む気になれないし、
有識者も基本的に職人気質なので、体系的な説明を聞くのは難しい。

そんな情報の少ないメインフレームとはどんなものかが書かれたこの本が
あったので、早速購入した。

著者は日本IBMで銀行の第3次オンラインシステムに携わった方で、年齢は
私より10年歳ぐらい上の方の著書である。

本を読んだおかげで、日頃よく理解せず使っている用語についても知ること
ができた。

特にメモリ系の用語は勉強になったし、最近流行りの仮想化はもともとメイン
フレームの技術であることは知っていたが、それが実装されたのはなんと45
年前の1972年だったというのは驚きだった。

ビットコインとかブロックチェーン技術が取りざたされる中、過去の遺産を背
負った銀行は、身軽なFintech企業にリードされ廃れていくとも言われている
なか、銀行の勘定系システムとそれを支え、支えられているメインフレームが
どうなるのか、自分の生活にも関わる話でもあるので注目である。



最後まで読んで頂きありがとうございます。こちらを押していただけると嬉しいです!!
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
にほんブログ村 オヤジ日記ブログへ
[ 2017年03月25日 04:41 ] 情報システム | TB(-) | CM(0)

人工知能は人間を超えるか

先日、とあるフォーラムの企画委員会に参加したとき、最近何かと話題の人
工知能について討論をする場を持ってはどうだろうかという話になった。

最近、読書する本の数もめっきり減り、組込みシステムの勉強ぐらいしか
していない私は、この人工知能の話題に全くついて行けず、適当に相槌を
打つのが精いっぱいだった。

人工知能というのは、何を隠そう旅好きおやじが大学のときに研究していた
テーマであり、同じ研究室の同級生が、今では人工知能関連の大学教授に
なっているのに、旅好きおやじときたらなんという体たらくと思い、反省の意味
をこめてこの本を読むことにした。

25年ぐらい前にドラクエ4に使われていたAIがアホだったなというぐらいの
認識しかない旅好きおやじにとって、AIの歴史、なぜ、最近になってまたAI
がブームになっているのかということが認識できた。

AI自体は地道に発展している分野だが、最近になりコンピュータがビッグ
データを扱えるようになったおかげで、人工知能がより能力アップし、より
人間に近くなり、実用的になったという話であった、

企画委員会で出てきた、ディープラーニングについてもなんとか人に説明
できるようになったし、近い将来ターミネータのような機械が現れ人間を
攻撃するというのはないということもわかってよかった。

ちなみにターミネーターのように機械が意思を持つことと、機械が人間の
ような思考をすることは、難易度に天と地ほどの違いがあるそうである。



最後まで読んで頂きありがとうございます。こちらを押していただけると嬉しいです!!
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
にほんブログ村 オヤジ日記ブログへ
[ 2017年03月07日 04:50 ] 情報システム | TB(-) | CM(0)

期末面談での出来事

毎年、この時期になると部下に対して期末面談を実施する。

期首に定めた目標に対し、この1年でどういう成果を上げたかを部下に説明
してもらい、それに対してフィードバックをするというものである。

同じ部門で6年近くやってきているので、どの部下がどういう傾向にあるか、
また、私は日頃あまり口うるさく言わないほうだが、こういった機会に苦言を
呈すのは効果があるため、改善点を指摘しなければならない部下に対しては、
色々とフィードバックしている。

といったのが毎年の面談であるが、今回はいつもと違うことがあった。

うちの課のナンバー2(以後:N2氏)、私より1年先輩になるの部下に対して面
談をし、私が出張がちで不在の中、課内をまとめ本当に助かっているといった
話を面談でした後、「うちの課ではどんだけ努力しても評価されないのか」と、
私に文書で提言して来たのである。

IT企業では、企画や開発、保守、運用といった仕事に分類され、その分類
ごとに部門が別れるが、一般的に企画開発>保守>運用に順に優秀な人
材が割り当てられるものであり、私の会社も同様な組織構成となっている。

その中でも、このN2氏は腐ること無く、多少仕事は雑で粗忽ではあるが、
色々と仕事に取り組む姿勢がよく、他部門にも良い影響を与えているので、
私は高く評価しているのだが、いかんせん、そのことを人事考課の部課長会
議で言っても、どうしても、その年度にこなした案件の規模とか、利益を上げ
た人たちと比べると地味な運用部門で彼らより成果を上げていると説得力
を持って説明するのが難しく、組織間をまたいだ相対評価では彼の評価が
下がってしまうのである。

どうやら、去年の部課長会議の内容が、N2氏と仲のいい課長から漏れて
おり、N2氏の一次評価が、構築部門の一般的な社員よりも低く、私がそ
のことを指摘して喧々諤々していた様子を知っていたのである。
(ちなみに喧々諤々により多少彼の順位は上がったが、彼が納得行く
 順位まで上がったかどうかは私にもわからないし、彼にもそこまで漏れ
 てはいないと思う)

多分、N2氏と仲のいい課長は私がめずらしく喧々諤々していたことを、好意
的にN2氏に漏らしていたと推測されるのだが、去年の話とか、
企画開発>保守>運用という序列がある話、実際にN2氏以外の課員はい
まいちな人が多く評価が低いのはやむを得ないこと、序列があっても結局は
個人の成果を課長である私がどれだけ部課長に説得力を持って主張できる
かで決まることを話し、納得はしなかったが話を聞いたからなのか心が落ち
着いた形で面談を終えた。

このエピソードがなかったら、どうせ言っても無駄だと今週の部課長会議で
は黙っておこうと思ったが、今年も、彼のために部課長会議では頑張って
みたいと思った。

最後まで読んで頂きありがとうございます。こちらを押していただけると嬉しいです!!
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
にほんブログ村 オヤジ日記ブログへ
[ 2017年02月13日 04:12 ] とあるIT会社にて | TB(-) | CM(0)

ITインフラ系のテストでの教訓 その3

メインフレームの更新の際に得ることができた3つ目の教訓は、

「運用テスト項目は可能な限り正確に挙げる」

ということである。

5年前のメインフレームの更新の際に、運用テストの大切さを知り、今回の
プロジェクトの教訓としていた。

このため、今回のメインフレーム更新では運用テストを特に重視した。

プロジェクト側としてはそう思っても、メインフレームを使用している各部門
や各社の認識としては、「インフラの更新など、更新できて当たり前」と思い、
舐めてかかり、自己判断でいちいち面倒なテストを省略するという担当者も
出てくるわけである。

そのようなことがないように、運用テスト項目を提出させた後1点1点精査し、
新たに取り込むお客さんについてはメインフレームの環境だけではなく、お客
さんのネットワーク環境や業務内容についても整理させてもらった。

特に、今回新たに取り込むどのお客さんの情報システム部門も、1人で何役も
業務をこなすことを余儀なくされている人が多く、ちゃんとしたネットワーク
図やサーバの機能一覧なども、お客さんの頭のなかにあり見える化できてい
なかった。

お客さん側のシステムの更新はお客さんの責任でという原則はあるものの、
今回のメインフレームの更新は1箇所でもしくじると全体が切り戻しに
なるというリスクがあったので、新たに取り込むお客さんの環境の把握には
時間をかけた。

こういう方針のお陰で、運用テストの設計の際には、テスト項目の漏れを
指摘することができ、運用テストを十分に行ったという自負があったのだが、
プロジェクト側からすると本番移行後はじめてとなる仕様の通信が見つかり、
その通信ができないという問題が発生した。

問題が発覚した後、お客さん側でお客さんお抱えのベンダと共に2日かけて
代替手段を講じて事なきを得たが、2日にわたりその業務ができなかった。

お客さん側も、通信できなかった部分については、問題ないだろうと判断し
運用テストしなかったようである。

インフラの更新で、お客さんの業務システムの細部に至るまでプロジェクト
側で把握し切るというのも、工数がかかって難しいが、こういった漏れを
検出する手段を考えておくのが、このプロジェクトのクロージング時までに
まとめておきたい課題である。

最後まで読んで頂きありがとうございます。こちらを押していただけると嬉しいです!!
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
にほんブログ村 オヤジ日記ブログへ
[ 2017年01月14日 04:07 ] 情報システム | TB(-) | CM(0)

ITインフラ系のテストでの教訓 その2

メインフレームの更新の際に得ることができた2つ目の教訓は、

「テスト環境と本番環境で、本当にIPアドレスしか違わないという場合で
 も注意が必要」

ということである。

今回のメインフレーム更新では、新しいお客さんであるA社のメインフレーム
を、私の会社で管理しているメインフレームに統合した。
A社にとっては、メインフレームが自分のセグメントから、データセンタに移る
のでIPアドレスを変えることになる。

メインフレームの環境は私の会社で管理しているだけで11環境あり、そこに
新たに取り込む3社の環境が追加されるのが今回のプロジェクトのスコープだった。

私の会社のメインフレームも、A社のメインフレームも同じネットワークセグメン
トに置かなければならないという制約から、A社のメインフレームのIPアドレスは、
テスト環境と本番環境で変えなければならなかった。


仮に、それぞれのIPアドレスが以下として、
①メインフレームの本番環境: 192.168.0.1
②メインフレームのテスト環境: 10.10.0.1
③通信先のサーバ      : 192.200.0.1

テストのときには②と③の通信がうまく行っていたのだが、本番切り替え後、
①と③の通信がうまく行かなかったのである。

そもそも、pingが通らないのである。

調査の結果、A社では基幹系とは別に個別管理で192.168/16を使用している
セグメントがあり、③のサーバが置いているセグメントから見ると192.168/16
は個別管理のセグメントにルーティングされていたのである。

このため、②のサーバから③のpingが通らなかった。

テストのときには、メインフレームのIPアドレスが10.10/16だったので、問題
なく通信ができていたのだった。

結局、A社の個別セグメントのネットワーク担当者にNATしてもらい、無事通信
ができるようになったが、無事故を狙っていただけに残念だった。

最後まで読んで頂きありがとうございます。こちらを押していただけると嬉しいです!!
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
にほんブログ村 オヤジ日記ブログへ
[ 2017年01月13日 04:24 ] 情報システム | TB(-) | CM(0)

ITインフラ系のテストでの教訓 その1

昨年末にメインフレームの更新をした。

運用テストを万全に行ったつもりだったが、移行時に1つ冷や汗をかく場面が
あり、移行後の本稼働時に2つ別の問題が発覚した。

3つとも、メインフレーム自体の問題というより、運用テストのやり方の問題と
いうか限界により起きたものである。

今日は、そのうちの1つである移行時に冷や汗をかいた場面について書いて
みたい。

ここで得た教訓は
「テストの際、やむを得ずテスト環境を使う場合、テスト環境と本番環境の
 差を精査しておく」
というものである。

業務系のアプリの場合、データベースやアプリケーションサーバなどのソフ
ト的な部分を本番環境とテスト環境で同じ状態にしておくことは比較的簡単だし、
当たり前のように実施することである。
インフラ系の場合、更新対象のインフラは本稼働前にテスト環境として使用する
ものだが、更新対象のインフラと連携する先の環境の用意については、連携先の
管理者にお任せになることが多い。

移行時に起きた現象は、メインフレームと他のサーバとのデータ通信を中継
するサーバ(以降中継サーバ)の間の通信で起きた問題である。


中継サーバというのは、いろんなサーバ系の通信のHUBの役割を担うサーバ
である。
データを連携するサーバの数が膨大になると、サーバ間の連携は中継サーバ
をかますのが一般的である。
そうしないと、1つのサーバの定義の変更をした場合、それに関連するすべて
のサーバの定義を直さなければならない。中継サーバを間に入れておくと、
変更のあるサーバと中継サーバの2つだけの定義を変えれば良い。


中継サーバはそんな役割のサーバなので、なかなか停止するのが難しく、
運用テストのときには、新しいメインフレームとの通信テストは中継サーバの
テスト環境との間で行った。

機能テストで問題がなければ、技術的に問題ないはずだという判断からで
ある。

今回の場合、運用テスト時には、新しいメインフレームと中継サーバのテスト
環境との通信がうまく行っていたのだが、本番移行時に、新しいメインフレーム
と中継サーバの本番環境との通信がうまく行かないというトラブルが起きた。

原因が全くわからない。

中継サーバの担当者に聞いてみても、中継サーバの本番環境とテスト
環境との違いはIPアドレスぐらいだという。

こういう状況の場合、原因を突き止めるのに苦労する。

中継サーバの本番機と、更新前のメインフレームとの通信は問題なく行え
ていたので、メインフレームを新しくしたことが原因なのは明らかなのだが、
メインフレーム側から見ても運用テストで中継サーバのテスト環境との通信
がうまく行っているので、双方の担当者はお互いに相手側の問題であるとい
う気持ちで調査を始めたわけである。

移行作業は朝8時から実施しており、12時になっても原因がわからない状態
だった。
各拠点から他の移行チェック項目がOKの報告が続々と入ってくる中、問題は
この中継サーバの問題解決待ちとなってきた。

幾つかの拠点では、移行テストが終わる拠点もででていたが、なかなか、
原因がわからない。

ようやく14時頃になり、中継サーバのサポートに問い合わせていた今回の
現象についての回答が返ってきた。

中継サーバで管理しているメインフレームのホスト名が英小文字なのに対し、
メインフレームから返ってくる通信制御に関する自分自身のホスト名が英
大文字になっていたため、中継サーバ側でホスト名のアンマッチにより通信
ができなかっただけであった。

メインフレーム側はもともとホスト名を英大文字しか使えないのだが、
メインフレームと中継サーバの間を取り持っている通信制御サーバが、
中継サーバの定義内容にあわせて英大文字を英小文字に変換してくれていた
のだが、今回の更新で通信制御サーバの仕様が変わり、中継サーバの内容を
参照するという親切機能がなくなったことが原因だとわかった。

また、中継サーバで定義しているメインフレームのホスト名は英小文字にして
いたのに対し、中継サーバのテスト環境で定義しているメインフレームのホスト
名が英大文字になっていたため、運用テストではこの問題が発覚しなかった
のである。

問題は、この通信制御サーバの非互換が把握できていなかったところによるも
のが大きい。
ただ、これはベンダからの情報がなければプロジェクト側としては防ぎようが
ない話である。
プロジェクト側の問題としては、中継サーバ側の本番環境とテスト環境で、
メインフレームのホスト名に差異があったことになかなか気づけなかったとい
うところが問題であった。

振り返ってみると、運用テストの前に中継サーバの担当が、中継サーバの本番
環境とテスト環境は全く同じだからと言われ鵜呑みにしたことが問題である。

テストの際には、テスト環境と本番環境の違いが何なのかもっと精査すること
という教訓を得ることができた。

最後まで読んで頂きありがとうございます。こちらを押していただけると嬉しいです!!
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
にほんブログ村 オヤジ日記ブログへ
[ 2017年01月12日 04:39 ] 情報システム | TB(-) | CM(0)

スマホ用サイトのアホなデザイン

どのサービスとは言わないが、私のブログの右上にあるサイトのモバイル版
であるが、スマホで見るとスマホ用の画面が立ち上がるようになっている。

そのスマホのデザインは


-------------------------
ヘッダ部
-------------------------
本文

-------------------------
フッタ部
-------------------------

という一般的なデザインになっている。

ここまでなら、普通の設計である。

また、このサイトは本文の部分を下までスクロールすると次のページが
自動で表示されるようになっている。

これについても問題ない。

アホな設計なのは、フッタ部にリンクが有るため、本文の部分を下まで
スクロールすると2ページ目の本文が出てくるので、何ページもデータを
登録している場合、したにスクロールしても次のページが出てきてしまい、
何回やってもフッタ部にたどり着けないのである。

多分、このソフトは製作者が作った後、テストとかが不十分なのだろう。

あと、最近、PC版のデザインを変えて、サイトが重くなりすぎて、元に戻し
たということもあった。


サイト的には気に入っているのだが、運営の姿勢がアホすぎて、スマホ
でこのサイトを使うたびにムカムカしている。

タダなのだから我慢して使えよ。という人がいるかもしれない。

こちらも、書評を書いており、広告収入に貢献しているのだから、言うこ
とは言わしてもらいたい。

ちなみに、不具合報告をしたところ、無視であった。

最後まで読んで頂きありがとうございます。こちらを押していただけると嬉しいです!!
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
にほんブログ村 オヤジ日記ブログへ
[ 2016年11月27日 04:11 ] 情報システム | TB(-) | CM(0)

Google vs トヨタ

ITを代表する企業Googleと、自動車を代表する企業トヨタ。

何の関連もない巨大企業同士が「自動運転車」の分野で競争が始まっている
という。

グーグルは「自動運転車」を取り扱う「Google X」というプロジェクトを進めながら、
新しい都市のかたちを狙っているという。

「自動運転車」は、実用レベルまで来てはいる。

「自動運転車」が人を轢き殺してしまったら誰の責任になるのか?
という解が出ないと、なかなか結論が出ないような気が個人的にはするが、
仮にぶつからない車ができてしまったら、免許はいらなくなるだろうし、
タクシーやバスの運転手、トラックの運転手、自動車保険業界が廃業に
追い込まれ、鉄道の代わりになるほど便利になるだろう。

あと、2つ面白い話があった。

1つは、Googleは主力事業である広告事業の利益率が良すぎて、他の事業
に投資しようとすると利益率を落とすのかと株主が黙っておらず、なかなか
他の分野に手が伸ばせない状況であるという話がもっと興味深かった。

もう1つは、事業領域における既存プレイヤーの倒し方の話。
新規プレイヤーはバリューチェーン(原材料調達から製品が顧客に届くまでの
企業活動)ををバラバラにすることがセオリーだという。

自動車は、部品点数も3万ぐらいありこのバリューチェーンが長いため、
他のプレイヤーが参入できないが、電気自動車になると部品点数が1万程度
になり、部品やそれを作る生産設備の会社との関係も既存のガソリンエンジン
を前提とするものより構築しやすくなり、このバリューチェーンが壊しやすくな
るという。

こうやって、ソニーやPanasonicは、GoogleやGoogleを担いだサムスン、Apple
にやられてしまったとのことである。





最後まで読んで頂きありがとうございます。こちらを押していただけると嬉しいです!!
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
にほんブログ村 オヤジ日記ブログへ
[ 2016年11月14日 04:56 ] 情報システム | TB(-) | CM(0)

FTPとNAT

現在、大型インフラ(汎用機)の更新で運用テストの最中であるが、
とある客先の業務でFTP通信がうまくいかない事例が発生した。
(FTPと言っても汎用機用にちょっとアレンジしたプロトコルである)

その業務は、データセンタの汎用機から客先サーバからに対してFTPで接続
しに行くというものであり、途中にNAT変換がある。

客先の汎用機を、データセンタの汎用機に統合するわけであるが、IPアドレス
は現在のものを使いたいというため、DIST-NATをしているのである。

PINGは通り、TRACERTコマンドで経路を調べても問題ないのに、なぜかFTP接続
はうまく行かなかったのである。

PING ok、TRACERT okということで、TCP/IP的には正しいので、自社のNW担当は
他の業務で忙しいこともあり、汎用機側か客先のNWが悪いのではないかと取り
合ってはくれなかった。

どこかがおかしいから、つながらないわけなので、仕方なく、1個、1個、
自分で原因を確認して、自社のNW担当に細かく質問して対応してもらうことにした。

経路上にファイアウォールがあるため、自社のNW担当に確認して見たところ、
・客先サーバ→汎用機の通信は必要なポートのみ通す
・汎用機→客先サーバの通信はポートの制限をかけない
というありふれた設定であり、特に問題になるようなものではなかった。

FTPについていろいろ調べていく中で、FTPとうプロトコルは
・制御用のコネクション
・データ転送用のコネクション
の2つのコネクションがあり、例えばAサーバとBサーバがあったとすると、

A→(制御コネクション) →B
A←(データコネクション)←B
というつなぎ方をするアクティブモードと

A→(制御コネクション) →B
A→(データコネクション)→B
というつなぎ方をするパッシブモード

があることがわかった。

そのことを、自社のNW担当に告げると、データコネクションの向きが一方向
だと思っていたので、NATは片方向にしかしていなかったというのである。

その後、双方向NATの定義を入れてみたが全く現象は変わらなかった。

その後、パッシブモードでつなげれば解決するのかと思ったりもしたが、
汎用機側がパッシブモードに対応していなかったりと、試行錯誤が2週間続いた。

結局、汎用機側のトレースについて製品のサポートデスクからの回答の結果、
・汎用機のFTPの相手ポートは21番ポートではなく、9000番台のポートを
使っていること
・FTPというプロトコルでは、データコネクションを張る際の相手先IPアドレ
 スを決めるのは、IPヘッダのIPアドレスではなくペイロード部にあるIPアド
レスであること。
・NATルータでは宛先ポートがFTPの21番ポートの場合、IPヘッダだけではなく
 ペイロード部のIPアドレスも自動で書き換えてくれるが、9000番台はFTPと
 は判断しないので、ペイロード変換はしない。
 ペイロード部のIPアドレスを自動で書き換えるためには、明示的に設定を
 追加しなければならない

ということがわかり、試してみるとすんなりうまく行った。

結局、このことがわかるまで3週間かかったが、運用テストでこの問題が
解決できてよかった。

これも、去年、一昨年とネスペの勉強をしていたおかげである。

最後まで読んで頂きありがとうございます。こちらを押していただけると嬉しいです!!
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
にほんブログ村 オヤジ日記ブログへ
[ 2016年10月25日 04:17 ] 情報システム | TB(-) | CM(0)
カテゴリ

openclose

プロフィール

旅好きおやじの日記

Author:旅好きおやじの日記
職業はIT関係です。
趣味は海外旅行(21カ国制覇)、読書、資格取得です。
取得した資格は以下のとおりで、半分趣味のようになってます。
情報処理(ITストラテジスト,システム監査,プロジェクトマネージャ,アプリケーションエンジニア,テクニカルエンジニア(システム管理),テクニカルエンジニア(データベース),ネットワークスペシャリスト,セキュリティアドミニストレータ,1種,2種)、元PMP、ITIL V3 Foundation、Oracle Master Gold、日商簿記1級、建設業経理士1級、英検2級

カレンダー
プルダウン 降順 昇順 年別

03月 | 2017年04月 | 05月
- - - - - - 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 - - - - - -



ブクログ
楽天
アクセスランキング
[ジャンルランキング]
日記
937位
アクセスランキングを見る>>

[サブジャンルランキング]
会社員・OL
191位
アクセスランキングを見る>>
おやじ日記ランキング
検索フォーム
人気ブログランキング
ブロとも申請フォーム