LoginSignup
26
22

More than 3 years have passed since last update.

@san-tak

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

Posted at

(仮説）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SRE本

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ではどうすれば良いのか

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

  1. チームとしての能力を認識し向上していく
    • メンバ間の能力の凸凹があるのは仕方ありません。能力差があることを前提とし、チームの多様性を認め合えるようにし皆で成長していきます
    • (参考)SREチームのロールポジション（多様性）の分かりやすい図が以下のイベントセッション資料に記載されています
  2. 外部知見をフル活用
    • 独自で考えるまでもなく、色々な事例やベストプラクティスが知見として外部公開されています。次のconnpassの勉強会では、実務に沿った質の高い事例などが多く得られます

結論

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

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

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

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

参考とした資料

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

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

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

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

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

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

その他

参考書籍

  1. note記事：シリコンバレーで流行りの、分析・仕様策定・実装まで行うグロースエンジニアとは？ ↩

26
22
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
26
22