
第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自分戦略研究所 今週のリーダー バックナンバー
- 第1回 ぼくは「引っ張らないリーダー」です
- 第2回 「プログラマの自分」と「経営者の自分」は矛盾しない
- 第3回 生粋のプログラマが体得、人を変えるリーダーシップ
- 第4回 ライオンになれなかった雑食系リーダー
- 第5回 リーダーは、メンバーの目指すゴールを理解すべし
- 第6回 生意気な「部下肌」から、部下を守るリーダーに
- 第7回 メンバーをプロファイリングするための10個の軸
- 第8回 参加者の成長を見守る、Shibuya.pm 2代目リーダー
- 第9回 角谷信太郎――「スーパーマンである必要はない」
- 第10回 きつくいわない命令もしない。むしろ文句をいってくれ
- 第11回 サイボウズの開発部長は、部内で5番目にエラい
- 第12回 不況下こそチャレンジを。客員起業家 尾藤正人の挑戦
- 第13回 キャラクターの生死を懸けて新技術を模索する
- 第14回 クックパッドの技術責任者が語る「3つの隠し味」
- 第15回 不可能を許さない超戦略的リーダー
- 第16回 相手を「気持ちよくだませる」リーダーになれ
- 第17回 「話し掛けやすい雰囲気作りを意識しています。」
- 第18回 「それはエンジニアの仕事じゃない」なんて壁をつくるな
- 第19回 個性派エンジニア集団の信頼を得た「話の分かる男」
- 第20回 ITが組織を改善する時代、リーダーの使命はたった2つ
- 第21回 誰にも依存せず、新しいものを生み出す会社でいたい
- 第22回 牧大輔「モノ作りにこだわればこそリーダーを目指せ」
- 第23回 事業立案から開発まで。グリーのリーダーは全部やる
- 第24回 HOWS 庄司渉の“軽い結び付き”
- 第25回 開発に専念し続ける取締役、モバゲー川崎氏の戦略
- 第26回 僕は教えない。問題点に気付かせる
- 第27回 「変わっていかなければ」。日本Rubyの会 会長の葛藤
- 第28回 人を“その気にさせる”MSエバンジェリストの管理術
- 第29回 「技術一筋」が「マネジメントも面白い」に変わった理由
- 第30回 ウノウラボを作った男の「揺るぎないゆるさ」
- 第31回 インターバースの夜明けを信じ、突き進む
- 第32回 システム開発の主役「バイリンガル技術者」育成計画
- 第33回 Rubyを支えるYuguiの自信 「最後にはわたしがいる」
- 第34回 「不採算プロジェクトは俺が防ぐ」技術責任者の決意
- 第35回 「自分で自分の面倒をみる人が得をする」組織づくり
- 第36回 良いリーダーは笑いとつかみのツボを心得ている
- 第37回 新規事業のリーダーに求められる決断力と勇気
- 第38回 はてなのインフラを支える「ビジョン」と「数値化」
- 第39回 空賊一味のような「職人エンジニア集団」を作る試み
- 第40回 クララオンライン 家本氏「トッププレーヤーを意識せよ」
- 第41回 技術者は技術に専念。ただ、ビジネスにも興味は持て
- 第42回 30分でやると決めたら30分でやる、「いい訳無用」
| iPhoneアプリは外注? いやオレらが作る! 社内エンジニアに“檄文” 開発秘話公開 公開後は酷評も、会社は理解。正式プロジェクト発足でバージョンアップへ |
| 【転職体験談】「もっと多くのユーザーに使って欲しい」⇒ mixiへの転職に成功! 8年間のSIer生活で得た経験とスキルを生かして転職活動。評価のポイントはどこ? |
| 【経営戦略】⇒「いつか勉強しよう」ではなく「いまこそ勉強すべき」スキル 50%のユーザー企業が「戦略を立案できるIT技術者」と仕事をしたがっている |
| 気になる「社会人大学院」という選択肢 仕事との両立は本当に可能? 独学とは何が違う? 実際の学生・卒業生6人に聞いた |
|
|
| 1日1問、模擬試験問題をメールで届けます | |
| ITスキル研修4000件、最新情報の検索できます |
スキルアップ/キャリアアップ(JOB@IT)
スポンサーからのお知らせ
- - PR -
| ◆ iPhoneアプリは外注?いやオレらが作る! 社内エンジニアに“檄文” 開発秘話公開 New! |
||
|
◆ 【転職体験談】mixiに転職したエンジニア 8年間のSIer生活で得たスキルとは何か? New!
|
お勧め求人情報
| ◆クライアント企業から求められる人材 ⇒IT技術と経営戦略を併せ持つ「戦略家」 New! |
||
| ◆気になる社会人大学院。興味はあるけど仕 事と両立可能?実際に通った6人に聞いた |
||
|






「秘密のファイル世界デビュー」――日立システムがセキュリティかるた大会