さん)の講演を聴いた。エントリを書こうという気になった。このエントリは講演メモや浮かんだ疑問、その後の議論等を記したものであり、すっきりとした結論は無いのでご注意。公開しているだけでは使われない。メンテナンスも行われない。やりとり常に英語を使う。見ると、見た瞬間に使う気が無くなる。英語のみを使うという意思が必要。却下する勢いでも良い。なにより英語を使うということは、コントリビューションを受け入れます、という意思表示になる。方が注目されやすい何であっちの方が......と心が濁る考えるな有名だから広まっているのではなく、それなりに叩かれ磨かれているから注目され評価されるだから気にするな。開発の活発さの維持と良いソフトウェア設計の間には緊張関係があるのだろうか?この講演を聴いていて心を揺さぶられると共に、後半になるにつれて疑問が首をもたげてきた。開発の活発さの維持と良いソフトウェア設計の間には緊張関係があるのだろうか?」という疑問だ。連なる「自分がやること/やらないことがハッキリしている設計が良い設計である」というような価値観のことだ。コードベースの小ささのことではなく、設計理念として小ささ、少なさ、統一感を志向している様と考えてもらえば良いだろうか。言語が相当するだろう。当日は「ソフトウェアとして小さく美しいこと」と表現したと思う。見るエレガンスは、力とシンプルさの組み合わせから生まれる。エレガントなコードは、ただ正しいだけではなく目に見える透明な形で正しい。コントリビューションを意識的にいざない、そしてそれらを積極的に採用するスタイルを採ることになる。ところを気にしたりする。開発にバイアスはかかっているかしかし、それは結果的にソフトウェアの構造をゆがめることにつながらないだろうか。活発さを志向するあまり、機能やコードベースの肥大化を招いてしまい、統一感のある小さく単機能なソフトウェアの姿を保てなくならないだろうか。開発にそのようなバイアスがかかるのであれば、そこには構造的な問題、不幸な構図があるように見えてしまう。さんのエッセイ「Noといえることの大事さ」の一節だ(本書の日本語訳を出すにあたりエッセイを依頼したら快諾いただき、二本も書いてくださったうちの一本だ)。できるようにしてくれ」という要望が出てきます。実際にそうした機能やオプションが欲しいとおもっているのは、ごく一部であるにもかかわらず、声の大きいユーザからの要望を無視することができず、忠実に応えようとするあまり、あなたはそれをすべて実装してしまいます。ユーザからのフィードバックはうれしいものですからね。公開したソフトウェアでとくにおこりがちなことです。してあなたのソフトウェアは、ほとんどのユーザが使わないようなニッチな機能と、それを有効にするための複雑怪奇な設定画面または設定ファイルが必要になり、またそれによってメンテナンスがしづらく、バグのでやすいソフトウェアになってしまいました。よばれ、ソフトウェアが破滅に向かう第一歩(あるいはもう手遅れ)の状態になっているといえます。した悲劇を避けるポイントはただひとつ、そうした要望に「No」といえる勇気です。いえることが、結果としてよいデザインやシンプルさを達成する原動力になります。見る例えば上手く設計できたソフトウェアがあるとして、「これ以上減らすところがなく、実質的に完成していて、手を入れるところもほとんどない」ことによって「開発が活発ではなく、メンテナンスされていない」というイメージを与えてしまい、それが悪い評価につながりかねないのは、不幸なことではないだろうか。以上)と活発にメンテナンスしてますというアピールを両立させるのがなかなか難しい問題、と言い換えても良いかもしれない。完成してしまうからだ。バージョンを上げていくくらいしかアピール手段がないが、小さく無矛盾である場合はその頻度すら低くなってしまう。削るものが何もなくなったときである。とって開発の活発さが文字通り死活問題であるならば、その開発の活発さと設計の統一感を両立する手段はあるだろうか。たまらず、質問してみた。開発と良いソフトウェア設計の間には緊張関係があると思いますか?」から始めたが、この単文では意図が間違って受け取られる可能性があるので、本エントリでは少し表現を変えた。実際当日はかなり長めの質問になったが、モリスさんはもちろん質問の意図を正確に把握してくれた。2015t_wadaさんかな。仰るとおり、構図的な問題はある。開発における活発さの維持を志向すると、ソフトウェアのエントロピーは増大し、肥大化し不格好になる。多くのユーザ、ユースケース、コントリビューションを得ることと、ソフトウェアとして小さく美しさを保つこととを両立させるのは難しい。すると、やがて同じ事を綺麗に上手くやる後発プロダクトに打倒されることもある。それは開発者コミュニティの新陳代謝にはなる。コントリビューションのチャンスがあるからだ。社会ときれいなソフトウェア設計との間には、やはり緊張関係はある、ということになるのだろうか。2015あと、ソフトウェアは使われることで育てられ、磨かれることも忘れてはならない。誰も使わないソフトウェアは、本当に問題を解決するのか実証できていないようなものだ。プラグイン機構による開発者コミュニティへの質的な転換その意味で、モリスさんの講演にあったようにソフトウェアの構造に「プラグイン機構」を設け、ユーザコミュニティから開発者コミュニティへの質的な転換を図るのは、ソフトウェア設計からエコシステム設計へとつながる、非常に重要な考え方であると再認識した。組織構造がソフトウェアの構造に影響を及ぼすというのは最近よく聞く話だが(コンウェイの法則)、ソフトウェアの構造がコミュニティの構造に影響を及ぼしうるというのは重要な気づきであったと思う。プロダクトがメジャーになればなるほど、コントリビューションを取り入れつつ、全体の整合性は壊さないような舵取りが大事になってくるのだろう。プロダクトや言語設計者のバランス感覚や調整能力が際立つのもわかる。ツールがコンパクトで美しいことと、何かを実現するためにソフトウェアが大きくなっていくことの話。これは、両立するのは大変だよなぁと。Goのcoreとかはこのへんうまくやってるなぁという印象がある。考え方に影響を受けている。)の違いを意識し、それらを混ぜずに分けて提供できるような構造に注力している。そのような構造になっている。)に関してはコントリビュートしてくださる方々に任せるようにしている。便利さは相対的な概念であり、一人一人によって便利さの文脈が異なるからだ。