▶平日 毎朝7時に公式LINE@で新着記事を配信しています。友達申請はこちらから！
▶ICCの動画コンテンツも充実! Youtubeチャネルの登録はこちらから！
「イノベーティブなプロダクトを生み出す開発/エンジニアリング・マネジメント」【K16-8D】セッションの書き起し記事をいよいよ公開！10回シリーズ(その10)は、最適なチームサイズやプロダクトの継続的な改善等、イノベーティブなプロダクトを生み出す秘訣について議論しました。是非御覧ください。
ICCカンファレンスは新産業のトップリーダー160名以上が登壇する日本最大級のイノベーション・カンファレンスです。次回 ICCカンファレンス KYOTO 2017は2017年9月5〜7日 京都市での開催を予定しております。
▼
登壇者情報
2016年9月6日・7日開催
ICCカンファレンス KYOTO 2016「ICC SUMMIT」
Session 8D
「イノベーティブなプロダクトを生み出す開発/エンジニアリング・マネジメント」
（スピーカー）
大宮 英紀
株式会社リクルートライフスタイル
執行役員
菊池 新
株式会社ナビタイムジャパン
取締役副社長 兼 最高技術責任者
徳生 裕人
グーグル株式会社
製品開発本部長
平栗 遵宜
freee株式会社
執行役員 開発本部長
（モデレーター）
安川 健太
株式会社ソラコム
取締役CTO
▲
▶「イノベーティブなプロダクトを生み出す開発/エンジニアリング・マネジメント」配信済み記事一覧
【前の記事】
【本編】
安川 組織のところで話が盛り上がり、時間が残り10分くらいになってしましました。今の話との関連で伺いたいのですが、いろいろなアイデア、プロダクトの改善、フィードバックを受けての改善、ないしは全く新しいアイデアも出てくると思いますが、そういったアイデアを実際に実現させていくにあたり、最適なチームの形や大きさについては、ご経験上、どのように考えていらっしゃいますか？
大宮さんから伺いたいと思います。
最適なチームのサイズとは？
大宮 私の経験では、ポンパレというサービスを立ち上げた時も、Airレジというサービスを立ち上げた時もそうでしたが、大体5人弱でした。
5人ともそれぞれ強みがはっきりしているのだけれど、ホスピタリティが高い、コミュニケーション能力が高いというメンバーで基本的にはスタートしました。
実際は5人よりも少なく、5人弱ですね、プロダクト、エンジニアサイドが2、3人と、ビジネスサイドが2人くらい、このような形でスタートすることが多いです。
安川 なるほど。それは私の実感にも合っています。
菊池さんはいかがですか？
菊池 弊社でも5人前後くらいですかね。
エンジニアが多い会社なので、エンジニアがビジネスを考えることも多く、プロダクトマネージャー、プロジェクトマネージャーレベルでも問題なくコーディングができるので、5人前後くらいでひとつのプロダクトが出るというイメージです。
コミュニケーションコストも考えると、この大きさが最適だと思います。
安川 徳生さんはどうですか？
徳生 何をもって実現と呼ぶかにもよりますが、1人か2人で始まって、とにかく動くものを作ります。特に検索だとロングテールがあるので、モノを作って色々な人に使ってもらわないと本当に有益なのか分からないことが多い。その後、その動くものをネタにあちこちを説得して周り、本格展開することになった場合には、純粋に次に作らないといけないものの複雑さの程度によって、チームの大きさを決めていくことになります。
安川 そうですよね。
平栗さんお願いします。
平栗 私も感覚は全く同じです。
安川 共通見解ですね。
大宮 やはり人が多くなると、累乗的にコミュニケーションが増えていきます。
ゴルフコースで言うと、フェアウェイでさえいれば、OBさえしなければいいという感覚でとにかく前に前にボールを運んで、カップインするという感覚でやっています。
ですので、何打で回ったかではなく、パターでもいいからとにかく早く入れた方がいいと思って運営していますので、コミュニケーションの観点から、少人数の方がいいのではないかと思います。
徳生 そこは弊社の場合、明確に違う時もあるかもしれません。
何かの機能を提供開始しようとした時に、レイテンシーなどが今のままでは許容できない、インフラ自体を更新する必要がある、となり、非常に大掛かりな話になったり、待たされる場合もあります。
大宮 そうですね。私がお話したのは、どちらかというと新しいサービスについてでして、例えばじゃらんで機能を追加しますという話になった時には、現状使っている方々がいるので、既存のお客様を不満にさせないようにするにはどうすべきか、リスクヘッジを考えなければなりません。
ただ、新しいサービス、新しい領域については、そのように決めてやっています。
安川 なるほど。新しいことを試す場合には、5人くらいで始めてということですね。
プロダクト運用・改善で気をつけていること
安川 先ほど、じゃらんのお話であるとか、スケールするインフラでなどのお話がありましたが、リリース後について、少人数で作って世に送り出した後に段々大きく成長し、安定運用に入っていく、その時の開発陣の関わり方、プロダクトのライフサイクル、先ほど負の遺産というキーワードもありましたが、その辺りについて何か気を付けていることなどはありますか？
菊池 弊社は16年にわたりサービスを提供してきていますが、サービスを廃止することは意外とありません。
他の企業がいろいろ止めていく中で、フィーチャーフォンのサービスも普通に残っています。
ある程度の問題意識はあるのですが、ユーザーもそれなりにいるので、そこは基本は維持しようという方針です。
セキュリティパッチなどがバックエンドで入ってくるので、そこで結構トラブルが生じたりすることは多いですが。
安川 メンテナンス的な作業、リファクタリングであったり、パッチ当てもそうですが、メンテナンス担当という意味でのリソースは、プランニングの中で決めて管理されていますか？
菊池 基本は同じ人がずっとやり続けますね。メンテナンス用の運用チームがあるわけではありません。
安川 作った人が責任を持って運用していくということですね。
菊池 そうです。もちろん人が変わることはありますが、同じチームが運用をしていくという方針です。
リニューアルを極力意識させないようにする
安川 リクルート社では、いろいろなサービスを出されていますが、サービスを世に出したチームがそれぞれ運用を続けていくのでしょうか。
大宮 先ほどの話にも関連しますが、ジョブローテーションを非常に活発に行っている会社ですし、すぐに人が辞めていく会社でもあるので、そこがまさに課題です。
加えて、こんなことを言っては何ですが、広告事業のようなものを考えた時に、リニューアルをした方が、お金をたくさんいただけるとか、営業案内がし易いということはあるので、リニューアルのタイミングで裏側の刷新を行うこともあります。
しかし、Airレジというプロダクトをやってみて初めて思ったのは、やはりインフラビジネスに近くなればなるほど、リニューアルなどを意識させないようにしなければならず、そのためには継続的に投資を続けるという判断をしなくてはなりませんが、そのバランスが本当に難しいと思います。
安川 後方互換はもちろんですが、サービスのエクスペリエンスというか、そこもなかなか唐突には変えられませんよね。
リファクタリングは経営判断である
大宮 応答速度がどのくらいか、こういう時は切れないようにするなど、非機能的な要件も決めていますが、機能を盛り込むことによりどうしても遅くなったりするので、それがある一定になった時に、開発に莫大なコストがかかってしまわないように、そうならないように未然に、実は今も裏側でいくつかリファクタリングを行っています。
つい最近の話ですと、Airレジは「Objective-C」で作っていたのですが、全てSwift（スウィフト）に移行しました。
アップル社の話でも、業務アプリでは世界でもそれほど多くないと言われているSwift（スウィフト）に移行して、本当に手間が楽になりましたし、採用の一環として、Swift（スウィフト）をPRし、エンジニアを集めようとしています。
安川 ひとつのステップが大きいけれども、やってしまえば後の作業が楽になるという意味で、どこかでやらなくてはならない作業ですね。
大宮 ただそれは、どのようなサービス、どのような事業をやるかによって大きく変わってくると思うので、事業によって意思判断をしていかなくてはなりません。
経営ボードが判断すべきテーマであり、現場の努力で何とかしてくような問題ではないと思います。
安川 そこがまさに、弊社でも悩みどころです。
大宮 いつまでに仕上げないと売れませんという話がどうしても出てくるので、本当に悩ましく思っています。
安川 平栗さんは何か悩んでいらっしゃるところはありますか？まだそんなにないでしょうか？
平栗 プロダクトに関してですか？それで言えば、弊社でもAirレジさんと同じく、120％業務アプリなので、止められない、廃止できないというのはありますね。
今まで廃止してきた機能は5％くらいだと思います。
完全に使われていないことを確認して、ユーザーを特定してコミュニケーションしてからでないと廃止できません。
そうでないと、その機能を使っているユーザーが1社でもあったら、廃止した翌日からその会社の業務は止まってしまうので、絶対にできません。
ひとつの機能を作ったら、10年、20年、30年、50年運用し続けるという覚悟をしています。
安川 なるほど。グーグル社ではそこを敢えて、このサービスは止めようと、勇気ある決断をされることがあると思います。
機能単位ではローンチ後の反応で自律的に判断
徳生 例えば、Googleリーダーのようなプロダクトそのものをシャットダウンするというのは、かなり上の方で、相当な議論をした上で判断していると思います。
一方、個別のフィーチャー、YouTubeの中の何か、Searchの中のフィーチャーというのは、例えば、5人や10人でその機能を出して、出す前はその機能が本当に流行るかどうかを見極めるのは難しいのですが、出してしまえば可能性があるかどうかというのは大抵の人には分かるので、この先あまりインパクトがないと思われる場合は、そのチームは自律的に、よりインパクトが出そうな他のプロジェクトに流れていっている場合も多い。
後はどこかのタイミングで、インフラを更新しなければならないので維持できない、UXを全部変えなければならないから維持できないという状況になった時に、当時ローンチしたPM(プロダクトマネジャー)やエンジニアに、アンローンチしてもよいか打診があり、それは止むを得ないというような判断がなされる、という流れになっています。
比較的、自律的に、誰もが納得できる形で改善されている場合が多いと思います。
安川 その部分も含めて自律的なのですね。驚きました。
更にお話を伺いたいところですが、いつの間にかお時間となってしまいましたので、最後に一言ずつ、先ほどの人数の話なども関連するかもしれませんが、イノベーティブなプロダクトを生み出し続ける秘訣についてお伺いして、セッションを終わりにしたいと思います。
では徳生さんからお願いします。
イノベーティブなプロダクトを生み出し続ける秘訣
徳生 エンジニアハピネスのようなところが一番大切だと思っています。
トップが大方針を決めるのはいいとして、透明で何をやっているか分かっていて、意見がきちんと尊重される組織の方が、独裁的な組織よりも、優れたものを出せる可能性が高いと思います。
安川 ありがとうございます。エンジニアハピネス、良いキーワードですね。
大宮 リクルートはいろいろなサービスを出してきていますが、エンジニアハピネスに近しいかもしれませんが、心理的に安全な場所を組織としてきちんと確保していくことが一番大事だと思います。
要は、何が起こっても責任を取れということになると、チャレンジできなくなるので、心理的な安全性を確保し、それを組織として許容すること、後はチャレンジした人を称賛するような、人と文化以外はないのではないかと思っています。
安川 チャレンジし易い文化ですね、おっしゃる通りだと思います。ありがとうございます。
菊池 私も、エンジニアハピネスというのは確かにそうだと思っています。
最近分かってきたことは、人をどんどん動かすと、成長も非常に早いということです。
エンジニアに、アプリ、コンテンツ、インフラなどいろいろなことをやらせるのが、イノベーティブなプロダクトを生み続けることにつながるのではないかと思っています。
安川 分野に縛られずに変えていくと、それによって気付くこともありますよね。
ありがとうございます。平栗さん、最後にお願いします。
平栗 最後ですので、お三方が挙げていないことを敢えて言えば、変化に強い組織にすることが非常に大事だと思っています。
イノベーションというのは、そのタイミング、タイミングでのイノベーションなので、その時点で何がイノベーションなのか、何を捉えるべきなのか、ということを常に考えなければなりません。
組織も大きくなっていき、ユーザーも世界も会社も変わっていきますが、そのような変化を常に汲み取って自分を変えていける、その結果、組織も変わっていけるような、そのような組織が良いのではないかと思います。
安川 素晴らしいまとめをありがとうございます。
私自身も、今皆さんがおっしゃってくださったこと全部にとても共感しますし、刺激的でした。
本当にありがとうございます。
会場の皆様、ご清聴いただきありがとうございました。
非常に有意義な時間を過ごすことができました、ありがとうございます。
（終）
編集チーム：小林 雅／榎戸 貴史／戸田 秀成／鈴木ファストアーベント 理恵
【編集部コメント】
最後までお読みいただきありがとうございます！他にも多く記事がございますので、TOPページからぜひご覧ください。
更新情報はFacebookページのフォローをお願い致します。
