R&Dはマネジメントできるか

どうも、セクションナインの 吉田真吾@yoshidashingo)です。

昔FeBeで買ったドラッカーのマネジメントを聞き直して、1963年HBRに寄稿された「R&Dはなぜマネジメントできないか」を聞いてグッとくるところがあったので【自分としてR&Dに対して思うこと】をまとめておこうと思います。

IT企業のR&D部門はなにをやっているか

大手のベンダーから中小企業のWeb企業まで「R&D」が冠につく部門、職業あるいはミッションを与えられている人は相当多いと思います。なぜならこのロールに期待されていることが、次世代の企業のメシのタネを担っているからです。ただし「次世代の」というのがいつ頃を指し示すかによってこのロールに期待される研究内容に個々の大きな違いがあるのが実情だと思います。

大手ベンダーの製品に関するR&D部門であれば5〜10年後に市場に投入されるプロダクトの開発を行ってることもあるでしょうし、中小のWeb企業では半年〜1年後には形になる新サービスや既存サービスのITスタックのモダン化に関するインテグレーションの検証を行ってることもあります。プロダクトのための新技術開発かインテグレーションに対する調査・検証かというあたりはR&Dを話題にするときにまずおさえておきたいポイントかもしれません。

これはCTOと言われる人たちの中にも実はリードエンジニアやシニアアーキテクトや超ギークやプロダクトマネージャや、実はやってること全然違うじゃんという議論と近いかもしれません。

さて、今回はこの中でも特に我々が身近に感じるだろう、プロジェクトのオーダーで実績のないプロダクトや扱ったことのないスケールを扱う場合に横断的に活躍してくれる「IT企業内でインテグレーションに関する調査・検証・サンプル実装」などを支援してくれる部門をペルソナにして考えてみます。僕がやってるセクションナインが受けるオーダーもここが主軸だからです。

R&Dについて思う12のこと

1. 対象プロジェクト(調査・検証物件)が多いほど成果は出るかどうか

企業の中で調査・検証したいものリストは、放っておけば果てしなく長くなっていきます。そのために担当者の「重要度」や「緊急度」に応じてリストの中で上へ下へと動かすわけですが、そもそもはてしなくR&D対象リストが長くなる(かつそのうち大部分は直感的には気乗りしないものばかり)というイシューについてどう対処すればよいでしょうか。

マネジメント側としては、比較的重要な事案を調査・検証してる期間はよいですが、そういうのが少ない時期においてR&Dメンバーを遊ばせておくのは我慢できないことでしょうが、さほど事業への貢献度の少ない些末なものをリストに載せ続けておくことで弊害(潜在的なものも含む)を起こしてないでしょうか。

問題点としてひとつ考えられるのは、調査・検証テーマが多く毎週のようにメンバーのアサインし直しや優先度の差し替えが発生しうるようになり、成果に向かうベクトルがあいまいになってしまうという点です。

また、純粋に作業に取り掛かってる以外に、R&Dメンバーには、プライベートな時間においてもアイデアを練ったり思考をウロウロする時間が割りと必要(これを労働時間とすると色々弊害もありますが実際のところ24時間そうやって脳みそのメモリ上にテーマを載せておける人物であることがR&Dメンバーの適性として望まれることには異論ないのではないでしょうか)なので、その他のことはいったん頭から追い出し24時間それを考えられるような環境が取れることがベストです。

つまり、一部のスーパーマンを除くと、たとえば毎日成果を求められるようなクライアントワークとR&Dを掛け持ちで取り掛かるような運営だと成果が出しにくいというようなことが考えられます。

  • 目に入るR&D対象リストはできるだけ少なくしておく
  • 一定期間は24時間それだけ考えられる体制にしておく

2. 能力の優れた技術メンバーは主担当は持たず、それ以外のメンバーを幅広くサポート(メンターのように)することで成果を最大化できるか

能力の優れた技術メンバーは幅広い知見や洞察力、実装力であっという間に成果を出します。彼らの中で特に優れているのは「当たりをつける感覚」です。それは過去の知識の積み上げもあるでしょうし、深い洞察による直感も含まれるでしょう。であれば、隣で成果がなかなか出ない他のメンバーのタスクについても素早くブレークスルーしてもらうために、あえて能力の優れたメンバーには主担当を持たせず、複数のタスクをぐるぐる回りながら、アドバイスや方向性の指示を行わせ、実際に手を動かすのはそれ以外のメンバーがいいと思うかもしれません。

これにはドラッカー同様私も懐疑的です。そもそも優れたメンバー自体、今まで繰り返し成果と言えるレベルにまでアウトプットを仕上げてきたことでレベルアップしてきたという経緯があったはずです。特にIT技術で言えば「あるものが好きでずっと触ってても苦にならないレベルでやってたらたまたま特定のことでNo.1になっている」ということが多いでしょう。それよりそういうメンバーは本当に成果を出したい部分で最高のアウトプットをしてもらうことに専念したほうがいいと思います。

でなければ、一定期間中に仕上がる「数」は多くなっても、どれもアウトプットの「質」が懐疑的なものに仕上がり、事業に強い影響を及ぼす調査・検証も、比較的どうでもいいものもいずれもそこそこの内容になってしまいます。繰り返しになりますが「事業への貢献度の最も高いアイデア、調査、検証で最高のアウトプットが得られること」が至上命題であり、「部門全体でこなした量」ではないのではないでしょうか。

  • 優秀なメンバーには大事なR&D対象に主担当として入り、協力の必要のない検証タスクについては無視してもよいとする

3. R&Dメンバーが多いほど成果は大きいか

求めるのが最高のアウトプットだと考えると、その前に「真に片づけないといけないイシューはどれか」に行き着くと思います。つまり、その企業が真に解決しなければいけない(解決すれば事業が今よりはるかに伸びるといったような)、調査・検証を要するイシューがどれで、その分野に対して最高のアウトプットをしてくれるメンバーを確保することが重要になります。つまり、もしかしたら今のR&D体制の中にはいない人が適任かもしれないし、たくさん人数を集めたらできることでもないだろうということです。

  • どういう分野でどういう成果を出したいか明確な定義をすること
  • そのイシューに対して誰が最高のアウトプットをしてくれるメンバーがいてくれさえすればよい(現業をいったん忘れて)

4. 好き放題にやらせておけばどんどん成果が出てくるのか

優秀なメンバーに担当させておけば、彼らは彼ら独自の自由な(自身が最も快適で生産性の高い)過ごし方で問題を解いてくるので、放っておけば大丈夫でしょうか。これにも私は否定的です。また何度も言いますが事業への貢献度を軸にR&Dをマネジメントすることを考えると、マネジメント側が要求する水準がどこにあるかは明確に定義しておかなければいけません。多くの場合、それを最も理解しているのはR&Dメンバーではなくマネジメント側の人間です。そして、ドラッカーも言うとおり「高い目標が設定されるからこそ、R&Dメンバーは自律した姿勢でウロウロ、紆余曲折、試行錯誤しながら(やり方は本人次第で)」成果につなげらるものと考えられます。

  • 成果への要求を高く設定したうえで、試行錯誤して成果を出してもらう

5. ドキュメントや手続きはどうするべきか

成果への要求を高く設定しておくということと同様、成果として求めるアウトプットは最初から定義しておく必要があると思います。

あるいは担当外のブロッカー要素が見つかったとか、方針転換を要することなどが出てきた場合に、どれだけ効率よい手続きで方向転換が決定できるかをあらかじめ決めておかないと、順調なときはよくても、何かあったときに途端にデッドロックしてしまいます。R&Dはそもそも平坦ではないことが多いので、あらかじめこういった点は考慮しておくべきでしょう。

  • ドキュメントや手続きは、時間と知識という有限な資源を浪費してしまううえ、最悪デッドロックしてしまうので、最も効率よく必要最低限のみで済むように日々ブラッシュアップを重ねてトガらせておくこと

6. 最終目標は技術的に明らかにすることか

アウトプットが揃えばそれでよいかということではなく、それを事業に昇華させるところまでがR&Dの意味と考えてます。でなければR&Dはただの技術の遊び場になってしまいます。ということは、R&Dの報告は最終的に「事業価値としてどうか」という観点でレビュー済みになる必要があり、その観点で評価できる人間によるレビューが行われる必要があります。

  • 最後にかならず事業価値としてのレビューを行うこと

7. 研究目標は業界のリーダー企業に従えばよいのか

最近、企業が活用すべきフレームワークはGoogleやFacebook、その他コンシューマー系のリーダー企業の発表したOSSなどが多く、それらをいかに活用してインテグレーションするかというのがR&D対象になることも多いでしょう(もちろんエンタープライズなフレームワークも否定しないですよ、割合という意味で)。これはとどのつまり広い意味で言うと他社でもできることであって、事業側が求める成果が汎用的な調査・検証であれば、最終的には横並びな成果しか得られないでしょう。

だからと言って、車輪の再発明よろしく「似たコンセプトでよりよいものを作ろう」程度の取り組みを開始してしまうと、費用対効果が見合わないうえに、ほとんどのプロダクトは彼らのものよりずっとレベルの低いものになるでしょう。「巨人の肩に乗る」のも大事な戦術です。

大事なのはインテグレーションにおいて「どれだけ上手く活用できるか(最も上手く活用できるのはそもそもどんなフレームワークか)」という汎用的な軸と、「似たような他社にはない自分たち独自な要件は何か(スケールや事業側が求めるコアコンピテンシーの部分)」という個別の軸を切り分けて考えることだと思います。

当てはめる事業において何がオンリーワンでなければいけない部分か明らかにすることで、相応の費用をもってしてもチャレンジが必要なことなのか、フレームワークの組み合わせにより素早く解決できることが価値なのかという切り分けが、メンバーレベルでも判断できるということです。

また往々にしてあるのは、そもそも事業側/R&D側双方でここは独自技術でチャレンジすべき部分だと判断しても、巷をちょっとググるだけで似たものがすでにあったりするという大変残念な状況も起きたりします。知らなかったと言ってしまえば簡単ですが、今後は(日本に入ってないという理由で情報が入手しづらいこともあったりしますが)まずは同じようなコンセプトですでにチャレンジしてる企業がないかどうか入念に調査するということ自体も大事な仕事になってくるでしょう。費用かけてよりレベルの低いものを作ってしまったらそれこそお金をドブに捨てるようなものだし、詳しい人がいればお金払ってでもアドバイスは受けたほうがいいでしょう。 ※たとえば最近のIoT関連であればKickstarterなどは少なくともチェックしておきますよね。

  • リーダー企業のフレームワークを活用する
  • 活用と個別にチャレンジすることを事業レベルで切り分けて定義する
  • チャレンジが相当と判断しても似たようなものが巷にある可能性は高い。リーダー企業のみに関わらず、技術のシーズもチェックしておくこと

8. ほどほどのんびりと推進すればよいか

これは4とも通じる話ですが、R&Dをコスト部門だととらえると、コストが嵩まないように、毎日定時で帰社してもらい、あまり多くの購買経費はかけず、なんならクライアントワークでもないからリモートでのんびり(ここではコミュニケーションコストをかけずに)やってくれればいいよというとらえかたをしている企業も多かったりするでしょう。

「弊社もリモートワークを推進してるんですよー」と自慢したい企業が多い最近の流れとも相まって、そこそこ優秀なメンバーをリモートで雇ってR&Dというミッションを渡して結局置き物にしてしまってるということはないでしょうか。

繰り返しますがR&Dのミッションは「事業に価値を供給する成果を生み出す場所」ですので、のんびりやればいいものではないと思います。散歩したりランニングしたり考えこんだり遊びに見えるようなことをやってるときでさえ、彼らはあらかじめ設定された高い目標があればこそ紆余曲折してるということであり(見た目は関係ない)、必要であればごりごりコードを書き、関係部門からF2Fで色々ヒアリングをしたりすることもあるわけです。

また、成果とモチベーションの間に相関関係があるという前提で考えると、楽しくやってるときがもっとも成果を産んでる時間になるはずで、何も目標なく遊んでるときと見た目は変わらなくても、前者はマネジメントが効いてる状態、後者はマネジメント不在という決定的な違いがあるということに注意すべきだと思います。

  • 爆速で推進するためにどんな成果が欲しいのかという定義を明確にして邁進すべき
  • 遊んでるように見えてマネジメントが効いてる状態と効いてない状態という全く正反対の状態がありうることを知っておく

9. 各種しがらみと矛盾しないように推進する必要があるか

R&Dをやってると、結果的に既存事業を全否定しなければならないような結果になることもあります。事業価値などを考えるとそういう結果は大歓迎で、必要があれば数年がかりの移行パスを引く必要が出てくるはずですが、往々にしてそういう結果は歓迎されず、既存の事業は結局そのままということも多いです。

成果を事業につなげる気が毛頭ないなら、そもそもR&Dする意味なかったんじゃないかと思えますし、しかもこの調子ならそもそも未来永劫R&D部門は要らないんじゃないかと思えます。

  • R&Dの成果でドラスティックな結果が出ても、事業側は真摯に受け止めて活用すること

10. 明確で具体的な市場調査が可能なものを対象にするか

R&Dにおける市場調査において、たとえばiPhoneのようなものが作れるか2005年当時に既存の市場調査をして出る答えは「携帯電話の市場は飽和しており端末価格も下落傾向にあり勝ち目はない」だったのではないでしょうか。iPhoneは(各種研究あるでしょうが)私なりに言い換えると「身につけて毎日使う芸術作品、ステータスシンボル」「常時インターネットにつながった情報端末」「手のひらの中のMac&ゲーム機」とも言えるような、市場調査からは出てこないコンセプトが具現化されたものだったからこんなに売れたのではないかと思います。R&Dにこういった成果を求めるのであれば、アプローチ方法自体を工夫する必要があるでしょう。(何が最適かは知らないですけど)

  • 綿密な市場調査が事業価値の高い方向性を見つける方法とは限らない

11. マネージャーは誰がいいか

では、こういった組織を効率よくマネジメントする人はだれが適任か。これは非常に難しい問題ですが、ここまで書いてきたとおり、R&Dの成果を事業価値につなげるということが体現できるという意味では「あらゆる事業のコンセプトを理解し、R&Dの結果が事業価値に置き換えるとどういう程度か判断でき、マイクロマネジメントに堕ちず最大限効率よくマネジメントができる人」ということになるので、少なくとも優秀なエンジニアとは限らないし、ただ優秀なだけのマネージャでもないという感じで、適任者を選ぶ必要があると思います。

  • あらゆる事業のコンセプトを理解し、R&Dの結果が事業価値に置き換えるとどういう程度か判断でき、マイクロマネジメントに堕ちず最大限効率よくマネジメントができる人をマネージャにする

12. 実用化せずに調査・検証して終わりでいいか

9とも重複しますが、事業に組み込んでいかないのであればR&Dの必要はありません。成果をビジネス側が活用に向けて青写真を描くことも大事ですが、その前にR&Dメンバーにおいても、事業の価値をその成果が最大化するためには成果の中でどういう「観点の結果」「所感」「周辺情報」「制約事項」が必要か言及しておく必要があるでしょう。

  • 成果は事業につながる範囲まで含める

まとめ

こう見ていくと、そもそもインテグレーションレイヤーのR&Dについては、事業価値を見極め、その価値の高いことをいかに効率よく最適なリソース配置で検証するかということになりますね。

ご意見ある方がいらっしゃればご連絡お待ちしております。

www.febe.jp