米国チームに思い知らされた、阿吽の呼吸の通じなさ：CTOが語る日米共同プロダクト開発の舞台裏（1）
日本主導の日米共同開発で思い知らされた現実を、開発の総責任者が振り返る本連載。第1回は日本における「阿吽の呼吸」という文化についての、それまでの認識が甘かったことについて語ります。
日本企業が米国に自社の開発チームを結成して日米共同開発を行うと、カルチャーギャップなどさまざまな課題に直面します。本連載では、大規模なSaaSの日米共同開発を指揮するセゾン情報システムズ 執行役員の有馬三郎CTO（最高技術責任者）が自らの体験を語ります。（編集部）
こんにちは。セゾン情報システムズ 執行役員 CTOの有馬です。
当社は3年半、日米共同チームで「HULFT Square」というSaaSを開発してきました。初めて行う海を越えた開発では、想像しなかった問題を経験してきました（現在進行形で起きています）。もちろん、今となってみれば、こうした経験を貴重な学びに転換できたり、プロダクト開発におけるメリットが出てきたりした部分もたくさんあります。
この連載を通じて、日本と米国とのプロダクト開発の違いや、共同チームの難しさ、学び、楽しさなどをご紹介していきたいと考えています。グローバルチームで仕事をしてみたい方や、今これで苦労しているエンジニアの参考になれば幸いです。
以下のテーマで書いていく予定ですので、お付き合いください。
第1話 阿吽（あうん）の呼吸はグローバルでも使えるか
第2話 決まらない会議はなぜ起こる
第3話 延々と続くコードレビュー
第4話 クラフトマンシップを超えたその先の世界
第1話である今回は、最初にぶつかった課題である、阿吽の呼吸や以心伝心のような日本の良き伝統と、日米共同プロダクトとの相性問題について記載します。
クラウドサービス開発でグローバル市場に挑戦
当社は「HULFT」というデータ連携製品を開発、販売、サポートしているソフトウェア企業です。
今年はちょうど発売30年に当たるアニバーサリーな年です。もう一つのデータ連携ソフトウェア「DataSpider Servista」も20年を超える製品であり、合わせて1万社を超えるユーザーにご利用いただいています。
ただし、当社の製品のほとんどはオンプレミス向け製品であり、最近のクラウド、アジャイル、DX（デジタルトランスフォーメーション）というユーザーの潮流とギャップが出てきている現実があります。
また、当社の製品はグローバルでも利用されており、さらなる拡販を目指して2016年に米国子会社のHULFT Inc.を立ち上げています。しかし、その後4年間、日本国内で開発したソフトウェアを米国市場で販売することの難しさを感じてきました。
これらの理由から、クラウドを通じたSaaSアプリケーションとして提供すること、そしてグローバルに挑戦することを目的として、米国に開発部隊を結成し、日米の共同開発を2020年4月から開始しました。
日米共同開発チームの立ち上げ
開発チームの形はこの3年半でいろいろと変化していますが、最初からプロジェクトのキーとなるアーキテクト、プロジェクトマネジャーは米国側に配置していました。私自身の役割はプロダクトマネジャーであり、本社側の執行役員として開発全体の責任者という立場も担っています。
米国側にアーキテクト、プロジェクトマネジャーを配置した理由は、世界に挑戦するプロダクトを作っていくためにも、これまでの当社にはない発想でプロジェクトを進めたいと思ったからです。
当社では「WebConnect」というSaaSを既に開発、販売していましたが、今回開発するiPaaSは単機能なサービスではなく、当社が今後メインビジネスとしていくプラットフォームです。そのため、マイクロサービス適用、Amazon Web Services（AWS）の全面採用、英語ベース、アジャイルでのプロジェクトの推進という当社にとって初ものづくしをてんこ盛りして、さまざまなことに取り組んだアグレッシブなプロジェクトでした。
さらにいうと、GDPR（EU一般データ保護規則）やCCPA（カリフォルニア州消費者プライバシー法）、SOC（Service Organization Control）にも対応させるという、今考えると無鉄砲が過ぎたものでした。
その背景として、当社には既に製品、サービスの開発の文化が存在していたことがあります。AWSを活用して巨人の肩に乗り、当社のコア部分を中心に開発していくことで、プロジェクトは成功すると考えていたのです。
つまずきと再プランニング
下の図は、本プロジェクトにおける現在までの大きなマイルストーンを示したものです。
R＆D段階で米国を中心にしたチームがフィージビリティを確認し、このぐらいの機能群であれば翌年の10月にGA（本番リリース)できるだろうということで、経営層に上申し、8月から本格的にプロジェクトを始めました。
実のところ、SaaSなので、最初からフル機能というよりも、リリース後にユーザーの利用状況を踏まえつつ機能を追加、ユーザー体験（UX）の改善を進めるのがよいという考えもありました、このためGAを最低限の機能で行ったうえで育てていこうと思っていました。
ところがそうはうまくいきません。2021年10月のGAは無理だと感じたのは、プロジェクトを開始して半年後の2021年2月ごろでした。プロジェクトとしては最終的には7月に再計画を実施、当初GA予定の3カ月後にPoC（概念検証）の受け入れ開始、そして製品の改善などを進めて、そこから12カ月後にGAするという形となりました。
今年の2月になって実際にGAを達成できましたが、開発チームも経営側も非常に忍耐強くここまでやってこられたのは、当社がHULFTという製品を30年開発し続けているプロダクトメーカーとしての文化があったからだと思っています。既存製品のHULFTも、最初からうまくいっていたわけではなかったのです。この話は長くなりますので、詳細はこちらをご覧ください。
今回は、下図の混乱期の部分における多くの問題の主因となった、言語化の不足について話を進めていきたいと思います。
阿吽の呼吸、以心伝心が妨げた開発スピード、スケーラビリティ
何十年もHULFTやDataSpiderを開発していると、「あれ」「それ」で伝わることがとても多いです。
また、開発だけでなく、販売、サポートを含めた製品全体のサイクルにおいて、こぼれ球を誰かがうまく拾うように組織が仕上がります。
これは、同じような教育を受けて育ってきた人が占める割合の多い、伝統的企業の特性とも言えます。同質性が生み出す奇跡のようなものです。ただ、その同質性は世界で戦う上で妨げとなり、また国内においてもDX化した企業によりディスラプトされる危機を既に招いています。
国内の伝統的な企業においては「なぜ、これが必要なのか」「これはどんな意味を持つのか」ということを深く考える機会が少ないと思います。私も今回のプロジェクトを通じ、改めて自分自身に対しても感じています。
開発メンバーは目的を問うことなく、トップダウンで降ってきたHULFT Squareの開発という目標に沿って、サービスをきちんと作るということにフォーカスします。ターゲットはどこか、誰のどんな課題を解決したいのか。そういう質問はあまりありません。要件を設計し、開発し、QAするというシステム開発の当たり前をきちんとこなしていくのです。
米国との共同チームで感じた最初のギャップはこの部分でした。具体的に書くと、設計書には「どう実現するか」だけが記述されていたため、「なぜこの方式を選んだのか」といった質問が米国側からたくさん出ました。結果として、設計がいつまでも固められないという状況が発生しました。
どちらがいいかはケース・バイ・ケースなので、ここで断じることはしません。ですが、SaaSのような不確実なプロダクトにおいては、これまでの非DX企業のソフトウェアプロダクトづくりの方法では、顧客の期待に応え続けるサービスを提供しづらいと、現時点では考えています。
それはウォーターフォールに代表される要件定義の重厚さがそのまま製品の価値につながらないことと同義です。いくらトップダウンで「こんな製品、こんな機能で作るぞ」と言ったとしても、初期段階で完璧なものを定義できるわけがありません。ウオーターフォールはそれができるという仮定の上で成り立っているので、今後ずっと改善し続けていくサービス開発とはそもそも相性が悪いのです。
「要件」ではなく、言語化された「目的」や「価値」が、サービスを作る開発者だけでなく組織にとって必要なのです。開発者それぞれが腹落ちするには多くの時間が必要でした。
言語化された「目的」と「価値」の強み
もちろん国内においても、DX化された最近のITベンチャーやソフトウェア企業はこのことに気付いています。ウォーターフォールでなく、アジャイル開発を取り入れ、短いサイクルでリリースしています。とても素晴らしいことです。とはいえ、開発だけアジャイルを取り入れただけの企業も多いなというのが実感です。予算の獲得、ビジネスデベロップメント、MRD（市場要求定義書）作成、開発、リリースをアジャイルに進めるためには、開発だけではなく組織全体がスピード感やアジャイルの流儀を理解しないといけないと考えています。
実はそれを進めていくときに、「阿吽の呼吸」「以心伝心」は邪魔になります。開発だけ、セールスだけ、サポートだけなどの閉じた世界の中では、一定の効果は出ます。最低限の以心伝心がなければ滑らかな開発が進められないのは現実です。
ただし、これを中心に置くと部門間でのサイロが生まれ、サービス開発全体の滑らかさは消えうせ、ざらざらなものになります。「あいつらは分かっていない」といった意見がお互いに出るような状況です。
最初から正しい要件を作ることができないので、リリース後にいかに対応していくか、変化を見て動きをどう変えるかというところが重要になります。それにはゴール設定とスピードが重要です。つまりいい意味での朝令暮改が必要です。コンセプトや目的を言語化し、早くユーザーに価値を届けるということを中心に置く必要があります。
AWSは毎年の「AWS re:Invent」で数多くのサービスを発表しています。それを彼らは毎年実現しています。新機能や前年に出した機能の大幅改善を、驚くスピードでリリースします。それはMicrosoftやGoogleも同じです。開発の速さだけではなく、マーケティング、プロダクトマネジメント、開発、セールス全体の滑らかさがないとこれは実現できないと考えます。
そういったスピードを上げるためには、大きなリソースプールが必要となります。
そのリソースプールを実現するためには、当該企業ないし国内だけで完結することは非常に難しい時代になりました。われわれの得意な、空気を読んだ仕事の進め方も、アジリティを上げるためにグローバルまで範囲を広げた途端、遅延の原因となることが多いです。よくある「何か分かってくれないんだよなー」という愚痴がそこかしこから聞こえてきます。
グローバルでのリソース活用という点だと、「中国、インドなどのオフショアなど従来企業でもできているよ」という意見もあるかもしれませんし、システムインテグレーション（SI）的な開発では、実際に多く採用されてきています。完璧な要件定義がある前提ならば、こういう役割分担もありかもしれません。ただ、改善し続けるSaaSをこの手法で開発し続けるのはかなり難しいと考えます。もし実現できるのであれば、米国企業が中心の世界のサービスの中で、日本の伝統的企業も顔を出しているはずです。やはり、そこには開発だけにとどまらない、滑らからさが必要になるのです。
「トヨタ自動車などは世界のトップを走っているじゃないか」という考えもあるかもしれません。カンバンという方式を世界に展開した功績は本当に素晴らしいと思います。何十年もかけてその方法を磨き、自分たちのやり方をグローバルに展開し、現在に至っています。最近ではTeslaのギガプレスなどは新しい技術を使って違う形で生産性を上げようとしています。
少数の日本企業を見て、自分たちのこれまでのやり方を正当化することもできますが、ソフトウェア開発手法においては「世界を変えよう」とするよりも「自分たちを変える」ほうが、効率は良いと思います。
サービスが目指すゴールによって、手法であるHowは当然変わりますが、近年のソフトウェアの進展の速さを見る限り、スピード、スケーラビリティは重要視されるべき指標です。海外のメンバーが話していた、「日本の伝統企業におけるクラフトマンシップは大切である。ただ、それらを大切に扱いながらも、最も重要視すべきなのはスピード、スケーラビリティである」という言葉は、私の中に強い印象として残っています。
何かのタスクをこなすための「阿吽の呼吸」で部分最適化はできたとしても、全体として早く進むことを妨げます。かつてのモノリシックなアプリケーションの作り方ではなく、マイクロサービスで構築することも増えてきました。これには幾つかの理由がありますが、スピードを持ってスケールしていくための手法でもあります。
「なぜ作るのか」「ユーザーの課題は何なのか」。それらを大きな要件とともに開発チームに言語化して提示し、開発側が降ってきた要件ではなく、目的から自らスペックを定義し、自らの責任で世の中に提供できるようにすることが必要です。そのフィードバックを組織として受けとめ、また開発チームに提示する。そういう責任感を持った繰り返しのサイクルがより良いサービスを作っていきます。
次回は次のような一部の日本企業で指摘されるあいまいさ、その場しのぎ的行動が引き起こす問題について書きたいと思います。
- 誰も決めようとしない会議
- お利口さんな振る舞いをよしとする雰囲気
ぜひご期待ください。
Copyright © ITmedia, Inc. All Rights Reserved.