総務省が発表している（PDF:テレワーク・ＳＯＨＯの推進のための施策の実施について）は，よりゆたかなライフスタイルをめざす個々のニーズに対応し、『2010年までに適正な就業環境の下でのテレワーカーが就業者人口の２割』となることを目指しているようだ。

これによると平成17年におけるテレワーク人口は就業者人口比率10.4%、企業におけるテレワーク実施率は、

日本：１４．７％
米国：６８．９％
韓国：２１．２％

どうして日本でテレワーク・SOHOスタイルがこうも広がらないのだろうか。

総務省は、セキュリティの高いネットワークができれば，遠隔地でもテレワークができるということを何億円もかけて実証実験をおこなって研究しているようだが，なぜ日本で欧米などよりテレワーク・SOHOスタイルが普及しないのかは，セキュリティやインフラ整備が諸外国より劣るからでは決してないはずだ。

原因は複合的だと思われるが、ひとつには企業の人事評価は年功序列と会社に居る時間のかけあわせで単純に行われてきたことで、仕事を評価するちから、人物を評価するちからが落ちているからではないか。

成果を的確に評価できるのであれば、テレワーク・SOHOスタイルは問題ない。

さらに言えば、仕事内容を的確に伝える能力も低いように感じる。業務内容を伝えるのに、会って伝えないと不安だというひとが少なくない。クライアントとの折衝やアイデアだしなどでは有効だろうが、決まった業務を下ろしていくのに身振り手振りや正確に聞き取りにくいことばより、文字や図に落とし込んだものをネットで交換したほうがずっと間違いや勘違いも無く、効率が良いだろう。

テレワークあるいはSOHOスタイルで仕事を最も行いたいのは、ＩＴ技術者だろう。会社で仕事をするのも自宅で仕事をするのも、ネットで情報が繋がっているのでほとんど業務に支障はない。自宅の方が無駄な連絡業務や移動時間、さらには意味のないだらだらと続きがちな会議を削減できるので却って生産性が上がる。比較的遠隔地に住めるので住宅環境が良くなり、家族とのたのしい時間がふんだんに生まれる理想的なライフスタイルとなる。

実際、わたしの会社は渋谷に本拠地を置いているものの、3名の取締役が東京小金井・大阪豊中・新潟十日町市それぞれSOHOスタイルで働いている。バーチャルオフィスのサービスを利用しており、電話や宅配の転送サービスや時々のクライアントとの打ち合わせに予約して会議室を利用、あるいは自由に立ち寄ってインターネットカフェ代わりに使っている。連携は主に社内ＳＮＳだ。電話もほとんど使わない。これでまったく差し支えなく高いモチベーションを維持しつつ業務を遂行できている。

ＩＴ企業の場合、極端に一般企業の下請けにつながる受託開発ばかりになって、コスト削減の波により、厳しい状況が生まれているのではないだろうか。情報産業は、サービス業であっても、一方的にクライアントのわがままにつきあうスタイルを脱却し、Googleやmixiのように、自らサービスを開発して提供し、使ってもらう側にまわれば立場は一転するはずだ。そのようなサービスを行う企業は日本ではまだまだ少ない。

自身の会社も受託開発を抜け切れていないものの、オープンソースを利用することにより、最小限のカスタマイズ開発でシステムを提供している。オープンソースの利用により、将来的には完全に受託開発を脱却したいものだが。

日本SOHO協会主催のSOHO DAY 2007では、はじめてSOHO代表者会議が開催され、全国から約30名のSOHOリーダ、研究者、地方自治体のSOHO担当等が集まり、真剣な議論があった。

その会議を機に、SOHOとは何か、SOHOはどうあるべきか、SOHOへの支援はどうあるべきか、真剣に議論する日本SOHO協会SNSが生まれた。

その中で、現在様々な議論が熱く交わされているので興味がある方は参加して欲しい。

また，なぜSOHOスタイルが定着しないのか，ここで聞いてみたい。

※筆者は日本SOHO協会SNSの設置と運営に関わっている。

オープンソース活動にフィードバックは必須だ。

ここで言うフィードバックとは，バグを修正してその内容を配布元に報告したり，なにか新しく開発してそのソースを配布元へ提供するだけではなく，もっと広い意味で使っている。感想を言う，改善の意見を言う，バグ・トラブル報告をする，導入事例を報告する，開発だけでなくデザインを提供する，といったあらゆる配布元へのアクションをフィードバックと言っている。

しかしながら，配布側もほとんどの場合ボランティアなので，配布パッケージを開発して提供することで手一杯となり，フィードバックを受けやすくするWEB環境を整えるところまで至らないことが多いように思う。公開掲示板はサポート掲示板として多く見かけられるが，公開された場に書き込むのはなかなか勇気の要るものだし，そういった場ではより本音に近い意見や小さなフィードバックはなかなか出てこない。

Geeklogの場合にはSNSを導入しているので，どういったひとが日々どう活動して，どういう悩みをもっているのか，どんな気づきがあったのかが自然にわかるしくみになっており，コミュニティはいくつも立って，日々いろんな開発がそれぞれ自発的に生まれてきている。

ドキュメントはWikiを導入して，ユーザにも参加してもらっている。なにか成果がでれば，配布サイトのダウンロードセクションに直接ファイルをアップロードして公開してもらうなど，比較的簡単にいくつもの方法でフィードバックできるしくみを提供している。

そういうフィードバックを十分行える場作りができていないオープンソースの場合にフィードバックできないというのもあるだろう。

また，そもそも提供側も元は単なるユーザだった。 ユーザの裾野が広く，個々のユーザにフィードバックできるだけの時間的ゆとりや経済的ゆとりが十分なのか。ソースを公開できるほどの開発能力を持った人材なら十分社会的にも尊重されて経済的にもゆとりを持ててよいはずだと思うのだが，どうもそういう環境には無いようだ。

会社は年功序列，あるいは職務階級により，本人の能力にはほとんどの場合関係ない。いかに社内で上の位置に登るか入社とともにスタートダッシュしなければならない。

オープンソースが日本でより活用されるためには，オープンソース配布元のフィードバック受け入れ体制とともに，フィードバック側の個々のユーザ，多くは開発者なのだが，彼らの社会的基盤が必要なのではないかと思うのだがどうだろう。

だが，そういう自然発生的なオープンソースコミュニティにはぬるいところが必ず出る。

日本で成功しているのは，オープンソースをビジネスの商材として活用している会社が本腰を入れて提供している場合が少なくないだろう。Geeklogもわたしの会社の一番の商材なので，クライアントからの厳しいバグチェックを日々受けながら配布パッケージを開発しているが，もっとも力を入れているのはコミュニティの運営とフィードバックの反映だ。コミュニティで無尽蔵のフィードバック力を最大限活かしてGeeklogに貢献していくことだ。

企業がオープンソースの配布元になっている場合，コミュニティ運営によるフィードバック体制の充実により注力しなければならないのかもしれない。

前回「苦悩するオープンソースコミュ運営」をテーマにしたが，日本でまともなコミュニティ運営がなされているオープンソースは，実は数えるほどしかないのではないか。他のオープンソースのリーダやコア開発者から，オープンソースのイベント等での雑談で直接聞いた中では，ほとんどの団体で，「えっ！」と驚くような運営実体だった。

もちろんうまくいっている団体もある。

Ruby関西は毎月勉強会が開かれているそうで，いつも盛り上がってセミナーも大盛況だが，それはオープンソース自体に魅力があって，しかも運営者の努力とあいまって盛り上がっているように思う。Geeklogもセミナーやオフ会を頻繁に開いて，コア開発者が各種CMSに関わりつつもGeeklogを選んで大変な開発協力をしてコミュニティが盛り上がっている。素材の良さと運営の努力双方があわさって，理想的なコミュニティ運営になる。

重要なのは，盛り上がっている団体というのは，オープンソース自体の良さ，運営努力，この２つが両方ともうまくいっている団体だということだ。

オープンソース自体の良さだけではただ良いように使われるだけでフィードバックが疎かになる。コミュニティとしての動きができない。

一方，運営努力だけでは良い開発者が集まらない。良い開発者というのは， 同類のCMSをよく知っていながら，そのオープンソースを選んで積極的に貢献しようとする開発者だ。もし他のCMSを知って，そちらが良いと思ったら，いとも簡単に歯抜けのようにそちらへ流れていくはずだ。

オープンソースのコミュニティは，コミュニティを軸に，サポートしあったり，オープンソースソフトウェアの開発を共同で行っていく。そうやって情報共有し，情報公開してGPLの精神，オープンソースの精神をみんなで共有して助け合いネットワークを構築していくことだと思う。

そういう性質のコミュニティにおいて，中心になるオープンソースのリーダは非常に重要な役目を背負っている。全体の動きを把握して対外的にどう動くのか，主に，どのイベントに出展してセミナーを開催するのか，本をだれが執筆するのか，いつオフ会を開くのか，さらに，コミュニティの理念を共有していけるよう配慮しながらコミュニティを運営していく。自ら直接動く必要はないが，目配りだけは全方向に向いて，それぞれの方向付けをして，必要なときには軌道修正していかなければならないだろう。

技術力が突出してオープンソースに中心的に関わる場合は特に，リーダとしての立場を自覚してコミュニケーション能力を最大限に高めてネットワークを築き，良好なコミュニティ運営をすることを努力する必要があるのではないか。

また，オープンソースの場合，中心にいた開発者がボランティアで行っていたリーダの仕事を半ば放棄して仕事に専念する場合も少なくない。 しっかりと後継者を決めたうえで引退することだ。リーダにその実行力がないのなら，セカンドの人材がコンセンサスを得て引き継ぐことだ。

本家が英語で開発したオープンソースの場合，共通して言語の壁がある。これはプログラムの問題に留まらない。本家が英語圏にある場合には，プログラム内に言語ファイルが多数仕込まれていて多言語化が難しくなる傾向がある。ドイツなど，ヨーロッパ圏から配布されている場合には比較的言語が切り分けられているので安全だ。

さらに，本家における開発と日本における開発の歩調をどう合わせるか，これは英語によるコミュニケーション能力になるわけだが，日本のコミュニティに英語と開発両方の達人がどうしても必要になる。英語の能力，説明能力自体に自信が持てないのでどうしても躊躇してしまいがちだ。もちろん，わたしも含めて英語が苦手な開発者も本家の掲示板には書き込みをしたり，言語ファイルの提供など，精一杯フィードバックしているが，他の開発者と異なる意見の場合に説得していく技術が必要だ。このような場合，英語も説明能力も開発も達者なメンバーに頼ることになる。本家が主催している英語の開発者メーリングリストの量は半端ではなく，それらの情報を日本のメンバーにつたえたり，そこで日本のメンバーたちの考えを発言してフィードバックしていく。

こうやってできうる限りのフィードバックを行うことにより，本家とさらに良好な関係を築くことができる。翻訳を含め，卓越した人材が必須だ。

また，デザインのセンスは英語圏と日本語圏ではかなり違う。英語圏でのデザインをそのまま日本語圏で適用するだけでは本当に日本語化したとは言えないだろう。そこで必要になるのがデザイナーの参加だ。

つまり，コミュニティには，様々な層からできる限り多くの開発に協力してくれるユーザが必要なのだ。

その貴重なユーザを集める努力，そのユーザの声を満遍なく聞き取って意見調整してコミュニティを維持し，コミュニティを割れさせたりすることのないように調整する能力が，オープンソースのリーダに課せられているのではないか。

しかしながら，そういったリーダの役割の認識は，現在ほとんどコンセンサスが取れているとは言えないようだ。

いったいどんなオープンソースがあって，それぞれのコミュニティがどういう動きをしているのか，中心となって積極的に情報を集め，オープンソースの運営に協力しようとする動きがまだまだ鈍いように思う。

そういう動きを期待したいのは，たとえばNPO法人であるオープンソースソフトウェア協会だったりするのかもしれない。オープンソースソフトウェア協会では最近ではGPLセミナーなどよくセミナーが開かれており，リーダ同士で情報を交換するのに最適だ。

オープンソースソフトウェア協会にはGeeklogやOpenPNEなど，オープンソースのリーダが参加し始めており，Geeklogとはお互いに協賛団体として連携することになった。

そういう動きがさらに広がることを期待したい。