Upgrade to Pro — share decks privately, control downloads, hide ads and more …

エンジニアのためのドキュメントライティング / Docs for Developers and...

エンジニアのためのドキュメントライティング / Docs for Developers and Paragraph Writing

2023年3月24日のNTT Tech Conference 2023で発表した「エンジニアのためのドキュメントライティング - Docs for Developers」の講演資料です。

講演詳細については次のイベントページをご覧ください。
https://ntt-developers.github.io/ntt-tech-conference/2023/

NTT Communications

March 24, 2023
Tweet

More Decks by NTT Communications

Other Decks in Technology

Transcript

  1. 5 • 岩瀬 義昌 (@iwashi86) / Yoshimasa Iwase • 本業

    ◦ NTTコムでプロダクトマネジメントや アジャイル開発の全社支援 ◦ その他、組織を強くすることなら何でも • サイドワーク ◦ 翻訳者 ◦ AIスタートアップで Co-VPoE として組織支援 ◦ 非常勤講師 ◦ ポッドキャスター (fukabori.fm)
  2. ドキュメントのライフサイクル PART I ドキュメント作成の準備 1章 読み手の理解 2章 ドキュメントの計画 PARTⅡ ドキュメントの作成 3章 ドキュメントのドラフト 4章 ドキュメントの編集

    5章 サンプルコードの組み込み 6章 ビジュアルコンテンツの追加 PARTⅢ ドキュメントの公開と運用 7章 ドキュメントの公開 8章 フィードバックの収集と組み込み 9章 ドキュメントの品質測定 10章 ドキュメントの構成 11章 ドキュメントの保守と非推奨化
  3. プロダクト開発と同じ流れ PART I ドキュメント作成の準備 1章 読み手の理解 2章 ドキュメントの計画 PARTⅡ ドキュメントの作成 3章 ドキュメントのドラフト 4章 ドキュメントの編集

    5章 サンプルコードの組み込み 6章 ビジュアルコンテンツの追加 PARTⅢ ドキュメントの公開と運用 7章 ドキュメントの公開 8章 フィードバックの収集と組み込み 9章 ドキュメントの品質測定 10章 ドキュメントの構成 11章 ドキュメントの保守と非推奨化 ユーザーを理解して ジャーニーを描く ジャーニーの中で ドキュメントが こう役立つのでは という仮説を立てる
  4. PART I ドキュメント作成の準備 1章 読み手の理解 2章 ドキュメントの計画 PARTⅡ ドキュメントの作成 3章 ドキュメントのドラフト 4章 ドキュメントの編集 5章 サンプルコードの組み込み

    6章 ビジュアルコンテンツの追加 PARTⅢ ドキュメントの公開と運用 7章 ドキュメントの公開 8章 フィードバックの収集と組み込み 9章 ドキュメントの品質測定 10章 ドキュメントの構成 11章 ドキュメントの保守と非推奨化 ユーザーを理解して ジャーニーを描く ジャーニーの中で ドキュメントが こう役立つのでは という仮説を立てる 仮説検証のために実装 (=ドキュメント実装) 設計してコードを書いて レビューするのと一緒 プロダクト開発と同じ流れ
  5. PART I ドキュメント作成の準備 1章 読み手の理解 2章 ドキュメントの計画 PARTⅡ ドキュメントの作成 3章 ドキュメントのドラフト 4章 ドキュメントの編集 5章 サンプルコードの組み込み

    6章 ビジュアルコンテンツの追加 PARTⅢ ドキュメントの公開と運用 7章 ドキュメントの公開 8章 フィードバックの収集と組み込み 9章 ドキュメントの品質測定 10章 ドキュメントの構成 11章 ドキュメントの保守と非推奨化 ユーザーを理解して ジャーニーを描く ジャーニーの中で ドキュメントが こう役立つのでは という仮説を立てる 仮説検証のために実装 (=ドキュメント実装) 設計してコードを書いて レビューするのと一緒 リリースして反応を見る ユーザーから フィードバックを集め プロダクトを改善する 不要な機能※は減らす ※ ドキュメントはプロダクトの機能の1部 プロダクト開発と同じ流れ
  6. PART I ドキュメント作成の準備 1章 読み手の理解 2章 ドキュメントの計画 PARTⅡ ドキュメントの作成 3章 ドキュメントのドラフト 4章 ドキュメントの編集 5章 サンプルコードの組み込み

    6章 ビジュアルコンテンツの追加 PARTⅢ ドキュメントの公開と運用 7章 ドキュメントの公開 8章 フィードバックの収集と組み込み 9章 ドキュメントの品質測定 10章 ドキュメントの構成 11章 ドキュメントの保守と非推奨化 ユーザーを理解して ジャーニーを描く ジャーニーの中で ドキュメントが こう役立つのでは という仮説を立てる 仮説検証のために実装 (=ドキュメント実装) 設計してコードを書いて レビューするのと一緒 リリースして反応を見る ユーザーから フィードバックを集め プロダクトを改善する 不要な機能※は減らす ※ ドキュメントはプロダクトの機能の1部 プロダクト開発と同じ流れ
  7. 🚨知識の呪い (認知バイアス) • こんな経験は? ◦ 同僚が、耳慣れない専門用語で話している ◦ 同僚が、開発環境を作る手順を教えてくれなかった ◦ デバッグでエラーメッセージを教えてくれたものの、

    他に必要な背景情報は伝えてくれなかった → 悪気があったのではなく、   おそらく知っていると思っていて伝えていない(可能性が高い)
  8. 知識の呪いをどう断ち切るか? • ユーザーへの共感が必要 ◦ そのためにユーザーの理解をしてきた • フリクションログを作る ◦ フリクション =

    原義は「摩擦」や「抵抗」 ▪ 転じて、プロダクトを使う際に 上手くつかえなかったことや違和感などを示す ◦ フリクションログはそれを記録したもの
  9. 修飾の順序 • 節(述語を含む)を先に、句を後に ❌ 白い横線の引かれた厚手の紙 (=横線が白い ことになる) ❌ 厚手の横線の引かれた白い紙 (=横線が厚手 に捉えられる) ✅ 横線の引かれた厚手の白い紙 •

    その他の原則 ◦ 長い修飾句ほど先に、短いほどあとに ◦ 大状況から小状況へ、重大なものから重大でないものへ ◦ 親和度(なじみ)の強弱による配置転換 P.43および70
  10. 動詞に「方法」「こと」などを付けて安易に名詞化しない • 冗長な、くどい日本語になるため • 例: ❌ 機能Aを使用するという方法もあります ✅ 機能Aも使用できます ❌

    Bにより改善することができます ✅ Bにより改善できます P.104 こういう基礎的な部分がたくさんあるので 良書をさっと読んでおくのがおすすめ
  11. Generative AI が全部駆逐するのでは? • 2023/3時点で、部分的にはYesっぽい ◦ 一方で、大規模に学習しているからか いまいちな日本語も生み出してくることがある (丁寧にプロンプトを書けば、かなり精度が上がる) ◦

    ただし、出力されたソースコードの安全性について プログラマが見ないといけないのと一緒で しばらくは出力されたドキュメントを見ないといけなさそう おしまい