こんにちは。アクセンチュア ソング Build の松尾です。カスタマーフロント領域のシステム開発を行うアクセンチュア ソング Build は、他のチームとも積極的にコラボレーションしてプロジェクトを進める「With Build」という戦略を持っています。

「With Build」を体現するプロジェクトの1つとして、とある企業の対従業員向けアプリケーションの開発があります。今回はそのプロジェクトからBuildチームの浦木さん、アプリケーションのデザインを担当したアクセンチュア ソングDesignチームの大塚さんと木谷さん、そしてアクセンチュア ソング Build のCoLeadである中尾達也さんを迎え、BuildチームとDesignチームのコラボレーションをいかに実現したかを振り返りました。

With Build とは何か

松尾：
今回のコラボレーションのキーワードである「With Build」とは具体的にどのような戦略なのでしょうか？

中尾：
私は去年の6月に旧組織からメンバーと一緒にBuildのチームに加わり、CoLeadをしています。「With Build」は去年の7月に発表したBuildの戦略の1つです。これまでの「モノづくりをやり遂げる」という枠を超えて、テクノロジーを熟知する立場でお客様の課題を聞き解決策を考えるところから価値を出したい、アクセンチュア ソングの色々なチームを繋ぐ役割を担いたい、という思いを込めています。

もう1つ僕自身が旧組織であるベンチャーを経営していたときにデザイナーやコピーライター、エンジニアが一緒になってものづくりをしたのが楽しかったという経験があり、アクセンチュア ソングBuildでもそういった働き方ができたらという思いもあります。

それぞれのチームに求められたこと

Designチームのミッション

松尾：
Designチームの方々は今回のプロジェクトで短期間でアイデアを出し、プロトタイプを作成したと伺いましたが、Designチームに求められていたのはどのような役割だったのでしょうか？

大塚：
本プロジェクトにおいてDesignチームには2つミッションがありました。1つは業務で使うアプリという特性から、ユーザーが使いやすいベーシックな見た目のデザインにすること。

もう1つはそこからワンステップ上がって仕事のモチベーション向上につながるようなワクワクする体験を設計することでした。一般的なアプリ改善はデザインの使いやすさに終始しがちなのですが、本プロジェクトでは直接ユーザーの声としては上がってこないような「こういう機能があったらワクワクする」、「モチベーションが上がる」といった要望を含めて体験を描き、Buildチームに具現化してもらいました。

木谷：
今回のプロジェクトで使ったSalesforceのモバイルアプリの標準のコンポーネントだけでは、我々の思い描く体験の実現は難しそうに感じました。そこを浦木さんたちとも相談しながら、どのような表現であれば実現できるのか、いかにワクワクする体験にできるかを工夫するのがDesignチームの大きな役割でした。

Build チームのミッション

松尾：BuildチームはDesignチームから挙がってきた案の実現可能性を調査したりプロトタイプの作成を行う中で、具体的にどのような役割を担ったのでしょうか？

浦木：
大きく分けて3つの役割がありました。1つは今お話しいただいたように、デザインに対して「そのデザインが実現できるかどうか」というところのチェックです。

2つ目に、チェックしたものを全て実装してしまうと工数がものすごいかかってしまうので、Designチームに対して「デザイン自体は可能でも、実際に実装するにはこのぐらい大変だよ」という工数感を伝える役割もありました。

3つ目に実現可能かどうかチェックしたもので、「実装すると理想のものができないかもしれない」というときに、そのまま「できません」と弾いてしまうのではなくて、代替案を提案する役割も意識的に行ないました。Buildの技術観点から「実はSalesforceだとこういうこともできます」や、「こうした方がもっといいアクションに繋がりやすい」など、「こうすれば求めている機能が実現できると思います」といった提案をしていく。

つまり、実現可能性と実際それができるかどうかという工数感と代替案を出すという3つが大きな役割として求められていたのかなと思います。これがまさにこのプロジェクトに入るときに中尾さんから言われたことでした。

中尾：
そこはきつく言ったもんね笑。

浦木：
そうですね。そこを具体的にしないと後々デザインの部分でもできることと、できないことがあやふやになってしまいます。「そういう点はしっかりと詰めておかないと、このプロジェクトはダメになるよ」と言われたので、すごく意識してやっていたかなと思います。

大塚：
今のお話を聞いて、なるほどなと思ったのですが、代替案を技術観点から出してくれることがありがたいんですよね。代替案を聞いてこちらも新しいアイデアを考えやすくなります。我々はもちろんデザインの観点や知見から世の中的に良いアイデアは出せますが、技術観点の意見を聞くことで、もっと良いアイデアに昇華できた場面も結構ありました。こちらが出したものを「できました」「できません」だけではなく、双方で意見を出し合えたというのが良かったですね。

中尾：
素晴らしい。涙が出てきますね。そういったコラボレーションが素晴らしいと思うんですよ。

大塚：
あと、こちらから「デザインをこんなふうにしたいんだ」と伝えるときに特に気をつけていたのは、「なぜこうしたい」や「ユーザーがこうしたいからこの画面デザインになっているんだ」というようにできるだけ背景や理由を添えるということです。だから代替案を出していただくときもその理由が損なわれることがなくて。なので、できるだけ「ユーザーがこう言っていた」とか「こうしたい」を伝えるのは、結構自然なコミュニケーションでしたね。

コラボレーションがうまくいかない事例の共通点

松尾：
BuildチームとDesignチームそれぞれが自分の範疇を一歩超えて、お互いに必要な情報を提供しあって共通のゴールに向けて一緒に進めていくという姿勢が今のお話だけでもすごく伝わってきました。逆にこれまでDesignチームとコラボレーションがうまくいかなかった経験はありますか？

中尾：
よくあるのはデザイン会社と開発会社が別々であるために、先ほど浦木さんと大塚さんが話していたみたいなコミュニケーションが一切ないまま、「これはどうやって実現するんですか」みたいなデザインが出てきて対立構造になっちゃうことですね。

大塚：
同じ会社でもプロジェクトが一緒にならない限りそんなに話す機会ないじゃないですか、だって皆さん初めましてでしたし。その状態だと普通はさっきおっしゃていたように、ともすれば別会社同士がやる状態にならないよう注意が必要ですよね。

中尾：
だから、さっきのコラボレーションというところで「Designチームを抱きしめにいけよ」って浦木さんに言ったんですよね笑。「君（浦木さん）が技術わかってるのだから」ってね笑

浦木：
そうですね笑

中尾：
相手をリスペクトし「やりたいのはわかります」と言いつつ、「でも、これはちょっとお金かかりすぎるからできない」と。でもやりたいことは汲む。それを実現するのが僕たち(Buildチーム)だから。その代わり、厳しいことを言えば「ふわっとしたもの出さないでくれよ」ということですよね。「何となくいいと思います」とか、あるいはたくさんある画面の中で1個だけ作って、「これをお客さんと通しました」というのは、許さないですよっていう。

やっぱりその厳しさと、作りたいものを一緒に作ろうというやり方は基本姿勢としてすごい大事じゃないかなと思う。基本なんだけど、ちゃんと実現するには簡単な話じゃないですよね。

松尾：
Designチームの皆さんはこれまでコラボレーションが難しいと感じることありましたか？

木谷：
開発者の方はテクノロジーでどんなところが実装で大変かをわかっているので、自分の感覚からすると保守的だと感じることが多かったですね。デザイナーが「こういうリッチな動きを作りたいよ」と伝えて、開発者の方が「うんわかるよ。できたらいいね」と言ってくれるのですが、「実装としてできるのは、ここまでですね」と。デザイン上ではすごいリッチな動きだったんだけど、実装するとそれがちょっと、さびれたというか、普通の感じになるというのは、今までかなりありましたね。

大塚：
わかりやすい例だと、「これやったらお金が（かかりすぎる）」という問題です。コスト削減や確実に売り上げ向上に繋がる取り組みには「よしやろう」とGoが出やすいんです。けれど、デザイン的なワクワクすることや、実はすごい大事なキラキラした部分って、Goが出にくい。そういうところが難しい点としてありますね。

コラボレーションを成功させた秘訣

松尾：
今までだったら難しかったBuildチームとDesignチームのコラボレーションを最大化できた秘訣や意識したのはどのようなことでしょうか？

大塚：
最初の雰囲気がまず良かったですね。元々Buildメンバーに包まれていたというか、浸透していった感じがある。「初めまして」のタイミングからお互いリスペクトし合う感じが出ていたのは良かったですね。彼らは「いいものを作りたいと思っているし、それを実現できるかどうかを検証して提示していきたい。できない・作れないものはないので」と言ってくれた。

浦木：
そんなこともありましたね笑。確かに我々の想いとして、最初からできないという姿勢で挑むのではなく、「どうにかしてデザインを実現したい」という思いで初回ミーティングに臨んでいました。第一歩としてそれが重要だったのかもしれません。

大塚：
初対面では相手と揉み合うことが多いと思っていましたが、彼らは「どんとこい」という第一声を出してきた。「これはいい予感がするな、このチーム、絶対いいだろうな」と感じました。また、プロジェクトが始まってDesignチームで飲み会をやろうとなった時にプロジェクト全体に声を掛けました。その時に浦木さんが、こっちも初めましてなのに1人「僕飲み会行きます」って来てくれた。最初から、どっちかというと私の印象は飛び越えてきてくれた、飛び込んできてくれたのがすごい印象強いですね。

浦木：
プロジェクトが始まったばかりで知っている方がいませんでした。また、ミーティングも顔出ししないことが多いのでどういう人かもわからない状態で、多分これからコミュニケーションをとりづらいだろうなというのがあって。顔を知ってる方がコミュニケーションするにあたってお互い「今この人は多分こういう感情で発言しているのだろう」と思えるなと。なので、まず顔を合わせるのが大事だなと思って、飛び込んでみたっていうのはありますね。

木谷：
初めて会う時、普通だと機械的な挨拶やミーティング進行になりがちですが、DesignチームとBuildチームは割とすぐに仲良くやっていけた。コミュニケーションの面では、顔を合わせることが大事だなと改めて感じましたね。

浦木：
コミュニケーションの面では、顔を合わせたことがやはり良かったですね。作る部分としては、Buildチームとしてはプロトタイプを作成したときにDesignチームに、デザインが実際にどれほど実装できるのかお見せしたんですがその時に、「すごい！！」と言ってもらえるのをちょっと意識してというかそれを期待して、「こうすれば絶対に驚くだろうな」とい作った先をイメージしながらやっていました。

中尾：
プロトタイプが上がったとき、「これすごいね！めっちゃ良いやん！」ってオフィスで話しましたよね。Designチームの反応も良かったって言ってましたもんね。

浦木：
そうなんです。Teamsで拍手やハートのアイコンがいっぱい上がったときは嬉しい。そういう反応が楽しみっていうのはありましたね。

あと、どうにかして実現したいと思えたというか。なんで思えたかというと、多分コミュニケーションをとって、「このデザインはこういう背景があって」などを聞いて、「デザインもめっちゃいいですから、これ作りたいですね」みたいな。

それと「そもそもSalesforceのプラットフォーム上で（こんないいもの）作れたことなんてないだろう」というのがあったんで。今までやったことないことをやるというところに対してもBuildチームとしてはモチベーションがあって、できたのかなと。

中尾：
でも、「何でもできます」というのは、裏で注意をした気がしていて、、、。フィジビリティ、管理表ではどのくらいカスタマイズするのかとか、プラットフォームを破壊的にカスタマイズするとまずいよねというようなバランスは当然見ながらやらないと、というのはBuildチームに対して言いましたよね。

浦木：
確かにそうですね。私のSV（スーパーバイザー）とはDesignチームとのミーティングが終わった後にラップアップで「あそこの実装ちょっと危なくないですかね」みたいな、バランスは確かにとっていましたね。

中尾：
やっぱりそこがモノづくりの大事なところで、実装する・しないの真ん中のあたりを取るというバランスがないと、破綻してしていたと思いますよ。だからそこのバランスを見てプロジェクトマネジメントしている皆さんも温かく見守ってQCDをちゃんと確認しながらコントロールしてくれたというのはすごくあると思うので。

浦木：
結果的によかったのは、途中でカスタマイズではなくSalesforceの標準コンポーネントのみを採用する標準化の話が出たこと。カスタム実装とは相反する考えだったけれど、そのタイミングでお互いのいいところを取るにはどうすればいいのかを考えるきっかけになりました。それがなかったら、全てカスタム画面になっていたかもしれないです。

中尾：
破壊的にカスタマイズして、もう作った者にしか分からないシステムができあがって...ってよくあるじゃないですか。そこのバランスは実はうまくコントロールしなきゃいけない。

木谷：
そうなんですよね。初めはカスタムで完全に寄せることがいいと考えていましたが、Salesforceの標準化の話が出た時、後にどれをカスタムし、どこを標準機能で実装するかというバランスが重要だと気がついたんですよね。

大塚：
デザインとBuildチームで標準なのかカスタムなのか対立することもあったのですが、重要なのはそこで「なぜその提案をしたのか」を理解し合えるまで会話をひたすらできたことでした。そのおかげで意図を理解できたし、信頼関係を深めることができたんじゃないかなと思います。

浦木：
プロジェクトにおいて「標準化」という話が出てきたのは決して悪いことではなく良いきっかけだったと思っています。ただこうした大きなテーマを話すときは話を受け取る関係者がどのような気持ちを抱くのかを考える必要があるかなと。なので、今回の話であればDesignチームがこの話を受け取りやすくするために技術的背景やプロジェクト事情をオフィスに出社して木谷さんとランチに行って個別に話したりしてDesignチームとの信頼関係が崩れないようにすることを意識しましたね。

今後の展望

松尾：
今回プロジェクトで得た経験を踏まえて、皆さんの今後の展望をお聞かせいただけますか？

浦木：
今回学んだ技術面、コラボレーション面での経験を他でも活かしていきたいと思っています。技術観点では、プラットフォームを使って何かを開発するときにカスタマイズするべきところと標準を使うべきところなどの知識・見解を身につけたと思います。コラボレーション観点では、Designチームとコラボレーションすることによるモノづくりの楽しさや、信頼関係を築いていくことの楽しさを経験することができました。これらの経験を活かしてプロジェクトの要件定義や開発という部分に関わっていき、「より良いものを作っていきたい」と思っています。

それと今回のプロジェクトは対従業員向けのアプリケーションの開発でしたが、「体験」というとどうしてもToC向けの「表に出やすい体験」が語られると思います。裏側であるToB向け、従業員向け体験はまだおざなりになっているというか、改善されていないところがいっぱいあると思うので、そういった部分の体験を向上していくプロジェクトに関わっていけたらと思います。

大塚：
浦木さんと重なるところもありますが、個人的にも今回「楽しかった」です。なので、楽しいことを全然知らない、このやり方も、このコラボレーションのあり方の「大変だけど成立したらめちゃめちゃ楽しい」ということを知らないDesignチームのメンバーに、この楽しさを伝えていきたいなと思っています。

また今回、浦木さんが他チームの輪に飛び込んでくれたことでその価値とか嬉しさを知ったので、今後Buildの皆さんとプロジェクトでご一緒するときはこっちから飛び込んでいって同じような関係を作れるようになりたいと思っています。 

木谷：
これまでは体験として一番良いものを自分たちがデザインして、「あとはよろしく」と開発チームに渡して終わりだったんです。

だけど、そうして「フルカスタマイズしたアプリはデザインとしては良かったけれど結局保守ができず継続的に使えなくなる」ということを聞いたことがあります。なので、今回みたいに良いところや作り込みたいところはカスタマイズ、そうでないところは標準でやるというUIのハイブリッドの事例ができたのはすごい大きいなと。これ本当に2回目やる時も余裕が全然違うと思うんですよ。

中尾：
2回目に余裕ができるっていうのが最高ですよね笑

木谷：
気持ちの余裕が全然違うと思うんですよね。「あーそうそう、Salesforceでカスタム画面を作る時はこういうところに気をつけるんだよ」とか

中尾：
それが最高なんですよ。

木谷：
そうなんです。デザイン側のメンバーでまだこういう経験をしていない人に、伝えられることは伝えていきたいですし、会社としてどんどん他の案件でも応用できたらすごく良いなと思いました。

それとToB向けのアプリは表に出ない分、割と地味目なことが多いのですが、従業員の体験を本当に変えられると思うんです。表に出なくてもやりがいはあるので、デザインの若手に「こういうやり方も面白いよ」と伝えたいですね。

「一緒にモノ作りすることの大切さ」が組織にもたらす影響

松尾：
メンバーの皆さんからコラボレーションの良さを伝えたいという思いが特に感じられました。アクセンチュア ソングBuild CoLeadである中尾さんから見て、今回のプロジェクトにおけるコラボレーション事例は組織にどのような影響を与えると考えますか？

中尾：
今回は「とにかくDesignチームの皆さんと一緒にモノづくりをする」ということをやりたかったので、それができたことがまず成果だったんじゃないかと思います。

コラボレーションの中でDesignチームが考えるモノづくりと我々Buildの人が考えるモノづくりが違うというところを経験できたことは、組織にとって良かったなと思います。カスタマイズなどプラットフォームの制約をちゃんと話し合わないとやりたいことがすり合わなかったり、すれ違いが起こって問題が発生したりということがあると思うんだけど、そうしたお互いの違いを経験できたのが良かったなと。

これの何が良いかというと、繰り返すことによって自分たちのできる範囲がどんどん広がり、それぞれの専門性が世の中の役に立つというような一体感、そういうことを知っているモノ作りの集団の一体感みたいなものがこの取り組みをもとに次、次やる時に「もっと面白いの、もっと良いのができる」と実感できるんですよね。

そして今回みなさんがおっしゃっているように、プロジェクトを通じて感じた「コラボレーションでのモノづくりって面白い」という感覚を他のプロジェクトやメンバーに伝播させていくということが組織としてすごく大事だと思っています。

自分の影響下において「モノづくりを楽しくする」ということを自分の心の中に持って仕事ができる人たち、そういう気持ちを持った人たちがたくさん増えていけば、おのずとみんなが楽しんで、お客さんとクライアントワークができる会社になると思っています。これが最大のメリットですね。これからもこうしたコラボレーションができれば良いなと思っています。

アクセンチュア ソングではこうしたDesignチームとBuildチームがコラボレーションして楽しく働けるプロジェクトを今後も増やしていきますので、コラボレーションできる仲間と出会えるのを楽しみにしております！

筆者プロフィール