テスト工数が少ないことでの利点は「トライ＆エラー」が容易であるということです。少しでも不自然なメニュー配置があれば、戸惑うことなく仕様の変更ができます。ところが、コンテキストメニューという要素が増えただけで、その工数は単純に2倍になり、テストでは「相互関係」の確認作業に追われてしまい、本質である「機能そのものの使い勝手」を練り上げるところまで配慮が行き渡りません。
最後に4. の「マニュアル、ヘルプなどを作り上げる」ですが、2ボタンマウスならば以下のような懸念事項がでてきます。
“A という機能に対して、Bという操作もある場合、両方について記述の必要性が出てくる”
いろんなソフトウエアのヘルプを見てみると、大抵の場合、操作に対して関連するページがあり、それぞれ飛び先が存在します。
存在する機能に対して重複した操作が多ければ多いほど、それぞれに対してさらに飛び先を作成する必要がありますし、それぞれが相互関係を保たなければなりませんから、機能が重複していたり、コマンドの関連性が整理されていないと、ヘルプを作成する側に“かなりの労力”が必要になってくるのは容易に想像がつきます。
これが、“1ボタンマウス”であれば、重複した操作があまりないため、ヘルプ作成もシンプルなのです。
Mac のヘルプは基本的に“自然言語”による検索が可能です。“文字を大きくしたい”とか“htmlを作りたい”とかを入力してボタンを押すだけです。
しかもヘルプ全体で検索できるので、使用しているアプリケーションとは異なるアプリケーションのヘルプを同時に検索することもできます。
これまでのことから、仮にマウスボタンを増やしたとしても、それに応じたソフトウェア開発ができていなければ、ほとんど意味がないということもわかっていただけたのではないでしょうか？
ソフトウェアを使う側
次は、ソフトウェアを利用する立場で“1ボタンマウスの意義”というのを検証してみましょう。使う側にとって、道具というのは便利でなければなりません。そしてよくできた道具というのは、操作が単純（シンプル）であることが重要です。例えば、絵を描く筆などで本当によいものとされるのは、多機能さではなく“本質”を磨いているものです。
これは、パソコンでいうと、マウスならばクリックの感触や、ポインタの動きに該当します。
家電製品などは、ほとんどの場合、ボタンをなんとなく操作すれば使えるようになっています。
これは、ボタン１つに対して機能が１つないしは2つに限定されているからで、適当にボタンを操作すれば大抵の作業ができる（目的の機能が見つかる）ようになっているためです。
つまり、“操作”と“結果”の関係がシンプルであるために、試行錯誤しながら使ってもそのうち目的が果たせてしまうということなんです。
