技術文書の品質管理(その5)5W1Hの考え方に基づく管理

投稿日

技術文書の品質管理(その5)5W1Hの考え方に基づく管理

 

【目次】

    今回は、「5W1Hの考え方に基づく技術文書の品質管理」について解説します。

     

    1. 5W1Hとは

    5W1Hとは、「When(いつ)」「Where(どこで)」「Who(だれが)」「What(なにを)」「Why(なぜ)」「How(どのように)」の英単語の頭文字をとった言葉です。これらの要素にしたがって情報を伝えることで必要事項を相手にわかりやすくかつ明確に伝えることができます。

     

    2. 技術文書の品質管理と5W1H

    2.1 技術文書の品質管理をするうえでの5W1Hとは

    技術文書の品質管理をするうえでの5W1Hとは「技術文書について『いつ、どこで、だれが、なにを、なぜ、どのように』品質管理をするのか」ということです。ここで、技術文書の品質管理とは、自分が書いた技術文書の内容が明確に伝わるかどうかを確認することです。

     

    5W1Hに基づき技術文書の品質管理について考えると技術文書の品質管理のことが掘り下げて理解できます。

     

    2.2 技術文書の品質管理での5W1Hについて

    技術文書の品質管理での5W1Hとは以下のように考えることができます。

     

    (1)When(いつ品質管理をするのか)

    基本的に、技術文書を書き終えたときです。例えば、会議の資料やメールを書き終えたときです。技術文書を書いたら技術文書の品質管理を必ず行います。

     

    (2)Where(どこで品質管理をするのか)

    仕事をしている所です。

     

    (3)Who(だれが品質管理をするのか)

    技術文書を書いた書き手です。ただ、上司など書き手以外の人が技術文書の品質管理をすることもあります注1)。自分で品質管理をするうえで重要なことがあります注2)。それは以下の2点です。

    • ①内容が明確に伝わらない書き方の基準を持つこと
    • ②「内容が明確に伝わらない書き方」の修正方法がわかること

     

    これらの条件を満たすことで品質管理を自分で確実に行うことができます。

    注1):「技術文書の品質管理(その2)技術文書を確認する人の視点から」を参照

    注2):「技術文書の品質管理(その1)文書の内容が明確に伝わるかどうかを確認」を参照

     

    (4)What(なにに対して品質管理をするのか)

    自分が書いた技術文書です。

     

    (5)Why(なぜ品質管理をするのか)

    不良品の技術文書(内容が明確に伝わらない技術文書)を書かないようにするためです。技術文書の品質管理を怠ると(内容が明確に伝わらない技術文書を書くと)読み手の貴重な仕事の時間を奪います。自分の仕事の時間を無駄に使うかもしれません注3)。仕事の関係者との技術文書を通したコミュニケーション不足で仕事が円滑に進まないことがあるかもしれません注4)

    注3):「内容が伝わり難い技術文書を書くことで起こる重大なこと」を参照

    注4):「“技術文書を書くこと”について考える(その1)」を参照

     

    (6)How(どのように品質管理をするのか)

    書き手と読み手の違いを認識し読み手の立場で品質管理をします。書き手は知っている人、読み手は知らない人です注5)。すなわち、知らない人の立場に立って「自分が読み手だったらこの書き方で技術文書の内容が明確に伝わるか?」という視点で技術文書の品質管理をします。

    注5):「内容が明確に伝わる技術文書の書き方(その3)」を参照

     

    技術文書を書いたら読み手の立場に立って...

    技術文書の品質管理(その5)5W1Hの考え方に基づく管理

     

    【目次】

      今回は、「5W1Hの考え方に基づく技術文書の品質管理」について解説します。

       

      1. 5W1Hとは

      5W1Hとは、「When(いつ)」「Where(どこで)」「Who(だれが)」「What(なにを)」「Why(なぜ)」「How(どのように)」の英単語の頭文字をとった言葉です。これらの要素にしたがって情報を伝えることで必要事項を相手にわかりやすくかつ明確に伝えることができます。

       

      2. 技術文書の品質管理と5W1H

      2.1 技術文書の品質管理をするうえでの5W1Hとは

      技術文書の品質管理をするうえでの5W1Hとは「技術文書について『いつ、どこで、だれが、なにを、なぜ、どのように』品質管理をするのか」ということです。ここで、技術文書の品質管理とは、自分が書いた技術文書の内容が明確に伝わるかどうかを確認することです。

       

      5W1Hに基づき技術文書の品質管理について考えると技術文書の品質管理のことが掘り下げて理解できます。

       

      2.2 技術文書の品質管理での5W1Hについて

      技術文書の品質管理での5W1Hとは以下のように考えることができます。

       

      (1)When(いつ品質管理をするのか)

      基本的に、技術文書を書き終えたときです。例えば、会議の資料やメールを書き終えたときです。技術文書を書いたら技術文書の品質管理を必ず行います。

       

      (2)Where(どこで品質管理をするのか)

      仕事をしている所です。

       

      (3)Who(だれが品質管理をするのか)

      技術文書を書いた書き手です。ただ、上司など書き手以外の人が技術文書の品質管理をすることもあります注1)。自分で品質管理をするうえで重要なことがあります注2)。それは以下の2点です。

      • ①内容が明確に伝わらない書き方の基準を持つこと
      • ②「内容が明確に伝わらない書き方」の修正方法がわかること

       

      これらの条件を満たすことで品質管理を自分で確実に行うことができます。

      注1):「技術文書の品質管理(その2)技術文書を確認する人の視点から」を参照

      注2):「技術文書の品質管理(その1)文書の内容が明確に伝わるかどうかを確認」を参照

       

      (4)What(なにに対して品質管理をするのか)

      自分が書いた技術文書です。

       

      (5)Why(なぜ品質管理をするのか)

      不良品の技術文書(内容が明確に伝わらない技術文書)を書かないようにするためです。技術文書の品質管理を怠ると(内容が明確に伝わらない技術文書を書くと)読み手の貴重な仕事の時間を奪います。自分の仕事の時間を無駄に使うかもしれません注3)。仕事の関係者との技術文書を通したコミュニケーション不足で仕事が円滑に進まないことがあるかもしれません注4)

      注3):「内容が伝わり難い技術文書を書くことで起こる重大なこと」を参照

      注4):「“技術文書を書くこと”について考える(その1)」を参照

       

      (6)How(どのように品質管理をするのか)

      書き手と読み手の違いを認識し読み手の立場で品質管理をします。書き手は知っている人、読み手は知らない人です注5)。すなわち、知らない人の立場に立って「自分が読み手だったらこの書き方で技術文書の内容が明確に伝わるか?」という視点で技術文書の品質管理をします。

      注5):「内容が明確に伝わる技術文書の書き方(その3)」を参照

       

      技術文書を書いたら読み手の立場に立って技術文書の品質管理を管理することで品質が保証された技術文書(内容が明確に伝わる技術文書)を書くことができます。

       

      【関連文献紹介】森谷仁著、「マンガでわかる技術文書の書き方」、オーム社、令和4年3月25日

      ◆関連解説記事:実践!技術マネジメント:7つのプロセスと35のチェックポイント

       

      特集】技術士第二次試験対策:技術士第二次試験に関する記事まとめページはこちら!口頭試験や論文対策などのポイントについての記事を紹介しています。

       

       

         続きを読むには・・・


      この記事の著者

      森谷 仁

      「君の書く文書は、わかりにくい」と言われる技術者から、「君の書く文書は、わかりやすい」と言われる技術者へのステップアップ!

      「君の書く文書は、わかりにくい」と言われる技術者から、「君の書く文書は、わかりやすい」と言われる技術者へのステップアップ!


      「技術マネジメント総合」の他のキーワード解説記事

      もっと見る
      自社の存在価値 普通の組織をイノベーティブにする処方箋 (その113)

        現在、知識や経験を整理するフレームワークとして、本質とそれ以外という区別があるという理解から「本質とは何か」を解説しています。また、企...

        現在、知識や経験を整理するフレームワークとして、本質とそれ以外という区別があるという理解から「本質とは何か」を解説しています。また、企...


      普通の組織をイノベーティブにする処方箋 (その188) 妄想を続けることで頭が良くなることを実感し妄想を好きになる

      ・見出しの番号は、前回からの連番です。 ▼さらに深く学ぶなら!「技術マネジメント」に関するセミナーはこちら! 妄想はネガティブに捉えられがちですが...

      ・見出しの番号は、前回からの連番です。 ▼さらに深く学ぶなら!「技術マネジメント」に関するセミナーはこちら! 妄想はネガティブに捉えられがちですが...


      研究開発の人間関係 新規事業・新商品を生み出す技術戦略(その65)

      1. 研究開発組織における多様性の受容  コンサルティングやセミナーでお会いする方々から次のような声を多くいただきます。 「結局、どんなアイデ...

      1. 研究開発組織における多様性の受容  コンサルティングやセミナーでお会いする方々から次のような声を多くいただきます。 「結局、どんなアイデ...


      「技術マネジメント総合」の活用事例

      もっと見る
      ‐企業内に発生している問題点を徹底的に追求 ‐  製品・技術開発力強化策の事例(その3)

       前回の事例その2に続いて解説します。企業内では解決が容易でない様々な問題が生じています。しかし、これらの問題解決に取り組まない限り、競争に勝つことが出来...

       前回の事例その2に続いて解説します。企業内では解決が容易でない様々な問題が生じています。しかし、これらの問題解決に取り組まない限り、競争に勝つことが出来...


      設計部門と組織政治の影響(その1)

       これまで数回にわたって、設計部門における仕組み構築の考え方や手順を解説してきました。仕組み構築のためのシステム化計画作成は、頂上を目指す登山ルートを設計...

       これまで数回にわたって、設計部門における仕組み構築の考え方や手順を解説してきました。仕組み構築のためのシステム化計画作成は、頂上を目指す登山ルートを設計...


      設計部門の課題と原因分析(その3)

      【設計部門の課題と原因分析 連載目次】 1. 設計部門の現状を正確に特定する 2. 課題分析と課題の根本原因除去 3. 設計部門用に用意したコン...

      【設計部門の課題と原因分析 連載目次】 1. 設計部門の現状を正確に特定する 2. 課題分析と課題の根本原因除去 3. 設計部門用に用意したコン...