【組織】属人化の功罪 Webアプリエンジニア編
はじめに
主語デカを防ぐために副題を『Webアプリエンジニア編』として保険をかけさせていただいております
【キャリア】IT業界の門を叩く者へ 〜現場視点で語る適性チェック〜 Webアプリエンジニア編
主に中小企業やベンチャー企業のWeb開発現場を想定しています。
【キャリア】Webアプリを作るITエンジニアは特殊部隊なので、軍隊の一兵卒志願の若者は一度よく考えた方がいい話
対象
- 特にWebアプリ開発を主とするITの現場における属人化について知りたい方向け。
属人化の罪
ブラックボックス化する
仕事を属人化させる人は、作業手順を共有しません。記録を残すという発想もありません。「作業が必要な場合は、自分に声をかけること」というだけです。
プロジェクト管理ツールのチケットは真っ白で、担当者と進捗率を変えた跡しか残っていません。プルリクエストもブランチをプッシュしただけですし、Gitのコミットメッセージもチケットのタイトル以上のものを書きません。
自分がした作業を誰かが理解することで、誰にでもできる状態にすることをしません。このため一部の機能や仕様の囲い込みが発生します。前提として知らないと困る顧客の声や仕様上の制約も頭の中にあるだけです。だから他のメンバーが触ることができなくなります。
トンデモ工法がまかり通る
仕事が属人化することは直接不利益を生みませんが、作業を囲い込んだトキシックワーカーが権力を握ります。必ずしもブリリアントな訳ではなく、ベストプラクティスも公式ドキュメントも見ていなくて、自分に都合の良い解釈で手抜き建築をしていることがあります。
（あくまで全員ではなく、一部そういう人が出がち。後述する考察にありますが、人材不足が原因だったら当てはまらないことが多い。自己肯定感が低い系だとありがち）
ブラックボックス化したことにより、必然的にその人を頼る他ないため、マネージャーや責任者が腫れ物に触るように接するようになります。まともで勤勉なITエンジニアはそれがトンデモ工法だと直ぐに気付いて注意しますが、聞く相手でないことが多いです。
そのような現場にまともな方は長居しませんし、アンチパターンがアンチパターンを呼び、バグを隠すためにバグを覆うような実装が蔓延るも珍しくありません。ここは属人化させた人の技術力によりますが、優秀であればそもそも仕事の囲い込みをする動機がないんですよね。
とっとと自分の仕事を減らして他の作業をしたいし、休暇の調整やこの後の後継者問題もありますし。組織全体で見たときにデメリットがでかいですから。
事業継続性が著しく低下する
割と経験あると思いますが、ずっと同じITエンジニアが同じ製品を担当することは稀です。それは突然の転職や休職なこともありますし、新しい事業や企画を立ち上げるために有能が根こそぎ引き抜かれることもあります。
というか誰しも突然、トラックに跳ねられて転生する可能性がある以上、今行っている業務ですら誰かが引き継げる状態にしておくべきではあります。作業中のブランチをpushしておくとか、チケットにメモ書きを残しておくとか。
理想は子どもが突然熱を出そうが、親戚が危篤になろうが、迅速に休暇が取れた上で、現場の仕事が回る状態であることでしょう。属人化していると、その人がいないと話も作業も進まなくなります。休んだ本人は困りませんが、お客様やメンバーはとても困ります。
その人が抜けたら終わる、というのは事業継続性の面で深刻な問題です。
属人化の功績
属人化というと悪い面ばかりが取り沙汰されますが、あくまでブラックボックス化をしない前提で、いい方向の属人化としか呼べない事象もあります。
生き字引
人の出入りが激しいこの業界、対象のプロダクトを作った初期メンバーというのはとっっっても貴重です。営業なら昔から信用と徳を積んできたような担当者です。勝てません。
プロフェショナルや職人とも違うのですが、設計の意図や当時の状況、歴史的な経緯などを体験して知っている方は貴重なのです。中途参画して数日でドキュメントを叩き込んだペイペイが追いつける訳がありません。
ソースコードの深い部分や、特定の実装に対して勘のようなものが働いたり、大体どの部分が不具合や改修に関わっているかも、直ぐに分かります。そりゃ途中参画でも頑張って1日かけて調べれば分かるでしょうが、彼らはそれを一瞬で何となく分かってしまうんですよ。
これは経験の差というやつですが、誰かに教えられるものでも、作業手順書に書き出せるものでもありません。私が「人の出入りが激しいだけで負債だ」というときは、これが結構でかいです。
考察
属人化というより作りっ放しで
他と違いWebアプリ自体が更新スパンが早いので、長期間で癒着が激しいということはあまりありません。10年、20年もののプロジェクトだとなかなか香ばしいですが、リプレイスなどがあるとソースコード自体は刷新されて、そこで知識整理も多少されるので。
大体は作りっぱなしで自分だけしか分からない状態で、新しいメンバーを呼んで説明不足で衝突する、というのが多いパターンかなと思います。あとは作り逃げして転職するパターンでしょうか。
期間的に短いと巻き取るのが楽というだけであって、属人化されると解読班が苦労することに変わりはないと思います。特にインフラ周りでこれをやられると、本番を正として事細かに掘り起こしていかないといけないので難儀です。
人がいない
属人化させたくなくても属人化してしまう典型ですが、人がいません。慢性的に人材不足です。冒頭のリンク先を参照なのですが、あくまで特殊部隊のように動ける人を求めてますので、一兵卒タイプが入ってきてもどうしようもなく。
選り好みするなというご意見もごもっともなのですが、脆弱性てんこ盛りでレビュー依頼を投げてくる人や、プルリクエストが毎回数十のコメントで埋まって1週間経っても画面一つ作れない人もいたりして、かえって仕事が増えることもあり。
1プロジェクトに3人以上は、社員なり長期契約の方なりがいないと危険水域だと思いますが、そんなこと言ったら大抵のプロジェクトは危険水域なんでないか。
共有できる人がいなくて、ドキュメントを書く時間もないと、もれなく属人化します。
自己肯定感が低いのかも
これは多分に憶測が交じるのと、そういった方々を逆撫でする話なのですが。
自分にしかできない仕事を作ること、自分が必要とされていると感じることって、気持ちが良いというか、安心することではあるんですよね。会社から切られないために仕事を教えないっていうのとは、また少し違うと思います。そもそも人がいないので。
あとマウントが取りやすいし、マウントを取られたくないというのもあると思います。いつまでも自分が優位に立っていたいから、この仕事だけは自分の安全地帯みたいにしがち。
そういう行動の根源がどこからくるかというと、トキシックワーカーの自己防衛に近いものがあるのではないかと。ただそれを職場で指摘する訳にもいかないし、そういう方が自分からカウンセリングに行くことなどまずあり得ず。
これが原因だと、解決は正直難しい気がします。
おわりに
一言でざっくりまとめるなら「余裕がない」、これに尽きるのかもしれません。それは現場のこともあるし、会社のことも個人のこともあると思います。
そういう時代なのかもしれませんね。
Discussion