さて、インフラ寺子屋では、ブログとして「ナレッジ」と「つれづれ」の２つのカテゴリに分けてエントリを書いていこうと思います。
「ナレッジ」では、技術的なエントリを中心に、「つれづれ」ではAkira Tsumuraの考えていることや思っている事を共有したいと思います。
よろしくお願いします。
テーマ：属人化
さて、「属人化」をテーマに、インフラエンジニアの仕事を考えてみましょう。
前回の#qpstudyで「属人化」という単語が出てきて、妙にひっかかるので、書かせてもらいたいと思います。
属人化と書けばわかりにくいですが、簡単に言えば「その人しか出来ない事がある状態」です。
さて、質問です。これはあなたの中では良いことでしょうか？悪いことでしょうか？
少し考えてみてから、↓を読んで頂ければと思います。
僕の中の結論は、属人化は良い・悪いではなく、「組織では必ず発生するもの」です。
それは組織の規模を問いません。ですので、自身のタスクを見極めて、少しづつ本来の姿にする事、上手く付き合うこと。これが大事だと思います。
身近な属人化について考えてみる
属人化について、簡単に考えてみましょう。
実は身近なところでも、属人化の有無を見ることができます。
属人化してはいけない場面として、「ファミレス・コンビニの店員」「コールセンターのオペレータ」といった例が挙げられるでしょう。簡単に言えば、「誰もが同じことが出来て、一定の品質でアウトプットできる」というタイプのタスクです。
一方、属人化している例も挙げると、例えばヘアサロンや美容院のスタイリストさん、レストランのシェフ、バーテンダーといった仕事が挙げられるでしょう。ミュージシャンやフォトグラファーといったアーティストもそうですね。男性の場合はナイト産業も含まれます。（笑）
ある日、ヘアサロンで運悪く他のスタイリストさんが当たってしまった場合、「他の人だと短めになりがちでイヤだ」「他の人だと何かセンスが違う」といった気持ちになりませんか？
実は属人化は、とてもアナログで自然な事なのです。
属人化の共通項目
さて、これらに共通する事として、属人化しないタスクには１つの共通点があります。
それは、「属人化しないタスクは、だれでも一定のトレーニングを受ければ同じタスクがこなせる」という事です。
例えばファミリーレストランのサイゼリアの場合、食器の洗い方、テーブルの拭き方、店内清掃のモップの通る経路まで、全てマニュアル化されていて、全てに評価システムが存在します。しかし、それらを全てクリアして店長に昇格するまで、アルバイトから10年かかると言われています。店長になり、はじめて店舗運営の問題を解決するタスクが与えられます。
以下の本は、サイゼリヤの運用ナレッジが多数紹介されていて、インフラエンジニアにも響くところがある一冊です。
一方、属人化する事は、言い方を変えれば「特定の人に依存している」とも言うことが出来ると思います。マニュアルやトレーニングでは伝えられない、感覚や経験といった、その人が居なければ誰も何も出来なくなる事です。
インフラエンジニアと属人化
さて、本題に戻りますが、僕らインフラエンジニアにも、属人化する・しない、そして属人化が必要なタスク・不要なタスクが存在します。
実は僕も、過去に何度もエンジニアが組織から抜ける時に、はじめて「事業・システムが１エンジニアに依存していた」という事が明るみになる事があります。
実際はとてもアナログな問題なのですが、事業の重要な部分の属人化を防ぐ方法はなかったのでしょうか。
属人化が起きやすいルール
実は、これらの組織には一定のルールがありました。
「プロジェクト（プロダクト）に対するエンジニアの数が少ない」という事です。
酷い例では、社員300人規模の会社で、社内エンジニアが3人という事もありました。
逆に、大きな組織等での「同じタスクを与えられた人数」が多いほど、属人化は発生しづらくなります。
例えば、大規模データセンタの運用エンジニアや、カスタマーエンジニアは、属人化は無い方が良いでしょう。もちろんエンジニアとして問題解決のスキルは必要だと思いますが、そのデータセンタないしベンダの製品について一定のスキルがあれば、業務をこなす事ができます。
一方、セールスエンジニアやアーキテクト、エバンジェリストといったタスクは、社内的にも対顧客としても属人化しやすいと思います。顧客から観た時に、「いつものあの人」となりやすい所がポイントだと思います。
もちろん同様のスキルを持ったエンジニアが代わりをつとめる事は可能だと思いますが、それまでの顧客との信頼関係やナレッジがコールレポートだけで共有し切れているとは言いづらく、リカバリはとても大変です。
組織のピラミッドと属人化
一般的に、組織はピラミッド型で構成されています。
このピラミッドが小さければ小さい程、構成する1人にタスクが依存する確率は高くなります。究極は個人事業主で、その１人が倒れたら事業/組織は終わります。
逆に、例えばコールセンター等のように、大きなピラミッドの下部で同じタスクをこなす人（仮に50人以上）の場合は、標準化が働いて属人化は発生しづらいと感じています。
尚、人数等は個人的な感覚なので、現場によっては規模等が変わるかもしれません。
属人化を解く為の標準化
抱えているタスクを標準化する為に、ドキュメント化やオペレータを教育する際、レビュー会やセミナーを開く事により、それまで１エンジニアで抱えていた内容を共有し展開する事で、そのタスクに関しては属人化されなくなります。
また、往々にして、ある程度のスキルのあるエンジニア間では「ドキュメントが多少無くても何とかなる」という暗黙のルールが存在しますが、これが発動されるのは最悪のケースだけにして欲しいものです。
しかし、標準化に時間がかかるにつれ新しい内容が属人化するという負のスパイラルも現実発生しています。たとえば、プロダクトの運用について標準化している間に、新しいバージョンのプロダクトがインストールされ、イレギュラー対応が属人化するケース等です。
逆に、ある企業では「初心者が観ても操作できるドキュメントを作る」というルールがありました。端的に言えば、第三者がドキュメントとマシンがあれば、すぐに代理でオペレーションできる、というレベルです。実際書いてみるととても難しく、レビューを通るのも大変ですが、ドキュメントスキルは上がります。（笑）また、副作用として、「オペレーション方法」を運用ドキュメントに記すのではなく、「目的、手段、理由」を明示的に書く事で、上記の「ドキュメントが足りない事態」に、有用なドキュメントとして働く効能があります。
小さな組織（プロジェクト）でのステータス共有
しかし、中小企業や小さな組織（プロジェクト）では、残念ながら標準化が機能しないのです。
問題点としては、やはりリソースの問題があります。
会社のリソース（お金・人・時間・ハードウェア etc…）として、とても余分な事に時間を使う余裕がありません。
スタートアップ企業等では、ナレッジは残したいけど、ドキュメントまでは要らない、というのが現実だと思います。
一方、大企業でもプロジェクトにアサインされるプロパーが少ないが為に、プロパーの間で属人化が発生している例もあります。
小さな組織では、本来は事前に全員が仲間のタスクの概要を把握していた方が、とてもスムースにタスクを引き継ぐ事ができます。現実は人間関係などありそう簡単な事では無いでしょうが、目標としては必要だと思います。
現実解としては、例えばRedmineやgit、Dropbox等を駆使したいところですが、「今、誰が何のタスクを抱えているか」という単純なステータスの共有にはとても複雑過ぎます。
個人的には、以下のサービスが理想に近いと思っていて、今個人的に検証しています。
ブラウザベースの付箋に共有機能・通知機能が付いただけの簡易なSaaSですが、iPad等ではアプリも存在しており、いつでも気軽に使うことができます。
「今日やる」「いつやる」「いつかやる」程度でタスクの日時を決める事ができ、パッと見て自分のタスクがわかるので、頭の整理になる事が１つ、他の人の付箋を見る事ができるので、そのまま情報共有になるのも１つあります。
また、シンプル故に、エンジニアでなくとも容易に使う事ができるので、ウェブ系等でデザイナー・コーダーといったタスクを超えて共有する事が可能です。
属人化は「人」だけじゃない。
属人化のような事は、社内に限らず、対企業間でも起きています。
僕も何度かかすりそうになりましたが、今回はとても良い教科書があったので、一部分を引用して紹介しましょう。
業平産業 橋本課長のセリフをご紹介します。
（引用：なれる！SE 3 レイヤー３ P.219-220より、なれる！SE Vol.4 P.127より）
「ひどいものでした。各システムの中身は完全にブラックボックス、ユーザーに開示されているドキュメントは何一つなく運用要員の数も非公開。挙句に月額費用はアウトソーシング一式×千万と丸められている有様です。資料公開を求めても業者は『サービス設備』だからと拒否する始末、運用要員数も同じく『シェアード窓口』と言って誤魔化される状態でした」
「顧客内部にシステムの内情を知っている人間はいません。インフラの規模、月刊の運用稼働、現状の構成、全てブラックボックスです。そんな状態でどこのベンダーがリプレース提案をかけられるんですか。最適構成を見積もれるんですか？」
「その-顧客の既存ベンダーですけどね」
「初めは本当にフットワークの軽い、良い業者だったそうですよ。担当範囲外のことも気にかけてやってくれて、顧客にとってみたら願ってもないパートナーだったらしいです。徐々に頼る範囲を増やしていって、運用から構成管理、しまいにリプレースサイクルまで任せきりになって......気づいた時は完全に手遅れになっていました」
これと似たようなこと、経験した事ありませんか？
「小さい会社で、システムを任されて、上手く運用していっていたら責任範囲を増やされて...」といったような事が、現実あると思います。
実は、「自分たちは何もできない事を、他社に頼む」というのが一般的な外注ですが、個人的にはシステムの発注ではやってはいけない事の１つだと思っています。
そう、この橋本課長のセリフのように。
僕の過去のお客様で、僕が書いたPHPの独自フレームワークのソースコードを、全部読んだお客様がいらっしゃいました。
その会社もシステムの運用は属人化していましたが、「自分たちで出来るけど、クォリティを管理しつつ他社に発注する」というのは、とても良いパートナーの形だと思っています。
属人化と上手く付き合う
最後に、組織である以上必ず属人化が発生する理由は、とても簡単です。
経営者は必ず属人化します。簡単に入れ替える事はできませんし、マネージャが居なくても部下が回る組織はあると思いますが、経営者が居なくなったら最終決定社不在になり、事業が回る事はありません。
上記の事から、一概に「属人化は組織にとって悪」ではなく、上手く付き合う、もしくは必要悪として捉える程度が良いと僕は思っています。
一つの解として、「ペアで１つのタスクをこなす」。いわゆるペアプログラミングですが、社内で多：多のペアを構成する事で、自ずとナレッジもスキルも共有されるのではないでしょうか。
「プロジェクトは死なないわ、チームが守るもの。」
（あなたは死なないわ、私が守るもの。/綾波レイ）
p.s.
ある会社の退職日に、僕はiDCの運用について2時間の社内セミナーを開催した事があります。iDCに置いているインフラそのものが僕1人に属人化していた為、とても2時間で伝える事はできず、なんとかネットワーク部分だけ解説して終わりました。
また、退職にあたり、何日もかけてツール類や設定等についてのドキュメントも残していきました。
…その後転職して数日し、今度はDC運用の商談として呼び出されましたが。（笑）