べひぶろぐ

しがらみある見積もり

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

　

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

　

　　

　　　

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

　

　

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

　

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

　

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

　

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

　

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

　

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

　

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

　

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

引継ぎ案件

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

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

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

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

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

感情に走ったメール

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

　

　

・・・おもしれぇ～っ！ｗ

　

　

しかも、、

　

　

頭悪そうーっ！ｗ

　

　

　

　

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

DBを連携したシステムの開発着手
↓
フェーズは結合試験なのに、DB連携部分はスケジュール遅延（客先都合）
↓
一か月遅れるも、やっと結合試験開始
↓
早々にエラー報告あり
↓
曰く、「弊社のシステムは0(ゼロ)とNULLを区別しません。御社は勉強不足なので、しっかり対応してください。」

　

　

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

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

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

やっと終わった‥

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

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

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

本日の打ち合わせ

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

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

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

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

発注後になって

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

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

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

無事納品

あんだけスケジュール厳しいって思ってたけど、割と順調に進んだなぁ。逆に見積もりが甘かったと評価されそう。。徹底的にリスクを排除した結果なんだけどね。

さて、並行して動いている他の案件も頑張らねば‥。（頭を切り替えるのが１番難しい）

一般的なペーストビンって

最近、Google先生で検索の上位にヒットするので目につく「一般的なペーストビン」

内容を見ても、ソースやログの切れ端で、見てもよくわからん。。

どうやら、クリップボードに張り付けた内容をWeb上で共有するサービスらしく、トラブル出先でWebは使えるがメールは使えないけどログの一部を送りたい、、なんて場合に使うWebサービス？

しかし、第三者には有益な情報・・・ではないですよねぇ。。。

最初、ペース＋トビンと思ってた・・・

話が進まない

今やってる仕事は3社くらい跨がる仕事なんですが、外注さんの窓口な人が非技術系の人で、事あるごとに「技術側に確認しますんで」で話が進まぬ‥。

いやいや、技術の担当さんを出してよぅ。こっちでディレクションしますからー。

うーむ、どうやら発注先のさらに外注さんのようで、こちら側からはコントロールできん。。

さて、どうしたものやら‥。