今回のも、タレコミにある2000年6月の事件も、「公開されないようにしたつもりの情報がソフトウェアを操作するだけで見えてしまう」ということですが、以前の Microsoft Office (詳細を失念)には削除したはずの文書の断片がファイルに含まれてしまうという問題もありました。このような文書の断片はソフトウェアを普通に操作しても出てきませんが、それなりに調べれば読めるということのよう
AC さんとぼくの意見の食い違いは、将来のソフトウェアに関する見通しの違いから生まれていると思います。ぼくの見通しは将来の可能性の一つでしかない、という批判なら甘んじて受けます。
しかし、もし、ソフトウェアはこの先も現在の形のままにしかならないと思っているなら、 Alan Cooper 著、(株)テクニカルコア訳『ユーザーインターフェースデザイン』翔泳社、1996年 [shoeisha.com]を一読することをお勧めします。全章にわたって「ソフトウェアは現在のものよりよくできる」という主張が貫かれています(今手元になくて確認できないのですが、今でも通用する話が多いと思います)。この本を読めば、現在のソフトより少ない注意力や知識しか要求しないソフトウェアもありうるということがわかっていただけると思います。
情報の漏洩 (スコア:2, 興味深い)
今回のも、タレコミにある2000年6月の事件も、「公開されないようにしたつもりの情報がソフトウェアを操作するだけで見えてしまう」ということですが、以前の Microsoft Office (詳細を失念)には削除したはずの文書の断片がファイルに含まれてしまうという問題もありました。このような文書の断片はソフトウェアを普通に操作しても出てきませんが、それなりに調べれば読めるということのよう
鵜呑みにしてみる?
Re:情報の漏洩 (スコア:0)
この事件の原因は、こうした事態にまで知恵がまわらない
愚かな人間が個人情報を扱っていた、という人事の問題。
Re:情報の漏洩 (スコア:1)
技術で何もかもが解決できると思ってはいけないということは承知しています。
ただ、どこに対して反論されているのかが今一つよくわからず、どうも誤解されているような気もするので、 #100947 [srad.jp] の補足を書きつつ少し #101210 [srad.jp] への再反論を試みます。
まず、ぼくは「今回の事件の原因はソフトウェア技術の未熟さにだけあって県にはない」とは思っていません。その点をわかってください。
ぼくは、情報漏洩の心配のないソフトウェアを実現するための技術革新が今すぐ起きるだろうとは思っていません。
鵜呑みにしてみる?
Re:情報の漏洩 (スコア:1, すばらしい洞察)
注意力と知識に依存しないなど無理。
ソフトウェアに多様な機能が存在する限り、その機能を
Re:情報の漏洩 (スコア:1)
しかし、もし、ソフトウェアはこの先も現在の形のままにしかならないと思っているなら、 Alan Cooper 著、(株)テクニカルコア訳『ユーザーインターフェースデザイン』翔泳社、1996年 [shoeisha.com]を一読することをお勧めします。全章にわたって「ソフトウェアは現在のものよりよくできる」という主張が貫かれています(今手元になくて確認できないのですが、今でも通用する話が多いと思います)。この本を読めば、現在のソフトより少ない注意力や知識しか要求しないソフトウェアもありうるということがわかっていただけると思います。 多様な機能を搭載したソフトウェアをデザインするとき、ユーザがすべての機能を理解していなければ重大な事故が起きるようなデザインをしていてはよくありません。
また、「機能を理解する」際の理解のレベルにはいろいろがあります。機能がどう実装されているかをユーザに理解してもらうことは困難ですが、実装の方法とは別の方法で理解してもらえば済むことが多いです。ソフトウェアをデザインする際には、ユーザにどう理解してもらうかを考えて、ユーザをその理解に誘導できるようなデザインをするのが望ましいです。 現在のソフトウェアではユーザに注意してほしいときに警告を表示することがよくありますが、警告の使いすぎによってユーザになかなか注意を払ってもらえなくなっています。ユーザの注意力には限りがあるので、警告はここぞという場面でのみ使うべきです。
説明は警告とは違いますが、やはりあちこちで説明を読まなければならないようなソフトウェアではユーザは注意力を使い果たしてしまいます。
ユーザに簡単に注意を払ってもらうためにアイコンを使うことがあります。文字を使うよりも効果的だと思いますが、アイコンも使いすぎれば注意を払ってもらえなくなります。例えば、 Windows にある程度慣れたユーザは、感嘆符の付いたダイアログボックスを見ても感嘆符にあまり注意を払いません。
ソフトウェアによって重大な事故が起きないようにするには、ソフトウェアをデザインする際に、ユーザがどのようにソフトウェアを理解して使うかをよく考える必要があります(デザイナの考えが正しいかどうかを確認するため、デザインの過程でユーザテストというのがよく行われます)。また、ユーザの注意力に限界があることを理解する必要があります。実装と異なる理解をしてもらうためにユーザを誘導する方法も習得する必要があります。
紹介した本には、ユーザに注意力をあまり要求しないようなソフトウェアをデザインする方法が書かれています(どうしてそういうデザインがいいか、という話も書かれていたと思います)。
鵜呑みにしてみる?