エンジニアのためのドキュメントライティング / 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/

Transcript

1. エンジニアのための ドキュメントライティング NTT Tech Conference 2023 (資料は別途公開) 2023年3月 NTT コミュニケーションズ 岩瀬 / @iwashi86
2. 1 • エンジニアであれば 「ドキュメントを書いておけば良かった」 と思った経験はあるのでは？ • 一方で 「そもそも、ドキュメントの書き方を体系的に学んだことがない」 という方も多いはず • 本トークは上記を学ぶための一助としていくつかのトピックを紹介 本日の対象者
3. 今日のゴール (イベント終了時) • ドキュメントライティングのスキルが高まっている
4. 今日のゴール (イベント終了時) • ドキュメントライティングのスキルが高まっている ◦ ドキュメントライティングの概要を知っている ◦ ドキュメントの「準備」で重要なポイントを理解している こちらがベース→
5. 今日のゴール (イベント終了時) • ドキュメントライティングのスキルが高まっている ◦ ドキュメントライティングの概要を知っている ◦ ドキュメントの「準備」で重要なポイントを理解している ◦ パラグラフライティングの基礎について知っている こちらがベース→
6. 5 • 岩瀬 義昌 (@iwashi86) / Yoshimasa Iwase • 本業 ◦ NTTコムでプロダクトマネジメントや アジャイル開発の全社支援 ◦ その他、組織を強くすることなら何でも • サイドワーク ◦ 翻訳者 ◦ AIスタートアップで Co-VPoE として組織支援 ◦ 非常勤講師 ◦ ポッドキャスター (fukabori.fm)
7. 6 本題
8. 今日のアジェンダ • ドキュメントのライフサイクル • 特に意識しておきたい箇所 ◦ 読み手の理解　および　読み方 ◦ パラグラフライティング • （時間があれば落穂拾い）
9. 今日のアジェンダ • ドキュメントのライフサイクル • 特に意識しておきたい箇所 ◦ 読み手の理解　および　読み方 ◦ パラグラフライティング • （時間があれば落穂拾い）
10. ドキュメントのライフサイクル PART I ドキュメント作成の準備 1章　読み手の理解 2章　ドキュメントの計画 ドキュメントライフサイクルを 右書籍の目次がカバーしているので引用します
11. ドキュメントのライフサイクル PART I ドキュメント作成の準備 1章　読み手の理解 2章　ドキュメントの計画 PARTⅡ ドキュメントの作成 3章　ドキュメントのドラフト 4章　ドキュメントの編集 5章　サンプルコードの組み込み 6章　ビジュアルコンテンツの追加
12. ドキュメントのライフサイクル PART I ドキュメント作成の準備 1章　読み手の理解 2章　ドキュメントの計画 PARTⅡ ドキュメントの作成 3章　ドキュメントのドラフト 4章　ドキュメントの編集 5章　サンプルコードの組み込み 6章　ビジュアルコンテンツの追加 PARTⅢ ドキュメントの公開と運用 7章　ドキュメントの公開 8章　フィードバックの収集と組み込み 9章　ドキュメントの品質測定 10章　ドキュメントの構成 11章　ドキュメントの保守と非推奨化
13. プロダクト開発と同じ流れ PART I ドキュメント作成の準備 1章　読み手の理解 2章　ドキュメントの計画 PARTⅡ ドキュメントの作成 3章　ドキュメントのドラフト 4章　ドキュメントの編集 5章　サンプルコードの組み込み 6章　ビジュアルコンテンツの追加 PARTⅢ ドキュメントの公開と運用 7章　ドキュメントの公開 8章　フィードバックの収集と組み込み 9章　ドキュメントの品質測定 10章　ドキュメントの構成 11章　ドキュメントの保守と非推奨化 ユーザーを理解して ジャーニーを描く ジャーニーの中で ドキュメントが こう役立つのでは という仮説を立てる
14. PART I ドキュメント作成の準備 1章　読み手の理解 2章　ドキュメントの計画 PARTⅡ ドキュメントの作成 3章　ドキュメントのドラフト 4章　ドキュメントの編集 5章　サンプルコードの組み込み 6章　ビジュアルコンテンツの追加 PARTⅢ ドキュメントの公開と運用 7章　ドキュメントの公開 8章　フィードバックの収集と組み込み 9章　ドキュメントの品質測定 10章　ドキュメントの構成 11章　ドキュメントの保守と非推奨化 ユーザーを理解して ジャーニーを描く ジャーニーの中で ドキュメントが こう役立つのでは という仮説を立てる 仮説検証のために実装 （＝ドキュメント実装） 設計してコードを書いて レビューするのと一緒 プロダクト開発と同じ流れ
15. PART I ドキュメント作成の準備 1章　読み手の理解 2章　ドキュメントの計画 PARTⅡ ドキュメントの作成 3章　ドキュメントのドラフト 4章　ドキュメントの編集 5章　サンプルコードの組み込み 6章　ビジュアルコンテンツの追加 PARTⅢ ドキュメントの公開と運用 7章　ドキュメントの公開 8章　フィードバックの収集と組み込み 9章　ドキュメントの品質測定 10章　ドキュメントの構成 11章　ドキュメントの保守と非推奨化 ユーザーを理解して ジャーニーを描く ジャーニーの中で ドキュメントが こう役立つのでは という仮説を立てる 仮説検証のために実装 （＝ドキュメント実装） 設計してコードを書いて レビューするのと一緒 リリースして反応を見る ユーザーから フィードバックを集め プロダクトを改善する 不要な機能※は減らす ※ ドキュメントはプロダクトの機能の1部 プロダクト開発と同じ流れ
16. PART I ドキュメント作成の準備 1章　読み手の理解 2章　ドキュメントの計画 PARTⅡ ドキュメントの作成 3章　ドキュメントのドラフト 4章　ドキュメントの編集 5章　サンプルコードの組み込み 6章　ビジュアルコンテンツの追加 PARTⅢ ドキュメントの公開と運用 7章　ドキュメントの公開 8章　フィードバックの収集と組み込み 9章　ドキュメントの品質測定 10章　ドキュメントの構成 11章　ドキュメントの保守と非推奨化 ユーザーを理解して ジャーニーを描く ジャーニーの中で ドキュメントが こう役立つのでは という仮説を立てる 仮説検証のために実装 （＝ドキュメント実装） 設計してコードを書いて レビューするのと一緒 リリースして反応を見る ユーザーから フィードバックを集め プロダクトを改善する 不要な機能※は減らす ※ ドキュメントはプロダクトの機能の1部 プロダクト開発と同じ流れ
17. 16 • エンジニアがよく作る・利用するドキュメントに集中した書籍 “エンジニアのためのドキュメントライティング” 本の補足・注意点
18. 17 “エンジニアのためのドキュメントライティング” 本の補足・注意点 • エンジニアがよく作る・利用するドキュメントに集中した書籍 ◦ そのため、ロジカルライティングや パラグラフライティングは説明されていない ◦ ドキュメントの種類のうち コンセプトガイド等では ロジカルシンキングが効果的
19. 18 • エンジニアがよく作る・利用するドキュメントに集中した書籍 ◦ そのため、ロジカルライティングや パラグラフライティングは説明されていない ◦ ドキュメントの種類のうち コンセプトガイド等では ロジカルシンキングが効果的 ◦ そこで、本資料後半で説明 “エンジニアのためのドキュメントライティング” 本の補足・注意点
20. 今日のアジェンダ • ドキュメントのライフサイクル • 特に意識しておきたい箇所 ◦ 読み手の理解　および　読み方 ◦ パラグラフライティング • （時間があれば落穂拾い）
21. ドキュメントを書く上で最も大事なこと
22. ドキュメントを書く上で最も大事なこと • 読み手となるユーザーを理解すること
23. ドキュメントを書く上で最も大事なこと • 読み手となるユーザーを理解すること ◦ ユーザーは誰なのか？
24. ドキュメントを書く上で最も大事なこと • 読み手となるユーザーを理解すること ◦ ユーザーは誰なのか？ ◦ ユーザーは何を達成したいのか？ ▪ ユーザーはドキュメントが読みたいのではなく 目の前にある課題やニーズを解決したいだけ
25. ドキュメントを書く上で最も大事なこと • 読み手となるユーザーを理解すること ◦ ユーザーは誰なのか？ ◦ ユーザーは何を達成したいのか？ ▪ ユーザーはドキュメントが読みたいのではなく 目の前にある課題やニーズを解決したいだけ ◦ ドキュメントにより、どんな課題を解きたいのか？
26. ドキュメントを書く上で最も大事なこと • 読み手となるユーザーを理解すること ◦ ユーザーは誰なのか？ ◦ ユーザーは何を達成したいのか？ ▪ ユーザーはドキュメントが読みたいのではなく 目の前にある課題やニーズを解決したいだけ ◦ ドキュメントにより、どんな課題を解きたいのか？ • なぜか？ ◦ ユーザーの理解を外すと無価値なドキュメントが爆誕する
27. それ、ビルドトラップの兆候かも？ “【資料公開】プロダクトマネジメントの ”罠”を回避しよう　より” 引用, https://www.ryuzee.com/contents/blog/14556
28. どうすればユーザーを理解できるのか？
29. どうすればユーザーを理解できるのか？ チャットでの会話ログ プロダクトの設計メモ インタビューメモ 過去のメール コミットログ 他にも色々
30. どうすればユーザーを理解できるのか？ チャットでの会話ログ プロダクトの設計メモ インタビューメモ 過去のメール コミットログ 他にも色々 ユーザーがプロダクトを 使って成し遂げたいことは？ ユーザーは誰か？ （ここでも仮説）
31. 検証：そのユーザー理解はあっているのか？
32. 検証：そのユーザー理解はあっているのか？ • ユーザーの理解を検証する最強の方法 ◦ ユーザーと直接対話してみること
33. 検証：そのユーザー理解はあっているのか？ • ユーザーの理解を検証する最強の方法 ◦ ユーザーと直接対話してみること • どうやって直接対話するか？ ◦ 既存チャネルがあればそれを活用（例：カスタマーサクセス） ◦ サポートチケット ◦ インタビュー ◦ アンケート
34. 対話したら知見をまとめていく • 代表的なまとめ方 ◦ ユーザーペルソナ ◦ ユーザーストーリー ◦ ユーザージャーニーマップ（カスタマージャーニーマップ）
35. 対話したら知見をまとめていく • 代表的なまとめ方 ◦ ユーザーペルソナ ◦ ユーザーストーリー ◦ ユーザージャーニーマップ（カスタマージャーニーマップ） • なぜまとめておくのか？ ◦ すぐに忘れてしまうため（覚えておけない）
36. ユーザーペルソナの例 (chatGPTのペルソナ)
37. ユーザーストーリーの例
38. ユーザージャーニーマップの例
39. ユーザージャーニーマップの例 感情の起伏 ラインを 書くことも
40. 🚨知識の呪い (認知バイアス)
41. 🚨知識の呪い (認知バイアス) • こんな経験は？ ◦ 同僚が、耳慣れない専門用語で話している ◦ 同僚が、開発環境を作る手順を教えてくれなかった ◦ デバッグでエラーメッセージを教えてくれたものの、 他に必要な背景情報は伝えてくれなかった
42. 🚨知識の呪い (認知バイアス) • こんな経験は？ ◦ 同僚が、耳慣れない専門用語で話している ◦ 同僚が、開発環境を作る手順を教えてくれなかった ◦ デバッグでエラーメッセージを教えてくれたものの、 他に必要な背景情報は伝えてくれなかった → 悪気があったのではなく、 　 おそらく知っていると思っていて伝えていない（可能性が高い）
43. 知識の呪いをどう断ち切るか？
44. 知識の呪いをどう断ち切るか？ • ユーザーへの共感が必要 ◦ そのためにユーザーの理解をしてきた
45. 知識の呪いをどう断ち切るか？ • ユーザーへの共感が必要 ◦ そのためにユーザーの理解をしてきた • フリクションログを作る ◦ フリクション = 原義は「摩擦」や「抵抗」 ▪ 転じて、プロダクトを使う際に 上手くつかえなかったことや違和感などを示す ◦ フリクションログはそれを記録したもの
46. フリクションログの例
47. 余談：ドキュメントを書く上で最も難しいこととは？
48. 余談：ドキュメントを書く上で最も難しいこととは？ • 白紙から脱却すること　＝　書き始めること （類義語？ → 発表スライドの表紙ができれば終わったようなもの）
49. 余談：ドキュメントを書く上で最も難しいこととは？ • 白紙から脱却すること　＝　書き始めること • 手を進めるコツ ◦ 手に馴染んでいるツールを使うこと ドキュメント専用に新規に何かを学ばなくても良い ◦ 紙とペンでも、ホワイトボードでも何でも良い
50. 余談：ドキュメントを書く上で最も難しいこととは？ • 白紙から脱却すること　＝　書き始めること • 手を進めるコツ ◦ 手に馴染んでいるツールを使うこと ドキュメント専用に新規に何かを学ばなくても良い ◦ 紙とペンでも、ホワイトボードでも何でも良い https://www.youtube.com/watch?v=JV3KOJ_Z4Vs
51. 50 こうして書き上げた ドキュメントは どのように読まれるのか？
52. ドキュメントにまつわる真実 • ユーザーは情報を探してドキュメントにたどり着く
53. ドキュメントにまつわる真実 • ユーザーは情報を探してドキュメントにたどり着く • ユーザーは書いてある内容をほとんど読まない
54. ユーザーはFパターンでドキュメントを読む https://www.nngroup.com/articles/f-shaped-pattern-reading-web-content-discovered/
55. 何がユーザーにとって大事か？ • せっかく書いたから読んで欲しい • ユーザーが必要な情報をすばやく見つけられるのが一番良い ◦ そのために「流し読み」しやすい構成にする
56. どうすれば流し読みしやすくなるか？ • 最も重要な情報を見出し・冒頭で述べる ◦ たとえば手順書であれば、手順書完了時点で達成できることを書く
57. https://docs.flutter.dev/development/ui/layout/tutorial
58. https://docs.flutter.dev/development/ui/layout/tutorial
59. どうすれば流し読みしやすくなるか？ • 最も重要な情報を見出し・冒頭で述べる ◦ たとえば手順書であれば、手順書完了時点で達成できることを書く • 大きな文章のかたまりを分割する ◦ 長い段落は流し読みが困難 ◦ 見出し・リスト・サンプルコード・図表　で分割する
60. https://docs.flutter.dev/development/ui/layout/building-adaptive-apps
61. 今日のアジェンダ • ドキュメントのライフサイクル • 特に意識しておきたい箇所 ◦ 読み手の理解　および　読み方 ◦ パラグラフライティング • （時間があれば落穂拾い）
62. https://docs.flutter.dev/development/ui/layout/building-adaptive-apps この辺りが パラグラフ
63. パラグラフ • パラグラフに含まれるものは次のいずれか
64. パラグラフ • パラグラフに含まれるものは次のいずれか ◦ 1つの主張を概論的に述べた文（トピック・センテンス）
65. パラグラフ • パラグラフに含まれるものは次のいずれか ◦ 1つの主張を概論的に述べた文（トピック・センテンス） ◦ トピック・センテンスを具体的に、詳しく説明するもの（展開部の文）
66. パラグラフ • パラグラフに含まれるものは次のいずれか ◦ 1つの主張を概論的に述べた文（トピック・センテンス） ◦ トピック・センテンスを具体的に、詳しく説明するもの（展開部の文） ◦ そのパラグラフと他のパラグラフのつながりを示すもの
67. パラグラフ • パラグラフに含まれるものは次のいずれか ◦ 1つの主張を概論的に述べた文（トピック・センテンス） ◦ トピック・センテンスを具体的に、詳しく説明するもの（展開部の文） ◦ そのパラグラフと他のパラグラフのつながりを示すもの • トピック・センテンスと関係ない文や、反する文を含んでいけない
68. 具体例 A君は根っからのスポーツマンだ。 夏は水泳、冬はスキー、春と秋はテニスと、日焼けのさめる間がない。 いちばん年季を入れたのはスキーだという。
69. 具体例の構造 A君は根っからのスポーツマンだ。 夏は水泳、冬はスキー、春と秋はテニスと、日焼けのさめる間がない。 いちばん年季を入れたのはスキーだという。 具体化して説明 トピック センテンス 展開部の文
70. ある主張 （伝えたいこと＝ 読者の課題を解決すること） 1つのドキュメントはパラグラフが集まって構成される こちらを参考に改変
71. ある主張 （伝えたいこと＝ 読者の課題を解決すること） 主張を説明するA 主張を説明するB 主張を説明するC 1つのドキュメントはパラグラフが集まって構成される
72. ある主張 （伝えたいこと＝ 読者の課題を解決すること） 主張を説明するA 主張を説明するB 主張を説明するC Bの具体内容① Bの具体内容② 略 略 1つのドキュメントはパラグラフが集まって構成される
73. Xという技術を チームで導入すべきだ たとえば
74. Xという技術を チームで導入すべきだ なぜならば現行のAは 3年後にEoSとなるから たとえば 注：説明上のサンプルなので、MECEではない
75. Xという技術を チームで導入すべきだ なぜならば現行のAは 3年後にEoSとなるから Xは導入企業も多く、情報が 世の中に多いから たとえば 注：説明上のサンプルなので、MECEではない
76. Xという技術を チームで導入すべきだ なぜならば現行のAは 3年後にEoSとなるから Xは導入企業も多く、情報が 世の中に多いから XはBig Techが開発しており 長く続く可能性が高いから たとえば 注：説明上のサンプルなので、MECEではない
77. Xという技術を チームで導入すべきだ なぜならば現行のAは 3年後にEoSとなるから Xは導入企業も多く、情報が 世の中に多いから XはBig Techが開発しており 長く続く可能性が高いから たとえば、 SOにn件の情報がある 略 略 たとえば 注：説明上のサンプルなので、MECEではない
78. Xという技術を チームで導入すべきだ なぜならば現行のAは 3年後にEoSとなるから Xは導入企業も多く、情報が 世の中に多いから XはBig Techが開発しており 長く続く可能性が高いから たとえば、 SOにn件の情報がある たとえば、 GitHubのStar数がm件ある 略 略 たとえば 注：説明上のサンプルなので、MECEではない
79. 構造上の注意点（並列性） • 同階層の抽象度が異なると、理解が困難に + 議論が噛み合わなくなる
80. 食べ物 肉 魚 構造上の注意点（並列性） • 同階層の抽象度が異なると、理解が困難に + 議論が噛み合わなくなる
81. 食べ物 肉 魚 バナナ 構造上の注意点（並列性） • 同階層の抽象度が異なると、理解が困難に + 議論が噛み合わなくなる 明らかに1つだけ具体的であり 「これはなんだろう？？？」となる 詳細が知りたい場合は ←の書籍がおすすめ
82. どこまで書けばいいかは、読み手との関係・文脈依存
83. どこまで書けばいいかは、読み手との関係・文脈依存 • 読み手との関係性が深いなら 主張だけで事足りる可能性が高い ◦ 例： 一緒に働いて3年経ち、重要 視すべき価値観があっている (とはいえ、意思決定の経緯を残すのは重要） 不要かも
84. どこまで書けばいいかは、読み手との関係・文脈依存 • 読み手との関係性が深いなら 主張だけで事足りる可能性が高い ◦ 例： 一緒に働いて3年経ち、重要 視すべき価値観があっている (とはいえ、意思決定の経緯を残すのは重要） • 反対に浅いなら全部説明したほうが 次の行動へ繋がりやすい 不要かも
85. トピック・センテンスと流し読みとの関係 • トピック・センテンスを読んだ段階で パラグラフの主張が理解できる構成であれば 「このパラグラフの残りは、これを説明したいんだな」 として読み飛ばせる
86. トピック・センテンスと流し読みとの関係 • トピック・センテンスを読んだ段階で パラグラフの主張が理解できる構成であれば 「このパラグラフの残りは、これを説明したいんだな」 として読み飛ばせる • 例： 8.1 文は短く 仕事の文書の文は、短く、短くと心がけて書くべきである。 ある人は平均50字が目標だという。（以下、略）
87. 86 （時間があれば） 落穂拾い
88. 事実と意見をはっきり区別する • 手順書などのテクニカルドキュメントに意見は紛れこみにくい • 一方で設計の思想が現れるドキュメントは主観が入る ◦ ここで事実と意見が混ざると理解しやすさ・信憑性が低下する
89. 事実と意見が曖昧な例 “近頃の学生は整った文章を書く能力がないという 声をよく聞くが，私はこれは主に理科系の学生に関 していわれていることだと思う． 理科系の学生がきちんとした文章を書けないことに ふしぎはない． 彼らの本領は文学ではないからである．” 1515/3419
90. “近頃の学生は整った文章を書く能力がないという 声をよく聞くが，私はこれは主に理科系の学生に関 していわれていることだと思う． 理科系の学生がきちんとした文章を書けないことに ふしぎはない． 彼らの本領は文学ではないからである．” 1515/3419 意見 事実と意見が曖昧な例
91. “近頃の学生は整った文章を書く能力がないという 声をよく聞くが，私はこれは主に理科系の学生に関 していわれていることだと思う． 理科系の学生がきちんとした文章を書けないことに ふしぎはない． 彼らの本領は文学ではないからである．” 1515/3419 意見 突然、事実になったため 議論の土台がグラグラに 事実と意見が曖昧な例
92. 修飾の順序 • 例：以下の紙を「言葉」で表現する https://unsplash.com/photos/WX5jK0BT5JQ 白い 厚手 横線がある
93. 修飾の順序 • 節（述語を含む）を先に、句を後に 　 白い横線の引かれた厚手の紙　 　 厚手の横線の引かれた白い紙　 　 横線の引かれた厚手の白い紙 P.43および70 わかりやすい文はどれ？
94. 修飾の順序 • 節（述語を含む）を先に、句を後に ❌ 白い横線の引かれた厚手の紙　（＝横線が白い　ことになる） ❌ 厚手の横線の引かれた白い紙　（＝横線が厚手　に捉えられる） ✅ 横線の引かれた厚手の白い紙 P.43および70 述語がある
95. 修飾の順序 • 節（述語を含む）を先に、句を後に ❌ 白い横線の引かれた厚手の紙　（＝横線が白い　ことになる） ❌ 厚手の横線の引かれた白い紙　（＝横線が厚手　に捉えられる） ✅ 横線の引かれた厚手の白い紙 • その他の原則 ◦ 長い修飾句ほど先に、短いほどあとに ◦ 大状況から小状況へ、重大なものから重大でないものへ ◦ 親和度（なじみ）の強弱による配置転換 P.43および70
96. 動詞に「方法」「こと」などを付けて安易に名詞化しない • 冗長な、くどい日本語になるため P.104
97. 動詞に「方法」「こと」などを付けて安易に名詞化しない • 冗長な、くどい日本語になるため • 例： ❌ 機能Aを使用するという方法もあります ✅ 機能Aも使用できます P.104
98. 動詞に「方法」「こと」などを付けて安易に名詞化しない • 冗長な、くどい日本語になるため • 例： ❌ 機能Aを使用するという方法もあります ✅ 機能Aも使用できます ❌ Bにより改善することができます ✅ Bにより改善できます （なお類義語に、「行う」もあります） P.104
99. 動詞に「方法」「こと」などを付けて安易に名詞化しない • 冗長な、くどい日本語になるため • 例： ❌ 機能Aを使用するという方法もあります ✅ 機能Aも使用できます ❌ Bにより改善することができます ✅ Bにより改善できます P.104 こういう基礎的な部分がたくさんあるので 良書をさっと読んでおくのがおすすめ
100. 99 ということで
101. 今日お話ししたこと • ドキュメントのライフサイクル • 特に意識しておきたい箇所 ◦ 読み手の理解　および　読み方 ◦ パラグラフライティング • （時間があれば落穂拾い）
102. 101 ゴールのおさらい
103. 今日のゴール (イベント終了時) • ドキュメントライティングのスキルが高まっている ◦ ドキュメントライティングの概要を知っている ◦ ドキュメントの「準備」で重要なポイントを理解している ◦ パラグラフライティングの基礎について知っている おしまい
104. Generative AI が全部駆逐するのでは？ • 2023/3時点で、部分的にはYesっぽい ◦ 一方で、大規模に学習しているからか いまいちな日本語も生み出してくることがある （丁寧にプロンプトを書けば、かなり精度が上がる）
105. 例 https://atmarkit.itmedia.co.jp/ait/articles/1001/19/news106_2.html から例文引用 “このコマンドの後には任意の値を設定することができる。このた め、設定した値ごとに、システムの動作の確認を行わなければ ならない。この作業には時間がかかるため、テスト要員の追加 が必要であると考えている。”
107. Generative AI が全部駆逐するのでは？ • 2023/3時点で、部分的にはYesっぽい ◦ 一方で、大規模に学習しているからか いまいちな日本語も生み出してくることがある （丁寧にプロンプトを書けば、かなり精度が上がる） ◦ ただし、出力されたソースコードの安全性について プログラマが見ないといけないのと一緒で しばらくは出力されたドキュメントを見ないといけなさそう おしまい