ソフトウェアの「アジリティ」と「品質」をトレードオフにしない、プロダクト開発の理想型｜Tably及川卓也×Autify 近澤良
ソフトウェア開発においても重要なキーワードとなっている「アジリティ」。激しい市場変化への対応力、機敏性を意味する言葉だ。あらゆる産業でソフトウェアを主体としたビジネスへとシフトするなか、その「アジリティ」と「クオリティ」をどう両立するか。そのためのプロダクト開発の理想型とは？ Tably及川卓也氏 × Autify 近澤良氏の特別対談をお届けする。
プロフィール
▼及川卓也（写真左）
大学卒業後、外資系コンピューター企業に就職。ソフトウェアの研究開発に従事する。その後、外資系IT企業にて、プロダクトマネージャーやエンジニアリングマネージャーとして勤務の後、スタートアップを経て、独立。2019年1月、テクノロジーにより企業や社会の変革を支援するTably株式会社を設立。著書『ソフトウェア・ファースト～あらゆるビジネスを一変させる最強戦略～』（日経BP）、『プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで』（翔泳社）
▼近澤良（写真右）
日本、シンガポール、サンフランシスコにて、10年以上、ソフトウェア開発に従事。DeNAにてOSSのゲームフレームワーク、全米No.1となったソーシャルゲームの開発に携わり、シンガポールのVikiに入社。プロダクトエンジニアとして製品開発をリード。その後、サンフランシスコへ移住、現地スタートアップに初期メンバーとして参画。2016年に退社し、Autify, Incを米国にて創業。2019年1月米国トップアクセラレーターAlchemist Acceleratorを日本人で初めて卒業している。
アジリティがなければ、もはや勝負にならない。
ソフトウェア開発の現場でも重要なキーワードとなっている「アジリティ」。激しい市場変化に対応する力、機敏性を意味する。一方でアジリティを追求すればするほど、それまで基準としてきたクオリティの維持も難しくなっていく。このジレンマをいかに解消していくか。対談は「アジリティ」に対するそれぞれの捉え方からスタートした。
及川：
近澤さんは日本でも海外でもソフトウェアエンジニアとして働かれてきた経験をお持ちですが、そもそも「アジリティ」については、どのような捉え方をしていますか？
近澤：
まずビジネスの文脈での「アジリティ」でいうと、本当にここ10年、20年ほどで市場の変化がどんどん激しくなっていますよね。わかりやすいところで、iPhoneが登場し、新たな市場も立ち上がり、世界をリードするテック企業がどんどん誕生した。
変更ができ、環境変化にも強いソフトウェアを主体とするビジネスが増え、ドラスティックな進化を遂げていて。そう考えるとアジリティがなければ、もはや勝負にならないわけですよね。当然、ソフトウェアにもアジリティが求められる。日本の大企業でも、多くの人がアジリティが持てていないことに危機感を抱いている現状だと思います。
及川：
日本企業でいうと、ほんの数年前まで海外のテック企業に対して「彼らと我々は違う」と線引きする風潮もありましたが、もはやビジネスにおいて身近な脅威になっていますよね。
また、近澤さんが「DX」や「IT」ではなく、「ソフトウェア」と言われたのも重要だと思っていて。「通信技術」と「ソフトウェア」の進化は、あらゆる産業が大きな変化をもたらしていて。
なぜ、海外のテック企業がここまで成功したのか。もちろんさまざまな要因はありますが、アジリティ、ベロシティを最も重要視してきた。つまり、提供するサービス、ソフトウェアにおいて、アップデートがかけられる前提で「確実に変化し続けてきたこと」が、大きな成功の要因だったのではないかと思っています。
近澤：
先日、トヨタが「ソフトウェアファースト」を掲げていて、それこそ及川さんが出された著書と同じキーワードですよね。ハードウェア領域でもその重要性について盛んに議論されていて。自動車でいえば、ソフトウェアを頻繁にアップデートしていくテスラも象徴的ですよね。
ミニウォーターフォール化する、アジャイル開発の罠
アジリティの高さが、優位性となる時代。ソフトウェア開発における方法論として「アジャイル開発」には陥りがちな罠があるという。
及川：
いかにアジリティを高めていくか、ここは非常に重要なわけですが、もしかすると「アジャイル開発をすれば、アジリティが確保できる」といった勘違いが生まれているケースもあると感じていて。このあたり、どう思われますか？
近澤：
誤解のレベルはさまざまあるかなと思うのですが、当然、アジャイルの方法論だけでは、開発は早くはならないわけですよね。どこまでのクオリティを担保するか。そのためのテストをどうするか、そこにまつわる要件定義、意思決定を誰がやるのか。そもそもベンダー依存体質になっていたら、内製開発へのシフトが必要だったりもして。本来は考えることがたくさんあるのかなと思います。
及川：
大企業でもアジャイル開発の「認知」は上がっていて、取り入れやすくはなったと思うのですが、ベストプラクティス的なプロセスが「儀式」化してしまうケースは多いですよね。そして起こる問題が、本来の目的から離れて「アジリティ」と「クオリティ」をトレードオフで考えてしまうこと。
要するに「アジャイル開発によってアジリティは高まったが、クオリティを下げてリリースする」のか、もしくは「品質基準を変えないまま、アジャイルの方法論にだけ囚われて突き進む」のか、この二者択一で考えてしまう。
クオリティを下げればいいとは全く思わないのですが、本当の意味での「必要なクオリティ」を確保するためにはやるべきことがある。
もともと、製造業、通信事業、設備産業など、日本の主力産業において「品質」は重視されてきましたし、実際、とても重要なものでした。ただ、あらゆる産業が「サービス」を提供するサービサーにシフトしているなかで、いわゆる「形あるモノにおける品質」と、「サービスにおける品質」は、定義を変えないといけない。ここを同じ定義でやってしまうと「手戻りできない、変更ができないもの」が前提になってしまう。
近澤：
そうですね。手戻りさせるのが、アジャイルのいいところでもありますよね。まずアジリティとクオリティにおける「トレードオフ」の考え方、そのものを変えないといけないと思います。ここは両立ができるもの。
前提として完全にバグがない状態でソフトウェアを出すことは理論上不可能に近い。一定のラインで諦めなきゃいけない。その前提に立ち、どこを絶対に守るのか、どこまで許容するのか。定義とバランス、全てをセットで考えていくことが理想だと思います。
及川：
ただ、実際にどう動かすのかが、すごく難しい。「クオリティ」は絶対的な尺度だと思われがちですが、じつは事業のステージ、ユーザーによって求められるものが異なり、相対的に変化しまう。それがわからないままだと、品質基準だけが独り歩きしてしまう。
すると、表面上はアジャイルでも、ウォーターフォール的に細かくステージゲートを設け、品質を確認しながら突き進み、破綻してしまいます。
近澤：
アジャイルがミニウォーターフォール化するパターンですよね。単に期間を細かく区切っただけで、結局はチェックリストそのものは見直せていない。そのリストに沿ったテストに膨大な時間を費やしてしまう。そうならないために、いわゆるシフトライトなアプローチも考えていくべきだと思います。
及川：
この「一部はリリースしてからテストする」という考え方は、日本だと少し前までとんでもない話だったんですよね。「お客さんを何だと思っているんだ！」と。確かにその通りなのですが、むしろ“サービスとして価値あるものが提供できているかという意味での品質の判断を自社だけで全て行なえる”と考えるほうが傲慢だと言える時代になってしまった。実際に使えるものか、ある意味、お客様にも確認してもらいながら巻き込んで開発していく。それが本当の意味で「顧客のことを考える」につながっていくとも思います。
高まる、E2E （End to End）テストの重要性
「アジリティ」と「クオリティ」をトレードオフで考えるのではなく、両立を目指していく。その時に課題となるのが、どうしても労働集約的になってしまうテストの工程だ。いかにこの課題を解決していくか―。
及川：
『Autify』の話につなげるわけではないですが、アジリティとクオリティを両立していこうと考えると「テスト自動化」は避けて通れないテーマですよね。
近澤：
そうですね。もう前提として考えなければいけないものだと思います。たとえば、Netflixでいえば、1日に1,000回、デプロイしていると言われていて。自動化を前提にしないとまずできません。
当然、アジリティだけがビジネスの競争力を高めるわけではないですが、テストは自動化でき、労働集約から脱却できる領域。なので、やるべきですし、本来はプロジェクトの途中ではなく、立ち上げる時から考えなければいけないテーマだと思います。
及川：
もう「何度もリリースしましょう」というのは「事業の仮説検証を素早く回しましょう」に等しいのでしょうね。ビジネスのアジリティを追求すると、自ずと開発のアジリティが必然的に出てくる、という話でもありますね。
近澤：
SaaSが台頭してきて、するとSaaSのお客様のなかには「ロードマップが共有されていて、アップデートが頻繁にあるから契約を決めた」という方もいる。品質を保証しつつ、継続的にアップデートがかかることに価値が生まれ、ユーザーに選ばれていくのだと思います。
及川：
少しテストの話に戻るのですが、改めて、ソフトウェアにおけるテストについて全体像と、自動化が進んでいる領域など解説をお願いしてもいいでしょうか。
近澤：
まずソフトウェア開発のテスト領域は大まかにUnitテスト、Integrationテスト、E2E （End to End）テストの3つから構成されているといっていいと思います。
こういったピラミッド型で表現されることが多く、図ではよりわかりやすいように、E2E （End to End）テストのなかでも、自動化している「Automated E2E」と、手動で行う「Manual E2E」に分けています。
このピラミッドの下にあるテストほど「量として多く揃えましょう」というのが、業界全体の共通認識にあると思います。
Unitテスト、Integrationテストは、いわゆるホワイトボックステスト。コードがどう構成されているかがわかる、エンジニアがメインで書くテストです。
そして、ピラミッドの上にあるE2E （End to End）テストは、いわゆるブラックボックステストと呼ばれ、コードや中身がわからなくても書けるテストです。わかりやすいところでは、ユーザーが実際に触って動くか、UIが絡むテストなどを指します。
ホワイトボックステストについては、書いて当たり前といった価値観が日本でも浸透しており、自動化が進んでいると思います。ここはTDD（Test-Driven Developmenttdd）的なアプローチで直したり、エンジニアの責務で行うことがほとんどかと思います。
E2E （End to End）テストに関しては、手動でやるのも、自動でやるのも、すごくコストがかかるところ。『Autify』はここの課題を解決しようとしています。
そもそも、E2E （End to End）テストは、コストがかかるので「可能な限り減らしていくもの」としてピラミッドの上にあり、領域も小さい。ですが、本当にユーザーが恩恵を受けられるか、検証のためには最も重要なテストでもあります。このコストを下げられれば、ピラミッド型そのものを見直してもいいと考えています。
及川：
あえて極端に言うと、E2E （End to End）テストを充実させれば、カバレッジが高くなかったとしても、ホワイトボックステストで担保すべき品質もカバーができると？
近澤：
それでいうと代替するわけではないので、両立は必要だと考えています。ですが、今までE2E （End to End）テストに費やしていたコストを減らすことができれば、Unitテストなども改善しやすくなる。「ピラミッド型」が、もっと「四角型」に近づくイメージかなと思います。
もうひとつ、逆にいわゆるアンチパターンとして「アイスクリームコーン型」になっているケースも多いと思います。
Unitテストが無さすぎて、E2E （End to End）テストでカバーするしかない。じつは多くの企業で見受けられるケースなのですが、いきなりピラミッド型にするのは難しい。それであれば、1番上にある「Manual E2E」をまずは自動化し、徐々に下っていくなかで改善していくのはどうか？と私たちは提案をしています。
E2E （End to End）テストのコストが下がれば、ピラミッド型である必要はないですし、カバレッジが高く担保できれば、お客様に価値が届けられている証明になると思います。
及川：
Unitテスト、Integrationテストでいえば、Webでも、スマートフォンでも、100%ではないですが、ほぼ自分たちでコントロールできる領域でもありますよね。ですが、E2E （End to End）テストになると、まだまだブラウザは複数あるし、OSも複数あり、自分たちではアンコントローラブル。にも関わらず、いろいろな不具合に対処しなきゃいけない。ここもE2E （End to End）テストを充実させなきゃいけない理由の一つですよね。顧客からすれば、問題は問題なので、どこで起こるかは関係がないわけで。
近澤：
そうなんですよね。それこそ、SaaS間の連携が前提になると、自社コードだけ参照するホワイトボックステストではサービス全体の品質の担保が難しくなるため、E2E （End to End）テストで品質を担保していく必要がありますよね。もはや自分たちで全てのソフトウェアをつくる時代ではないので、今後さらに顕在化してくる課題だと思います。
組織として「テスト自動化」を戦略に組み込めるか
E2E （End to End）テストの重要性が高まるなか、いかにテスト自動化を組織として戦略に組み込めるか。そもそもどういった組織のパターンがあるのか。話は展開されていった。
近澤：
まずアメリカのトップテック企業でいえば、テスト自動化専門のエンジニア、たとえば、SDET（Software Development Engineer in Test）と呼ばれるような人たちがいるケースがあります。彼らは仕様を決めるところから入り、開発と同時にテストの自動化コードも書いていく。スクラムでいうDefinition of Done（完了の定義）のなかに自動化コードが全て入っている状態にする。ここはコストがかかる部分でもあるので、トップテック企業が頑張ってるところだと思います。これができれば理想だとは思います。
ただ、多くの企業はSDETを採用するような採用力はないので、E2E （End to End）テストも含め、開発エンジニアが自動化コードを書くケースが多い。そのなかでもQAチームがあったり、なかったり、さまざまだと思います。
また、ウォーターフォールからアジャイルが主流になるなか、QAチームの役割も変わってきたように思います。従来のQAチームは「品質における最後の砦」でしたよね。もし品質に問題があったらQAチームの責任ですが、作るのは開発チームなので、敵対する構造がよくあって（笑）
ですが、アジャイルでリリースサイクルを早めていくとなると、QAチームを「最後の砦」にすることは無理がある。そうなると、QAチームは「品質のあり方を決め、道筋を決めていく役割」へとシフトしている気がします。
及川：
先ほど、理想型としてアメリカのトップテック企業がSDETを採用し…というお話がありました。採用力もそうですが、仮にコードが書けるエンジニアがいて、雇う側はテストよりプロダクトコードを書かせたいですし、エンジニア自身もテストよりプロダクトコードを書きたい人のほうが多く、全体的にもニッチで。特に日本ではエンジニアは奪い合いが起こっている。そういったなかで、いわゆるローコード、ノーコード的なところを活用し、自動化することで、エンジニアのリソースを確保していく。ここが重要になるわけですね。
近澤：
そうですね。そこが私たちが目指しているところでもあります。
及川：
業界全体としても、E2E （End to End）テストの自動化はさらに進むと思うのですが、最後に考えたいのが、組織において誰がそこを担うか。プロダクトマネジメントの観点からすると、技術者上がりのプロダクトマネージャーでなければ対応が難しいところだと思うのですが、誰が、どう関与していくといいと思いますか？
近澤：
そこは本当に難しいところですよね。私自身は、プロダクトマネージャーがある程度は知識を頭に入れ、アジリティ、担保すべきクオリティ、テストの自動化をセットに考えていくといいのかなとは思います。
及川：
プロダクトマネージャーは「What」を決めることが重要な役割ですが、クオリティに関しても判断できたほうがいいということですよね。少なくとも自分なりに意思決定できるようにしておく。それこそ「アジリティ」と「クオリティ」をトレードオフにしないために。そう考えると、逆に仕様を削る、そういった引き算もプロダクトマネージャーの役割ですよね。事業価値とプロダクト価値にかなり影響を与えるところでもあるので。
ただ、技術者あがりではないプロダクトマネージャーにとって「E2E （End to End）テストの重要性が増していく」というのはいいことでもあって。言ってみれば「目に見える領域」のテストの自動化なので、理解しやすい。そこから入って知見を溜めていくのもいいことだと思いました。
近澤：
そうですね。実際に『Autify』もプロダクトマネージャーの方が使っているケースもあります。委託されて開発する際に、発注元側と近しい環境でテストするような受け入れテストで使われるケースが多いですが、そういったところから入っていくのも方法としてあると思います。
及川：
エンジニア、QAチーム、プロダクトマネージャー、どこが担っていくのか。組織としてはさまざまなパターンがありそうですが、本質的には、組織課題として「アジリティ」と「クオリティ」の両立に取り組み、戦略に組み込めるか。改めて、ここが市場変化が激しい時代、ユーザーに選ばれるために重要なポイントになりそうですね。
