メンバー増加でお見合い状態、プロジェクトが遅延・炎上…　ゆめみ・渡部氏が失敗から気づいた、プロジェクト成功の鍵

いきなり大きなものを作ろうとして頓挫する経験を何度かしてきた

渡部陽太氏（以下、渡部）：最後になりますが、私の失敗談です。失敗からふりかえるアジャイルと心理的安全性のお話をしようかなと思います。

R&Dがなかなか進まないというのを、私は何度も経験しているのですが、みなさんはいかがでしょうか。R&Dの意味は広いんですが、ゆめみの場合は、その技術要素が実際のプロジェクトの中で有効に活用できるかと判断するための検証の開発を指します。

また、私自身ゆめみ以外の会社でも、会社の新サービスの研究開発や立ち上げを経験したことがありました。これがなかなか進まない、頓挫するという状況を何度か経験してきた中でふりかえると、いきなり大きいものを作ろうとしていたケースが一定あったかなと思います。

これも、小さく始めるのが鉄則なのかなとは思うのですが、どれぐらい小さくというのは、やはり判断が難しいですよね。「技術検証だから、最低限これぐらいの規模は試したほうがいいよね」とか「こういうサービスを作りたいから、最低限こういうものから始めようか」みたいな、それ自体がもしかしたら大きい場合もあるかもしれません。

目的ベースの最低ラインと、技術要素観点での小さい妥当ラインは必ずしも一致しないので、判断ミスを招き易いのではないかと考えています。

“チームを小さく始める”のがキーポイント

メンバーが多すぎることが課題になることもありました。業務の片手間で推進してくれるメンバーがたくさんいる。技術的にはおもしろいので、たくさんのメンバーが興味を示してくれているけど、メンバーが増えてきてしまってお見合いになるなど、なかなか進まなくなっていきます。

メンバーが多いために、みんな業務が忙しくなった時になかなか推進されなくなるケースもあったかなと思います。

逆に、少数メンバーでやると、全員が全体を俯瞰して理解する状況を作りやすいと思います。初期の段階はそういうのが大事なのかなと思います。

あとは、少数メンバーだとメッセージを濃度濃く届けられることが大きいかなと思います。なぜそれに取り組むのか、それが会社のビジネスとどう連動していくのかというメッセージを伝えやすい。少数メンバーは、そういった面でメリットはあると個人的には思っています。

iOSやAndroidに関しては、AppleやGoogleといったプラットフォーマーが方針を決めているので、そこに対してやる理由は、正直そんなに要らないと思うのですが、そうじゃないものは、しっかりリーダーから、なぜ取り組むのかというメッセージを届ける必要があるのかなと思います。

なので、チームを小さく始めるというのは、勝ちパターンではないですが、私の中でキーポイントかなとは思っています。

先ほども小さく始めるとか、チームも小さくというお話をしたのですが、技術の特性や成熟度を意識すると、どの程度のダウンサイジングが妥当か見えてくるかなと、最近感じています。

ある程度、市場に採用事例もあふれてきていて、各社が使っているので私たちもいってみようということであれば、そんなに慎重になる必要はないかもしれませんし、逆に、市場にそんなに採用事例がない未開拓・未成熟なものであれば、より小さく始める必要があるでしょう。そこのダウンサイジング感は、ある程度あたりがつくかなと思います。

かつ、やってみて、やはり大きすぎたということもあるでしょうし、そこは密にエンジニアとコミュニケーションして軌道修正できることが大事かなと思いますね。

新しい技術も不確定要素の1つとして捉える

続いて、新技術の導入によってプロジェクトが遅延するとか、言い方は悪いですが、炎上することも、私はたくさん見てきたと思います。みなさんは、いかがでしょう。みなさんもご経験はあるでしょうか？

私が最近思うのは、新しい技術が主原因ではないケースが比較的多いということです。新技術という要素もあるのですが、そもそもなかなか要件が決まらないとか、連携するサービスやSDKが安定しないなど新技術以外が要因になっている、もしくは新技術以外の要因がウェイトとしては大きいというケースが一定あると思います。

実際に、新技術が原因なのであれば、経験不足が理由なのか、それともプロジェクトに対してアンマッチな技術だったのか。もしくはまだ安定していない、つまり成熟していないのか、みたいなところをしっかりと判断していく必要があります。

マネージャーサイドでは新技術が原因だと思っているけど、エンジニアサイドはそうではないところが原因、みたいな現象も私は見てきたことがあって、そこで深い議論や、ふりかえりができていないケースもあるかなと思っています。そこを忌憚なく話せる関係性は、非常に大事かなと思います。

それから、本番のプロジェクトでも小さく作って先に失敗しておくことが肝要で、それがすごく大事だと思っています。

いくつかモジュールを作って、それを最終的につなげることにはなると思いますが、モジュール1個1個を完成させてから最後につなげるのではなく、まず小さくてもいいから全部のモジュールを揃えて、先に全部つなげます。イメージが湧きますかね？

いろいろな開発、いろいろな領域がありますが、私の得意領域のお話をしてしまうと、モバイルアプリであればAPI接続する部分を作って、その後にビジネスロジックを書いて、最終的にViewを書いていくと効率がいいです。

そうではなく、先に画面は1個だけで、ビジネスロジックとAPIなど全部を先に一本通ししてしまうと、技術要素が全部揃って全体俯瞰ができるので、難しいポイントも先に見えてきます。

特に、アジャイルでスプリントを回さなくても、考え方としてアジャイルにしていって、意識的に小さく作って先に失敗することは一定可能だと思っています。過去を振り返った時に、めちゃめちゃエッジが効いている技術を採用した案件で、大成功したものは、やはりまず新しい技術要素を全部揃えて、それを全部つなげるのを優先していたかなと思います。

いろいろお話ししましたが、結局、新しい技術も不確定要素の1つとして捉えるのがいいのかなと思っています。

新しい技術以外にも、要件がなかなか決まらないとか、連携するSDKがよくわからないとか、安定していないとか、不確定要素はいくつかあるので、全部並列に考える。新技術を使うという不確定要素がもうすでに決まっているのであれば、それ以外をいかに最小にするかとか、それ以外をいかに早期に減らせるかとか、新技術の不確定要素自体もいかに早期に減らせるかというところが重要かなと感じています。

いっぱいお話をしましたが、私からの発表は以上です。ありがとうございました。

新技術を社内で育てていく時のアンチパターンは？

佐藤歩氏（以下、佐藤）：ありがとうございました。いろいろと興味深いご経験やお話をうかがえました。

最後のほうにあった、まず一気通貫の部分を、新しい技術を通して使ってみるというところは、私もすごくわかり、共感しました。

最初に全体俯瞰するところは、やはり、何より最初にあたりをつけることで、それこそ先ほどおっしゃっていた不確実性みたいなのが見えてきたりしますものね（笑）。

ということで、ここからは質疑応答で、「Zoom」のQ&A機能で集まっている質疑応答についてお話をちょっとうかがったり、場合によっては、私も一緒にお話しさせていただきながら進められればなと思っています。

ではさっそくまいりましょうか。では1つ目。「新技術を社内で育てていく際のアンチパターンはありますか？」というところです。

渡部：アンチパターン。何でしょうね。アンチパターンと言われて、パッと思い浮かぶものはありませんが、先ほどお話しした、技術の特性や成熟度に対して、「未成熟であれば、より小さく」という、成熟度とサイズのダウンサイジングの比率に近いものがあると思っています。

「未成熟なものを一気にみんなでやるぞ」というのは、やはり難しくて、未成熟なものに取り組むのであれば少数精鋭チームを作る。ある程度業界で採用事例が多いものやスタンダードになってきたものを社内で新しく取り入れる場合は、わりと大人数でドカッとやっても大丈夫でしょうし、そのあたりのサイズ感は一定あるかなと思います。

佐藤：ありがとうございます。登壇の中でお話ししていた、やはり小さく始めるというところの、適用のしどころを見誤るのが、逆説的にアンチパターンの入り口かもしれないということですかね。

渡部：まとめていただいてありがとうございます（笑）。

メンバーのモチベーションを低下させるものは意図的に取り除いている

佐藤：次の質問は、「メンバーの技術に対する探求心やモチベーションを向上させるために行っている取り組み」です。

確かにそうですよね。会社としての制度、委員会ギルドの仕掛けがある中で、メンバーの方々がどういうモチベーションで取り組んでいるのか。向上させるための仕組みを含めてうかがえればと思います。

渡部：意図的にモチベーションを上げようと思ってやっている施策は、実は特にはないと思います。逆に、モチベーション低下になるような、やりにくさは意図的に取り除いているとは思います。

やりやすい環境にして、モチベーションが低下しないようにというところに気を配っているというところでしょうかね。

佐藤：モチベーションを低下させるポイントは、一般的なものももちろん入ってくると思いますが、ゆめみさんの中でモチベーションの低下ポイントとして気を使っている部分はなにかありますか？

渡部：技術選定の自由度とかですかね。

佐藤：それこそお客さまの仕事をしていると、技術選定は必ずしも自由にできないところもあるのかなとも思います。やむを得ない事情は別として、自分がやりたいと思ったことを通すための仕組みがなにかあるんですか？

渡部：これは私自身というより、マーケティング部門や、ゆめみメンバーの努力によって、ゆめみのことを知ってくださっているお客さまが最近増えているというのがすごくあります。

ありがたいことに、私たちの意思決定を尊重してくださるお客さまが最近増えているなという印象があるので、技術選定の自由度は一定、お客さまとの折り合いという面でも保てているかなと思います。

佐藤：いい仕事をさせてもらえるお客さんを全社的に、営業やビジネスのほうからも獲得してもらえているというのは、そういう意味で言うと、だいぶ恵まれているいい環境ですね。

R&Dが進まないことは何度かあった

佐藤：では、次の質問にまいりましょうか。「日々の業務に追われて、各種の制度が形骸化することはありませんか？　例えば、ほかの会社さんが真似する時に、どういう点が大事だと感じますか？」。ちょっと難しい質問かもしれないですね（笑）。

渡部：先ほど挙げた制度に関しては、それほど形骸化はしていないですね。それよりゆめみでよくあるのは、「研究開発でこれをちょっとやってみようよ」で始まったけど、みんな忙しくてちょっと進まなくなっちゃったという、R&Dが進まない的な形骸化は何度かあったかなと思いますね。

佐藤：そういうのは、社内的な雰囲気としては空中分解しちゃったね、みたいな感じなんですか？

渡部：そうですね、みんなが忙しくなっちゃって進まなくなっちゃったのは、私自身もやってしまったことがあります（笑）。

佐藤：完全にみなさんの忙しさに依存していたのか。それとも技術的な意思決定における優先度に対して、なんだかんだでみんなの中で温度感が低くなってしまったのかでいうと、どっちですか？

渡部：前者だと思います。なので、やはり少し小さく始めて、小さく刻んで達成感を得ながらやるべきだったかなとは思いますね。ちょっとこの質問に、直接的に答えられていないですね。

佐藤：（笑）。

渡部：形骸化は、ありますよね。

佐藤：今お話しいただいた限りだと、ゆめみさんの中で直近ワークしている制度自体の形骸化はあまりないというお話だったと思います。けっこう特徴的な制度も多いので、パッとは難しいかもしれませんが、例えば、他社が真似する時にどういう点が大事、というのはありますか？

10パーセントルールなどを真似する時の肝とか、こういうところは確実に抑えたほうがいいとか、もしあれば。

渡部：10パーセントルールは比較的導入しやすいんじゃないかとは思います。先ほどのモチベーションのお話にもつながりますが、やりにくさや、制度の使いにくさを作らないということに気を配っていただければ良いのかなと思います。

佐藤：ありがとうございます。

（次回へつづく）