コンサルティング業界就職☆2008コミュの前半部：会社におけるオープンソース開発の提案　（endeworks牧氏）

perlの世界でクローラーのプログラミングや、バインディングなどを行っております。今回は技術的な話はあまりしません。哲学・コミュニティが全体としてオープンソース。一般的にビジネス的な話が多いが、お金・作業効率・TCOなどは重要ではあるが、あまり好みのネタではない。仕事場でオープンソースに参加しやすい環境を今回は提言したい。それによって技術力の底上げにつながる。社内からまわってくる仕事は受身になりがち。それはしょうがない面もあるし、自己保身という面がある。確立した技術を使って保険をかけがち。こんなことばかりしているとスキルがなかなか上がらない。研修も一般的な内容が多い。じゃあ、どうするかというと、僕は技術者＝職人だと捉えている。エンジニア＝職人と捉えたときに、職人の技は授業で教わるのではなく、修行して覚えるものである。だからこそ会社で修行しやすい環境を作ることが大事。僕は会社でオープンソースに参加することを奨励している。

もともと自分はずぶの素人。ものづくりはしたいと考えていた。父が理系の大学にしかお金を出してくれなかった。不真面目なので、落第したりしていた。オープンソースの世界でいろいろやってきて、エンジニアとして食べていけるようになったので、オープンソースの効果はあるはず。会社ではQA部隊でテストをするためのツールを作っていた。自分でモジュールを書かなければならず、ウェブで検索していたら、cpanに出会った。パールで書いたモジュールを配布するための仕組みで、便利だ。これらを使って開発していた。時々バグもあるし、問題ある。時々は実装が気に入らなかったりする。開発者に直接連絡して、文句を言っても「俺はやる気ないけどやる気あるならどうぞ」といわれる。しょうがないから、自分でやり始めた。これが私のオープンソースとの出会いです。

　当時いた会社では寛容で、必要ならどうぞと言ってくれた。初めてパッチを作って、XMLを処理するライブラリ用のエンコーディング修正パッチを作った。何も分からなかったが、パッチの作り方から聞いて始めた。皆意外と親切に教えてくれた。オープンソースは敷居の高いとこだと思っていたが、大した志がなくてもできると思った。それからソースコードを見るようになった。深みにはまっていった。作り方がだんだんわかってきて、一からやってみようと思い始めた。perlの日付計算のライブラリに参加。今日の日付はマヤ暦でいうと何日なのかなどを計算するモジュラーだった。和暦は誰も実装してなくて、自分がやることになった。日本の旧暦は天文学が必須。太陽の緯度や月の緯度なども使用しないといけない。MLで天文学について質問して、本を紹介してもらったりした。とにかくその本を読んで、勉強しネットでも情報収集した。そして、MLでディスカッションを繰り返した。そして、コミュニティに検証を手伝ってもらった。フィードバックを受けて、バグを潰しての繰り返し。これは仕事の合間に２ヶ月で作った。自分が触れることがなかっただろう天文学に触れられてためになった。縁でその他のプロジェクトにも関わっていった。すごい意気込みがなくても縁でオープンソースには関わっていけた。報酬はなかったが、仕事に１００％還元できたと思っている。純粋に技術力はあがった。そのためには優れたエンジニアのソースコードを手本にして、MLでのフィードバックでソースコードの書き方を教わった。任意精度計算（天文学で）もできた。Cの勉強もできた。ソースコード管理を試せたのは、今コードを管理する側になって、良かったと思っている。

オープンソースの学んだことはソーシャルスキル。見知らぬ人と一緒に開発することになるのでオープンソースでは対人スキルが重要である。どんなに優れたアイディアでも営業力がないと駄目。自分が何をしたくて、皆にどんなメリットがあるのかを説明しなければいけない。オープンソースのエンジニアは基本的にはみんなパートタイマーだから、だれかが率先しないと停まっちゃう。リーダーシップが重要。一癖もふた癖もある人と渡り合えるようになる。コードできる人に限って、皆開発についてこだわり持っている。そういう人たちとうまくやってはじめて成功できる。

　これらの経験を通して、悪い例もたくさん目の当たりに出来る。会社の中だと悪いコードだと言えなかったりするが、オープンソースでは癖のある人がはっきりとコードの悪さを指摘してくれるので、どこが悪いのかがすぐ分かる。オープンソース参加で学べることは、技術力は前提として総合的なスキルが学べる。だからこそ、とってもよい修行の場である。また、オープンソースは失敗してもいい開発でもある。試行錯誤して行き詰ってもOKなのである。社会還元もできて、うまい構造になっている。万人にできるかというと、できないかもしれないが、部署で奨励はするべきである。会社としてプラスになる。雇用する側の人はオープンソースの特性を理解して、しやすい環境を作ってあげるべきである。１，２時間オープンソースの時間を与えるべき。そこで環境や著作権などでちょっと逃げ道をつくってあげるべき。結局はwin-winになる。是非参加してみてください。雇用している人はオープンソースに参加させてあげてください。

質問
Q,endeworksではオープンソース奨励にどんなルールがあるか？
A,使うものを制限していないので、使えるものはどんどん使ってください。ということで奨励している。

Q,特許はどう扱うべき？
A,難しい問題ですね。会社として基本ソースコードは会社のもので、合意のもとで、リリースしていくという形が現実的。一旦、審査をするところを設けておけばいい。そういうプロセスでリリースしたコードもあるが、オープンソースは汎用性の高い部分なので、著作権に関連するような部分はリリースされないので、現実的にはそれほど問題ない。

Q,ときめきメモリアルでGPLのコードを逆にコピペする問題などあったが、権利で他に気をつけるべきこと？
A,権利に関しては、エンジニアの性格によるが、僕のチームは全てのコミットをみているので管理できる。大企業に関しては正直考えていない。

Q,オープンソースの開発は遠くから見ている立場だが、オープンソースに入るのにこんなことからしたらいいというアドバイスはありますか？
A,メーリングリストを眺めているのが一番いい。関わる製品でプレーヤーの性格違っている。例えば、一人カリスマ的なプログラマーがいる場合や、明確なプロセスがある場合など。

Q,perl周辺だとどういう技術や人が必要か？
A, Perlの新バージョンのところに人が必要。10年近く開発されているのに、なかなか出てこないので新しいものつくりたい人にはおすすめ。言語の規格から仕様の実装まで一通りできるので。
しばらくメーリスを見てどういう人がいるか把握して、次にソースコードの取得方法も出てくるので、それを眺めていくと流れが分かるので頃合を見て自分も参加していけばいいのではないか。

Q,得意分野PHPとあるがパール以外のオープンソースコミュニティには参加しないのか？
A,昔はJAVAでブラウザを作ろうというプロジェクトがあったが、途中で頓挫してしまった。さっき話したXMLの処理ライブラリももともとはCで出来ているライブラリの上にPerlがあったので、その辺りには手を加えたことがある。ただ、基本的にはパール周りが多い。

Q,最初にXMLパッチを作ったとき、同じ会社でオープンソースに携わっている人多数いたのか？
A,ほとんどいなかった。いても両手で数えられるくらい。

Q,その際にオープンソースで開発していくことに関して会社側からの抵抗なかった？
A,テスト部分だったこともあって、抵抗はなかった。テストできればそれでいいというスタンスだった。半分くらいできていたテスト用のフレームワークがPerlで書かれていたので、そのまま続けられた。

Q,オープンソースにコミットして成長できるという部分と参加には資質が必要に矛盾を感じるのですが？
A,プログラマーには変わり者が多く、中には他人とはやっていくのが面倒くさい人も多いので、それを考えた上での資質ということです。また職業プログラマーでやりたくてやっているわけではない人もいるので、できればやってくださいということ。少し興味あれば、そんなに壁はないので見てくださいという主旨です。