今回のも、タレコミにある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] への再反論を試みます。
まず、ぼくは「今回の事件の原因はソフトウェア技術の未熟さにだけあって県にはない」とは思っていません。その点をわかってください。
ぼくは、情報漏洩の心配のないソフトウェアを実現するための技術革新が今すぐ起きるだろうとは思っていません。
言うまでもなく、情報漏洩の心配のないソフトウェアが出てくるのを待つ、というのではこの事件の解決になりません。技術過信とはそのような態度のことを指していると思います。何年か何十年か後にはそれで解決するかもしれませんが、今目の前にある問題を解決するのに未来の技術革新にすがっても仕方がありませんよね。
しかし、目の前の問題を解決する手段を考えるのとは別に、 #100947 に書いたような未来の解決手段を考えることにも価値があります。未来の技術革新にすがっても意味がありませんが、未来の技術革新を想像したり望んだりすることは意味がないどころか、ある意味、技術の進歩になくてはならないステップです。
さて、ぼくが「情報漏洩の心配のないソフトウェアを生む技術革新」が起きてほしいと思う理由は、ユーザの注意力と知識に大きく依存している現在のソフトウェアのあり方が望ましくないと考えているからです。これも技術過信になってしまうのでしょうか。
ぼくは、本来コンピュータはユーザを楽にするためのものであり、ソフトウェアはユーザに注意力や知識を要求するべきでないと考えています。「本来のソフトウェア」を生むような技術革新が（そのうち）起きてほしいという思いがあって、 #100947 を書いたのです。
鵜呑みにしてみる？
Re:情報の漏洩 (スコア:1, すばらしい洞察)
ソフトウェアに多様な機能が存在する限り、その機能を理解していなければ、想定外の事故が起きる。このことはどうやっても、技術革新などで解決できるものではない。警告や説明などによって軽減できるかもしれないが、注意力に依存することは間違いない。
Re:情報の漏洩 (スコア:1)
しかし、もし、ソフトウェアはこの先も現在の形のままにしかならないと思っているなら、 Alan Cooper 著、（株）テクニカルコア訳『ユーザーインターフェースデザイン』翔泳社、1996年 [shoeisha.com]を一読することをお勧めします。全章にわたって「ソフトウェアは現在のものよりよくできる」という主張が貫かれています（今手元になくて確認できないのですが、今でも通用する話が多いと思います）。この本を読めば、現在のソフトより少ない注意力や知識しか要求しないソフトウェアもありうるということがわかっていただけると思います。多様な機能を搭載したソフトウェアをデザインするとき、ユーザがすべての機能を理解していなければ重大な事故が起きるようなデザインをしていてはよくありません。
また、「機能を理解する」際の理解のレベルにはいろいろがあります。機能がどう実装されているかをユーザに理解してもらうことは困難ですが、実装の方法とは別の方法で理解してもらえば済むことが多いです。ソフトウェアをデザインする際には、ユーザにどう理解してもらうかを考えて、ユーザをその理解に誘導できるようなデザインをするのが望ましいです。現在のソフトウェアではユーザに注意してほしいときに警告を表示することがよくありますが、警告の使いすぎによってユーザになかなか注意を払ってもらえなくなっています。ユーザの注意力には限りがあるので、警告はここぞという場面でのみ使うべきです。
説明は警告とは違いますが、やはりあちこちで説明を読まなければならないようなソフトウェアではユーザは注意力を使い果たしてしまいます。
ユーザに簡単に注意を払ってもらうためにアイコンを使うことがあります。文字を使うよりも効果的だと思いますが、アイコンも使いすぎれば注意を払ってもらえなくなります。例えば、 Windows にある程度慣れたユーザは、感嘆符の付いたダイアログボックスを見ても感嘆符にあまり注意を払いません。
ソフトウェアによって重大な事故が起きないようにするには、ソフトウェアをデザインする際に、ユーザがどのようにソフトウェアを理解して使うかをよく考える必要があります（デザイナの考えが正しいかどうかを確認するため、デザインの過程でユーザテストというのがよく行われます）。また、ユーザの注意力に限界があることを理解する必要があります。実装と異なる理解をしてもらうためにユーザを誘導する方法も習得する必要があります。
紹介した本には、ユーザに注意力をあまり要求しないようなソフトウェアをデザインする方法が書かれています（どうしてそういうデザインがいいか、という話も書かれていたと思います）。
鵜呑みにしてみる？