はじめに
このエントリは、（ソフトウェアの）テクニカルライティングの文章について考えた結果をまとめる連載の2つ目である。
なお、このエントリは勤務先で新人や若手向けに行おうとしているテクニカルライティング講義の予習としてまとめているものである。
- イントロ：テクニカルライティングに求められる文章とはなにか https://qiita.com/pujeba/items/b4be9417c018b66c1f82
なぜソフトウェア技術者は日本語を書かねばならないのか
連載の2つ目では、「そもそもなぜソフトウェア技術者は日本語を書かねばならないのか」という問いについて考える。
単に「エンジニア」といった際に「ソフトウェアエンジニア」を暗黙的に指すことも多くなったが、いったん漢語の「技術者」に読み替えて論を進めてみる。
最近Twitterの一部界隈にウケている書籍「誇り高き技術者になろう」（名古屋大学出版会）では「技術者の仕事は、自分の判断に基づいて他の人の生活に大きな影響を与えることができる」としている。すると、「私はXXという根拠を持ってYYという判断をして、ZZという製品（あるいはコンポーネント）を作りました」と説明する責任が生じる。このとき、「ソースコードを読んでください」で責任が果たせればよいのだが、残念ながらそうはいかない。この理由は大きく2つある。
- 誰もがソースコードを読めるわけではない
- ソースコードの背景にある思想や使い方をソースコード自身は説明しない
お仕事としてあなたが作るソフトウェアに関わる人はコーダーだけではない。エンドユーザーや営業、それにヘルプデスクといった比較的内部構造に詳しくない人も多くいる。そういった人に「ソースコードを読め」というわけにはいかない。作った人が作ったものを日本語で伝える責任を負う。
更に、ソースコード自身は「なぜその設計を選択したか」「プログラム全体としてどのように使うか」ということに関しては説明してくれない。背景や前提、それにボツとなった実装案を全部ソースコードコメントに記録するというゴリ押し案も理論上はありえるが、そんなことをしたらコードの保守性は壊滅的に悪くなってしまう。何より、プロプライエタリソフトウェアの場合、社外の人間にソースコードを開示するわけにはいかない。
ソフトウェアの背景や使い方をソースコードから自然言語で書かれたドキュメントとして分離することで、ソフトウェアのコアであるソースコードと説明を分離し、ドキュメントは性質に応じて技術者からの距離が遠い立場の人たちにも公開するのである。
先の説明でも少し触れたが、お仕事としてのソフトウェアで最も重要なことは「様々な立場や技能を持った人が集まって一つのものを作り上げている」という事実を常に心の何処かにもっておくことである、と私は考える。これはコーダーのみに限った話ではなく、SEや営業、ヘルプデスク、マネージャーに対してもいえる。
特に難度の高い製品を作るとき、誰かを動かさなければ良い仕事はできないし、良い仕事ができなければ修正や作り直し、最悪の場合は勤務先の経営難という形で将来の自分たちの首を絞めることになる。そして誰かを動かすためには自分の思っていることを整理して、相手に寄り添った説明をして、納得してもらうことが不可欠なのだ。その意味で、テクニカルライティングはビジネス文書に通じるところがあると考えるし、技術者のためだけのものではないとも言える。
参考文献
- 黒田光太郎, 戸田山和久, 伊勢田哲治(2004), 「誇り高い技術者になろう」, 名古屋大学出版会
- 高橋麻奈(2005), 「入門テクニカルライティング」, 朝倉書店