なぜ研究開発で成果を出せないのか？
若手のエンジニア・研究者には，研究開発で十分な成果を出せずに悶々と悩んでいる人が少なくないと思います。目の前の課題に集中し，それを解決できるアプローチを自分なりに必死で考えて結果を出しても，なかなか具体的な成果として認められない──そのように悩むエンジニア・研究者には，実は共通の傾向があります。
例えば，研究開発の進捗報告書を上司に提出すると，「さっぱり分からん」と首をかしげられ，そもそもこの研究開発を進めている目的や前回の報告内容まで立ち返ったうえで，今回の報告の趣旨を確認されることがあるのではないでしょうか。あるいは，チーム内で議論するための技術検討会（大学の研究室で言えばゼミナール）で発表しても，聞き手の反応が薄かったり，自分が発表した内容からずれた部分で議論が進んだりしないでしょうか。なんとなく心当たりがあるとすれば，それは研究開発における自身の取り組みを適切に言語化できていないことが原因です。
こう指摘すると，内心で腕に覚えのあるエンジニア・研究者ほど意外に感じるかもしれません。なにも手を抜いて技術資料を作っているわけではない，むしろ自分の取り組みに初めて接する人でも理解できるように，全体の構成を考え，新しいアプローチを詳細に説明し，実験結果を示すグラフを工夫していると反論したい気分になるでしょう。そして，ここまで説明に労力を費やして伝わらないのは，受け手に理解する能力が欠けているからだと憮然としてため息をつきたくなるかもしれません。
その気持ちはよく分かります。私が大学・民間企業で研究開発に携わっていたときも，そう指摘されて同じような気分になったからです。しかし，研究開発の現場から退き，いろいろな経緯を経てそれを俯瞰する立場になってから当時を振り返れば，言語化できている「つもり」という重大な誤解こそが成果を出せない原因だったと気づいたのです。
「理解できない」と言われ続けたエンジニア・研究者時代
ここで，少し私の経験を語ります。
大学院時代に指導教官だった教授は，私が新しく書いた論文の初稿を受け取るたびに，毎回私を自室に呼び出し，「君が書いた論文を読んでも，研究の内容を理解できない。論文にまとめた成果をここで説明してください」と口頭で詳細を述べるよう求めました。教授は黙ってそれを聞き，初稿を朱筆で修正しました。最終的に学会や学術誌に投稿する段階では，私が書いた文章はあまり残らなかったので，筆頭著者として論文に私の名前が載ることが恥ずかしい気分でした。
もちろん，私は手を抜いて書いていたわけではありません。それどころか，「同じ分野を研究する専門家であれば，さらりと読むだけでその全貌が理解できるだろう」といつも考えながら書いていたのです。つまり，誰に何と言われようと，私は自分の文章力・プレゼンテーション力に根拠のない自信を持っていました。そのため，朱筆の指示どおりに初稿を修正しながらも，「指導教官として私自身より研究内容を熟知している教授が異なる視点から文章を推敲すれば，読みやすくもなるだろう」と軽く考え，「理解できない」と言われた本質を深く考える機会を放棄してしまいました。
大学院を修了し，民間企業でデータサイエンティストとしてデータ分析の研究開発に携わっていた時代も同じでした。「もっと分かりやすく内容を説明してください」と，知的財産部から発明届出書（特許出願のために技術の内容を詳細に説明する文書形式の資料）を戻されるたびに，「この内容がなぜ理解できないのだ」と逆に憤慨する始末でした。
「自分の書き方に問題があるのではないか」と反省することもありませんでしたし，まして「知財担当者を納得させられない技術資料しか書けない自分は，自身で開発した技術の本質を理解していると言えるだろうか」と疑いを持つこともありませんでした。そればかりか，「そもそも，エンジニアは技術開発が仕事であって，発明届出書を書くなど雑用だ」と言い逃れをして，知財担当者を困らせていました。
その後，私は弁理士資格を取得して特許事務所に転職し，特許明細書の書き方について集中的に指導を受けました。特許明細書は，特許権の実体を規定する「権利書」であると同時に，発明の技術的な内容を開示する「技術文書」です。つまり，これまで私が根拠のない自信を持ったまま，真剣に取り組んでこなかった「テクニカルライティング」（技術文書の作成方法）を徹底して学ぶことになったのです。
そこで初めて，私がエンジニア・研究者だったころに書いた論文や技術資料は，コミュニケーション能力の足りないダメ資料であったことに気づきました。自分がこれまで「当然できている」と確信していたことを，「全然できていなかった」と痛感したわけですから，相当なショックでした。
文書作成のための言語化能力と実務能力は相関する
同時に，興味深いことにも気づきました。それは「発明として技術的な完成度が高いほど，それを説明する資料の内容を理解しやすい」ということです。
弁理士は，クライアントから発明届出書を事前資料として受け取ったうえで，その内容の詳細を発明者（エンジニア・研究者）から直接ヒアリングするという段取りで特許明細書を書き上げます。このとき，発明届出書を一読するだけでヒアリングなど不要と感じられるほど，その本質から詳細まで明瞭に理解できる場合もあれば，どれほど届出書を深く読み込み，注意深く発明者の話を聞きながら技術的な内容を掘り下げても，なかなか理解できない場合もありました。そして，後者の場合より前者の場合の方が，エンジニア・研究者として優秀な人が多く，発明の質も高い傾向が明らかだったのです。
これに気づいたとき，私は「優秀な人が優れた成果を出したから，優れた資料を書くことができたのだろう」と安易に考えました。そして，私はエンジニア・研究者として優れた成果を出せなかったから，ダメ資料しか書けなかったのだと納得したのです。なるほど，要するに才能の問題で，私はエンジニア・研究者に向いていなかったのだと。
ところが，いつも優れた技術を開発し，分かりやすい届出書を出すエンジニアに「発明の秘訣は何ですか」と質問してその回答を得たとき，私はその納得が早合点であり，因果を逆に理解していたと気づいて衝撃を受けました。
彼は，日常的につけている開発ノートを，そのときこっそり私に見せてくれました。そこには，研究開発に関する彼の取り組みがびっしりと詳細に書かれており，初めてノートを見る私でも，彼が何を考えて研究開発を進めたかが手に取るように理解できました。例えば，先行技術の要点，未解決の課題，課題が生じる原因に対する仮説，それに対して可能なアプローチ，それらのアプローチの先行技術との差異，それらを試した結果，その結果が生じた理由に対する仮説，それを検証する次のアクションなど……研究開発で必要になる情報やそれを自分なりに解釈した思考の流れが，一冊の開発ノートにすべて美しく整理されていました。
このとき，「優れた成果を出したから，優れた資料を書けた」のではなく，「日ごろから自身の取り組みを言語化して研究開発に取り組んだから，優れた成果を出せた」という因果が真実であることに，私はようやく気づきました。つまり，「思考を言語化できる」（正しく文書作成できる）ことが「研究開発の成果」に直結するという現実を目の当たりにして衝撃を受けたのです。ということは，ダメ資料ばかり書いて「理解できない」と言われ続けたのに，なぜか「当然できている」という妙な自信と誤解を抱えたまま思考を適切に言語化しなかった私が，エンジニア・研究者としてイマイチだったのは，実は必然だったのです。
もし，早い段階で「言語化」の重要性とその正しい作法を身につけられていれば，いまも研究開発の最前線で戦えていたかもしれない──この現実に気づいたとき，「理解できない」と指摘された本質を謙虚に受け止めなかった自分がさすがに情けなくなりました。
テクニカルライティングで成果を上げる
思考整理のための「黄金フォーマット」
私が本書をとおして読者に伝えたいことは，たった1つだけです。それは「正しいテクニカルライティングの作法を身につけて思考を整理し，それを正確に言語化できるようになれば，研究開発で継続的に成果を上げられる」ということです。
論理的に文章を組み立てる過程をとおして，自分の思考を整理する方法論に触れる機会はなかなかありません。特に，技術的な内容を正確に他人に伝える枠組みは，長いサイエンスの歴史をとおして確立されており，それが思考の整理にもたらす効果が大きいことも間違いない事実ですので，本来は必修科目として学生に教えるべきだと私は思うのですが……残念ながら，大学の教養課程でもテクニカルライティングの作法を体系的に教えるカリキュラムは少ないようです。
私の場合は，発明者の思考を整理・明確化し，弁理士として自分の仕事を進めるためにテクニカルライティングの作法を身につけられました。しかし，こうした偶然がなければそれを知ることすらできないという事実は，日本の科学技術の見通しを悪くしている1つの原因になっていると思います。
本書では，言語化の重要性，特にエンジニア・研究者が研究開発を進めるうえで必須となる「テクニカルライティングをとおした思考の整理法とその具体的な方法論」に焦点を当て，それを集中的に説明しています。そのため，メインタイトルに「テクニカルライティング」という用語が入っており，具体例を紹介しながらその作法を解説するという「解説本」の体裁をとっているものの，「美しい技術文書を書く」こと自体を目的としてこれを解説する本では当然ありません。サブタイトルにあるとおり，本質的には「思考整理」の本です。
言語化のプロセスを経て思考が整理されると，まだ思考が十分に詰まっていない部分に気づくことができます。その部分を追い詰めるようにさらに言語化を進めれば，また新たな気づきがあり，言語化の余地が生まれます。このように，自分がいまどのような情報に基づいて何を考えているかを，まずは自分自身にうまく伝えることが重要です。本書は，その伝え方の枠組みを「テクニカルライティング」という切り口で説明します。
研究開発の現場における言語化は，自身の取り組みを大きな技術トレンドのなかで位置づけることによってオリジナリティを明確化し，そのオリジナリティによって課題解決に寄与したインパクトを正確に評価することを意味します。言い換えれば，その研究開発に着手した背景から最終的に得られた結果までを立体的な関係性で結び，1つのストーリーとして繋ぐことです。多くのエンジニア・研究者は，日常の業務に追われてこのプロセスを疎かにしがちなのですが，これを簡易に実現する手段として，本書では「黄金フォーマット」にのっとって技術の内容を表現する方法を紹介しています。
技術に関する新しいアイデアを適切に位置づけ，これを言葉にして見える化することには専門のスキルが必要となります。しかし，フォーマットを用いれば，記載の自由度が下がった分だけそれが容易になり，自然とオリジナリティとインパクトを明確にできます。その結果，自身の取り組みの全体像を明らかにするという思考の訓練を無意識にできるため，研究開発で成果を上げやすくなります。
本書の構成と各章の概要
本書は，全部で6章から構成されています。
まず，エンジニア・研究者には，研究開発を推進する実務能力だけでなく，その内容を分かりやすく他人に伝える「コミュニケーション能力」も必要になること，そして，そのコミュニケーション能力とは具体的に何であり，それが実務能力とどのように関係しているかを最初に説明しています（第1章前半）。
また，エンジニア・研究者は，自身の取り組みのオリジナリティを明確化し，インパクトを評価することが求められます。もしこれが適切にできなければ，個人として，組織として，どのような弊害を招くかについても詳細に説明しています（第1章後半）。さらに，「思考を言語化できる」（正しく文書作成できる）ことと「研究開発の実務能力が高い」こととがなぜ相関するかについても，掘り下げて説明しています（第1章後半）。
次に，正確なテクニカルライティングを実践するための具体的な方法論を解説しています（第2章前半）。本書で提案するのは，「黄金フォーマットにのっとって言語化する」という普遍的な方法論です。
詳しくは本編に譲りますが，ダメ資料を書いてしまうエンジニア・研究者は，たいてい「読書感想文の罠」に陥っています。これは，小学校で多くの人が教えられる「心に感じたことを自由に表現しましょう」というエッセイ的な思想です。しかし，この思想に捕らわれたままでは，技術資料を書こうとしても「技術資料っぽいエッセイ」にしかなりません。自分の感じたことを自由に表現するフリーフォーマットのエッセイは，オリジナリティとインパクトを浮き彫りにする技術資料と対極にある文書です。本書では，この罠に陥らないように，黄金フォーマットを活用する方法を提案しています。
研究開発の過程でフォーマットに厳密に合わせて万全のテクニカルライティングを実現することは困難でしょうが，前述した優秀なエンジニアが実践していたように，これを意識しているのといないのとでは課題解決に向かう精度に大きな差が生じることを，具体例を出しながら説明します（第2章後半）。また，フォーマットにのっとって自身の取り組みを言語化した後，成果を他人に伝える目的に応じてそれを再構成する方法についても解説します（第2章後半）。
そして，本書の後半（第3章～第6章）では，エンジニア・研究者が実際にテクニカルライティングを実践するシーンを想定し，各シーンでダメな例と理想的な例を具体的な内容を用いて説明しました。特に，黄金フォーマットにのっとって技術的な内容を正しく言語化できていることを前提として，それぞれに固有の注意点を掘り下げて説明し，より伝わりやすい技術文書・資料に仕上げる方法を説明しています。
最初に，第3章では，進捗報告書（週報）の書き方を解説しました。報告を受ける側が報告してほしいと考えている内容を理解し，それを伝わりやすく端的に要約するというコミュニケーション能力の本質を最も如実に示す形式が，「報告書」だからです。
次に，第4章では，テクニカルライティングによる文書作成を基礎にした技術プレゼンテーション資料の作成方法を解説しています。エンジニア・研究者が社外のコミュニティで成果・知見を共有する場が増え，個人のブランディングや技術力向上のきっかけとなるチャンスが増している背景を考慮しました。
そして，第5章では，研究企画書の書き方を解説しました。企業における研究開発の企画や学術機関における科研費の申請などにおいて，エンジニア・研究者が主体的に研究開発の内容を企画できれば，その自由度も高くなり，成果を上げやすくなるからです。
最後に，第6章では，本書の総括として論文・国際学会予稿・技術報告を書く際の注意事項をまとめました。特にIT分野を中心として，民間企業でも論文発表を後押しする傾向があるからです。
部下・学生の指導にも役立つ文書作成の方法論
私は，主に若手のエンジニア・研究者に向けて本書を書きました。しかし，その若手を指導する立場にある管理職・チームリーダ・教員の方々にも読んでいただき，正しく言語化することの重要性を若手の部下や学生に伝えてほしいと考えています。
専門知識を備えた優秀な若手でも，技術資料を書かせると「技術資料っぽいエッセイ」を出してくるケースは，どこの企業・研究室にもあるのではないでしょうか。「文章力が不十分なだけだからそのうち改善するだろう」と楽観しがちなのですが，それは誤解です。残念ながら，「文章力」と「思考を言語化する作法」は別物であり，後者を知らないままエッセイしか書けないうちは，その若手が研究開発で十分に成果を上げることはできません。後進が育たなければ「研究開発」という貴重な投資を空費し，ジリジリと開発力を落とすことになりかねません。
とはいえ，「理解できない」と指摘して資料を突き返すだけでは本人も困惑するだけでしょうから，本書で解説するテクニカルライティングの作法を紹介し，本人が自覚していない欠点を自覚できるように促すことが重要になります。
詳しくは第3章で述べますが，私が考える理想の状態は，部下から上がってくる進捗報告書を上司が一読するだけで，PDCAが適切に回っている（研究開発が進捗している）かどうかを判断できることです。つまり，チームメンバーを全員集めて，口頭で順番に進捗を報告・共有させる会議をなくし，300～400文字程度で端的にまとめられた報告書ベースで各メンバーの進捗状況を把握し，このまま任せてよいか，フォローが必要かを判断できることが理想です。私の経験上，進捗確認・共有のための会議は，現場のエンジニア・研究者に余計な負担をかけることが多いからです。
しかし，これを判断できるようにするためには，各メンバーが「上司は何を報告して欲しいと考えているか」を理解したうえで，それを適切に言語化できるスキルを身につける必要があります。本書を用いてテクニカルライティングの勘所を指導すれば，若手を育て，PDCAの精度を上げ，研究開発を加速させられるでしょう。
本書には，私自身が若手のエンジニア・研究者であったころに知っておきたかったことを詰め込みました。かつての私のように「ひとりよがりなダメ資料」を書き，成果を上げるチャンスを逃し続けるのは実にもったいないことです。本書を読まれたエンジニア・研究者の皆さんが，「優れた技術資料」を書くことをとおして優れた技術を研究・開発できるようになれば，著者としてこれに勝る喜びはありません。
