IBMは、Microsoftがダイアログボックスのフィールド間移動にTabキーを使うことを望まなかった
(devblogs.microsoft.com)- MicrosoftとIBMがOS/2を共同開発していた時期、ダイアログボックスでフィールド間を移動するのにどのキーを使うかが、組織構造の違いをあらわす争点となった
- Boca RatonのIBMオフィスに配置されたMicrosoftの同僚は、フィールド移動キーとしてTABキーを使うことを決めたが、IBMはこれをRedmondのマネージャーにエスカレーションするよう求めた
- Microsoftのマネージャーは、彼がBocaにいるのはそのような決定を代わりに下すためだと答え、IBMには「Microsoftはこの用途でTABキーを使うことを支持する」という表現で伝えられた
- IBMは満足せず、組織体系に従って問題を何段階も上に上げ、プログラマーより約7階層上のVPが反対しているとして、Microsoft側でも同格の管理者による確認を求めた
- Microsoftの同僚は「Bill Gatesの母親はTABキーに関心がない」と答え、その後議論は終わったようで、TABキーはそのまま維持された
OS/2協業であらわれた組織構造の違い
- MicrosoftとIBMがOS/2を共同開発していた時期には文化的な衝突があり、Microsoft側はIBMの同僚たちを不必要な官僚主義に縛られていると見なし、IBM側はMicrosoftの人々を規律のないハッカーだと見ていた
- 衝突点の一つは組織構造であり、ダイアログボックスであるフィールドから別のフィールドへ移動するときにどのキーを使うかが争点になった
- Microsoftの同僚の一人はフロリダ州Boca RatonのIBMオフィスに配置されており、フィールド移動キーとしてTABキーを使うことを決めた
- IBM側はこの決定に満足せず、Redmondにいる彼のマネージャーへ問題をエスカレーションするよう求めた
Microsoftの委任とIBMの上申手続き
- Microsoftのマネージャーは「あなたがBocaにいる理由は、私がBocaにいなくても済むようにその種の決定をするためだ」と答えた
- この返答はIBMに伝えられる前に、より企業的な表現へ言い換えられ、「Microsoftはこの用途でTABキーを使用することを支持する」となった
- IBM側は満足せず、組織体系に従ってこの問題を何段階も上へと上げた
- IBMは、プログラマーより約7階層上にいるVPがこの用途でTABを使うことに断固反対しているとして、Microsoftでも同格の管理者による確認を求めた
論争の終結
- Microsoftの同僚は「Bill Gatesの母親はTABキーに関心がない」と答えた
- この返答のあと議論は終わったようで、TABキーはそのまま維持された
- アメリカでは次の日曜日がMother’s Dayだが、母親にTABキーについての見解を尋ねるのは勧めない、という冗談で締めくくられている
- MicrosoftとIBMが互いに抱いていた評価は、どちらもある程度は的を射ていた可能性がある
1件のコメント
Hacker News のコメント
IBM は伝説的に 過剰管理 がひどかった
以前一緒に働いていた人が、90年代半ばにロンドンの IBM で夏季インターンとして今でいう QA エンジニアリングのような仕事をしていたのだが、当時は全員がスーツで出社する文化が変わりつつある時期で、インターンたちが金曜日だけでもカジュアルな服装を許可してほしいと頼んだそうだ
顧客に会うこともなく奥の部屋に閉じこもって働いていた立場なので大した話ではないと思っていたが、数か月後、インターンシップが終わる直前になってようやく返事が来て、その要望はロンドンオフィスの4段階の承認ラインを通ってアメリカ本社へ送られ、ついには副社長の机まで上がっていた
各階層がこの重大案件を処理する権限が自分たちにあるのか考えるのに何週間もかかったようで、返答は同じ経路を一段ずつ下って大西洋を渡り、ロンドンのスーツ姿のインターンたちに届いたが、その時にはインターン期間はもう数日しか残っていなかった
答えは 不許可 だった
ところが 8か月後、IBM の人事から来週木曜に面接したいと電話があり、もう興味がないと言うと本気で困惑していた
何を考えていたのか分からないが、高い給料を提示するわけでもないのにやたらと自意識が強かった
かなりくだけた雰囲気で、上の話自体を否定したいわけではなく、別の視点を添えているだけだ
勤務時間外に作る知的財産について IBM が優先権を持つという契約条項に例外を入れてほしいと頼んだことがある
自分は技術サポートのコールセンターで働いていただけで、IBM の専有情報にアクセスしていたわけでも開発職だったわけでもなく、その点でのリスクはまったくなかった
実際、物理的に会える相手はみな非常に妥当な要求だと見ていたが、最初の却下回答が来るまで 6週間 かかり、直属の上司が仲裁を試みたことでさらに 2 週間の検討が追加されたものの、答えはやはり拒否だった
報告ラインに沿ってアメリカまで上がり、そこから法務に分岐してまた下りてきたようで、結局、友人と小さなソフトウェアプロジェクトをやっただけで IBM が権利を主張するリスクを避けるために会社を辞めた
さらに HR のフォームは 80 年代初頭に作られて 2000 年代にデジタル化されたもので、顧客対応ではないうちのチームは非常に多様だった
異なる性別・代名詞の組み合わせを認めるようフォームを更新しようという試みがあったが、検討に 12 週間 ほどかかり、結局は誰もそのフォームを誰が直すべきか特定したがらなかったために却下されたようだった
チームには LGBT のメンバーが多く、その維持は重要に見えたにもかかわらず、きっぱり拒否された
セクハラ防止研修は 2010 年にテープで提供されており、「更新版」と書かれていたので、その前はビニールレコードだったのかもしれない
この話が奇妙に感じられるのは、IBM がいくつもの製品で キーボードの命名法 を一貫して使っていて、3270 系のメインフレーム端末では現代のキーボードの Tab の位置にある Tab キーでカーソルを次のフィールドへ移動させていたからだ
https://www.bitsavers.org/pdf/ibm/3278/GA27-2890-4_3278_Disp... PDF 73 ページ
ちなみに IBM 端末ではフィールド間移動が重要だったので、Tab キーの反対側には専用の Back Tab キーまであった
元の IBM PC ではこの 2 つの機能を 1 つのキーにまとめたため、古典的な PC キーボードの Tab キーには前方 Tab と後方 Tab の記号が両方あり、後方 Tab の記号が上にあるのは Shift を押す必要があることを意味している
さらに 5250 系端末では Tab/Back Tab の代わりに “Field Advance” と “Field Backspace” という用語を使っていたが、キーの記号と位置は 3270 系とだいたい同じだった
参考: https://www.bitsavers.org/pdf/ibm/5291/GA21-9409-0_5291_Disp...
左側の “Next field” キーと右側の対応する “Previous field” キーを見ればよい
IBM 3270 は フォーム入力用の装置 で、メインフレームが空欄付きのフォームを端末へ送り、ユーザーが空欄を埋めていた
端末ハードウェアはフォームの固定部分を上書きできないようにし、数値フィールドのような制約も適用しており、これらの処理はすべて端末側で行われていた
フォームを埋め終えるとユーザーが ENTER を押し、完成したフォームが 1 つのトランザクションとしてメインフレームへ送信された
この方式のおかげで 1 台のメインフレームが膨大な数の端末を処理でき、ユーザーは入力中に遅延を感じることなく、画面を見ずに高速にタイプできた
PC にはこうした利用モデルがなく、PC 側の人々は「タイプライター」を思い浮かべていた
初期の家庭用コンピュータ端末の 1 つも “TV Typewriter” と呼ばれていた
Web フォームはこのモデルを持っているが、一貫性はさらに低い
[1] https://sharktastica.co.uk/resources/images/model_bs/themk_1...
ただし推測にすぎない
80 年代の IBM には “Systems Engineers” という上級技術職群があり、彼らの仕事全体は特定システムの長所と短所を論評することだった
システムを書いたりデバッグしたり説明したりするのではなく、ただ「あなたは間違っている」と判断する役割だった
Microsoft チームには絶望的に企業的な組織に見えたが、IBM 内部では Boca の人たちは「反乱部隊」と見なされており、実際、IBM の大半はその存在すら知らなかった
IBM 的な時間感覚ではほぼ一夜にして始まり、信じられない速度で動き、Thomas Watson Jr. が部下の反対を押し切ってこうしたスカンクワークスを承認したからこそ可能だった
そのため Boca には、通常その規模のプロジェクトにあるはずの監督・調整・統制がほとんどなかった
初期の Boca は通常の報告体系の外で動いており、IBM の他部門から技術や部品を調達しようとすると、自分たちが本当に IBM 所属であることを説明しなければならないことさえあった
1 つは今日の一般的な Return キーで、次のフィールドへ移動するだけでフォームは送信しなかった
もう 1 つの Enter キーは今の右 Ctrl の位置にあり、そのキーがフォームを送信した
なので IBM が Tab キーそのものに反対したのではなく、3270 ユーザーが次のフィールドへ移動すると期待する Return キーをフォーム送信キーとして使うことに反対していた可能性がある
DOS プログラムにもこういうものが多く、Return を押すとフォーム送信ではなく次のフィールドへ進み、Windows では慣れなければならない点の 1 つだった
CUA は Tab と Backtab がフィールド間を移動すると明示している
つまり IBM は自分たちの標準に対して 7 段階の管理階層 を上げながら反対していたことになる: https://archive.org/details/ibmsj2703E/page/n13/mode/2up
Tab を好む人間として、論争をしたいわけではないが、以前 Twitter で Brendan Eich に、なぜスペースを好むのか尋ねたことがある
彼の答えは予想以上に考え抜かれたものだった
現代の OS や UI の動作が Tab キー自体を横取りしてしまう ため、特にブラウザのような文脈では実際のタブ文字を入力するのが厄介になるというのだ
それでも私は依然として Tab を好むし Go 開発者でもあるが、これが本当に面倒な問題だという点では彼は完全に正しい
たとえば Hacker News のテキストエリアにタブ文字を入れようとしてみればすぐ分かる
言いたいことはある程度分かるが、タブとスペースが重要なコードを HN のテキストエリアで書いているなら、その時点で何かがおかしい
コードエディタなら Tab キーを正しく扱う
ただし Enter には Shift+Enter、Alt+Enter、Cmd+Enter のようにある程度の慣習があるのに、OS 全体で使える タブ文字入力の方法 がほぼ存在しないのはやはり腹立たしい
Shift/Alt/Ctrl+Tab もたいてい別の動作に横取りされている
ただしタブと改行がすべての文脈に当てはまるわけではない
また、プログラムによっては ^V のように、制御文字をコマンドではなく データとして入力 するためのキーやキー組み合わせを設けるのも理にかなっているかもしれない
既存のコンピュータと同じである必要のない新しいコンピュータを設計するなら検討に値する要素で、私もこういうことを考えたことがあり、実際に考慮するかもしれない
Tab キーには本来の目的があったのに横取りされ、その本来の目的を使うのが難しくなった
Apple が最初に Touch Bar を導入したとき Escape キー をなくしたのと大差ない
平均的なユーザーはそのキーをほとんど使わないかもしれないが、平均的な開発者はそのキーの本来の用途を長く使わずに済ませるのは難しい
昔、タブキーはシステムごとに違った表現になることがあるので、常に同じ見え方をするスペースのほうが安全だと聞いたことがある
Brendan が言いたかったのはそのことなのだろうか?
良い記事だが、IBM が Tab キーをこう使うことに反対した理由が何だったのかはやはり気になる
Tab が入力文字であると同時に制御文字になることを望まなかったのだろうか?
つまり、ある入力フィールドでは Tab を入力でき、別のケースではできないが、どちらなのか即座には分かりにくいという理由だろうか?
2026 年の今でもこの見方には共感できる
第一に DOS との 互換性破壊 だった
DOS プログラムでは Enter を使っていて、テンキーにも Enter キーがあったので、片手で数値データを入力できた
左手は紙の原本に置いたまま、右手だけで入力でき、人々はこれに非常に慣れて高速化していた
このパターンは Excel のような一部プログラムにも残っている
多くの顧客は両手をキーボードに置かなければならないのを嫌い、私たちのプログラムの多くは Enter=Tab マッピングを許していた
重要なのはキーの「名前」ではなく 位置 だ
キーの二重用途は私たちが受け入れている煩わしさにすぎず、あるときはナビゲーションキーとして動き、別のときは空白入力キーとして動く
Enter にも同じ問題があったはずだ
圧倒的に良い解決策はキーボードに新しいキーを 1 つ追加することで、できればテンキー側に置くのがよかっただろう
当時は新しいキーがたくさん増えたのだから、振り返ればそのときに「次へ進む」キーを追加すべきだった
その環境では Tab キーに完全に論理的で直感的な役割が 2 つあり、それらが衝突するからだ
同じ問題は Enter キー でももっと頻繁に起きており、現代でも ctrl+crlf が改行なのかメッセージ送信なのか、単独の crlf と shift+crlf がそれぞれ何をするのかという、かなり複雑なルールを私たちは覚えている
HN エディタでは shift+crlf と単独 crlf が改行を作り、ctrl+crlf は何もしない
しかし他の場所では ctrl+crlf がフォームやメッセージ送信をトリガーし、shift+crlf が生の改行を入れ、単独 crlf はそのどちらかだったりどちらでもなかったりする
こうしたバインドはよくあるが例外や逆転も見たことがあり、shift+crlf がフォーム送信を行い、ctrl+crlf が生の改行を入れるべき場合もあった
こういうことはどれも本当に厄介でユーザー摩擦を大きくし、しばらくの間 Microsoft のスタイルガイドは、今の人には皮肉に見えるかもしれないが、ベストプラクティスの中核的参考文献と見なされていた
多数の可動部品を抱えた組織を管理することと、ユーザーのために素早く何かを作ることとでは、関心事が大きく異なるのは確かだ
IBM の官僚機構の誰かが割って入って話を止め、それが文化の違いを示している、という読み方だった
そもそもその文章自体が、そうした 文化の違い についての文章だからだ
IBM は、MS-DOS がオプションに “-” を使えない理由でもあり、各ドライブの “\DEV” ディレクトリにデバイスを置かなくなった理由でもある
“/” をパス区切りとして使えることだけは生き残った
Microsoft の多くの人は Xenix を使っていて Unix ファンで、かなり初期の DOS にはこの目的のための SWITCHCHAR と AVAILDEV という config.sys オプションがあった
だが私の知る限り、IBM がこれに強く反発して削除を強いた
特に DEV 問題 が腹立たしいのは、DOS 1 にはディレクトリがなかったのだから互換性問題になるはずがほとんどなかった点だ
その結果、DOS/Windows はデバイスファイルがすべてのディレクトリに存在すると仮定するため、“CON” や “COM1” という名前のファイルを作れない状態に縛られている
ただ何年ものあいだ、そのために必要な呼び出しを 文書化していなかった だけだ
メインフレーム 3270 では Tab キーがフィールド間移動に使われていた記憶があるので奇妙だ
Operator's Guide の PDF を見つけた
https://news.ycombinator.com/item?id=48028227 を見ればよい
Tab を使うのはほとんど 第二の天性 で、GUI アプリに移ったとき、特に Visual Basic アプリでタブ順が変だと腹が立った
ただ、その目的専用に予約された機能キーもあった気がする
AS/400 は使ったことがないが、独立した Field Exit キーという概念があったと思う
「Microsoft の人たちは IBM の同僚を無駄な官僚主義に沈んだ人たちだと見なし、IBM の人たちは Microsoft の人たちを規律のないハッカーだと見ていた」という一節には大笑いした
MSFT で働いているが、当時の Microsoft は今とはまったく違う会社だったようだ
今では終わりのない会議、AI 指示、昇進芝居などで、私も同僚も無駄な官僚主義に閉じ込められていると感じる
給与は悪くないが、官僚主義は魂を削る
すべての機械にゲームコントローラーをつないで、方向ボタンでフィールド間を移動し、“A” キーで階層メニューを 1 つ上に戻り、“B” キーで下位メニューに入るようにすべきだ
そうすればフィールド間を移動するには、データを入力したあとキーボードから手を離し、ゲームコントローラーを持って右か左を押し、それからまたキーボードに手を戻せばよい
生産性は本当にものすごく上がるだろう
標準 OS コントロールを使うビデオゲームを ゲームパッドで自然に操作 できるようにするのが目的だ
ぜひ特許を取るべきだ
それまでは次善策の マウス を使うことにしよう
30 年以上の Mac ユーザーだが、Raymond Chen の歴史記事は本当に好きだ
folklore.org は知っているが、Apple の内部にもそれに相当するものがあればいいのにと思う
残念ながら、そういうものは Apple 文化 の一部ではない
1992 年に System Software チームの夏季インターンをしていて、私のプロジェクトの 1 つは、ディスク初期化中に見つかった不良ブロックを示す Disk Initialization Package の機能を改善することだった
既存機能は動いてはいたが非常に遅く、進行状況も表示せず、キャンセルもできなかった
いちばん厄介だったのはユーザーインターフェースだった
速度は大幅に改善したが、全体にどれくらいかかるか分からないので、残り時間を表示しようとするあらゆるヒューリスティクスがひどい出来だった
数席離れたところに肩書きが “User Interface” の人が見えたので助けてもらえるかもしれないと思い、少し時間はあるかと尋ねたうえで、Apple 社員 4 番であり 2 人の Steve を互いに紹介した Bill Fernandez と一緒に座って問題を考えた
その夏に会った人の中で、マネージャーを除けば本当にいちばん親切な人で、問題をすぐ完全に理解し、すばらしい解決策を出してくれた
残り時間の推定は捨てて、各ディスクトラックをテストするたびに進む 不定進捗バー に切り替えようというものだった
うまく機能し、人々にも好評で、7.1 以降のポイントリリースに含まれた
Raymond の記事ほど驚く話ではないが、出だしとしては十分だ
どの時代も、ほぼあらゆる細部をめぐる争いで満ちていたのだと感じられるのは、ある意味で感心する
キーもそうだし、配列、形状、意味まで全部含まれる
なのに今では誰もこういうことを気にしていないのが、とても奇妙でもあり面白くもある