本「ソーシャルアーキテクチャ」の翻訳：第5章デザイン、開発、イノベーション

「コミュニティの規模と多様性が重要です。」

ウィキペディアが「価値を付加する新しい方法での古い顧客や市場の明らかなニーズやニーズではなく、新しい要件を満たすソリューションによる新しい価値の開発」と定義するイノベーションを見てみましょう。 実際、これは問題をより安価に解決することを意味します。 それは単純に聞こえますが、倒れた技術巨人の話は反対を示唆しています。 チームがこれを正しく理解しないことが多い理由を説明し、革新的なものを作成する方法を提供します。

2つの橋の物語

2人の古いエンジニアが人生について話し、彼らの傑出したプロジェクトについて自慢していました。 エンジニアの一人は、彼がこれまでに作成した最高の橋の1つをどのように設計したかを語った。



「川の峡谷の上に建てました」と彼は友人に言いました。 「それは広くて深かった。 私たちは2年かけて土壌を研究し、プロジェクトと材料を選択しました。 最高のエンジニアを雇い、橋を設計しましたが、さらに5年かかりました。 最大のエンジニアリング会社を雇い、橋を主要な高速道路に接続するための構造物、タワー、制御柱、道路を作成しました。 建設中に数十人が死亡しました。 道路のレベルの下で、私たちは列車を立ち上げ、サイクリストのための特別な道を開きました。 私の人生の年はこの橋に関連しています。」



二人目はしばらく考えてから話しました。 「ある夜、友人と私はウォッカを投げて、渓谷にロープを投げることにしました」と彼は言いました。 「ただ木に縛られたロープ。 両側に1つずつ、2つの村がありました。 最初、人々はベルトと滑車を使ってこのロープに沿ってbaを引っ張りました。 それから誰かが2本目のロープを投げて、あなたが行くことができる道を作りました。 彼女は危険でしたが、子供たちは彼女を崇拝しました。 それから人々のグループがそれをやり直し、それをより強くしました、そして彼らの製品を持つ女性は毎日それを歩き始めました。 橋の片側では、市場が成長し、次第に大都市になりました。 家のための十分なスペースがありました。 ロープブリッジは、馬やカートが渡れるように木製のものに置き換えられました。 その後、市は金属棒で本物の石の橋を建設しました。 「後に彼らは石を鋼に置き換え、今日では同じ場所、つまり斜張橋に置きました。」



最初のエンジニアは黙って聞きました。 「それは面白い」と彼は言った、「私の橋は私たちがそれを建設してから10年後に解体された。 それは間違った場所に構築されたことが判明し、誰もそれを使用したくありませんでした。 数マイル下流の渓谷にロープを投げた人もいました。

ZeroMQがロードマップを失った方法

2012年初頭にフランスのリヨンで開催されたMix-ITカンファレンスでZeroMQの代表を務めたとき、ロードマップについて何度も尋ねられました。 私の答えは、ロードマップはもうありません。 それらがあり、それらを排除しました。 次のステップを決定しようとする数人の専門家の代わりに、イベントが自然に発展することを許可しました。 聴衆は私の答えが本当に好きではありませんでした。 フランス語すぎません。



ただし、ZeroMQの歴史は、ロードマップで問題が発生する理由を明確に示しています。 最初は、小さなライブラリ開発チームと数人の参加者がいて、承認されたロードマップはありませんでした。 そのため、私たちは計画をまとめ、リリースの形で計画しようとしました。 「ここに」、「次のリリースで何が起こるか」と書きました。



リリースが公開されると、問題が発生しました。何かを約束するのは簡単であり、計画に従ってそれを行うのははるかに困難です。 まず、作業のほとんどは自発的なものであり、ボランティアをロードマップに誘導する方法は完全には明確ではありません。 第二に、タスクの優先度は時間とともに大きく変化します。 したがって、私たちは守れないと約束し、今後のリリースはロードマップと一致しませんでした。



もう1つの問題は、ロードマップを決定したときに、領土を禁止しているように見えたため、他の人が参加するのが困難になったことです。 人々は自分が考えていることの実現に参加することを好みます。 何をする必要があるかをまとめたリストは、参加する興味深い機会ではなく、雑用のようなものです。



その結果、ZeroMQのトラウマ的な変化に直面しました。「すべてを正しく行う」ことに多くの努力と言葉が費やされたにもかかわらず、ロードマップは私たちを救いませんでした。 その結果、APIとプロトコルに互換性のない変更が加えられます。 変更のプロセスを定義する新しいアプローチが必要であることは明らかでした。 ソフトウェア開発者は、賢明な開発者が慎重にチェックして熟考しなくても、強力で効果的なソリューションが生まれるという考えを好みません。 それでもなお、リヨンでは誰も進化論に疑問を抱かないでしょう。 これは奇妙で皮肉なことなので、この現象については、2012年の初めからZeroMQコミュニティが発展を続けているため、引き続き考察します。



革新の一般的な理論は、問題の状況を考えた独創的な個人が正確で正確な解決策を提供すると言います。 時々、彼らは「エウレカ！」のスタイルで洞察を持っています-そして、解決策は準備ができています。 発明者と発明のプロセスはまれで、貴重で、唯一のものです。 歴史はこれらの孤独なヒーローの多くを知っています。 私たちは彼らに現代世界を借りています。



ただし、よく見ると、ここに何かが収まらないことがわかります。 物語は、単一の発明者については語りません。 彼女は、他の多くの人々の作品から生まれたアイデアに対して著者を盗んだ、または流用した幸運な人々について語っています。 彼女はクーデターを起こし、無益で意味のない検索に何十年も費やした優秀な人々について語っています。 トーマス・エジソンのような大規模で有名な発明者は、実際には科学者の大規模なグループによって実施されたさまざまな研究を整理するのが得意でした。 これは、Steve JobsがAppleが作成したすべてのデバイスを発明したという声明に似ています。 良い神話、マーケティングには良いが、科学の実用的な観点からは絶対に意味がない。



最近の数十年の歴史は、より良く記録され、操作がより困難であることが、これを明確に示しています。 インターネットは間違いなく最も革新的で急速に発展している技術の1つであり、その形成には大量の信頼できる情報があります。 この技術には発明者がいません。 代わりに、現在の一連の問題を慎重に成功裏に解決し、回答を書き留めて、すべての人が利用できるようにする人々が大勢います。 インターネットの革新的な性質は、アインシュタインの小さな選ばれたグループによってではありません。 誰でも使用でき、改善できるオープンソースソフトウェアを使用して、何百、何千もの賢い人（ユニークな賢人ではないが）が使用および改善できるRFC文書が提供されています。 それは、コミュニティの共有、ミキシング、およびスケーリングに由来します。 それは、良い決定の数が絶えず増加し、悪い決定を取り除くことに起因しています。



したがって、ここにイノベーションの代替理論があります。

1. 問題/解決策の無限の領域があります。
2. 面積は、外部の状況に応じて時間とともに変化します。
3. 身近な問題だけを正確に認識することができます。
4. ソリューション市場を使用して、問題の収益性/コストを評価できます。
5. 解決する問題に最適なソリューションがあります。
6. この最適なソリューションをヒューリスティックかつ機械的に実現できます。
7. インテリジェンスはこのプロセスを加速できますが、それに代わるものではありません。

これは次のとおりです。

• 個々の創造性はプロセスよりも重要ではありません。 賢い人はより速く働くことができますが、間違った方向に進みます。 現実の集合的なビジョンは、私たちが現在の道をたどり、自分自身や他人を欺かないようにするのに役立ちます。
• 確立されたプロセスがある場合、ロードマップは必要ありません。 時間が経つにつれて、ソリューションが市場シェアを奪い合うと、機能が増加します。
• 私たちは解決策を見つけるほど多くは発明していません。 創造的な性質に対する哀dolの意：創造性は単なる情報処理のゴーレムであり、自らのエゴを磨き、カルマを高めることに夢中になります。
• インテリジェンスは社会的な効果ですが、個人的なもののように感じます。 他人から切り離された人は考えるのをやめます。 他の人なしでは問題を特定することも解決策を評価することもできません。
• コミュニティの規模と多様性が重要です。 より大規模で多様なコミュニティは、関連するタスクをカバーし、それらをより正確に解決し、少数の専門家グループよりも速く実行します。

したがって、私たちが一人の専門家を信頼するとき、彼らは古典的な間違いを犯します。 問題ではなく、アイデアに焦点を当てています。 彼らは間違った問題に焦点を合わせています。 彼らは解決される問題の価値について間違った結論を下します。 そして、彼らは彼らが取り組んでいるものを使用しません。



上記の理論を実践できますか？ 2011年の終わりに、私はC4および同様の契約を文書化し、それらをZeroMQおよびクローズドソースプロジェクトで使用し始めました。 基礎となるプロセスは、私がシンプル指向設計（SOD）またはシンプル指向設計と呼んでいるものです。 これは、シンプルでエレガントな製品を開発するための再現可能な方法です。 問題領域を迅速かつ安価にナビゲートできる柔軟なソリューションプロバイダーチェーンに人々を編成します。 これを行うには、「パッチ」と呼ばれる最小限の許容可能なソリューションを作成、テスト、および保持するか、それらを放棄します。 実行可能な製品は、上下に重ねて適用された長い一連のパッチで構成されています。



まず、ODAはこのようにZeroMQを開発しているため、重要です。 また、大規模なZeroMQアプリケーションを作成するときに使用する開発プロセスの基盤でもあります。 もちろん、ZeroMQでは任意のソフトウェアアーキテクチャ手法を使用できます。

ODAにたどり着いた方法をよりよく理解するために、代替案を見てみましょう。

ゴミ志向のデザイン

大規模な組織で最も人気のある開発タイプは、ごみ指向設計です。 TODは、お金を稼ぐにはクールなアイデアが必要だという信念に基づいています。 この頑固でナンセンスなポップアップは、想像力を奪われている人々にとって強力な松葉杖です。 理論は次のようになります。アイデアはめったにないので、コツはそれらをつかむことです。 音楽から遠く離れた人々がギタリストを賞賛しているように、偉大な才能があまりにも安くて文字通り街頭で演奏していることに気付かない。



TODの主な消耗品は、コストのかかる「思考」です。コンセプト、エンジニアリングドキュメント、およびゴミ箱に直接行く製品です。 このように判明します。CreativePeopleには、「X u Yができる」という長いリストがあります。 私は、製品が実行できるこれらすべての驚くべきことの無限に詳細なリストを見てきました。 私たちは皆これについて有罪でした。 アイデアを生成する創造的な作業が完了するとすぐに、それを実現するだけの問題になります。



その後、マネージャーとそのコンサルタントは、素晴らしいアイデアを、完璧な言葉遣いのドキュメントを大量に作成するデザイナーに伝えます。 それらは、マネージャーの最高の10のアイデアを順番に取り、100のプロジェクトに変えます。

これらの開発は、頭を悩まし、このナンセンスを思いついたのは誰なのかと考えている開発者に引き継がれます。 彼らは議論し始めますが、デザイナーはオリンパスの子孫であり、最終的に、非致命的な開発者は創造的な人々と高価なコンサルタントと議論します。



その後、開発者は隠れ家にさまよい、屈辱を与えられ、鞭で無理やり巨大で「非常にエレガントな」ジャンクを作ります。 そして、デザイナーは実際のコストを考慮していないため、この作業は緊張しています。 ちょっとした気まぐれでも、数週間の仕事に変わる可能性があります。 プロジェクトが遅くなると、マネージャーは開発者に夕方と週末に残業を強います。



その結果、動作中の製品に似たものが光を見ます。 それはきしみがあり、もろく、複雑でandいものです。 デザイナーは開発者を自分の能力がないと非難し、コンサルタントに豚のメイクをするためにより多くを支払い、製品は少しずつ良くなり始めます。



この時までに、マネージャーはすでに製品の販売を試み始めており、予想外に、誰もそれを必要としていないことに気付いていました。 疑いの影もなしに、彼らは大胆に何百万ドルも広告会社に投げかけ、なぜこの製品が絶対に必要なのかを一般に説明しています。 彼らは他の組織と取引して、彼を怠zyで愚かな、恩知らずの市場に押しやる。



12か月にわたる激しい広告キャンペーンの後、製品はまだ利益を上げていません。 さらに悪いことに、彼は劇的に失敗し、報道機関によって完全な失敗として非難されています。 会社はゆっくりと倉庫に持ち込み、コンサルタントを解雇し、小さなスタートアップの競合製品を購入し、自社製品のバージョン2と呼んでいます。 数億ドルが無駄になっています。



一方、組織内のどこかで別のマネージャーとビジョンがテキーラを一杯余分に注ぎ、マーケティング部門に彼の素晴らしいアイデアを伝えます。



TODがそれほど一般的でなかったら、似顔絵になっていただろう。 大企業による発売の準備ができている20の製品のうち約19が失敗します（はい、統計の87％はローカルで行われます）。 積極的な広告と弱い競合他社のおかげで、20のうち1つだけが成功する可能性があります。



TODの基本的なモラルは明確ですが、把握するのは困難です。アイデアは安価です。 例外なし。 素晴らしいアイデアはありません。 「ああ！」という言葉で会話を始めた人 私たちもこれを行うことができます！」さまよう伝道者の熱意でbeatられなければなりません。 山のふもとにあるカフェに座って、ホットチョコレートを飲んで、他の人に次のように言うのと同じです。「ちょっと、いいアイデアがあります。この山に登れます！ そして、シャレーの上に建てます！ 2つのサウナ付き！ そして庭！ ねえ、太陽電池パネルを使って電気を供給できます！ おい、かっこいい！ どの色で塗りますか？ 緑色で！ いいえ、青で！ OK、行ってやる、しかし今のところはここにいてテーブルとグラフに取り掛かる！」



成功する開発プロセスの良いスタートのために、人々が直面する本当の問題を集めてください。 2番目のステップは、「この問題の解決にかかる費用はいくらですか？」という基本的な質問を使用して、これらの問題を評価することです。 その後、解決する価値のある問題のリストを作成できます。 実際の問題に対する優れたソリューションは、成功する製品です。 それらの成功は、ソリューションがどれだけ優れていて安価であるか、そして問題がどれほど重要であるか（そして、残念ながら、どれだけのマーケティングコストを支払うことができるか）に依存します。 しかし、その成功は、アプリケーションがどれだけの労力を必要とするか、言い換えれば、どれだけシンプルになるかにもかかっています。



今、絶対的な無益のドラゴンを打ち負かし、複雑さの悪魔を攻撃します。

複雑さを重視した設計

本当に優れた開発チームと中小企業は通常、まともな製品を作成できます。 しかし、ほとんどの製品は依然として複雑すぎるため、成功する可能性は低くなります。 これは、スペシャリストのチーム（最高のチームでさえも）が、私が言うところの複雑性指向設計（COD）を頑固に実践することが多いためです。 そして、それは次のように機能します：

• 経営陣は、経済的な観点から魅力的な興味深い複雑な問題を正しく特定します。 ここでは、彼らはただTODの軌道に乗っています。
• チームは熱心にプロトタイプの作成とコアの作業を開始します。 このすべては、計画どおりに機能し、チームはさらに日焼けしながら、建築の集中的な開発と議論、エレガントで美しいスキーム、調和のとれたスキームの作成を掘り下げます。
• 経営陣が戻ってきて、チームがさらに複雑な問題を解決するよう促します。 私たちはコストとコストを同一視する傾向があるので、問題の解決がより困難で高価であればあるほど、あなたはそれを手伝うことができます。
• チームは、ものを作成したいエンジニアで構成され、彼らはビジネスに参入します。 それらは作成し、作成し、作成します、そして、それはすべて大規模で、美しくデザインされた複雑さで終わります。
• 市場は、製品に精通すると、耳の後ろにひっかき、「真剣に、これがあなたが見つけた最良の解決策は何ですか？」と尋ねます。 はい、マニュアルの山を登るのに自分のお金を費やす必要がない場合、人々は製品を使用します。
• 経営陣は、コスト（トレーニングと使用）が高いほど価値が高いという見解を共有する大規模な顧客から肯定的なフィードバックを受け取り、プロセスを推進し続けます。
• 現時点では、世界のどこかで、小さなチームが最善のアプローチを使用して同じ問題を解決しており、1年後、現在の市場での地位を小さな断片に広げています。

CODの特徴は、間違った問題の解決に取りつかれ、集団マニアになりやすいチームです。



通常、COD製品は大きく、野心的で、複雑で人気がありません。 オープンソースソフトウェアの多くはCODから来ています。 開発者にとって、潜在的な問題をますますカバーするために、プロジェクトの停止と拡張を停止するのは非常に困難です。 彼らは「もし誰かがXを作りたいとしたら？」と主張しますが、彼らは決して「Xは実際にいくらですか？」と自問しません。



Bluetoothは、実際にはCODの良い例であり、ユーザーが嫌いな複雑で過度に複雑なプロトコルのセットです。 完全に特許を取得した業界には真の代替手段がないためにのみ存在し続けています。 Bluetoothは完全に保護されており、非接触プロトコルにはほとんど役に立ちません。 同時に、彼は開発者向けの標準APIを欠いているため、アプリケーションで使用するのは非常に高価です。 グループディスカッションチャンネル#zeromqで、Wintreのメンバーは、XMMS 2には有効なプラグインシステムがあるが音楽を再生できないことを発見したとき、どのように激怒したかを書きました。



CODは、開発者とエンジニアが技術的な解決策を探し続け続けるためのウサギの穴です。 彼らはより多くの機能を追加し、仕事の経済的側面に目をつぶっています。



基本的なCODレッスンはシンプルですが、味は苦いです：

• 今必要のないことをするのは無意味です。 あなたがどれだけ才能があろうと独創的であろうと-あなたが誰も必要としないことをしているなら、あなたは時間を浪費しています。
• 問題はしばしば不平等です。 簡単に解決できるものもあれば、難しいものもあります。 皮肉なことに、単純な問題を解決することは、複雑な問題を解決するよりも人々に利益をもたらす可能性が高くなります。 したがって、開発者にランダムな作業を許可する場合、ほとんどの場合、最も興味深いが関連性のないタスクに焦点を合わせます。
• エンジニアと開発者はさまざまなことをして装飾することを好みますが、これは必然的に複雑になります。 「ストップタップ」は、最も重要なタスクに対する重要度の低い単純な答えを人々に探すことを余儀なくさせる、短い厳密な期限を設定する方法を持つことが不可欠です。

シンプル指向設計

最後に、希少で価値のあるシンプル指向設計（SOD）に到達します。 このプロセスは実装から始まります。何かを始めるまで、何をすべきかわかりません。 アイデアや大規模なプロジェクトを投入するだけでは役に立たないだけでなく、真に正確なソリューションを開発できなくなります。 本当に大切なオアシスのように、本当の情報は隠されており、それらを検索する以外のアクティビティは、それらをさらに霧に包むだけです。 あなたはモバイルである必要があり、速く、軽く動く必要があります。



SODは次のように機能します。

• 興味深い問題のリストを作成し（人々がテクノロジーや他の製品をどのように使用するかを観察することによって）、それらを単純なものから複雑なものへと整理し、それらの使用方法を検討および決定します。
• 最も単純で最も劇的な問題を取り上げ、許容できる最小の数の解決策、つまり「パッチ」を探します。 各パッチは、元々一般的に承認されている問題を最適な方法で解決します。
• パッチを評価するとき、次の質問に導かれます：「問題に対するより簡単な解決策を見つけることができますか？」 少ないほど良い。 完璧なパッチは、ユーザーに何も要求せずに問題を解決します。
• 当社の製品の開発は、「概念実証」の問題を解決するパッチを作成することで構成され、その後、数十万のパッチで構成されるより成熟した製品の単一ラインに統合されます。
• パッチ以外のことは行っていません。 私たちはこれを正式なルールで実施します。このルールでは、すべてのアクションまたは義務を、明確で明確に文書化された、主要かつ普遍的に承認されたタスクに結び付ける必要があります。
• ソリューションプロバイダーのチェーンとしてプロジェクトを構築します。各プロジェクトは、その「サプライヤー」にタスクを提供し、それに応じてパッチを受け取ります。 サプライヤのチェーンは「停止クレーン」です。なぜなら、人々が熱心に答えを待っているとき、私たちは故意に狭い時間枠で働か​​なければならないからです。
• 個人は、任意のプロジェクトに取り組み、重要な問題に対するパッチを自分の意見で作成できます。 それらはどれもプロジェクトを「所有」せず、正式な規則に従うよう強制することしかできません。 個々のプロジェクトには多くのバリエーションがあり、それぞれが互いに競合する異なるパッチに囲まれている場合があります。
• プロジェクトは、正式なドキュメント化されたインターフェイスをエクスポートするため、ソースプロジェクト（クライアント）は行われている作業について暗闇の中にいます。 さらに、クライアントプロジェクトの注目を集めて競争することができ、自由で競争の激しい市場を作り出します。
• サプライチェーンを実際のユーザーと外部顧客に結び付け、外部のユーザーから受け取った問題をパッチで数時間で分析、評価、解決できるように、プロセス全体を迅速なサイクルで実施します。
• 最初のパッチから始まるすべての瞬間に、当社の製品はリリースの準備ができています。 これは重要です。なぜなら、ほとんどのパッチは不正確（10〜30％）であり、ユーザーに製品を提供するだけで、どのパッチに問題があり改善が必要かを見つけることができるからです。

SODはボトムアップアルゴリズムであり、未知の分野で最も重要な問題に対する最適なソリューションを見つけるための信頼できる方法です。 SODを使用するのに天才である必要はありません。実際の問題を解決する上で、フォギングアクティビティと進捗状況の違いを確認できれば十分です。



このようなアルゴリズムには制限があることに注意してください。 ローカル問題の解決に集中できます。 しかし、これが人生の仕組みです。私たちは長い間、小さな漸進的な改善を集めています。 独創的な開発者はいません。 私たちは、問題の局所性に関連するリスクを軽減し、エリア全体をカバーします。一般に、これは物議を醸す問題です。 制限から逃れることはできません。それらは物理法則のようなものです。 理論では、 これがイノベーションの仕組みであると言われているので、魔法の信念に導かれるよりも、それを受け入れて協力する方が良いとされています。



技術革新の増加する性質を理解すると、一部のチーム、企業、または製品が、見込みが減少する架空の国で立ち往生している理由を理解できます。 彼らは単に努力するのに最適なピークを見つけるための多様性と集合的な知恵に欠けています。 ノキアがオープンソースプロジェクトを閉鎖したとき、彼らは酸素を止めました。



優れたチームを持つ真に優れた開発者は、SODを使用して世界クラスの製品を迅速かつ正確に作成できます。 SODの利点を最大限に活用するには、開発者は最初の日から製品を長時間使用し、矛盾、異常な活動、その他の種類の誤動作などの問題を検出する能力を開発する必要があります。 多くの迷惑な現象に気付かない傾向がありますが、優れた開発者はそれらに注意を払い、パッチを適用する方法を見つけます。 開発プロセスの本質は、製品の問題を修正することです。



オープンソースプロジェクトでは、この作業を公的に行います。 「コードを開いてみよう」というものはありません。 私の意見では、これを行うと、人々はオープンソースプロジェクトの意味を理解していないことを意味します-ユーザーをあなたの研究に関与させ、メインアーキテクチャの周りにコミュニティを構築します。



本「ソーシャルアーキテクチャ」の翻訳：

• まえがき 群衆の知恵
• 第1章ツールキット
• 第2章
  
  - ボランティアの感情的な燃え尽き
  
  - オープンソースプロジェクトをキャプチャ/保護する方法
  
  - 個々の知性の神話
• 第3章
  
  -ZeroMQコミュニティ
  
  - ソフトウェアアーキテクチャの心理学
  
  -契約の重要性
  
  -自治コミュニティへの4つのステップ
• 第5章
  
  — , ,
  
  — open source
• 第6章生活システム

---

Filtechの価値に見合った高い技術シェアを持つプロジェクト/スタートアップを念頭に置いている場合は、お気軽に申請書を提出してください。

2月25日までまだ時間があります！



Telegramでチャット

PhilTechプロジェクトを開発している、または単に社会部門のテクノロジーのトピックに興味がある人々のコミュニティ。



#philtech news

#philtechイデオロギーのプロジェクトに関するニュースと有用な資料へのリンク。



Facebookページ

Philtechのスタートアップニュース、慈善のためのテクノロジーの世界からのロシアおよび国際的なイベント。技術と慈善の世界からの週刊ニュース



レターを購読してください

。