誰に何を伝えたくて書くのか。
文章を書く際、大事にしたい観点のひとつと考える。
エンジニアとしてドキュメントをアウトプットする場合は楽だ。大体は、書き始める前から そのドキュメントの目的が明確になっている。
たとえば「提案書」。顧客の要件を再定義する。その要件に対して自社の売り物がどれだけ適っているか。また、顧客の要件を超えてメリットを生み出せる売り物なのか。それらが顧客に伝わるように表現するドキュメント。
たとえばITインフラにおける「基本設計書」。システムを構成するための基準となる設計方針を著す。システムの構成パラメータを決定したり、システムのテスト内容を決定したりする際の基準を示す。それらがシステムを取り扱う人たちに伝わるように表現するドキュメント。
とはいえ、意外とそうなっていないドキュメントを目にすることは多い。執筆者の独りよがりになっているパターンだ。唐突な略語。説明のない表や箇条書き。Googleで検索できたりマニュアルに載っていたりするような内容ばかりに終始して、「提案」や「設計」が載っていない。など。
こういった読み手に意図が伝わりづらかったり無駄に冗長だったりするドキュメントは なぜ生まれるか。
「執筆者の独りよがり」で片付けてしまうのは簡単だが、それじゃ不毛だ。
僕は「文書を著す目的がちゃんと定義されていない」ことが原因だと考える。
設計書や提案書といった類のドキュメントは そのタイトルに意味が定義されているので、目的が表現されていないことが多い。あったとしても「１．目的」に「本書は、xxxxxシステムを構成するための基本的な設計方針を記載する文書である」といったことが書かれているレベルだ。
顧客だったりに提示するドキュメントとしては これでも十分とは考えるが、プロジェクトで多数の人が見て参考にすることを考慮すると、もう少し深掘りしたい。
その深掘りが本記事のタイトル「誰に何を伝えたくて書くのか」である。
ITにおける基本設計書の執筆を例にする。読み手が「基本設計書」の意味を通例で理解している人であれば恐らく問題ない。(それでもブレは生じるとは思うが。)
プロジェクトでドキュメントを読む人は多種多様だ。特定の技術に疎い人もいれば、そもそもITプロジェクト遂行の経験が浅い人もいる。なので、さまざまな人が読む場合の前提条件を揃えたい。
冗長になるためドキュメントそのものに書く必要はないかもしれないが、メモなのか口述なのか、少なくとも「誰に何を伝える」ことを前提としたドキュメントであるかは定義しておきたい。すなわち「前提条件」の定義だ。
ITプロジェクトで作成する基本設計書であれば、以下のようなことを定義する。
・スコープ。「プロジェクトAのシステムBについて著す」
・目的。「基本設計以降のフェーズにおける設計の基準とする」
・対象者。「製品Cに関する基礎知識として、資格D相当の知識を持っている人」
・基準。「要件定義書Eで定義された要件を基に設計する」
前提条件を定義するのは、読み手のためだけではない。書き手にとっての意識付けにもなる。
熱中して書いていると、ふと目的を見失ってしまうことがある。そこで記載内容の方向性がズレたとすると、そのまま どんどん書き進めてしまって わけの分からないドキュメントができあがる。
それを防ぐために目的を見失ったら都度、前提条件の定義を読み直す。改めて「誰に何を伝えたくて書くのか」という前提条件を念頭に置き直して再開する。
この前提条件が書き手にも読み手にも共通していると、システムの設計はブレにくい。事故発生リスクの低減や手戻り発生時の対応スピード向上にも繋がるはずだ。
長くなってしまったが、ITにおける基本設計書を例に「誰に何を伝えたくて書くのか」を定義することの大切さを述べた。
ところがだ。
実は この文章には それがない！笑
「誰に何を伝えたくて書くのか」を定義するのが難しいのが この手の雑記系文章だと思う。
というのは、基本的に自分が考えていることを ただそのまま表現するだけだからである。
誰に何を、みたいなことは正直あんまり考えていない。
しかし やはり、それだと読み手に不親切だし、書き手としても文章の一貫性を確保できないような気がする。
ということで、これからは ちゃんと やってみたいと思う。
ネタ切れ気味になっていることに加えて、そんな枷を掛けると更に筆が重くなる気がして億劫だったが、大事なことだと思うので やってみよう。目的の再考だ。
次回は改めて、ここで書いている記事について「誰に何を伝えたくて書くのか」の定義にチャレンジしてみようと考える。
なお今回の記事は、主にビジネスパーソンを対象に、ドキュメントをつくる際に必要な心構えを伝えたくて書いた。それは、文章の目的を定義することの大切さを多くの人に理解してもらい、これから文章を書く際に多少なりとも心がけてもらえれば、世にあふれる文章の品質向上に少しでも繋がるかもしれないという思いだ。また、自分自身ができていないことも多いので、振り返りと自戒の目的も含んでいる。
文章の品質が上がると、たとえばITプロジェクトであれば炎上の原因となる認識相違の発生を減らせる。契約や事務などの業務でも同様だ。
自分の経験を基にした この文章が、少しでも人の幸せに繋がったなら僥倖と思っている。
Discussion