社員が会社を人質にするのを止めるには？

この状況を改善するために何かできることはありますか？

何もありません、あなたはまだ数ヶ月しかそこにいません、それはあなたの役割ではありません、あなたにはそれについて愚痴を言う以外に何かをする力はありません。

賢い開発者を2、3人雇うんだ 彼らにすべてのコードを渡してください。彼らに、本当にすべてのコードを持っているかどうか、ソフトウェアを実行するために必要なすべてのものを確認させてください。彼らにコードが何をするかを学習させ、文書化し、リファクタリングし、A氏よりも早く問題を解決できるようになります。

私が思うに、Aさんの開発方法では、彼のコードの作業量は、通常7年間の開発で得られる作業量よりもはるかに少なく、コードは難読化されていますが、実際には難しくはないので、新しい開発者の仕事はとても楽になります。いくつかのコメントの関係で、改めて強調しておきたいことがあります。問題はお金だけではありません。問題は、Aがソフトウェアを改善することではなく、開発を困難にすることに焦点を当てているため、ソフトウェアが開発されている可能性がはるかに低いことです。

短い回答:あなたの組織は現在、バスファクターの重大な危険にさらされています。それは大きなリスクです。この人が辞めることにした場合、あるいは文字通りバスに轢かれた場合はどうなるでしょうか？あなたがそれを概説するように状況がある場合は、その後、全体の会社がなくなっています。このことを人事の問題ではなく、組織のリスクとして上司に報告する必要があります。

A氏がいてもいなくても、他の人をコードに参加させてください。もし彼が本当にバスに轢かれてしまっても、あなた方全員が前に進めないということにならないように、彼の力を奪ってください。

他の回答は非常に素晴らしいですが、私の個人的なアドバイスとしては、他の職場を探すことを検討してみてはいかがでしょうか。私には、これは会社の他の種類の問題の警告のサインとして読み取ることができます。

そして彼は、ソフトウェア製品を不安定にし、メンテナンスやトラブルシューティングが困難な状態に保つために、意図的に間違った決定をしていることを繰り返しています

では、なぜあなたのチームはこれらの “間違った決定 "をデザインレビューやコードレビューを通過させているのでしょうか? もしコードレビュープロセスやデザインレビュープロセスを持っていないのであれば、長い目で見てそのことを主張してください。そして、彼は、ボーズに対処するための特定の呼びかけを持っています。FILE BUGS. ある時点で、これらの天才の1人が2週間かけて、信じられないほど悪いコードを書いて、それが決して動作することはできません。あなたは、そのコードをゼロから正しく書き直すために必要な15分を費やしたいと思うでしょう。その誘惑に抵抗してください。あなたは数ヶ月間、このバカを無力化する絶好の機会を手に入れたのです。彼らのコードに対してバグを報告し続けてください。あなたがこれ以上のバグを見つけられなくなるまで、彼らは何ヶ月もそれに取り組んでいくしかないでしょう。それは、彼らが他のどこにもダメージを与えることができない数ヶ月間なのです。

ただ、今の回答よりもわかりやすく言うと…

あなたの問題 :

誰も直し方を知らなかった

あなたの解決策 :

• 自分で直す方法を学ぼう

そこに、今の会社はもう相手を必要としていません。

これを壁に貼ってください。(一部、名前や場所を変更する必要があります)

何年か前、アメリカ中西部の製造業の会社で一週間、社内でプログラム設計の講座をしたことがあります。金曜日の午後にはすべてが終わっていました。そのコースを手配し、予算から費用を出していたDPマネージャーが、私をオフィスに招き入れた。"What do you think? “と彼は尋ねた。彼は私に、彼のオペレーションと彼のスタッフについての私の印象を教えてくれと頼んでいた。"「とてもいい」と私は言った "「いい人たちがいるんだね」と言った プログラムデザイン講座は大変だし、疲れたし、スタッフ評価のコンサルティングは別料金だし。とにかく、彼は本当に自分の考えを私に伝えたいのだと思いました。と聞かれました。"彼はとても賢い "と私は言った。"メソッドにはあまり熱心ではないが プログラミングには詳しい” “はい」とDPマネージャーは言った。彼は椅子に座ったまま回転して、壁に貼り付けられた巨大なフローチャートに向き合った。"フレッドがやったんだ。これは毎週の給与計算のための総支給額の積み上げだ。フレッド以外には誰も理解していない” 彼の声は恭順な沈黙に落ちた。"フレッドが言うには、彼自身が理解しているかどうかわからないとのことです"

“素晴らしい、と私は尊敬の念を込めて呟いた。私ははっきりと絵を手に入れた。フランケンシュタイン役のフレッド、制御不能な怪物のフローチャートを作った才人フレッド。"でも、ジェーンは？” 私は言った “ジェーンは非常に優秀だと思いました。彼女はプログラム設計のアイデアを非常に速く拾ってくれました。”

“はい。"とDPマネージャーは言いました。"ジェーンは素晴らしい評判で私たちのところに来てくれました。私たちは彼女がフレッドのように優秀になると思っていました。しかし、彼女はまだ自分自身を証明していません。私たちは彼女に、本当に難しいと思っていた問題をいくつか与えましたが、彼女が解いてみると、それは全く難しくないことがわかりました。ほとんどの問題は簡単なものでした。彼女は本当にまだ自分自身を証明していない — あなたは私が何を意味するかを見るならば？”

“私は彼が意味するものを見た。”

• 本のソフトウェア要件＆仕様書からの抜粋 - ミッシェル・ジャクソン（よく読む価値がある）。

答えは簡単です。彼が作った混乱を修正するために、短期的には、他にはない金額のお金を支払わなければならないかもしれませんが、A氏は世界中の誰よりも賢くはありません - 短期的には誰かがソフトウェアをメンテナンスし、長期的にはより良いものにしてくれるでしょう。

考慮すべき視点があります。

私たちは開発者として、良いコードを書くのが私たちの仕事ではないということを忘れがちです。私たちの仕事は、製品を完成させることです。良いコードを書くことは、そのプロセスをより良いものにしてくれますが、全くのくだらないコードでも、素晴らしい製品を作ることができるのです。彼らは彼と彼のやり方を「気に入っている」のです。あなたがどうにかして彼をクビにしたとしても、これを変えることはできないでしょう。何が起こる可能性が高いのは、彼らが “男 "になるために新しい人を選ぶと、プロセスはすべての最初からやり直しです。会社は彼らの選択をしました。あなたはあなたのものを作る必要があります。男（彼は彼が右の何かをしている必要があります7年間同じ仕事を保持している）または移動から学ぶ。

良くも悪くも、nothingも誰もがかけがえのない存在ではありません。(何人かは他の人よりも多いかもしれませんが、それでも) 人々が解決策を知っていれば、それをリバースエンジニアリングすることができます。私も過去に何度かあなたの靴を履いたことがあります。あなたと似たような状況では、"Mr.A “はとっくにいなくなっていましたが、私はケーブル会社のバックエンドで働いているモノリシックソリューションを持っていました。私は次に行く前に各モジュールを完成させた。数ヶ月後には前者のアプリケーションを殺していました。

掛け替えのないものであることは大げさです。

ビジネスの観点からは、基本的に2つの解決策があります。1.段階的に移行する、つまり、機能の一部を取り出して、それを高水準に再実装して本番に投入し、古いシステムが完全に廃止されるまで、この作業を少しずつ続けていく。新しいシステムを完全に構築してから、一度に、あるいは徐々に移行する。

オプション1の利点は、多額の先行投資を必要としないこと、新しいコードが一気にではなく徐々にテストされていくこと、そして早期に効果を実感できることです。

ただし、デメリットとしては、新システムの構造が旧システムの構造の影響を強く受ける可能性があり、非常にごちゃごちゃしたシステムのパーツを入れ替えるのが本当に難しいケースもあります。時には、少しの創造性が必要になることもあります-他のすべてが失敗した場合、新しいコードは、古いシステム上でキーを押したりボタンをクリックしたりするのをシミュレートすることができます! しかし、古いシステムとのインターフェイスは、オプション2で行く方が良いほど多くの作業を発生させるかもしれません。問題は、それはどのくらいの費用がかかり、どのくらいの節約になるのでしょうか？上記の各オプションのためにそれを推定しようとすると、どのオプションを選択するかを決定するのに役立ちます（もしあれば）。それは、機能要件、既存のシステムの構造、そして将来の節約のために前もってお金を使う/クレジットを使うというビジネスの意欲に依存します。

ソフトウェアチームのメンバーとして、あなたの仕事は会社とその従業員を管理することではありません。

あなたはソフトウェアの問題を見て、あなたの質問から、それはあなたが問題を修正するためのいくつかのアイデアを持っているように聞こえます。あなたのマネージャーにこれらのアイデアを持ってきて、それらのために戦ってください。

「マネージャー、このソフトウェアはテストされておらず、現在の実装はテスト可能ではありません。私は、よりテストしやすい言語で再実装することを提案します。"

今、それは非常に可能性が高いです:

A. これは大きな事業であり、会社は必要性を感じていないため、投資する気がない

B. A氏はこのようなものに反対するでしょうし、彼はより年上であるため、聞く耳を持つでしょう

もしそうなった場合、あなたは仕事をうまくやろうとしたのに、息が詰まる思いをしました。新しい仕事を探す時間です。

これがうまくいって、彼らがあなたの話を聞いてくれたら、あなたは仕事のトンのためにサインアップしたことになります。

意図的に現代のソフトウェア開発フレームワークから遠ざかっていた

彼は自分が一番よく知っているものが一番快適なのかもしれませんね？

私は大企業で働いていましたが、そのパイプラインは古いコードと新しいコードのパッチワークで、ある特定のコードの部分は “ただ動いていた "だけで、決して触れられていませんでした。その上、それを書いていたプログラマーはとっくにいなくなっていて、誰もそれがどのように動くのか理解していなかったので、要求の変化に対応するために新しい機能を追加しただけでした。また、彼らのパイプラインは常に稼働していたので、どのような大きなロールアウトも悲惨な結果を招く可能性がありました。もし適切なドキュメントがない場合は、(あなたが資格を持っていて時間があることを知っているなら)ドキュメントを作成することを提案するか、作業をスピードアップするためのドキュメントを作成すべきかどうかを尋ねてみてください。

残念ながら会社の構造上、突然の変化には抵抗がありますし、近代化は抵抗を少しずつすり減らしていくか、あるいは少しずつ実装していくことになります。

たとえ彼が仕事を維持するために悪意を持ってこれをやっていたとしても、直属の上司がそれを知らされている場合は特にですが、それを吹き飛ばすことがあなたの責任であるとは思えません

あなたならどうしますか？

あなたのマネージャーが問題を追求しないことを決めたように、彼はおそらくあなたの有無にかかわらず、彼の上司に話をしたくないでしょうし、彼はすでに行っていて、そこに封鎖されています。

あなたが彼なしで彼の上司に話をする場合、あなたは彼を疎外するリスクがあります。

これを修正する唯一の方法は、Aさんのコントロールを奪うことです。

まず、管理者の承認を得ることです。そこからスタートしてコードを前に持っていく

1. Mr.A.に全くアクセスを与えない(存在を伝えない)

2. Aさんの変更を自分のレポに移植するか、書き換える。

5.Aさんのレポは、あなたが使うことはないので、Aさんの好きなようにさせる。彼からあなたの新しいレポを隠すために必要であれば、それがアクティブに見えるように偽のコード変更を行います。

7.最終的にコードは彼が自動的に陳腐化するのに十分なほど発散されます。モジュールは必ずしも悪いそれらではありませんが、あなたはそれらをsync'edと作業順序で維持する必要があります。

これは、既存のコードの多くを書き換えなければならないように多くの仕事になるだろう。

追加の利点は、コードは最終的に彼がもはやその彼のコードを主張することができないことを十分に遠く発散されます。それは彼にとって完全に外国のものになります。

また、「We want problem XY solved」を「…because of problem XY」と盲目的に解釈してはいけません。会社の政治では、"個人的な議題を持たない無邪気なイノベーター、我々は意図しない結果の責任を保持することはできません “のようなものはありません。

あなたがそれを行う場合は、個人的な議題を持つ_でそれを行い、どちらの方法で結果を所有しています。

@MightyPizza - 時間の無駄だ。明るくてより良い未来を持っている別の会社で働きなさい。この会社があなたの最後の砦であるならば、あなたはこの問題の解決にこれだけのエネルギーを費やすべきです。

これはあなたが得ようとしている絶対的なベストアンサーです。ジャンプのために自分自身を準備してください。

「ソフトウェアをモダンで保守可能で安定したものにしたい」

これを行うための最良の方法は、初日に、コードの最初の行であり、誰かの熱いゴミの山ではありません。

彼がその地位に長くとどまっているのは、企業が意識的に、あるいは無意識的に「ハンロンのカミソリ」を使っていることを示しています。実際には、A氏は、人々が物事を変更しようとし、彼らが間違ってしまったときに英雄的にそれらを修正させているように見えます。

また、A氏は、彼がやっていることが間違っていることを見ることができないという点で、ダニング・クルーガー効果に苦しんでいるかもしれないことを考慮する必要があります。誰にもわからない。あなたが第一原則として受け止めなければならないのは、彼がどれだけ鬱陶しくても、彼が悪意のある工作員ではないかのように対処しなければならないということです。

あなたの質問は、彼がジョブセキュリティの後にいるだけで、これを埋め込むために物事を更新することを拒否しているという前提を取っているように見えますが、彼が悪意のある工作員であるかどうかはわかりません。あなたは正しいかもしれませんが、これを前提にして彼に対処することはできません。

あなたの聡明なアイデアの中には、"一度試してみたが、Xのためにうまくいかなかった “という抵抗感を持っている人もいると思います。ビジネスの観点から、これは理にかなっている、彼らはリスクを取った何かが動作しませんでしたので、なぜ彼らは再びそれを試してみる必要があります。

あなたの目標として状態。モダン**

モダンには暗黙のビジネス価値はありません。それはいずれにしても議論の余地がある。あなたはJava 8と言い、他の人はRustやGolagが現代的だと言うでしょう。システムがサポートされている限り、それを更新することに大きな価値はありません。Maintainable**

これも議論が難しいかもしれません。Aさんはメンテナンスをしているからメンテナンス可能だと反論するでしょう。枠組みの大規模な変更を正当化するためには、維持費が大幅に下がることを主張しなければならないでしょう。Stable**

あなたはシステムをHA化したいと言っていますが、あなたはまた、それが

ソフトウェアがイベントを監視し、それらにいくつかの処理を行い、その後、適切なアクションを取ると言っています。

*So what to do? *

あなたのシステムは、

によって定義された 泥の大きなボール のように聞こえます > 泥の大きなボールは、行き当たりばったりの構造化された、ずさんで、ずさんな、ダクトテープとバリ取り線、スパゲッティコードのジャングルです。これらのシステムは、規制されていない成長の紛れもない兆候を示しています。

これを管理する非協力的な開発者と、これに正面から取り組むことは、非常にイライラさせ、おそらく実りのないことでしょう。それは多くの他の人が試してみて失敗したように聞こえます。

あなたができることは、それを回避するために開始されます：

• あなたはシステムのHAを作ることができない場合は、メッセージバスシステムを使用するか、またはそのような方法でメッセージをキャプチャするようなシステムがダウンした場合、あなたはデータを失うことはありません。これらはきちんとしたものではありませんが、システム上で行われるテストを可能にします
• 次回、いくつかのアクションが必要なときは、メッセージバスを聞いて、それ自身のアクションを実行することができます独立したサブシステムにそれを構築するために開始します。
• いくつかの下流の効果に影響を与え始めることができる場合(例えば、取られたアクションをカプセル化するなど)、これらをサブシステムに入れてください。あなたの場合、システムはよく設計されたモノリスとしては問題ないかもしれませんが、よく設計されていない場合は、物事を分割する必要があります。 この は、あなたを始めるのに良い記事のように見えます:

より一般的なアプローチは、モノリスから始めて、徐々にエッジでマイクロサービスをはがすことです。このようなアプローチは、マイクロサービスアーキテクチャの中心に実質的なモノリスを残すことができますが、モノリスが比較的静かである間、ほとんどの新しい開発はマイクロサービスで発生しています。

しかし、それは氏と一緒に再生することが重要ですが、あなたがシステムを置き換えているが、あなたは "信頼性を向上させる "または冗長性を追加していることを彼に言わないでください。彼がしたことを攻撃すれば彼はあなたの目標を達成するためにあなたのためにそれをより困難にします。それは事実ですが、長期的に前進するためには必要なことです。

なんでみんなそんなにAさんをクビにしたがるの？彼は何も悪いことはしていないと思います。ソフトウェア開発とは、かっこいいツールやフレームワークを使って新しいものを作ることではありません。ただ「動く」だけの安定したものを作ることです。あなたの会社はAさんが大好きで、Aさんの仕事に満足しています。

わざと現代のソフトウェア開発のフレームワークから遠ざかっている

あなたのシステムは現在安定した状態にあるのに、なぜチームはスクラムやアジャイルのような現代のソフトウェア開発のフレームワークを使う必要があるのでしょうか？

コアビジネスロジックをテストできない言語で書いている

コアビジネスロジックは自動的にテストされなければならないという要件があるのでしょうか？

ソフトウェアコンポーネントを30モジュールに再設計し、複雑さとバージョン認証の問題を追加する

この実装はあなたの会社にどれだけ多くのコストがかかりましたか？

HA（高可用性）機能がないことを確認し、スケーラブルではない方法でそれを設計しました

まだ同じ質問 - この実装はあなたの会社にどれだけ多くのコストがかかりましたか？

私の意見では、あなたがここに書き留めているすべてのことは、彼に対するあなたの不満に過ぎません。彼が多くの「ひどい」ことをした場合、システム自体が最初の1年でメルトダウンしているだろうし、彼はあなたの会社でその長い間滞在していたことができませんでした。

簡単に言えば、ソフトウェアの現状と文書化されていない知識を文書化するために、企業は彼に多額の昇給を提示しなければならず、その後、彼を解雇します。あるいは、技術コンサルティング会社を雇ってすべてを文書化し、壁に書かれていることを理解した上で彼を解雇するという方法もあります。