タイトルの「属人化した作業ほどskillと相性が良い」というのは数日前にどこかで見かけた言葉です。
整理された記事ではなかった気がするので多分Xのちょっとしたポストだったと思うし、なんならニュアンスもちょっと違ったかもしれません。
ただその言葉が何故か頭に残っていて、ここ数日で「確かに」と思う部分もあったので作文しておきます。
属人化とは
属人化した作業とはある特定の人にしかできない作業のことです。
- 作業手順が明文化されておらず、その人にしか作業のノウハウがない
- 作業中の判断に経験値的なものが必要になる
というのが属人化が発生する要因です。
そんなの文書化すれば良いじゃないか、と思うかもしれませんが「作業内容」は恒久的な文書とすることができるとしても「作業手順」は(時代の流れによって)毎回変わったりするので文書化してもすぐに陳腐化することがあるので難しいことがあります。
逆に言えば作業手順が明文化できる作業は属人化しません。
例えば私は「プログラミング試験/研修で使う各種プログラミング言語用のdocker image(Java, Ruby, NodeJS, Python, PHP, etc.etc...)を年に一度バージョンアップする」というタスクを持っていますがこの作業は実質確認作業が9割です。
バージョンアップ作業自体は手順化可能ですし、確認作業もある程度自動テストは作れますが「Java21をJava25に上げたらどういう問題が起こり得るか？」とかは、やってみないとわからないわけです。
実際、docker imageの作成と自動テストを通すところまでは2日で終わりましたが、むしろそこからが本番で確認作業は2週間経過した現在でもまだ終わっていません。(この作業だけをやっていたわけではないですが)
毎年確認すべきポイントを列挙したりもしていますがそこだけクリアすればOKとはならないので文書化アプローチでの属人化解消はほぼ無理だと思っています。
属人化は悪か？
本題とややそれますが、属人化が必ずしも悪ではないということについても一応書いておきます。
何故なら組織の規模や成長過程におけるポジションで変わってくるので一概には言えないからです。
例えばスタートアップ企業においては属人化はむしろ正義です。
少ない人数でとにかく成果をあげなければいけないので得意な人が得意なことをやってひたすら業務のサイクルを上げるというのは理にかなっています。
しかし、ある程度組織が育ってくると「その人しかできない」という業務の存在は逆にリスクとなります。(SPOFとかBus factorと言われるものです。)
どんな組織でも初期には属人化した作業だらけだけれども成長につれて徐々に解消していかなければならないということですね。
属人化とskill
さて、前述のdocker imageの検証作業は当然のようにclaude codeにやらせています。
(マジで便利になった。自分でひたすら検証用の使い捨てスクリプトを書いていた時代にはもう戻れない。ありがとう、AI。)
元々は、1年に1度しか発生しない作業だったのでskillにする必要性は薄いと考えてひたすら対話形式でやっていたんですが、やっている途中で気がつきました。
skill.mdはよくよく考えると作業内容の明文化と作業手順の指示そのものです。
つまり、skillを作る(正確にはAI自身に作らせる)ことは、上で難しいと書いた属人化作業の文書化そのものなのです。
しかし、単純な文書化とは決定的に違うことがいくつもあります。
- 文書は文書でしかないが、skillはそれに従って実際に作業してくれる
- 手順が陳腐化してもAIは自分よりも賢いので、それに自分で気がついてくれる
- 書いたものを読んでくれる人がいる(人じゃないけど)
など。
他にもメリットはいくつもあると思いますが、実のところここで強調したいのは最後の一つです。
上で属人化解消のための対策として文書化は有効ではないという話を長々と書いていますが、ぶっちゃけた話をすればただただめんどくさい、というもうそれだけです。
なぜ、この作業をこんなにも面倒だと感じるかというと、
- 目の前にある自分のタスクの解決には寄与しない
- 書いたところで(必要に迫られるまでは)誰も読まないと思っている
- 読まれる段階では陳腐化している可能性が高い
と思っているからです。
言い方を変えるとこの作業はコストに対して成果が圧倒的に見合っていないと思えるのです。
組織にとってSPOFの解消は死活問題なので、度々文書化してくれとの要請を受けますし、その必要性も理解できますがが、モチベーションもプライオリティもあがらずずるずると先延ばしにしてきました。
しかし、これをskillにするというのであれば話は別です。
文書を書くのは苦痛であっても、AIとの協業でskillを作っていくのは目の前のタスクをこなす作業でもあるのであまり苦ではありません。
skill化は上記の問題点すべてを完全に解決しています。
素晴らしい。
言い換えればskillを作るということは、社内で一番優秀なエンジニアに対してドキュメントを残し、引き継ぎを任せることができるということなのです。
そう考えるとお釣りが来るほどにコストと成果が見合います。
十中八九来年もこの作業をするのは自分だろうと思っていますが、その時にも役に立つし仮に自分がいなくなって経験の浅いメンバーが引き継ぐことになたとしてもskillは単なる文書よりも圧倒的に役に立つはずです。
エンジニアはもれなく全員ドキュメント書くの嫌いだと思ってますが、skillを作るのはプログラミングに通ずる楽しさがあるので、こちらの方針であれば今までまっったく進まなかった属人化タスクの文書化が進むかもしれません。
まとめ
skillについて解説した記事は山ほどありますが、それらの中ではskillを作成する動機としてあげられているのは
- 毎回同じ作業をするのがだるい
- 時短
というものが多いと思います。
これらはどちらかというと個人の業務の効率化に焦点を当てたお話です。
プロジェクトでskillを共有することもありますが、それらもちょっと枠が広がっただけで個人作業の効率化の延長でしかありません。(と思っていたけれど、改めて考えるとシニアがskillを書いてジュニアがそれを使って実装するというパターンは属人化解消の亜種ですね。ただその場合でも「属人化」というキーワードは意識されていないと思います。)
しかし、「属人化」という視点を持ってskillを使い始めるなら、これは「個人」だけではなく「組織」の業務全体を大きく改善していく可能性があると思います。
ここで、取り上げたのはかなり極端な例でしたが、会社という組織の中ではだれもがちょっとした自分だけの属人化タスクを持っていると思うので、それをskill化することは個人にとっても組織にとっても大きく価値があることだというのはもっと意識されて良いと感じます。
またAIを対話的には使っているけれどskillとかよくわからん、と思っている非エンジニアの方に対してもskillを敬遠せず使い始めるきっかけになってくれると良いなと思います。