Webエンジニア向けプログラミング解説動画をYouTubeで配信中!
▶ チャンネル登録はこちら

【ITニュース解説】Your most reliable person is hiding your most broken process

2026年10月24日に「Dev.to」が公開したITニュース「Your most reliable person is hiding your most broken process」について初心者にもわかりやすく解説しています。

作成日: 更新日:

ITニュース概要

チーム内の「信頼できる人」が手作業で問題を解決している場合、その裏には壊れたシステムプロセスが隠れている。繰り返し行われる手動修正は、システムが抱える課題のサインだ。これらの隠れた作業を可視化し、文書化・共有・自動化することで、システム改善と業務効率向上に繋がる。

ITニュース解説

どのチームにも、あなたの周りにも、きっと一人は「あの人がいればなんとかなる」という存在の人がいるだろう。彼らは、システムが抱えるちょっとした不具合や、ルーティン作業の中で発生する「なぜかうまくいかない」事象を、まるで魔法のように解決してくれる。例えば、毎月の請求書データがなぜかうまくインポートできない時、月末のレポートが月初に必ずエラーを吐く時、顧客の注文がシステムの中で立ち往生している時などだ。これらの問題がどうやって解決されたのかを尋ねると、決まって一人の名前が挙がる。では、具体的に彼らが何をしたのかを問うと、途端に部屋が静まり返る。

このような「頼りになる人」は、実は二つの仕事をしている。一つは彼らの職務記述書に書かれている本来の仕事。そしてもう一つは、誰も気づかない「見えない仕事」だ。それは、うまく機能していないプロセスの負担を、彼ら自身が吸収するという役割である。彼らの高い能力や責任感こそが、システムの不具合やプロセスの欠陥を表面化させずに隠し続けているのだ。もし、これらの修正作業が、誰にとっても同じように苦痛で、すぐに問題として認識されるようなものであれば、とっくに何年も前に根本的な改善が施されていたはずだ。しかし、この苦痛が特定のたった一人に、毎週のように静かに集中してしまうために、その問題は組織の中で「予算を必要としない些細なこと」として見過ごされ、放置されてしまう。

この問題がどれほど深刻かを浮き彫りにするのが「バケーションテスト」と呼ばれる状況だ。その「頼りになる人」が休暇を取った週に、組織の業務のどれだけが彼らの頭の中にだけ存在していたかが明らかになる。例えば、月の初めが来ると、いつものレポートがエラーで作成できない。その時になって初めて、複数の人が同時に「誰も回避策を知らない」という事実に直面する。なぜなら、その問題の回避策は、文書化されたり共有されたりした「プロセス」ではなく、たった一人の「人」の中にだけ存在していたからだ。

ここで注意すべきは、これは個人の問題ではないという点だ。その頼りになる人が信頼できる存在であることが悪いわけでは決してない。根本的な問題は、組織のシステムにある。彼らの信頼性に無意識のうちに依存してしまい、その依存が誰も気づかないまま業務の基盤となってしまった。その「見えない仕事」を文書化したり、正当に評価したり、あるいは改善に費用を投じたりすることなく、放置してしまったシステム側に責任があるのだ。

壊れたプロセスは、自ら「私は壊れています」と大きな声で主張することはない。むしろ、同じ現象が繰り返し起こることで、その存在を静かに示唆する。同じ人が、同じ修正を、まるでカレンダーに沿って繰り返すかのように定期的に行っている状況こそが、プロセス自体が自分の重さに耐えきれていないと自白しているようなものだ。

このような繰り返される修正のリストアップは、最初は気が重い作業だが、実際にはあっという間に終わる。チーム内の頼りになる人たち一人ひとりに、シンプルに「繰り返し直しているけれど、本当は修正する必要がないはずのものは何ですか?」と尋ねてみてほしい。ほとんどの人は、おそらく1分もかからずに答えられるだろう。彼らは、誰かがその問いを投げかけてくれるのをずっと待っていたからだ。そうして集まったリストこそが、組織が抱える真の「技術的負債」のリストである。これらの問題は、個々の修正作業がたった20分程度で済んでしまうため、「計画文書に載せるほどではない」と見過ごされてきた。

しかし、たった20分の手動修正であっても、それが毎週繰り返されるとすれば、年間で一人あたり実に17時間もの時間を費やしていることになる。そして、ほとんどのチームでは、頼りになる人一人につき、このような繰り返しの修正が五つも存在している。もしそれが五つあれば、年間で85時間もの時間が、本来不要な作業に費やされている計算になる。これは決して無視できない大きなコストである。

では、この技術的負債のリストをどうすれば良いだろうか。焦ってすべてを一度に修正しようとしないことだ。まずは、これまで見過ごされてきた「見えない仕事」を「見える化」することから始めよう。具体的に、どのような問題が、どのくらいの頻度で発生し、誰がそれに気づいて、実際にどのような修正作業を行っているのかを一つ一つ書き出していく。たった一枚の紙にこの情報をまとめるだけで、組織内の議論は劇的に変わるだろう。なぜなら、これまで特定の誰かが「好意」で行っていた回避策が、明確な名称と発生頻度を持つことで、それはもはや個人の善意ではなく、「ビジネスが継続するために支払っている保守コスト」として認識されるからだ。そうすれば、その保守コストを払い続けることと、根本的な解決策に投資することの費用対効果を比較検討できるようになる。

リストアップされた項目の中には、自動化やシステムの再設計によって、比較的安価に解決できるものが見つかるかもしれない。また、手動での作業を続けるのが妥当だと判断されるものもあるだろう。しかし、そのような場合でも、一度それが問題として認識され、作業内容が文書化され、一人だけでなく複数の人で共有されることで、状況は劇的に改善される。どちらの結末も、現状(ビジネスが何にいくら費やしているかすら知らない状態)よりもはるかに良い結果をもたらすはずだ。

たいていの場合、その頼りになる人は、ヒーローになりたいわけではない。彼らが本当に望んでいるのは、毎週、問題の修正に費やしている「火曜日の時間」を、本来の仕事や、もっと創造的な活動のために取り戻すことなのだ。もしあなたのチームが、このような静かな回避策の上に成り立っていて、いつかはこの問題を解決したいと考えているのなら、まずはその「見えない仕事」を可視化することから始めてほしい。

関連コンテンツ