「影響範囲の考慮漏れ」によるソフトウェアトラブルの多発はビジネス継続性に対する危険信号｜mtx2s

リリースするたびに「影響範囲の考慮漏れ」によるトラブルを起こす。こういう症状は、既存のソフトウェアシステムに追加開発を繰り返す組織によく見られるのではないかと感じます。コードやシステムの変更が影響を及ぼす箇所を見逃してしまい、未修正な箇所が残されたまま本番リリースされたために発生するトラブルです。 このようなトラブルが頻発すれば、関係者らは不満を感じます。エンジニアたちの能力に不信感を抱くかもしれません。 しかし、不満の矛先をエンジニアに向けたところで問題が解決することはありません。そもそも原因を見誤っているからです。根本的な原因は、もっと奥深くにあります。 影響範囲の考慮漏れの多発は、ソフトウェアシステムが大きな問題を抱えていることを知らせるサインです。このサインを見逃して表面的な対策ばかりを続けていると、症状が良くなるどころか、かえって悪化し続けることになるでしょう。 問題/原因の3層

[turanukimaru]

所属してるチームが「指示されたこと以外はしないから外部への影響とか外部からの使い勝手とか確認しない！」という空気で絶望してる。このチームが提供してるツールを動かすのに一週間かけてまだ動かないんだけど…

[Sousui1125]

3層目の組織設計のひずみ起因は共感。リリース後は運用部門に技術担当が居ないとエスカレーションという名のたらい回しに遭遇しやすい。普段からメシでも食って仲良くしとこうな！

[toaruR]

業務フローの方をちょっと直せばエレガントになってコストもグッと下がるのにって事も多いよ＼(^o^)／なぜこんなに無駄に複雑なのか的な

[yujimi-daifuku-2222]

開発を外注する場合、今回これしか予算を確保できなかったのでこの機能だけお願いしますパターンが加わる。/断続的な開発ではコアメンバーの離脱やそれによるナレッジ継承の失敗などのリスクが増加する。

[gcyn]

コンピュータのソフトウェアプログラムだけの話じゃないですね。同じことがそれ以外の場面でもあるですね。

[fantatchi]

なんで動いてるんだ…的な魔改造コードよくみるもんなー。ほんとに疎なコードは芸術的だし読みやすい。

[JGEEM]

心当たりがありすぎて胸が痛い。その状況を指摘して、改善の道を示してもなお内部品質を無視して「今はスピードを優先して」とのたまうマネージャーとそれを容認する組織に何をか言わんや

[quick_past]

魂が凍る

[NOV1975]

仕様の考慮漏れとかはそんなにないんだけど、リリースタイミングでの特殊運用の考慮漏れが結構起きるんだよなあ。

[QURULI]

最近見積もりで悩んでるから必読

[rgfx]

ｳｯ

[chi-bd]

“このトラブルの原因をエンジニアの能力不足とみなしてしまうと、対策はおそらく1層目に対するもので止まってしまいます。それが意味するのは、ビジネスにおける競争力の喪失、つまりビジネスの死です。”

[asrog]

仕様変更で要件定義みたいなFプロジェクトだと、相応のコードになって、保守や機能追加もすごいことになる。

[PrivateIntMain]

弊プロジェクトは絶賛炎上中だが、自分は外注の立場なのと、後参入とはいえ摩訶不思議なコードベースを作った当事者でもあるので、何言っても通用しないからと粛々とこなすモードに入ってしまっていてよろしくない。

[izoc]

若手の頃金融系PJで死ぬほど厳しく根拠を求められたが他PJでは緩々で驚愕したのをふと思い出した。とにかく疎に作ることが大事よ。

[kuwayoshi]

ほんとこれ。

[emt0]

誰も全体を知らず知ろうとせずスキルもないから

[daishi_n]

自分一人で20kstepのコード書いて、継承クラスのインターフェイス実装のみ任せたことがあったけど、ほとんどバグは出なかった。ただしコードを他の社内でチームに譲ることができず、そのまま顧客が引き取った

[WildWideWeb]

むかし、深く考えもせず結果的に「ユニバーサル・フレンドリー」になっていて機能見直しの際に整理してしまった。(突然現れた)利用者からの声が辛かったけど「これを契機に」という対応力が自分にも組織にもなかった