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

by NTT Communications

Slide 1

Slide 1 text

エンジニアのためのドキュメントライティング NTT Tech Conference 2023 (資料は別途公開) 2023年3月 NTT コミュニケーションズ岩瀬 / @iwashi86

Slide 2

Slide 2 text

1 ● エンジニアであれば「ドキュメントを書いておけば良かった」と思った経験はあるのでは？ ● 一方で「そもそも、ドキュメントの書き方を体系的に学んだことがない」という方も多いはず ● 本トークは上記を学ぶための一助としていくつかのトピックを紹介本日の対象者

Slide 3

Slide 3 text

今日のゴール (イベント終了時) ● ドキュメントライティングのスキルが高まっている

Slide 4

Slide 4 text

今日のゴール (イベント終了時) ● ドキュメントライティングのスキルが高まっている ○ ドキュメントライティングの概要を知っている ○ ドキュメントの「準備」で重要なポイントを理解しているこちらがベース→

Slide 5

Slide 5 text

今日のゴール (イベント終了時) ● ドキュメントライティングのスキルが高まっている ○ ドキュメントライティングの概要を知っている ○ ドキュメントの「準備」で重要なポイントを理解している ○ パラグラフライティングの基礎について知っているこちらがベース→

Slide 6

Slide 6 text

5 ● 岩瀬義昌 (@iwashi86) / Yoshimasa Iwase ● 本業 ○ NTTコムでプロダクトマネジメントやアジャイル開発の全社支援 ○ その他、組織を強くすることなら何でも ● サイドワーク ○ 翻訳者 ○ AIスタートアップで Co-VPoE として組織支援 ○ 非常勤講師 ○ ポッドキャスター (fukabori.fm)

Slide 7

Slide 7 text

6 本題

Slide 8

Slide 8 text

今日のアジェンダ ● ドキュメントのライフサイクル ● 特に意識しておきたい箇所 ○ 読み手の理解　および　読み方 ○ パラグラフライティング ● （時間があれば落穂拾い）

Slide 9

Slide 9 text

Slide 10

Slide 10 text

ドキュメントのライフサイクル PART I ドキュメント作成の準備 1章　読み手の理解 2章　ドキュメントの計画ドキュメントライフサイクルを右書籍の目次がカバーしているので引用します

Slide 11

Slide 11 text

ドキュメントのライフサイクル PART I ドキュメント作成の準備 1章　読み手の理解 2章　ドキュメントの計画 PARTⅡ ドキュメントの作成 3章　ドキュメントのドラフト 4章　ドキュメントの編集 5章　サンプルコードの組み込み 6章　ビジュアルコンテンツの追加

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

16 ● エンジニアがよく作る・利用するドキュメントに集中した書籍 “エンジニアのためのドキュメントライティング” 本の補足・注意点

Slide 18

Slide 18 text

17 “エンジニアのためのドキュメントライティング” 本の補足・注意点 ● エンジニアがよく作る・利用するドキュメントに集中した書籍 ○ そのため、ロジカルライティングやパラグラフライティングは説明されていない ○ ドキュメントの種類のうちコンセプトガイド等ではロジカルシンキングが効果的

Slide 19

Slide 19 text

18 ● エンジニアがよく作る・利用するドキュメントに集中した書籍 ○ そのため、ロジカルライティングやパラグラフライティングは説明されていない ○ ドキュメントの種類のうちコンセプトガイド等ではロジカルシンキングが効果的 ○ そこで、本資料後半で説明 “エンジニアのためのドキュメントライティング” 本の補足・注意点

Slide 20

Slide 20 text

Slide 21

Slide 21 text

ドキュメントを書く上で最も大事なこと

Slide 22

Slide 22 text

ドキュメントを書く上で最も大事なこと ● 読み手となるユーザーを理解すること

Slide 23

Slide 23 text

ドキュメントを書く上で最も大事なこと ● 読み手となるユーザーを理解すること ○ ユーザーは誰なのか？

Slide 24

Slide 24 text

ドキュメントを書く上で最も大事なこと ● 読み手となるユーザーを理解すること ○ ユーザーは誰なのか？ ○ ユーザーは何を達成したいのか？ ■ ユーザーはドキュメントが読みたいのではなく目の前にある課題やニーズを解決したいだけ

Slide 25

Slide 25 text

ドキュメントを書く上で最も大事なこと ● 読み手となるユーザーを理解すること ○ ユーザーは誰なのか？ ○ ユーザーは何を達成したいのか？ ■ ユーザーはドキュメントが読みたいのではなく目の前にある課題やニーズを解決したいだけ ○ ドキュメントにより、どんな課題を解きたいのか？

Slide 26

Slide 26 text

ドキュメントを書く上で最も大事なこと ● 読み手となるユーザーを理解すること ○ ユーザーは誰なのか？ ○ ユーザーは何を達成したいのか？ ■ ユーザーはドキュメントが読みたいのではなく目の前にある課題やニーズを解決したいだけ ○ ドキュメントにより、どんな課題を解きたいのか？ ● なぜか？ ○ ユーザーの理解を外すと無価値なドキュメントが爆誕する

Slide 27

Slide 27 text

それ、ビルドトラップの兆候かも？ “【資料公開】プロダクトマネジメントの ”罠”を回避しよう　より” 引用, https://www.ryuzee.com/contents/blog/14556

Slide 28

Slide 28 text

どうすればユーザーを理解できるのか？

Slide 29

Slide 29 text

どうすればユーザーを理解できるのか？チャットでの会話ログプロダクトの設計メモインタビューメモ過去のメールコミットログ他にも色々

Slide 30

Slide 30 text

どうすればユーザーを理解できるのか？チャットでの会話ログプロダクトの設計メモインタビューメモ過去のメールコミットログ他にも色々ユーザーがプロダクトを使って成し遂げたいことは？ユーザーは誰か？（ここでも仮説）

Slide 31

Slide 31 text

検証：そのユーザー理解はあっているのか？

Slide 32

Slide 32 text

検証：そのユーザー理解はあっているのか？ ● ユーザーの理解を検証する最強の方法 ○ ユーザーと直接対話してみること

Slide 33

Slide 33 text

検証：そのユーザー理解はあっているのか？ ● ユーザーの理解を検証する最強の方法 ○ ユーザーと直接対話してみること ● どうやって直接対話するか？ ○ 既存チャネルがあればそれを活用（例：カスタマーサクセス） ○ サポートチケット ○ インタビュー ○ アンケート

Slide 34

Slide 34 text

対話したら知見をまとめていく ● 代表的なまとめ方 ○ ユーザーペルソナ ○ ユーザーストーリー ○ ユーザージャーニーマップ（カスタマージャーニーマップ）

Slide 35

Slide 35 text

対話したら知見をまとめていく ● 代表的なまとめ方 ○ ユーザーペルソナ ○ ユーザーストーリー ○ ユーザージャーニーマップ（カスタマージャーニーマップ） ● なぜまとめておくのか？ ○ すぐに忘れてしまうため（覚えておけない）

Slide 36

Slide 36 text

ユーザーペルソナの例 (chatGPTのペルソナ)

Slide 37

Slide 37 text

ユーザーストーリーの例

Slide 38

Slide 38 text

ユーザージャーニーマップの例

Slide 39

Slide 39 text

ユーザージャーニーマップの例感情の起伏ラインを書くことも

Slide 40

Slide 40 text

🚨知識の呪い (認知バイアス)

Slide 41

Slide 41 text

🚨知識の呪い (認知バイアス) ● こんな経験は？ ○ 同僚が、耳慣れない専門用語で話している ○ 同僚が、開発環境を作る手順を教えてくれなかった ○ デバッグでエラーメッセージを教えてくれたものの、他に必要な背景情報は伝えてくれなかった

Slide 42

Slide 42 text

🚨知識の呪い (認知バイアス) ● こんな経験は？ ○ 同僚が、耳慣れない専門用語で話している ○ 同僚が、開発環境を作る手順を教えてくれなかった ○ デバッグでエラーメッセージを教えてくれたものの、他に必要な背景情報は伝えてくれなかった → 悪気があったのではなく、　おそらく知っていると思っていて伝えていない（可能性が高い）

Slide 43

Slide 43 text

知識の呪いをどう断ち切るか？

Slide 44

Slide 44 text

知識の呪いをどう断ち切るか？ ● ユーザーへの共感が必要 ○ そのためにユーザーの理解をしてきた

Slide 45

Slide 45 text

知識の呪いをどう断ち切るか？ ● ユーザーへの共感が必要 ○ そのためにユーザーの理解をしてきた ● フリクションログを作る ○ フリクション = 原義は「摩擦」や「抵抗」 ■ 転じて、プロダクトを使う際に上手くつかえなかったことや違和感などを示す ○ フリクションログはそれを記録したもの

Slide 46

Slide 46 text

フリクションログの例

Slide 47

Slide 47 text

余談：ドキュメントを書く上で最も難しいこととは？

Slide 48

Slide 48 text

余談：ドキュメントを書く上で最も難しいこととは？ ● 白紙から脱却すること　＝　書き始めること（類義語？ → 発表スライドの表紙ができれば終わったようなもの）

Slide 49

Slide 49 text

余談：ドキュメントを書く上で最も難しいこととは？ ● 白紙から脱却すること　＝　書き始めること ● 手を進めるコツ ○ 手に馴染んでいるツールを使うことドキュメント専用に新規に何かを学ばなくても良い ○ 紙とペンでも、ホワイトボードでも何でも良い

Slide 50

Slide 50 text

余談：ドキュメントを書く上で最も難しいこととは？ ● 白紙から脱却すること　＝　書き始めること ● 手を進めるコツ ○ 手に馴染んでいるツールを使うことドキュメント専用に新規に何かを学ばなくても良い ○ 紙とペンでも、ホワイトボードでも何でも良い https://www.youtube.com/watch?v=JV3KOJ_Z4Vs

Slide 51

Slide 51 text

50 こうして書き上げたドキュメントはどのように読まれるのか？

Slide 52

Slide 52 text

ドキュメントにまつわる真実 ● ユーザーは情報を探してドキュメントにたどり着く

Slide 53

Slide 53 text

ドキュメントにまつわる真実 ● ユーザーは情報を探してドキュメントにたどり着く ● ユーザーは書いてある内容をほとんど読まない

Slide 54

Slide 54 text

ユーザーはFパターンでドキュメントを読む https://www.nngroup.com/articles/f-shaped-pattern-reading-web-content-discovered/

Slide 55

Slide 55 text

何がユーザーにとって大事か？ ● せっかく書いたから読んで欲しい ● ユーザーが必要な情報をすばやく見つけられるのが一番良い ○ そのために「流し読み」しやすい構成にする

Slide 56

Slide 56 text

どうすれば流し読みしやすくなるか？ ● 最も重要な情報を見出し・冒頭で述べる ○ たとえば手順書であれば、手順書完了時点で達成できることを書く

Slide 57

Slide 57 text

https://docs.flutter.dev/development/ui/layout/tutorial

Slide 58

Slide 58 text

https://docs.flutter.dev/development/ui/layout/tutorial

Slide 59

Slide 59 text

どうすれば流し読みしやすくなるか？ ● 最も重要な情報を見出し・冒頭で述べる ○ たとえば手順書であれば、手順書完了時点で達成できることを書く ● 大きな文章のかたまりを分割する ○ 長い段落は流し読みが困難 ○ 見出し・リスト・サンプルコード・図表　で分割する

Slide 60

Slide 60 text

https://docs.flutter.dev/development/ui/layout/building-adaptive-apps

Slide 61

Slide 61 text

Slide 62

Slide 62 text

https://docs.flutter.dev/development/ui/layout/building-adaptive-apps この辺りがパラグラフ

Slide 63

Slide 63 text

パラグラフ ● パラグラフに含まれるものは次のいずれか

Slide 64

Slide 64 text

パラグラフ ● パラグラフに含まれるものは次のいずれか ○ 1つの主張を概論的に述べた文（トピック・センテンス）

Slide 65

Slide 65 text

パラグラフ ● パラグラフに含まれるものは次のいずれか ○ 1つの主張を概論的に述べた文（トピック・センテンス） ○ トピック・センテンスを具体的に、詳しく説明するもの（展開部の文）

Slide 66

Slide 66 text

パラグラフ ● パラグラフに含まれるものは次のいずれか ○ 1つの主張を概論的に述べた文（トピック・センテンス） ○ トピック・センテンスを具体的に、詳しく説明するもの（展開部の文） ○ そのパラグラフと他のパラグラフのつながりを示すもの

Slide 67

Slide 67 text

パラグラフ ● パラグラフに含まれるものは次のいずれか ○ 1つの主張を概論的に述べた文（トピック・センテンス） ○ トピック・センテンスを具体的に、詳しく説明するもの（展開部の文） ○ そのパラグラフと他のパラグラフのつながりを示すもの ● トピック・センテンスと関係ない文や、反する文を含んでいけない

Slide 68

Slide 68 text

具体例 A君は根っからのスポーツマンだ。夏は水泳、冬はスキー、春と秋はテニスと、日焼けのさめる間がない。いちばん年季を入れたのはスキーだという。

Slide 69

Slide 69 text

具体例の構造 A君は根っからのスポーツマンだ。夏は水泳、冬はスキー、春と秋はテニスと、日焼けのさめる間がない。いちばん年季を入れたのはスキーだという。具体化して説明トピックセンテンス展開部の文

Slide 70

Slide 70 text

ある主張（伝えたいこと＝読者の課題を解決すること） 1つのドキュメントはパラグラフが集まって構成されるこちらを参考に改変

Slide 71

Slide 71 text

ある主張（伝えたいこと＝読者の課題を解決すること）主張を説明するA 主張を説明するB 主張を説明するC 1つのドキュメントはパラグラフが集まって構成される

Slide 72

Slide 72 text

ある主張（伝えたいこと＝読者の課題を解決すること）主張を説明するA 主張を説明するB 主張を説明するC Bの具体内容① Bの具体内容② 略略 1つのドキュメントはパラグラフが集まって構成される

Slide 73

Slide 73 text

Xという技術をチームで導入すべきだたとえば

Slide 74

Slide 74 text

Xという技術をチームで導入すべきだなぜならば現行のAは 3年後にEoSとなるからたとえば注：説明上のサンプルなので、MECEではない

Slide 75

Slide 75 text

Xという技術をチームで導入すべきだなぜならば現行のAは 3年後にEoSとなるから Xは導入企業も多く、情報が世の中に多いからたとえば注：説明上のサンプルなので、MECEではない

Slide 76

Slide 76 text

Xという技術をチームで導入すべきだなぜならば現行のAは 3年後にEoSとなるから Xは導入企業も多く、情報が世の中に多いから XはBig Techが開発しており長く続く可能性が高いからたとえば注：説明上のサンプルなので、MECEではない

Slide 77

Slide 77 text

Xという技術をチームで導入すべきだなぜならば現行のAは 3年後にEoSとなるから Xは導入企業も多く、情報が世の中に多いから XはBig Techが開発しており長く続く可能性が高いからたとえば、 SOにn件の情報がある略略たとえば注：説明上のサンプルなので、MECEではない

Slide 78

Slide 78 text

Xという技術をチームで導入すべきだなぜならば現行のAは 3年後にEoSとなるから Xは導入企業も多く、情報が世の中に多いから XはBig Techが開発しており長く続く可能性が高いからたとえば、 SOにn件の情報があるたとえば、 GitHubのStar数がm件ある略略たとえば注：説明上のサンプルなので、MECEではない

Slide 79

Slide 79 text

構造上の注意点（並列性） ● 同階層の抽象度が異なると、理解が困難に + 議論が噛み合わなくなる

Slide 80

Slide 80 text

食べ物肉魚構造上の注意点（並列性） ● 同階層の抽象度が異なると、理解が困難に + 議論が噛み合わなくなる

Slide 81

Slide 81 text

食べ物肉魚バナナ構造上の注意点（並列性） ● 同階層の抽象度が異なると、理解が困難に + 議論が噛み合わなくなる明らかに1つだけ具体的であり「これはなんだろう？？？」となる詳細が知りたい場合は ←の書籍がおすすめ

Slide 82

Slide 82 text

どこまで書けばいいかは、読み手との関係・文脈依存

Slide 83

Slide 83 text

どこまで書けばいいかは、読み手との関係・文脈依存 ● 読み手との関係性が深いなら主張だけで事足りる可能性が高い ○ 例：一緒に働いて3年経ち、重要視すべき価値観があっている (とはいえ、意思決定の経緯を残すのは重要）不要かも

Slide 84

Slide 84 text

どこまで書けばいいかは、読み手との関係・文脈依存 ● 読み手との関係性が深いなら主張だけで事足りる可能性が高い ○ 例：一緒に働いて3年経ち、重要視すべき価値観があっている (とはいえ、意思決定の経緯を残すのは重要） ● 反対に浅いなら全部説明したほうが次の行動へ繋がりやすい不要かも

Slide 85

Slide 85 text

トピック・センテンスと流し読みとの関係 ● トピック・センテンスを読んだ段階でパラグラフの主張が理解できる構成であれば「このパラグラフの残りは、これを説明したいんだな」として読み飛ばせる

Slide 86

Slide 86 text

トピック・センテンスと流し読みとの関係 ● トピック・センテンスを読んだ段階でパラグラフの主張が理解できる構成であれば「このパラグラフの残りは、これを説明したいんだな」として読み飛ばせる ● 例： 8.1 文は短く仕事の文書の文は、短く、短くと心がけて書くべきである。ある人は平均50字が目標だという。（以下、略）

Slide 87

Slide 87 text

86 （時間があれば）落穂拾い

Slide 88

Slide 88 text

事実と意見をはっきり区別する ● 手順書などのテクニカルドキュメントに意見は紛れこみにくい ● 一方で設計の思想が現れるドキュメントは主観が入る ○ ここで事実と意見が混ざると理解しやすさ・信憑性が低下する

Slide 89

Slide 89 text

事実と意見が曖昧な例 “近頃の学生は整った文章を書く能力がないという声をよく聞くが，私はこれは主に理科系の学生に関していわれていることだと思う．理科系の学生がきちんとした文章を書けないことにふしぎはない．彼らの本領は文学ではないからである．” 1515/3419

Slide 90

Slide 90 text

“近頃の学生は整った文章を書く能力がないという声をよく聞くが，私はこれは主に理科系の学生に関していわれていることだと思う．理科系の学生がきちんとした文章を書けないことにふしぎはない．彼らの本領は文学ではないからである．” 1515/3419 意見事実と意見が曖昧な例

Slide 91

Slide 91 text

“近頃の学生は整った文章を書く能力がないという声をよく聞くが，私はこれは主に理科系の学生に関していわれていることだと思う．理科系の学生がきちんとした文章を書けないことにふしぎはない．彼らの本領は文学ではないからである．” 1515/3419 意見突然、事実になったため議論の土台がグラグラに事実と意見が曖昧な例

Slide 92

Slide 92 text

修飾の順序 ● 例：以下の紙を「言葉」で表現する https://unsplash.com/photos/WX5jK0BT5JQ 白い厚手横線がある

Slide 93

Slide 93 text

修飾の順序 ● 節（述語を含む）を先に、句を後に　白い横線の引かれた厚手の紙　　厚手の横線の引かれた白い紙　　横線の引かれた厚手の白い紙 P.43および70 わかりやすい文はどれ？

Slide 94

Slide 94 text

修飾の順序 ● 節（述語を含む）を先に、句を後に ❌ 白い横線の引かれた厚手の紙　（＝横線が白い　ことになる） ❌ 厚手の横線の引かれた白い紙　（＝横線が厚手　に捉えられる） ✅ 横線の引かれた厚手の白い紙 P.43および70 述語がある

Slide 95

Slide 95 text

修飾の順序 ● 節（述語を含む）を先に、句を後に ❌ 白い横線の引かれた厚手の紙　（＝横線が白い　ことになる） ❌ 厚手の横線の引かれた白い紙　（＝横線が厚手　に捉えられる） ✅ 横線の引かれた厚手の白い紙 ● その他の原則 ○ 長い修飾句ほど先に、短いほどあとに ○ 大状況から小状況へ、重大なものから重大でないものへ ○ 親和度（なじみ）の強弱による配置転換 P.43および70

Slide 96

Slide 96 text

動詞に「方法」「こと」などを付けて安易に名詞化しない ● 冗長な、くどい日本語になるため P.104

Slide 97

Slide 97 text

動詞に「方法」「こと」などを付けて安易に名詞化しない ● 冗長な、くどい日本語になるため ● 例： ❌ 機能Aを使用するという方法もあります ✅ 機能Aも使用できます P.104

Slide 98

Slide 98 text

動詞に「方法」「こと」などを付けて安易に名詞化しない ● 冗長な、くどい日本語になるため ● 例： ❌ 機能Aを使用するという方法もあります ✅ 機能Aも使用できます ❌ Bにより改善することができます ✅ Bにより改善できます（なお類義語に、「行う」もあります） P.104

Slide 99

Slide 99 text

動詞に「方法」「こと」などを付けて安易に名詞化しない ● 冗長な、くどい日本語になるため ● 例： ❌ 機能Aを使用するという方法もあります ✅ 機能Aも使用できます ❌ Bにより改善することができます ✅ Bにより改善できます P.104 こういう基礎的な部分がたくさんあるので良書をさっと読んでおくのがおすすめ

Slide 100

Slide 100 text

99 ということで

Slide 101

Slide 101 text

今日お話ししたこと ● ドキュメントのライフサイクル ● 特に意識しておきたい箇所 ○ 読み手の理解　および　読み方 ○ パラグラフライティング ● （時間があれば落穂拾い）

Slide 102

Slide 102 text

101 ゴールのおさらい

Slide 103

Slide 103 text

今日のゴール (イベント終了時) ● ドキュメントライティングのスキルが高まっている ○ ドキュメントライティングの概要を知っている ○ ドキュメントの「準備」で重要なポイントを理解している ○ パラグラフライティングの基礎について知っているおしまい

Slide 104

Slide 104 text

Generative AI が全部駆逐するのでは？ ● 2023/3時点で、部分的にはYesっぽい ○ 一方で、大規模に学習しているからかいまいちな日本語も生み出してくることがある（丁寧にプロンプトを書けば、かなり精度が上がる）

Slide 105

Slide 105 text

例 https://atmarkit.itmedia.co.jp/ait/articles/1001/19/news106_2.html から例文引用 “このコマンドの後には任意の値を設定することができる。このため、設定した値ごとに、システムの動作の確認を行わなければならない。この作業には時間がかかるため、テスト要員の追加が必要であると考えている。”

Slide 106

Slide 106 text

No content

Slide 107

Slide 107 text

Generative AI が全部駆逐するのでは？ ● 2023/3時点で、部分的にはYesっぽい ○ 一方で、大規模に学習しているからかいまいちな日本語も生み出してくることがある（丁寧にプロンプトを書けば、かなり精度が上がる） ○ ただし、出力されたソースコードの安全性についてプログラマが見ないといけないのと一緒でしばらくは出力されたドキュメントを見ないといけなさそうおしまい