SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

翔泳社 新刊紹介(AD)

エンジニアが書く文章の問題点とは? 伝わる文章のポイントは相手と目的の理解

  • X ポスト
  • このエントリーをはてなブックマークに追加

 翔泳社より発売中の『エンジニアのための文章術 再入門講座 新版』では、意外と苦手なエンジニアが多いという文章表現について伝わりやすくするための要点を解説。今回は「エンジニアが書く文章の問題点とは?」や「文章の説得技術には何が必要か?」といった改善すべきポイントが指摘されている「第1章 エンジニアが書く文章の問題点と文章表現力」を抜粋して紹介します。

  • X ポスト
  • このエントリーをはてなブックマークに追加
本記事は『エンジニアのための文章術 再入門講座 新版 状況別にすぐ効く!文書・文章作成の実践テクニック』の「第1章 エンジニアが書く文章の問題点と文章表現力」を抜粋したもの。掲載にあたり一部を編集しています。

1-1 ビジネス向け文章作成に必要な素養

 昨今、人工知能(AI)やデータ分析、デジタルトランスフォーメーションでビジネスモデルを根本から変えるような事例が世界中で生まれています。ビジネス環境はこれまでにないスピードで変化し、ICT・デジタル技術はますます高度化しています。この流れを受け、システム開発は従来のウォーターフォール型からアジャイルになり、多くの専門人材による分業化で複雑化し、ITエンジニアは、開発メンバーたちとより頻繁で確実なコミュニケーションをとることが必要になりました。

 この頻繁で確実なコミュニケーションの必要性が、これまで以上に、ITエンジニアに「伝える力」が欠かせないと強く言われるようになった理由です。

 そして、コミュニケーションに使われる具体的なツールは、従来の紙媒体から、メール、チャット、トークアプリを使った「電子媒体」にとって代わりました。しかしどのような媒体であれ、その本質は他人に何かを伝えるために書く「文章」です。

 そこで本書は、ビジネススキルの中でも特に重要で、かつ習得ニーズが高い「文章作成」をテーマとしています。難しいと言われる「開発側の上位職」や「顧客(利用者)」向けの「文章」について具体的な技術を紹介していきます。

 さて、本題に入る前に、私のことについて少し書かせてください。私は、ビジネススキルを指導するIT教育コンサルタント/コーチとして活動しています。

 指導するテーマは、「マネジメント」「コミュニケーション」「思考」「ドキュメンテーション」「チームビルディング」などです。

 これらのテーマに必要な技術を研究し、雑誌や書籍に発表しています。そして同時に、企業のシステム部門の部長として、日々、チームメンバーとともに、システム企画、デジタルビジネスの立案、プロジェクトマネジメントといった業務も遂行しています。

 つまり、「ビジネススキルを研究/教える立場」と、「それを実務で実践する立場」の2つの立場を持っています。20年以上仕事をしていますが、両方の立場を知っていると各々の立場で仕事をする際に役立つことが多いものです。

「ビジネススキルを研究/教える立場」なら、実務で実践していることはメリットがあり、反対に「実務を実践する立場」なら、ビジネススキルを研究/教えるメリットも多く、両者は相乗効果を出す関係にあります。

 本書では、そんな2つの立場を経験している私が、ビジネスで書く文章にはどのような要素が必要なのか、具体的にどのようにして身につけていけばよいのかについて、具体的な事例を交えて紹介していきます。

エンジニアが書く文章の問題点とは?

 私は企業のシステム部門においてチームメンバーの文章をチェックしています。また、IT教育コンサルタントとしてビジネス向けの文章の書き方を教えたり、国家試験科目の論文添削をしています。そのような立場で非常に多くの文章を見てきたことにより、「どんな文章が問題なのか」を考察し整理することができました。

「よい文章」とは「ダメではない文章」

 本書で紹介する技術は、「よい文章を書く技術」です。そして、よい文章を書くコツは、「ダメな文章を書かない」ようにすることです。

 私はさまざまな人から「よい文章を書くコツは何ですか?」と聞かれることがありますが、いつも「ダメな文章を書かないようにすることです」と答えています。

 人が「よい文章だ」と感じるのは、あくまで個人の受け止め方、感じ方に依存する部分が多く、それは極めて主観的なものです。

 しかし、少なくとも、読んだ際に「ダメな文章」と思われなければ、ビジネス向けの文章としてはとりあえず十分です。

 なぜなら、どんな上級者でも「上手い」と思わせるような文章を書けるようになるには相当な訓練が必要で、時間がかかるからです。そこで、本書では、「誰が見ても下手でダメ」という文章を書かないこと=「よい文章を書ける」と定義し、その技術を紹介していきます。

そもそもダメな文章とは何か?

 私は論文講師の立場で、情報処理技術者試験の論述添削を行い、これまでに2000本ほどの論文を読んできました。その中でA評価(合格レベル)が付くものは、どれくらいだと思いますか?

 答えは5%(100本のうち5本)程度です。この合格レベルの基準がよい文章を考える上でとても参考になるため、添削時に何をダメと評価しているのかを紹介します。

 情報処理技術者試験の論述試験は、出題される1000字程度の出題テーマの文章を読み、その主張に合わせて、自分の考えを実務体験に即して論述していく試験です。問題文をよく読めば、さほど悪い評価にはならないように配慮されています。

 にもかかわらず、100人のうち、およそ95人が合格できない論述になる原因は、「読み手に理解させる配慮」がないケースがほとんどです。私はおよそ95%の論文に対して、図1.1のようなコメントをしています。

図1.1 読み手への配慮がない論述への指摘事項
図1.1 読み手への配慮がない論述への指摘事項

 論述試験では、合格するために、わかりやすく相手(採点者)に理解してもらうための文章を書くことが必要です。しかし、多くの人は自分視点で書いてしまい、読み手視点で書く人はとても少ないという現実があります。

実務の文章も相手への配慮がない

 そのようなことは、ビジネスの現場でもよくあります。続いて、実務での例も見てみましょう。

 次の2つは、私が会社でチームメンバーの文章をチェックするときによく言う言葉です。

(1)「部長はこんな細かいことは気にしない。」

<相手の関心と不一致>

 システム開発プロジェクトの部長宛て進捗報告などをチェックしているときに思わず出てくる言葉です。

 一般に部長レベルのマネジメントなら、「詳細仕様がどうなっているか」「テストの詳細計画がどうなっているか」という細部よりも、「予算は超過しないか」「顧客との関係は良好か」「今回の開発でチームメンバーにノウハウは蓄積される仕組みになっているか」など、より大きな視点が気になるはずです。したがって、「部長レベルで気になるポイント」を気にして文章を書く必要があります。

(2)「説明する相手はシステムを知らない営業部門の課長だから、アジャイルとかレグレッションテストの意味はわからないよ。」

<「知識差」があるので伝わらない>

 他部門の担当者や管理職向けのトラブル報告や進捗報告などをチェックするときに出てくる言葉です。自分が知っている専門用語、部門方言を他部門の担当者や管理職向けの文章でも使ってしまいがちです。人は自分が知っていることは相手も知っていると思う傾向があります。

 このため、人に説明すべきことを省略することが多く、これがわかりにくい文章を書いてしまう原因になります。相手がわかるような言葉で文章を書く必要があります。

 論述試験のケースも、実務での2つのケースも、本質は同じです。要は相手の視点にフォーカスできていないから問題なのです。したがって、よい文章を書く方法は、書き手の視点でなく、読み手の視点で書く、つまり相手にフォーカスして書くということです。論述試験なら、試験という「目的」にフォーカスし、相手(採点者)に伝えることが必要ですし、ビジネス文書なら、文書の目的や相手の関心に配慮した内容を考えなければ、よい文章は書けません。

 ビジネス向けの文章には多くの種類があります。企画書、手順書、調査レポート、提案書、議事録、プログラム仕様書などの文章は、目的を達成できるように作成すべきです。

1-2 文章の基本は、相手と目的の理解

 ビジネス向けの文章を書く上で最も大事なことは「どのような目的」の文章を「誰に対して」作成するかを考えることです。文章の目的には、

  • 情報収集を行う
  • 説明や報告を行う
  • 議論をする、決める
  • 説得する、誘導する、お断りする

などがあり、目的が異なれば、必要な文章の要素も違ってきます。

 したがって、文章を作成する際には、目的ごとにどのような配慮が必要かという視点を持つことが必要です。しかし、目的だけでは不十分です。同じ「説得」をするための文章であっても、「(1)同僚や部下」を説得するときと、「(2)顧客や会社の上司、上層部」を説得するときとでは、方法が異なるからです。

 一般に、(1)よりも(2)の難易度が高く、難しいと言えます。そこで、相手別の説得技術を身につけることが必要になってきます。

文章の「説得」技術には何が必要か?

 私は仕事では、「説得力」を意識して文章を作成しています。そして、チームメンバーには「説得力」について理解してもらうために、よくする質問があります。ここで、いくつか紹介しましょう。

Q1:言っていること(主張)の理由が「ないもの」と「あるもの」では、どちらに説得力があるか?

答え:理由があるもの。なぜ、「そうなのか」という疑問が解消され、すっきりするから。理由を書いてくれないと、「なぜ、そうなの?」と聞きたくなる。

Q2:言っていることが、「途中で変わってくる文書」と「最後まで首尾一貫している文書」では、どちらに説得力があるか?

答え:首尾一貫しているもの。首尾一貫していないと、あまり考えていないと思ってしまう。言っていることに漏れや不整合、矛盾があると、いい加減な人だと思ってしまい、信用できない。そういう人が書いた文章の内容は疑わしい。

Q3:根拠に数字の裏づけが「あるもの」と「ないもの」では、どちらに説得力があるか?

答え:数値の根拠があるもの。たとえば「この新商品は1日かなり売れる可能性がある。なぜなら、新しい機能が魅力的だから」という主張よりも、「この新商品は1日100売れる可能性がある。なぜなら店には1日あたり、1000人の来店があるが、アンケートをとった結果、今回の商品を買いたいという客が300人いたから、少なくとも100くらいは売れる可能性を持つ」という主張のほうが説得力がある。

 これらの回答、

  • 理由
  • 首尾一貫
  • (数値)根拠

は3つとも「説得力」の要素です。

 このようにチームメンバーに質問をすると、これらの要素について答えることはできます。しかし、いざ文章を作成してもらうと、この「説得力」の要素が入っていない説得力に欠ける文章になってしまうことが多いのです。聞かれればわかるけど、最初からは実践できない。

 これが文章作成の難しいところです。

企画提案書の説得力

 企画提案書の事例をベースに、「説得力」の持たせ方について見ていきましょう。

「提案書」は、一般的に「何か新しいことを他人に説明し、了承してもらう」という性格を持つ文書のため、「説得力」が必要になります。ここでは、かつてチームメンバーに書いてもらった次の文章をベースに、どこがポイントになるのか考えます。

Before 修正前

 この文章の内容を抜き出すと、以下のようになります。

(1)<言いたいこと(主張)>

 システムの開発維持において、テストケースを検討したり、他社事例や業界研究をして、当社システムの品質維持に生かす特別チームを発足させる。

(2)<その理由>

 開発チームと別の部隊を品質維持活動専任にすることで、開発チームの負担を軽減するとともに、専任チームにすることで、専門知識を習得しやすいようにできると思うから。

 要は、特別チームを作れば、高度なシステムにおける高度な品質維持活動ができる上に、品質の専門的なノウハウを蓄積でき、開発チームの負担もなくなるというものです。では、この提案書には「説得力」があるでしょうか?

 その答えは、「一定の人にとっては説得力があるが、説得力がないと思う人もいる」です。この企画は、総論としては問題ないように思えます。品質を高める方策として、開発チームと品質保証チームを分けるのは実際に行われていますし、開発チームと別の部隊を品質維持活動専任にすることで、

  1. 開発チームの負担を軽減する
  2. 専任チームにすることで、専門知識を習得しやすいようにできる

という主張も間違いではないからです。その意味で、岡山さんの企画内容に説得力を感じる人もいるでしょう。

 しかし、逆に説得力を感じない人も多くいるはずです。それは、以下のような立場の人です。

  • この企画の導入に責任を持つマネージャークラスの人
  • コスト効果を判断する上位職の人

 つまり、実行責任を持つ人や最適な判断責任を持つ人たちです。

 このような人たちにとって、1つの案件の判断や実行責任は自分の身にふりかかる大きな関心事なので、「思いつき」程度の考えでは納得してくれません。「本当に上手くいくのか」「本当に効果があるのか」を本気で反論してきます。

 文章の書き手として、本気で反論してくる人たちに「反論しにくい」書き方ができるか。それが提案書に説得力を持たせる大きなポイントになります。

反論指摘のポイント

「本当に、開発チームと品質維持チームを分けて上手くいくの?」というのが指摘ポイントになるでしょう。具体的には、次のような反論・指摘が想定されます。

<反論・指摘ポイント(1)>

 最初は開発チームから分離して品質維持専門チームを組織するので、開発に関する知識は問題ないと思うが、次第に品質チームに「開発のノウハウ」が少なくなっていくのではないか?

<反論・指摘ポイント(2)>

 開発チームと品質保証チームは、対立しやすいのではないか。足を引っ張り あうことで、かえって組織力は落ちるのではないか?

 このように、誰に対する文章なのかを考えないと、相手の立場・視点がわからず、結果的に説得力のない、効果の低い文章を作成することになってしまいます。

 したがって、先ほどの文章に、このような反論に対する対応を入れておくと、説得力のある「よい文章」になります。具体的には、次のようなかたちです。

After 修正後

 1.~3.は変更なしですが、「4.検討のポイント」を追加することで、批判・反論をしにくい説得力のある文章にすることができます。

 このように文章に説得力を持たせるためには、文章を読んで何らかの判断や行動を起こす相手にフォーカスしなければなりません。

 したがって、上司や上位職向けの文章であれば、それらの相手にフォーカスした文章を作成しなければならないのです。

上司・上位職にフォーカスする

 多くの人は、課長から経営層クラスのいわゆる「上位職」向けの文章を書くことを苦手としています。その理由は、「上司・上位職」という相手にフォーカスしていないからです。

人の役職・立場の違い

それによる相手の視点の違い

書き手に必要な文章表現の違い

 ここで理解すべきことは、「上位職の好む文書表現と、担当者が書きなれた表現は違う」ということです。

<上位職が好む要素>

  1. 忙しいので、すぐ読めてポイントが理解できる
  2. 完結でシンプル、枚数が少ない。ひと言でわかる、結論から入っている
  3. なぜこの企画が必要なのか、この企画が成功する論拠は何かという理由がわかりやすく説得力がある

 上位職は、短い時間で論点がわかり、「判断する理由」が明確でわかりやすい表現を好みます。一方、担当者は「企画をどのように進めていくのか、誰がいつまでに何をするのか」という作業をできるだけ詳細に表現することを好むので、「視点がまったく違う」のです。

 この理由は、両者の仕事の責任を考えれば明らかです。上位職が行うのは意思決定・判断を中心とした業務であり、自分が判断した結果には常に成功責任を持つため、成功するかの判断に関係する理由を詳細に知りたがるからです。

 こういった上位職の心理を理解しておくことも、文書を上手く書くノウハウになります。

視点が違う「役員と担当者」

 私がA社でシステム企画を担当していた頃の話です。A社にはシステム企画部があり、システム計画、たとえばハードウエアやネットワークの調達・維持、ITエンジニアの調達・育成、業務アプリケーションの開発・保守計画などを行っています。

 あるとき、Bくんが私の後輩としてシステム企画を担当することになりました。彼は担当者としてシステム開発の経験は多かったのですが、企画の仕事では成果を出すことができていませんでした。説明したり説得したりするスキル、文章スキルが弱かったからです。Bくんは企画会議などで、上司や同僚に質問されると見当違いの回答をしたり、黙ったりしてしまうことが多くあったのです。

 あるとき、専務向けにBくんが案件の説明をすることになりましたが、その場でも彼は上手く説明できませんでした。落ち込んだBくんに私はこうアドバイスしました。

  • 専務のような経営層は、たくさんの人に説明を受けるから、1つの案件にあまり時間を割けない。だから、説明の途中でも、すぐ知りたいことを質問することがある。
  • 何が問題で、何をすればよいのか、どれくらいでできるのか、コストはいくらかかるのか、効果はどれくらいなのか。これらをできるだけ計数的に回答できればいい。それができるように準備してみたらどうだろうか。

 これ以降、Bくんは、説明や報告時には事前に想定質問を紙に書いて準備するようになりました。しかし、彼の説明力・説得力が向上していくにつれ、紙で書き出す準備も必要なくなっていきました。紙に書き出さなくても、頭の中で準備できるようになったからです。同時に、伝える目的と相手を意識することで文章スキルも向上していきました。

 このように、ITエンジニアには「伝える力」が欠かせません。会話や文書のやりとりなど上司や他者とのコミュニケーションでは、「(伝える)目的と相手にフォーカスする」ことが重要です。相手に上手く伝えるには、以下のポイントで常に考える必要があります。

  • 自分の視点からの説明ではなく、必ず相手の立場に立った説明をする
  • 相手の関心のある視点にフォーカスする。関心のない視点を説明する際には工夫する

 そしてさらに「わかりやすい、伝わる」文章を作成するには、文章表現力の基礎技術も押さえておく必要があります。次節では、この基礎技術について解説します。

1-3 文章表現力の基礎技術とは?

 ではさっそく、文章表現力の基礎技術とはどのようなものか見ていきましょう。

わかりやすい、伝わる文章にする7つの力

 次の7つが「わかりやすい、伝わる」文章を作成するために必要な文章表現力の基礎技術です。これらは、私が文章を書く際にいつも気を付けていることであり、他者が書いた文章をチェックする際のポイントでもあります。

7つの力──文章表現力の基礎技術

  1. 確実に伝える
  2. 納得させる
  3. 一目でわかる
  4. 理解しやすくする
  5. 正確に伝える
  6. 短い文章で伝える
  7. 心に訴える

7つの力 (1)確実に伝える

 よい文章は「何を言っているのか、なぜそうなのか、具体的にはどういうことか」「詳細に言うとどうなのか」が明確になっています。このような文章構造で最も重要なのは、「言いたいことを絞る」ことです。関係しそうなことを思いつきで書いていく文章はわかりにくく、説得力も低くなります。

 次章2-1節では、「言いたいことは何か」を明確にしてから論点を設定し、論点に沿った文章を書くことを学びます。

7つの力 (2)納得させる

 よい文章は「主張」が明確で、その主張に納得できる根拠(理由)が明記されているものです。また、根拠は明確でなくてはならず、事実に基づいたものが強い納得感をもたらします。言いっぱなしで、根拠がともなわない主張しかない文章は説得力が低くなります。次章2-2節ではまず、「主張と根拠の関係とは何か」を明確にしてから、主張と根拠がしっかりした文章を書くことを学びます。

7つの力 (3)一目でわかる

 よい文章が持つ構造上の美しさ、わかりやすさを実現するのが、文章の構造化です。文章の構造化とは、同じグループの物事をまとめてタイトリングして書いたり、同じ階層(レイヤー)の物事のレベルを合わせて書いたりすることです。

 次章2-3節では、「構造化とは何か」を明確にしてから、文章を構造化して、バランスのとれたわかりやすい文章を書くことを学びます。

7つの力 (4)理解しやすくする

 よい文章は、「何を言っているのか」を相手に確実に理解してもらうことができなければなりません。このような文章に必要なのは、「できるだけ平易に表現する」ことです。専門用語、難しい用語、自分やチームにしかわからない用語で文章を書いても、相手に理解してもらえなければ、文章はわかりにくくなり、説得力も低くなります。

 次章2-4節では、「平易に表現する」ための要素を明確にしてから、それらの表現を使った文章を書くことを学びます。

7つの力 (5)正確に伝える

 わかりやすい文章を書くためには、むやみに省略をしないことです。省略とは、本来記載すべき内容を「書かない」ことです。書き手と読み手両方が既知の内容だけ省略すべきですが、通常、読み手と書き手の情報量・知識量は異なっているため、むやみに省略してしまうと読み手が理解できない文章になってしまいます。

 次章2-5節では、「省略せず、正しく表現する」ことを学びます。

7つの力 (6)短い文章で伝える

 よい文章は、短い時間で、一目で直感的に内容を理解できることが求められます。このためには、ムダな文章をそぎ落とすことはもちろん、言い換えや記号化、図表などを使うことが必要です。締まりのない長い文章は、理解しにくいだけでなく論点もぼやけてしまいます。

 次章2-6節では、「短文で表現するとは何か」を明確にしてから、できるだけ短い文章で理解させることを学びます。

7つの力 (7)心に訴える

 よい文章を書くためには、読み手の感情に訴えるなど、心理面のアプローチも必要です。特に「説得する」「依頼する」「断る」「アピールする」ような文章では、論理性やわかりやすさはもちろん、感情に配慮した工夫が必要になります。人は感情を持つため、文章に書かれた内容で心を動かされ、目的が達成できることも多いものです。

 次章2-7節では、相手の感情に配慮した文章を学びます。

 基本的に、この7つの力を理解して使うことができれば、日常業務で文章を書くのに困ることはなくなるでしょう。ただし、これらの習得には根気が必要です。

  • 考える
  • 書く
  • チェックする
  • 修正する

 これら4つの手順の繰り返しで多くの文章を書くことです。私も自分のチームで、この手順を実施しています。

7つの力を利用した文章例

 次章で7つの力について詳しく説明しますが、その前に7つの力を利用した文章とはどのようなものなのか簡単に見ておきましょう。次の文章は、7つの力を利用する前(修正前)の文章です。

Before 修正前

 これは、ある企業A社でのシステム開発プロジェクトにおいて作成された文章です。これを7つの力の一部を使って修正すると、次のようになります。両者を比較してみてください。緑色の部分が修正箇所です。

After 修正後

 Before(修正前)の文章の最初(1)に、以下の一文があります。

開発は現在システムテストフェーズに入っており、テストは3900ケースを完了した状態で、バグ数は累計で54件であり、安定した水準です。

 しかし、これは現状の説明を補足的に書いているにすぎず、この文章のメインテーマ(論点)にはなっていません。ここでの論点はあくまでも以下の部分(2)です。

部内関係各課の皆さまに、テストアイテムに関する説明をしたいと思いますので、日程調整したいので、このメールに添付しています日程調整表に皆さまの都合のよい日程を記入の上、返信ください。明日中でお願いします。

 ただし、この文章は長い上に、メイン主張の前に長い修飾語(テストアイテムに関する説明をしたいと思いますので、日程調整したいので)が入っており、構造の理解に時間がかかります。

 そこで次のように、大事なことを先に書き、理由や補足を後から書く方式に変更します。

1.依頼事項
以下説明会の日程調整をしたいので返信願います。
→テスト要員増員に関する内容
→添付の日程調整表に記入の上返信願う。(明日中)

 上記の文章では、「1.依頼事項」が論点のラベルの効果、「以下説明会の日程調整をしたいので返信願います。」がメインテーマ(論点の位置づけ)になっています。また、その下に矢印で結んだ、

→テスト要員増員に関する内容
→添付の日程調整表にご記入の上返信願う。(明日中)

が、会議の内容と日程調整に関する作業の詳細内容になっています。これなら、読み手は「自分はなぜ、これをすべき」なのかが確実に理解できます。

 さらに、タイトルも変更しました。

テストに関する依頼 → テスト実施要員の増員に関し、説明会参加依頼

 タイトルは、文章の意味をひと言で表現するものが必要です。Before(修正前)はテストに関する何の依頼なのかがよくわかりませんでしたが、After(修正後)は具体的になっており、何をしてほしい文章なのかがわかります。

 さらに、Before(修正前)はテスター、テストアイテムといった意味がわかりにくい専門用語が使われていたので、After(修正後)では一般的に理解しやすい言葉に書き換えています。

テスター → テスト実施要員
テストアイテム → テスト実施作業内容

 7つの力と上記の修正内容の対応は表1.1 の通りです。このように7つの力をきっちり押さえておけば、わかりやすく、伝わる文章を書きやすくなります。

 なお、「(7)心に訴える」は、ここでは未使用です。これは一般的な報告書や通知書の類では使わず、反対している相手を説得する文章などで使う技術です。

表1.1 依頼文の修正前と修正後の違い
表1.1 依頼文の修正前と修正後の違い

 次の第2章では、この7つの力それぞれについてさらに詳しく解説します。そしてさらに、第3章以降は実践編として、文章のテーマ別に具体的な文書作成テクニックを紹介します。

エンジニアのための文章術 再入門講座 新版

Amazon SEshop その他


エンジニアのための文章術 再入門講座 新版
状況別にすぐ効く!文書・文章作成の実践テクニック

著者:芦屋広太
発売日:2020年4月23日(木)
価格:2,200円+税

本書について

本書はIT分野における国家試験対策の論文指導、コミュニケーション・マネジメント、教育コンサルタント、コーチとして豊富な経験を持つ著者が執筆した文章・文書作成の指南書です。

 

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
翔泳社 新刊紹介連載記事一覧

もっと読む

この記事の著者

芦屋 広太(アシヤ コウタ)

企業のIT 部門で部長職としてシステム企画やプロジェクトマネジメント実務を行いながら、 ビジネススキルを指導する教育コンサルタント。実務で得た知見やノウハウを体系化し、現 場での教育、雑誌・書籍での発表、セミナー・研修に利用する活動を行い、『日経コンピュー タ』で9年にわたってビジネススキル連...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

渡部 拓也(ワタナベ タクヤ)

 翔泳社マーケティング課。MarkeZine、CodeZine、EnterpriseZine、Biz/Zine、ほかにて翔泳社の本の紹介記事や著者インタビュー、たまにそれ以外も執筆しています。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/12208 2020/04/30 07:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング