手順書、ちゃんと更新してますか
ドキュメントあるある
- 半年前に書かれたまま実態と微妙にずれていてメンテされてない
- 「ここは○○さんに聞いてください」で結局属人化している
- 手順通りにやったはずなのに途中でつまずく
- 末尾に追加されていたトラブルシューティングの章の存在に最後に気付く
- 新しいメンバーが来るたびに横について説明している
- 手順書と作業画面を行ったり来たり、視線の移動だけで疲れる
- そもそも書くのめんどくさくて後回し
特にリリース作業やテスト環境構築のような「定期的だけど手順が多い作業」は手順書だけだとどうしても限界があります。
手順書はどこまでいっても「読み物」なので、ドキュメントと作業画面を交互に見ながら「えーと次は…」と実際の自分の操作画面と手順書を突き合わせるのが結構大変です。
特に出先でMacbookの1画面しか作業空間がない時はウィンドウの切り替えの手間もあり特にストレスフルでした。
ところが最近Claudeが登場し、コーディングなどでたいへんお世話になっている中であることを思いつきました。
手順書もCoworkのスキルにしたらめっちゃ楽なのでは？？？
ということで実際に2つの業務で試してみたので、その体験をシェアします。
そもそも「スキル」って何？
Coworkのスキルとは超簡単に言うと 「Claudeに渡せる手順書」 です。
普通の手順書（マークダウンで書かれたドキュメントなど）との違いはこんな感じ
| 手順書 | Coworkのスキル | |
|---|---|---|
| 読む人 | 人間が読む | Claudeが読んで実行する |
| 対話 | 一方通行 | Coworkのチャットで質問しながら進めてくれる |
| 実行 | 読んで手作業 | ファイル編集などは自動でやってくれる |
| 状況判断 | 自分で判断 | エラーが出たらリカバリも提案してくれる |
手順書を別タブで開いて行ったり来たりする必要もなく、Coworkのチャット上で会話しながら進められるので、視線移動のストレスもなくなりそうです。
さらにClaudeで実行可能な箇所はやってくれるようになるので一石二鳥です。
事例1: Androidアプリのリリース作業
Before ― 手順書ベースの運用
弊社MGReのAndroidアプリは、リリースのたびに以下の8つの手順を行う必要があります。
- リリースブランチの切り出し
- バージョン番号の更新（複数ファイル）
- コミット＆プッシュ
- PRのdescription作成
- aarライブラリの作成・配布
- テンプレート用ブランチの作成＆更新
- リリースノートの更新
- 社内各所でリリース告知
手順書はあるものの、更新するファイルの場所やコマンドの引数を毎回確認する必要があり、1回のリリースで約半日かかることもありました。
特に厄介なのが「PRのdescription作成」で、PR番号やbacklogのチケット情報を手作業で拾って分類して整形する作業が地味に大変でした。
After ― Coworkに「リリース作業をしたい」と伝えるだけになった
Coworkで一緒にリリース作業をしながら、その手順をそのままスキルにしました。
後からスキル化もできますが、Coworkで冒頭に「これから行う作業をスキル化したい」と伝えて手順書を添付するとスムーズに移行できます。
次からはスキルがある状態で「リリース作業をしたい」とCoworkに伝えるだけで、Claudeが対話形式で進めてくれるようになります。
- 「次のバージョンは何にしますか？」と選択肢付きで聞いてくれる
- build.gradleやREADME.mdのバージョン番号を自動で書き換えてくれる
- git logからPR一覧を取得して、PRのdescriptionを自動生成してくれる
- Slack告知文も、内部変更を除外した上で作ってくれる
- git操作やビルドなど、ローカルでしかできない作業はコピペ用コマンドを生成してくれる
- エラーが起きたら原因を分析してリカバリ手順を提示してくれる
かんたん〜
手順書と照らし合わせての手作業 → Coworkとの対話ベースの半自動作業に変わったことで、作業時間も心理的な負担も大幅に減りました。
作業時間もおおよそ1時間くらいで完了できるようになったので大幅削減です。やったぜ
事例2: QAテストビルドの環境設定
Before ― パターンの多さに心が折れる
QAテスト用のビルドでは、テストパターンのスプレッドシートに基づいて設定ファイルを書き換える作業があります。アプリの会員方式や契約プランをはじめとした設定項目が多く、1パターンごとにブランチを切って設定ファイルを置換していく作業は、正確さが求められる割にひたすら単調でした。
After ― Coworkにスプレッドシートを渡すだけ
こちらもスキル化しました。Coworkのチャットにスプレッドシートを添付して「QAテストの設定をお願いします」と伝えると、Claudeがパターンを解析して必要な設定変更を全て実行してくれます。
途中から別のメンバーが作業に合流するケースにも対応していて、「ベースブランチはもう作ってありますか？」と聞くようにしたので、環境構築の重複も防止しています。
スキルにすると何が便利なのか
手順書と違ってできるところは自動でやってくれるのでその時点でめちゃくちゃ便利ではありますが、
個人的にいちばんの利点は 「作業の再現性が高い」 ことだと感じました。
手順書は、正しい手順が書いてあっても、実行するのは全て人間です。
途中でエラーが出たら自分で調べて対処するほかなく、手順書に書いていないイレギュラーには対応できません。
手順書と作業画面の間で視線を常に行ったり来たりしないといけません。
またヒューマンエラーの混入確率も非常に高いです。
Coworkのスキルなら、同じ画面のチャット上で「次にこれをやりましょう」と導いてくれるので手順書の見間違いはまず起きないはずです。
ファイル編集のように自動でできる部分は実行し、人間にしかできない部分はコピペ用のコマンドを用意してくれます。エラーが出たら「これが原因だと思います、こうすれば直ります」と提案もしてくれました （過信は禁物） 。
スキルのつくりかた＆共有のしかた
作ったスキルをチームに展開するのもCowork上で完結します。
スキルのつくりかた
チャット画面左上あたりの表題のところから作業をスキルにできます。
ただ初めから定型作業をスキル化しようと思っている場合は
チャットで作業を始める前に「これから行う作業を最終的にスキルにしたい」と伝えておくと向こうで初めからそのつもりで準備してくれてるのでスムーズな気がします。
そのあとに手順書として用意してあるものがある場合はそのマークダウンなりなんなりを渡すとその内容に沿って一緒に作業してくれます。
共有のしかた
1.Coworkのチャット画面左下にある+アイコンから 「スキルの管理」 を開く
2.スキル一覧から、共有したいスキルを見つけて、右上の 「共有」 ボタンをクリック
3.共有ダイアログで「一般アクセス」を 「組織の全員」 に設定して「共有」をクリック
これで組織のメンバー全員がこのスキルを使えるようになります。
使う側（共有されたスキルを追加する人）
使う側は「スキルの管理」を開き、左上+アイコンから 「スキルを閲覧」 でディレクトリを開きます。
ここから 「共有済み」タブ を選択すると社内で他の人が作って公開しているスキルが表示されるのでここから追加すればOKです。
これで自分のスキル一覧に追加されるので、あとはCoworkで「リリース作業をしたい」「QAテストの設定をお願いします」のように指示すればチャットから作業を開始できます。
注意点・限界
とはいえスキルも万能ではないので、限界も正直に書いておきます。
ローカル操作は人間の仕事: gitのpushやGradleビルドなど、ローカル環境でしか実行できない操作はClaudeにはできません。コマンドは生成してくれるのでCoworkの画面からコピペして実行する形になります。ここは現状しょうがない。
スキル自体のメンテは必要: プロジェクトの構成が変わったらスキルも更新しないといけません。ただ手順書の更新と違って、Coworkで「スキルのここ修正して」と頼めばやってくれるのでハードルはだいぶ低いと思います。
初回は手間がかかる: スキルを作るにはまず作業の全体像を整理する必要があります。前述の通りCoworkで一緒に作業しながらスキルに仕上げてもらえば、実質的な追加コストはほとんどないです。
スキル化に向かない作業もある: 1回きりの作業や毎回やり方が全然違う作業（新機能の設計とか）、あえて人に覚えてほしい研修的な作業などはスキル化しても旨味が薄いです。「手順にパターンがあって繰り返す作業」がスキル化に向いてます。
過信は禁物: スキルがあってもClaudeの提案が常に正しいとは限りません。特にエラー対応やリカバリの提案は鵜呑みにせず、自分でも必ず最終確認するクセはつけてたほうがいいです。マジで。
まとめ
「手順書を書く」こと自体は決して悪いことではありません。
でもその手順書が「定期的に実行する作業」「手順が多くてミスしやすい作業」「引き継ぎが大変な作業」に関するものなら、Coworkのスキルにしてしまうほうが圧倒的に楽なように感じます。
環境構築の手順、定期的なデータ集計、コードレビューのチェックリスト、障害対応のランブック…などなど、「手順書を書こうかな」と思ったときには「これ、Coworkのスキルにできないかな？」と考えてやってみるのもいいかもしれません。