研究開発系の新規事業と似非スクラム

感情に寄り添った会話を実現しようとしているインコですこんばんわ。

2017年ももう終わろうとしています。
私にとって今年は、「感情に寄り添った会話をできる物理的デバイスを作る」という新規事業に最初のエンジニアとして参加し、作るべきものを考えるとともにチームを作り、それを運用するという初めての体験をした年でした。
まだまだ至らぬところも多いですが、その中でどう考え、どう行動してきたかなどをつらつらと振り返っていこうと思います。これは個人の感想でありポエムです。

Demo or Die

プロジェクトへの参加

まだ PO (プロダクトオーナー) 一人という状態のチームにエンジニアとして入った私が最初にやったことは、なんでも良いから動く会話できるものを作って見せることでした。

会話、特に雑談というのは掴みどころの無い存在です。人はそれをするのに何の苦労も感じません。
「こんな感じのいい感じな会話がしたい」というのは簡単ですが、「こんな感じ」とは何か「いい感じ」とは何か突き詰めていくと、はたと何もわからなくなるのが会話という世界なのです。
そのような、妄想が先走りがちな世界でまずやらないといけないと私が思ったことは次の２つでした。

• 企画でもできるだけ仕組みまで落ちるくらい、具体的に考える文化を作ること
• 現実を知ること

まずは私が大学時代に作っていた Twitter で会話する bot, nisehorn を Slack に移植して動かしました。
nisehorn はいわゆる用例ベースと言われるアルゴリズムですが、そのような大規模データに基づくナイーブな実装で実現できることを示しました。
（とりあえず動かす目的ですのでプロダクションに nisehorn を使うことは考えていません）

また、ふわふわしがちな議論の中で技術としてどのような方針があるのか、どういうふうに考えていくべきなのかを自身でも調べつつ共有していきました。その中で、常にそれらを実装して試せるようすることを重視しました。

中期

その後エンジニアが増え、様々なアルゴリズムでの会話システムの実装を始めてからも、この Demo or Die の考え方は継続しています。
これはスクラムでの重要な3つの核心、「透明性」「検査」「適応」にもとづいています。

• 透明性
  • チーム内の状況・成果物等をメンバー全員が見えるようになっていること
  • 研究というのは成果を評価するのが難しく、企画の人にとってはその成果はわかりにくいものになりがちです。常に動くものを作ることで、エンジニアがやっていること、それがもたらすことを可視化することができます。
• 検査・適応
  • 作ったものを検査し、適応することを繰り返すこと
  • 常に動くものをつくることで、現在の仕組みの悪い部分を見つけ（検査）、何を次にやるべきかを考える（適応）ことができるようにします。
    • 会話というのはふわふわしているので、仕組みを作ってもそれを実際に会話してみないと「良い会話」になるのかはわからないのです。そして、動かして初めて次の課題が見えるのです。
  • 目的思考：動くものを作るを最初に考えることによって、「そのように動くものを作るにはどうすればいいか」という目的から出発してものを考えるようします

２つ目の目的思考的な部分ですが、これは研究なのか開発なのかという問題だと思っています。個人的には、研究的なことをやるとしても、チームが目指すプロダクトを作るための「手段」としての研究であってほしいと思っています。具体的に言うと、「こんなデータが手に入った。これを使ったらこんな研究ができそう。」という考え方よりも「今動いているものはこの性質が足りていない。じゃあこれを実現するためには何が必要だろう。」という考え方であってほしいと思っています。（前者も時に必要なことは認識していて、そういうものは後述する20%ルールで活かしてほしいと思っています。）

これらのマインドセットは、チームの仕組みや文化で作っていくものでもありますが、同時にそのようなマインドに合う人を最初から採用していくということも重要と考えています。その素晴らしさを説いていくというのはスクラムマスターとしての仕事ではありますが、純粋に根っから研究をやりたい人に対し Demo or Die と叫んでも、お互いに不幸にしかなりません。

人を集めるということ

事業の初期に多くの時間を割かれたのは人集めでした。
私は一人目のエンジニアで、そして他のエンジニアを探す際にそのエンジニアを評価できるのも私だけでした。
人の採用のために社内外動き回り、「エンジニアなのだからものを作りたい」「エンジニアがやる仕事だろうか」と弱音を吐いたこともありました。採用を手伝ってくれていた人事に「採用を舐めるな」と怒られ、元ベンチャー CEO の人からは「新規事業初期の仕事は資金集めと人集めがそのほとんどだ。資金があるだけ恵まれてるよ。」と諭されました。
その後素晴らしい人材を何人も取れて、結局その時周りに言われたことはそのとおりだといまでは思っています。
優れた技術を持っている人をとること、チームの文化として作りたいものに親しいマインドを持っている人をとること。

研究開発でのスクラム

今私達が作っているサービスは、まだ市場にお手本もなく、どうすれば良いものになるのか、そもそも良いものとは何かさえあやふやなものです。従って、とにかく動くものを作りそれを検査・適応を繰り返すことで良いものを作っていくべきだと考えました。つまり、スクラムの枠組みで開発をしたいと考えました。
一方でこのサービスは既存技術を導入すればすぐ実現可能なものではなく、幅広い技術を研究開発する必要もありました。

研究開発にスクラムを導入しようとした時にぶち当たる壁は２つありました。

• 属人性
  • 研究というのはスペシャリストの世界です。一方でスクラムというのは属人性を排除しチームでものを作るのを良しとします。
  • 初期にはチームでの研究という路線でチームを作ろうとしていましたが、メンバーから「研究では広く浅い知識を持っている人より、狭く深い（=ちゃんと理解した）知識を持っていることが重要」と言われ、その後スペシャリスト方面にやや舵を切りました。
  • 実際に進めていく中で、音声対話というとてつもなく幅広い技術が必要な場ですべてを深く理解するというのは無理というのは実感しています。
  • 伝導するスペシャリスト
    • 一方で「技術的知見共有会（通称、技会）」で各人の知見を共有することで、自身でそれをゴリゴリすすめるまではできなくても、議論はできるという広さを常に確保することは大事と考えています。
    • 「自分の知見を教えることが賞賛される文化」「教えてもらったことに感謝する文化」ができるととても良いチームになるというのが今年の大きな感想です
      • マサカリ文化というのも一つのシステムとしてありなのでしょうが、私はマサカリ怖い人なので、誰かが知見を共有したらまず真っ先にみんなで感謝し、肯定するという文化を私のチームでは作っています。
• 見積もり
  • 研究的な要素が入ってくると、特にその中でもディープラーニング系の技術が入ってくると、工数の見積もりは非常に難しくなります。
  • 期限や成果をあまりかっちり求めすぎるとチームが上手く動かなくなり、また逆に期限感をエンジニアが持っていないと無限に一つのテーマをやり続けることになります。
  • このあたりは今のところは PO ・企画含めた各メンバーでの信頼感で今のところは回っています。その信頼感を作る上で役に立っているのが上述した Demo or Die です。また、研究という特性上やれば動くものではないという前提は最初に PO ・企画と共通認識を持っておくことが重要です。

結局、スクラムをそのまま研究開発に当てはめるのは合わない部分が多く、「透明性」「検査」「適応」という考え方を重視し他はフレキシブルにやりましょうという似非スクラムで現在は回しています。

ディープラーニングで TDD でペアプロ

少し余談ですが、研究ぽいこととスクラム文化をうまく合わせる試みとして、ディープラーニングのモデル作りをペアプロでやるというのをやっています。
これは特に、ディープに不慣れなエンジニアをディープな世界につれてくるのに有用でした。
（開発の進め方は個人個人で好きな様にやってるので、 jupyter で書いてる人ももちろんいます）

• 用意するもの
  • 巨大なディスプレイ
  • 机の上に敷くホワイトボード
  • tensorflow
  • emacs と保存したらテストが実行される save-hook の elisp（任意）
• 手順
  1. 論文をふたりとも読んでおく
  2. 作るネットワーク図をホワイトボードにゴリゴリ話し合いながら書く
     • 先に概念的なネットワーク
       • ここまではわりと誰でもできます
     • 次に concat とか reshape まで含めた tensorflow 的なネットワーク
       • 特に tensorflow などは使い方が独特で、 Deep の理論はわかっていてもここがわからないという人が多い印象です
  3. concat, reshape, split などデータ処理系をペアプロ ＆ TDD で作る
     • tf.constant や tf.placeholder で入力ノードを外から与えて、 session.run でテスト実行すれば TDD できます
  4. ディープラーニング的なネットワーク部分をペアプロ ＆ TDD で作る
     • ここでの TDD は「データを流し込んで実行してもエラーがおきない」程度に
     • 保存のたびにネットワークが実行されるのでミスに素早く気づけます

TDD 的な部分は save-hook 使っても jupyter 使ってもどちらでもかまわないのですが、 TDD だと作ったものをそのままプロダクションに突っ込めたり、データ処理系で品質保証されるというメリットがあります。
（一方で設計をあっちこっち変えてみるみたいな試行錯誤はやっぱり jupyter の方が強い気がします）

ディープラーニングでペアプロするときには、混乱したときにとにかく手で絵を書くとなんとかなることが多いので、巨大なホワイトボードのシートを机の上に張っておくのはとても有用でした。

その他の試み

20%ルール

作り方の王道が全くない研究的な要素があるプロダクトの場合、エンジニアはいろいろなアイディアを思いつきます。また、読んでみた論文や本からインスピレーションを受けて何かを作りたいと思うこともたくさんあります。
このようなクリエイティブなプロダクトでは20%ルールは必要だし、うまく動くと考えています。
上記のようなアイディアは思いつきレベルだったり、挑戦的なアイディアだったりで成果が実際出るかは思いついた本人も含め確信がもてません。そのようなものをチームでの計画の一部に含めるとプレッシャーが高くなり様々な技術的な小さな挑戦がなくなってしまします。
そのようなアイディアを活かす場として、週のうちの半日〜1日をそれらの実験等にあてることで柔軟にいろいろなことを試せる体制を作っています。
（私達がやっている会話という分野は、真面目なアルゴリズムから思いつきのちょっとしたアイディアまでいろんな技術やアイディアの組み合わせで動くという性質によるところもあります。）

この20%をやる上で大事なのはその価値や目的を上に立つ人とエンジニア双方にわかってもらうことです。
なので、以下の3つが大事だと考えています。

• 目的思考的にやること・やりたいことを考えてもらうこと
• 成功しても失敗してもその成果をチームに共有すること
• 失敗した場合もそれによって知見を得たというように肯定的にチームがそれを捉えること

1 on 1

これは新規事業やスクラム関係ないですが、わりとみんな思っていることをみんなの前では言いません。
一日一人メンバーと15分くらい話す場を作ると気になっていること、やりたいことなどいろいろみんな話してくれます。自分が話したいことを話すのではなくひたすら相手のことを聴くのが大事です。

• こういうアイディアがあってこれを試したいと思っている
• ここがわからなくて困っている
• チームのここがイケてないと思う
• （企画）こういうことを試してみたいが仕組みが作れないか

また、特に人間関係というのはヒビが入ってからそれを治す場を作るのはとてもむずかしいです。
過去の部署でスクラムマスターをしていた時にメンバーの一人の反感を買ってしまい、上司からは「飯でも誘って話してこい」と言われるもそんなコミュ力もなく途方にくれたことがあります。その時に、平時から 1 on 1 をやってそういう不満を小さなときから汲み取ることと、ヒビが入ってしまっても定期的に話せる場を作ることが大事だと感じました。

ちなみに 1 on 1 は本来上司と部下でやるものならしいですが、私は組織上他のメンバーの上司ではありませんし、どちらかと言うと「困ってることはありませんか？助けられることはありますか？」みたいな気持ちできいています。

最後に

断片的に書いてきましたが、チームとして大事なのはどういう文化を作るのかというところだと思っています。
同じ目的を達成したいと願い、それを実現できる技術を試す人たちが集まっていれば、その人達に足りてないものを聞きながら PDCA を回していけば自然といいチームができます。
書いていていろんな部分ですごくエンジニアに対して甘々な感じに見えますが、上記ができてればみなびっくりするくらい真摯に目的に向かってものを考え作ってくれます。内発的な動機って最強だと思ってます。

昔、映画「風立ちぬ」を見た時に、若者が技術研究会みたいなのを自発的に開いているシーンを見てこんな環境、いいなって思いました。当時は研究とか最新の技術とかではない開発をしていたのでそういうのが憧れでした。
この前、学会から帰ってきて話をしているとどんどんメンバーが集まってきて、今度の技会でその分野について調べてたことを話すよなどといった話になり、今自分はとてもいい仲間に恵まれているなと思うと同時にそういうチームを作ってこれたことを嬉しく思いました。

チームの良さというのは最終的に良いプロダクトを産めるかどうかです。今のチームはまだプロダクトという成果も出しておらず、これが良いのか悪いのかというのはまだわかりません。
これからもチームのあり方も検査と適応をしていきながら、より良いアウトプットを出せるよう頑張っていこうともいます。