ビジネスライティングスキルを身に付ける狙い・避けたいこと

このセクションでは、システム開発の現場において必要だと考える、ビジネスライティングのナレッジやノウハウをアレコレと語っている。

先に、そもそもどうしてビジネスライティングスキルが必要なのか、どんな効果を狙っていて、どんな問題を回避したいと考えているか、をまとめておく。他の項目で書いているナレッジやノウハウは、いずれもこうしたメリットを享受し、こうしたトラブルを避けたいがための具体的な手法やテクニックであることを念頭に置いてほしい。

目次

ビジネスライティングスキル・ドキュメント作成能力がなぜ求められるか

なぜドキュメントを適切に書けないといけないのか。重要なキーワードは

である。

ドキュメントが直接の成果物であり、目に見えない成果を可視化する術だから

ホワイトカラーの中でも特に SE の仕事には、明確な形を持った成果物が存在しない。自分たちの仕事の成果は、システムの中でもユーザの目に見えて分かりやすい「ユーザインタフェース」と、納品された設計書等のドキュメントのみで評価される。

だから、自分達が何を考慮し、どのようなモノをどうやって作ったか、という成果を外部に表明するためには、ドキュメントを適切に書ける必要があるのだ。

ドキュメントは「システム」よりも有形な成果物であり、情報を可視化するモノだ。ドキュメントなしでは、何がどう大変だったか、どういうつもりでシステムを作ったか、が何も伝わらない。ドキュメントを相手に伝わるように書けなければ、やはり上手く伝わらない。ビジネスライティングスキルがないと、自分の仕事に対して正当な評価をもらえなくなるのだ。

顧客やチーム内の合意事項の記録であり証拠になるから

システム開発で作成するドキュメントは全て、「我々はこう理解しています (間違ってたらツッコんでくださいね)」「皆でこの認識でいましょう」という情報を書き残すモノだといえる。

基本は合意事項の記録であり、工程や執筆範囲によってそれを「議事録」と呼んだり「設計書」と呼んだりしているだけ、と思っても良いだろう。

議事録はニアリアルタイムに展開することで、設計書等はレビューと納品によって「後で『こんなの聞いていない』『そんなつもりじゃなかった』なんて言わないでくださいよ？」と顧客に念押しするための、証拠文書になる。言った・言わないの記録が残っていないと、理不尽で頭に来るような赤字対応が発生したり、最悪は裁判にもなりかねない。

だから、何を話し何を話さなかったか、何に合意し何に合意しなかったか、何を採用して何を採用しなかったか、どうしてこのように設計・作業をしたのか、といった情報を、誰が読んでも分かるように記述できなくてはならない。それこそ裁判に持ち込まれても不利にならないようにするには、対象システムを知らない部外者 (弁護士や陪審員など) が読んだとしても明らかな表現で記述できるスキルが求められる。要は自衛のために、「誰が読んでも分かる文書」を書ける必要があるのだ。

些細なことでもトラブルはトラブル。回避できるなら、予め賢い人間が予防策を打って回避しようではないか。

システムの寿命を伸ばすために必要だから

そのシステムがどういう目的で開発することになり、どういう意図で設計され、今までどういう運用保守作業が行われてきたか。各種ドキュメントがそうした経緯や背景、意図や目的を明言している。

もしもこうしたドキュメントが存在しないと、システムの大部分がブラックボックスになってしまい、「このシステムがどういうロジックで費用計算しているのか分からず、規則改定に合わせた改修ができない」「バグの原因箇所の検討が付かず障害対応が困難」といったトラブルが発生する。数万行に及ぶソースコードを1行残らず丹念に読み、サーバの各種設定を細かく確認し、ネットワークの設定を全て見直していけば、いつかは修正目処を立てられるかもしれないが、爆裂に時間と労力がかかるし、「その対応だけで本当に十分なのか？対応漏れやデグレのリスクはないか？」を担保することが極めて難しくなる。

改修・改善がしづらいシステムは段々評価が落ち、凍結されていく。OS やハードレベルの老朽化対応で「もっと使いやすくしたい」という要望が挙がり、システムごとリプレイスされることになる。せっかく作ったプログラムが、すぐに役立たずになり、捨てられていくのだ。ドキュメントがなくて現行仕様も分からないのに、こうした大規模リプレイス案件が生まれてしまうと、開発メンバはトラウマを抱えること間違いなし、顧客も「いざゴッソリ変わったら慣れなくて使いづらい」とか言い出すので、誰も幸せにならない。ｗ

一方、各種ドキュメントで「○○機能はこういうロジックで計算しています」「○○ロジックは△△機能でも共通利用しています」「将来、税率改定が発生した場合は、プログラムの○○部分で設定を変更して、次の手順で動作確認をしてください」といった情報を残していたとしたら。ドキュメントとソースコードを照らし合わせることで正しさを確認しやすくなるし、影響範囲も確定させやすい。無関係な機能や影響しない場所が明らかなので、調査や対応にかかる時間や労力が少なく済む。

ドキュメントのおかげで見通しの良いシステムであれば、日頃から安心して改修・改善・機能拡張等が行いやすくなる。ユーザの要望や外部の状況に応じてシステムを育てていき、息の長いシステムが低コストで運用できるのだ。もしも全体のリプレイスやシステム分割等が発生する際も、何を引き継ぎ、何を捨てて良いかが見極めやすいので、低コストでリプレイスができる。

よく「ソースコードがドキュメントです」と大真面目に語る輩がいるが、コレは浅はかで間違った考え。ソースコードは「経緯」と「意図」と「書いていないこと」が表現しきれないので、書かれたとおりに動いていることは分かっても、「そのように動くことが果たして本当に正しいのか？」を担保できないのだ。その動作は顧客要望を満たしているのか、そのように動くことをエンジニアが開発時に狙っていたのか、それらの考えは今も変わっていないのか、コードだけでは何も分からない。コードにはそうした「理由」が残しきれないので、ドキュメントによってそこを補い、システムの品質担保、およびシステム寿命の延命を支援するのだ。

ドキュメントによって会話コストを削減できるから

詳細は後述するが、「口頭での会話」は情報伝達の手段として非効率であり、正確に情報が伝わりづらい手法である。それと比べて、文書を共有し読んでもらうような「テキストコミュニケーション」は、読み手と共通認識を作りやすく、所要時間も短く済む、効率的な手法である。

会話そのものは「コレでようやくお互い合意できましたね」「同じ理解を持てましたね」というところがゴールで、実際のシステム開発の仕事は何も進んでいない。議事録等の記録も残されないと、「結局、先週の会議で我々は何を決めたんでしたっけ？」なんていう不毛な時間が消費される。一方で、ドキュメントを作ったりメール文書等で展開すれば、前述のとおりドキュメントは「成果物」になる (転化させやすい) ので、仕事として進んでいるし、その進捗が対外的にも明らかになる。

「会話」はその性質上、話し手と聞き手の時間を同時に消費し、その間の他の作業がストップするので、「何の成果も出ない『会話』というタスク」がクリティカルパスになり、作業遅延が発生する。そのくせ、会話は「何かをした気分」になりやすいので、当人たちはどうして「やった気にはなっているのに成果が伴っていないのか」分析できなかったりする。ドキュメントを回覧するなどの「テキストによるコミュニケーション」は、口頭での会話と比べて情報伝達にかかる時間と労力を削減できるので、その分、実作業に時間を割けるようになる。

伝達手段の時点で、「書くことによるコミュニケーション手段」の方に優位性があるので、上手に書くスキルを養えば、どんどん伝達効率も合意形成の品質も上げていけるのだ。ちなみに、「会話」にも専門スキルが必要なので、「書くのは苦手だけど、話せば伝わるでしょ」といった勘違いはしないように。会話のスキルがないあなたが何時間話しても何一つ伝わっていない。会話術もライティングスキルも持ち合わせていない人なら、一見時間が掛かって難しそうな「テキストコミュニケーション」の方が、全体最適の観点では幾分コスト削減になりマシだ。

ビジネスライティングスキルをもって回避したい状況

逆に、ビジネスライティングスキルがないと、次のような面倒なトラブルを引き起こす。こうした面倒は回避したい。

適切なドキュメントが存在しないことで、対象システムのことが分からない

「コードがドキュメントです」というのは色々な理由から、劣った・誤った考え方なので、ドキュメントがないことは論外。開発段階でも、運用段階でも、関係者全員が苦労することになる。

人に伝わるように書かれていないので、ドキュメントを読んでも分からない

それらしい文書ファイルだけ存在しても、誤解を生むような雑なモノは役に立たないばかりかトラブルの元。ドキュメントは合意事項の記録なので、何に合意し何に合意しなかったのか、誰が読んでも分かるように書けていなければ意味をなさない。

ドキュメントが役に立たないので、会話によるコミュニケーションが必要になり、作業コストが膨れ上がる

「会話」自体が好きで、会話によるコストや必要な専門スキルを軽視している人間は多い。そういう人間達が、21世紀になっても非効率で低品質な「会話」を続けては、「どうして上手くいかないんだろう」とか「業界の進化に合わせて我々も変化を！」とか抜かしていたりする。

「親睦を深めるためには会話が大事」とか昭和の精神論ほざくのは止めろ。そんなことないし無価値だ。業務時間を消費するのだから、もしも口頭で会話をするなら無駄なく効果の高い会話をすべき。「口頭伝達」は情報伝達の手段として極めて非効率かつ低品質な結果を生むモノであり、文書化し共有する方がより高効率で高品質だ。口で喋っただけで仕事した気になるな。文書を書くまでは何もしていないのと同じ。

よく「書くのは苦手だけど、話せば伝わるでしょ」と考えるバカが多いが完全な間違い。それは聞き手の「ヒアリング能力」に頼って依存しているだけで、口で伝えるのが上手なワケではない。伝達手段に関係なく、そもそも情報を上手く発信できていければ、どれだけ聞き手のヒアリング能力があっても絶対に認識相違を生むので、会話だろうがテキストコミュニケーションだろうが、「ビジネスコミュニケーションスキル」は必要。その前提で、より学習コストがかかり、費用対効果の低い伝達手段が「会話」であり、それと比較すると学習コストが実は低く、それでいてあらゆる面で効果の高い伝達手段が「テキストコミュニケーション」なので、テキストコミュニケーションを円滑に進めるためにビジネスライティングスキルが重要になるのだ。