技術文書の品質管理(その2)技術文書を確認する人の視点から

投稿日

技術文書の品質管理(その2)技術文書を確認する人の視点から 
【目次】

    今回は、自分以外の人が技術文書の品質管理をする場合(自分が書いた技術文書を自分以外の人が確認する)に関する解説です。前回と異なり、自分以外の人の視点つまり技術文書を確認する人の視点で解説します。具体的な例として、部下が書いた技術文書を確認するとき(チェックするとき)を考えます。

     

    1.「部下が書いた技術文書をチェックするときに必要なこと」とは

    部下が書いた技術文書をチェックするときに必要なこととは「内容が明確に伝わらない書き方(わかりにくい書き方)の基準を持っていること」と「その具体的な修正方法の指示ができること」です。

     

    「〇〇君の書いたこの打ち合わせ資料は内容が明確に伝わらない(わかりにくい)ので修正してくれ」のような指示を部下が受けたとします。

     

    このように指示されれば「どこがわかりにくいのだろう?」と考え、部下は打ち合わせ資料を読み返す必要があります。この打ち合わせ資料を書いた部下は“書き手”なので“知っている人”です注1)。書き手の立場(知っている人の立場)で書いているので内容が明確に伝わらない箇所がすぐにわからないかもしれません。あるいは、内容が明確に伝わらない箇所を見つけることができないかもしれません。

     

    2. 具体的な修正方法の指示を出す

    上司が、内容が明確に伝わらない書き方の基準を持ちさらにその修正方法がわかれば、上司は、部下に対して具体的な修正方法の指示ができます。具体的な修正方法の指示を出すことで、部下も「内容が明確に伝わらない」の意味を理解したうえで自分が書いた技術文書を修正することができます。例えば、以下のような指示です。

     

    • ①結論がわかりにくいので結論を打ち合わせ資料の冒頭に書いたほうがよい。
      *「6つのルールと18の書き方注2)」の中の「書き方1:要点を冒頭に書く」に対応します。
    • ②決定事項に対して明確な根拠が書いてないので決定事項が明確に伝わる根拠を書いたほうがよい。
      *「6つのルールと18の書き方」の中の「書き方4:根拠を書く」に対応します。
    • ③この箇所は文の羅列で書いてあるので見出しを付けてかたまりに分けて書いたほうがよい。
      *「6つのルールと18の書き方」の中の「書き方6:かたまりに分けて書く」に対応します。
    • ④この文は長いため内容がわかりにくいので一文一義の考え方で書いたほうがよい。
      *「6つのルールと18の書き方」の中の「書き方16:短い文を書く」に対応します。

    技術文書の品質管理(その2)技術文書を確認する人の視点から

     

    このような具体的な修正方法を指示してもらえれば部下も修正がすぐにできます。また、内容が明確に伝わらない書き方とその修正方法も学べます。

     

    部下に具体的な修正方法の指示を出すためにも「内容が明確に伝わらない書き方(わかりにくい書き方)の基準を持つこと」と「内容が明確に伝わらない書き方の修正方法がわかること」が上司にも必要です注3)

    技術文書の品質管理(その2)技術文書を確認する人の視点から 
    【目次】

      今回は、自分以外の人が技術文書の品質管理をする場合(自分が書いた技術文書を自分以外の人が確認する)に関する解説です。前回と異なり、自分以外の人の視点つまり技術文書を確認する人の視点で解説します。具体的な例として、部下が書いた技術文書を確認するとき(チェックするとき)を考えます。

       

      1.「部下が書いた技術文書をチェックするときに必要なこと」とは

      部下が書いた技術文書をチェックするときに必要なこととは「内容が明確に伝わらない書き方(わかりにくい書き方)の基準を持っていること」と「その具体的な修正方法の指示ができること」です。

       

      「〇〇君の書いたこの打ち合わせ資料は内容が明確に伝わらない(わかりにくい)ので修正してくれ」のような指示を部下が受けたとします。

       

      このように指示されれば「どこがわかりにくいのだろう?」と考え、部下は打ち合わせ資料を読み返す必要があります。この打ち合わせ資料を書いた部下は“書き手”なので“知っている人”です注1)。書き手の立場(知っている人の立場)で書いているので内容が明確に伝わらない箇所がすぐにわからないかもしれません。あるいは、内容が明確に伝わらない箇所を見つけることができないかもしれません。

       

      2. 具体的な修正方法の指示を出す

      上司が、内容が明確に伝わらない書き方の基準を持ちさらにその修正方法がわかれば、上司は、部下に対して具体的な修正方法の指示ができます。具体的な修正方法の指示を出すことで、部下も「内容が明確に伝わらない」の意味を理解したうえで自分が書いた技術文書を修正することができます。例えば、以下のような指示です。

       

      • ①結論がわかりにくいので結論を打ち合わせ資料の冒頭に書いたほうがよい。
        *「6つのルールと18の書き方注2)」の中の「書き方1:要点を冒頭に書く」に対応します。
      • ②決定事項に対して明確な根拠が書いてないので決定事項が明確に伝わる根拠を書いたほうがよい。
        *「6つのルールと18の書き方」の中の「書き方4:根拠を書く」に対応します。
      • ③この箇所は文の羅列で書いてあるので見出しを付けてかたまりに分けて書いたほうがよい。
        *「6つのルールと18の書き方」の中の「書き方6:かたまりに分けて書く」に対応します。
      • ④この文は長いため内容がわかりにくいので一文一義の考え方で書いたほうがよい。
        *「6つのルールと18の書き方」の中の「書き方16:短い文を書く」に対応します。

      技術文書の品質管理(その2)技術文書を確認する人の視点から

       

      このような具体的な修正方法を指示してもらえれば部下も修正がすぐにできます。また、内容が明確に伝わらない書き方とその修正方法も学べます。

       

      部下に具体的な修正方法の指示を出すためにも「内容が明確に伝わらない書き方(わかりにくい書き方)の基準を持つこと」と「内容が明確に伝わらない書き方の修正方法がわかること」が上司にも必要です注3)

       

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

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

       

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

       

       

         続きを読むには・・・


      この記事の著者

      森谷 仁

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

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


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

      もっと見る
      位置関係-3 普通の組織をイノベーティブにする処方箋 (その106)

         現在、KETICモデルの中の「知識・経験を関係性で整理する」を解説しています。前回からは、KETICモデルの中の空間的な「位置(関係...

         現在、KETICモデルの中の「知識・経験を関係性で整理する」を解説しています。前回からは、KETICモデルの中の空間的な「位置(関係...


      視覚 普通の組織をイノベーティブにする処方箋 (その155)

        私が好きなNHK BSの番組に「中井精也の絶景!てつたび」があります。この番組は、中井さんという写真家が日本中や時に海外を旅して、ロー...

        私が好きなNHK BSの番組に「中井精也の絶景!てつたび」があります。この番組は、中井さんという写真家が日本中や時に海外を旅して、ロー...


      製品開発における失敗と戻り工程の考え方

          今回は新商品開発における成功度と成功しなかったときの戻り工程についてお伝えします。   まずは顧客価値創...

          今回は新商品開発における成功度と成功しなかったときの戻り工程についてお伝えします。   まずは顧客価値創...


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

      もっと見る
      サブシステムの開発目標 プロジェクト管理の仕組み (その41)

       前回までで、化粧品の自販機についてシステムの内部構造を決めました。システム内部構造は、システムを独立したサブシステムにブレークダウンしたもので、ブロック...

       前回までで、化粧品の自販機についてシステムの内部構造を決めました。システム内部構造は、システムを独立したサブシステムにブレークダウンしたもので、ブロック...


      開発者が意識したい1日のスケジューリング(午後~夜編)

        前回の記事では一日の業務を有意義なものにするため、就業前の朝の時間と午前中の脳がフレッシュなうちにアイデア創出やメンバーとのコミュニケ...

        前回の記事では一日の業務を有意義なものにするため、就業前の朝の時間と午前中の脳がフレッシュなうちにアイデア創出やメンバーとのコミュニケ...


      人的資源マネジメント:インダストリー4.0 を追いかけるその前に(その2)

       前回のその1に続いて解説します。   4. 開発・製造リンクによる製造性評価    少し具体的な例を紹介したいと思います。図...

       前回のその1に続いて解説します。   4. 開発・製造リンクによる製造性評価    少し具体的な例を紹介したいと思います。図...