可読性の低い文書は未来に害を残す
日本において、設計書というとその大半は日本語で記述します。
そして、その日本語表記の大半はほぼ自然言語となっています。
自然言語とは、
のことを指します。口語/文語の表現の違いはあれど、要する普段使っている言葉遣いのことです。
たとえば、次のような感じです。
自然言語を普段使っていてもなんとなくコミュニケーション等が成立するのは、こうした言葉の表現として足りない部分を読み取る側が脳内補完するからです。いわゆる読解力によって補助されているからです。
しかし、読解力というものは人間一律みな同じというわけではありません。
そこで発生するのが「認識齟齬」というトラブルです。
プロジェクトあたりにおける認識祖語の発生確率はほぼ100%であり、その頻度が高ければ高いほど、齟齬による認識の乖離が大きければ大きいほど、トラブル被害の割合は大きくなっていきます。
にもかかわらず、その方が良いと判断するマネージャーやエンジニアもたくさんいます。もちろんそう判断する大半の人には「根拠」なんて何一つありません。
「今までそうしてきたから(変えないほうが楽)」
「それで問題が起きなかったこともあるから」
くらいしかないのではないでしょうか。
しかし、前者の場合はただの習慣化の問題でしかありません。確かに切り替えることによって生じる初期の苦労(=スイッチングコスト)はかかるかもしれませんが、それだけでは所詮は慣れの問題でしかありません。
もし、慣れてしまえばどちらも効率は変わらないとした場合、切り替えることで「問題の発生率をグッと抑えることができる」という効果がついてくるような方法があるのであれば、慣れるまでの初期投資としてはその甲斐があるというものです。
また、後者の場合は、「起きなかったこともある」かどうかは問題ですらありません。ここで問題なのは「起きたことが(少なからず)あった」これまでの実績に対して、その起きる確率を減らそうという論点ですので、過去に何度か問題が起きなかった事例があったとしても関係ありません。むしろ「1度も問題が起きないようにするためにはどうするべきか」「問題が起きる確率を下げるためにはどうするべきか」という話をしているのです。そのために自然言語を用いた様式が問題要因となるのであれば改善するのは当然のことです。
みなさんは「根拠」の無い、勘や感覚に頼っただけの決定に信頼を寄せることができますでしょうか。
自然言語が問題を起こしかねない一例として次のようなものがあります。
はい、みなさんは「取引先」と「トラブル」どちらに「厄介な」という副詞がかかっているように見えますか?
厄介なのは「取引先」ですか?それとも「トラブル」ですか?
こうした言葉と言葉の関係性を指し示すものを
係り受け
といいますが、これが人によって自由に、好き勝手に、グチャグチャに使われているために自然言語の多用はかならずコミュニケーション不良を引き起こす原因となってしまうのです。
ほかにも
これは、どのように解釈すればいいでしょうか。
「二重にして、首にかける数珠」ですか?
「二重にし、手首にかける数珠」ですか?
これは一休さんが出したとも、近松門左衛門が出したともいわれている問題です。読点(、)や漢字変換などで区切りをはっきりさせなくては、誤解が生まれてしまう一例です。
先の「厄介な取引先とのトラブルを放置してはいけない」も同じです。
問題を出しておいて恐縮ですが、この文だけでは「取引先が厄介なのか」「トラブルが厄介なのか」決めることはできません。本来は、読み手がどちらか迷わないよう係り受けを意識して明確に書くべきでしょう。
たとえば、取引先が厄介なのであれば
「あの取引先は厄介だ。あそことのトラブルは放置してはいけない。」
また(取引先との)トラブルが厄介だというのであれば
「取引先とのトラブルが厄介なことになったら放置してはいけない。」
というように書き改めるべきなのです。設計者本人のボキャブラリや日本語能力に問題がある…と言えばそれまでですが、それは根本的な問題(真因)にはなりえません。
もし、それが根本的な問題であるならば、そうした問題をほとんど起こさずにビッグプロジェクトを成功させてきた世の中の多くの優秀なリーダー、マネージャーは個々人の言語能力を均一化する術を持っている…と言うことになります。
しかし、そんなことは世界人口60億人以上いても誰もできはしません。
他にも区切り目がわかりづらく、読みにくい文を挙げます。
矢印の先の改善例と見比べてください。
少し時間を空けて音読してみると、読みづらい箇所がよくわかります。
上の「×」のような例文はスムーズに音読できません。
また一般に、こうした読みづらさは一文が長くなるほど発生しやすいものです。
主語と述語関係がねじれてしまう現象も長い文ほど発生します。
過去にも何度か「品質不良はコミュニケーション不良」と説明したことがあったと思いますが、品質に
成果物品質
プロセス品質
マネジメント品質(コミュニケーション品質も含む)
等があるとしたら、結局のところトータルの「品質」を向上すれば、トラブルのみならず、不良も起こりにくくなる、と言うことを意味します。
ドキュメントを作成せず、情報を記録化しない
ドキュメントの可読性が低く、不良の温床になっている
これらはすべて、必ずトラブルや大惨事に影響を与えていることを自覚しておきましょう。そのうえで
「自然言語」
を多用しないコミュニケーション方法というものをもう少し前向きに考えてみてはいかがでしょうか。「全く使わない」というわけにはいかないと思いますが、「なんとなく」「今までそうだったから」「面倒くさい」を言い訳にして、これまで通りの進め方を確信犯的に踏襲することが本当に自分のため、チームのため、会社のため、社会のためになるのか考えてみてください。
少なくとも、そんな進め方に問題があると考えたからこそ2000年前後に
UML(Unified Modeling Language:統一モデリング言語)
が生まれましたよね。まぁUMLが作られたそもそものきっかけは、グローバル化が進む中、生まれや育った国ごとの「言語」「コミュニケーション」の特徴や癖によってお客さまやエンジニア同士の意思疎通が非常に困難となり、そのことが市場を圧迫している…という背景から作られたものですが、私はこうした問題を国家間だけのものとは考えていません。
あたりまえですが、個人間でもこうした問題はあると考えています。誰しも生まれや育ちは違いますし、その過程で得た知識や認識、表現力や読解力だって100人いれば100通りあることでしょう。
だからこそ、個々人のこれまで身につけてきた教養結果が表れやすい自然言語を多用するコミュニケーション方法に危険性を感じてなりません。
日頃の何気ない会話であれば問題はないでしょう。直接会話するようなケースなら表情やしぐさ、間の取り方で読み取れる部分も増えるかもしれません。長年付き合ってきたお客さま担当者とエンジニアであれば意思疎通に問題が生じないかもしれません。
ですが、新規参画者や引継ぎは必ずできますし、毎年何十人と新卒採用している企業だってあります。人は必ず定年をむかえ、次の世代にバトンタッチする日が来ます。
ITシステムなら、リリースされて5年や10年経過した後にサポート切れや老朽化に伴う再構築(リプレース)が必要になることだって普通にあります(というかそれが一般です)。その時に、次の世代に情報渡すという意味で残された「設計書」や「仕様書」、あるいはソースコードのなかに記述されたコメント(ソースコード自体も)が、次の世代にとって齟齬を発生させにくい表現・表記となっていなければ、5年越し、10年越しのトラブル要因を仕込んでいたということになりかねません。
それでもコミュニケーション齟齬を発生させやすい表現・表記方法を個人能力に依存させたまま継続して用いるのが正しい選択といえるのでしょうか。