2005年06月24日(金) << 前の日記 | 次の日記 >>
これまでの06月24日 編集

■1 NTT、ミゾのないネジが回せるドライバーを開発[http://www.asahi.com/digital/nikkanko/NKK200506030004.html]次の記事 >> このエントリーをはてなブックマークに追加

どういう仕組みかと思ったのですが、
開発したドライバーの素材には電圧の大きさによって膨らんだり縮んだりする特殊なセラミックスを使用した。この膨張する動きを回転運動に変える。ドライバーの回転体は平らなネジの頭に接触すると、摩擦を利用して引っかくことでネジが回る。ネジ自体は特殊な材質を用いていない。回る強さは押しつける力に比例する。
圧電モーターと似ている原理ですね。面白い。

■ 関連記事

■2 三菱電機、Winnyによる発電所情報の漏洩事件について会見[http://internet.watch.impress.co.jp/cda/news/2005/06/23/8134.html][セキュリティ]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

ニュースリリース[http://www.mitsubishielectric.co.jp/news/2005/0623.htm] (pdf)[http://www.mitsubishielectric.co.jp/news-data/2005/pdf/0623.pdf]
社員が情報をHDDに入れて持ち出した点については、「規則ではデータの社外への持ち出しは原則禁止としており、社外に持ち出す場合には上司の許可が必要となっていたが、こうしたルールの徹底が欠けていた」と述べた。
というルールが徹底できるのならば、
「データの暗号化や社外への持ち出しを防ぐ技術や製品などを三菱電機でも開発しているが、社内で使用されていなかった点について反省し、こうした技術の採用も含めて管理を徹底してきたい」
という製品は存在意義が無いのでは無いか。「ウチだけは大丈夫」意識が引き起こした事故と言えよう。

Winnyで原子力発電所の内部情報が流出[http://internet.watch.impress.co.jp/cda/news/2005/06/23/8124.html]:

Winnyを業務に使用した例としては、 秋田県湯沢市[http://www.nantoka.com/~kei/diary/?200504b&to=200504151#T200504151] のケースが有名だが、
同社広報によると「実際にWinnyをインストールし、指摘されたものと思われるデータをダウンロードした。現在は、MPE社員のPCに保存されていたデータと、Winnyからダウンロードしたデータを照合しているところだ」という。
こちらは、確かに業務で使う必要が認められそうだ。

ファイル交換ソフト使用上の注意事項について[http://www.ipa.go.jp/about/press/20050623-2.html]:

ということで、IPAから ファイル交換ソフト使用上の注意事項[http://www.ipa.go.jp/security/topics/20050623_exchange.html] が発表されています。 (プレスリリース)[http://www.ipa.go.jp/about/press/pdf/050623Press2.pdf]
恐らくですが、99%以上の職場では一般ユーザーがファイル交換ソフトをインストールする必要は無いはずなのですが、意外と入っているものの様です。漏洩事件が発生して大きく報道されるケースがこれだけあることを考えると、根拠無く「ウチは大丈夫」と考えるのには無理があります。
ネットワーク管理者がトラフィックを継続的にモニターしていれば、気づくことなのでしょうが、勤務時間外にセットして帰る様なユーザーもいたりするので注意です。

■ 関連記事

■3 新手法「Ajax」登場を機に見直し迫られるWebの操作性[http://itpro.nikkeibp.co.jp/free/NC/TOKU2/20050621/1/][Ajax]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

本誌で先に読んだ。日経コンピュータの様な比較的一般向けの雑誌で特集が組まれた事が興味深い。
全体としてリッチクライアントはまだ普及しているとは言いがたい。野村総合研究所が、無作為抽出した2000社を対象に昨年実施した調査(有効回答数は 275社)によれば、企業システムのクライアントのうち、リッチクライアントの割合は14.4%。HTMLクライアント(Webアプリケーションのクライアント、30.5%)やファット・クライアント(C/S型システムのクライアント、39.4%)の半分以下だ。
新手法「Ajax」登場を機に見直し迫られるWebの操作性, 『日経コンピュータ』, 日経BP社, 2005年6月27日, pp.64.
の理由として、
リッチクライアント製品の機能がまだ不十分、ベンダー依存にならざるを得ない、ライセンス料金が発生するといった点が挙げられる。だが、大きいのは「Webアプリケーションの使い勝手に対する問題意識を持つ企業が少ないからだ」と、カールの古賀実 取締役は指摘する。
新手法「Ajax」登場を機に見直し迫られるWebの操作性, 『日経コンピュータ』, 日経BP社, 2005年6月27日, pp.64.
としているが、実はもう一つ大きい視点がある。
広く一般に利用されるためのシステムの作成にリッチクライアント製品を採用した場合、リッチクライアント製品のセキュリティ上の問題に関して責任が生じる。
リッチクライアントはWebページからインストールした時点で、通常のアプリケーションとして動作するため、利用者のローカルディスクの内容を盗み出したり、書き換えたりすることを含むあらゆる操作が可能となる。
このため、リッチクライアントの端末への導入は、
1)リッチクライアント環境そのものにセキュリティホールが存在しないこと
2)リッチクライアント上のアプリケーションの作成者に悪意がなく、信頼できること
3)リッチクライアント上のアプリケーションにセキュリティホールが存在しないこと
という条件を満たした場合にのみ安全であり、一部の製品に見られる署名やサンドボックス的なアプローチを用いても、1,3を保証することは不可能である。
何らかのサービスを提供するサイトがリッチクライアント製品で構築されたアプリケーションをインストールさせた場合、ここで導入したリッチクライアント製品あるいはリッチクライアント上のプログラムにセキュリティ上の欠陥があって、これが第三者に悪用され、利用者の個人情報が盗み出された場合、リッチクライアントを導入することを要求したサイトは、責任を追求される可能性がある。
また、リッチクライアント自体にセキュリティホール等が発見された場合、利用者がアップデートを行う必要があるが、新たなプログラムを導入したという意識が薄いこともあり、アップデート情報を把握して、アップデートすることを利用者に期待するのは難しい。
さらに、リッチクライアントの導入を要求することが一般化すると、フィッシング詐欺等の手法によって、継続的にユーザの情報を盗み出したり、特定のサイトを攻撃するDDoS攻撃に悪用される様な機能を持つ、悪意のあるプログラムを送り込む犯罪が発生する危険性がある。
これらの被害は、リッチクライアントを用いてサービスを提供しているページに留まらず、リッチクライアントが導入されている限り、常に発生しうる。
広く一般の利用者に対するサービスでのリッチクライアントの採用には、この様なセキュリティ上の問題がある。
とある提案書から抜粋, MAEDA Katsuyuki, 2005年3月31日
この様な問題を考えた時に、安全性が客観的に確信できるAjaxのアドバンテージは大きい。
一方、Ajaxの課題としては、
Ajaxは、料金がかからないという意味では敷居が低い反面、開発環境が整っていないという点では敷居が高いとも言える。
新手法「Ajax」登場を機に見直し迫られるWebの操作性, 『日経コンピュータ』, 日経BP社, 2005年6月27日, pp.67.
が挙げられるだろう。
ビジネスロジックとhtmlの他に、JavaScriptとも整合性を取りながら開発を進めるとなると、フレームワークの重要度が増してくる。
今年も半分になったけれども、「Webアプリでのフレームワークの必要性が注目される」の予言が実現しつつある。

■ 関連記事

■4 [FreeBSD-users-jp 85444] Linux との違い?(ディスク高負荷)[http://home.jp.freebsd.org/cgi-bin/thread?mesid=%3c018701c576e7%24bfb06aa0%247d03a8c0%40morimotoPC%3e][freebsd]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

ウチで運用しているサーバのほとんどは、FreeBSDを導入しているのだけれども、開発用にLinuxを使うと高負荷時の操作性が落ちる感じがあって、これはチューニングに問題があるのかなぁと思いつつ諦めて使っていたのだけれども、実際仕方がないことらしい。
この日記を動かしているサーバみたいは、mrtgでロードアベレージを見ていると一面緑色になる位、酷使されているのだけれど、こういう使い方をすると厳しそうだ。

■ 関連記事

■5 世界最速360キロ…JR東、次世代新幹線お披露目[http://www.sankei.co.jp/news/050624/sha042.htm]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

■ 関連記事

■6なぜ、進捗率が上がらないのか〜進捗が上がらないヒミツ<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

某所での話。
進捗会議の度に進捗率を報告するのだけど、1週目「80%です」、2週目「90%です」、3週目「99%です」、4週目「99.9%です」等と報告して後が無くなりつつあるという話になっていた。
プロジェクトの進捗率報告には、
  • 会議での批判を避けるために
  • 見込みや
  • 希望的観測
が織り込まれるために、こういう事態が生じていると見られているのだけれども、実は、こういった要素を取りのぞいても、「進捗率」はこうなる運命を持っている。
「とあるプロジェクト」の進捗をグラフにしたものを示す。
進捗率のグラフ
プロジェクトは、今はグラフの「期間B」の中盤位、進捗率で50%を超えたところだ。これから先の実際の進捗はもちろん誰も知らない。
「期間A」の頃は、なかなか進捗が伸びていかずに心配したけれども、最近は順調に開発は進んでいて、「期間A」での遅れも完全に取り戻した。特に問題も抱えていない。プロジェクトは順風満帆だ。
進捗会議で完成時期を訊ねられたけども、「希望的予測」によれば、納期よりもずいぶん前に完成できる様だ。もちろん少しサバは読んであるけども「納期には十分間に合います」と言うだけの余裕があった。

「おかしい、こんなハズでは」:

進捗も70%を超えた頃、どうも進捗率が伸びていかない事に気づいた。定例の進捗会議が苦痛になってくる頃だ。
1週目(今週は伸びが悪かったが仕方がないか)「80%です」
2週目(若干サバを読んで)「90%です」
3週目(納期過ぎているし、来週には取り返せるだろう)「99%です」
4週目(進んでいないとは言えない)「99.9%です」
等と報告して後が無くなってしまった。

どうしてこういうことになるのか:

そもそも、進捗率というのは線形に上がっていかないものなのだ。
このプロジェクトの進捗は、実際には波線の様に推移した。開発末期には当たり前にこういうことが起こるものなのだ。
これは、経済学では 「限界効用逓減の法則」[http://www.nikonet.or.jp/spring/sanae/MathTopic/teigen/teigen.htm] として知られている法則だけれども、開発においては、
「進捗率が100%に近づけば近づくほど、進捗率を上げるのが難しくなる。」
『進捗逓減の法則』, MAEDA Katsuyuki, 2005年6月24日
という困った現象が起こるのだ。
例えば、残っているバグが100個あるとする。もちろんこの時点で残りのバグの個数は分からないのだけれども。 そこから任意のバグ1個を取りのぞくのと、最後の1個のバグを取りのぞくのは当然、難易度が異なる。当然ながら、最後に残るものほど難物になりやすいし、それは終わってみて分かるのだ。
取っても取っても新たな敵が出てくる。百鬼夜行の箱を開けた様な感じだ。 小物を倒すと、どんどん強い敵が出現する感じ。百鬼夜行は百匹って分かっているけど、こっちは残りの数が分からない分だけ分が悪い。

一方、プロジェクトの立ち上がりは:

一方、プロジェクトの立ち上がり[期間A]においては、学習曲線があるので、なかなか進捗が上がらない現象が生じる。
この時期を過ぎると、一見順調に進捗率が上がっていくけれども[期間B]、完成に近づくと、再び進捗率の上昇は遅くなってくる[期間C]。
実は、これは当然のことだったのだ。

生産量をグラフに示すと:

この時、単位期間あたりにどれくらい進捗が増加したかを「生産量」として、これをグラフに示すと、
進捗率と生産量のグラフ
の様になる。
労働力は常に一定であるという仮定をすると、最大の生産効率だった時期と比較すると、プロジェクト末期では、数十分の一にまで生産性が低下することになる。
こんな中で、進捗が上がらないプレッシャーと闘うのは非常に辛い。 別にサボっている訳ではない。誰もが必死で働いているのに、進捗は全くと言って良いほど上がらない。 進捗会議では責任者が針のむしろに座らせられる。そのストレスは現場全体に伝わる。誰もがどうしてこんな状況になったのか分からないままに徹夜を重ねる。
そういう辛い状況にプロジェクトの度に直面して、コの仕事を辞めたくなるヒトは多いと聞く。

進捗は上がらなくなるものだと受け入れること:

進捗率が線形に上がっていくという根拠のない妄想がこういう悲劇を招いている。
線形に伸びなければならないのだったら、線形になる様に再定義すれば良いのだ。
幸い、ここで見た進捗のカーブは「ロジスティック曲線」そのものだ。ロジスティック曲線になるものだと思えば、全期間を見積もって、進捗率nn%は、期間進捗率nn%に相当すると再定義することができよう。その方が、みんなが幸せになれる。
先人も言っている。
「百里の道を行く者は、九十九里をもって全行程の半ばとす。」
佐藤一斎
こう定義すると、そもそも「とあるプロジェクト」が納期通りに完了しないということは、早期に判明していたりするのだ。
結局、サイズを見積もっていないのにスケジュールと工数が決まっているという状況では、こうやってなるべく早期に再スケジューリングのサインを発見した方が良い。

ロジスティック曲線だとすると進捗は100%にならない:

「永遠に進捗は100%にならないじゃないか」という指摘は正しい。 でも、プロジェクトは進捗が100%に達したから終わるものではないのだ。

ドラえもん〜のび太のデスマーチ〜[http://pc8.2ch.net/test/read.cgi/prog/1116741745/]:

■ 関連記事

■7 VISAドメイン問題解説[http://www.e-ontap.com/summary/fornondnsexpert.html][セキュリティ]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

ドメイン名を確認しても確実ではないこともあるという事例。
安全に利用するためには、必ずSSL証明書を確認すること。

■ 関連記事

■8 携帯番号から名前や住所を特定するサービス[http://d.hatena.ne.jp/magisystem/20050623#1119513799][プライバシー]<< 前の記事 このエントリーをはてなブックマークに追加

こういうのは、せめて名前と電話番号を聞く運用にすべき。
考えてみると、ナンバーディスプレイに偽番号を表示させるテクニックとソーシャルを組み合わせられると、なかなか危険かも知れない。

■ 関連記事

以上、1 日分です。

指定日の日記を表示

前月 2005年06月 翌月
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

最近の日記

2019年04月01日

新元号「令和」について

2019年03月23日

DXアンテナ ワイヤレスチューナー メディアコンセント DMC10F1

2019年02月17日

#例のグラボを活用する

2019年01月03日

シリーズ5・myHomeAlexaで自分のCDをかける

2018年12月25日

シリーズ4・英語の楽曲・アルバム・アーティスト名をカタカナに直す

2018年12月23日

シリーズ3: Echo Dotがやってきた

2018年12月19日

続・Echo Dotがやってきた

分野別タイトル一覧


全て
CLIP
SYA!nikki
book
freebsd
hns
magic
おさけ
おしごと
お買いもの
ぐる
ごはん
アクセシビリティ
オープンソース
セキュリティ
音楽
地域情報化
電子自治体
日記

keikuma on Twitter

keikuma Name:前田勝之
Location:長崎市
Web:http://www.nantok...
Bio:前田勝之(まえだかつゆき)。長崎在住。コンサル、SE、プログラマー、 なんとか株式会社代表、非常勤講師(情報セキュリティ)。 セキュアド、テクニカルエンジニア(SV,NW)。サーバ管理とWeb日記を10年ほど。 ネットとリアルの接点に関心あり。食べること・歌うこと・愛すること・作ること・飲むこと。おいしいものがぜんぶすき。

サイト内検索

Google AdSense

Powered by hns-2.19.9, HyperNikkiSystem Project