3カ月で「本当にユーザーが求めるサービス」を生み出す。いま注目の開発会社が徹底していること

2020/03/13
  • facebook
  • twitter
  • このエントリーをはてなブックマークに追加
  • linkedin
  • line

日本企業の多くでは、社内の「上司と部下」、社外の「クライアントと“業者”」といった上下関係がコミュニケーションや取引の前提となっています。

その中ではしばしば、商品・サービス開発においてプロジェクトのゴールを見失ってしまったり、消費者やユーザーにとって魅力あるプロダクトやサービスを生み出せなかったりすることもあります。

アジャイル開発のコンサルティングを行うPivotal Labs(以下、ピボタル)では、クライアント・ピボタル双方の担当者が1対1のペアを組み、「ワンチーム」としてプロダクト開発を行うのが特徴。

そこでは、お互いに知見やアイデア、情報を共有し、3カ月という短期間でユーザーのニーズに即した開発が可能となることから、注目を集めています。

今回はPivotal Labsのプロダクトマネジャー、エンジニア、デザイナーのお三方を迎え、チームメンバー間の不要な上下関係を打破し、ユーザーにとって本当に価値ある商品・サービスを、しかもスピーディに生み出す秘訣を伺いました。

チームの効率を高めるのは「メンバー間の対等な関係」

クライアントが抱える課題としてはどういったものが多いのですか。

小俣 当社でお取引している企業としては、ヤフーやANA、日本事務器、JR東日本など、大手企業とご一緒しています。また、ここ1年で特にお客さまから問い合わせいただくことが増えています。

それぞれ細かい課題は異なるものの、大枠としては「デジタルトランスフォーメーション(DX)を加速させたい」「よりユーザー目線でアプリケーションを開発したい」「そのために組織文化を変えたい」といった課題を抱えていることが多いですね。

プロダクト開発を行うにあたって、それにふさわしい体制を編成し、チームをよりよくしていくために、私たちが並走していく形になります。

従来は発注側と受注側との間に上下関係があることも多いですが、貴社はあくまで「並走型」なんですね。

伊藤 そうですね。同じ目標に向かって一緒に作業しているので、クライアントと「Pivots(Pivotalの社員)」との違いを感じることはあまりありません

小俣 だいたい3カ月くらいのプロジェクトが多いのですが、新しいプロダクトの開発、あるいは既存のプロダクトをよりよくしていくことを目的として、クライアントのメンバーの方には当社へ「出社」してもらうようにしているんです。

そこでは「ペアリング」と言って、クライアント側のメンバーと私たちが、それぞれ同じ役割の人とペアを組んで開発を進めていきます。私はプロダクトマネジャー(以下、PM)なので、クライアント側のPMと、エンジニアの梅原さんはエンジニアと、デザイナーの伊藤さんはデザイナーとともに仕事を進めることになります。

伊藤 朝一でオフィスの全体朝礼とチームの朝礼を行った後、ペアごとの作業に移ります。同じマシンにつながった2つのモニターをそれぞれが見ながら、横並びで同じ作業を同時に行います。

車をイメージしてもらうと分かりやすいと思いますが、一人がドライバーで、もう一人がナビゲーター。一方がメインで作業を進めながら、もう一方が「こうしたほうがいい」「こっちがいいかも」とフィードバックしながら、UIをデザインしていきます。

デザイナーとPM、エンジニアとPMといった組み合わせでペアを組むこともありますし、厳密に担当領域が決められているわけではありません。それぞれPMはビジネスを、デザイナーはユーザーを、エンジニアは技術をメインに考えてはいますが、分け隔てなくみんなでアイデアを出し合っています。

小俣 これを「クロスファンクショナルチーム」と呼んでいるのですが、F1でマシンがピットに入ると、スタッフが一斉にそれぞれの役割を担うじゃないですか。それと同じように、一つの課題にフォーカスして、真っ先にそれに取り組むイメージです。

伊藤 しかもその課題は、あらかじめ設定されているというより、まずはみんなで探し出します。従来だったらデザインをラフに絵で起こして、ある程度完成に近い状態で周りからフィードバックをもらうところを、ラフ絵の段階でまずみんなに意見をもらって、技術的に可能なのか、より機能的なのはどういったデザインなのか・・・・・・と、なるべく具体的なフィードバックをもらい、みんなでより良いデザインを作るようにしています。

フィードバックをもらうためのラフ絵
フィードバックをもらうためのラフ絵

梅原 エンジニアも同様です。場合によっては3名のこともありますが、ペアでプログラミングします。しかも毎日ペアを交代して、違う組み合わせで作業するのです。

そうするとチーム全員がプロジェクトの全容を把握することができるので、「あの人がいないと進められない」「この人がいないから分からない」といった不測の事態を回避することができます。そして、その日の作業内容をきりのいいところでまとめて、チームと共有し、18時には定時退社です。

伊藤 毎週金曜は週次の反省会を行うのですが、ビールを飲んでもOKなので結構和やかに進むんですよ。そこにある卓球台も結構活用されていて、仕事で煮詰まったらリフレッシュのために試合もしたり

一度ペアでやり始めると、もう一人だけでは進められないくらい効率が上がるんです。「悩んでるんですよね」ってペアに相談すると、それこそピンポンみたいにいろいろと意見を出し合って、「あ、思いついた!」って、スッと新しいアイデアが出てくる。一人でやっていると、悩み始めたらあっという間に時間が経つじゃないですか。

梅原 エンジニアにしても、iOSとAndroidOSの違いとか、やっぱりそれぞれ得意不得意があるんです。それをお互いに教えながら、学び合えるのも、従来の受発注の関係との違いですね。

小俣 PMの場合も、プロダクトライフサイクルがどのフェーズなのかによって仕事は変わってきますが、ペアで作業を行うことで意思決定のスピードは上がります。PMはデザイナーやエンジニアのように分かりやすいアウトプットが少ないので、意識的に自分が何を考えているかを言語化して、共有しながら進めていきます。すると、ボトルネックになっているものや、それをいかに解決するかが見えてくるんです。

価値あるサービスをすばやく。カギは「2つのフィードバック」

そうしたユニークな手法にふれることで、クライアントのサービス開発にどんな変化が現れるのでしょうか。

梅原 だいたい最初に混乱が起きますね(笑)。

伊藤 これはペアリングだけでなく、「アジャイル開発」の特性にもよるものだと思うんですが、私たちのサービス開発の手法は、一般企業の方が慣れているやり方とは「真逆」なんですよね。

小俣 従来の手法では、まず大きな計画を立てて、要件定義して、設計して、計画のはじめのほうから順々に・・・・・・と進めていきますよね。ですが僕らは、大きく計画するのではなく、アイデアをいくつかの仮説に分解し、プロダクトの価値に強く関係する仮説から検証します。結果的に開発の単位も小さくなりますね、。

なぜそうしているのでしょうか。

小俣 例えば、途中まで実装を進めていたとしても、そもそもペルソナ設定に思い込みがあるかもしれない。実際、ユーザーインタビューで仮説を当ててみると、だいたい間違っているんですよ。そのままプロセスを進めても、精度の低いものしか完成しません。

梅原 ですから、リファクタリング(改善)できないガチガチのものを作るのではなく、現時点で分かっていること、確定していることでまずはある程度作ってしまう。そうすると、より具体的な「フィードバック」が得られますからね。

結果的に、ユーザーが求めるサービス開発にスピーディに近づけると。

小俣 そう考えています。たしかに、大きな計画を立てることで、安心感を得られるし、さまざまなステークホルダーと合意も取りやすくなるでしょう。一方、僕らの手法は、よく言えば状況適応的、悪く言えば「行き当たりばったり」に見えるかもしれない。

梅原 しかし、そうして得たデータやフィードバックがさらなる仮説検証につながります。検証の結果、仮説が間違っていることに気づくかもしれない。だけど、いつでも軌道修正ができるからこそ、まったく見当違いのことに時間を費やさなくて済んだ、とポジティブに受け入れられるんです。

小俣 実際、ヤフーさんなど、プロジェクトに参加したメンバーがアジャイルの手法を身につけて、会社に帰って他のメンバーに方法を教えて、ねずみ算的にメンバーが増えていっているようです。

そうして本当に価値あるサービスを、スピーディに開発するうえで大切なことはなんでしょうか。

小俣 ここでも大切なのは「フィードバック」です。多くの日本企業だと、上司が部下に指示をすることだけがフィードバックだと思われそうですが、実際にはマネジャーとメンバーが双方向にフィードバックし合うことが重要です。

伊藤 良いフィードバックは、タイムリーであること。気づいたらその場ですぐに話すようにしています。そして、直すべきところはダイレクトに言うこと。

梅原 改善点がある場合は「ダメだったよ」ではなく、「こうしたほうがよかったね」と、改善案とともにフィードバックしてあげたほうが良いですね。

小俣 「関係を壊したくないからフィードバックしない」というのは不誠実です。かと言ってみんなの前で罵倒するのは本人のためにならない。率直さと思いやりを一緒に持つというか、お互いに尊重しながら、率直かつタイムリーに、適切な言い方で相手の成長を促すことが大切です。

伊藤 フィードバックを受ける側も、相手が話す内容に対してすぐ反論するのではなく、いったん受け入れて共感することが大切です。加えて、いいフィードバックをもらうために、ただ思いつくままに話すというより、相手の専門領域を踏まえて意図を明確にして話すようにもしています。

スピード重視の時代に大切な「ファシリテーションの4原則」

一方で、開発が遅々として進まなかったり、プロジェクトの軌道修正が必要なのに後戻りできなかったりすることは往々にして起こります。根本的な原因は何だと思いますか?

小俣 組織の中で「誰かがこう言ってる」とか「この人はこう考えるかも」とか、伝言ゲームを続けていくから苦しくなってしまう。「あなたも一緒に考えて、一緒に決めましたよね」と合意形成するのが大切です。

そのために重要なのが、いかに社内外の関係者と合意形成するか、「ファシリテーション」のスキルです。

著名なエンジニアたちが合議で決めた「アジャイルマニフェスト」という原則があるのですが、その中には次のような価値基準があります。「プロセスやツールよりも個人と対話を」「包括的なドキュメントよりも動くソフトウェアを」「契約交渉よりも顧客との協調を」「計画に従うことよりも変化への対応を」というものです。

はじめから「何を作るか」で合意していると、それが間違っていたとき、手段の目的化が起きてしまう。「せっかくここまで作ったから」と、中途半端なクオリティのものになってしまいますよね。それなら、はじめは「何がゴールなのか」「どんな仮説があって、どれから検証するか」を考える。

大手企業では1年先、2年先のビジョンや明確な成果を求められるかもしれないけど、その前に検証すべき仮説がいくつもあるはずなんです。不確実性やリスクを織り込んだうえで、何を証明するか。ゴールと現在地との距離を明確にして、お互いにゴールを認識し合うことで、社内外の協力関係を築くことができるんです。

小俣 上司の承認がなかなか下りないとか、権限委譲してもらえないからプロジェクトが進まないというなら、プロトタイプなど具体的なものを提示してみると、一気に話が進むこともあります。

伊藤 作って提示してみると、自然とフィードバックが具体的になるんですよね。権限委譲する側の心理を考えると、「まかせて失敗したら怖い」というのがある。それなら、はじめから最悪のケースをすり合わせておけばいいんです。

最悪起こりうるのはこういうことで、そうならないためにこうしましょう、2週間ごとにチェックインで振り返りの場を設けましょう、と。そうやって落ち着いて考えてみると、最悪のケースも意外と大したことなかったりするんです。

梅原 できるだけ早いタイミングでアプリをデプロイ(使用可能な状態に)して、実際に動くものを見てもらうことで不安を解消できることもありますね。

小俣 そうやってプロダクトが出来あがってくると、上司や経営陣からの信頼性も上がってきますし、彼ら彼女らの妙なこだわりも薄れていくんです。

最低限の機能を実装した段階からアウトプットを見せて、「まかせていいんだ」と安心してもらいながら、どんな仮説を検証するかはしっかりとステークホルダーを巻き込んで意思決定していく。そうやって同じ方向を目指しながら、細かくフィードバックサイクルを回していくことが、スピード重視の時代に本当に価値あるモノづくりを行ううえで重要だと思います。

Pivotalジャパン株式会社 Pivotal Labs Tokyo プロダクトマネージャー  小俣剛貴
写真左。Pivotal LabsでSIer、保険, インターネット系などのプロジェクトを担当。クライアントのプロダクトチームの育成とプロダクト開発をハンズオンで支援。Fuller株式会社 CMO、ライフネット生命 事業開発を経て、2018年1月より現職。

Pivotalジャパン株式会社 Pivotal Labs プロダクトデザイナー 伊藤えりか
写真中央。米大学で美術学士取得後、デジタルガレージにて主にグラフィックデザイン、DeNAにてUI/UXデザイン、nudo,IncではWebデザインに従事した後、2016年1月にプロダクトデザイナーとして同社に入社。Pivotal LabsではユーザーリサーチやUIも含めたプロダクト全体のデザインに関わる。

Pivotalジャパン株式会社 Pivotal Labs ソフトウェアエンジニア 梅原一造
写真右。ニューヨークで複数のベンチャー企業でのエンジニア経験を経て、2015年12月より現職。Pivotal Labsではテスト駆動開発やペアプログラミングなどの手法を取り入れながら、Webやモバイルのプロダクト開発を担当。

[取材・文] 大矢幸世 [企画・編集] 岡徳之 [撮影] 伊藤圭
2020/03/13

いいね!」していただくと、
最新記事をお届けします。

iX(アイエックス)とは

新しい時代の「はたらく」に応えるために、
人材と仕事が自由に行き交う場
「iX(アイエックス)」を創ります。
競争力ある日本の未来に向けて。