これは管理上の問題です。

クリティカルなコードをデプロイする前に、バージョン管理、コードレビュー、少なくとも使用方法は文書化しておくべきです。セキュリティが懸念される場合は、適切なレビュアーを選び、レポとドキュメントを保護する。これをすぐに始められない理由はありません。

ジョブセキュリティよりも大きな問題があります

これらの開発者の誰もが、間違っても、あるいは自分の理由で、悪意のあるコードを会社に入れる可能性があります。最悪の場合、彼らは自分で作った状況（恐喝、破壊工作、産業スパイなど）を利用して、積極的に悪質な行為を行うことができます。最良の場合、彼らの不透明さは、セキュリティ上の懸念に誰もがさらされ、監査や説明責任に常に疑問符を残すことになります。何かがうまくいかない場合、誰が彼らが何らかの形で関与していなかったと言えるのでしょうか？

**経営陣に向けて報告書を作成する必要があります。

また、この男のアプローチがあなた自身の仕事だけでなく、あなたの同僚の仕事にも影響を与えている方法のリストを含めてください。

最後に、コードをバージョン管理に追加して全員が見ることができるようにしたり、誰もがアクセスできるVM上でサーバを実行したりするなど、すぐに実行すべき推奨事項をリストアップしてください。これらの対策がこの人の仕事に影響を与えることはなく、単に全体のプロセスにセキュリティと透明性を追加する方法を概説してください - make it clear that there are no reasonable objections to these measures.

おそらく、このレポートを彼に渡すときにあなたの上司と一緒に座って、あなたがここに書いた正確な恐怖を口頭で伝えてください：この男は、会社のインフラストラクチャで自分自身が帝国を築いていること、そして最終的には、彼は潜在的に危険です。もしあなたの上司がこの人物が理不尽になるかもしれないと感じているのであれば、@BillLeeper のアドバイスに従い、彼があなたの組織に危害を加えることができないように、彼のマシンを制御することをお勧めします。もちろん、それは上司が決めることである。

残念ながら、このような懸念を同僚や経営陣に話した人がいるかどうかは、実際には言われていないようですね。本当に悪意があるのでしょうか？それとも同僚が盲目なだけなのでしょうか？それとも経営者が盲目なだけなのか？

私自身も「その」人になったことがあります。

前の職場では「この小さなツールを作ってみよう」とか「簡単なものを作ってみよう」とか、いろいろな副業があったりしました。結局、社内ソフトのリソースがないんですよね…。それは通常このような何かを行った：

– 誰かがそれが適切であるかどうかを伝えるために私が選んだソリューションを見ることができますか？– 仝それにしても、このようなことをするには、簡単なツールが必要なんだよ、それをやればいいんだよ。– 男、社内で使うだけだよ。壊れた物理的な箱に他のものと一緒に入れればいいんだよ。壊れた箱の上に他の物を置いてもいいし、何の機能もない箱の上に置いてもいい。勿論、ドキュメントを書く時間的余裕はありませんでした。暇な時にやることにしたのであれば別だが。もちろん、いくつかのツールに問題があったときに言えることはすべて「作業中」でした。

そして、辞めることを決意しました。それをきっかけに、周りの人が「社内の小さな」ツールが実は重要で、「簡単な」ものはそんなに簡単なものではないことに気がついた。週末の数日間は、同僚を少しでもねじ伏せるためにドキュメントを書いていました。それからほぼ1年が経ちましたが、今でも毎月複数の電話がかかってきて、社内ツールをどうにかしたいという相談を受けています。

編集

コメントの中には、タダで手伝ってはいけないという指摘もありました。これは一般的には正しいです。私は彼らの問題を解決するために私の時間を何時間も費やしているわけではなく、質問に答えるために1分を費やしているだけだということを明確にしたかったのです。技術的には、私はこのようにして既存の慣行を可能にし、奨励していることはまだ真実です。 ところで、会社は私に以前のような問題を解決するためにパートタイムまたは時給制のポジションを提供していますが、私はそれを拒否しました。また、元同僚との 2 分間の電話は、stackexchange を訪問するのと同じくらいポジティブでリラックスできる気晴らしです。あなたの同僚はかなり有能そうですよね？経営陣に相談してみてください。彼はかけがえのない存在になりつつある」とは言わないでください。ただ彼らに尋ねてみてください-もし彼が去ったら？長期間病気になったらどうするのか？問題が現実にあることを納得させましょう。彼らは、解決策を見つけるために、その人自身とそれを議論する必要があります。もしかしたら、彼はリソースが不足しているだけかもしれません。もしかしたら、彼は「内部ソフトウェア」チームにもう一人必要としているのかもしれません。

これらの回答のほとんどは、問題の開発者側に悪意があると仮定してのものです。

サーバーの秘密の画像を作成して、その人をオフィスから連れ出す前に、一呼吸置いて、何が起こっているのかを理解してみてはどうでしょうか？

それは、問題の人が働きすぎて、十分なリソースを持っていない可能性があり、知識を共有したいと思っている可能性があります。あるいは、彼は長い間この方法でやっていて、そうでなければならないという指示を受けたことがないのかもしれません。最低限、特に彼のものが機能している場合、彼は懸念を解決し、同僚と協力する機会を得るに値するのです。ドラクシアンなオプションを検討する前に、まずコミュニケーションを試してみてください。相手に危害を加える意図がなかったのであれば、彼からの協力を期待することができます。

他の回答ではまだ見ていないことがありますが、

さりげなく新しい仕事を探し始める

もちろん、これはあなたがすでに上司と話し合っていることを前提にしています。他の回答では、これがあなたの問題ではなく、あなたのマネージャーの問題である理由や、あなたのマネージャーとの会話にどのようにアプローチするかのポイントを示しています。

今、私はあなたがあなたのマネージャーとこのことについて話した後、それなりの時間が経過した後、このことについて何も起こっていない状況を見ています。あなたは、あなたの上司がこの問題をあなたが知っているほど問題視していないように感じています。あなたの上司がこれを問題だと思っていないだけなのか、それとも単に問題を理解していないだけなのかに関わらず、ここには何かが間違っています。(しかも「非公開」のコードの話ではなく、マネージャーがそれをどうにかしていないという問題です)

そのような問題は、開発者の立場から変えることはできないでしょう。しかし、他の会社にも同じような問題を抱えていない会社はありますので、別の会社を探した方がいいかもしれません。

良い面から見れば、今のあなたにはあまりプレッシャーはありません。あなたは仕事を持っていますし、その仕事を失うことを想定していません。家賃やローン、生活費を払い続けるために妥協する必要はないでしょう。本当に好きな仕事が見つかるまで今の仕事を辞めずに、さりげなく周りを見渡してみてもいいのではないでしょうか。

ここには将来的に防ぐための良い対処法が書かれているようですが、今はどうしたらいいのかわかりません。

1. コンピュータのセキュリティを確保する。どちらかの管理者とITの専門家は、それがロックされていないと無人のときに行くか、または彼がマシンのロックを解除してアクセスを許可することを要求しに行く。その後、ネットワークからこのモンスターを取得します。彼は死んだ男のスイッチを持っている場合に備えて、HDの即時画像を作成します。すぐにこの個人を発射して下さい。ドアから彼を歩かせてください。原因を心配しないで下さい、彼のそのコンピュータに証拠の多くがあるでしょう。会社が心配な場合は、弁護士に彼の魔法を働かせてください、それは彼らが支払われるものです。チームをまとめろ 何が起こったのか説明してくれ この個人は、無謀でプロではない方法で行動していた。彼は会社を危険にさらし、そのために解雇されました。この混乱を解決するためには、すべてのリソースが必要です。チームを使って、安全なマシンなどに適切な方法でこの作業を再構築し、再配備する。チームはアプリごとに処理を進めていくことになるので 書き換えについてはすぐに心配しないで、バックドアなどがないことを確認してから、新しく管理されたハードウェア上でサービスを開始してください。この男は、おそらく黙ってはいないでしょうし、サボタージュやシステムへのアクセス権を得るために、「ハッキング」して戻ってくるでしょう。彼はまた、彼が時間をかけて相互作用したり、個人のパスワードを取得したシステムへのグローバルなパスワードを持っている可能性があります。IT部門は、すべてのユーザーにパスワードを強制的にリセットさせ、外部からのアクセスを一時的にブロックする必要があります（VPNのように）。

現在の回答やコメントのほとんどが現状を述べているだけ、もしくは極端な手段をとるための提案をしているだけです。

ただ、要約すると 2つの状況が考えられます。同僚が故意にやっている場合、この場合は悪意があり、細心の注意が必要です。または同僚はちょうど潜在的な、実際の問題と危険性を見ていない、彼らは引き起こしている、その後、彼らは “友好的 "ですが、より良いことを行うために教えられるべきである。

だから、次のロードマップは、同時に二つのことを試みています。(btw: あなたは上司ではありませんが、他の人が提供してくれた情報では、このスレッドを真剣に受け止めるために、あなたの上司を説得するために、あなたの手の中にすべてのものを持っていると思います。btw2: それでも上司が言うことを聞かない場合は、新しい仕事を探して、新しい仕事が見つかったらすぐに辞めましょう。友好的か悪意があるかどうかに関係なく、その同僚は時限爆弾を刻んでいるので、それは全く問題ではありません）。) 静かにあなたがアクセスできるすべてのもののバックアップを作成します。その過程でシステムをシャットダウンしないでください。) 作業ステーションがシャットダウンする必要がある理由を構築してください。アイデアが必要な場合は、私に連絡してください。) ハードドライブを取り出して、フルイメージを作成して、元に戻します。週末かそこらでこれをしてください

4.) システムがBIOSレベルの侵入検知機能を持っていて、それを回避できない場合は、別の理由を構築して、なぜ侵入検知システムが発火したのか。だから顧客システムなどへのアクセスは必要ないのでは？) 彼らがシステムへのアクセスを持っている場合、彼らは必要ありません、パスワードを変更し、公開鍵ログインのようなものがないことを確認し、標準以外のログインを許可するプロセスのポートをチェックしてください。cron/at ジョブをチェックし、inetd をチェックし、現在実行されているすべてのものをチェックしてください。一つ一つの pid に対して、なぜそのプロセスが実行されているのかを答えられるようにしなければなりません。) 新しい従業員を雇う（本当に新しい、全くの無名。彼は本当に良い専門家でなければなりません。あなただけのランダムな卒業した学生を取ることはできません（最高の成績を持つ1つでもありません）、あなたは大学を全く訪問したことがないが、まだすべてを知っているそれらの人の何人かを必要としています）と彼らをサポートするためにそのチームに彼を挿入します。特に彼らは他の労働者のブロッカーを引き起こしているので、それは簡単に正当化することができます。彼の公式な仕事は彼らをサポートすることですが、本当の仕事は彼らがどのように動いているのかを学ぶことです。

新人がチームに溶け込んでいるならば、彼らは友好的であると考えていいでしょう。すべてを学び、彼らがやっていることをクールに見つけて、そう。彼は二度働かなければならないので、彼に二倍のお金を払ってください。彼が家に帰ってきたら、彼が学んだことをすべて書き留め、十分な知識が転送されるとすぐに仕事を引き継ぐべきいくつかの新しく形成されたチームにそれを送らなければならないからです。

悪意のある人が彼を統合しない場合、あなたの唯一のチャンスは、あなたが十分なデータを持っていることを望むことです。そして、私が上で話していたように、新しいチームをそのコードに迅速に組み込むためには、2つ以上の追加の専門家が必要になるかもしれません。多分、あなたの会社では、いくつかの選択肢があると思いますが、私が考えられないような、文化の違いがあるかもしれません。

問題のプログラマーは、状況が何らかの形で解決されるまで、新しい仕事を与えられてはなりません。すべての新しい要件は、適切なソース管理とピアレビューの手順に従わなければならない別の開発者/チームに任されなければなりません (必要であれば新規採用者)。問題のプログラマーは、欠陥の修正や既存のレガシーの「火消し」に忙殺される可能性があります。既存のレガシーをリバースエンジニアリングし、適切なプロセスで再実装するためのリソースを割り当てなければなりません。これを行うためのコストは、既存のリスクによって正当化されなければなりません - このプログラマーが行ってきたことが突然失われた場合、ビジネスにどのようなコストがかかるのでしょうか？あるいはもっと悪いことに、どのような独自の（会社の）データが競争への損失に脆弱なのでしょうか？

それは、この従業員に尋ねる価値があるかもしれません。"もしあなたがバスに轢かれたり、世界一周の一ヶ月間のクルーズに参加することを決めたら、私たちはどうなりますか？」と聞いて、彼が進んでコードを放棄するかどうかを決めるために、反応を測ってみてください。協力的であれば、状況が敵対的になる必要はありませんが、彼の側に会社を心配する兆候がなければ、彼が触れたすべてのものを確保するのに忙しくなる時間です。

**

プロのプログラマーは、これがビジネスを運営するための方法ではないことを知っておくべきですし、もしマネージャーが他に何も知らないのであれば、彼らは少なくとも知っておくべきです。もしあなたがプログラマーを失った場合(あるいは他の何かに再割り当てされた場合)、プログラマーが自分のマシンを失った場合、あなたは問題を抱えています。

少なくともあなたは “会社のバージョン管理 "を持っているので、その戦いを戦う必要はありません。まず最初のステップは、次のことを主張することかもしれません:

• ユーザーは開発者のマシンにネットワーク接続をしないこと
• ソフトウェアは本番サーバ上で/本番サーバから実行されること
• 本番サーバ上で実行されるソフトウェアは、他の誰か(またはビルドマシン)がソース管理からビルド可能でなければならないこと

実装するには、ソースコードをチェックインし、ビルド指示を公開する必要があります。準緊急事態としてやっておいた方がいいと思います。開発者に本番サーバやビルドマシンへの書き込みアクセスを許可しない(本番コードがバージョン管理からビルド可能であることを確認するため)

それを行った後(ソースコードがバージョン管理にあり、ビルド指示書が公開されていることを確認した後)、他の開発者はソースコードを検査してメンテナンスを手伝うことを考えればよいでしょう。

• [ Get Get Rid Of Indispensable Programmer As Quickly As Possible ** は Gerald Weinberg によって 1971 に出版されたことに注意してください（だから、誰もが今頃は知っているはずです）。) 私の記憶では、元の引用は、

"プログラマーが不可欠であれば、できるだけ早く彼を処分しなさい。”

これはあなたの問題ではなく、これは管理者の責任と役割であり、あなたはただの同僚であり、おそらく必要な情報をすべて持っていません。私は同僚と関わりたいと思うよりも、自分の仕事の方が気になります。同僚のことで大騒ぎすることで、何かプラスになることがあるとは思えません。

あなたは彼を敵に回すことになるでしょうし、上司に無能であることをアピールすることになるでしょうし、頼まれたり権限がなくても内部調査をする時間があるほど仕事が少ないという印象を与えてしまいます。

問題は、この悪循環からどれだけ脱却したいか？このことについてかわいくないことを許可しないので、それは会社を費用がかかるようになっている。会社は会社が制御するコードを書くために誰かを雇うためにお金を使わなければならない。会社はコーダーからコードを要求し、必要なら法的助けとのその要求を返さなければならない。私はコードが会社によって委託されたことを指摘するだろう、コードが会社のものであるので、コードを書いている間、コーダーは会社から給料を描いたこと。コードを生成するためにコーダーの側の失敗は、最悪の場合、犯罪行為である盗みとみなされるでしょう。もし会社がこの個人から自由になるためにリソースを費やす気がないなら、あなた方がやっていることは、あなた方の歯茎をバタバタさせているだけです。コーダーが移動したり、トラックに轢かれたりしたら、会社は解決ですから、皆さんは状況に直面しなければならないでしょう。

彼らがこのようなことをしている理由を考えてみてください。時間的な制約、パフォーマンス目標、そして一貫して増加する要求に合わせて、手抜きをしている可能性があります。これは、多くの場合、技術的な負債と選択の余地がないが、オフザフーフのすべての問題を修正するために持っている1つの非常にストレスを受けたコーダーにつながります。このような立場になってしまった人は、誰にでもマイナスの影響を与えてしまうことになります。それは誰かが座ってリラックスできる楽な役割ではありません。

タイトルが示唆するように、彼らが問題を解決していないのであれば、何の問題もありません。役に立たないからといって、そのコーダーのコードを全部捨ててしまえばいいのです。

このような状況を防ぐことは、極めて基本的な経営課題である。問題を認識している管理者は能力がなく、能力がある管理者は認識していないということになります。

残念ながら、このような状況を切り離すことは難しい管理作業です。だから、この開発者の担当者は、それを防ぐことすらできなかったのだから、解決できるとは思ってはいけないのだ。 ** もし、彼らが興味を持ち、解決できるのであれば、あなたが私たちに説明した以上のことを説明する必要はありません - プログラマーではなく、プログラムとその問題点に焦点を当てて、個人的な問題を少なくしてください。もしあなたがこれを行うと、たとえそれがうまくいったとしても、開発者とそのマネージャー（おそらくあなたのマネージャーでもあるでしょう）は苦しみ、あなたに責任があることを知ることになります。これを行うことで得られる唯一の利点は、あなた自身の倫理と名誉の規範に従っているということですが、それが原因で仕事を失うかもしれません。だからこそ、他の回答のいくつかは、それを手放すか、より良い仕事を探すことをお勧めしていますが、それは賢いことです。

彼自身の自己評価の後、彼は彼が昇進する機会がないことと、会社が彼を維持しなければならない唯一の理由は、彼がコードを彼らから保留していることの両方を決定しました。

私はあなたがこれに同意するかどうかは知りませんが、もし同意するならば、コードはおそらくより良い誰かによって行われる可能性があります。あるいは、この行動が彼を決して昇進させることができないことを確実にする理由を説明しないのであれば。

私はそれがこの状況をどのように修正するかと同じくらい修正する価値があるかどうかに帰着すると思います。

これは経営者の課題です。まず経営者は、これが故意によるものかどうかを見極めようとするべきです。もしそうであれば、違反者を解雇する計画を立てるべきである。故意でない場合は、違反者を訓練する計画を立てるべきである。

彼らはプログラムを設計しています……そうすることで、徐々に入れ替えが難しくなっていきます。プログラマーが悪い

1. 無能な管理者。

これはもちろん、あなたが正しく状況を表現していると仮定してのことです。

問題1を修正することはできません。問題#2に対処できる可能性はわずかにあります。このわずかなチャンスは、いくつかの理由で上司が単に何が起こっているかを認識していない場合です。上司に行って、あなたが見ている問題と、なぜ彼らは会社のために悪いのかを彼に教えてください。上司はすでに問題を知っていて、それに対処する能力がないか、または、彼は問題を理解する能力がないことをソフトウェアとソフトウェアエンジニアを管理することについてあまり知らないので、それはおそらく失敗するでしょう。この無能なマネージャーを交代させる必要があります。

新しいマネージャーは、このプログラマーとの座談会を行い、彼にアーキテクチャを説明させ、新規開発を中止し、すべてのプロトコルを文書化するように指示します。その間に、彼は、プロトコルを文書化すると、最初のエンジニアを「助ける」ためにそこにある新しいエンジニアを取得し、ソース管理にソフトウェアを入れて、コード自体がよく文書化されていることを確認します。この新しいエンジニアは、任意の新しい開発を行い、うまくいけばバグ修正と既存のソフトウェアのマイナーな強化を行います。彼は辞めるかもしれない、かんしゃくを投げるかもしれない、騒々しく異議を唱えるかもしれない、あるいはもっと悪いことに、物事を妨害するかもしれない。だからこそ、バックアップを取ることが第一の仕事なのです。1人目のエンジニアから2人目のエンジニアへとスムーズに移行できればいいのですが、そうはならないと思ってください。最初のエンジニアが辞めるか、先に会社に対して（さらに）破壊的な行動を起こさなければ、最終的には最初のエンジニアをクビにする計画です。

このような無意味なことを続けさせてはいけないだけです。長引けば長引くほど、最終的には修正するのが苦痛になる。それはすでに苦痛になるので、それを修正しないことは、これについて考えるための絶対に間違った方法です。

この場合、私は修辞的な「あなた」を使用していました。あなたが個人的に何ができるかという質問に答えるためには、上で言ったように、上司にあなたの懸念を持っていくことから始めましょう。繰り返しになりますが、それは有益な結果をもたらす可能性は低いです。

次のステップは、あなたが話していないことにかかっています。上司の頭の上を行くのは非常に危険かもしれません。そうであれば、本当にそこで働き続ける気があるのかどうかを見極める以外にできることはほとんどありません。上層部に気軽に相談できるような小さな会社であれば、行ってみてはいかがでしょうか。上層部がすでにその低レベルのソフトウェアマネージャが無能であると感じている可能性は十分にありますが、もちろん彼らはあなたにそれを言うつもりはありません。

もしあなたの第一の目的がこの混乱を解決することであり、あなた自身がこの場所で長く働いていると考えるならば、もう一つの遠い可能性として、内部ツールの開発の一部を自分で引き受けることを提案することがあります。そうすれば、最初のエンジニアと話し、物事がどのように動くのか、コードがどこにあるのかなどを理解する正当な理由が得られるはずです。最終的には、あなたがツール担当者となり、経営陣は最初のエンジニアを追い出すことができます。そうすれば、その役割のために誰かを雇ってもらうことができるので、あなたは自分のやりたいことに戻ることができます。繰り返しになりますが、これは私が本気で提案していることではありませんが、もしあなたが本当にやりたいと思っていて、やる気があるのであれば、選択肢の一つになるでしょう。