優秀なプログラマないしシステムエンジニアとして絶対に身につけなければいけない技能は何か？と聞かれら、私は間違いなく「日本語能力」と答えると思います。
「日本語ならペラペラだよ。」という声が聞こえてきそうですが、ここにいう日本語能力とは、「自分の伝えたい相手に、何かのアクションを取ってもらうために、必要十分な情報を過不足なく正確に素早く伝達する」能力を言います。
言い換えると、「ビジネスライティング能力」ともいえるかもしれません。
システム業界に働く人々は、ある意味「翻訳家」です。
一方には、「こんなことできたらいいなあ。」という、いわば非・システム的な自然言語(人間の話す言葉という意味です)を話すクライアントがいて、他方にコンピュータ語しか理解しないコンピュータがいます。
クライアントとコンピュータの間に、非・システム的な自然言語で語られる要望を、要件や基本設計書上でシステム的な自然言語に翻訳するシステムエンジニア（又はシステムコンサルタント）がおり、基本設計書を詳細設計書に翻訳する上級プログラマがいて、詳細設計書をプログラミング言語(人間もコンピュータも理解できる言語)に翻訳するプログラマがいて、プログラマの翻訳によってプログラミング言語によってコンピュータに与えられたロジックを基にコンピュータは動作(演算)できるようになります。
このように、システム業界の仕事はある意味で、異なる役割を持つ人々の間の伝言ゲームと言い換えることさえできます。
このような業界に身を置く以上、冒頭に述べた「ビジネスライティング能力」はシステム業界に属する者にとって最も大切な能力といえるのです。
ビジネスライティング能力を欠く人がいると納期遅れのリスクが高まる
ビジネスライティング能力に欠ける人がプロジェクトに一人いると、納期遅れのリスクが高まります。
なぜでしょう？
それは伝える側と理解する側の間に「認識齟齬」がおきるために、プロジェクトメンバがプロジェクト遂行に不要なアクション、ひどい場合はプロジェクト遂行を阻害するアクションをとってしまうからです。
すべきことについて「認識齟齬」があったことが露見するのは、たいてい仕事を依頼された側が成果物を仕上げて、仕事を依頼した側の人に成果物を共有し、仕事を依頼した側の人が、自分の意図していた成果物ができていないことを見つけるときです。
この時、プロジェクトとしてはその仕事をもう一度やり直さなくてはいけません。
これをシステム業界では「手戻り」といいます。
このような手戻りの累積が過重労働や納期遅れの原因になります。
プロジェクトでは、「伝え方」が悪いのか「聴き方」が悪いのか、しばしば当事者の間で責任転嫁のし合いがまま起きることになりますが、一段俯瞰的な目線に立てば、結局プロジェクトに与えられているマンパワーの浪費をしていることにかわりありません。
したがって、システム業界で生きていこうと思うのであれば、プログラミングスキル以前にビジネスライティング能力を徹底的につける必要があります。
このことを、よく理解していただきたいと思います。
ビジネスライティングの原則１：読み手にわかる文章を書く
ありとあらゆるビジネス文書には、必ず特定の読み手がいるはずです。
もし、皆さんが何かを会社で書くときに読み手が理解できるか否かを意識していない場合、その文書は恐らく何の用も為さない無意味な文書になるでしょう。
文章は、必ず読み手にその内容が理解できるように意識して構成します。具体的には以下の3点を意識して文章を作成してください。
- 自分の言いたいことではなく、読み手のいちばん知りたいことを中心に書く
- 読み手が知っていること知らないことを想定し、知らないであろう事柄は補足して書く
- 読み手の理解できる語彙を使って書く
1点目については、相手のいちばん知りたいことを端的に書くことが必要と、言い換えられます。
例えば、トラブルの発生報告のメールで、読み手が知りたいのは、そのトラブルの責任が誰にあるのかではなく、そのトラブルがどれほどのインパクトをもたらしうるかです。
したがって、トラブルの影響範囲をまず書く必要があります。これを怠ると、「こっちは●×を知りたいんだけども」というやり取りが生じて時間を余分に取ります。
2点目については、システム業界で働く以上、色々に異なる専門性を持つ人たちと協働する必要に迫られますので、相手のキャリアや役割から知らないと想定される内容は、予め文中で補足しておく必要があります。ビジネス文書に「読ませる行間」がある場合、それはビジネス文書失格です。この点に注意しないと、情報の出し手と受け手に「認識齟齬」が生じる可能性が高まります。
3点目については、例えばシステムのトラブル(仮にエンタプライズシステムのバッチが異常終了した際の対応として、「コマンドを手打ちする」か「スケジューラを使ってバッチをReRunさせる」か2つの選択肢があり、いずれを選択するかをクライアントの業務部門(システム部門ではない)の方に判断していただかなくてはいけないとします。
このとき、「コマンドを手打ちしましょうか、それともスケジューラで動かしましょうか」と聞いても、相手は何を言っているか理解できませんから(恐らく読者の皆さんもよくわからないでしょう)、ビジネス文書として全く用をなしていません。
このような場合、「誤操作のリスクは多少あるがすぐに実行できる手動の復旧方法と、実行に時間が掛かるが誤動作のリスクは極めて低い機械的な復旧方法と、いずれを選択しましょうか？」と聞かなくてはいけません。
この点に留意しなければ、おそらくプロジェクト遂行に必要な決定がなされず停滞するか、誤った決定がなされて「手戻り」を生じるでしょう。
【無料あり】エンジニアが解説！プログラミングスクールおすすめ５選ビジネスライティングの原則2：読み手に望むアクションを促す文章を書く
ビジネスは、経営資源を活用して利益を生み出す活動ですので、ビジネス上のコミュニケーションを取る目的は、読み手に何らかのアクションをさせることにあります。
読み手にどんなアクションをさせたいか意識できていないビジネスコミュニケーションは、無意味なものです。
読み手に何らかのアクションをさせるためには、文章中に以下の3要素が含まれている必要があります。
- 書き手は読み手にどんなアクションをとってほしいか
- 読み手がアクションをとるにあたって知っておくべきこと
- 読み手に書き手がアクションをとるように要求できる理由
まず、書き手が読み手に何をしてほしいか、文章の冒頭部で端的に示されている必要があります。
例えば、「●×の件について企画書を提出いたしますので採否の判断を願います。」と書いてあれば、上長に自分の企画の採否の判断をゆだねていることが分かります。
また、「■■の件に関しては以下の要領で対応するように命ずる。」という記載があれば、上長が部下に対して自身の命令の範囲内で■■の件に関して業務を遂行するように指示していることが分かります。
このような記載がないと、文章全体の趣旨がぼやけてしまいます。
次に、文章の読み手が求められているアクションをとるために知っておくべき情報を予め示しておく必要があります。
企画書の提案であれば、当然企画書の中に、その企画の前提となる経済状況や市場環境が分析され、需要規模が合理的根拠に基づいて見積もられ、利益を上げるための最適な方法の案が複数の中から比較検討されたうえで選ばれ、そのうえで最良の案の遂行に調達が必要な人員や予算、設備や外部リソースが一覧されているはずです。
また、何らかの案件についての方針を指示した書類の中には、基本的なプロジェクトの目標や体制、スケジュール、納入すべき成果物、会議体などが規定されているはずです。
求めたアクションに必要な情報を予め提供しなくては、結局後々情報を求められることになりますので、その分時間が無駄なのです。
そして、ビジネス文書においては、書き手が読み手に読み手への要求を正当化できる根拠を示す必要があります。
企画書では、企画が会社の利益にかなうことを示さなくてはいけません。
上長からの指示書は、上長という社内での地位ゆえに有効なのです。
読み手が意に介さない文章は読み手のアクションを変えませんので、ビジネス文書としての意味を持ちません。
読み手がわかる言葉で、相手に端的にアクションを求めるのがビジネスライティングの基本
システム業界では異なる専門性を持った人たちの共同作業によってプロジェクトを進めていきますので、相手にわかる書き方で、端的に何らかのアクションを求めるビジネスライティングの技法を身に着けることが大変重要であることを説明して参りました。
色々の書籍を見ますと「メールはスクロールしない長さでおさめなさい。」といったことが色々書いてあったりしますけれども、これらの細かいアドバイスは、全て「読み手にわかる言葉で、端的に何らかのアクションを求める」という目的のための技法であることを押さえて頂きたいと思います。