2018年10月
  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 31      
フォト

つぶやきTwitter

無料ブログはココログ

仕事

2016年6月27日 (月)

平成28年度 春期 情報セキュリティスペシャリスト試験 合格しました

【... 合否と点 ...】 合格 午前I 85.00点、午前II 72.00点、午後I 70点、午後II 66点
【....受験回数....】 4回
【....勉強期間....】 1ヶ月
【....年齢性別....】 37歳 男
【 職業or学生 】 自称PM
【IP/FEの所持】 FE/AP
【.使用テキスト】
● Webサイト(情報セキュリティスペシャリストドットコム)
● IPA過去問(直近過去3回分)
【 感想を一言 】
今回、4度目の受験でようやく合格。これまでは問題の読み違えによるケアレスミスで5~6点を失い、50点台で苦渋を味わうことが過去3回。つくづく、国語力・日本語力を試される試験だなぁと思いました。

続きを読む "平成28年度 春期 情報セキュリティスペシャリスト試験 合格しました" »

2014年9月 6日 (土)

プロジェクトマネジメント・プロフェッショナル(PMP)合格しました

【受 験 日】2014/06/07
【合  否】合格
【受験科目】PMP
【受験言語】英語+日本語
【出題形式】リスト選択(4択)
【試験時間】4時間
【勉強期間】70時間(2ヶ月)
【受験目的】自分のスキルアップ
【勉強形態】独学
【実務経験】あり

 

◆ 正解率

立上げ:平均以上
計画:平均程度
実行:平均以下
監視・コントロール:平均程度
終結:平均以下

結構、ギリギリ…

 

◆ 取得までの費用(あくまでも私の場合です)

  • PMI入会費 10ドル(約1,000円)
  • PMI本部年会費 129ドル(約12,900円)
  • PMI日本支部年会費 50ドル(約5,000円)
  • 35時間の公式なプロジェクトマネジメントの研修の受講 (30,000円)
  • PMP試験受験費 405ドル(40,500円)
  • eラーニング (4,000円)
  • PMP再試験受験費 275ドル(27,500円)1回落ちたので

合計 120,900円(けっこう掛かったなぁ…)

続きを読む "プロジェクトマネジメント・プロフェッショナル(PMP)合格しました" »

2013年9月20日 (金)

プロジェクトマネジメント・スペシャリスト(PMS)合格しました

合格率は約50%。

【 実務経験 】 だいたい5年くらい
【試験番号】 平成25年度第1回プロジェクトマネジメント・スペシャリスト(PMS)資格試験
【 正解数 】 7割くらい?
【受験回数】 1回
【勉強期間】 約2ヶ月間

続きを読む "プロジェクトマネジメント・スペシャリスト(PMS)合格しました" »

2009年3月 9日 (月)

しがらみある見積もり

システム屋にとって見積もり作成はツライお仕事。。

 

この前も得意先と見積もりの内容についての打ち合わせに行ってきたのですが、

 

  

   

開口一番に「去年の改修時と比べて高い!」

 

 

『この機能を実現するとなると、こういったリスクもありますし、実装を行い試験もする必要もありますよ』

 

「その試験とは別項目にある統合テストに含まれるのでは?」

 

『いや統合テストとはシステム全体に対するテストです。一つの機能に対するテストては異なります』

 

「仮にこの機能を見積もりから外した場合は、設計やテストからも減額されますよね?」

 

『増えることはありませんが、一概に減るとも申し上げられません。』

 

とまぁ納得はしてないが理解はした印象。これで充分。押し問答にこれ以上時間を費やすのもバカげているし。

 

最近の不況にこじつけて、手を変え品を変え発注額を下げようとしてくる。

 

倒産しちゃった得意先もいるが、それは本業の経営に問題があったためで、うちが問題ではないと思ふ。

2008年12月18日 (木)

引継ぎ案件

プロジェクトを立ち上げる前に、まず顧客と要件をある程度聞き出し、システム化すべき部分について工数を算出し、スケジュールを算出し、コストを見積るのですが、たまに経験と勘で出してしまう輩がおります。

しかも、顧客から聞き出した要件について「検討します」と言ったっきり曖昧なまま見積もりを提示。(それに対してGOを出した方も悪いが)その後、受注決定。

開発着手後にあいまいな要件を残していることが引継ぎして発覚。顧客はてっきりやってるものだと思っているらしく、当事者は退社してしまっており今更になって見積りの想定に無いという辻褄合わせに四苦八苦しております。。

やっぱ、要件定義は大切です

今日も終電。しかも寝過してひと駅乗り過ごした。。。

2008年10月10日 (金)

感情に走ったメール

得意先から自分たちの非を認めず論理性を欠いた主張を書き立てたメールがCCで飛び込んできた・・・。

 

 

・・・おもしれぇ~っ!w

 

 

しかも、、

 

 

頭悪そうーっ!w

 

 

 

 

そのイミフな主張を簡単にまとめると、、

DBを連携したシステムの開発着手

フェーズは結合試験なのに、DB連携部分はスケジュール遅延(客先都合)

一か月遅れるも、やっと結合試験開始

早々にエラー報告あり

曰く、「弊社のシステムは0(ゼロ)とNULLを区別しません。御社は勉強不足なので、しっかり対応してください。」

 

 

・・・(゚Д゚ )ハァ?? いまさら自己中な仕様をほざくなw 買い叩きだとしたら、コイツは法律を知らんのか?しかし、、そんなわけのわからないシステムと結合して大丈夫なのか・・・(笑)

2008年7月15日 (火)

【今更】ケータイの匿名性【あるあ…ねーよw】

2008年6月8日、秋葉原通り魔事件の容疑者は、携帯サイトに犯罪予告を書き込みしていたとの報道があった。また、類似の事例として、犯罪予告だけで容疑者が特定され逮捕に至った、という報道を最近よく耳にすることが多い。

PCからの書き込みより個人を特定する方法として、以下の方法がある。
IPアドレスの特定⇒アクセス元IPアドレスとの時刻情報(ISPに開示要求)⇒契約者

しかし、携帯の場合は、携帯会社のゲートウェイを介してインターネットに接続するため、上記の方法は有効な手段となりえない。このゲートウェイがproxyの役割となるため、IPアドレスが特定できたとしても、契約者に至るのが難しいからだ。
(IPアドレスは都度変更され、紐付ける情報が時刻情報のみとなるため)

実は、携帯電話番号(SIMカード)ごとに一つ付与されるユニークなID(契約者固有ID)が振られている。そして、それがWEBにアクセスするたびに、キャリア公式・非公式を問わずWEBサーバに送信されている。

つまり、これはWEBアクセス履歴と携帯端末と契約者の3者の紐付けを可能にする。これがケータイにおける、契約者特定のカラクリである。
※ PCの場合は、PCと使用者には「契約」という概念が無い。

 

以下、主要4キャリアについて、契約者固有ID(キャリアによって呼称が異なる)の取得方法とそのソース元URL。また、このIDはナンバーポータビリティや、SIMカードの再発行を伴う電番の変更を行うことで変更できるが、ユーザー任意による変更は基本的に不可能。

■ docomo(iモードID)
1. リンクのURLの最後に「?guid=ON」というパラメータをつけます。
2. HTTPリクエストヘッダの X-DCMGUID に7桁の識別番号が入っています。

http://www.nttdocomo.co.jp/service/imode/make/content/ip/#imodeid

■ au(EZ番号)
HTTPリクエストヘッダの HTTP_X_UP_SUBNO に含まれています。
http://www.au.kddi.com/ezfactory/tec/spec/4_4.html

■ Softbank, J-PHONE, Vodafone(端末シリアル番号)
ユーザーエージェントに含まれています。
http://developers.softbankmobile.co.jp/dp/tool_dl/web/useragent.php

■ イーモバイル(ユーザID)
HTTPリクエストヘッダの x-em-uid に含まれています。
http://developer.emnet.ne.jp/useragent.html

2008年7月 2日 (水)

やっと終わった‥

本日のメイン案件のリリースを持って、これで今週のリリースラッシュは終わり。大きなトラブルも無く、無事乗り切ったな〜。これで○百万かと思うと、少々高い気もするけど‥(^_^;)

まぁ当初の想定スケジュールを約一ヶ月も短縮したんだからいいよね(笑)あとは次期リリースに向けての残務整理っと。

ってか、このプロジェクトは打ち上げないの?(-_-;)→外注さんとの打ち上げは原則しちゃだめらしい。

2008年6月26日 (木)

本日の打ち合わせ

本日はアプリ開発をお願いするパートナー会社さんとの打ち合わせ。主に仕様とスケジュールの確認。

後々の追加要件や仕様変更を想定し、基本方針の認識だけを合わせるため、この場ではあえて詳細な仕様は詰めず、概要レベルでの確認とリスクの洗い出しに留める。

やはりスケジュールが議題の中心。こちらから提示したスケジュールと各マイルストーンで何をどこまで出来るかを再確認する。

実績もあるので(今のところ)問題はなさそうかな。。

2008年6月25日 (水)

発注後になって

「これはできませんでした」なんてキタネェ!

ったく、何のための見積もりだよ。。まぁ、その分ちゃんと穴埋めしてもらうからいいけど‥。

やりたいようにしてあげたいけど、内輪で仕事してるわけではなく、リミットとリソースにリスクが伴うわけで。。

より以前の記事一覧