第9回 角谷信太郎――「スーパーマンである必要はない」
岑康貴（＠IT自分戦略研究所）
赤司聡（撮影）
2009/3/30
 |
| 角谷信太郎（かくたにしんたろう） 永和システムマネジメント サービスプロバイディング事業部 チーフプログラマ 1975年2月19日、大阪府出身。1998年 立命館大学法学部卒業。「『楽しさ』がシステム開発の生産性を左右する」と信じて、アジャイル開発を現場で実践するテスト駆動開発者。日本Rubyの会の理事を務め、日本最大級のRubyカンファレンス「RubyKaigi」の運営に携わっている。 |
■うまく回るように、全体を見る
「Rubyを使って、お客さまにとって価値のあるシステムを届けたい」と以前から考えていました。2年ほど前から実際にRuby開発チームのチーフプログラマとして働いています。わたしの任務は「プロジェクトが失敗しないようにすること」。お客さまに対するヒアリングから、見積もり、メンバーのマネジメント、実際の開発まで、「危なくなりそうなところ」をケアするようにしています。全体としてうまく回っていくようにするのがわたしの仕事です。
もともとRubyやアジャイル開発が大好きでしたが、夜や週末の趣味でしかありませんでした。これを「昼にやる」、すなわち「仕事にする」には、ビジネスとして成立させないといけないわけです。
ビジネスとテクノロジはつながっています。「Rubyを使いたい」「アジャイル開発をしたい」というのは、それによって「お客さまにいまより喜んでもらえるはず」という確信があるから。単にその技術を使いたいから、ということではないんです。
わたしを含め、同僚の何人かはずっと「Rubyやアジャイル開発は良い」といっていたのですが、「お客さまに採用してもらうのは難しいよね……」とも思っていました。ところが、ある日「Rubyでやろうぜ！」と声を上げる人が現れた。みんな「待ってました」というところですね。
もちろん、最初から「昼間の仕事」にできたわけではありません。しばらくは定時後に集まって作戦を練る活動が続きました。営業メンバーや事業部長に対して、どうやったらRubyで仕事が取れるかを話したり、Railsがどういうものなのか、デモを混じえて説明したりしました。
どんなことであれ、組織の何かを変えていこうとするには、大変なエネルギーがいります。正直にいえば、こうした社内ネゴシエーションを面倒くさいと思うこともあります。
実際に採用に至ったとしても、何もかもがうまくいくわけではありません。でも、「これで自分たちの未来の仕事を作るんだ」と志を同じくする同僚、仲間がいたから、頑張れているんだと思います。
■小規模チームで開発
Javaで開発していたころは5人から10人くらいのチームが多かったのですが、現在は2人から4人くらいの小規模チームで開発することが多くなりました。Rubyだとこの規模でも、1〜2週間のサイクルでお客さまに対して、目に見える形で成果を出せます。コミュニケーションの面でこれはとても強力です。
チーム開発では「個人差が大きい」という当り前のことを忘れないように気を付けています。Rubyの場合は特にそうなのですが、各自のスキルの差が顕著にプログラムに反映されます。そのため、個々人のスキルの把握を常に心がけています。
メンバーのスキルアップに関しては、ペアプログラミングが有効だと思っています。わたしがペアプログラミングの際に注意しているのは、単に技術だけを伝えるのではなく、Rubyやアジャイル開発での「考え方」も合わせて知ってもらえるように話をすることです。
それ以外にも、プロジェクトをまたいだ社内ミーティングを週に1回開催して、困っていることなどを話し合ったり、社内IRCで情報共有を図ったり……。1つ1つが小さなチームなので、チーム内では完結できないことが多いんですね。その分、ほかのチームとも情報を共有して、利用できるものは利用するというスタンスで進めていきます。
■スーパーマンである必要はない
優秀な人は「1人で何でもできちゃう」んですよね。例えば最近のWeb系開発者界隈（かいわい）を見ていると、スーパープログラマとか、すごいギークとか、スーパーマンみたいな人が出てきている。
でも、ソフトウェア開発って、わたしを含めた「普通の人」が多い。普通の人たちだって開発はできるんです。1人で全部はできないけど、チームを組めば開発できる。
個々人のプロフェッショナルとしての鍛錬が必要ない、といっているわけではありません。でも、スーパーマンである必要はない。「ソフトウェアを作って、お客さんに届ける」のに、突出した何かがなくてもできるやり方がある。そう信じています。
アジャイル開発は「人は学ぶ存在である」という前提の上に成り立っています。例えば新しいプロジェクトに参加するに当たって、最初は分からないことだらけなわけです。「何を作るの？」「作り方は？」「仕事の進め方は？」という具合に。でも、「人間が学ぶ存在なのであれば、学ぶことでそれができるようになる」のです。
学んで、できるようになるために重要なのが「フィードバック」だと考えています。どうやると失敗して、どうやったらうまくいったか。それをフィードバックして共有し、開発プロセスのパターンを改良していくのが大切です。
そうやって作り出されるのは、スーパーマンには頼らない「チームなりの上手さ」や「総合力としての強み」です。こういったものは、チームでなければ発揮することができません。
それに、1人で開発していると、くじけそうになったときに誰にも頼れない。ほかにも、技術的な問題で深みにはまったときに、1人だと戻って来られなくなってしまうことがあります。少なくともわたしはそういうタイプなので、「1人でやっちゃえばいい」なんて思ったことはありません。
■イベント運営もソフトウェア開発も同じ
Rubyコミュニティって、当たり前ですが、当初は完全に開発者のコミュニティで、すごいプログラマが集まっているような場所でした。わたしはプログラマとしては三流だし、「○○を作った角谷です」みたいな代表作もない。なので、ずっとRubyコミュニティにあこがれはあったものの、どうやったら絡めるのか分からなかった。ファンというか、ただのミーハー。「いつも利用させていただいています」という感じですね。
ところがあるとき、「日本でもRubyカンファレンスをやろう」と高橋さん（日本Rubyの会 会長の高橋征義氏）がいったらしい、と卜部さん（卜部昌平氏。Ruby1.8系列のメンテナの1人）のブログで知りました。そのときに思ったんです。「それなら、わたしでも貢献できる！」と。
勤務先がコミュニティ活動に積極的にかかわる社風のある会社で、「オブジェクト倶楽部」のようなイベント運営の経験もそれなりにありました。イベント運営のノウハウならわたしにもあるから、手伝わせてください、と自ら手を挙げました。
かくして「RubyKaigi」にかかわるようになりました。初年度は一スタッフとして、次年度からは運営を仕切るようになりました。
イベント運営も、ソフトウェア開発も、考え方はまったく同じです。どちらもチームで取り組むプロジェクトですから。
■「人は学べる」という信頼
RubyKaigiのようなイベントの運営は、基本的にボランティア。でも、イベント運営を手伝いたいと思っている人は、案外たくさんいるんじゃないかと思っています。なぜなら、自分がそうだったから。
そうはいっても、なかなか自分から入ってこられないという人もいると思います。人手は常に不足しているので、「参加したがっている」という雰囲気を漂わせている人に声を掛けるようにしています。
これは普段の仕事でも同じかもしれません。基本は「相手を信頼する」こと。あの人にこれを依頼したら、きっとやってくれるんじゃないか。あの人はきっとこういうことには前向きに取り組んでくれるんじゃないか。あの人はこれをやったことはないけど、任せたらきっとうまくやってくれる。そんなふうに考えて、種をまくイメージです。
繰り返しになりますが、重要なのは「人は学べる」という前提を信じられるかどうか。任せたら、信じる。「任せたんだから、自分の期待する成果と同じものを出せ」というのは間違っているけれど、思ったよりひどいことにはならないものですよ。
| » ＠IT自分戦略研究所 トップページへ |
＠IT自分戦略研究所は2014年2月、＠ITのフォーラムになりました。
現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。
これからも、＠IT自分戦略研究所をよろしくお願いいたします。
