属人性の排除と責任感の欠如について

## (仮説）
**「属人性の排除を進めると、要員の責任感が欠如するのではないか。」**

上記仮説について、システム開発・運用業務での考察をしてみます。

## 属人性排除の必要性について

#### 属人性の排除をしたい会社(経営層)側の一般的動機

* 要員を「駒」として扱える（人月単金の呪縛）
* 特定要員への依存リスクの低減
* 対外的なアピール（CMMI などの標準規格への準拠、業務改善活動、働き方改革…）

会社側からすると、「要員の管理がしやすい」と言う点に尽きます。ソフトウェアやシステムを組み上げてサービスを開始することを「均一な工業製品のように考えたい（管理したい）」、と言う古い動機からくるものかもしれません。

#### システム開発・運用実務者から見た属人性排除の意義

後述の参考資料や各種勉強会などに多くの属人性排除の事例が出ています。代表的な価値をあげてみます。

* ツールによる自動化での効率化、作業ミスの撲滅
* 作業プロセスの均一化（品質の一定化）
* ドキュメントなどの物を探す、と言ったムダの低減

属人性の排除により直接効果として、いわゆる `QCD` の改善がポイントとなります。

#### 属人性排除の真の意義は何か

属人性排除を行うことでの真の意義は、技術者の**QoEL**(Quality of Engineering Life） を高めることだと私は思います。

もう少し踏み込んで言うと、開発や運用の作業の属人性を排除することで属人性の高い人（高スキル者）をさらに高みへ上げること、です。「さらなる高み」というのは、価値を導き出す開発や研究を行ったり、サービス価値の高いシステム運用を行ったりすることです。エンジニアリングを突き詰めることになります。

これはまさに[SRE本](http://amzn.asia/d/2cHs3mx)で言うところの５０％ルール（業務の最低５０％はエンジニアリングに割り当てる）に該当します。５０％ルールを実現するためには、トイルの削減活動（属人性排除の活動の一つ）がポイントとなってきます。

SRE本
<img src="https://images-na.ssl-images-amazon.com/images/I/91qrMLHokjL.jpg" width=25%>


## 実際の現場での属人的な例

属人的なユースケースに登場する人々は、往々にしていい意味での「変わり者」と呼ばれる方々が多い気がします。彼ら・彼女らの活躍の具体的な例をみてみましょう。

#### 有事のヒーロー, ヒロイン

システムトラブルが発生した際、昼行灯（ひるあんどん）の様な人が大活躍する、ということがあります。
このような人は、なぜか**怪しい匂い**を嗅ぎ分けることができます。しかし、彼ら・彼女らは超能力者というわけではありません。トラブル発生の契機から現状の状態に至った原因の分析が素早く行えるのです。
それは、トラブル発生を引き起こした「何らかの変化や変更」とトラブルの原因への到達が以下の様なことを前もって把握できているためと思います。

* システムやソフトウエェアのアーキテクチャを熟知している
* 過去のトラブルを把握していて、その原因を記憶している
* 異常時の状況を正しく観測できる（例えばログの収集と見方）

例えば、バグが多いコンポーネントやモジュールや、課題の多い作業者、委託先などを把握・整理できていることから、発生した事象と「何らかの変化や変更」から怪しい匂いを嗅ぎ分けています。

#### ステークホルダとの人当たりが良い人

システム運用では、開発チームやオーナーなどとの人間関係的な軋轢(あつれき)が発生することが往々にしてあります。
特にリリース間近であったり、トラブル発生時などにそれぞれの役割(ロール)の責務によって意見の相違がおきます。例えば開発(Dev)は、機能追加や変更や行いたいと思い、運用側(Ops)は評価完了したシステムをできるだけ変更したくないと一般的に考えます。管理層は、とにかく約束の期日までにリリースして欲しいし予算オーバーして欲しくない、とそれぞれの主義主張がはびこってきます。
このような複雑な人間関係の中をミズスマシのように調整を進めて100%ではないが、それぞれある程度の納得感を得るような結果を得てくれるヒトがいます。
このような人は、関係者との日頃の信頼関係が構築されていることがポイントと思います。信頼関係は、一朝一夕には築くことはできません。基本的には、普段からGiveの精神が強く、この人が言うのであれば仕方ないな、と思わせるのでしょう。

#### プログラミングの美しさにこだわる

属人性観点とは少しそれるかもしれませんが、プログラミングに「芸術性(≒美しさ)」を強く求めてくる人たちがいます。
例えば、ネストの深さ、関数の行数、変数やファイル名などの命名規則、コメントの付け方、アンチパターンの排除、構造化、ゴミコードが残っていないテクニックに走っていない、・・とか。コーディング規約に記載されているものから、暗黙知的な観点まで総合して美しさを追求しています。
何事もやりすぎは、逆効果となることもありますが、美しいコードというのは、どのファイルを見ても、スッと入っていけます。言い換えれば、レビューがしやすいということで、結果的にはバグが少ない、変更がしやすいプログラムということになります。
このような人々は、プログラミングにおいても創造性を常に発揮していることから、属人性が高くなるものと思います。好きこそ物の上手なれ、です。まさにGeek だと思います。

開発だけでなくシステム運用でも、IaC ツールを使うことでコード実装することが増えてきます。同じように、他人から見てわかりやすいコードを書くべきでしょう。

<!---

#### OUTOUTの達人

過去のプロジェクトでの開発手法や、トラブルの解決方法など、定型パターンを押さえつつ新たな業務へすばやく活用できるプロジェクトマネージャがいます。

整理術がうまく、過去の情報をすぐに取り出すことができる。

常日頃、ドキュメントを整理しているメモ魔

* 開発におけるメモ
* 運用手順をドキュメント化
* 打ち合わせのメモ
* 各種展示会、勉強会のログ

単に書けば良いのではなく、要点のまとめ方、特に後から見る人（その執筆者含む）がわかるように書けているのがポイント。
Qiita にOUTPUTされている方は、まさにこのような方々
OUTPUTも多く実践しているものと思います。

* ポストモーテム

ナレッジ管理が得意

-->

## 属人性の排除を急速に進めた場合、想定される弊害

#### 作業のコモディティ化とメンバの責任感の欠如

あるプロセスについて属人性が少なくなることで、ある程度の訓練とマニュアルにて誰でも作業が出来るようになります。これにより要員の採用が容易になり、一定品質のOUTPUTをだせるといった効果が見込めます。

ただし、次のような思考で責任感が欠如した「作業」となってしまう可能性があります。

* プロセス定義に記載されていることだけ作業する（マニュアル頼み）
* 特別な工夫をしなくなる（指示されたことだけやる）
* 監視ツールから通知される計測データだけを見てしまう（監視ツールの設定は、設計している状況の定義のみ）

システム開発・運用では、「想定外」の事態が発生することが往々にしてあります。また、自動化されすぎて中で何が処理されているのかわからず手を出せなくなる、ということもあると思います。これは、AIが進化した場合も同じかもしれません。

## ではどうすれば良いのか

属人性を排除していく場合、単にマニュアル化や機械化するだけでなく次のような考慮が必要でしょう。

1. チームとしての能力を認識し向上していく
   * メンバ間の能力の凸凹があるのは仕方ありません。能力差があることを前提とし、チームの多様性を認め合えるようにし皆で成長していきます
   * (参考)SREチームのロールポジション（多様性）の分かりやすい図が以下のイベントセッション資料に記載されています
      * [SRE Lounge #7](https://sre-lounge.connpass.com/event/114005/) -> [SRE的team開発Tipsとベストプラクティスっぽい何か (P18)](https://speakerdeck.com/oguma/srede-teamkai-fa-tipstobesutopurakuteisutupoihe-ka?slide=18)
1. 外部知見をフル活用
   * 独自で考えるまでもなく、色々な事例やベストプラクティスが知見として外部公開されています。次のconnpassの勉強会では、実務に沿った質の高い事例などが多く得られます
      * [SRE Lounge](https://sre-lounge.connpass.com)
      * [NoOps Japan Community](https://noops.connpass.com)
      * [Ansible ユーザー会](https://ansible-users.connpass.com)

# 結論

仮説：「属人性の排除を進めると、要員の責任感が欠如するのではないか」

→　Yes であり、Noでもある。（結論になっておらず申し訳ありません）

今後のエンジニアは、二極化していくものと思われます。AI化・自動化で仕事を奪われてしまう人と、さらなる高みを目指し努力し新たな力を得る人とに分かれるでしょう。特に属人性の排除で得られた時間をどのように有効に使うかがポイントと思います。そういう意味で、Yes でもありNoでもあると考えます。

さらなる高みを目指す方向性(人材イメージ)は、Growth Engineer[^1] と Site Reliability Engineer(SREs) ではないでしょうか。

[^1]: [note記事：シリコンバレーで流行りの、分析・仕様策定・実装まで行うグロースエンジニアとは？](https://note.mu/tank_mouri/n/n111631aa4421)

# 参考とした資料

## 属人性の解消が必要と主張している記事

コンサル提案を行なっている企業の記事が多い印象。

* 大規模サービスあるある、”属人化”解消のための開発体制パターン
  - (2015-12-17)
  - [medium.com/eureka-engineering](https://medium.com/eureka-engineering/%E5%A4%A7%E8%A6%8F%E6%A8%A1%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%82%E3%82%8B%E3%81%82%E3%82%8B-%E5%B1%9E%E4%BA%BA%E5%8C%96-%E8%A7%A3%E6%B6%88%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E9%96%8B%E7%99%BA%E4%BD%93%E5%88%B6%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3-2beb313f6f69)

* もう「属人化」させない！ナレッジマネジメントを進めよう。
  - https://alpaca.nichimy.co.jp/news/029

* 膨大な運用コストを払っても属人化が止まらない……基幹系システムの実態とは
  - (2018-02-01)
  - https://techtarget.itmedia.co.jp/tt/news/1802/01/news01.html

* あなたのプロジェクトは大丈夫？ 属人化がもたらす見えないコストの恐怖
  - (2009-02-04)
  - https://enterprisezine.jp/iti/detail/964

* 社内SEと属人化の世にも奇妙な物語
  - (2015-11-05)
  - http://zen-in-senryoku.com/individualistic-work

* 属人化を排するということ
  - https://www.agilejapan.org/image/AgileJapan2016-pre-3-4-Ohwaki.pdf

* 属人的な業務を減らそう
  - https://kashika.biz/sps-zokujin-flowchart/

* (Qiita) 属人化を避ける
  - (2017-10-21)
  - https://qiita.com/4kizuki/items/9eddae1205dc00e9dccc

* (Qiita) 続・属人化を避ける
  - (2017-12-15)
  - https://qiita.com/4kizuki/items/3b60443ccd473d192c21


## 属人性が必ずしも悪ではないとしている記事

属人性を減らしていく必要はあるが、特定の業務については属人的であった方が成果がでる、としている記事

* 属人化とは？知らない間にリスクは増えています！！
  - (2018-08-02)
  - https://aippearnet.com/single-post/zokujinka-risuku/

* 属人化の原因を徹底分析！標準化と使い分けて、業務効率を数倍高める方法
  - (2018-03-17)
  - https://aippearnet.com/blog/individualization/

* 属人性の排除は正しいか
  - http://www.t-epoch.co.jp/KM/KM_3_1.htm

* 属人性のジレンマ
  - (2018-03-24)
  - https://qtamaki.hatenablog.com/entry/2018/03/24/160407

## 属人性が大事だと主張している記事

属人性こそがクリエィティブな仕事ができる、としている記事

* ソフトウェア開発での属人性は排除すべきでない？？
  - (2018-01-12)
  - http://bonotake.hatenablog.com/entry/2018/01/12/085058

* 属人性を排除しないことで、創造性を発揮して働く会社【連載】遊ぶように働く
  - (2019-01-09)
  - https://finders.me/articles.php?id=597

* 仕事は「属人化」したほうが、好都合なんじゃない？
  - (2012-05-09)
  - https://blogos.com/article/38672/

## その他

* 2018/11/30 に開催された[「第15回 itSMF Japanコンファレンス /EXPO」](http://conf.itsmf-japan.org/)では、SREが新たなテーマとなっている。

* ブログ記事「[SRE book から学んだことと、献身と愛情、2018 年の行動指針について](https://mozami.me/2018/01/14/impressions_of_sre_book.html)」


## 参考書籍

* [残業の9割はいらない ヤフーが実践する幸せな働き方 (光文社新書)   本間浩輔](https://www.amazon.co.jp/dp/4334043615/ref=cm_sw_r_tw_dp_U_x_d8MFCbKMQHQFP)
  - 第二章 「仕事は属人化させず、「組織」につけよ」
  - 組織としての生産性を上げることについての見解
  - 企業の歴史を重ねるごとに三流の人材ばかりなってしまう（出世のための権力闘争に勝った人ばかりになってしまう）
* [Team Geek ―Googleのギークたちはいかにしてチームを作るのか   Brian W. Fitzpatrick](https://www.amazon.co.jp/dp/4873116309/ref=cm_sw_r_tw_dp_U_x_q-MFCbQ3A61HW)
  * ものごとを突き詰めていくGeekは、まさに超属人性の塊
* [人生で大切なことはみんなマクドナルドで教わった 鴨頭 嘉人 (著)](https://www.amazon.co.jp/dp/4103328819/ref=cm_sw_em_r_mt_dp_U_YYAUCbYARXCJ8)
  * マクドナルドは、オペレーションが完全にマニュアル化されていると思っていたが、思いの外いい意味での「属人性」に依存しているということがわかる書籍
* [リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)](https://www.amazon.co.jp/dp/4873115655/ref=cm_sw_em_r_mt_dp_U_WPgWCbA0V3TAC)
  * 「美しいコードを見ると感動する。優れたコードは見た瞬間に何をしているかが伝わってくる。」とはじめに書いてある
* [人月の神話 Jr FrederickP.Brooks (著), Jr.,Frederick P. Brooks (原著), 滝沢 徹 (翻訳)](https://www.amazon.co.jp/dp/4621066080/ref=cm_sw_em_r_mt_dp_U_ZVMXCbM0AG6DK)
  * 40年前の書籍がいまでも遜色なく見えるということは、どういうことだろう
* [学びを結果に変えるアウトプット大全](https://www.amazon.co.jp/dp/4801400558/ref=cm_sw_em_r_mt_dp_U_I0MXCbGYN2X85)
  * Give, Give, Give が重要。大きなTakeを得られる
* [エンジニアのための時間管理術 Thomas A. Limoncelli (著)](https://www.amazon.co.jp/dp/4873113075/ref=cm_sw_em_r_mt_dp_U_rpNYCbVEXRWC0)
  * 9章 「ストレスの管理」9.2 休暇より引用
      * システムアドミニストレータ(SA) は、」休暇が取れないことを自慢する。「この会社は私がいないとやっていけない。だから何年も休暇を取得していない」。筆者はSAが殉教者の強迫観念を抱いている、このような人と一緒に働くのは不可能、としている
  * 10章「文書化」
      * SAが自分の作業を文書化することを要求されると疑念をいだきます。それは解雇の前兆に思えるから。
      * SAはたいてい完璧主義者。すべてを文書化することなどできるはずない
      * ギークは印刷されたドキュメントが嫌い