最近、ウェブやソーシャル系ブログなどで何かと話題に上る「オープンソース」。

僕は典型的な文系人間なのですが、ひょんなきっかけから、あるオープンソースプロジェクトに関わっております。

オープンソースというと、どうしても「プログラム」「技術系」のイメージが強いのですが、ばりばり文系の自分がオープンソースに関わって気づいたこと、感じたことなどをかいつまんで書いてみます。

■ 自分のスペック

以下、僕自身のスペックです。

• 関わっているオープンソースプロジェクト
  ウェブCMS。LinuxもしくはWindowsとApache、MySql、phpで動作する。典型的なLAMPアプリケーション。(Movable Typeにあらず)
  
  
• 関わった経緯
  2003年ごろからCMSの仕事に携わっていたが、プロプライエタリなソフトビジネスに疑問を感じ、オープンソースのCMSの情報調査をしていた。
  そのときに出会ったあるCMSの出来が素晴らしく、ウオッチしたり掲示板に投稿しているうちに、コミュニティメンバーと親しくなっていく。
  展示会や翻訳のお手伝いをしているうちに、本格的に手伝おうと思い、モデレーター兼アメリカの開発メンバーとのコミュニケーションを担当。
  つきあいは、ユーザーとして2年半、モデレーターとして1年。合計3年半ぐらい
  
  
• 自分のスペック
  大学は文学部。仕事は営業、マーケティング畑を1０数年。
  
  Linux(Vine、ubuntu、CenｔOSなど)のインストールとセットアップはできる。
  
  Apacheの設定（バーチャルホストの設定や同時アクセス制限などのチューン）、phpの設定調整、cpanから必要なモジュールをインストールするなどはできる。
  
  プログラムは、人のコードを見て、簡単なアレンジができるぐらい。
  
  Perlは、MTのプラグインを作って、オブジェクト指向の概念が理解できた。
  
  phpは、最近pearの使い方が分かった。
  
  典型的な文系人間。高校時代、数学・物理・幾何学などが大の苦手だった。大学の専攻は東洋哲学（老子とか）

■ 普段の活動

僕がやっていることを大まかにまとめると、以下のような感じになります。

• 掲示板の管理。議論や討論は基本的に当事者同士の調整に任せているが、議論があさっての方向に行って個人攻撃になったり、個人情報や第三者の誹謗中傷があった場合に対処を行う。そのほか、活動に参加している方々へウェルカムメッセージを行うなど。
  
• 展示会やイベントの協力
  オープンソースカンファレンス他、諸々の展示会などがあった場合、説明員としてソフトの説明を行ったり、搬入や搬出を手伝ったりする
  
• 本家パッケージの言語ファイル日本語化
  本家が開発するプログラムの英語言語ファイルを日本語化。
  
• 日本→本家の連絡、改善要求、仕様調整。
  現在はここがメインの仕事。日本ユーザー会の活動に伴い、本家のメンバーに提案を行い、調整する。 また、英語圏と日本語圏（2バイト文字圏）との間に発生する諸々の不具合や要求をコア開発メンバーに提案、改善要求をする。
  日本ユーザーが独自に作った有用な改善プログラムを「どこが素晴らしくて、採用するとどんなメリットがあるか」をロジカルに説明して、本パッケージに採用してもらうなど。
  
• 本家→日本コミュニティへの要求整理と対応
  本家の開発メンバーから「これこれやってほしい」みたいな依頼が来る。依頼内容を翻訳、真意を確認して、日本のユーザー会で対応可能な人を探したり、情報を取りまとめて連絡する。
  
• デバッグと改善提案
  プロト版を利用して、気がついた箇所を日本のユーザーたちと共有、バグと思わしきものは日本国内で直してフィードバックしたり、「ここがバグってる」とレポートを入れる
  

とまあ、こんな感じになります。一般の企業で言うと「雑用」「交渉窓口」と「クオリティ･コントロール」、「マーケティング」を合わせたような感じでしょうか。

一言で言うと「コミュニケーター」的なことをやっています。人と人とのコミュニケーションを手伝ったり、調整したりしている感じです。

ただし、基本的には自分が勤める会社の業務時間外に行っているため、仕事ほど時間やエネルギーを注げません。また、2児の父親であるため、子育てや家族の仕事に結構時間を使っています。 自分で時間を作れる範囲での対応を行っています。

■ メリットとモチベーション

現在、僕自身は、このCMSを使ったビジネスをしていません。僕が現在、ビジネスで使っているのは、Movable Typeと他の複数システムですが、自分が参加しているこのシステムは（主に会社の都合上）使っておらず、将来的にも使わない可能性が高いです。

「このシステムはビジネスに適していないのか？」というと、全然そんなことはなく、このシステムを利用してビジネスをしている人・企業は多いです。

僕自身は、このオープンソースプロジェクトに関わることで、直接ビジネス的なメリットを受けていません。

じゃあ、なんで参加しているのよ・・・というと、主に以下のような事柄によります。

• 技術的には結構尖ったことをしているのに、初心者歓迎なコミュニティの雰囲気
• そこで知り合った人たちの人柄。話していると非常に勉強になる
• 英語力の向上。僕は海外に滞在したことが無く、仕事上で英語を使うことも無いのだけれど、このコミュニティに関わったことで英語力がぐんと伸びた
• オープンソースの現場を体験できる

総じて「自分の引き出しを増やす」こと、「自分にとって非常に勉強になることが多い」ことがメインのモチベーションとなっています。

■ 「自分ができることを探す」ということ

このソフトは魅力的だったのですが、僕自身はプログラムが本職ではありません。
じゃあ、自分は何もできないのかな？とりあえずユーザーとして、使えばいいのかな？

・・・いろいろ考えて、「せっかくだから、他の人が手をつけてないことで、自分ができることがあったら手を上げてやってみよう」と考えたのです。

例えば、海外のユーザーさんにインタビューして、意見を聞いて、それを日本語訳してメンバーに見てもらったり。

例えば、営業的な観点で「僕ならこういう使い方があると思う」と、営業提案のサンプルを書いてみたり。

例えば、「他と比較したときに、こんなところが足りないので、強化するともっと良いのに」と意見を書いたり。

「とりあえず」自分にできることを、時間があるときにやってみました。
そのうち、少しづつ知人が増え、気がついたら頻繁に意見交換をしていたのです。

たまたま参加メンバーが、あまり英語が得意でなかったため、技術情報について僕がつたない日本語訳をすると、とても喜んでくれたりしました。 英語の情報をかいつまんで日本語訳していくうちに、いつのまにか「英語圏の人間と交渉するならあいつだ」と思われたらしく、知らない間にコアメンバーと日本コミュニティの橋渡しのようなことをするようになっておりました。

つまり「今の自分ができること」を探して、それを少しづつ実行しているうちに、いつのまにか「居場所」ができていた、という感じです。

オープンソースプロジェクトでは、特にこの「自分ができることをやる」という姿勢が、非常に大事な気がします。かつて、アメリカの大統領、J・F・ケネディがスピーチで「Not ask what the country can do for you, but ask what you can do for your country」と語りましたが、そんな感覚でしょうか。

■ 伽藍とバザールと「コミュニケーションコスト」

オープンソースの開発手法については、有名な「伽藍とバザール」という概念があります。

詳細はエリック・レイモンドの文章をご覧いただくとして、簡単にいうとこんな感じです。

• 伽藍・・・英語では「Chatedral（カテドラル、大聖堂の意味）」。設計書に基づき開発を進めていくこと
• バザール・・・みんなでわいわいと議論をしながら開発を薦めていくこと。議論の過程でより良い、メリットのある意見が出たら、設計書に無くともそれを採用していく。議論と共に設計書が有機的に書き換わるイメージ

オープンソースの世界では、圧倒的に「バザール」方式が主流です。誰かが有用なプログラムを書いたら「それ採用！」ばかり、次の日にはパッケージ化されている、というのもよくある話です。

バザール方式は、「誰もが参加者」になり、誰もが「核」「中心人物」になれる世界でもあります。

このとき、参加者みんなが自己主張を強め、自身のアイディアを採用させるために「エゴ」を突き通すと、プロジェクトは前に進みません。

そういった事態を避けるために、「コミッター」という、フィルタリングの役割を果たすメンバーが存在するのですが、採用・不採用の論拠がうまく伝わらない場合、相互不信が生まれます。参加者が増えれば増えるほど、この「コミュニケーションコスト」が問題になります。ひどいときには、議論だけが延々続き、プロジェクトが停滞したり、協力者が離反することも良くあります。

バザール方式のプロジェクトは、「コミュニケーションコスト」を無視できないのです。

そんなときに、潤滑油となるコミュニケーターが存在することで、このコミュニケーションコストや摩擦を最小限に抑えられることがあります。

「コミュニケーター」あるいは「ファシリテーター」の存在は、この「コミュニケーションコスト」の解決のために、非常に重要なのです。

■ もっとプログラマー以外の人間が、オープンソースに関わればよいのに

インターネット上で、オープンソースに関わる人、あるいはオープンソースに関するブログや文章を書く人たちは、圧倒的に技術畑の人が多く、あまりそれ以外の人間は見当たりません。

僕は、もっともっと、プログラマー以外の人間、たとえば営業系・マーケティング系の人間が、オープンソースプロジェクトに関わればよいのに、と思います。

オープンソースプロジェクトに関わると、プログラムを書く人の偉大さが良く分かります。無の世界から形あるものを作り上げるエネルギーは、並大抵のものではありません。

逆に、「その価値を一般に伝える」な行動、あるいは「参加メンバー間の意見を調整するファシリテーション」のような動きは、往々にして後回しにされがちです。

こういった「プログラミング」ではない活動だとしても、「自分自身の気づき」や「コミュニティの活性化」に繋がるような動きができるのであれば、それは立派な「オープンソース活動」であると思うのです。

だいぶ長文になってしまったので、続きは次回に記述させていただきます。