企業の成長の過程には、さまざまな壁が現れます。事業全体でも成長にともなって課題が出てくるように、エンジニアリング組織も初期の体制のままでは立ち行かなくなってきます。初期に作ったコードのリファクタリングや組織構成の再編、採用における課題など、技術的な部分から組織全体の問題まで、見直すべきポイントは多岐に渡ります。
事業が成長期〜成熟期とステージを上げていくなかでも持続的な発展をしていくためには、これらの課題に対してしっかりと向き合い、組織力を活性化し続けなければなりません。
この記事では、GMOペイメントゲートウェイ株式会社の専務執行役員CTO 三谷隆さんにお話を伺いました。設立から四半世紀を超え、今も次世代の決済サービスを次々と世に送り出している同社。これまでに彼らがどのような課題にぶつかり、どのように乗り越えてきたのか。そして業界のトップランナーが目指す開発組織の形とは。
目次
事業が成長して顕在化したテクノロジーとマネジメントの課題
企業、そしてサービスの規模が大きくなってくると、開発部門ではそれまであまり見えていなかったいろいろな課題が顕在化してくるかと思います。
テクノロジーに関する課題
まずあげられるのがテクノロジーに関する課題です。
当社でも、古いプログラムの上に機能を追加してきてしまったために、開発が属人化してしまったり、問題が発生しても原因がすぐに特定できなかったり、プログラムそのものがスパゲッティ状態になっていたりといったことが起きていました。特に会社が立ち上がって十数年経ったころから、そのような事象が各所で現れてくるようになりました。
当時は会社が非常に成長している時期で、サービスを使ってくれるお客様は大きく増加。今までにない負荷がシステムにかかったり、ピーク性が強くなったりしたときに不具合が出ることもありました。しかし、開発が属人的になっていたために課題の解決に時間がかかってしまい、全体の障害にまでつながってしまう……そのような事例がまれに発生していました。他にも「なんだかサービスの動きが遅い」という場面があっても、システムが複雑化しているために深追いするだけのリソースを割けず、原因不明のまま放置されてしまうといったケースも出ていました。
さらに、ドキュメントの共有にも課題を抱えていました。当時はファイルサーバでプロジェクトごとに権限を設定して管理していましたが、設立から十数年経つうちに、どこに何があるかを正確に把握できなくなってきていたのです。開発当時のドキュメントを確認しようとしても、すぐに見つけることができない。社内では俗に「ファイルサーバ地獄」と呼ばれていました。
また、組織が大きくなってきたことに起因する課題ではありませんが、これらの課題が顕在化していた当時はサービスをクラウドへ対応させるかの判断も必要なタイミングでした。当社はもともとオンプレミスで長くやってきて、自社のデータセンターでサーバ構築をしており、それまでクラウドを使ってのサービス構築はしていませんでした。ただ、エンジニアからは「今後はクラウドに移行したほうがいいのではないか」という声もあがってきていました。
マネジメントに関する課題
一方、エンジニアリング組織が大きくなってきたことで、マネジメントの課題も出てきます。
おかげさまで事業は毎年25％営業利益成長を目標として増収増益を達成しており、エンジニアの人数もそれに合わせて年間で20％ずつ増やしていこうという方針で採用をしています。それもあって加速度的にエンジニアリング組織が巨大化しており、5年前の時点で約80人だったものが、現在は約200人となっています。規模の変化に対応しながら適切なマネジメントをしていくために、改めて組織体制を整えていく必要がありました。
一般的に組織が成長して階層が深くなると、上下間が何をしているかも見えにくくなります。また、一緒に仕事をしていても少し離れたところのメンバーが今何をしているのかが見えなくなりがちです。さきほどお話しした「ファイルサーバ地獄」のこともあり、社内の情報共有もうまくできていませんでした。
周りが何をやっているか見えない状況をそのままにしていると、徐々にメンバーの中に不安感や不信感が生まれてしまいます。実際に辞めていってしまう方も出てきていて、エンジニアの働く環境の見直しが急務でした。
マインド面からのアプローチを重視した組織改善
テクノロジーとマネジメントの課題に対して、当社ではエンジニアのマインド面によりフォーカスして、組織改善を進めていきました。ここからは、具体的に実施した施策についてお話ししたいと思います。
エンジニアとして最も優秀な人をマネジャーにする組織体制
エンジニアの心理として、「技術のことが分からない人に評価をされたくはない、しっかりと技術について理解がある人から評価されたい」という欲求が強いと思います。「マネジメントは上手だが技術への理解はそこまででない」人をマネジャーにするのは、その下で働くエンジニアにとって快適ではないはずです。
そこで組織のマネジメント層には「そのチームで最も開発能力がある人」「エンジニアとして最も能力がある人」をつける組織体制にしました。もちろん、マネジャーと言ってもプレイングマネジャーとして手を動かして開発してもらいます。マネジメント側になったからといって、現場から離れるというわけではありません。
「そのような体制でちゃんとマネジメントできるのか」「チームとして動けるのか」と思った方も多いと思います。しかし、当社ではマネジャーに対して、タスクを細かく砕いて、メンバーをアサインして、進捗確認して……といった役割はほとんど求めていません。業務は比較的大きなかたまりの状態で渡して、その中でどう分割して取り組んでいくかは、各エンジニアに任せています。
当社では「全員社長主義」をパートナー（社員）に求めるマインドの1つとしています。たとえば与信のコンポーネントの開発プロジェクトであれば、各メンバーがそのコンポーネントの社長になってもらうイメージです。もちろん適宜相談などはするものの、マイクロマネジメントはせず、各自で責任を持って自分の裁量で進めていく体制にしています。
周りの動きが見えるようにするための取り組み
そのようにしてプロジェクト内の体制を整えつつ、組織全体の課題解決にも取り組んでいます。
まず取り組んだのが1on1の積極的な実施です。組織の巨大化でできてしまった上下間の距離を埋めるため、私自身も50人ほどいる部下全員と定期的に1on1をしています。そこでは業務の進捗の話などはほとんどせずに、私からはその人に何を期待しているかを伝えています。一方、メンバーからは日々どんな仕事で困っているかや、直属の上司には言いづらい内容の話を聞くことが多いです。あるいはパーソナルな相談やただの雑談になるときもあります。この1on1の実施によって、縦のラインの風通しをよくしています。
次に、周りが何をしているか見えない一因となっていた「ファイルサーバ地獄」を解決するためにConfluenceを導入しました。かつてファイルサーバで共有していたころは、プロジェクトごとに権限を設定していて、それが情報の蛸壺化を招いていました。そのため自分がやっていることは分かっても、隣のプロジェクトが何をやっているか分からない。たとえ知りたいと思うメンバーがいても、うまく共有することができていませんでした。
そこでConfluence上では、基本的に全員がすべてのドキュメントを閲覧できるようにしています。現在は設計書もConfluence上で書いています。これによって、よそのプロジェクトがツールをどう使っているのか、トラブルが起きたときにどうやって対応していたのかなど、さまざまな情報が共有される状態になりました。
これらの施策を通じて、縦のラインと横のライン双方で「自分以外が何をやっているのか見えない」という状況を解決してきました。
パフォーマンスを引き出すためにやりたい仕事の比率を高める
さらに、各エンジニアのパフォーマンスが上がるよう、できる限り本人がやりたい仕事の比率を高めるようにしています。エンジニアも人間ですから、やりたい仕事とやりたくない仕事では、パフォーマンスに大きく差が出ます。やりたい仕事の比率を増やしてパフォーマンスを上げてもらったほうが会社としてもよいという考えがあり、会社とパートナー（社員）がwin-winになれる状態を目指しています。そのために会社としてエンジニアが自分の希望を伝えやすくなるような環境づくりに取り組んできました。
一般的に、自分の希望と仕事内容に違いが出てきたら、直属の上司に相談するのではないでしょうか。しかし、現実的に上司に直接そういった相談をしにくいときもあります。そこで当社では年に一度、自分がどんな部署でどんな仕事に関わりたいとか、長期的にはこんな仕事がしたいとか、そんな話を上長を通さず人事に直接提出できる機会を設けています。そういう機会があると、意外とみんなフランクにいろいろな希望を出してきてくれるんです。希望をもとに人事と各部門の上長で調整して、できるだけ多くのメンバーが本人の望む業務に取り組めるように会社として動いています。
また、新たなエンジニアの採用時に見るポイントもここ数年で見直してきました。
具体的には、応募者のスキルセットや経験ばかり見るのではなく、面接の中で「何がしたいか」を重視するスタンスに変えていきました。本人がキャリアパスをどう考えているかを伺い、当社でその希望をかなえるのは難しいと感じたら、正直に「うちはこんな会社だから希望とは少し合わないかもしれない」という話もするようにしています。逆に、本人のやりたいことが当社の業務の中にあれば、なるべくすぐにその業務にアサインできるような対応もしています。
テクノロジーの課題の解決でもマインド面を大切に
続いて、テクノロジーに関する課題にどう取り組んでいるかもお話ししていこうと思います。
システムの再構築プロジェクトを若手育成の場に活用
はじめに、古くなったシステムの改善について。結論からいえば、既存システムをすべてフルスクラッチで作り直すプロジェクトを遂行し、マイクロサービス化を推し進めています。ただ、多くの企業でそうかと思いますが、事業を成長させるために、新しい開発を止めることはしたくないはずです。目の前の開発を止められない状況が延々と続いてしまい、どうしても古いものの改善に大きなリソースが割けないというケースが多いのではないでしょうか。
当社でもできるだけ目の前の開発リソースは残しながら、どうやったら既存システムを作り直せるかを考えました。たどりついた答えとして、このプロジェクトの開発を比較的若手のメンバーに任せることにしました。
もともと機能は存在していて、具体的にどういう動きをすればいいかが分かっているものを作るので、若手でも比較的開発に取り組みやすい。一方で、すべて一から作り直しているので、開発を通して彼らのスキルアップにもつながっています。そうやって経営的にインパクトのある開発を止めることなく、システムの作り直しを進めています。
エンジニアの気持ちを大事にしてクラウド導入を決断
そして、会社としてクラウドへの対応も進めました。ただ「コストダウンや品質担保のためのクラウド導入」というのは建前です。それよりも、エンジニアのやってみたい気持ちを尊重するために、クラウドを導入したと言っても過言ではありません。
当社はずっとオンプレミスでオープンソースをメインに使っていたので、サーバの運用自体は比較的安くできていました。それを全部クラウドにしたら、コストダウンどころかコストが3倍くらいに膨れ上がる状態だったので、金銭的には乗り気になれなかったというのが正直なところです。
ただ、AWSやAzureといったサービスが現れれば、当然エンジニアからは「触ってみたい、やってみたい」という欲求が湧きでてくるものです。それと同時に「ずっとオンプレミスでサーバを作ってきたけど、いずれはこれらの技術に取って代わられるのではないだろうか」「このままでは世の中から取り残されるのではないか」といった不安も出てきていました。そんなメンバーたちを見て、彼らの気持ちは止められないなと思いました。
クラウドサービスを導入して一時的にコストは上がりましたが、一方で、クラウドサービスに合わせたアーキテクチャを設計すればコストダウンを図れることも見えてきました。そこでエンジニアたちに「今はこんな課題があって、こんなコスト感でなんとかなるアーキテクチャを考えてほしい」と言ったところ、みんなその仕事にのびのび取り組んでくれました。人はやりたい仕事の比率が上がれば、パフォーマンスを発揮してくれるといういい例だったと思っています。
エンジニアも人間ですから、コストだけを見て動いてくれるわけではありません。一見コストがかかる判断でも、その技術の導入によって働く上で彼らの満足度が上がるのであれば、会社としてはメリットが大きいときもあります。その部分まで踏まえて技術選択をするようにしています。
本業の魅力なくして定着なし
最後に、われわれは「本業の魅力なくして定着なし」と考えています。会社で働く魅力っていろいろあると思いますが、自分の会社が社会に貢献していたり、成長を続けたりしていないと、継続的な魅力を感じられないのではないでしょうか。
当社の魅力は本当に決済にこだわって、世の中の課題を解決していこうとしているところにあると思っています。経済活動において、決済はなくてはならない当たり前の行為ですが、その割にはまだまだ面倒くさいことが多いですよね。最近だとQR決済が乱立していますが、どれがどこで使えるのかすぐに分からずに不都合を感じた経験がある方も多いでしょう。まだまだ、決済に関する課題は尽きません。いずれは誰もが意識せずに決済できる世の中を作っていくのがわれわれの目標です。
テクノロジーを使って課題を解決していくことで、社会活動そのものをよりよくしていく。それを実現するための開発組織を作っていきたいと考えています。
