読者です 読者をやめる 読者になる 読者になる

具志ブログ(β版)

ピキーン!ときたフレーズや画像、動画なんかを俺のフィルタを通して紹介

36. 過度の対話的インタフェースを避ける

スポンサーリンク

過度の対話的インタフェースを避ける

少し、ふりかえり。

今、くどくど紹介している本はこれ。

UNIXという考え方―その設計思想と哲学

UNIXという考え方―その設計思想と哲学

コンピュータを操作するためのOS(基本ソフト)、UNIXってやつについて、その流儀というか、こうあるべきというか、そんな設計思想や哲学をまとめた本。

で、9つの定理としてまとめられたそれらの考え方を、コンピュータではなく、人間に当てはめて考えると非常にしっくり来るので、その捉え方を一つずつ、ね。

で、今回のやつが8番目の定理で、これまでの7つをリストアップしとく。

  1. スモール・イズ・ビューティフル blog.gushijiro.com

  2. 一つのプログラムには一つのことをうまくやらせる blog.gushijiro.com

  3. できるだけ早く試作する blog.gushijiro.com

  4. 効率より移植性を優先する blog.gushijiro.com

  5. 数値データはASCIIフラットファイルに保存する blog.gushijiro.com

  6. ソフトウェアを梃子(てこ)として使う blog.gushijiro.com

  7. シェルスクリプトによって梃子の効果と移植性を高める blog.gushijiro.com

といった感じ。

で、今回の定理は「こうしよう」ではなくて、「こうするな」ってことになる。

「どう」するな?

「過度の対話的インタフェース」はダメ!

さて、「過度の対話的インタフェース」って何だろう?

どうしてダメなんだろか?

そして、この定理を人間に当てはめると?

過度の対話的インタフェースってのは

この本では、mailとsearchっていう(架空の)プログラム例を出してて、それぞれ、起動させたら、明示的に「exit」と入力しないとプログラムが終了しない、としてる。

で、「明示的に入力」ってのが対話的インタフェース。

コンビニで買い物するときレジで「20歳以上ですか?はい いいえ」って、わざわざタッチさせるのも対話的インタフェース。

つまり、何らかの動作の確認を取るってこと。

これ自体は悪くない。

この対話的確認によって、やっちゃいけないことをやらなくてすむ、ってことがあるから。

例えば、消しちゃいけないデータを間違えて消そうとしてるかもしれない。

最後の確認で「あ!これは!」って気づいて助かることもある。

だから、この対話的インタフェースは大事なところに使うといい。

そう、大事なところに。

なぜ、過度の対話的インタフェースは避けるべきなのか?

「過度の」対話的インタフェースってのは、そんなに大事じゃないのにわざわざ確認させること。

人間の判断はコンピュータより遅いので、どんなにコンピュータの性能が上がっても、そこで全体の処理が遅くなっちゃう。

だから、できるだけ対話的インタフェースは避けて、できるだけ自動実行するようにプログラムを作るといいですよ、ということ。

人間に当てはめると?

人間も同様で、一つ一つ確認をしてると、遅くなっちゃう。

全然するなってわけじゃない。

大事なところは、振り返りをして一つ一つ丁寧に確認をする。

と、いうか、昨今の問題は、この振り返りを取り入れずに、何でも自動化させようとし過ぎてることが原因なんだけど、ちょっと置いておく。

いつか、改めて。

ありがちなのが、組織で細々と承認作業をすること。

いや、「間違いをなくす」ってのは大事なことってはわかるけど、やりすぎじゃない?ってのもあるでしょ。

スピードが遅くなって、必要な時に間に合ってないとか、本末転倒なことに。

だから、「過度な」ってのは避けようね、と。

そして、それは「大事なことはきちんと確認しよう」と同意で、何が大事なのかってのを知らないとできない。

この「何が大事なのか」ってのを知ることこそが、「本当に大事なこと」だ。

それにはちゃんと時間を当てて、確かめる作業をすること。

自分の人生にとって、これは大事なのか?

それを吹っ飛ばして、何でも自動的にやろうとすると、「あれ?こんなはずじゃ?」ってなる。

これもまた、改めてまとめます。

今回の定理については、ちょっとね、ふかーい捉え方があって、それこそ、人とは何か?まで行くので、今回はここまで。

次は最後の定理を紹介。

UNIXという考え方―その設計思想と哲学

UNIXという考え方―その設計思想と哲学