どうも、ゆるめのミニマリスト＆へっぽこSEのアシアです。
今日の話は…
アシア
こちらの話の続き、Claudeの全体指示とプロジェクト指示編。
これは完全に自分好みにする設定だと思うので、好き勝手やっています。
幸い、うまくいっているようで、たまに情報収集のためにコンソール上で専門外のリポジトリで作業すると「おおおおおお前、勝手にそっちにいくなよ！」って叫ぶことが多々あります。
Claude Desktopの設定 > 一般 > Claudeへの指示
- 私自身の役割
- 開発ツールや設計書おきばのリストと「適宜参照すること」
- 基本的な応答ルール
- ドキュメントの作成ルール
- 製品やツール選定調査時の評価観点
書いているのはこれくらいで、特に力を入れたのは、ドキュメントの作成ルール。
QAチームや営業も見るドキュメント（ユースケースや画面遷移図などの仕様書）って、エンジニアの悪癖が出ると思うんだよね。
- 事実ではあるが、解決法を書かない
例：「XXXな場合は、エラーメッセージYYYを表示する」
このときYYYに「どうすればユーザーがこのエラーを回避できるか」が書いてあるかが大事。
「〜処理で失敗しました」なエンジニア的な言い回しにも注意。 - 事実ではあるが、長ったらしい
例：「XXXしたら圧縮する。圧縮するときは暗号化する。作成した圧縮ファイルはYYYに配置し、アップロードする。」
「XXXしたらYYYに圧縮＆暗号化し、アップロードする」で十分に伝わります。 - 開発時に気をつけたこと ≠ 優先的に伝えること
非エンジニアは温度感まで読み取れないので、補足レベルの情報は補足らしい場所や見た目を使おう - 同じコト、何度も書きがち（しかも重要じゃない）
このへんを見つけ次第、止めるルールに随時見直していっています。
最近読んでいる「やさしくわかるBABOK」の３章にも、IT技術者の文章力スキル問題として挙げられていたので、それな！の気持ち。
プロジェクトの指示
プロジェクトは主に要件定義を進めるときに作っています。
要は、主軸以外の話に脱線したくないとき、かも。
- Claudeに求める役割
- 関連資料の置き場
- 応答スタイル
Claude Desktopの設定には含めてない「Claudeに求める役割」は必ず書いています。
要件定義を進める上では、役割がとっ散らかると話もとっ散らかるし、私の考えがとっ散らかっている状態な分、Claudeさんにはドッシリ構えていてほしい。
関連資料は言わずもがな、要件定義をする上で必要な資料を列挙しています。
確定しているもの／検討中のもの／参考資料などの、各資料の立ち位置も記載しておきます。
これはClaudeさんのためでもあるし、自分の中の頭の整理も兼ねて。
応答スタイルは、主に「案を絞りすぎないこと」を目的としています。
質問には複数の案を提示すること、情報にはソースを添付すること、懸念点があるなら必ず添えること、など相談相手に求めるようなことを書いています。
このへんって、自分が相手になにを求めているかの言語化能力を問われているなぁって感じ。
必要なのは違和感の言語化能力
冒頭に書いたとおり、どちらもうまくいっているのですが、振り返ってみると、本編が意外と苦労したなぁと思います。
Claudeの回答を読んで「そうなんだけど、そうじゃないんだよ」と思うことが、最初は多々あった。
単純なモデル性能ではなく、私が目的／背景／何を求めているのかをちゃんと伝えられていない面が大きかったかも。
その上で「何をちゃんと伝えられていないのか」を明確にし、Claudeに伝え、設定に盛り込めるものは盛り込んでいかなきゃいけない。
設定への盛り込みもClaudeさんにお願いすれば良いんだけど、その盛り込む素案を見てもやっぱり「そうなんだけど、そうじゃないんだよ」と思うことが多々。
このモヤモヤの言語化が、Claudeさんの応答スピードに対して当然遅いわけで。
「明日の朝、また考えるか！」ってタスクを切り替えることも多々。
でも振り返ってみれば、この切り替えは良かったかも。
私は朝型人間なので、ひと晩おいて朝になると言語化できることが多かった。
そのぶん時間は掛かったけど、改めて自分の言語化スキルのお勉強にもなったし、なにより「自分は日本語をこねくり回すのが好きなんだな」という再認識にもなりました。
いやー、信託銀行マンさんに鍛えてもらって良かったなぁ！と転職してからずっと感謝しきり。
他にもニッチなIT関連要素をまとめていますので、よければ一覧記事もご覧ください。
