ソフトウェア開発に適用される戦争の芸術
公開: 2022-03-11ソフトウェア業界で働いている場合、分割統治法の設計パラダイムについて聞いたことがあると思います。これは、基本的に、問題を2つ以上のサブ問題に再帰的に分割すること（ divide ）で構成され、これらが直接解決できるほど単純になるまで続きます。 （征服）。
あなたが知らないかもしれないことは、このパラダイムが古い政治戦略（名前は分割統治と言っているラテン語に由来する）に由来しているということです。
この戦略は、ジュリアスシーザー（ガリア戦記で軍事的に強力なガリア人を打ち負かすために使用した）やナポレオン（フランスの大砲の専門家が敵軍を分割するため、どの部分も強力ではなかった）など、歴史を通じて無数の政治家や軍事指導者によって使用されてきました彼自身の軍隊よりも、そして彼らのコミュニケーションを妨害し、攻撃を調整して実行する敵の努力を妨げます）。
孫子：開発に適用される古代の原則
ただし、分割統治法は、ソフトウェア開発に適用できる唯一の政治戦略ではありません。 政治や戦争はソフトウェア開発とはほとんど関係がありませんが、政治家や将軍と同じように、開発者は部下を率い、チーム間の取り組みを調整し、問題を解決するための最良の戦略を見つけ、リソースを管理する必要があります。
孫子は紀元前5世紀に書かれた古代の軍事論文であり、その理論が東洋と西洋の両方の哲学に大きな影響を与えた古代中国の軍事戦略家である孫子に帰属します。
その年齢にもかかわらず、テキストは東アジアの多くの軍学校のシラバスにまだ含まれており、西部のいくつかの軍学校で推奨される読み物としてリストされています。 テキストは13の章に分かれており、それぞれが戦争のさまざまな側面に専念しています。
しかし、戦争に加えて、孫子の原則と教えは、政治、ビジネス、スポーツ、そして信じられないかもしれませんが、ソフトウェア開発に実用的なアプリケーションを持っています。 実際、あなたはそれらの起源さえ知らずに、あなたの日常生活の中でこれらの原則のいくつかを単に適用しているかもしれません。
以下に詳細を示します。ArtofWarで説明されている基本的な戦術とヒントの簡単なリストがあります。 それらはおそらくソフトウェア業界や他の多くの業界でのあなたの仕事に適用することができます。
どのキャンペーンでも時間が重要です
チャプターII、パラグラフ2
あなたが実際の戦闘に従事するとき、勝利が来るのが長いと、男性の武器は鈍くなり、彼らの熱意は弱まります。
この原則は、開発サイクルの長さと開発者の士気との関係を説明するルールとして、ソフトウェア開発に適用できます。
開発者のグループが同じプロジェクトに何ヶ月も取り組んでいて、明確な目標がないか、終わりが見えない場合、彼らは欲求不満になり、生産性が低下する可能性があります。
ソフトウェア開発は知的努力であるため、モチベーションが生産性の主な燃料です。 あなたの仕事が実際の結果を生み出していることに気付かずに毎日働くことは、非常に意欲をそそる可能性があります。
いくつかのアジャイル手法で示されているように、開発ロードマップはいくつかの目標とマイルストーンに分割する必要があります。これらはチームが短期間で達成できる可能性があり、進歩と達成感をチームに与えることになります。
第II章、パラグラフ18
戦争では、それなら、あなたの大きな目的を、長いキャンペーンではなく、勝利にしましょう。
このフレーズは、次の2つの方法で解釈できます。
まず、これはUNIX哲学の先駆けと見なすことができます。1つのことを実行し、それをうまく実行するプログラムを作成することです。 ソフトウェアを開発するときは、プログラムの主な目的、プログラムが提供する主要な機能、またはプログラムが解決する最大の問題を常に念頭に置き、適切な実装を確保する必要があります。
インスピレーションを得て、追加する本当にクールな機能を思いつくことがありますが、使用頻度の低い機能がたくさんあるアプリケーションには、軽蔑的な名前が付いていることを忘れないでください： bloatware 。
第2に、このステートメントは、リーンソフトウェア開発の原則の1つである「できるだけ早く提供する」の前兆と見なすこともできます。
大きな欠陥のないソフトウェアを提供するのが早ければ早いほど、クライアントからのフィードバックが早く得られ、変更を次のイテレーションに組み込むことができます。
一方、機能しないソフトウェアを提供する場合、クライアントはそれを適切にテストする機会がないため、貴重なフィードバックを見逃すことになります。 これにより、開発の次の段階がより困難になるか、次のイテレーションが顧客のフィードバックに依存する状況では不可能になります。
リーダーシップなし、結果なし
チャプターIII、パラグラフ11
現在、将軍は国家の防波堤です。 防波堤がすべてのポイントで完了した場合、国家は強力になります。 防波堤に欠陥がある場合、状態は弱くなります。
この引用は、開発チームにおけるマネージャーの役割の重要性を説明しています。プロジェクトの成功は、関係するすべての人々の力に依存し、マネージャーはプロジェクトの防波堤です。 責任はトップから始まります。
開発者は頻繁に一人で作業しますが（それぞれがコンピューターの後ろに座って、同僚とのコミュニケーションが制限されています）、それは彼らが優れたリーダーシップを必要としないという意味ではありません。 プロジェクトマネージャーは、チームを軌道に乗せ、効果的なコミュニケーションと紛争解決を確保する責任があり、リーダーは明らかに、プロジェクトの優先順位を（他のタスクの中でも）定義するため、彼らの役割を過小評価してはなりません。 何かがうまくいかない場合の彼らの責任もすべきではありません。 部隊が戦闘の分野でその任務を遂行できなかった軍事指導者がどうなるか想像してみてください。
チームは、開発ポジションにいくつかの悪いリンゴがあったとしても、優れたソフトウェアを作成できますが、プロジェクトマネージャーが悪いリンゴである場合、チームにロックスター開発者がいくつあっても、それは起こりそうにありません。
第VI章、段落28
あなたに1つの勝利をもたらした戦術を繰り返さないでください、しかしあなたの方法が無限の多様な状況によって規制されるようにしてください。
プロジェクトを開始するときに、以前に成功したプロジェクトで使用したのと同じテクノロジのセット（同じプログラミング言語、同じライブラリ、同じサーバーなど）を使用したくなることがあります。 ただし、新しいプロジェクトの要件が以前のプロジェクトとまったく同じでない限り、これは間違ったアプローチである可能性があります。
プログラミングでは、ほとんどのドメインと同様に、万能薬（すべての病気を治すことができると思われる治療法）は存在しません。 すべての問題を解決するために使用できるテクノロジーの単一の組み合わせはありません。 それぞれのテクノロジーには長所と短所があります。
もちろん、新しいプログラミング言語を学んだり、未知のAPIを使用したりすることは、最初は費用がかかるかもしれませんが、長期的には、ソフトウェアの品質が優れており、より優れた開発者になります。
第XIII章、段落27
したがって、スパイの目的で軍の最高の知性を使用するのは、悟りを開いた支配者と賢明な将軍だけであり、それによって彼らは素晴らしい結果を達成します。 スパイは戦争で最も重要な要素です。スパイは軍の移動能力に依存しているからです。
このフレーズは、メンテナンス段階で監視ツールとロギングライブラリを使用することの重要性として解釈される場合があります。
クライアントがそう思わないこともありますが、安定した完全にテストされたリリースを入手しても開発は終了しません。 ソフトウェアは、バグの修正、新機能の追加、または効率の向上のいずれかによって、常に進化しています。
また、本番環境でソフトウェアを監視し、最も使用されている機能、最も一般的なエラー、および最も長い操作をスパイに確認することほど、どのような変更を加えるかを知るための優れた情報源はありません。
制御されたテスト環境で同じ状態を再現できるとは限らないため、エラーレポート、ログエントリ、および使用状況データは、バグの検出、ボトルネックの特定、およびその他の問題の基本です。
チームワークとモチベーション
チャプターX、パラグラフ24
名声を求めずに前進する者、非難を逃れることなく後退する者、民を守り主に仕えることを目的とする者、その男は王国の宝石である。
基本的に、これは「チームに私はいない」の古代中国語版です。 個人的な利益を追求するよりも、他の人と協力することがより重要です。
ソフトウェア開発は、開発者がチームとして効果的に作業する必要がある複雑なアクティビティです。 優れた開発者は、ほとんどのバグを修正したり、ほとんどの機能を実装したり、予定より早く割り当てを完了したりする開発者ではありません。 優れた開発者とは、チームが目標を達成するのを支援する開発者です。
自分のしたことすべてに信用を主張したり、自分の過ちを認識したり他人を責めたりしない、あるいは自分自身をコード忍者と呼ぶことは、経験の浅いマネージャーをだまし、昇給させることさえありますが、あなたはチームの逆効果のメンバーになります。
第7章、段落21
行動を起こす前に、よく考えて熟考してください。
このフレーズは、アジャイル手法によって提案されたようなチーム開発会議の重要性を示しています。
チームで作業するときは、実装する前に大きな変更について話し合うことが重要です。 あなたがチームリーダーであるかどうか、またはあなたが主題の最も経験のある人であるかどうかは関係ありません、あなたは常にチームの他の人と話すか、少なくとも知らせるべきです。
他の開発者が、ソフトウェアのなじみのない部分についての洞察を与える可能性があることを忘れないでください。 これは、変更の影響を完全に認識できるため、予想よりも早く変更の実装を開始できることを意味します。
チャプターX、パラグラフ25
あなたの兵士をあなたの子供と見なしてください。そうすれば、彼らはあなたを最も深い谷へと追いかけます。 彼らをあなた自身の愛する息子として見なさい、そうすれば彼らは死ぬまであなたのそばに立つでしょう。
この引用は、マネージャーやチームリーダーによって忘れられることがある管理の原則であるモチベーションの重要性を示しています。 やる気のある開発者は、より良いコードを書き、より速く作業し、より少ないエラーをコミットし、より多くの時間を費やすことをいとわないでしょう。
マネージャーは、部下に真の関心を持ち、耳を傾け、仕事と生活のバランスを大切にし、前向きな職場環境を構築し、キャリアパスを大切にすることで、モチベーションを高める必要があります。
また、モチベーションを報酬と間違えないでください。 最近の研究によると、お金はほとんどの労働者をやる気にさせません。お金はほとんどの場合、従業員を引き付けて維持するのに役立ちますが、彼らの仕事に満足させることはできません。 したがって、昇給や昇進は動機付けのツールと見なされるべきではありません。
箱の外で考える
第V章、段落7、8、および9
音符は5つ以下ですが、これら5つの組み合わせにより、これまでにないほど多くのメロディーが生まれます。
原色は5つ以下ですが、組み合わせることで、これまでにないほど多くの色相を生み出します。
カーディナルテイストは5つ以下ですが、それらを組み合わせることで、これまでに味わったことのないほど多くのフレーバーが得られます。
プログラミングの良いところの1つは、可能性が無限にあることです。 基本的に、必要な場所で開発できます（少なくとも、NP完全問題でない限り）。
モバイルアプリ、ウェブサイト、ゲーム、デスクトップアプリケーション…プログラミングを知っていれば、それらすべてが手の届くところにあります。
第III章、段落1
戦争の実際の芸術において、すべての最も良いことは敵の国を完全に無傷にすることです。 粉砕して破壊するのはあまり良くありません。 ですから、軍隊を破壊するよりも軍隊全体を捕獲する方が、連隊、分遣隊、または会社全体を破壊するよりも、軍隊全体を捕獲する方が良いのです。
大規模なコードベースを持つプロジェクトで作業する場合、不適切な方法で、または非推奨のライブラリを使用して実装されたモジュールまたはコードのセクションを見つけるのが一般的です。 このコードを消去（または破棄）したくなるかもしれませんが、いくつかの理由で最善のアイデアではない可能性があります。
レガシーコードは必ずしも悪いものではありません。他の方法論やテクノロジーが進むべき道と考えられたときに書かれた良いコードである場合もあります。 ただし、古いからといって機能していないわけではありません。
コードの他のより重要な部分の修正に集中する代わりに、まだ機能しているコードを修正する時間を失う可能性があります。
自分が何をしているのか本当に確信が持てない限り、機能するコードのセクションを置き換えることは、新しいエラーやバグを導入するリスクがあることを意味します。
これは、 「壊れていない場合は修正しない」というフレーズが優れた戦略であることを意味するのではなく、すべてのプロジェクトに優先順位、目標、および時間の制約があることを意味します。 したがって、改善できるコードを見つけた場合は、それをチームの他のメンバーまたはプロジェクトマネージャーと話し合って、いつ最適化するかを判断してください。
第VIII章、パラグラフ3
従わない道、攻撃されてはならない軍隊、包囲されてはならない町、争われてはならない地位、従われてはならない主権者の命令があります。
直接言っていなくても、この原則をアンチパターンを回避するための警告と解釈することができます。
アンチパターンを使用すると短期的な問題は解決する可能性がありますが、長期的には逆効果になることを覚えておく必要があります。 したがって、どれだけ時間を節約しても、修正するバグの数や、それがどれほど便利であっても、それらを避けてください。
それでも、緊急のタスクを解決するためにアンチパターンを使用したくなる場合があります。時間があれば適切な修正を実装することを約束しますが、マーフィーの法則の1つを覚えておいてください。すべての迅速な修正は永続的な変更になります。
結論
ソフトウェアの開発は、戦争中の兵士の指揮や国の指導とは異なりますが、チームワーク、優れたリーダーシップ、効率性、長期的な解決策を必要とする問題を解決する必要があります。
ただし、ソフトウェア開発に適用できる原則が含まれている本は、 ArtofWarだけではありません。 ニッコロ・マキャヴェッリの『君主論』はその一例です。
実際、ここにまだ関連しているマキャヴェリからの引用のリストがあります。 ソフトウェア開発の世界で対応する原則がどれであるかを推測してみてください。
- ライオンは罠から身を守ることができず、キツネはオオカミから身を守ることができません。 したがって、罠を認識するのはキツネであり、オオカミを怖がらせるのはライオンでなければなりません。
- 欺瞞によって勝つことができるものを無理やり勝ち取ろうとしないでください。
- 危険なしに素晴らしいことは決して達成されませんでした。
- 絶え間ない成功を望む人は誰でも、時代とともに行動を変えなければなりません。
- 男性は一般的に、現実よりも外見から判断します。 すべての男性は目を持っていますが、浸透の才能を持っている人はほとんどいません。
- 従うことを望む人は、命令する方法を知らなければなりません。
- 知恵は、問題の性質を区別する方法を知ることと、より小さな悪を選ぶことから成ります。
- 戦争を回避することはできません。 それはあなたの敵の利益のためにのみ延期することができます。
- 自然は勇敢な男性をほとんど生み出しません。 産業と訓練は多くを作ります。