自分戦略研究所 | 自分戦略研究室 | キャリア実現研究室 | スキル創造研究室 | 生活向上研究室 | 組み込みキャリア研究室 | コミュニティ活動支援室 | エンジニアライフ | IT業界就職ラボ |

第33回　Rubyを支えるYuguiの自信 「最後にはわたしがいる」

金武明日香（＠IT自分戦略研究所）
浅井隆晃（撮影）
2009/9/28

Yugui (園田裕貴)　Ruby1.9系統リリースマネージャ　Rubyコミッタ。2008年6月よりRuby 1.9リリースマネージャ。MtF-TS。1981年生。2004年、立教大学理学研究科在学中から大手航空会社予約管理システムなどWebシステムの開発に携わる。その後いくつかのwebシステム開発に携わり、2008年から株式会社スケールアウト。著書『初めてのRuby』。http://yugui.jpにてブログを執筆中。

■「誰かがやらなければ」「ならばわたしが」

　Rubyを使い始めてから、今年で9年目になります。「Perlよりもすっきりしていて使いやすい」という噂を聞いたのが、Rubyとの出合いでした。実際、当時はあまりPerlを使いこなせていませんでした。C++で学んだオブジェクト指向をスクリプティングに適用する上で、Rubyは非常に分かりやすかったんですね。

　コミッタになったのと、リリースマネージャになったのはほぼ同時でした。2007年まで、わたしはいちユーザーとして、仕様の改善書やパッチをメーリングリストに送っていました。でも、コミッタとしては参加していなかったのです。リリースマネージャになったきっかけは、2008年のRuby会議です。

　「1.9系統のリリースマネジメントには改善の余地がある」という提案を、 ずっとしていたんですね。そうしたら、Ruby会議の会場で「じゃあ、自分でやってみる気はない？」とまつもとゆきひろさんに誘われました。「はい、やります」と、その場でお受けしました。

　 もともと、Rubyにはあまりマネジメントをする人がいませんでした。まつもとさんはマネジメントをするタイプではないし、笹田さんも細かな作業をこなすタイプではない。「リリースマネジメントは誰かがやらなければならない」という共通認識が、皆の間で強くありました。

　「誰かがやらなければならない、だったらわたしがやろう」と思ったのです。Ruby会議の後、すぐにリリースマネージャとしての仕事を始めるようになりました。

■「誰が何をしているか」全体像を把握する

　現在、Rubyのコミッタは63人います。コアメンバーは10名ほどで、全員が日本人です。

　 リリースマネージャは「リリースをきちんと行う」ことが使命です。そのためには、「スケジュール管理」が特に重要です。誰が何を実装しているのか、何をやろうとしているのかという「全体像」を把握しておくようにしています。

　 全体像を把握するため、メーリングリストやカンファレンスはくまなくチェックするようにしています。個人ブログ上の発言にも注意を払います。コミッタではない人が「こうした方がいい」という発言をしている場合は、発言者に声をかける場合もありますよ。また最近では、Ruby言語の他の実装であるJRubyやRubiniusのチームとも歩調を合わせるようにしています。
　
　皆の行動や発言を俯瞰した上で、次のリリースまでにどの仕様を取り入れて、どれを取り入れないのか、取捨選択をします。「誰が、いつ、どんな提案をしてくるか」ということについては、わたしがコントロールできるものではありませんので、わたしはリリース期日までに仕様を収束させることを第一に考えています。

■提案を取り入れる判断基準は「ユーザーの利便性」「言語の一貫性」

　コミッタによる提案を取り入れるかどうかは、「重要度」に鑑みて判断します。「重要度」の判断基準は2つあります。「ユーザーにとって必要かどうか」、そして「言語の一貫性」です。

　 ユーザーにとって必要かどうかについては、まずわたし自身がRubyユーザーとして「この仕様は必要であると思えるかどうか」と考えます。わたしはやや古めのユーザーでもあるため、10年前の文化も分かりますし、Ruby on Rails以降のユーザーのニーズも把握しています。言語の一貫性については、それぞれの個所に詳しいコミッタに、取り入れる必要があるかどうかを相談します。
　

IT業界を目指す学生必見 ★今日もせっせと業界研究★

気になる離職・転職率、 IT企業では「0.5％未満」が最多 IT企業の5社に1社が「転職・離職率」0.5％未満。80％以上の企業が「離職・転職率は10％未満」と回答している

　コアメンバーとは、よく話し合いをしますね。「何が必要で何が必要ではないのか」などの議論が活発に行われます。もし、話がなかなか収束しそうにない場合は、わたしが意見を述べて収束させる場合もあります。言語仕様の最終決定は、まつもとさんに委ねます。ユーザーの利便性については、わたしが最終的な判断を行います。

　 リリースマネージャとしての仕事は、他にドキュメント制作やバグ報告の処理などがありますね。Ruby付属の埋め込みドキュメンテーションに関しては、わたしが中心となって行っています。Rubyは全体的にドキュメントが不足しています。ドキュメント不足は、リリースの品質としてはあまり良くないことだと思っています。でも、コミッタはあまりドキュメントを作ろうとしないため、わたしがやることにしています。

■企業とオープンソースコミュニティ、マネジメントの違い

　企業におけるプロジェクトマネジメントと、オープンソースのリリースマネジメントの大きな違いは、やはり「リソース配分」ではないでしょうか。

　Rubyなどのオープンソースは、あくまでボランティアベースで回しています。もし作業が終わっていないところがあっても、リソースを割り振る権限がありません。Rubyの各部分について大まかな担当者はいますし、遅れている個所についてはメールやチャットで確認します。けれども声を掛けたところでその人に作業する義務があるわけではありません。

　 リリースする数日前に、本来なら誰かがやっているはずの仕事が終わっていなかったということがありました。「誰かやってくれませんか」と声をかけて実装しましたが、間に合わなかったために見送ったものもあります。 不確定要素は、企業内のプロジェクトとは比べ物にならないほど多いですね。

　 基本的には、リリースのスケジュールに間に合わせるようにマネジメントをしますが、本当に必要なものだと判断すれば、スケジュールの変更を行います。

　 実は、1.9.1のリリースは1カ月遅れたんですね。まつもとさんによる、大きな言語仕様の変更がありました。

　「もしここを変更するなら、リリースを1カ月遅らせなければならないですが、遅らせるだけの価値がありますか」と、まつもとさんに確認したところ、「Yes」という答えが返ってきました。その一声で、実装を決定しました。

　急な変更だったので多くのコミッタが驚きましたね。言語仕様の変更に、ライブラリのあちこちが追随しなくてはいけませんでした。間に合わないと思った分は、わたしが自分でコードを書きました。リリースは遅れましたが、「1カ月遅れるだろう」という予測どおりにちゃんと収束できたのは良かったと思います。

■「最終的にはわたしがどうにかする」

　お話してきたように、オープンソースのリリースマネジメントは、いろいろな不確定要素があります。でも、あまり不安はありません。それは、「最終的にはわたしがどうにかする」という自信があるからだと思います。

　 わたしは、いろいろな人に頼んで仕事をやってもらいます。でも、誰もやらないのであれば、わたしがやります。コミッタの皆は「良いものを作りたい」というモチベーションが高いので、わたしはあまり手を出しませんが、もし最終段階に来たら、わたしが動けばいいのです。

　 もし、わたしがひっくり返っても真似できないような凄腕の技術者をマネージしなければならなくなったら、状況は変わるかもしれません。でも幸いいまのところは、ほとんどのことは自分で勉強すればどうにかすることができるものです。また、開発メンバーがもっと増えてくれば、おそらくマネジメント方法も変わってくるでしょう。人数が増えれば、おそらくLinuxのように、ゆるい階層構造になるのかもしれません。それまでは、こうした形でマネジメントを行っていく予定です。

　2年前のわたしのように「わたしがやります」という人がいたら、マネジメント業務は喜んでお譲りいたしますよ。わたしは「こうした方がいい」という改善点を提案し続けますので。

　「Rubyを、皆が安心して使える言語にする」。そのためにわたしは仕事をしています。

» ＠IT自分戦略研究所 トップページへ

» ＠IT自分戦略研究所 全記事一覧へ

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

◆あなたのプロジェクトは大丈夫？ システム開発における法的トラブルの事例

◆気になる社会人大学院。興味はあるけど仕 事と両立可能？実際に通った6人に聞いた

インデックス