プログラマの思索

@t_wadaさんのBlogを読んでいたら、「プラグイン機構はソフトウェアの構造がコミュニティの構造に及ぼす事例に相当する」という重要な指摘があった。
考えたことをラフなメモ書き。

【参考】
OSS開発の活発さの維持と良いソフトウェア設計の間には緊張関係があるのだろうか? - t-wadaのブログ

【1】上記の記事では、「良い OSS 開発と良いソフトウェア設計の間には緊張関係があると思いますか?」という質問が発端になっている。
意図としては、OSSが良い設計であるには、ユーザからの多数の要望を五月雨式の取り入れると、アーキテクチャとしてもUIとしても一貫性がなくなり、複雑化するだけ。
一方、OSSが活発に活動を維持するには、熱心なユーザがフィードバックやパッチをどんどん送り、ソフトウェアをバージョンアップしながらどんどん機能改善していくミッションがあるべき。

(引用開始)
しかし、それは結果的にソフトウェアの構造をゆがめることにつながらないだろうか。活発さを志向するあまり、機能やコードベースの肥大化を招いてしまい、統一感のある小さく単機能なソフトウェアの姿を保てなくならないだろうか。
もし活発さを志向する OSS 開発にそのようなバイアスがかかるのであれば、そこには構造的な問題、不幸な構図があるように見えてしまう。
(引用終了)

つまり、OSSコミュニティの活発さとより良いソフトウェア設計の間には、トレードオフがある。
では、どうやってその折り合いを採るべきなのか？

一つの解決策としては、OSSのプラグイン機構を設けて、「ソフトウェアを汚さずに、ソフトウェアを拡張する機構」というI/Fを用意しておくことだ。

(引用開始)
プラグイン機構による開発者コミュニティへの質的な転換

その意味で、モリスさんの講演にあったようにソフトウェアの構造に「プラグイン機構」を設け、ユーザコミュニティから開発者コミュニティへの質的な転換を図るのは、ソフトウェア設計からエコシステム設計へとつながる、非常に重要な考え方であると再認識した。
組織構造がソフトウェアの構造に影響を及ぼすというのは最近よく聞く話だが（コンウェイの法則）、ソフトウェアの構造がコミュニティの構造に影響を及ぼしうるというのは重要な気づきであったと思う。

OSS プロダクトがメジャーになればなるほど、コントリビューションを取り入れつつ、全体の整合性は壊さないような舵取りが大事になってくるのだろう。
大きめの OSS プロダクトや言語設計者のバランス感覚や調整能力が際立つのもわかる。
(引用終了)

つまり、プラグイン機構とは、ユーザコミュニティが単に、ソフトウェアを使用するだけの受動的立場から脱却して、自ら必要な機能はプラグインで実装するように、誘導するためのソフトウェア設計機構なのだ。

よって、プラグイン機構は、「ソフトウェアは組織構造に従う」というConwayの法則のコミュニティ版と言えるのではないか。

【2】上記の記事を読んで、改めてRedmineについて思いを巡らせた。

【2-1】RedmineはRailsを開発基盤としているので、ソースも読みやすいし、プラグイン機構でユーザが機能拡張することも容易だ。
実際、Railsのプラグインの作成手順は、ネット上にいくらでも転がっている。

日本では、自分たちの組織に合った開発プロセスや業務プロセスに、Redmineを従わせて、Redmineを自由に使いたい、という要望が多い。
日本人はパッケージ製品をそのまま導入するのは嫌で、自分達なりにカスタマイズしたがる、という特徴が、Redmineにも出てくるわけだ。

Redmineが日本人好みのツールであるという仮説: プログラマの思索

Redmineが日本人好みのツールであるという仮説 part2～日本の硬い組織構造をRedmineが柔らかくしてくれる: プログラマの思索

その時、Redmine本体を修正するのではなく、プラグイン機構を使えば、Redmine本体の影響を最低限に抑えて、カスタマイズすることが可能だ。
そうすれば、Redmine本体のVerUPに追随しながら、カスタマイズした機能の保守コストを下げることができる。

【2-2】では、なぜ、「プラグイン機構＝ソフトウェア本体を汚さずにソフトウェアを拡張する機構」がRedmineにあえて必要なのか？

以前、Redmine勉強会では、JPLのRedmineの開発スタイルは非常に保守的である、という話があった。
実際、大幅な機能追加はやらないし、FunctionalTestが通らないパッチは受け取らない。
テストカバレッジは基本は100％になるまでリリースしない。

第8回東京Redmine勉強会の感想 #redmineT: プログラマの思索

JPLの美的感覚、設計思想が、熱心なユーザの機能改善要望を全て実現するのではなく、Redmineの発展に必要な機能、さらに、Redmineの品質低下を起こさないような機能だけに絞り込んでいるのだろう。

すると、確かにRedmine本体はVerUpしても安定しているだろうが、ユーザにとっては、標準機能だけでは機能不足と感じる場面も多くなる。

そんな時に、Redmineのプラグイン機構を用いて、Redmine本体に手を加えずに、自分たちの組織やプロセスに見合った機能を追加するわけだ。

換言すれば、プラグイン機構という柔軟なソフトウェア設計が、OSSアプリの標準機能では物足りないと感じるユーザに、自分達でカスタマイズできる余地を残しておき、それを利用させるような雰囲気を奨励している、とも言えるだろう。
それによって、Redmineは標準単体で安定した品質を保ちながら、ユーザはプラグインを入れて、自分達の環境に合ったプロセスを実現できる。
つまり、Redmineの柔軟なプラグイン機構が、ユーザにプラグイン開発を促進させ、多様なプロセスを実現することを促進させているわけだ。

【2-3】だから、Redmineのように、自由に機能拡張できるI/Fを持つOSSソフトウェアは、日本人向きなのだろう。

実際、Redmineはプラグイン機構以外にもREST APIやメールによるチケット登録、rakeコマンドなどの数多くのI/Fがあり、それらを適材適所に当てはめれば、機能をカスタマイズしやすい特徴がある。
以前、この辺りの事情は分析していた。

Redmineの裏の顔～開発基盤としてのRedmine: プログラマの思索

但し、この特徴はRedmineに限らず、SAPなどの著名なERPにおいても、パッチ当てをプラグインのような機構で実現しているので、そんなに特別なわけではない。

【2-4】もう一つは、Redmineは「プラグイン機構＝ソフトウェア本体を汚さずにソフトウェアを拡張する機構」の特徴を持つことで、Redmineコミュニティ自身が活発になりやすいこともあるだろう。

日本のRedmineコミュニティではプラグイン開発者が多い、という特徴を以前、@agilekawabataさんが指摘していた。

Redmineが日本人好みのツールであるという仮説part3～日本のRedmineコミュニティにはプラグイン開発者が多い: プログラマの思索

この意味は、日本企業はRedmineを自分たちの組織にあわせてカスマイズしたがるので、プラグイン開発者を必要としていることだ。
そして、そういうプラグイン開発者が日本のRedmineコミュニティには結構多い。

OSSの日本人Redmineプラグイン開発者として、@akiko_pusuさん、@tkusukawaさん、@haru_iidaさん、@onozatyさんたちがすぐに思い浮かぶ。
また、日本企業でも、アジャイルウェアなど、Redmineプラグインを専門に開発するSI企業も結構いる。

そういうプラグイン開発者や開発ベンダーは、RedmineというOSSコミュニティの活動にとても貴重な人達だ。
なぜなら、彼らはRedmine本体に取り込まれなかった機能を無償・有償でプラグインを公開してくれており、ユーザも恩恵を受けられるからだ。

また、彼らはRedmineの機能改善や利用事例に関するニーズも多数保持しているだろう。
そこで得られた知見も多いに違いない。
そして、実際、そういう知見をRedmineコミュニティで発表して、ユーザと共有してくれている。

そんな事を考えると、プラグイン機構というソフトウェア設計は、OSSソフトウェア本体を汚さずにOSSコミュニティを活発化させていくために必要な特性と言えるのだろうと思う。

つまり、柔軟なソフトウェア設計は逆に、OSSコミュニティという組織構造に良い影響を与えているわけだ。

【3】「Redmineは組織構造に従う」「柔軟なソフトウェア設計はOSSコミュニティを活発化させる」という二つの経験則は、正直面白い。

似たような経験則として、逆コンウェイ戦略「望ましいアーキテクチャに合わせて、アジャイルな開発チームを作る」という話もあった。

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

これ以外にも、Redmineインスタンスとプロセスの密接な関係もある。
「唯一のRedmineインスタンスで組織内のプロセスを標準化させる」という観点と、「それぞれの開発チームの組織文化や開発プロセスに合わせて、あえて、Redmineインスタンスを複数個立てて運用する」という観点の二つのやり方がある。

Redmineインスタンスとプロセスの関係～Redmineは組織に従うのか、Redmineに合ったチームを作るべきか: プログラマの思索

Redmineインスタンスはチームの組織文化や慣習を表す: プログラマの思索

どちらが正しい、というのではなく、それぞれの前提条件、組織の状況に応じて、コンテキストは変わる。

今の僕の興味は、Redmineのような柔軟なOSSソフトウェア、それを運用する組織構造やプロセスとの間に、どんな関係があり、どのようなコンテキストが発生しているのか、を経験則として抽出して、その本質を探ってみたい、と思っている。