tisにおける、研究開発のメソッド

Copyright © 2016 TIS Inc. All rights reserved.

TISにおける、研究開発のメソッド

戦略技術センター久保隆宏

Copyright © 2016 TIS Inc. All rights reserved. 2

自己紹介

はじめに

研究開発のプロセス

企画: 情熱を持てる課題に取り組む

検証: 議論より検証

開発: 博打を打たない

広報: 博打を打つ

学習: 先端に身を置き続ける努力をする

おわりに

目次


久保隆宏 TIS株式会社戦略技術センター

化学系メーカーの業務コンサルタント出身

既存の技術では業務改善を行える範囲に限界があるとの実感から、戦略技術センターへと異動

現在は機械学習や自然言語処理の研究・それらを用いたシステムのプロトタイピングを行う

自己紹介

人とロボットを連携させた接客システムmaicoの発表 (@対話システムシンポジウム)

OpenAI Gymを利用した、強化学習に関する講演 (@PyConJP 2016)

kintoneアプリ内にたまったデータを簡単に学習・活用 (@Cybozu Days 2016)

icoxfog417

https://twitter.com/icoxfog417


所属するチームのミッション

chakki

すべての人が、ティータイムに帰れるようにする

すべての人が、ティータイム(15:00)に帰れる(茶帰)社会を実現します。この実現には、既存の仕事を効率化するのでなく、根本的に「仕事の仕方」を変える必要があります。しかし、慣れた仕事の仕方というのは簡単には変わりません。だからこそ、実際に「体験」をし、効果を「実感」してもらうことが重要になります。そのため、私たちは先進的技術を用い、仕事の仕方が変わる体験を提供していきます。


はじめに


新技術をどのようにビジネスにつなげるか、というのは研究開発において大きなテーマです。

機械学習や自然言語処理についても、その技術的なチュートリアルは多くありますが、これをサービスにつなげるための方策についてはあまり触れられていないと思います。

私達も、研究開発部門としてこの問題に取り組んでいます。そして、失敗をしながらそのプロセスを改善してきています。

本日はその一端をご紹介します。これが皆様の活用の糧になればと思います。

本日のテーマ

! これからするお話は内実に迫った部分も多く、お話し

できるのは今日限りになる可能性があります。


研究開発のプロセス(2017/1時点)




広報検証

企画

開発

学習

ミッションをベースに企画を立てる。学習する技術も、これに関連したものになる。企画は検証を経てから、開発を行う。学習・検証・開発過程で得られたものは、戦略的に発信を行う。


各プロセスのポイント








企画：情熱を持てる課題に取り組む


研究開発では、通常の開発よりもアイデア・ひらめきといった創造性が占める部分が大きい。

そして、人はモチベーションが向かないことについて良いアイデアを出すことができない(あえて言いきる)。

よって、モチベーションがわかないような研究テーマは、端的に言えば失敗する。


メンバーのモチベーションが向かない研究テーマは失敗する

三菱電機の炊飯ジャーの研究風景

米なんてたいてあればどれも同じだろ？という思いではこの研究の継続も進展も難しい。

http://www.mitsubishielectric.co.jp/home/suihanki/okomejuku/kamado/


具体例

市場ニーズや技術動向などから設定された研究テーマは、このパターンに陥りがち。

東京オリンピックがもうすぐ開催されるから、観光をテーマにする

○epperが発売されるから、対話ロボットをテーマにする

ロボットに接客をさせてみたいというお客様が増えてきたので、接客をやる


メンバーは別に観光好きでもないし、接客業務にも興味はない。対話ロボットの実現性についても懐疑的。しかし顧客からのニーズもあるし技術的には確かにトレンドだから・・・(という会社の意向)



大変なことになった

（※詳細割愛※）


市場ニーズや技術動向などの外的要因は驚くべき速さで変遷する。そして、それが来る/来ないについての捉え方はメンバーにより様々。

よって、よほどの確固とした根拠の提示がない限り、「個人的にはそうは思わないけど顧客と会社のニーズで・・・」という状況になる。

これによるモチベーションの低下は、研究の質の低下や離職といった形で表出する。

そもそも同じ会社、部門、またチームに所属しているからには、何等か共通する「仕事に対する思い」があるはず。その「モチベーションの源泉」を探し、具体化し、共有していくプロセスなしに、情熱を持てる研究テーマの設定はなしえない。そして、これなしに成果を生む研究開発は起こらない。


その研究テーマに大義はあるか。あるいは共感できるか。


自分達にとって、一番身近な問題に取り組むことにした。

全員開発者で、それにまつわる問題には関心が持てる

実際現場の経験からそれがなかなか上手くいかないことも知っている

これを解決することは、みんなが純粋に「良い」と思えた

こうした「純粋に良いと思える状態」をまず共有する。そして、これをイメージがずれないように具体化する(「ティータイムに帰れる」)。

マイクロソフト: すべての机と、すべての家庭にコンピュータを

Google: 世界中の情報を整理し、世界中の人々がアクセスできて使えるようにすること

この「共有された、具体的な理想状態」へ至るための課題であれば、情熱を持って取り組めるものになる。



karura

“Analyst for Analysis”

データの分析や機械学習などはデータをためる段階から始まっている。そのため、増えていくデータに対し、現時点での精度はどれくらいか、どの項目がどれくらい効いているかを提案する。


WatchMe

“Minimizing Time to Think Error”

エラーが発生した瞬間に、StackOverflowなどから該当の回答を提案する。また、Slackのチャンネルにエラー情報を流しリプライがついたらポップアップで回答内容を表示するなど。

開発者が開発環境から出ずに課題を解決できるようにする。


研究開発部門におけるマネージャーの役割は、端的にはメンバーのモチベーションを上げること。なぜなら、それなしに研究成果は起こりえないため。

つまり、会社から振ってきた「やらざるを得ない案件・仕事」をごまかしてメンバーに納得してもらうことはマネージャーの役割ではない。

これらを躱していくのは正直容易な仕事ではないが、その「容易ではない仕事」がマネージャーの仕事であると、自覚する必要がある。

※これを躱すのに一番大きな武器は「実績」になる。個人的な感覚としては、一千万規模の売上か、外部との提携実績があればだいぶ楽になる。そのため、これらに向けて上が納得できるロードマップと、実績の蓄積を行っていくことが肝要になる。


マネージャーはマネージャーの戦いをする


検証：議論より検証


「理論上完璧にうまくいく」というプランは山ほどある。


検証されていない企画はすべて仮説である

理論上よさそうに見えるが、遊びに来た人の応対にロボットが対応できず、人に引き継いでしまうといった現象が発生 ⇒理想と現実の差異は、やってみて初めて分かる。


逆に、ダメと思っていたものが意外な効果を生むこともある。


検証されていない企画はすべて「平等に」仮説である

「TOKYU CARD」の案内に活用する「Pepper」のアプリの構築をTISが支援

クレジットカードの入会のためのロボットで、お客様の要望により入会を断られたら「だだをこねる」というアクションを追加。

クレジットカードの入会に断られたらダダをこねるって・・・と思っていたが、実際はかわいいと好評だった。

http://www.tis.co.jp/news/tis_news/20150909_1.html










そもそも新しい技術を使うのだから、「やってみないとわからない」ことの方が多い(特にVRやロボットの領域)。それを議論により決着させることには無理があるし、予断を生む。

※その意味では、先ほどの会社から振ってくるものも食わず嫌いになる必要はない。やってみて、検証結果をだし納得してもらうのも手。

そのため、「まず試してみる」ことが重要。実際にアプリケーションを作らなくても、ホワイトボードやポストイットを使った「ハリボテプロトタイプ」で十分事足りる。



開発の段階で、新しいフレームワーク、手法を試すことを目的にしない。

検証により確信が持てたユーザー体験をスケールさせるために、アプリケーションなどの媒体に落とし込むことが開発の目的。

速く: 慣れたフレームワーク、資産のあるコードを使い手早く仕上げる

軽く: コードの量はなるべく少なく

堅く: ちゃんとテストを書く

新しいフレームワークなどを使うと開発のスピードが落ちるほか、性能面でも問題をきたす可能性がある。企画・検証の熱が冷めないうちに、さっさと作り上げられることが需要。


開発の最大の目的は、実証された仮説を再現することである


まず、知名度が皆無であることを自覚する。

「我々が新しいサービス作った！みんな使ってくれ！」

こういってどれだけの人が使ってくれるか？通常は皆無である。あの人(達)の作ったサービスなら使ってみよう、という下地の構築をしていくことが重要になる。そのためには、サービスのユーザーになってくれそうな人たちに対して、自分たちのプレゼンスを築いていく必要がある。

私達のチームの場合、対象は「システム開発者」になる。

広報: ファンを増やす

広報なくして、研究開発の出口なし


どんなメディアに出すのがいいのか

どんなテーマなら注目してもらえるか

これらは、実験してみないとわからない。そのため、色々仮説を立てながら実験＝博打を打っていく。

広報: ファンを増やす

広報については、積極的に博打を打つ

英語での情報発信様々な媒体での広報様々なテーマ

GitHub Star 2000越え(>Chainer)

論文実装やライブラリの最新機能など


技術動向へのキャッチアップは常に怠らない。

実装のために必要になることもあるし、アイデアのタネにもなる。最新のトレンドについて解説を求められることも多いので、学び続けることを怠らない。


日々の鍛錬により筋肉が生まれる

会社をまたいでの論文輪講、GitHubでの論文サマリ共有など


おわりに


機械学習や自然言語処理といった、いわゆる人工知能と(メディアに)称される技術は、実際大きな可能性を秘めています。

しかし、それらの技術を使えば良いサービスができるというわけではありません。単純に機械学習や自然言語処理といってもその分野は膨大であり、「来る」と謳われる領域は刻一刻と変化し、予想しないところで技術革新が発生します。これを単純に追っていると、毎年やることが変わるような事態になり、モチベーションの低下を招き、研究開発としての実績を上げることはできません。

今日ご紹介したプロセスは、ここから抜け出すための一つの提案になります。新しい技術を基にサービスを立ち上げたいと思う方にとって、少しでも参考になれば幸いです。

おわりに

＜免責事項＞本資料は、作成時点の法規制等に基づき、細心の注意を払い作成しておりますが、その正確性、適用性、完全性、網羅性、有用性、最新性、知的財産権の非侵害などに対して弊社は一切保証いたしません。また当該情報に起因するいかなる損害についても弊社は責任を負いません。本資料より得られるいかなる情報も利用者ご自身の判断と責任において利用していただくものとします。なお、本資料は特定の事項に関する一般的な情報提供を目的としています。提供されている情報は、専門的アドバイザリー、コンサルティング等のサービス提供を意図したものではありません。＜本資料の取り扱いに関して＞本資料は、著作権法及び不正競争防止法上の保護を受けております。資料の一部或いは全てについて、TIS株式会社から許諾を得ずに、いかなる方法においても無断で複写、複製、転記、転載、ノウハウの使用、企業秘密の開示等を行うことは禁じられております。本文記載の社名・製品名・ロゴは各社の商標または登録商標です。

tisにおける、研究開発のメソッド

Data & Analytics