【ITニュース解説】Blind coding

システムエンジニアを目指す皆さんにとって、プログラミングは魅力的な仕事だ。しかし、全ての人が同じ環境で、同じようにコードを書けるわけではない。ここでは、視覚に障がいを持つ一人のプログラマーが、どのようにしてプログラミングを行い、どのような工夫を凝らしているのか、その実体験とそこから見えてくる課題を紹介する。

まず、視覚障がいが進行する中でプログラミングを続けることの現実的な困難さが語られる。一口に「視覚障がい」と言ってもその程度は様々だが、道路を安全に渡れないほどに視力が低下すると、「盲目」に近い状態と捉えられる。このような状況で、プログラミングの道を志す、あるいは続けることには、非常に厳しい現実がつきまとう。

特に、就職活動における障壁は深刻だ。たとえ軽度の視覚障がいであっても、面接時にその事実が知られれば、ひどい扱いを受ける可能性がある。もし入社後に発覚すれば、能力があってもすぐに解雇されるケースもあるという。これは、アクセシビリティに関する配慮を求めることが「この会社では働きたくない」と受け取られかねない現状を反映している。連邦労働法の施行が不十分なこともあり、特にテック企業では障がい者への差別が蔓延していると指摘される。

しかし、困難な状況の中でも、プログラマーは自身の能力を最大限に引き出すための工夫を凝らしている。このプログラマーが最も効果的だと感じるのは、コードを頭の中で「視覚化」することだ。C言語やC++、Goといった命令型言語、そしてHaskellのような宣言型関数型言語でも、構文が正しく表現されていれば、頭の中でコードの構造やロジックを正確に組み立てられる。この経験から、コードの構文と正しい表現がいかに重要か、そしてそれがコードを書く、読む、デバッグする全ての工程において不可欠であるかが強調される。

最大の課題は、頭の中で完成したコードを実際にエディタに入力する「タイピング」の工程だ。わずかな視力しかなく、全てがぼやけて見える状況では、タッチタイピングが役立つものの、些細なミスでも発見し修正することが極めて難しい。リアルタイムでコードのチェックを行うエディタは、ポップアップや警告が多すぎて、それ自体が作業の流れを中断し、集中を妨げる原因となる。そのため、初期のコードを大量に入力する際には、可能な限り干渉の少ないシンプルな環境が求められる。

この課題を解決するために、驚くべき方法が採用されている。それは、AIにタイプミス（typo）の校正や修正、そして自身では読み取ることが難しいコンパイラエラーの解釈を依頼することだ。特にC++のような言語では、複雑で理解しにくいエラーメッセージが大量に出ることがあるため、AIの助けは非常に大きい。AIが不適切なリファクタリングや提案をしてくることもあるが、プロンプトの工夫によって、変更を加えずに修正済みのテキストだけを出力させる方法を見つけたという。このような、頭の中でのコードの視覚化とAIによる校正作業を組み合わせることで、以前よりも速く、そして信頼性の高いコーディングが可能になったと語られている。

使用するツールや環境の選択も、作業効率に大きく影響する。シンプルなモノクロ表示が好ましいため、Vimのようなエディタが選ばれることが多い。一方で、Visual Studio Code（VS Code）も、不要な機能を無効にし、UIのスケーリングや高コントラストモードを活用することで、視覚障がい者にとって非常に有用なツールとなる。特に、文字を先読みして入力候補を表示するスマートタイプアヘッド機能は、タイピングの負荷を軽減するのに役立つ。VS Codeは、モダンなUIデザインで省略されがちな境界線を明確に表示する機能も備わっており、それが視覚的に大きな助けとなる。

デザイン作業においては、LibreOfficeが高コントラストモードで効果を発揮する。しかし、全てが白黒表示になるため、最終的な見た目が予想しにくいという課題もある。また、線に付随する矢印が、高コントラストモードで正しく表示されないという細かな問題も指摘されている。

UIデザインの観点からは、古いX11デスクトップ環境が理想的だと感じる。X11では、明確な境界線が設けられ、黒色は本当に真っ黒に表示されたため、テキストがはっきりと見えたという。これに対し、前面に画像が大きく表示される現代のウェブサイトは、テキストを読むことを困難にする「目潰し」のような存在だと感じる。古いX11が採用していたXPMフォーマットのように、画像もテキスト形式で表現されるようなアプローチが望ましいとも語られる。

オペレーティングシステムのアクセシビリティ機能についても、それぞれに一長一短がある。Windowsは、全体としてはまずまずのアクセシビリティ機能を提供するが、ファイルマネージャーなど一部のコンポーネントがアクセシビリティ設定をサポートしていないなど、一貫性に欠ける点が課題だ。しかし、対応しているアプリケーションでは十分に機能する。

macOSは、アクセシビリティの「ゴールドスタンダード」と評価されることもあるが、視覚障がい者が高価な機器を頻繁に買い替える経済的余裕はないため、このプログラマー自身は使用経験がなく、評価できないと述べている。

Linuxデスクトップ環境に関しては、過去のX11デスクトップやGnome 2はアクセシビリティに優れており、25年前には盲目のユーザーが初めてコンピューターを使えるようになった歴史がある。しかし、現代のLinux、特にWayland環境はアクセシビリティの点で大きく後退していると指摘される。Gnome開発者からは「アクセシビリティは我々が関心を持つユースケースではない」と明確に言われた経験があり、この姿勢がUbuntu 24.04でアクセシビリティが損なわれた原因にもなったと述べられている。

対照的に、KDEはアクセシビリティに関心を持っているものの、技術的な課題を抱えている。Qt QMLというUIフレームワークが、アクセシビリティモードを提供するように最初から設計されていないため、各アプリケーションで個別にアクセシビリティ機能を実装するか、QMLの上に構築されたKirigamiのような層で対応する必要がある。これは多大な労力を要するが、少なくともKDE開発者はアクセシビリティを真剣に考えている点が評価されている。

このプログラマーの体験談は、視覚障がいを持つ人々がプログラミングの現場で直面する現実と、それを乗り越えるための知恵と努力を示している。同時に、現代のIT業界やツール開発において、アクセシビリティへの配慮がまだ不十分であること、そしてその改善が強く求められていることを浮き彫りにしている。システムエンジニアを目指す皆さんには、将来開発に携わる上で、多様なユーザーのニーズに応えられるような、より包括的な視点を持つことの重要性を教えてくれるだろう。