句点はどこに打ちますか?

突然ですが、こんな質問を受けたら、みなさんならどのように答えるでしょうか。

問1
文末にカッコ書きがある文章の場合、句点(。)はどこに打ちますか?
  • <パターン1>句点はこのように打ちます(カッコ内はこのようになります)。
  • <パターン2>句点はこのように打ちます(カッコ内はこのようになります。)。
  • <パターン3>句点はこのように打ちます。(カッコ内はこのようになります)
  • <パターン4>句点はこのように打ちます。(カッコ内はこのようになります。)

上の問に対する補足となります。
・<パターン1>と<パターン2>は、カッコ書きの後に句点を打っています。
・<パターン3>と<パターン4>は、カッコ書きの前に句点を打っています。
・<パターン1>と<パターン3>はカッコ内の文章には句点を打っていません。
・<パターン2>と<パターン4>はカッコ内の文章にも句点を打っています。

「…こんなのどうでもいいじゃないか」と思った方もいらっしゃることでしょう。しかしながら、筆者が関わっているPMOという仕事では、しばしばこのような、一見どうでもよいことが大きな問題になるのです。

上の問に対して、PMOは最も合理的な回答を1つだけ選んで、「文書標準」というものに表さなければなりません。最も合理的な回答とはどのパターンでしょうか? 答えは一旦後回しにして、まずは「PMO」という仕事について、そして「文書標準」というものについて、簡単に説明したいと思います。

「PMO」と「文書標準」の簡単な説明

「PMO」とは、「Project Management Office」の略です。

ある目的の達成のために期限付きで編成された複数のメンバーから成る「プロジェクト」が、予定どおり進むように運営・支援するチームのことです。少人数のプロジェクトであれば一人のマネージャが運営・支援することも多いでしょう。
しかし、プロジェクトによってはメンバーが数十人、数百人、ときには千人といった規模になり、とても一人のマネージャだけでは運営・支援しきれなくなります。
PMO自体にも規模の大小や性質の違いはありますが、この連載におけるPMOは、このような中規模~大規模プロジェクトに対して編成される運営・支援チームのことをいうものとします。

「文書標準」とは何でしょうか?

PMOが運営・支援するプロジェクトには、多くのメンバーが関わり、また多くの文書が作られます。
各メンバーがそれぞれ勝手な体裁で文書を作ってしまったら、それらの文書を読む「読み手」側の立場としては、読みづらくて、書かれている「内容」になかなか集中できません。
文書を作る「書き手」側の立場からいっても、「文末にカッコがあるときには句読点はどこに打つのが正解かな?」などと細かいことに迷っていたら、自分が書くべき「内容」をいかに表現して伝えるか、という肝心な部分に集中できません。

「問1」でみなさんに質問したような、文末にカッコ書きがある場合の句読点の位置といった細かい点でさえ、各メンバーが異なった書き方をしていたら、多くの文書を読んでいるうちには意外に気になってくるものです。

そこで、一般的にプロジェクトでは「文書標準」を用意し、章番号や項番の付け方・フォントの種類や大きさ・字下げの仕方といった「体裁」をはじめとして、用字・用語の使い方、句点や読点といった記述符号の表記ルールなどを定めます。
まとめると、「文書標準」は、読み手も書き手も文書の「内容」に集中できるように、文書の「書き方」を定めたルールブックということになります。

この「読み手も書き手も文書の「内容」に集中できるように」という「目的」の部分は大変重要なので、頭の片隅にとどめておいていただきたいと思います。

「残念な文書標準」とは

筆者はITコンサルタントとして、民間企業や公的機関のさまざまなプロジェクトに関わり、多くの場合PMOの一員としてプロジェクトの運営や支援を行ってきました。「文書標準」の策定に関わったこともあります。そして、中には失敗してしまった経験もあります。
「文書標準」が失敗するというのはどういうことでしょうか?
それは、以下のような事態です。
・ 文書標準で定めたルールが合理的でなかったために、後から想定外の事態が次々と起こって、その都度ルールを書き変えたり追記をしたりしなければならなくなる。
     
・ だんだんルールが複雑化してくるので、メンバーは「この場合にはどういう書き方をするのが正しいんだっけ?」と、都度都度、文書標準を確認しなければならなくなる。
     
・ だんだん面倒くさくなって、誰も文書標準に従わなくなる。
     
・ 結局、「読み手も書き手も文書の「内容」に集中できるように」という「目的」が達成できない。

いかがでしょうか?何とも残念な事態です。
このような「残念な文書標準」を策定しないためには、最初からなるべく合理的に判断して、ルールを定める必要があります。
しかし、何が合理的なのか、どういう事態をあらかじめ想定しておく必要があるのか、なかなか考えが及ばないところであり、これが「文書標準」を策定するうえで最も難しい点になります。

公用文ルールを文書標準に生かそう

ここでようやく、「公用文ルールを文書標準に生かそう」という、このブログ連載のテーマにつなげることができました。
筆者はここ数年、官公庁のプロジェクトに関わってきました。そして官公庁で作られる文書の書き方、つまり「公用文ルール」には大変合理的な部分があることを知り、そのような部分は民間プロジェクトの文書標準にも積極的に応用できるのではないか、と考えるようになりました。
逆にいうと、民間プロジェクトの文書標準には必ずしも応用できない部分もある、ということになります。どういう部分が応用可能で、どういう部分が応用できないと筆者が考えているかは、次回以降の連載でおいおいと表していきたいと考えています。

さて、最初に書いた「問1」の質問ですが、みなさんがPMOの一員なら、どのパターンを文書標準に採用するでしょうか?
間違ったパターンを選ぶと、後でメンバーから「文書標準にはこう書いてあるけど、こんな場合にはどう書けばよいの?」と質問を受け、ルールを追加しなければならない事態になるかもしれません。そうなると、「残念な文書標準」の第一歩を踏み出してしまいます。

最も合理的だと筆者が考えるパターンは、公用文ルールに一致しています。その答えと解説は、長くなるので次回のお楽しみにさせてください。


なお、このブログの文章そのものは、公用文ルールには必ずしも従っていません。公用文ルールをそのまま適用すると、堅苦しくなりすぎる場合があるからです。次回以降も、どうか気軽に読んでいただきたいと思います。単なる話のネタとしていただいても結構ですし、また実際に文書標準を検討するときの参考にしていただけたら大変うれしいです。


会社ホームページでは、HYBRIDE(ハイブライド)がソリューション提供する「データ分析」「業務改善」「プロジェクト推進」を紹介しております。
HYBRIDE(ハイブライド)の公式Facebookページ