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

EVENT

2023年03月15日に開催

株式会社overflowによって開催された、開発組織のあり方について考える1ヶ月「CTOWeek 2023 by Offers」。Week3に登壇したのは、株式会社ゆめみ技術担当取締役の渡部陽太氏。「挑戦し続ける開発組織であるために」をテーマに、ゆめみの制度・組織・新技術の推進について発表しました。全3回。2回目は、過去の失敗からふりかえるアジャイルと心理的安全性について。前回はこちら。

スピーカー

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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