_T3A9006Sponsored
Pocket

IT・ネットマーケティングの高度な専門スキルを活かし、リクルートグループが提供するさまざまなサービスのシステム開発などを手がけるリクルートテクノロジーズ。同社では日本国内での開発と同時に、海外のITエンジニアと協力しながら、納期短縮・高品質を実現するオフショア開発にも取り組んできた。

本連載では、異国の地で開発を推進してきたリクルートテクノロジーズのエンジニアに話を聞くことにより、大規模開発を成功に導く真髄に迫る。第一回は、ITマネジメント統括部 ITマネジメント1部オフショア開発2グループ※の山口弘人氏に、その経歴や仕事の魅力、業務を円滑に進める上でのポイントなどを聞いた。
※2016年3月現在

開発が“目的”となっていたSIer時代

編集部:まずはこれまでの経歴についてお教えいただけますか?

山口:私が最初にPCを触ったのは小学生の頃。私には兄がいるのですが、PC9801を持っていて、自分も影響されて兄のPCをいじって遊ぶようになったのがきっかけです。徐々にインターネットが普及しはじめた中学生時代は、地元の北海道の小さな町からまったく知らない人たちと交流できることに感動しましたね。高校生でさらにPCやインターネットへの興味が加速し、大学では音楽イベント向けにフライヤーやWebサイトを制作。さらに知人経由でWebサイト制作の依頼を受けたりもしていて、自分の中で“作る楽しみ”を強く感じていたのが、この時期です。

ITマネジメント統括部 ITマネジメント1部オフショア開発2グループの山口弘人氏
ITマネジメント統括部 ITマネジメント1部オフショア開発2グループの山口弘人氏

編集部:幼い頃から一貫してPCやネットに親しみがあったんですね。具体的に“エンジニア”を意識されたのはいつ頃でしょうか?

山口:就職活動を始めた頃は、エンジニアになることをはっきりとは意識していませんでした。最初は、大学時代のWeb制作の経験から、そのままWebデザインやディレクションの道を歩もうかと思いましたが、調べれば調べるほど「この道のプロになりたい」というほどには興味がわかなかったんです。そこでいろいろと考えていく中で、自分が何かを「一から作り上げる」仕事がしたいと思うようになりました。

その中でふと頭に浮かんだのが、プログラミング。Webサイト制作でHTMLなどを触っているのも楽しかったのですが、それだけじゃなくて、裏側のプログラムで動いている部分を正しく理解したいなと思いました。当時はまだ趣味程度で、本格的なプログラムを組んだ経験なんてありませんでしたが、就職を機に「チャレンジしてみよう!」と思ったんです。

編集部:そこからエンジニアとしての人生がスタートしたんですね。

山口:そうですね。私が最初に入社したのは、ソフトウェアの開発・販売やアウトソーシングサービスなどを手がける独立系SIerでした。入社時の希望通りWeb系エンジニアとしての経験が積める部署に配属され、まずは食品流通企業の受発注サイトを作るプロジェクトで要件定義から設計・製造までを業務の中で経験。次の業務システム開発プロジェクトではリーディング能力を養い、最終的には保守開発のリーダーも務めさせてもらいました。でも、入社から5年ほど経った頃に、自分の中で「このままで良いのか?」という疑問が浮かびはじめたんです。

編集部:それは今後のキャリアに関する疑問ですか?

山口:まさにそこなんです。確かにエンジニアに必要な知識・能力やマネジメント関連のスキルを身につけ、この先も成長できる実感はありました。でも、どこか「開発が目的になってしまっている」という違和感があって。いまの仕事を淡々とこなすだけではエンジニアとしての可能性を自分自身で狭めているような気がしたんです。自分の能力の幅や、レベルをもっと上げたいと思い、社内で新規事業の立ち上げや国際営業を経験したものの、「このままで良いのか?」という疑問は消えず、転職を検討し始めました。

数社受ける中で光明となったのが、たまたま目にした、リクルートテクノロジーズからのスカウトメール。実際に面接を受けてみて、「やっぱり自分は作る側、開発がやりたいな」と思いましたし、現在の部署長である面接官の話しぶりが、あまりにエネルギッシュで(笑)「自分もここならば、エンジニアとしての可能性を広げられるのではないか」と感じました。正直、面接が終わった頃には「絶対ここで働きたい!」と思うまでになっていました(笑)

チームが抱える“本質的な問題”を考える

編集部:その熱い思いが通じて現在の職に就かれたんですね!入社後はどんな業務に就かれたんですか?

山口:最初に手がけたのは、リクルートのサービスで使われているシステムをクライアントであるメーカーのWebサイトと連携するためのオフショア開発プロジェクトです。開発を行うのはベトナムのダナン。リクルートテクノロジーズのオフショア開発では、実際に現地に行って、直接ベトナムのエンジニアたちと一緒にチームとなって開発をします。当時、私は2つのチームのリーディングを担当しており、現地パートナーのチームリーダー2人と、2つのチームのメンバー計15名と一緒に仕事をしていました。

プロジェクトがスタートした当初は、正直なところなにをすれば良いのか分からない状態でした。要件や仕様などはもちろん理解していますが、たとえばドキュメントを渡した後、具体的にどのようなフォローがいるのか、といったように、自分の存在意義や役割をつかむ必要がありました。そこで私は現地パートナーのリーダーやメンバーと積極的にコミュニケーションをとったり、彼らの仕事ぶりを観察したりすることで、足りない役割を見つけ出しました。

端的に言えば、日本とベトナムの“つなぎ役”であり“潤滑油”ですね。ドキュメントを渡しただけでは絶対に伝わらない部分もありますし、内容によってはチームメンバーたちの状況を見ながらどう対応するか決断をする必要が出てくるでしょう。そうした役割の担い手がいなければ、チームメンバーも迷ってしまいますし、結果として開発自体が上手くいきません。そこから私は、“チームが抱えている本質的な問題”はなにかを常に考え、解決に向けた最適な方法や行動が導き出せるよう極力意識するようになりました。

編集部:“本質的な問題”の解決ですか。つなぎ役であると同時にチーム全体を俯瞰できるポジションならではですね。チームとしてはこれですべてのピースがそろった感じでしょうか。

山口:そうですね。ただし、まだ現場レベルでの問題は数多く残っていました。製造とテストが終わり結合テストへ移行したタイミングで、単体テストレベルのバグが想定以上に見つかったんです。最初は、このバグが限定的なものなのか、それとも他に影響するものなのかも不明でした。このあたりまでくるとチーム内の結束力も強くなり、プロジェクト全体として徹底的にバグの原因究明をするべきだという意識も高まっていましたが、実際にはまだ誰も手をつけられていない状態。

そこで私は、何かいい手はないかと品質分析手法などが記載された論文を調べ、それを参考として自社の開発環境に合うようにカスタマイズ、フォーマット化したバグの真因分析用のシートを作り上げ、運用を始めました。これはベトナム語で「なぜ」「どうして」を意味する「タイサオ(Tai sao)」から「タイサオシート」と呼ばれ、現地のオフショア開発チームはもちろん、現在では他のプロジェクトにも活用されています。オフショア開発ということもあり、当時は下流工程の問題に頭が寄りがちでしたが、このタイサオシートにより、私たちはバグの原因が上流工程にもあると判断。適切な対策で品質を保ちつつ、カットオーバーが迎えられました。

オフショア移管と新拠点の立ち上げを同時に実施

編集部:現在はどのようなプロジェクトに携わっていらっしゃるのですか?

山口:現在手掛けているのは、2015年2月からスタートした、大型サービスの一つのサブシステムをオフショア化するプロジェクトです。今までサービスを開発してきたメンバーにとっては突然のことなので、当然、「なぜオフショア移管をするのか」の説明を求められる場面もありました。相手に納得してもらうには、自分自身にも現場開発者と同等の知識やスキルが求められますから、かなりのプレッシャーを感じましたね。また、国内とオフショアで異なる開発のスキームやプロセスを融合する必要もありました。

そしてもうひとつ、この案件では大きな問題が出てきたんです。それは、このプロジェクトを従来のダナンの開発現場ではなく、新たにハノイに開発現場を立ち上げて実施するという点でした。ハノイの立ち上げは、なにもかもが“初めてづくし”。日本側で参画するメンバーは私以外オフショア開発の経験がなく、現地のチームメンバー50名も大半がハノイで急遽募集した人材でした。唯一救いだったのは、ダナンの開発現場でリクルート案件を経験しているコアなメンバーが数名参加してくれたことくらいでしょうか。連携どころか現地のメンバーの持っているスキルや各人のレベルすら分からない手探り状態でした。

編集部:オフショア移管と新たな開発現場の立ち上げを同時に行うというのは、聞いただけで大変そうですね。

山口:正直かなりハードでした(笑)誰に何を任せたらいいのか、適切な配置はどうなのか、そこからのスタートです。
そんな状況で私が最初に行ったのは、リクルートの案件や仕様などに付随する知識・能力のテストを行い、その結果からベストなチームを編成することです。このテストで印象的だったのは、いくら能力やスキルが高くても、チームとしてどう仕事に取り組むか、というスタンスが良くなければリーダーに向かないということ。いかにチーム全体のことを見て、そこで起こっている問題を自分事としてとらえられるかが重要なんです。

当時、「スタンスには課題があるものの、スキルの成績が良いから」という理由でリーダーを任せた現地のエンジニアがいたのですが、彼が率いた7名ほどのチームは、最終的に1名を残して全員辞めてしまいました。そのチームは品質も明らかに劣っていたので、改めてチームリーディングにおけるスタンスの重要性を感じましたね。スタンスが共感されないと人がついていかないし、チームとして踏ん張れないんです。

_T3A8909

また、初めて仕事をする者同士なので、効率の良い業務のやり方が確立できていないのも課題のひとつでした。各メンバーは、当然ながら異なる学校やプロジェクトでエンジニアとしての能力を磨いてきています。そのため、自分のやってきたやり方にこだわって「なぜこのドキュメントが必要なのか分からない」「ドキュメント作りなんていいから早くコーディングがしたい」といった声も最初は多く聞かれました。

そしてもうひとつ、人間関係の問題も苦労しました。メンバー間でのコミュニケーション不足から衝突が発生することも少なくなかったので、それをいかに解決するかも私の役割でしたね。これまでの経験で人と人とのつながりやコミュニケーションの重要性は身に染みていましたから、時には衝突している当事者たちを呼び出して、それぞれの意見を聞いた上で解決策を見つける、といったこともしていました。

こうしたいくつもの壁を乗り越えて、このプロジェクトは3月1日に無事サービスインを迎えられました。その後も特に大きな問題が発生することなく稼働しています。最初は初めてづくしでしたが、徐々にチームのコミュニケーションがよくなりましたし、全員で考えながらやり遂げ、高品質なサービスに仕上げられたことには大きな達成感を覚えましたね。

開発は、実現したい目的をかなえる“手段”

編集部:リクルートテクノロジーズに入社されてから、ご自身の中で変わったと感じる部分はありますか?

山口:自分でしっかりと考えて、本質的な問題ってなんだろう、ということを常に探すようになったのは大きく変わった点です。SIerで働いていた時期は、企業や組織の思想に合わせなければ、という意識が働き、考え方が狭まっていましたし、エンジニアとして自分が手の届く範囲内の仕事をやることしか考えられていなかったなと思います。
しかしリクルートテクノロジーズに入社してからは、事業やリクルート全体をよくするためにはどうあるべきなのか、をまっすぐに考えられますし、よく問われるようになりました。

また技術的な部分では、マネジメント能力が入社前と比べて格段に上がったと実感しています。
現在、ハノイには約50名のエンジニアがいますが、直接的な役職のつながりこそないものの、感覚的には疑似的な部署や組織を持っているような感じです。これだけでも、SIerのエンジニアだった頃と比べてはるかに上位レイヤーの経験ができていますし、それを上手く回すことでマネジメント能力が身につきました。

結局のところ、開発はあくまでも手段でしかありません。リクルートとして実現したいことは何なのか、目的は何であるかを常に考え、共有し、そのために開発という手段をいかに磨くかを考えています。上から教えられるのではなく、自発的に挑戦して成し遂げられる、そしてしっかりと評価してくれる。このサイクルは、エンジニアにとって最高に面白い環境だと思います。

人と人とのつながりや信頼がプロジェクトを成功に導く

編集部:最後に、プロジェクトを成功に導く秘訣についてお聞かせいただけますか?

山口:やはり人と人とのつながりや信頼が一番重要なのではと感じます。信頼関係が築けていない状態では、チームが非常に弱くなるんです。それが徐々にまとまり、全員が協力しながら取り組める状態になると大きく変わります。信頼を持てるからこそ強いチームが築けるのであり、それがプロジェクトを上手く回す根幹にあると、私はこれまでの経験から感じました。こうした人間関係の基盤があってはじめて、プロジェクトマネジメントの方法論などが活きてきます。基盤のない状態で方法論だけを押し付けても、決して上手くいかないでしょう。

もうひとつ、チーム全員で目線を揃え、共通の認識を持つことも重要です。たとえば前回のプロジェクトで数多くの失敗をした場合、課題だった部分を全員で意識し、次回にどう活かすかを話し合うことによって、同じ目線で動けるようになります。これも人と人とのつながりを強くする重要なファクターです。

編集部:ありがとうございました。

提供:リクルートテクノロジーズ

Pocket