ITの開発においては「属人性は下げるべき」というのが一般的な考え方だ
これは他の業界でも大体同じだと思う
でも、属人性を上げなければならないシーンもある
属人性が高くなると色んな問題がある
- その人が居ないと詰む
- その人に対しヒアリングが必要
- その人しかできないので、ボトルネックになる
- その人が忘れたら詰む
簡単にいえば、リスキーすぎる、仕事抱えるな、氏ね、ということだ
じゃあどうして属人性が高まるかといえば
- アウトプットする余裕が無い
- 複雑すぎて、その人が「理解」はできるが「伝える」ことができない
- 伝える先がない
などだろう
しかし、IT業界人ならこれも知ってると思うが、属人性が下げようとしても難しい
- ドキュメントが網羅的に書かれているため、理解に苦労する
- 文章ってそもそも書くのも読むのも難しい（画は書いてる暇がない）
- 例外に対応していないことがあり抜け漏れが発生する
- ドキュメントが間違っていたり古いことがある
- ドキュメントの場所が分からない
- ファイルの管理コスト、混乱
ただ、これらの問題はがあるから属人性を上げましょうというわけではなく、これらの問題は工夫して解決していきましょうという方針だ
じゃあいつ属人性を上げるべきなのか？
それは
- 議論が中途半端な状態で、再び議論が必要な状態（文脈保持が必要）
- コミュニケーションルートが多岐に及び情報が錯綜している
- それを真として進められると他に悪影響してしまう
- 間違った情報が伝搬してしまうおそれがある
これが最も起こるのが炎上案件だ
（炎上の中でも、特にスケジュールに余裕が無い時）
この時は、敢えて担当を１人に割り振ることで無理やり属人性を上げるようにしている
じゃないとどうなるかといえば
- 真実が何かが分からなくなる
- 書いて、書いた、書いてない、古い、読んで、読んだ論争になる
- 言った、言ってない論争になる
- 何でそうなの？議論が多発する
特に難しいのが「文脈の保持」で、ドキュメントには大抵結果しか書かれない
そうすると、別の人間達が似た議論をして別の答えにたどり着いたりする
その時、真実（仕様）は前の議論だろうか、後の議論だろうか？
それはどちらかが折れるか、２つのグループを合わせまた考えなおさなければ決まらない
そして、決まった結論をまた他の人に伝えなければならないのだ
そういうことがあると、混乱に拍車がかかるばかりか仕様変更（行ったり来たり）が大量に発生し、軋轢を生む
文脈は、説明するのも大変だ
これこれこういう理由で、あの人がああ言って、でも私はこう言って、でも実際こうだから、世の中的にはこれが常識で・・・
と説明するのも大変だし、「そのAさんのBって意見はおかしくない？確認してきてよ」などと言われても大変なのは分かるだろう
だとすれば、一番いいのは「まとまるまで情報を開示せず野次を排除する」ことだ
そんなこんなで、炎上シーンで属人性を安易に捨てるのは危険なのだ
ちなみに・・・
ちなみにその１．
当たり前だが属人性を上げるとその人はかなりキツイ状況に置かれる
必ずその人がボトルネックになるので
- はやくしろと急かされる
- 情報を出せとせびられる
- 何でそうなってるの？ を説明する必要がある
- 議論が大量に発生する
- 議論の文脈を全て覚えていなければならない
そして大抵このことは誰しもが何となく気づいているため、その誰にも振られていないであろう担当に名乗りを上げる人は少ない（何とかする人以外）
誰も情報をせき止めず、「属人性さげようよ」の意見に耳を傾け情報をブロードキャストしたらどうなるかといえば、上に書いたとおりだ
ちなみにその２．
属人性を捨てていいタイミングは何時なのか？ といえば
文脈を保持しなくてもよいくらいに、煮詰まってきた時だ
じゃあどう煮詰めればいいかといえば
- ロジカルに議論すればどう考えても同じ結論に達することを確認する（論破可能状態）
- 決定者の承認を得る（お客さんが言ったから状態）
- 議論した上で、誰かの意見を採用する（文句があるならその人と相談してくれ状態）
- 文脈が分かりやすいように他の面子に展開できる（起承転結状態）
こんな感じだと思う
他にもあると思うが、現状自分がみつけた方法はこのくらい
ちなみにその３．
この状況は要件定義フェーズでも発生する
会社間の場合は安易に仕様変更できないため更にシビアだ
そのため属人性の取捨選択は難しい
その場合、担当を割り振って属人性を強く持ちつつ、議事録で文脈もカバーするのが一番安全だと思う
