【読書会】読書会がただの概要発表会になるのは、きちんとプロンプトを設定していないからかもしれない
はじめに
対象
- 定期的に読書会を実施しているITエンジニアの方向け。
- 読書会に参加したことがあるITエンジニアの方向け。
曖昧なプロンプトでは有意義な時間は得られない
消極的な会話・あらすじの列挙
チーム開発の視野を広げるべく、読書会を開いている方もいると思います。あるいは前任者からの引き継ぎかもしれません。
ただ実際に運営側に立ってみると、
- 発表や議論が盛り上がらない。
- 書いてくる内容があらすじになっている。
といった状況に陥りがちです。訪れる静寂がつらい、ということもあるでしょう。あるいは一部の人だけが話し続けてしまう状況もあるかもしれません。このような状況が続くと、読書会の存在意義が分からなくなってしまいます。なぜこうなってしまうのでしょうか。
原因はプロンプト不足かも
本来IT関連でプロンプトといえば、対話型のシステムなどでユーザーが入力する指示文のことを指します。最近はAI関連で知名度が上がりました。読書会に参加するのは人間ですが、入力を受けて出力する機構に違いはありません。今一度、誘い文句を振り返ってみましょう。
「読書会やります」
「読んで感想を書いてきてね」
こんな雑なプロンプトで何を出力させようというのでしょうか。参加者に向けたもう少し丁寧なプロンプトを用意してみてもよいのではないでしょうか。それも参加者の発言を引き出し、議論が自然と生まれるようなプロンプトです。
何度か読書会を主催してみて、また参加してみて。意見交換が活発で有意義な時間が過ごせた読書会には、何個かの見えないプロンプトが隠されていたように思います。それをいくつか言語化してみようと思います。
読書会用の環境を構築する
生成AIにどれだけ優れたプロンプトを与えても、スペックが低ければ本来の性能を発揮できません。読書会も同じです。環境が整っていなければ期待したアウトプットには繋がりません。
読書時間の確保を行う
参加者が本を読み込めていない状態で、まともな議論はできません。
理由としてよくあるのは、
- 炎上プロジェクトなど、業務が立て込んでいる。
- 睡眠不足や疲労など、体調が芳しくない。
- 突発的な対応が多く、まとまった読書時間が取れない。
これらは個人の努力でどうにかなる範囲を超えていることもあります。
特に社内の公式イベントである場合、「業務外で読んでおいてください」という運用は避けるべきです。今の時代、勤務時間外に強制なんてしたら離職の一因になりかねません。もちろん部活や社外イベントなどであれば自己管理の範囲ですが、詳しくは次項で説明します。
まずは読書会に参加できる余地があるかを確認し、必要に応じて業務調整や体制の見直しから始める必要があります。
そもそも読書会への参加すら難しい状況が続いているようであれば、プロジェクト自体がキャパオーバーしているか、業務負荷が一部のメンバーに偏っている可能性があります。
読書会ができる関係性を構築する
「こいつと一緒だと飯が不味くなる」
どこかで聞いたことのある台詞かもしれません。どんな遊戯も読書会も、共にする人々との関係性が上手くいっていなければ、どんなに良い内容でも味気なくなってしまいます。
例えば、
- 何を言っても否定から入る人がいる。
- 相性が悪く、会話がすれ違いやすい。
- 最低限の準備（書籍を読む・感想などを書いてくるなど）ができていない。
といった状況では、心理的な安全性が低く、活発な対話は生まれにくいでしょう。
読書会は知的な対話の場です。必要であれば参加メンバーを再編し、同じ読書会を複数回別チームで実施するのも一つの手です。無理に開催するより、やらないという判断もよいでしょう。
また参加者はお客様ではありません。参加メンバー一人ひとりが良い読書会にしようとする責務があります。
読書会が1時間であれば、その1時間を互いに供出している訳です。開催者の準備時間も含めれば、もっとコストはかかっているでしょう。その時間に敬意を払い、お互いの貢献にリスペクトを持てるかどうか。それが場の質を大きく左右します。
読書会用プロンプトを作る
<!-- あらすじや要約は書かないでください -->
## 共有したい知見・感想
## 議論したいこと・質問したいこと
## チケット化して取り組みたいこと
進め方は色々ありますが、
- 開催趣旨の認識を揃える。
- 数日前までに読了し、上記を共有する。
- 追加調査や説明準備を行う。
- 当日、まず一人ずつ発表（他のメンバーは口を挟まない）を行う。
- 優先度の高い項目から取り上げて話し合う。
と上手くいくことが多かったです。
原則
技術書を読んで得た知識を、今後の活動に活かすこと。
プロンプト1: あらすじや要約を禁止する
つい要約やあらすじから話し始めてしまうのは、読書感想文の影響かもしれません。しかし全員が同じ本の同じ章を読んできている前提ならば、改めて内容をなぞる必要はありません。
重要な一節を取り上げるのは良いのですが、それに留まらず、
- なぜその部分が気になったのか。
- その内容に対してどう感じたのか。
といった観点を合わせて言語化することで、自然と議論の幅も広がっていきます。
プロンプト2: 疑問・質問は事前に論点化しておく
まず技術書を読んでいて、疑問が出てくるのはとても素晴らしいことです。分からないことを分からないと素直に認められるだけで、開発者として一歩抜きん出ているといってもいいでしょう。
問題はその疑問をどう料理するかです。ほぼ生のまま持っていっても、素材の味といえば聞こえはいいですが、美味しくいただくことはできません。もし議論をするなら、ある程度明確な議題とゴールを設定する必要があります。
また「誰も答えられない質問」になると厄介です。読書会で取り扱う本は読んだことがないか、あるいは自分達のレベルよりも高い本のこともあるでしょう。読書会で議題として取り上げるなら、誰かが説明できるか、疑問を共有することそのものが有意義な質問が望ましいです。
このため事前に議題や質問を共有できると理想的です。説明の準備もできますし、当日の議論が場当たり的にならずに済みます。
プロンプト3: プロジェクトで活用できないか探る
OSSや企業が主催でリポジトリを共有している前提にはなりますが、技術書で取り上げられている内容をチケット化し、業務に組み込んでしまうのが最も効率的でした。
例えばリファクタリングやテストに関する本であれば、自分達のコードに適用できるポイントは多い筈です。マジックナンバーやコメントの追加などであれば本番コードへの影響も少ないため、新入社員向けのチケットとしても良いでしょう。もし規模が大きくなるようであれば、議題として読書会に持ち込むこともできます。
このプロンプトの最大の利点は、読書会が「技術書を読んで終わり」にならないことです。せっかく良い知識を吸収しても、それを活かす場がないことが多いのです。
プロンプト4: 自分の経験や実体験に基づく知識を共有する
応用技術者試験など試験勉強の延長なら、資格取得が事実上の目的になるでしょう。その他多くの技術書を趣味で読むことは止めません。それならそれで、開催要項にそう書いておけばよいだけです。 業務時間内に実施している場合、最終的な目的は製品開発に活かすことでしょう。
職務経歴の長い中堅エンジニアは、守秘義務に違反しない程度に、現場レベルの知見を共有すると捗ります。他の現場で遭遇したアンチパターンやベストプラクティスを補足すれば、価値のある知見の共有に繋がります。
経験の浅いITエンジニアの場合は、今までの人生の中から引っ張り出しても良いです。学生時代の体験や別分野での経験から共通点を探してみると、良い切り口になることがあります。
技術書を読んで要旨を掴んでさえいれば、抽象化した上で類似の出来事を持ってきてもいいでしょう。具体的な話になれば、他のメンバーも要点が掴みやすく・話しやすくなります。
プロンプト5: プライドを捨てて素直な感想を書く
新入社員向けによく言われることですが、先輩や上司は直ぐに成果を上げることは求めません。他に出せるものはないのですから、やる気と感想を出して姿勢で示しましょう。
「何を言えばいいか分からない」と萎縮してしまうかもしれませんが、感想を素直に出すことに価値があります。もしかしたら参加者の誰かが饒舌に説明してくれるかもしれません。
分からないことは分からないと書く、もし少し調べたら分かることであれば調べる。一度と言わず二度三度と読み返す、関連書籍を読んでくる、書いた人物の来歴を調べるなど、知識や経験がなくとも動くだけでできることは沢山あります。
プロンプトn:
思い付いたら追加しますが、もし上手くいったプロンプトがあれば、コメントにて補足ください。
おわりに
とはいえ最終的には読書会の趣旨に合わせて調整するものです。これが絶対！という正解はありません。
本記事で書いた項目以外にも、本の選定・スケジューリング・当日のファシリテート・読書会後の片付けなど、様々な考慮点があります。
上記のプロンプトを参考に、ぜひ参加者に合ったスタイルを模索してみてください。
Discussion