リチャードハミング：第28章システムエンジニアリング

システムエンジニアリングの最初のルール：「コンポーネントを最適化すると、ほとんどの場合、システムのパフォーマンスが損なわれます。」

こんにちは、Habr。 「You and Your Work」という素晴らしい記事（+219、2146のブックマーク、339kの読み取り）を覚えていますか？



そのため、ハミング（はい、はい、自己チェックと自己修正のハミングコード ）には、彼の講義に基づいて書かれた本があります。 男性がビジネスを話しているので、それを翻訳しましょう。



この本はITだけでなく、信じられないほどクールな人の思考スタイルに関する本です。 「これは単なる肯定的な思考の責任ではありません。 素晴らしい仕事をする可能性を高める条件を説明しています。」



すでに4つの章を翻訳しています。

第28章システム工学

（翻訳のおかげで、ジュリアペルーノフスカヤ、「前の章」で私の電話に答えてくれました。）翻訳を手伝いたい人は-個人のメールまたはmagisterludi2016@yandex.ruに書いてください。



all話は多くの場合、直接的な陳述よりも効果的であるため、par話から始めましょう。 男は大聖堂が建設されているのを見ました。 彼は煉瓦職人になぜ石を砕くのか尋ねたところ、煉瓦職人は「石を作る」と答えた。 彼は石彫師に何をしていたのかと尋ねた。「ガーゴイルを彫っています」。 そして彼は皆に尋ねました、そして、誰もが彼らが何をしていたかを詳細に話しました。 最後に、彼は領土を掃除している老婦人に行きました。 彼女は、「私は大聖堂の建設を手伝います」と言いました。



通常のキャンパスで、次の学術時間に何をしようとしているのかについて教授のサンプルをインタビューすることにした場合、「最も単純な部分を教える」、「正規分布の瞬間を見つける方法を示す」、「モジュールを説明する」弾性とその測定」など 教授から「学生を教育し、将来のキャリアに備える」というフレーズを頻繁に聞くことになるとは思いません。



どちらの場合でも、教育とトレーニングは大きな目標であるため、言及する必要がないことは明らかです。 しかし、あなた自身がそれを本当に信じているとは思いません。 ほとんどの場合、各人は全体の1つの特定の部分の詳細に没頭しており、自分の行動が全体像にどのように影響するかについては考えません。 このようなビジョンは、ほとんどの人の特徴です。 彼らは自分の仕事で狭い見方を示し、システムのより一般的な目標とそれを関連付けることはめったにありません。 それにもかかわらず、外部からの圧力の下で、彼らはシステムの真の目標がまさにこれらの共通の目標であることを認める用意ができています。 このような狭い視野は、官僚の主な特徴です。



トップに登るには、少なくともすでにそこにいるときは、より広い視野を持つ必要があります。 システムエンジニアリングは、主な目標を常に念頭に置いて、各ローカルアクションが実行される理由と全体的な結果にどのように影響するかを理解する試みです。 ただし、特定の大きな画像はありません。 たとえば、最初に自分のコンピューターを手に入れたとき、主な目標はできるだけ多くの算術演算に毎日使用することだと思いました。 主なアイデアが計算された情報の量ではなく、計算の重要性であることに気付くまでに少し時間がかかりました。 後に、私は、最も重要な計算は、私が所属する数学部ではなく、研究ユニットのために行われたことに気付きました。 当然、私はすぐに、科学者自身が直接作業するときに新しいマシンから最大の価値を引き出すことができることに気付きました。 そうすれば、彼らは自分の仕事で使用できるコンピューターの価値を完全に理解し、実際の計算数を減らしながら、同時にBell Telephone Laboratoriesの価値を高めることができました。 しかし、後になって、研究部門のニーズだけでなく、研究所のすべてのニーズにも注意を払う必要があることに気付きました。 それからAT＆T、AT＆Tの外の国、科学および工学コミュニティ、そして最終的には全世界でした。 したがって、私は自分自身、私の部門、部門、会社、親会社、国、科学者とエンジニアの世界、そして地球のすべての住民に対して義務を負っていました。 明確に定義された境界線はありませんでした;いつでも自分で境界線を引き、中に入っていないものはすべて無視できました。



それぞれの場合の義務は、（1）直接拠出、（2）長期拠出、（3）非常に長期の拠出でした。 また、ポイント（2）および（3）の下で、研究部門での私の役割の1つは、既存の問題を解決することではなく、問題を解決するための方法を開発し、可能性の範囲を広げ、他の人に見つけられることを教えることであることに気づきました私の努力の結果をさらに適用し、継続し、改善します。



システム工学で正しい言葉を言うのは非常に簡単であり、このトピックで質問されたときに多くの人々がそれらを話すことを学んだが、テニス、ゴルフ、水泳などの多くのスポーツのように、一般的に必要なことをすることは難しい。 したがって、システムエンジニアは、彼らが言うことではなく、最終的に実行および生成されるため、判断されるべきです。 良いゲームについて話す人はたくさんいますが、実際には彼らはそれをすることができません。

システムエンジニアリングの最初のルール

コンポーネントを最適化すると、ほとんどの場合、システムのパフォーマンスが損なわれます。

これは理解するのが非常に難しい瞬間です。 通常、個々のコンポーネントが改善されるとシステム全体が改善されることは非常に合理的ですが、これは事実ではありません。 システムのパフォーマンスが低下する可能性が高くなります。 簡単な例として、私は差動アナライザーを使用し、重要な問題を解決することに成功し、さらに2つのアナライザーを購入する必要が生じました。 2つ目を現在の1つに接続するために注文しました。これにより、互いに別々に、または共同で計算を行うことができます。 彼らは2番目のモデルを構築し、それを改善したかったのですが、それはマシン全体の動作を妨げないという条件で同意しました。 車を解体し、私たちの場所に運ぶ前に、検査の日が来ました。 私はそれをテストし始めましたが、私の友人はしぶしぶ助けてくれました。 マシンは最初のテストに失敗しました！ このテストは、微分方程式の古典的な解決策でした。







解決策は、もちろん、y =コストです。 次に、グラフy（t）およびy´（t）を描画すると、円が表示されます。 正確さの尺度は、彼がサイクルごとにどれだけ自分を閉じるかです。



したがって、他のコンポーネントでテストしようとしましたが、同じ結果が得られました。 私の友人は、何かが完全に間違っていることを認めざるを得なかったので、機器を設置してセットアップした人に電話して、絶対に明らかな不具合を示しました。 私たちは、彼らが疲れて、友人と私が昼食に行くまで、彼らが長い間装置をいじるのを見ていた。 戻ったとき、彼らはすでに問題が何であるかを理解していました。 彼らは本当にアンプを改善しましたが、今では不十分な接地の流れが回路からの漏れを引き起こしました！ 彼らはもっと重い銅被覆の地面を設置するだけで、すべてがうまくいきました。 前述したように、このようなマシンのコンポーネントの1つを改善すると、各コンポーネントが完全に独立しているという事実を考慮しても、システムパフォーマンスが混乱することになりました。 これは些細な例ですが、このルールの意味を示しています。 通常、コンポーネントを改善する効果はそれほど強く明白ではありませんが、パフォーマンスに等しく悪影響を及ぼします。



あなたはおそらくこの規則をまだ信じていないので、私はそれをあなたに適用させてください。 ほとんどの人は、試験の準備をするときに、学期の終わりの最後の瞬間に資料を読み直し、暗記します。ほとんどの場合、取得したい教育に関しては生産的ではありません。 問題は、各コースの試験に個別に合格し、各学期を個別に正常に終了する必要があると認識しますが、実際には、トレーニングの最後に知識ではなく、その各段階。 シカゴ大学での学部課程の最後の2年間で、主な専門分野の9つのコースに基づいて1つの試験、追加の専門分野の6つのコースに基づいて別の試験を受験する必要がある規則がありました。 そして、重要なのはこの結果であり、トレーニングを通して学生が受けた成績ではありませんでした。 その瞬間、私は教育に対する体系的なアプローチが何であるかを最初に理解しました。 特定のコースを選択する際、試験に合格する学年や知識を教授にどのように喜ばせるかではなく、一定期間後、たとえば2年後でも応募できるように、科目を学び理解することが重要ですこのコースで得た知識。



試験前に詰め込むのは時間の無駄です。 あなたはこれを本当に理解していますが、ほとんどの人の行動は、この真実の断定的な拒絶を示しています。 前に述べたように、言葉はシステムエンジニアリングの仕事を評価する上でほとんど意味がありません。何をするかが重要です。 教授、そしてあなたの研究のために法案を支払う人たち、そしておそらくあなた方の何人かはあなたが教えられていることはあなたの将来のキャリアに非常に役立つだろうと信じています。 ただし、システムコンポーネントを最適化して、全体に悪影響を及ぼします！ システムエンジニアリングは従うのが難しいプロセスなので、詳細に迷子になりやすいです！ 言うのは簡単ですが、するのは難しいです。 この例は、私の推論の現実を示すことを目的としています。多くの人が言いたいことを知っていますが、現実の世界で行動する時が来たときに実際に実践できる人は多くありません。 あなたのほとんどはできません！



システムコンポーネントの最適化の影響の別の例として、大学の数学コースの指導を検討してください。 長年にわたり、数学的分析と線形代数のコースを最適化し、これらの各コースに直接関係のないものをすべて削除しました。 その結果、全体として見た場合、数学の教育に大きなギャップが生じました。 （1）数学的帰納法の重要な方法、（2）代数の2次方程式に関連した簡単な言及の後、実際には触れません。同時に2つの新しい複雑な概念に精通し、そしてもちろん、これは彼を混乱させます、（3）不確実な係数の有用な方法が簡単に述べられています、（4） lstva不可能、（5）は、離散数学、（6）現実世界での適用の重要な概念に訓練例を考えて学生をもたらすために行われている何の努力を無視されていません。 これはさらに続けることができます。個々のコースを最適化するために、ほとんどの優れた数学教育は省略されています。 通常、数学的分析の内部構造と限界の中心的な役割は重要ではないようです。



私が研究した（そしてそれらの多くがある）数学的分析の標準コースの提案されたすべての変換は、「一般的な数学的教育とは何ですか、そして数学的分析の過程で何をすべきか」という質問から決して始まりません。 彼らが数学教育に一般的に含まれているものを研究していないので、教育にコンピューターの使用を含めようとする人はほとんどいません。



学習に対する体系的なアプローチは繁栄せず、さまざまな観点からの愛好家だけが、地元のイニシアチブに適したものを自分で作成しようとします。 ほとんどの場合、「この部分が含まれる一般的な問題は何ですか？」という質問は広範すぎると見なされているため、コースの最適化が継続しています。 どのシステムでも改革を計画する人はほとんどいません。最初にシステム全体の主要な問題を理解しようとすると、発見された最初の症状をすぐに攻撃します。 その結果、最初に目を引くのは、それが何であるかではなく、システムに必要なものではありません。



最近、システム工学の歴史について考えようとしました。 また、システムが設計されたという事実は、設計者が個々のコンポーネントではなくシステム自体を念頭に置いていたことを意味するものではありません。 私が詳細に読んだ最初のシステムは、1200-1400年頃の夜明けのベネチアの兵器庫です。 彼らには生産ラインがあり、船がラインを離れる頃には、ロープ、マスト、帆、そして訓練されたチームさえも彼らの場所にあり、船はすぐに出航しました！ 定期的に、新しい船は兵器庫を去りました。 これは、機器が製造されたときに適切に訓練された人々を含む、定刻生産の初期の例です。



最初の鉄道は、もちろん、システムでした。 しかし、最初のビルダーが実際に個々のパーツを最適化しようとしなかったのか、それがシステムであり、機能するシステムを実現するためにパーツがどのように相互作用するのかを考える必要があると本当に思っていなかったのかわかりません。



システムエンジニアリングの問題に最初に遭遇したのは電話会社だったと思います。 適切なサービスを提供するには、すべての部品を相互接続し、高い信頼性を確保する必要があります。 当初から、同社は機器だけでなくサービスも提供しています。 これは大きな違いです。 何かを作成し、それを他の人が使用できるようにしておく場合-これは1つのことですが、これをサービスとしてサポートする場合は別です！ その前に多くの人が明らかに小さなシステムに出くわしましたが、電話システムは開始前よりも大きく複雑でした。 彼らはまた、おそらく初めて、拡張に規模の経済性がないことを発見しました。 反対に、これには損失が伴います。 各新規クライアントは他の既存のクライアントと組み合わせる必要があったため、各新規クライアントのコストは前のクライアントよりも高くなりました。 したがって、システムは十分に検討する必要があります。



古典的な数学的教育を受けて、システムエンジニアになった方法を理解しているふりをするつもりはありませんが、私はシステムエンジニアになりました。 穀物は私の大学時代に発生したと思いますが、実際にはロスアラモスで発芽しただけで、現在の航空機の特別な区画に爆弾を正確に設置するプロセスを含め、各コンポーネントが適切に設計および調整される必要があることが誰にでも明らかになりました。 同時に、爆弾を開発した敵がそれを行う前に、作業を迅速に行わなければなりませんでした。



Nikeの誘導ミサイルシステム、私が取り組んだコンピューターシステム、およびBell Telephone Labsで働いていた他の多くの側面から、システムエンジニアリングを学びました。抽象ではなく、全体を理解せず、そのコンポーネントだけを見た馬鹿の日々の例がありました。 コンピューターを使って作業していたため、システムアプローチがどのように機能するかをすぐに理解していないことに気づきましたが、それでもコンピューターは研究開発に携わる組織の一部として構築されていることに徐々に気付きました。これは確かに非常に重要です。 しかし、長い目で見れば重要なのは、このシステムのコンピューターの価値でした。マシンは、それらを使用した人員の仕事を促進するだけでなく、組織と社会の目標を達成するのにどれだけ役立ちましたか。



ここでもう1つポイントを思い出す必要があります。これは、ソフトウェアと機器の作成で明らかになり、システム設計の新しい問題を明らかにしています。 すべてが急速に変化しているため、システムは絶えず更新され、将来どのような変化が起こるかを最初に理解することは困難です。 柔軟性は、モノとプロセスの最新の設計の一部である必要があります。 設計の柔軟性により、システムのインストール後に必然的に発生する変更にうまく対処できるだけでなく、設計の後の段階とシステムのフィールドトライアルの両方で必然的に発生する小さな変更の形で自分の作業に貢献できます。 クワジェリン諸島のナイキプロジェクトのフィールドテストに参加する前に、テスト中にどれだけの変更が行われるかを理解していませんでした。 機器を設置しましたが、プロセスと並行して、設置に絶え間ない変更が加えられました！

第二のルール

システムエンジニアリングの設計の一部は、他の部品のパフォーマンスを低下させずに、それらを正常に通過させるための変更の準備です。

あなたの教育に戻る：私たちの本当の仕事は、あなたを私たちの過去や現在に備えることではなく、あなたの未来に備えることです。 だからこそ、現在さまざまな分野の基礎と考えられているものの重要性を強調し、おそらく短期的に存在する可能性のある現在の詳細を慎重に無視しました。 前に書いたように、設計アプローチの半減期は15年です。これから学習するアイデアの半分は、15年後には役に立たなくなります。

第三のルール

仕様をより正確に満たすほど、過負荷時のパフォーマンスが低下します。

このルールの真実は、特定の負荷で橋を建設するときに明らかです。 適合が規定の荷重に近ければ近いほど、制限を超えた場合にブリッジがより速く崩壊します。 同じことが電話会社の中央オフィスでも見られます。 最大負荷向けにシステムを設計すると、トラフィックがわずかに過剰であっても、システム全体の動作がすぐに低下します。 したがって、確立された仕様を超えると、優れたプロジェクト設計により生産性が徐々に低下します。

この章を書く準備として、私はG.R.による「One Man's Systems Engineering」という一連の未発表のエッセイを読み直しました。 ウェスターマン（1975）、ベル電話研究所でまだ働いています。 これらのエッセイは、システムエンジニアリングにおける「何、どのように、なぜ」のトピックに関する唯一の深い哲学的議論です。 私は著者の言葉から特定の時点で少し離れますが、一般的に彼の論文に同意します。 私は彼のエッセイで彼が議論していることを名前だけで要約することができます：



1.ワンマンズシステムエンジニアリング。 /一人システム工学

2.システムエンジニアリングとは /システムエンジニアリングとは

3.目的について。 /目標について

4.システムエンジニアは何をしますか？ /システムエンジニアは何をしますか？

5.システムエンジニアリングのフレームワーク。 /システムエンジニアリング構造

6.組織およびシステム工学。 /組織およびシステム工学

7.目的と政策立案者。 /目標と政策立案者

8.システム工学の方法論について。 /システム工学の方法論について

9.評価および（Un）常識。 /評価と常識/珍しいアプローチ

10.使節。 /メッセンジャー



このリストは、軍事プロジェクトに取り組み、電話会社の体系的な問題を解決している間に生じた彼の見解の幅を明確に示しています。



彼は、個々の問題の分析よりも、システムエンジニアリングの問題を扱う人々のグループをより重視しています。 コンピューティングの経験が限られている私は、コンピューターの正しい使用について誰かと話し合う機会なしに一人で働いていました。 もちろん、彼の仕事は私の仕事よりもはるかに困難でした。



彼は、チームに集まった専門家がシステムエンジニアリングの基盤であり、プロジェクト間で適切なレベルの経験を維持するために専門分野に戻るべきだと考えています。 チームを使用して頻繁に火災に対処することは、彼らの分野で磨かれた経験を失うため、有害です。



私たちは、システムエンジニアリングプロセスが決して終わらないことに同意しています。 その理由の1つは、問題を解決すると環境自体が変わり、解決する必要がある新しいタスクが作成されるためです。 たとえば、最初にコンピューターセンターの管理を始めたとき、小さなタスクは大きなタスクよりも比較的重要だと考えました。 常に信頼できるサービスを提供したかった。 したがって、午前1時間と昼食時間を設定し、その間、3（またはそれ以下）分だけのタスク（主にソフトウェアテスト）を実行することを許可し、タスクが5分以上実行された場合、それを停止する必要がありました。 タスクがほぼ完了した場合でも。 その結果、10分間の問題を抱える人々は、それらを3つの小さな断片に分割し、他の従業員に配布し、私が設定したルールの枠組み内でそれらを実施しました。 そのため、データ入出力システムの負荷が増加しました。 私のソリューションがシステムの反応を変えました。 1人の従業員に最適な戦略は、研究室全体に最適な戦略と明らかに反対でした。 システムエンジニアの機能の1つは、個人のローカルな最適化のほとんどを停止し、システム全体のグローバルな最適化を実現することです。



設計が決して止まらない2番目の理由は、最初のタスクに対して提案された解決策が通常、エンジニア自身の深い理解と不満につながることです。 さらに、設計段階が提案されたソリューションから評価へ、およびその逆に絶えず移動している間、この再考のプロセスを停止する必要があり、実際のタスクはソリューションを取得することです。 したがって、エンジニアは、長期的にはソリューションがまだ最適ではないことを理解しています。



ウェスターマンは、私のように、クライアントはいくつかの症状に気づいているかもしれないが、彼らの本当の原因を理解していないかもしれないと信じています。 そして、それは愚かで、症状だけを治そうとします。 したがって、システムエンジニアはクライアントの声に耳を傾ける必要がありますが、クライアントから現象をより深く理解しようとする必要があります。 したがって、システムエンジニアの仕事は、問題が何であり、症状から実際の原因に移行する方法をより深い意味で判断することです。



システム自体、見つける必要がある解決策は定義されておらず、問題の境界は可動性であり、解決策の検索の新しい反復ごとに拡大する傾向があるため、多くの場合、最終的な解決策はありません。 ただし、評価と決定の各サイクルには努力する価値があります。 少し理解を深めても次のラウンドに備えない決定は、まったく解決策ではありません。



システム工学の本質は、これが特定の問題や最終的な解決策ではなく、自然な状況としての進化に関するものであるという事実を受け入れることだと思います。もちろん、これは彼らが学校で教えられているものではなく、特定の解決策がある特定の問題を示しています。



学校は現在の状況にどのように適応し、システム工学を教えることができますか。これは、社会の発展の観点からますます重要になっています。結果を実感するまで、システムエンジニアリングに対する実験室アプローチのアイデアは魅力的です。上記のシステムエンジニアリングは、標準的な学校教育に大きく依存しています。特定の問題を解決するには、特定の方法が適しています。ここでの新しい要素は、社会の根底にある不確実性を背景にした特定の問題の定式化です。特に学校には新しい科目であるシステムエンジニアリングを導入する時間もリソースもないため、従来の教育アプローチを無視することはできません。この状況でできる最善のことは、常に言及することだと思います学校教育の枠組みの中での決定がシステム工学の現実とどのように異なるか。



Westermanは、明らかに、システムエンジニアリングの技術は、新旧両方の顔を含むチームで最もよく研​​究されると考えています。同時に、より経験豊富な同僚をプロセスから徐々に削除し、チームに新しい人を紹介する必要があると彼は言います。 「孤独な狼」の個人的な経験を伝える方法がわかりません。特定の状況で何をしたか、どのように行動したかについてのみ話すことができます。通常、実際の状況は非常に複雑であるため、外交政策、組織の習慣、最終システムを立ち上げるチームの個人的な資質、現場の労働条件、伝統などの要因を克服するのに多くの時間がかかります。これらの要因はすべて、問題の解決に強い影響を及ぼします。システム。一般的にこの決定は、対立する目標と、生徒の側で応答の構造を形成する境界の無形部分の重要性のまれな理解との間の大きな妥協になります。したがって、システムエンジニアリングの実際の問題を明確かつ詳細に表現することはほとんど不可能です。代わりに、詳細の一部を簡素化しながら、全体像を過度に歪めない学習状況とストーリーを使用する価値があります。前の章に再度戻ると、多くの例が見つかります。多くの点で、システムエンジニアリングの状況に関する簡単な話です。私は確信しているシステムエンジニアであり、必然的に常にこの方向に傾くと信じています。しかし、もう一度明確にしましょう。システムエンジニアリングは、特定のソリューションの特定の問題に対する古典的な単純化の強固な基盤の上に構築する必要があります。疑うこれは、ab initioで教えることができること。



私は間違った問題を正しく解決する多くの提案された解決策を見てきました。ある意味では、システムエンジニアリングは正しい問題を解決しようとしていますが、おそらく少し間違った方法で解決しようとしています。ただし、その実装では、ソリューションは一時的なものであり、設計の次の反復中に完全なエラーが特定され、システムの一般的な理解が向上します。すでにこれについて言及しましたが、もう一度言いましょう。より深い理解をもたらさない解決策は悪い解決策ですが、これが現在の制限時間内にできることのすべてである可能性があります。システムエンジニアリングの目標は、問題の本質をより深く長期的に理解することであると同時に、クライアントは常に現在の症状に対する即座の解決策を求めています。繰り返しますが、メタシステムエンジニアリングにつながる競合！



システムとその問題の詳細な理解の例として、ナイキの誘導ミサイルプロジェクトを検討したいと思います。最初は、目標は単一のターゲットを倒すロケットを作ることでした。この目標を達成した後、私たちはナイキミサイルのバッテリーと、敵の航空艦隊の攻撃の下で各ミサイルを調整する方法について考え始めました。それから、どの目標と都市を保護し、どの都市を保護しないかを考え始めた日がやってきました。私たちは、すべての目標が敵にとって同等に高くなければならないこと、他の目標よりも少ないまたは高い保護される目標がないことを理解し始めました。各ターゲットは、敵が攻撃することによって受けるダメージに比例して保護する必要がありました。したがって、私たちは、ナイキミサイルを、敵が引き起こしたダメージの代価を支払うための単なるデバイスと見なし始めました。また、彼に「安い」目標を残しませんでした。このビューは、開発を開始したビューとは大きく異なります。これは、各ソリューションが問題の理解の発展に貢献する必要があるという事実の良い例です。あなたが指摘する最初の症状は、これに成功するとすぐに見えなくなります。あなたとあなたのクライアントの理解が深まるにつれて、目標は常に変わります。



システムエンジニアリングは、エキサイティングな職業であり、実践するのは困難です。実際のシステムエンジニアには、ゲーム自体を効果的にプレイできないだけでなく、良いストーリーを伝えるだけの人を排除する必要があるように、大きなニーズがあります。



継続するには...



誰が翻訳を手伝いたいのか-個人のメールまたはメールに記入してくださいmagisterludi2016@yandex.ru