ABC(*1)の5日目。共通テーマは私が開発している「Risouto」についてです。
「会社で作る」ということ
昨日までのエントリで、Risolutoが生まれる前のバックグラウンドをつらつらと書いてきた。Risolutoの誕生間際の頃について、もう少しだけ。
Risolutoより前に作っていたオレオレフレームワークは、ある種「会社で使うために」作っていたという面が大きい。短期的にみれば、これは「作る」というモチベーションに対してはプラスの効果を与える結果となった。
なぜなら、ユーザグループが目の前にいる(*2)し、バグレポートや機能面でのリクエスト、使い勝手についてのフィードバックも常に得られる。運が良ければ共同開発者もゲットできる。
ただ、作ってからのモチベーション、すなわち「維持する」とか「発展させる」という方面のモチベーションに対しては、マイナス方向に作用したように思う。なぜか。使っていくうちに皆が満足してしまうのだ。「それで十分」、そう思ったときに成長は止まる。
新しい技術を取り込んだり、改善するのも骨が折れた(*3)。全くできなかったわけではないけれど、「会社の」オレオレフレームワークは徐々に時代遅れになっていった。
自分の自分による自分のためのオレオレフレームワーク
Risolutoが生まれたときというのは、そういったフラストレーションがたまっていたときだったように記憶している。もっと自由を。もっと楽しみを。そうした結果、作り始めていたのがRisoutoだった。
Risolutoとは元々音楽に関する用語で「決然と」という意味がある。「会社で使うため」ではなく「自分で使うため」のもの。そういったものを作ろうという決意表明のつもりだった。
とはいえ、どういうアプローチで作るか……という点については、それなりに悩んだ。もう何度も車輪の再発明を繰り返してきたし、すばらしいFLOSSなフレームワークが多数存在したし。モチベーションの維持に多大な影響を及ぼすからだ。
アプローチ
何かの理想型を形にするなら、既存のFLOSSプロジェクトに参加してそこでやればいい。Risolutoをゼロから作るよりも、その方が良いように思えた。ユーザはすでに沢山いるし、開発も活発だし、良いものはどんどん取り込まれていくし。
というわけで、いろいろなプロジェクトを漁ってみたわけだけれども、どれもこれも自分が参加するには不適切に思えた。
まずは言語の問題。英語でのコミュニケーションは自分にとって骨が折れた。ドキュメントを読む程度ならともかく、それ以上のことができるほどの語学力は持ち合わせてなかった。
そして目指す方向性の問題。既存のFLOSSなフレームワークは、自分にとってリッチすぎた。それらはとてもすばらしいものだ。そして便利なのは疑いようのない事実である。が、私にはそこまでリッチなものはいらなかった。
そういったことを総合的に考えた結果、既存のFLOSSなフレームワーク開発に合流するのは困難だと思った。自分のスキル的な意味でも。誰も幸せにならないだろう、と。
結果的に、車輪の再発明に勤しむ事に決めた。
何をすべきか、そしてすべきでないか
Risolutoを作る上で、「何をすべきか」という点においては、会社組織という狭い閉じたコミュニティでの常識しか頭になかった。その常識を踏まえた上で作り出すのは、非常にマズイアイディアに思えた。今までそれをやってきて、なにがしかの失敗をしてきたから。
まず最初にしたことは、既存のFLOSSフレームワークに関するドキュメントを読むこと。ソースじゃない。ドキュメントだ。もちろん、そのフレームワークが使えるレベルには至らないが、さらっと概要を把握するだけで良かった。なぜならそれらの真似をしようとしたわけではないから。ただ、「Risolutoではこれはしない」というのを決める作業のためだったから。
次に今までやってきたことの反省。特に使い勝手の部分について。「ここがこうなっていたらよかったのに」という点を洗い出した。そしてそれをどうすれば改善できるか。整理した。
その結果、Risolutoの基本設計……というか、基本概念が固まった。そのあたりについてはまた明日。
*1:アドベント・ぼっち・カレンダーの意
*2:会社で使うんだから上司や同僚がユーザなのだ
*3:会社組織として必要なものもあれば、ばかばかしいと思われるものある