最新テクノロジーの開発現場では、スクラム開発がどう活かされているか〜「業務チャットボット作成サービス」開発

「チャットボット」という言葉を広く見かけるようになっています。これが広がるきっかけは、やはりAI(人工知能)がビジネスに活用できるようになってきたと喧伝され始めたことによります。
クラウド技術の発達により、大量のデータを安価に収集し、解析することができるようになったため、AIをビジネスに利用できるようになりました。
そのAIの活用方法の一つでもある「チャットボット」ですが、今回お話を伺ったのは、DialogPlayというSaaS型の業務チャットボット作成サービス(TIS株式会社)のプロダクトオーナーの白石さんです。

白石さんプロフィール:
氏名:白石康司
TIS株式会社 AIサービス事業部 AIサービス企画開発部 主査。
自社サービスである業務チャットボット作成サービスDialogPlayのプロダクトマネージャー。
TISに入社後、金融基幹系システム開発案件でアジャイル開発と出会い、社内のR&D部門の社内公募での異動を経て、対話システムの技術獲得を行った。現在は獲得した技術をベースにプロダクトオーナーとして事業化をスクラム開発で実践し、DialogPlayを開発中。他にも機械学習などの技術に関するオープンな技術勉強会Tech-Circle( https://techcircle.connpass.com )の企画運営にも従事。

https://www.dialogplay.jp/
https://www.tis.co.jp/

「業務チャットボット作成サービス」DialogPlay とは

大井田:

「チャットボット」そのものにも興味がありまして、今日はどんなお話が伺えるかと楽しみでした。本日はよろしくお願いします。

白石:

こちらこそよろしくお願いします。お役に立てるお話ができればよいですが

大井田:

DialogPlay は、そもそもどのような経緯で開発が進んだのですか

白石:

TISは、グループ全体で約2万人の従業員を抱えるシステムインテグレーターです。したがって、その仕事のほとんどは受託開発なわけですが、獲得した新規技術の中からサービスを開発してやっていこうという機運がおそらくどのSIerにもあると思います。そうした流れの中でタイミングよくこのチャットボットが生まれるに至ったということです。

大井田:

ということは、もともと白石さんはAIに携わる仕事をなさっていたわけですか

白石:

はい、金融系の事業部で受託開発のメンバーだったのですが、言語処理や機械学習をやりたくてR&D部門に異動をしました。またその前提条件としては、新規事業開発に取り組んでみたかったからです。「戦略技術センター」で獲得した技術をベースにして、新しいサービスを開発して事業化をするというミッションが与えられました。

いまは、DialogPlay のプロダクトオーナーとなっています。

大井田:

では、最初にこれはどのようなサービスなのかということを簡単にお話いただけますか

白石:

DialogPlayは、コールセンターやBPOのオペレーター業務、セールス/アフターサービスの問合せや情報提供などの業務に活用できるチャットボットを簡単に作成・運用できる、法人向けのSaaS型プラットフォームになります。あるサービスの問い合わせ窓口として人間に代わって対話できるチャットボットの対話シナリオの作成やメンテナンスが、機械学習技術や自然言語処理などの専門知識のない方々でも、簡単な操作・手順で行なえるという点が特徴です。

LINEやWebサイトへの埋め込みもかんたんに実装できます。

大井田:

開発のスタートはいつからなのですか?

白石:

このプロジェクトが属するAIサービス事業部は現在30名を越える所帯にもなっているのですが、始まりというと昨年の春ですかね。ちょっとあいまいなお返事になるのも、そもそもこの開発の基盤となる研究は既に存在をしていて、メンバーは6名くらいいましたかね、私がそれをDialogPlayの開発に引き継いでサービス化を進めることになったのがそれくらいの時期ということなんです。

大井田:

5月にはベータサービスが始まり、昨年の12月19日に正式リリースというと、かなり早い開発ペースですよね? 開発期間としては、つまり約1年

白石:

1年半くらいですね。

大井田:

それを支えたのが、「スクラム開発」であったと。という話だと収まりがよいのですが、いかがでしょう?

スクラム導入当初は、揺り戻しもあった

白石:

先に、改めてもともとの経緯をお話しましょうか。

金融系の事業部での大規模開発の際、これは受託開発の案件なわけですが、初めてアジャイル型を採用することになりました。大手リース会社様の開発だったのですが、クライアントさんから「今回はアジャイル開発でいこうよ」と声が掛かったのですが、いま振り返っても珍しいことだったなと思います。
ただ、内実は、いま思うと、あれは「アジャイル」になってはいなかったなぁ、とつくづく思いますけれども。

そんな様子ですから、「アジャイル開発なんてやめろ」的な圧力もあちこちから発生したり、悩みも深まってくると有志の間で『アジャイルサムライ』の読書会をしたり勉強会が活発に行なわれるようになりました。もちろん、私もそのメンバーで。
で、今回のDialogPlayの礎ができていた、ということなんですね。その頃からの経験の蓄積が現在進めているDialogPlayをやることになって活きてきたと実感しています。
でも、はじめて見ると、、、

大井田:

うまくスクラムが回らない、みたいな話なのでしょうか

白石:

開発当初は、それまでにメンバーがしていた開発を引き継ぐ状態で始まっているものですから、体制を変えたと言ってもおそらくマインドまで変わらなかったと思うんです。そのためか、計画通りに進めるということがほぼできていない状態でした。

それぞれのタスクは、もちろんメンバーの一人ひとりが相当に頑張って消化していたと思うのですが、それがプロダクトの成長につながっていなかった。その先の見通しも私自身ができていなかった。だから、メンバーとプロダクトオーナーの間の温度感というか意識の差はだいぶあったのだと思います。
開発当初だと特に、これも作りたい、こうしたらどうだろう、あれも作るべきだ、、、などプライベートのさなかにも発想が湧いてきてワクワクしっぱなしでしたから。

大井田:

スクラムマスターは白石さんが担っていたことになりますか

白石:

メンバーにも良い候補はいましたし、一時的にはチーム外のメンバーに掛け持ちで、スクラムマスターとして手伝ってもらったタイミングもありました。
しかし、片手間で、スポット参加して、なんとかできるほどスクラムは甘くはないので、当然、上手く行きませんでした。
スクラムマスターとしてスクラムチームをより良くしたいという、誰よりも強い想いを持っていなければ務まらない役割だと感じました。

スクラム開発がうまくいくための工夫と努力

大井田:

ようやくスクラムがまわり始めたなと思えるようになったきっかけはあったんですか

白石:

一言で言うと、「全員でスクラムを意識するようにした」ことですね。先ほどお伝えしたように、外部コーチを招いて3時間の講習を進めたり。スクラムガイドにある言葉が、チームの共通語になってきたと思えた時に、ようやく、でしたかね。

また、パートナー会社のメンバーも同じ熱量で開発に臨めるように周辺環境を考えることも大事でした。彼らにも、講習に参加してもらいました。

大井田:

「スクラム」の型にはまる、はめた、という感じなのでしょうか。少し使用されているツールや具体的な方法を伺っていきたいのですが、Trelloをお使いだということです。

白石:

最初からTrelloでしたね。一つには、ツールに関して必要以上にリソースをかけたくなかったということもあります。scrum for trello というChrome拡張も十分使えるなと感じたので。それを使いました。

そのリソース配分というのは、私自身の問題でもありまして、プロダクトオーナー兼スクラムマスターとして、このプロジェクトのスクラムマスターとしてのどこまでエネルギー使うかはかなり悩んだところではあります。先もお伝えしましたが、スクラム開発って相当な熱量がスクラムマスターになければならないんですよ。
私の場合、プロダクトオーナーとして新規事業の旗振り役というミッションもありましたので、現実的にスクラムマスターの時間は少しショートにせざるを得ない。だから、メンバーが自主的に開発できる仕組みが必要でした。

大井田:

ちなみに、Trelloの使い方を教えていただけますか?

白石:

Trelloはかなりカオスになってます。Trelloをひらくと結構な圧迫感がありますね。

目的ごとに、「ボード」「リスト」があります。「リスト」は粒度を細かく分けるようになっていきましたね。
スプリント計画では、スプリント計画バックログを作成しましょう。ちなみに、この時に、ストーリーポイント(フィボナッチ数)もチームリーダーが付与しています。
担当者作業が開始したら、「仕掛中」リストに移動させましょう
作業終了したら、「スプリントレビュー」に移動して、スプリントレビューMtgのときに順番に確認していきましょう
プロダクトオーナーのレビューを経たらチケットを終了させましょう
など、誰が見ても解るようになってきたのではないかと思います。

Trelloのかんばんはうまく回っていると実感しています。

白石:

課題感を感じていることもあります。
ROIの優先付でプロダクトバックログを並べ替えしましょう、と考えると、Trello 単体では優先度の紐づけが困難です。
別途、スプレッドシートで別のプロダクトバックログを作成してその優先度を示したものを知らせる必要があって、そうすると2重タスクにもなって負担増になりますから、そこまでの管理はできないという。

こういう時、他の方々はどうしてるんだろうってつくづく思います。

大井田:

先ほど少し、ストーリーポイントのお話が出ました。このポイントというのは、「難易度」なのか「作業時間」なのか「エンジニアスキル」なのか、という尺度も表現できるのではと考えるのですが

白石:

それで言うと、「作業量」ということだと解釈しています。ストーリーポイントについては、プランニングポーカーを使ったりということはしていないので、リーダーが肌感覚で設定している状態です。
ストーリーポイントについては、正確にベロシティを計測できるのがベストなんですが、そこもできてはいないですね。

これが、自分たちのスクラム開発だとまずは言いたい

白石:

この半年くらいでチームも拡大して、スクラムマスターが新たに加わっているんですよ。彼は、大阪拠点にいます。あ、前後してしまうのですが、東京と大阪の2拠点で、このプロジェクトは動いています。

大井田:

2拠点ということは、コミュニケーションレベルの問題ということが想像されます。

白石:

コミュニケーションも然りですが、大阪メンバーはスクラムのことを知らないメンバーが複数いたので知識レベルのギャップが大きかったです。それが、スクラムマスターが加わったことで大幅改善できています。この拠点間の物理的な距離は埋められませんから、東京のスクラムマスターは一部自分が兼任するつもりで割り切っています。

大井田:

スクラムミーティングはどうされています?

白石:

リモートで映像も繋いでやっていますね。スプリントレビュー、振り返り、スクラム計画ミーティングと、一気に4時間くらいやりますね。2週間ごとに4時間ミーティングがある感じです。課題検討会というのも2週ごとにやっていますが、これはチームリーダーなどメンバーを限定して開催します。

スプリントレビューは結構盛り上がってみんな楽しんでますよ。スプリントレビューは実際に動かして確認します。で、これはそもそも不具合が見つかって当たり前という認識もあるのですが、6週ごとのリリースは極めて大事に考えています。

大井田:

ミーティング、そもそも時間かかりますからね。みなさん、発言はされますか

白石:

それは確かに課題と思っているところがありまして、一部参加者に発言が偏る傾向もあります。ただ、自分たちがいいものを作っているという誇りを持ってほしいので、こういうところの工夫も他のみなさんどうしているんだろう?

大井田:

既に公開されているプロダクトなわけなので、ユーザーの声のフィードバックもあるのではないですか

白石:

そうですね。そこが難しくて「外部との折衝はプロダクトオーナーがやるべき」「開発者はチケットに専念すべき」みたいな、スクラム開発の考え方があるじゃないですか。メンバーは、「プロダクトバックログ」を見て、プロダクトオーナーと話をしていればよい、みたいな。もちろん、そのほうがノイズが生まれないわけですが。

少し付け加えると、「プロダクトバックログ」も更新すべきことが多々現れるのですが、スプリント期間中には更新しないというルールにしています。これも、主要機能とそれ以外の機能というカタチで分けていて、主要機能のリリースは必達で、と伝えています。
また、開発時には、このスプリントでどうなりたいかというビジョンを丁寧に伝えることには気をつけています。

大井田:

ちなみに、今後さらに開発強化される機能としてはどのような方針があるのでしょう

白石:

このプロダクトは「チャットボット」です。競合プロダクトも登場してきていますので、その動きももちろん注視しています。私としては、対話分析などの方向性を見ていますね。まずは、企業担当者さんが簡単に自分たちの望むシナリオで回答する「チャットボット」を作成できるという利点を認知させていきたいです。

目標としては、唯一無二のサービスにしていきたいですね

大井田:

お話を戻しますが、朝会・夕会はされていると思います。こちらはいかがですか

白石:

朝会・夕会で、毎日の課題整理をしようということはうまくできているのではないでしょうか。夕会まだはいらないんじゃないか、って声もありましたが、というのも、開発者同士は背中合わせで仕事をしていたるする環境になっているので、それなりに普段から口頭のコミュニケーションができているという実感もあります。

だから、以外とチャットコミュニケーションの比重が少ないのはこのプロジェクトの特徴かもしれないです。
少しまとめると、ドキュメント管理はdocbaseでコミュニケーションはE-mailやSlackです。大阪メンバーとはSlackが多いですね。

大井田:

振り返りにはKPT手法を取り入れられていますよね

白石:

方法そのものはいろいろ変化をつけながら、いまここ、という感じでもあります。振り返りの方法そのものも変化していますよ。10分くらいで、「Keep」「Problem」「Try」それぞれを書き出してもらって、順番に発表をしてもらいます。

その際に、「Try」は自発的なもの優先するということと、みなでやるものは2つくらいまでにすること、というルールをお願いしました。埋没するものはあまり意味がありませんからね。
振り返りについては、Timelineを採用したこともあります。あのときはこうだったね、ああだったねとこれも話が膨らみました。メンバーのマインドを上げるにはいいかな。ただ、履歴を整理するのはそれなりに大変でしたね。

大井田:

いま、このスクラム手法の改善に手を入れるとしたらどこに?

白石:

自社プロダクトでもあるので、甘えたくなる気持ちもなくはないのですが、先ほどもお伝えした通り、6週ごとのリリースは守るべきだと考えています。スクラム開発の場合、スプリントごとの開発優先で考えてしまうと、リリースの概念が吹き飛んでしまうことが気になっています。

これでうまくリリーススケジュールが約束できれば問題ないのですが。そこで、ベロシティ(生産性)ということを考えると、リリースの直前のスプリントと時期の離れたスプリントとでは明らかにベロシティが違うということが把握できています。これをうまくできるようにするには、Trelloじゃないのかな、と悩んでいるところなんですね。

取材を終えて

まさに、旬のテクノロジーでもある自然言語処理や機械学習。
ですが、驚いたことに「それでも人集めには大変だった」というお話でした。
今回のDialogPlayの要求技術は非常に高く、react-redux + AWSということで、もともと「エンジニアのモチベーションに繋がるだろう」と考えていたものの、ハードルが高すぎて「難しい」「わからない」という言葉が相次いだそうです。

この新しい技術習得を楽しめる人じゃないと無理だとわかった、ということでした。
もうひとつ、DialogPlayはすでにサービス提供が始まっていますが、「いいものを作る」ことと「売れるものを作る」ことは違う、ということを開発メンバーに伝える難しさもとても印象的でした。
私たちも、いま「TeamHack」というサービスの開発を進めていますから同じ心境でもあります。
貴重なお話をどうもありがとうございました。

TeamHackersでは、これから数回にわたってスクラム開発事例を個社インタビューを通してご紹介していきます。引き続き、ご購読をよろしくお願いいたします。

この記事が気に入ったら
いいね!しよう

最新情報をお届けします

同じタグのついた記事

同じカテゴリの記事