いわゆる人工知能技術が巷をにぎわす昨今、人工知能を研究する部署/団体を設立するのがトレンドになっています。もちろん、部署の設立にはそれをマネジメントする人間が必要です。「その時」は突然やってきます。
「わが社でも人工知能技術を研究しビジネスに役立てるべく、新しい部門を設立することになった」
「はい」
「ひいては、君にその部門のマネジメントを任せたい」
「！？」
「将来的には100人規模にし3億円規模のビジネスにしたいと思っている(※)。まずは中期計画を作成してくれ」
「そ、それは・・・」
「部門設立のプレスリリースは来月発行される。よろしく頼むよ(肩ﾎﾟﾝｯ」
(※: 好きな数字を入れてください)
(from 疾風伝説 特攻の拓)
本文書は、実際こうした事態が起こった時に役立つチェックリストとして機能するようにしてあります。具体的には、以下の構成をとっています。
- 設立編: 何を「目指す」のかはっきりさせる
- 本業へのコミット方式を明確にする
- 勝負可能な研究領域を見定める
- 3年は続けられるミッションを決める
- 計画編: 行動するための地図を作成する
- 事業と研究のリンクを設計する
- 業績評価指標を設計する
- 採用・広報のための資材を整える
- 運営編: チームのパフォーマンスをマネジメントする
- 意思決定のプロセスを明確にする
- モチベーションを設計する
- メンバーへの支援体制を設計する
なお、内容は私が実際に直面した経験に基づいており、そのためまだ直面していないフェーズについては情報が不足しています。また、可能な限り体系的にするよう心掛けてはいますが、経験済みの点についても確認事項に偏りがある可能性があります。その点についてはご容赦いただければと思います。
※私は志願して始めたので、上記のようなケースに該当するわけではありません。
では、ドエレーCOOLな状況を乗り切っていきましょう。
設立編: 何を「目指す」のかはっきりさせる
最初にすべきことは、組織の長期的な目標を決めることです。なんのためにそれを決めるのかというと、組織の方向性とメンバーのモチベーションを一致させるためです。研究開発、また新規事業の立ち上げといったものは、何をやればいいのか明確でないですし、その完成の定義もあいまいです。「販売管理システムを作る」という案件なら機能ごとに分割して実装を行い、仕様に沿っているかテストできますが、研究開発/新規事業では案件の姿も仕様の定義もありません。これは夏休みの宿題における「計算ドリル」と「自由研究」の違いによく似ています。夏休みの最後に嫌々まとめた自由研究も、好きで取り組んで一生懸命調べた自由研究も同じ「自由研究」ですが、そのクオリティの差は計算ドリルなどの形が決まったタスクに比べて大きなものになります。その差の源泉が「モチベーションの差」です。よって、まずもってこれが湧くような目標を設定することが一番重要なタスクになります。
ただ、実際の長期的な目標は市場環境や会社からの要求によって制約を受けます。みんながやろう！と思えても市場がレッドオーシャンな状態ならそこで成功するのは難しいですし、会社における部門の立場によっては、やろうと思えてもできないことが出てきたりします。
そこで、以下のチェックリストはそうした制約のチェックと、それを踏まえた上での目標設定のポイントをまとめています。
本業へのコミット方式を明確にする
新しい部門が、会社本体のビジネスにどのように貢献するのかをはっきりさせます。これには、主に以下3つのパターンがあります。
- 新規ビジネスの創出: 「人工知能」を使った新しいビジネスを創出し、会社の新たな柱にしたい
- 既存ビジネスの改善: 「人工知能」を使って、現在行っているビジネスを改善し売り上げ拡大につなげたい
- コスト削減: 「人工知能」を使って、事業コスト、また間接費を削減したい
3つのルートのどれを選択するかは、長期的な目標に大きな影響を与えます。特に「既存ビジネスの改善」で行くならそもそも既存ビジネスが目指している所が長期的な目標なので、別途新たに目標を設定する必要がなくなってきます。また、「新規ビジネス」は対外的ですが、「コスト削減」は対内的になります。
チーム/部門のメンバーの出自は、このコミット方式の選択に影響が大きい因子になります。例えば、既存の部門から「新規ビジネスをやりたい」と言って移ってきた人が多いのか、基幹部門から派生する研究開発分室といった形でできたのか、はたまた社内業務改善プロジェクトの一貫として立ち上がったのか、によってモチベーションの分布は変わってきます。ここで一つにまとめるのが難しい場合は、新規/既存改善の2つに分けるなどいったことも検討してよいと思います。無理に一つの方向にまとめようとする必要はありません。これは、もちろん無理に一つの方向にすることがモチベーションを大きく毀損するためです。
勝負可能な研究領域を見定める
「勝負可能な研究領域を見定める」のは新規ビジネスを行う場合に検討が必要な事項であり、他のコミット方式を選択している場合特に検討する必要はありません。なので、新規ビジネスを考えていない場合はこのセクションは飛ばしても大丈夫です。
さて、人工知能関連の研究・ビジネスは世界の名だたる大企業が闊歩する領域であり、「今からやろう」という新参者が生息可能な領域はかなり限られています。例えば、Google翻訳がある中で今から翻訳やろうというのはだいぶ無謀に感じられると思います。
(from 進撃の巨人)
研究領域は、主にタスクとそのドメインによって特徴づけられます。タスクは翻訳や画像認識といったもの、ドメインは日英の翻訳データ、猫の画像、といったデータの属性に依存するものです。例えば、翻訳というタスク自体はかなりやりつくされていますが、ガーンジー語(絶滅危惧言語)の翻訳はまだ行われていないでしょうし、Googleが今後やるというのも考えにくいです(ガーンジー語を話す人はそれ以外にメジャーな第二外国語を操っていると思われるため)。ただ、当然ビジネス化を考えているならばニーズがない領域ではいけません。
多くの場合ドメインで差別化するのが現実的になります。というのも、完全に新規なタスクをひねり出すのはとても難しく、また既存の研究を利用することができず進めるのが困難なためです。ドメインはデータの属性によって決まってくるので、一番簡単に「勝負領域」を決定づける要素は「他に誰も持っていないデータを持っている」というパターンです。以下は、これが非常にうまくはまった事例です。
「日本は公的介護保険制度が充実しており、介護サービスや機材のレンタルに対して、要介護者の身体状態に応じて7段階で上限金額の異なる保険給付が国から支給される。国はこの要介護度認定のために、『自分で食事ができるか』『自分で歩けるか』など74項目に及ぶ詳細な身体状態の検査を行っている。この膨大なデータを、AIを使ってより良い介護プランの作成に活用できないだろうか」と。
グイド博士は目を見開いた。そんな介護システムはアメリカにはないし、聞いたこともなかったからだ。「日本の要介護者約600万人×74項目×2000年の制度開始から15年分」ものビッグデータ。「素晴らしい。イノベーションが起こせるよ」と博士は言った。
良質なデータは、研究者を引き寄せるだけの効果があるということです。そういう意味では、部門の人間全員でデータを作るというのも真面目に考えてよいと思います。ただ、それはGoogleやAmazonがその気になったら簡単に集められるor既に持っているようなデータであってはいけません。
研究対象として成立しているタスクであり、かつ自社独自のドメインデータを保持している/保持できる。これが「勝負可能な研究領域」の条件になります。ちなみに世界の名だたる大企業達は止まっているわけではないので、昨日まで勝負可能だったけど今日焼け野原になった、ということも十分あり得ます。だからこそ、ある程度大きな「長期的な目標」を設定しておかないと、焼け野原になった瞬間部門を解散する、ゼロからのスタートになるということになりかねません。
3年は続けられるミッションを決める
コミット方式、勝負可能領域、この二点の制約をメンバーで共有したのちに、その中で「3年は続けられるミッション」を選択します。「3年は続けられる」というのは、それだけモチベーションが湧くものであると同時に、達成に3年はかかると目される程度には大きい計画にする、という側面があります。また、ミッションが実現した状態を具体的にイメージできる、という点が重要になります。つまり、持続性・期間・具体性の3つが重要ということです。
- 持続性: その問題領域に強い関心がある、好き、もはや趣味など
- 期間: 3年程度
- 具体性: ミッションが達成された状況のイメージが人によってぶれない
このうち、最も欠けてはならないのは「持続性」と「具体性」です。モチベーションの持続性が重要であることは、先に述べた通りです。具体性は、評価基準を明確にするために重要です。例えば、「コミュニケーションを革新する」とか、「オフィス業務を改善する」といった目標は、その状態を評価できません。Slackを導入したらコミュニケーションは革新したのか？まだなのか？それを決められないということです。これは、この後の計画を評価する段で障害になります。
ちなみに、うちのチームのミッションは「すべての人がティータイム(15:00)までに帰れるようにする」です。ポイントとしては、「すべての人がティータイム(15:00)までに帰れる」という状態が明確であることと、その実現にチームがモチベーションを感じられた、という点です。ただ、これは3年で実現するには大きく、実際初期は結構迷走してスクラップ＆ビルド的な状態に陥りました。サイズが大きすぎるミッションだと、具体的な計画とのギャップが大きくなってしまうためです。これがミッションが定まっていない弊害です(まだ公開資料にはしていないですが、現在はより具体的なところに落としています)。
場合によってはより長期の計画を会社から求められることもありますが、前述の通り動きの速い環境の中で3年を超える計画にあまり意味があるとは感じられません。求められた場合は、適当に書く3年の延長線上の姿を大まかに書くといいと思います。
以上3点にチェックがつけば、社内での部門の立ち位置、事業としての妥当性、組織として目指すゴール、の3点が明確になります。
計画編: 行動するための地図を作成する
ミッションが決まったら、その実現に至るルートを洗い出した地図を作成します。ミッションの実現には概ね複数の機能が必要です(音声認識＋翻訳など)。ゴールに向かって、どういった機能が必要で、その実現にはどんな研究が必要で、それをだれが担当するのか、という点を明らかにしたマップを用意します。
注意点としては、この「地図」は工程表ではないということです。音声認識を1/1~3/31までに実装する、みたいな工程を連ねたものではないということです。その期間内に実装をしたらその分野に触れることはもうない、というのではそもそもメンバーに研究者としてのキャリアパスを用意することができません。
そもそも当初想定したゴールが「勝負可能領域」でなくなってしまうことも十分あり得ます。この際に、「ゴールに向かって一直線」の方式だとすべてが無駄になってしまいます。「地図」は、この先の道が封鎖されてもこのポイントまでの研究は無駄にならない、というようなルート関係を明らかにするためのものになります。
(from HUNTER X HUNTER)
上記の点からもわかる通り、研究開発チームの運営は進捗管理表を作成しタスクばらしをしてその消化に邁進する、というマネジメント方式とは全く異なるものになります。この点については、運営編で詳細を述べます。
事業と研究のリンクを設計する
これは、先ほどから出てきていた「地図」の作成に該当するステップです。実際作成したものを紹介します。
以下はミッションである15:00までに帰るための要素として、「読む量が減れば早く帰れる」というシンプルな仮説をベースに、要約の作成というゴールに向かっての地図を作成したものです。左がパス、右がパスに対応する研究領域になります。アイコンはその研究領域の担当を示しています。
単に要約を作成すること自体はそれほど難しくありません。TensorFlowでもモデルが提供されているので、やろうと思えば一週間ぐらいでできるでしょう。今目指している要約はもうちょい捻ったものなのですが、それにしても作るだけならそう時間はかかりません。
重要な点としては「要約が勝負可能領域でなくなる」可能性を考慮しているという点です。要約というゴールに向かって一本のパスで行くのでなく、研究領域というノードを繋ぐ形で進めています。これにより、出口の要約が死んでもノードは生きているため、他のゴールが設定されたとしてもノードのつなぎ方を変えるだけですぐに転移できるようにしています。図中のApproachエリアとResearchエリアの紐付けはそれを明確にするために行っており、例え「要約作成」というゴールが死んでも、各Researchエリア(=ノード)に蓄積された知識は次のゴールに向けて保持される、ということです。担当はノード単位で置かれるため、ゴールの生死いかんにかかわらず長期スパンで担当の研究領域に取り組むことができます。
現在各人はそれぞれが担当する研究領域で仕事を進めており、要約作成というゴールは意識していますが「要約作成」に邁進しているわけではありません。ゴールに到達するスピードは落ちますが、より耐性の高いすすめ方をしているということです。
業績評価指標を設計する
フェーズ、また役割に応じた評価が可能な業績評価指標を設計しておくと良いです。というのも、急造の人工知能部門はメンバーのスキル構成も様々であり、数式見たくないと言う人もいれば大学で機械学習やってましたという人まで様々だったりします。そのため、研究成果のみにフォーカスを当てた業績評価指標では成果を出せないという人が出てきてしまいます。
研究開発が成るには多様なスキルが必要であり、研究以外の仕事も評価できる枠組みを整えておくべきと思います。最近は研究をデモページで発表することも多いですが、その際はフロントエンドの技術が必要になりますし、学習にはGPUインスタンス/Dockerイメージの使用といったインフラ面でのスキルも必要になります。これら全てを一個人に求めるのでなく、多様なメンバで分担することは負荷の低減という面でも効果的と覆います。
研究のフェーズという面では、実際に成果といえる結果が出るまではある程度の期間が必要になります。その間研究のアウトプットがないから評価しない、では非情に過ぎるでしょう。
現在、うちのチームでは専門性の獲得と成果の普及の2種類の評価軸を設定しています。研究中は論文などのまとまった成果にはなってはないですが、その間どんどん知識を身につけているはずです。その獲得した知識をブログ/GitHub等で発信することを一つの評価指標としています。これは、所属するメンバーがその分野でのプレゼンスを獲得するという面を評価しているということです。成果の普及は、対外発表、また社内の他の部署や社外の企業への説明など、得た成果を普及させる活動を評価しています。そして、この2つのウェイトは期単位で自由に割合が決められるようにしています。研究に集中したいときは専門性の獲得を高めにし、成果がまとまったら普及のウェイトを上げるといった運用が可能です。また、営業的なポジションの方には初回から普及高めで評価するといったこともできるようにしています。
採用・広報のための資材を整える
自分たちが何を目指してどうやって取り組んでいるのか、A41枚両面で常にさっと出せる資料を作っておくと良いです。これは採用・広報の面ではもちろん、自分たちの立ち位置を見直す際にも役立ちます。そのため、ゴールが変った場合などには都度作り直すようにします。
チームのロゴなどをきちんと作っておくのも良いと思います。発表スライドなどに入れることで、アイコンとして認識されるようになるためです。うちは99designsというサイトで発注して作ってもらいました(これは身銭を切りました)。
運営編: チームのパフォーマンスをマネジメントする
チームのマネジメントについては、以下の本に全てが書かれているためとりあえず全部読むとよいです。
実際研究開発のチームを運営するまでは、正直簡単だと思ってなめていたことをここに告白しなければなりません。いうてもチームリーダー・プロジェクトマネージャーの経験はあったため「同じやろ？いけるで！」と思っていたのです。
ただ、前述の通り研究開発はチケットを消化していくたぐいのものではなく、どこに進むも自由であり、進む速度はモチベーションによりいかようにでも変容するというかなりわけのわからないものです。残念ながらこれを解決するためのベストプラクティスは存在しませんが(上記の本にも、「銀の弾丸はない」と書いてあります)、最も気をつけるべき点についてチェックリストとして提示したいと思います。
意思決定のプロセスを明確にする
何を行うべきか、どうやるべきか、誰がやるべきか、いつ頃までにやるべきか、研究開発の進行は意思決定の連続になります。しかも顧客という相手はいないので、「顧客の要望だから」というパワーワードは使えません。全ての決定はあなたの決定であり、それに対する賛成も反対も全て自分に返ってきます。言葉にしてくれるならまだいいですが、反応がなくて納得しているのかよくわからないという状況にも陥りがちです。
これに対する万能薬はありませんが、意思決定にリズムを作ることが重要と感じています。例えば以下のような形です。
- 第一回ミーティング
- 事前：決定したい事項と、それについて集めた資料の収集
- 当日：資料の説明と、それに関する質疑応答
- 第二回ミーティング
- 事前: 決定についての各自の考えを提出してもらう(メールで送るなど)
- 当日: 各自の案を一覧にし、決をとる
この場合だと、2回のミーティングで必ず決定がなされる、というパターンになります。第一回は必要な情報の共有、第二回は決める会議、と各会議の役割も明確です。資料を事前に共有しておくことで「その場で考える」ことに時間を使わなくて済みます。また、会議では声の大きな人の意見が通ってしまうことが多いので、発言者のバランスが偏っている場合は意見を事前に送ってもらうというのは効果的と思います。
モチベーションを設計する
新しい事業や研究開発は大半が失敗するので、デフォルトだと多くの場合モチベーションは減衰していきます。そのため、「成功を感じられる体験」「その成功が蓄積されている体験」を上手く設計する必要があります。RPGでいうところのレベルアップの仕組みに近いです。
モチベーションの設計については以下の本に全て書いてあるので、こちらを参考にすると良いです。
学んだ知識をQiitaに書いていいねを獲得する、GitHubのStarを獲得するというのも「成功を感じられる体験」の一つです。研究成果本体だけでなく、そうしたフィードバックもモチベーションの設計に活かすことができます。
メンバーへの支援体制を設計する
マネージャーの最大の仕事はメンバーを教育することです。マネージャーの仕事はチームのアウトプットを最大化することであり、そのためにはメンバー各人のスキルアップが最も有効なためです。なお、これはHIGH OUTPUT MANAGEMENTに書いてあるとおりです。
そうした意味では、マネージャー自身が研究成果を出すのは必須ではありません。逆に、研究成果を出しながらチームのマネジメントも行うというのはとんだ超人野郎といった話になります。優秀な新人がいたりするとその先を走らないとという焦りが生まれることもあると思いますが、そもそも自分を追い越すような人材が出てこないとチームとして発展していかないですし、自分の限界がチームの限界になるというのも健全ではありません。
個人的には、トレーニング以外に研究に必要な事務(必要なデータの購入手続きとか)も最近こちらがやるようにしています。それと、幅広く情報を追うようにしています。これは、メンバーが研究に取り組むときに先行研究としてどんなものがあるかサッと引き出せるように、また研究に詰まったときにそれを解決できそうなアプローチについてサッと出せるようにするためです。なお、論文のまとめは公開しているため検索すればいつでもサッと引き出せます。
以上が、個人的な経験も踏まえたチェックリストになります。参考になれば幸いです。