OBT　人財マガジン

────日本でシステムを設計し、プログラミングはインドや中国などの海外で行う『オフショア開発』と呼ばれる手法がＩＴ業界で広がっています。御社はベトナムに開発拠点を置かれていますが、他社とどのような差別化をされているのでしょうか。

オフショア開発での差別化を考えるときには、ポイントが２つポイントあります。１つはインドや中国といった他国でのオフショア開発との差別化。もう１つは、ベトナムでオフショア開発をすると決めたとして、ではなぜ弊社が選ばれるのかという点。

まず、前者についてですが、インドや中国を拠点に普及してきたこれまでのオフショア開発は、"設計書通りに作る"ということが主流になっていました。つまり、設計書に書いていないことは「書いてないから作っていません」ということ。これは、欧米型の開発技法とも言われています。

一方で日本に従来からあるシステム開発は、練り込んでいきます。人間の頭で考えていることをプログラムにするわけですから、設計書にも漏れは必ずある。だから、設計書は全体の７割や８割で、後は作りながら練り込むことが必要になります。その代わり、コストや時間はかかります。つまり、欧米型のオフショア開発か練りこむ日本の開発か、どちらを選ぶかということが、これまでだったように思います。

そこに対して当社は、"練り込む日本型の開発がオフショアでできます"ということなんです。プログラミングの拠点はベトナムですが、設計やテストやプロジェクトマネジメントはすべて日本で、日本人と日本に駐在するベトナム人とが行います。日本で設計を経験したベトナム人のＳＥがベトナムに戻ってプログラミングにあたったり、逆のパターンで現地のプログラムリーダーと日本駐在のＳＥを入れ替えたりといった、人の還流も意識して行っています。

これには意図がありまして、我々は、システム開発は決して目的にしてはいけないと思っているんです。システムは手段であって、本当のゴールはその先にある。そのことはプロジェクトのマネジメントでも重視しますし、メンバーに徹底するために日本とベトナムの間で人も還流させる。そうすることで、本来の目的にまで入り込んだ開発をオフショアでできるということが、当社の差別化の一つになっています。

────オフショア開発を手がける企業の中では、御社のような考えは少数派なのでしょうか。

メインではないと思いますね。短期的に見ると、当社のようなやり方は利益率が良くないですから。通常は、仕様書通りにプログラミングしたら終わりなんですね。けれども当社は、仕様書を見直すこともあるし、設計に戻ることもある。もちろん、すべてがそうというわけではないですよ。なるべく戻さないようにはするものの、システム開発の本来の目的に向かっていくためには、戻しは必ずあるんです。「競合会社がこんな事をはじめた」「人事構成上半分の人数で運用をしないといけなくなった」などのように、「外部要因」「内部要因」は刻々と変化している。だから、システムも変わっていくのは当り前のことだと思います。

ですから、ときには「このシステムは作らないようにしましょう」ということまで含めてプランニングします。「エクセルか何かでやるだけにして、１年後にまた声をかけてください」と言うこともある。当社の一番の特徴はプランニングにありますから、そうして少しずつ信頼を得るしかないと思っているんです。

これが、いわゆる欧米型のインドや中国でのオフショア開発に対する差別化ポイント。では、ベトナムでのオフショア開発の中での差別化はといいますと、当社はその中でも最先端の技術を扱っています。今、ベトナムでは、携帯の組み込みソフトといった非常に簡単なプログラミングが多いんです。でも当社は、それはしません。「アドバンスド　ラボ」なので最先端のものを扱います、という特徴づけをさせていただいています。

────実際のプロジェクトでの、プロジェクトマネジャーの役割はどのようにお考えですか。

マネジメントで一番大事なのは、目指すものをメンバーに最初にきちんと伝えたり、開発していく中で目指すものがぶれないようにコミュニケーションを取ることだと思います。お客さまの要望が最初の計画から変わるということは、やはりあるんです。それは仕方がない。内部要因と外部要因が変わればシステムや提供サービスは変わりますから。そうしたときに、「なぜ変わるのか」ということ各メンバーにきちんと伝えられる能力がとても大事だと思っています。「何のために作るのか」「なぜ急いでいるのか」「なぜ時間をかけるのか」「なぜこの料金でやるのか」といったことも含めて。

────プロジェクト内のヒエラルキーはどういう構造になるのでしょうか。

ヒエラルキーはあまり作りたくないと思っています。ですから、"マネジャーとそれ以外"という構造ですね。ベトナム側にもプロジェクトリーダーを立てますが、プロジェクトマネジャーから見ればリーダーも特別ではなくて全員の一人、という位置づけ。リーダー以下のチームで決めたことをその中で共有するということはありますが、マネジャーからリーダー、リーダーからその下へといった情報の伝達は、なるべく減らそうとしています。今はSkypeもありますし、メールもありますから、全員が情報を共有することが当社の基本です。

※Skype：インターネット電話の無料ソフトウエア

────ヒエラルキーを作らないのはなぜなのでしょうか。

全員が同じように情報をつかんで、各自の中で動いてほしいからです。ヒエラルキーは効率がいいように見えますが、全体のことを考えなくなるんです。階層を作ってしまうことで、情報の流れが分断されてしまう。その代わり、ヒエラルキーを作らないことでロスは生まれますし、失敗もある。でも、失敗とロスはあっていいと思っています。

────失敗やロスは、具体的にはどんな場面で起こるんですか。

プロジェクトマネジャーは全員に向けて話すことになるので、ある人は10割分かっているのにある人は５割ということが、ときにはあります。その中で「なんだこれ、違うじゃないか」ということが後の工程になって出てくるということもある。

────それは危険なことではないですか。

危険です（笑）。システム開発のプロジェクトマネジメントとしては、恐らくＮＧでしょうね（笑）。でも、個人の成長はこのやり方のほうが速いんです。情報を全員に同じように流し、自由度をなるべく広げていますから。

────個人の成長のためには、失敗やロスも容認するということですね。

そうですね･･･、失敗しても取り返せるように、大きな意味でのリスクマネジメントはしますが、"失敗をしないように"ということにはコストをかけていないですね。

────それよりも同じ情報が全員に行渡るメリットのほうが大きい。

大きいです。我々はプロを作ろうとしているので、個人の成長も含めるとメリットは大きいですね。

────プロとはどういう人のことですか。

何かをやる上でのものさしを、きっとそれぞれが持っているんだと思うんですが、周囲と話しながらお客さまや会社のメリットを視野に入れてものさしを調整し、最終的に行動をする人、です。例えば、「僕はきれいなプログラムを書きたい」という人は、そのことを周囲に分かってもらいながら、"きれいなプログラム"がお客さまや会社のためになるように自らベクトル調整をする、といったイメージでしょうか。

────「僕はきれいなプログラムを書きたいんだ」という人も、ＯＫなんですね。

そういう人のほうが、私はウエルカムです。全員が同じような志向やスキルである必要はなくて、自分の好きな形でいいんです。本来、プロというのはそういうもの。例えば「設計が好き」とか「営業が好き」、「新しい技術が好き」「ベーシックな技術を徹底的にやりたい」とか。自分が得意な、やりたい方向性で邁進してもらえればいいんです。それを会社としての形態に結びつけるのは、経営者の役割ですから。

────そうすると、マネジャーの方は一人ひとりの得意分野や方向性をしっかりと見ることが大切になりますね。

恐らく最初はそうなんでしょうが、できれば一人ひとりが自らそれをしてほしいと思っています。例えば、「あの人はこういう仕事が好きで、こういう仕事はしたくない」ということを、みんなが知っているわけです。で、「好きなんだから、しょうがないね」と。したくない仕事をしてもあまり効果があがりませんから。

────そういったあうんの呼吸が生まれるような状態にチームを持っていくコツは何でしょうか。

ジョブを通して得意分野を明確に出せるものが必要だと思います。１つは、メンバーの "スキルマップ"を作り、この４月から運用する予定です。「フレームワークは何を使いこなせますか？」「データーベースは？」というスキルであったり、「プログラムよりも設計のほうが得意です」といった志向を全員で共有するためのフォーマットです。

そして、そのスキルマップを置きながら「あなたは今年、何を目指しますか」、「３年後は何を目指すんですか」と言った方向性付けをしていく。ＳＥになりたい人もいるだろうし、プログラムを書き続けたい"スーパープログラマー"がいてもいいと思ってるんです。大切なのは、スキルマップを自分で考えて、目標を設定して、できている・できていないということを、自分も周りも確認すること。評価や査定としてではなく、マネジャーも本人の志向や目標に合ったジョブがないかを見ながらやっていくし、技術者同士も「この人はこういうことを目指している」といったことを見る。

例えば、プログラムを見ると、「こいつのプログラムはダメだよ」といったことって分かるんですよね。けれども、スキルマップで本人の方向性がつかめていれば、「この人が目指すのはプログラミングではないから、しょうがないね」ということも分かる。そういったメンバー同士の呼吸がうまくできて、自分の得意領域でリスペクトされて満足感を得られればいいなと思っています。

────自分自身の得意分野に没頭するあまり、他のメンバーに意識が向かないということはありませんか。

それは、少しだけマネジメントを入れないとダメですね。例えば、正しいプログラムを書くこと自体は個人的には非常にバリューのあることですが、それだけではダメですよね。システム開発の目的は違うところにありますから。これだけは最大のルールなので、プロジェクトのゴールはプロジェクトマネジャーがきちんと説明しないといけない。その中で、あなたは何がやりたいのかということです。

また、プロジェクトが始まる前に、ルールを決めるということもします。例えば、先日手がけたプロジェクトは、Ｂ to C の"新しい仕組み作り"だったんですが、お客さまが目指していることもまだ固まっていない状態でしたので、プロジェクトでは"役割分担は決めるが、領域は作らない"ということをルールにしました。やわらかく進めることが必要なプロジェクトで役割分担を作ると、隙間ができるんですね。ですから、「他の人も担当も自分のことだと思って、みんなで領域をどんどん重ねていこうよ」という約束を作りました。

────世の中一般で言いますと、どうすればゴールをきちんと伝えられるかに悩むマネジャーの方も多いのではないかと思います。

当社でいう"ゴール"は、"このプロジェクトは何のためにやるのか"ということですが、それをメンバーに伝えるにはお客さまともゴールを握っていないといけないんです。もしかすると、握るべきお客さまは先方の窓口の方ではないかもしれない。先方の経営者であったり、実際にシステムを使う方だったり。B to CやB to Bのシステムであれば、その先の消費者や顧客かもしれない。どこを見るかによって、ゴールは違ってきます。ですから、"何を伝えるか"ということ以前に、"お客さまのどこを見るのか"が最も大事なポイント。これができるかどうかが、プロジェクトマネジャーの力量なんですね。

さらに、ゴールをカットオーバーしたときに置くのか、１年後なのか２年後なのかによって、また違ってくる。お客さまはカットオーバーした時点での効果を期待するかもしれないけども、例えば「今回の目的から考えると、２年後や３年後までにうまく運用できるようにＰＤＣＡを作る仕組みを入れましょう、その代わり初期コストは５割くらいに抑えましょう、そして３年後にこういう形で流れていくようにしましょう」ということが、お客さまと話せるかどうか。これはもう、プロジェクトマネジャーの力量にかかってくることだと思います。

────プロジェクトマネジャーの力量は、どのように育成されているのですか。

これはもう、育成ではない気がしているんです。やはり、経験ですね。さらに言えば、そういう価値観を共有できる仲間を採用するしかないんですよね。当社のようなやり方は、あまり儲からないんです。といっても、こんな風に一種わがままな形でやらせていただいても大丈夫なコスト構造は持っています。でも、儲けることだけを考えるならもっといい方法が他にある。それを、あえてこのやり方をするということを受け入れられる人でないと難しいと思います。

ただし、そのためには時間軸を長く、３年などではなくて10年タームぐらいの長さで持たないといけないんです。「10年後にベトナムに次の世代に残るこういうものを作ろう」というゴールを共有して、今はそのためのフェーズだという共通認識がある。きちんとしたお付き合いができるお客さまを一社ずつ作っていって、「やはりあそこが本当にいいよ」と言っていただくことが、マーケティング的にも一番良いということだと思っています。

ですから、大きなベクトルは一緒。でも、短期間で見るとズレは出てきます。何でもそうですけどほんの少しズレるんですよ、必ず。けれども、５年後や10年後に目指す夢を共有していれば、少しのズレは構わないと思っています。

────プロジェクトメンバーの方々へは、ゴールをどのようにお話されるのですか。

ことあるごとに、ですね。ベトナムとは離れていますけども、Skypeやメールを使って、日本に来たりベトナムに行くときは食事もして。オンとオフと両方で、一つか二つのことを何度も何度も繰り返します。少しずつ苦労して、みんなずいぶん理解してくれるようになりました。やはり苦労しないとダメですね。失敗して、喧嘩もして。修羅場をある程度くぐらないとダメなんですね。

────社員の方々のモチベーションを維持、向上させることについては、どのようにお考えですか。

経営者の役割の中で、もしかすると一番大事な仕事かもしれないと思います。ただし、モチベーションを向上させるということを、テクニック論にしないようにしようとは思っているんです。

先ほどもお話した例が一番分かりやすいんですが、一般的にはプログラムだけを書いていたら、そのうちに「ＳＥになってくれ」「プロジェクトリーダーになってくれ」と言われます。この業界は単価商売ですから、優秀なプログラマーでも単価はＳＥの半分くらいだったりする。そうしたら会社としては、高い単価でやってほしいですよね。でも、「マネジメントはしたくない。プログラムを書いていたい」と、本人の希望はただその１つ。これを"ワガママ"とするか"良し"とするかといったら、私は"良し"としたい。"良し"として、そのことをみんなでリスペクトするのが一番のモチベーションアップだと思うんです。

けれども、これだけでは足りなくて、それでもやはり仕事をしていて疲れることってありますよね。そこでモチベーションを上げる何かが、プラスして必要なんです。まずは、私自身のモチベーションを上げるものが必要だと思っていまして、それを、今、作ろうとしています。

ベトナムの代表もそれは同じで２人で考えていることなのですが、テーマはスキルアップといった個人のものではなくて、次の世代に何を残せるのかということ。私の娘やベトナム代表の子どもたちの世代に何か残るものを作っていこうということを、ベトナムの代表と２人で考えているんです。為替の差のおかげで、私たちの資金規模でもベトナムでできることがいくつかあるんです。

────それはどのようなものなのですか。

一つは、ベトナムの中部、ハノイとホーチミンの間にある自然の豊かな街に、300人規模のシステム工場のようなものを作って、システム開発のIT専門学校も併設するという計画を考えています。そんなに夢物語ではないくらいのコスト計算でできるんですよ。

もう一つは、今年の１月から『ＨＡＬ基金』というものを始めました。ベトナムでは、農村の方って現金収入が少ないんですね。食糧はとても豊かな国ですので生活には困らないんですが、若い人たちが大学に行くとなると都市に出ることになりますから、現金がなくて苦労する人も多い。そういった方々に月々の生活費の半分を『ＨＡＬ基金』が援助するという仕組みです。今年度の対象は５人だけですが、来年度は10人や20人の規模にできればと考えています。

なぜこういうことを考えているかと言いますと、日本のこれからを考えたときに、やはりアジアとの関係はますます深くなっていくと思うんです。そうしたときに、ベトナムやタイといった東南アジアは非常にいい国々ばかり、日本とそれらの国とのビジネスの基盤を作っていきたい。一緒に商売をしたり会社を運営する仲間って、喧嘩はするけど、とても信頼関係があるんですね。信頼関係があれば、戦争などは起こらないじゃないですか。

ですから、そんな基盤を、私たちができるＩＴの中で作るというのがＨＡＬの仕事。ＩＴは初期投資が少なくて済むうえに、市場はワールドワイドです。フラットな世界で勝負できる。ということは、実は後進国といわれている国のほうが有利なんです。コストが安いですから。しかも、ベトナムには知的水準が高い人が多い。

恐らく、当社のメンバーの人たちもみんな同じ気持ちになってくれるはずだと思っていますし、そういう人たちだけが仲間に入ればいいなとも思います。自分のスキルアップだけではなく、将来に何かを残すということをモチベーションの源にして、そのための目標を明確し、言葉にして、具体的な事例にもして、それに賛同する人を採用する。賛同した時点で、それがモチベーションになりますから。規模が小さいからできることなのでしょうけれど。

────そういった目的を共有できる組織は強いと感じますが、社員の方々に目的やその考え方を伝えるのも、マネジャーや経営者の大切な役目といえるのでしょうか。

まったくその通りでしょうね。特にベトナムは、きちんとした言葉にしないと通じない文化なんです。いくら日本語が通じたとしても、こちらがきちんと言わないといけない。つまり、自分の考えもきちんとしてないと伝わらないんです。海外と仕事をすることは、自分のためにも勉強になりますね。

────仕事だけではない目標があるというのは、いいですね。

仕事は手段ですからね。もちろん利益の基盤がないとできないことなので、そこは大切にしていますが、それだけだと、利益が出たとしても疲れてきてしまうんです。その先にもう一つ、何かがないと。社員のモチベーションを上げることも大事ですが、経営者の仕事としては、自分のモチベーションを上げることが最も大事だと思っていまして、疲れないようにするにはどうすればいいのかを考えて行き着いたのが、今お話した目的。これを考えるとすごく楽しくて、この頃元気になりつつあります（笑）。

────ありがとうございました。