暗証番号を通行人に見せる新幹線自動券売機 (高木浩光＠茨城県つくば市の日記)

そういえば、暗証番号の入力が丸見えな端末って、ちらほらと見受けることができます。割と体を使って指の動きを隠しながら入力する僕は典型的な性悪説に則った人間ですね。(笑
そもそもセキュリティ上好ましくない、なんてことはこのシステムを見れば一目瞭然なのですが、では何故その問題を開発時の設計不良 (というかバグですよ最早これは) として改善できないのでしょうか。
それは簡単なことで、要するにこの動作は「設計上は問題のない動作」であるからです。では何故そのような設計書が出来上がってしまうのでしょうか。
顧客が製品を発注する際に (プロバイダに) 求めること (モノ) は、「その製品に対する高水準な品質であること」であると考えられます。即ち機能であったり、デザインであったり、耐久性であったりするものです。
例えば自動車などを取り上げるとすれば、その品質とは以下のようなものが挙げられると思います。

外見や座り心地
燃費
操縦性能や運転補助機構

上で挙げた例は即ち非常に目に見えて判りやすいものですよね。ですから、作る側も電卓や数式・図面を使い論理的に問題解決に望めるわけです。
ではプログラムをとった場合どうなるでしょうか。簡単に置き換えてみたいと思います。

洗練されている GUI 画面
処理速度
入力ボタンやダイアログ、ヘルプ

となるでしょう。しかしこの中にさらに「セキュリティ」という新しい要素が加わります。今回のような問題は、即ちこれが判るか判らないかによって発生する確率が大きく変わってくるものなのです。
これは扱うものが車と違い、非常に個人的なモノを取り扱っているために新たに生まれる要素です。ですから、今までと同じようなモノ作りの感覚では、とても対応しきれないものでもあります。
しかもこの「セキュリティ」と言うものには絶対的な数式や証明理論が成立しているわけでもないわけで、取り扱いがとても厄介なものです。実際紙に書き起こした時点でこれらにどのようなセキュリティ問題が発生するかを理解することは、特別に訓練を行っていたり知識を身に付けていたりしない限り難しいでしょう。ですからなかなか「バグ」として取り扱いづらいのです。
さて、設計段階での発見の難しさを上げた上で、次に実際の製造工程に入ったときについて考察してみましょう。
例えば 1 人の開発者 (PG) に求められるものは、割り与えられた設計をプログラムに書き起こし、求められた機能を満たすモノを作り出す、というものです。ですから表示画面や入力系に問題が無いかチェックする必要がありますし、求められる実行速度を満たす必要もあるでしょう。これらは製造物を確認すればすぐにわかりますし、数字や動作の結果で簡単に表すことができます。
それに対しセキュリティの問題をどのように設計書に盛り込めばよいのでしょうか? 高木さんはこのケースで「離れたところからでも見通しがよい」と述べています。作っている際に「今自分が作っているプログラムは、もしかしてそういうセキュリティ的問題があるのではないか?」と疑問に抱くのは容易なのではないでしょうか? そこまで考えが至れば、例えばこんな仕様が提案できると思います。

距離にして 50 cm 以上離れた場所から閲覧できないようにする
暗証番号を入力するキーの配置はランダムにする

実に具体的な仕様が出てきますよね。
つまりです、設計者にセキュリティ設計が難しくてできないんだから、製造者に設計を任せ設計者はそれに評価を行っていく。そういう製造工程が必要なわけです。これはつまり「スパイラルモデル」に基づいた開発を意味します。ですからそのような開発を行っていくことが、この問題を解決するための一つのステップになるでしょう。
しかし、実際の開発現場は納期があり、つまり開発期間が限られていて、このようなスパイラルをせいぜい良くて 1 周しかできないのが現状だと思います。現状ではそのような過酷な環境が生まれてしまうのです。非常に悪循環です。
できれば案件の見積もりにおいて、そのような開発手法をしっかりと考えられる技術者がしっかりとした提案を行っていくべきだ、つくづくそう感じます。