未来のいつか/hyoshiokの日記

hyoshiokの日々思うことをあれやこれや

OSS開発者の実践的教育プログラムとキャリアパス

基盤系プログラマの実践的教育が必要だ(http://d.hatena.ne.jp/hyoshiok/20090429#p1)に、多数のブックマーク、コメントなどを頂いた。補足的な説明を。

コミュニティというのは、誕生し、発展、成長、成熟、そして衰退というような、生物と同じような過程をたどる。OSSコミュニティももちろん同様な過程をたどる。活発なコミュニティが注目を浴びるわけだが、そのようなものは例外的な存在でむしろ閑古鳥が鳴く寂れたコミュニティというのは少なくない。

持続可能なコミュニティになるためには、継続的な新規参入者が必要だ。コミュニティには強制力がないので、去るものは追えないし、コミュニティに束縛するようなメカニズムもない。参加者が自らの意思によって参加したいと思うような何がしかの魅力がない限り、タコ壷化していく。

さて、そのような前提の中で、OSS開発コミュニティを考えてみると、常に開発者は足りていないし、新規参入者も多くない。常連さんはいるんだけど、どうも内輪感が漂っていて、入りにくいし、メンバーが固定化しているので、年々高齢化してくる。マンネリ化している。というような問題をかかえているというような話をよく聞く。例外的に元気のいいコミュニティももちろんあるけど。

開発コミュニティに興味はあるのだけど、どこにとっかりがあるのかよくわからない。というような若者（別に若者に限定する必要はないのだけど）がいたとして、彼ら彼女らを意識してリクルートして、コミュニティ誘い込んで開発者の卵に仕立て上げると言うのはコミュニティにとって間違いなくメリットがあるし、新規参加者にとっても、開発に参加できてうれしかったりして、誰も損はしない。

コミュニティによって創造される価値と言うのは、個々のメンバーが創造する価値の蓄積だから、価値を創造するメンバーが増えることはコミュニティにとってはプラスだ。

その前提に立てば、開発者はほっておいても勝手に育つというスタンスはコミュニティにとって愚かな戦術だと思う。別に参加したくない奴を無理やり引っ張ってきて拉致監禁するのではなく、興味を持っている人に参加しやすくしようというだけの話である。もちろんコードを書くだけではなく、マニュアルをレビューしたり、テストをしたり、その貢献は様々であるが、開発者視点で言えば、やはり開発プロセス、バザールモデルへの実践的なガイドが必要になると思う。

別に大学だけが教育機関ではないので、コミュニティが新人を、生暖かく迎え、成長するのを妨げない、気持ちよくコミュニティで活躍してもらうような環境をみんなで創っていく。そんなイメージである。

もちろん、クラスルーム、座学ですべて学べると言うことはなくて、理屈ではわかっていても、デバッグやテストというのは、知識だけではだめで、ある種の経験や勘、センスが必要だ。だから、実習あるいは実際のプロジェクト参画などが必要になってくる。そのようなトレーニングは必ずしも大学教育の得意とするところではないかもしれないが、オープンソースプロジェクトに参加することによって、そのような実践的な経験を得ることは可能かと思う。そのエッセンスを形式知化することによって、様々なプロジェクトで再利用可能になる。

理論と実践という観点から言うと両者は車輪の両輪なので、どちらが欠けてもだめで、両方のバランスのよい関係が必要である。大学は理論さえ教えればいいという立場にはわたしは与しない。応用できない理論、実践できない理論というのは少なくともソフトウェアの世界では弱いものだと考える。

キャリアパスとしての基盤系

昔々日本にハードウェアベンダーがあって（今もあるけど）、そこでOSやらコンパイラやらを作っていた時代があった。当時、基盤系の開発をしたければ、そのようなベンダーとか電電公社とかに就職するしかなかった。80年代から90年代、そのような会社のコンピュータビジネスは、ご承知のとおり、UnixワークステーションやPCに置き換わってしまって、国内でがっつり基盤系ソフトウェアを作る職場があっという間になくなってしまった。RDBMSを作りたければOracleやMicrosoftやIBMへ転職するくらいしか職場はなくなってしまったのである。多くの人にとって現実的ではない選択肢だ。

オープンソースソフトウェアの時代になって、仕事としてMySQLをいじったりPostgreSQLをいじったりできるようになってきた。もちろん多くの場合はSIの現場で部品としてそれを使うというのがほとんどだろうし、単に部品として使うのであればOracleやSQL Serverを使うのとそれほどかわりはしない。

ところが、オープンソースの場合は、何か問題があれば、ソースレベルでトラブルシューティングをしたり、どうしても性能が出ないときに内部実装の観点からワークアラウンドを発見したりすることが技術力さえあればできるのである。多くの技術者はさすがにRDBMSのソースコードにまでは手を出さないし、PHPの文字コードの処理に不満があったとしてもソースレベルで変更したりはしない。それでも、徐々にではあるがちょっとしたバグフィックスであったり、性能問題があるコードにパッチを当てたりする人は出てきている。

mixiやGREEやLivedoorの中の人がMySQLやPHPやPerlをちょこちょこいじっているというのは、自社のサービスを安定的に稼動するためには当然のことで、それは趣味でやっているのではなく仕事でやっている。

せっかくRDBMSや言語処理系をいじれるようになっても仕事がないと考えているのかもしれないが、実はそんなことはなくて、あるところにはあるのである。もちろん、素人がほいほい入れるようなところではなし、数も多くはないが、そのような基盤系技術者を必要としている職場が日本にもある。シリコンバレーになんか行かなくても十分食っていける、技術力さえあれば。

RDBMSのエンジニアを募集するときに間違っても未経験者可なんてことはありえないので、OSSの世界で思う存分才能をアピールして、パッチなんかをがしがし投稿して、華麗なる転職をするというのがWeb2.0的なエンジニアの未来像である。