一気通貫のSIerだから味わえる、　開発本来の面白さと、オフショア開発の苦悩

──では早速、進めさせていただきますね。リンググループの強みのひとつに「コンサルから保守まで一気通貫でできる」という点があると思います。お客様と接する中で、その強みや面白さを感じるのはどんなときですか？

K・O： 自分はまだ入社して7、8年なんですが、その立場でもお客様同士の内部会議とかに直接出て、「どんなシステムを作りたいのか」を本人たちから聞けるんです。お客さんにかなり近いところで、どういったものを作っていきたいかという話ができるのは、すごく強みだなと思っています。

A・S： それはね、ずっと意識してやってきたところだよ。よくあるケースだと、システムを開発する会社と、運用するチームが会社ごとに分かれちゃっていることが多いじゃない。

K・O： 多いですね。あれだと、仕様面での認識のズレとか、要望のやり取りで社内連携が大変になりますよね。

A・S： そう。うちは開発も運用も自社の中にあるから、お客様からの要望をその場で引き取って、すぐにすり合わせができる。「作ったあと、どう運用するか」まで見据えて設計できるのは、やっぱり大きな強みだよね。

J・N： RDCだと、それをより強く感じますね。お客様と直接お話しして要件を固めて、セブのメンバーと一緒に開発して、リリース後の保守・運用チームも社内にいる。全部が社内でつながっているんです。

K・O： 運用を知らない人が設計してしまって、現場で使えないものができる、みたいなことが起きにくいわけですね。

J・N： まさにそこです。設計と運用が別会社だと、後から「これでは回せません」という手戻りが必ず出ますが、その構造的な手戻りが少ないのはリンググループの強みだと思います。

K・O： A・Sさんの立場から見ると、どうですか？

A・S： RDCは、お客様とセブの開発チームと国内のチーム、というように複数の会社をまたいで調整しながら動いている。一方でRSSは、インフラも運用もお客様サポートも、基本的に一社で完結しているんだ。

J・N： ほとんどの場合、お客様とグループ会社のみで完結していますよね。 会社をまたぐと、どうしても確認の手間が増えますしね。

A・S： そこなんだよ。会社をまたぐと、「いつできるの？」「見積もりを出して」といった確認を一件ずつ別の会社にお願いすることになって、これが一番時間を食う。うちなら窓口がひとつだから、お客様は一社に言えば済むし、作る側も動きやすい。

K・O： お客様にとっても、社内にとっても速いということですね。

A・S： そう。ただ、裏を返せば「この会社が止まったら、お客様の運用も全部止まる」ということでもある。

K・O： ……たしかに。良いところの裏返しですね。

A・S： そう。良いところばかりじゃなくて、そこはしっかり責任を背負わないといけないところだよね。

── 2つ目の質問ですが、セブでのオフショア開発を始めた頃はどんな状況だったんですか？苦労したことや、工夫したことを教えてください。

A・S： 11、12年前の話だからね。今で言うオフショア開発と呼べるようなものではまったくなかったよ。

K・O： 僕が入るよりだいぶ前ですよね。どうやって始めたんですか？

A・S： 現地でITを学び始めたばかりの若いメンバーに声をかけて、「一緒にやってみよう」というところからのスタート。体制も環境も何もない、ゼロからだね。

K・O： えっ、環境がないってどういうことですか？

A・S： 本当に何もなかったんだよ(笑)。当時はSlackのようなチャットツールもまだ普及していなかったから。

J・N： 最初はSkypeでしたよね。

A・S： そう。Skypeでやり取りをして、現地のメンバーに自分のパソコンの中で作ったプログラムをメールで送ってもらって、日本側で組み込む。そんな進め方だった。

K・O： プログラムをメールで……。今だと考えられないですね。

A・S： そうすると当然、「セブでは動くのに日本側では動かない」という問題が次々に出てくるわけ。

J・N： 開発環境が人によってバラバラだと、必ず起きますよね。

A・S： だから「全員が同じ環境を見られるようにしよう」と決めて、AWS上に共通の開発環境を用意した。それでまず一つ解決した。

K・O： なるほど、そこでクラウドに行き着いたんですね。タスクの管理はどうしていたんですか？

A・S： しばらくはExcelに一覧を作って管理していたよ。

J・N： ありましたね、あのExcel（笑）。

A・S： ただ、誰かが更新し忘れると古い情報が残ってしまって、どれが最新か分からなくなる。これは限界だな、と。そこでRedmineを入れて、「チケットはこう起票する」「進捗はここで更新する」とルールを決めたんだ。

K・O： 今使っているRedmineの運用って、そういう経緯でできたものだったんですね……。正直、そこまでは知りませんでした。

A・S： 最初から整ったマニュアルがあったわけじゃないからね。やりながら「ここが回っていない」と気づいて、一つずつ手を打ってきた積み重ねが、今の運用になっているだけなんだ。

K・O： 先に設計図があったわけではなく、現場で起きた問題から順番に潰していったと。

A・S： そのとおり。代表が新しいことを立ち上げて、我々が後ろから仕組みとして整えていく、という形だね。

J・N： K・O君が入ってきたときには、もうその体制がだいぶできていたよね。

K・O： そうですね。今の話を聞くと、かなり整った状態から入らせてもらったんだなと思います。

A・S： 始めてから5年くらいで、一気に形になった感じだね。

── 最後に、グループにおけるエンジニアの評価や、若手に伝えたいこと、皆さんが日頃意識していることを教えてください。

A・S： K・O： 個人的に思っているのは、「どれだけ目立ったか」ではなく「担当したプロジェクトをきちんと成功させたか」というところを見られている気がします。

J・N： J・N： 派手に前に出た人が評価される、という話ではないですよね。

K・O： K・O： そうなんです。自分たちが価値を出せるのは、開発から運用までをトータルで設計して、お客様と長く続く関係を作れることだと思っています。保守の費用をどれだけ積み上げるかではなく、最初からお客様の業務を理解した上で提案できるかどうか。

A・S： そこは本当にそうだね。

K・O： なので管理職に求められるのは、お客様のことをちゃんと見れているか、理解できているか。そこに加えて、チームの連携をうまく回せるか。この2つなのかなと思っています。A・Sさんは、どこを見ていますか？

A・S： 私は、メンバー・リーダー・マネージャーの3つの層で、見るものが変わると考えていて、メンバーは顧客満足、つまりCS。リーダーはCSに加えて、チームが健全に働けているかというES。マネージャーはそこにコストまで加わる。

K・O： 層が上がるごとに、見なければいけない範囲が広がっていくんですね。

A・S： そう。その中でもメンバーについては、まずお客様をちゃんと見れているかを重視している。上司に言われたことをそのままこなすのではなく、その指示の意図を理解した上で、「この動き方のほうがお客様のためになる」と自分で考えて動けるかどうか。

J・N： 分かります。コミュニケーション能力が高い、という言い方になりがちですけど、実際は「相手の立場で考えられるか」ですよね。

A・S： まさにそこ。J・Nさんは、評価するときに何を意識してる？

J・N： 私が見ているのは、言われたとおりに動くのではなく、「今の状況を見て、必要な行動を自分で選べているか」という点です。

K・O： 具体的には、どういう動きですか？

J・N： たとえば、お客様との関係が今こういう状態だから先回りして連絡を入れておこう、とか。社内で仕様が固まりきっていないから、自分がそこを確認しにいこう、とか。

A・S： それができる人は強いよ。指示を待っている時間がないからね。

J・N： はい。設計のスキルがまだ高くなくても、周囲の変化に気づいて自分から次の一手を打てる人は、それだけで十分にチームの力になると思っています。

K・O： 今日の話は、そのまま若手にも聞かせたいですね。