なぜソフトウエア後進国の日本でRubyは成功したのか？～ソフトウェアの成功の秘訣はコミュニティ、そしてコンウェイの法則にある

なぜソフトウエア後進国の日本で、Rubyは成功したのか？ 生みの親・まつもとゆきひろが語った五つのポイントの記事がとても心に残った。
ラフなメモ。

【参考】
なぜソフトウエア後進国の日本で、Rubyは成功したのか？ 生みの親・まつもとゆきひろが語った五つのポイント - エンジニアtype | 転職type

この記事で僕の心に響いたのは下記の文章だった。

（引用開始）
ソフトウエアの成功にとっては、コミュニティーやポリシーなど、意外とテクノロジーではない部分が重要だというのが、私の経験から言えることです。
（引用終了）

ソフトウェアは、プログラマが書いて生まれる。
しかし、永続的に存続していくには、ソフトウェアを囲むエコロジーが必要だ。
それは、開発者コミュニティやユーザコミュニティだ。

熱心なユーザや開発者がいるからこそ、ソフトウェアのバグがあってもユーザが見つけてくれて、開発者がパッチを即座に当ててくれる。
高品質なソフトウェア、永続するソフトウェアは、熱心なユーザや開発者がバグ修正したり、新たなアイデアに基づく機能改善によって成長していく。

オープンソースのコミュニティの存在意義と知的財産権: プログラマの思索

柔軟なソフトウェア設計はOSSコミュニティを活発化させる～OSSソフトウェアとOSSコミュニティの密接な関係: プログラマの思索

次の文章もすごく心に残った。

（引用開始）
最初に申し上げた通り、日本の大企業的なやり方はソフトウエアづくりの面ではうまくいきません。21世紀のソフトウエアビジネスをしようと思ったら、コミュニティーの存在が不可欠なのではないかと思います。
（引用終了）

日本の大企業的なやり方とは、製造業に基づく大量生産かつ高品質な生産プロセスとのことだ。
製造業の高品質な生産方式は、規模の経済を活かしやすい特徴がある。
しかし、ソフトウェアは規模の経済が効きにくいのが最大の特徴だ。
大人数で開発するほどソフトウェアの品質は悪くなるのはよく知られている。

ソフトウェアもムーアの法則で巨大化する: プログラマの思索

少人数のチームの方がソフトウェアの品質は高いという経験則: プログラマの思索

ソフトウェア開発のチームは人数が増えるとプロジェクトは失敗する経験則がある: プログラマの思索

その理由は、人月の法則、リーマンの法則によるものだ。
コミュニケーションロスが、ソフトウェア開発の生産性を大きく落とす。

ソフトウェアの複雑性は本質的な性質であって偶有的なものではない: プログラマの思索

リーマンの法則～ソフトウェアもエントロピー増大の法則を避けられない: プログラマの思索

その背後には、Conwayの法則がある。
1つのコンパイラを4チームが作ったら、4つのインターフェイスに分割されて、無駄に複雑なアーキテクチャになってしまった、という逸話を思い出す。
つまり、「アーキテクチャは組織構造に従う」。
だからこそ、逆に、組織をアーキテクチャに合わせるように、組織をフラットに少人数なチームへ編成し直す戦略が必要になる。
これが、逆コンウェイ戦略。

今、「DXとは組織論である」という風潮が流れているが、その背景には、ソフトウェアに基づくビジネスモデルを構築したいならば、従来の重厚長大な階層型組織ではなく、ソフトウェア開発に向いたフラットで少人数のチームへ編成し直すべき、というメッセージが込められているのだろうと思う。

Conwayの法則～アーキテクチャは組織にしたがう: プログラマの思索

逆コンウェイ戦略のメモ～望ましいアーキテクチャを促進するためにチームと組織構造を進化させる: プログラマの思索

ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説: プログラマの思索

DXとは組織論である: プログラマの思索