ウェブサイトなどのデザインにおいて、機能（裏側）とユーザーインターフェイス（触れるところ）のデザインは通常別に職能を持った人が行い、フェーズとしても分かれている。
さて、LinuxにMacOSのような見栄えが必要かと言えば、うーんまあ今ぐらい頑張ってればいんじゃない? と思う。実際に使うのはアプリケーションだったりオンライン上のサービスだったりするわけだから、デスクトップやファイルのアイコンなどは、既存OSのい いとこ取りをして使い勝手が良ければ、それで十分だろう。
それよりも、ちょっと使い勝手を変えたり、ツールを入れたりするときに、やっぱり10年経ってもsudoしてコマンド打ち込んだり、エディタで設定 ファイル開いて書き直すみたいなことになっている。多くの人を取り込もうと思うのならば、この辺をGUIで何とかした方がいい。
OSの動き全体をコーディネートする人がいて、その人のポリシーを実現しようとするような集団が後ろについているような状態、つまり会社内の命令系統のような形でチームが固定化されないと、なかなかすべてをGUIでデザインするのは難しい。
そのあたりが、多くの推進力を有志のプログラマ集団に依存しているGNU/Linuxというものが構造的に抱え続けている問題だと思う。
この融合については、いくつか方法を試したり、検討がなされていたりしている。
昨日、テクニカルコミュニケーター協会（TC協会）シンポジウムでのパネルディスカッションの事前打ち合わせのために、TC協会理事の高橋さん、HCD-Net機構長の黒須さん、ソシオメディアの篠原さん、テクニカルライターの高橋さんなどとミーティングをしてこのテクニカルライティング業界でも同じようなことが起きていることに気づいた。
テクニカルライティングは、通常「マニュアル執筆」という形をとることが多いが、これはわりと後工程として製品私用ができあがってから、その説明書、という形で書かれる、ことが多いようだ。
が、いま情報プロダクトを企画するとき、「どう使えるのか」というメッセージは、説明書で説明するものではなく、機器自体に埋め込まれていなければならない（あるいは箱に書いてある、とかでもいいかもしれないけど）。
この部分にテクニカルライティングの専門家が関与していない、できていない、というのは大変もったいない。
「テクニカルライティングの専門家」がどこからどこまでの領域の技能を指すのかは定義が難しいような気がするが、そこが明らかになれば、サービスや製品の企画・設計の段階にもっと関与できるようになると思う（というか、参加していただきたいです）。
若干はしょり気味で書いたのでわかりにくいですが、今後深掘りする必要があるテーマに思う。