インターネットは終わった？ - novtan別館
１．真っ当なサービスを装った(実際にサービス自体はちゃんとやる)、個人情報登録必須サイトを作る ２．架空請求用釣りサイトを作成する ３．架空請求サイトにアクセスしてきたユーザーを１のデータで同定し、請求 とか出来るよね。まあ、これまでだって「送信しますか／はい」で同じことになったんだろうけど、あからさまに怪しいサイトに送信しないよね。デフォルトで送信するのってのはそういうことだ。 ユーザの希望で契約者固有IDを変更することができるかどうか、各社のサポートセンターに問い合わせてみたところ、au以外は基本的に変更できないとの回答だった。 NTTドコモ iモードIDは「基本的にお客様にずっと通して使って頂くもの」とのことで、ID変更手続きは存在しない。ただし、電話番号の変更手続きをするとiモードIDも変更されるとのこと。 KDDI au EZwebサービスの利用を「廃止」して、同サービスの「再追
開発生産性が低い方が収入が多いって変だよね - ひがやすを技術ブログ
開発生産性が低い方が収入が多い（人月がかかるほどお金がとれる）というビジネスモデルを根底から覆す可能性があります。開発生産性をあげればあげるほど収入が減ってきます。SIビジネスが立ち行かなくなる方向に向かうのです。 実際の現場では、開発生産性が低くて、人月がかかるほうが売上が増えるというのは、紛れもない事実です。大手SIerの開発手法が、生産性よりも失敗しないことを重視するのは、この事実が原因なのは間違いありません。失敗せずに多くの工数をかけたほうが売上が増えるのです。 だから、ソースコードと一対一に対応するような無駄なドキュメントを「誰が書いても同じようなソースコードにするため」なんて理由で書かせるのです。 詳しくは「誰が書いても同じコード」は大事なことなのかのエントリを参照してください。 営業は、売上で評価されることが多いので、営業の力が強いところは、売上至上主義に走りがちです。でも、
[製造/テスト編]任せすぎてはいけない
プロジェクトマネジメントを実行するに当たっては，各種の会議体（プロジェクト会議，進捗会議，リーダー会議など）が決められ，それらを通してプロジェクトの進捗や問題の把握，問題点の対策及びフォローが実行される。このようなプロジェクト管理制度は，会社や組織で定義されている場合が多い。にもかかわらず，現実は「プロジェクト管理ができていない」「実行されているにもかかわらずプロジェクトが混乱した」といったケースが後を絶たない。なぜ，このような状況に陥ってしまうのか？ プロジェクト・マネージャ（PM）が，各工程の進捗や問題点，リスクを正しく把握できていなかったり，問題やリスクは把握していたにもかかわらず，真の問題点や原因を追求できずに適切な対策が打てなかったりするなど原因はそれぞれある。一番まずいのは「リーダーやメンバーがきちんとやってくれると思っていた」という言い訳である。PMとしては言えるものではない
![[製造/テスト編]任せすぎてはいけない](https://cdn-ak-scissors.b.st-hatena.com/image/square/bed39b5962a5d552c95b6d796db8f55e72d32943/height=288;version=1;width=512/https%3A%2F%2Fxtech.nikkei.com%2Fimages%2Fn%2Fxtech%2F2020%2Fogp_nikkeixtech_hexagon.jpg%3F20220512)
第4回 「クリティカルな業務」のBCPを考える
山本 直樹 ベリングポイント テクノロジーソリューションチーム シニア マネージャー 前回は、BCP（事業継続計画）を発動する際の指令塔である「コマンドセンター」の役割について解説した。今回は各部署に求められるBCPの内容やレベル、果たすべき役割などについて考える。 まず前半では、BCPの策定を効率的に進めるために「クリティカルな業務」を明確にすることを提言する。後半では、昨今のBCM（事業継続マネジメント）において、情報システム部門に求められる新しい役割について解説する。 「クリティカルな業務」を識別する BCMは、事業を滞りなく継続するための活動である。したがって、企業の事業活動を支えるすべての部署がBCMの対象となる。しかし、仮に企業内のすべての業務が一斉に中断したとしても、それらすべての業務を、同じ緊急性で復旧させる必要はない。 では、どのような業務を優先的に復旧させるべきなのだろ
システム開発をめぐる法律問題（1）紛争に発展しやすいオーダーメイドのシステム開発
今回から，システム開発時に発生する法律問題を網羅的に取り上げます。 システム開発時に発生する法律問題は，決して目新しいものではありません。しかし，日本IBMとスルガ銀行との間で今春裁判に発展した紛争に代表されるように，ITベンダー企業とユーザー企業の間でもっとも頻繁に発生する紛争類型の一つであることは間違いありません（関連記事1，関連記事2）。 システム開発は後述するように契約の締結段階から，非常にトラブルが発生しやすい類型の契約です。契約を無事締結できたとしても，検収段階でユーザーが満足するようなシステムを円滑に納品することは非常に困難です。今回からは，システムの発注者となるユーザーと請負人となるベンダーの攻防を，契約の締結段階から網羅的に概観します。その上で，システム開発委託契約において問題となる個々の争点について検討し，システム開発委託契約をめぐる紛争の予防，紛争となってしまった場合
プログラミングファーストでもまだ中途半端 (mark-wada blog)
ひがやすをｂlogで「プログラミングファースト開発の必要性」が書かれている。このひがさんのプログラミングファーストは以前あるセミナーでプレゼンを直接聞いたことがあるのでだいたいの考え方や内容も理解しているが、ぼくの感想はまだ中途半端のような気がする。まずはそのブログから。 プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法。ドキュメントは仕様が固まった後に書く。 プロトタイプ開発との違いは、最初に作ったものを捨てずに、本番で動かすものとして開発し続けること。アジャイルとの違いは、全工程をテレーション（筆者注：イテレーション？）でまわすのではなく、顧客と仕様をつめるところのみを何度も繰り返し仕様が固まるまで行なうこと。 これは、現在のような人月ビジネス化し
onkはギリギリ霊長類
Σ（´Д｀ｽﾞｶﾞｰﾝとりあえず第 2 部の雑感。 心に響いたのは以下の 2 点。 なぜ IT 業界に入ったのか。 土日出れることがうらやましいと思うときもある。 「なぜIT業界に入ったのか？」 大学に居た 3 年間，平均すると 1 日 5 時間ぐらいは web に触れていたはず。5*365*3=5,475。低く見積もっても 5,000 時間ぐらいは費やしていたわけで。このコミットを無駄にしたくない気持ちが，この業界に飛び込むキッカケかなぁ。 少なくとも同期の中では負けない自信があったし，150 人の中で 1 番になれるならプロとしてやってくことも出来るんじゃないかと考えた，と思う。まぁ「気づいたら居た」というのがリアルなところだけど。 この業界に入るにあたっての敷居の高さについては，十年泥が話題になった頃から疑問に思っていたんだよねー。業界自体に魅力を感じなくなってる人を無理に引き止める
ECMAScript for XML (E4X) 仕様邦訳
この文書は ECMA-357 ECMAScript for XML (E4X) Specification 2nd edition を訳者 (nanto_vi) が私的に訳したものであり、Ecma International またはその他の関連団体・個人とは一切関係ありません。 この文書は正規の仕様ではありません。正規の仕様に関しては Ecma International から PDF で公開されています。 翻訳の内容については保障しません。この文書の利用によって発生したいかなる損害についても訳者は責任を負いません。 翻訳上の誤りなどがあれば訳者 (ブログまたはメール <nanto (at) moon.email.ne.jp>) までご連絡ください。 Standard ECMA-357 2nd Edition / December 2005 序文 2002 年 6 月 13 日、BEA S
Windowsを傷付けずにUSBからLinuxをブートせよ！（1/3） − ＠IT MONOist
組み込みソフトウェア／ハードウェア開発における技術力の向上、改善・最適化などを幅広く支援する“組み込み開発エキスパート”のための情報フォーラム
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
