「できてる」つもりのスクラム開発はやめよう。愚直に進めていったらアナログの大切さがわかってきました

セプテーニ・オリジナルは、インターネット広告事業を中核としたセプテーニグループでサービスの企画、開発を行なっている会社です。
インターネット広告の分野はテクノロジーの進化が著しく、最近は動画広告の伸長が大きなニュースになっています。アドテクノロジーと一般には語られますが、その技術領域は広範にわたることも特徴的です。セプテーニ・オリジナルでは、ソーシャルメディア (Facebook、Twitterなど)の運用最適化ツールの開発をスクラム体制で進めているということで、詳しいお話を伺いに会社を訪ねました。

そもそもスクラムマスターの役割はどんなものだと思います？

大井田：

今日のお話は、社員が参加したスクラムマスター研修会でのご縁から生まれました。どうぞよろしくお願いします。

貫名：

はい、こちらこそよろしくお願い致します。

大井田：

「認定スクラムプロダクトオーナー兼認定スクラムマスター」の資格をお持ちだとのことですが、プロダクトオーナーとはどのような役割ですか？

注：
スクラムに関する研修や認定資格を手がけている組織としてよく知られているのは、Scrum AllianceとScrum.orgの2つ。 とりわけ、2001年設立の非営利団体Scrum Allianceは、アジャイルコミュニティーの中で影響力が比較的大きい。認定資格の取得者は世界で50万人を超える。

貫名：

プロダクトオーナーの役割は、そのプロダクトによってマーケットのニーズに答える、というプロダクトの成功に責任を持つことです。ユーザーに使ってもらうことだけでなく、収益・利益が上がるなどのビジネス価値も考慮しなくてはなりません。
どんなプロダクトを誰に向けて作っていつ世に出すのか、プロダクトマネジメントをしっかり行なうことが大事だと考えています。

大井田：

今回取材に伺うにあたって、御社の掲げられている「技術指針」というドキュメントを読みました。ドキュメントというよりもマニュフェストですよね。

注：
セプテーニ・オリジナル　技術指針
http://www.septeni-original.co.jp/culture/policy.html

序文
この文章は、セプテーニ・オリジナルに所属する企画者・エンジニアの指針となるよう、2016年5月当時の我々の目指すところ／我々が取っている行動の理由／我々が求める姿勢、を文章化したものです。

貫名：

ありがとうございます。少しこの会社についてお話をしますと、当社の親会社はインターネット広告事業を行うセプテーニで、私たちはセプテーニの広告運用ツールの開発など、アドテクノロジーをより進化させるために生まれたエンジニア集団です。当初はセプテーニの中の一部署として存在していましたが、よりエンジニアリングのレベルを上げ、技術力の強化を目的として、分社化しました。

会社設立からしばらくして、グループ会社および外部に対して自分たちの理想を宣言しようという気運から「技術指針」を作成しました。今ではこれをきっかけに採用にもつながっています。

大井田：

社内でのコンセンサスづくりとか、どのようにできあがっていったんだろう、と読んでいて気になりました。非常にクールな文書ですよね。ああいったものが好きな人にはたまらない。

貫名：

そうですね、一方で、宣言したからにはしっかり守らなければという戒め的な側面もあります。宣言しておきながら実際にはできていなかったら、途中から仲間に加わってくれた方にとっては凄くショックだろうなと。少し補足すると、技術指針ができる以前はとにかく「スピード重視」だったんです。でも、それでいいのだろうか、「高速高品質」が本来の目指す姿だよな、と考え直し、エンジニアを中心に経営陣も巻き込みながらまとめていきました。

大井田：

さらり、と言ってのける感じがとてもクールなのですよね。正直、嫉妬するくらい、かっこいいステイトメントだと思いました。

ちょっと話が脱線気味になっちゃいましたが、プロダクトオーナーについては伺いました。スクラムマスターの役割は？

貫名：

スクラムマスターは、一言で言うならスクラムを最大限活用してチームを成功に導く役です。スクラム開発についてきちんと理解した上で、スクラムが適さないと判断したらそれをチームに提案することも求められるところがミソなのだと思います。

大井田：

その「チームを成功に導く役」というのも、言葉のマジックでその中には実にさまざまな含有物があるということなのでしょうね。実際にセプテーニ・オリジナルではどのようなプロダクトを作っているのですか？

どんなプロダクトを作っているのか、作るのかをきちんと知るところから

荒井：

Facebook広告の運用管理ツール「PYXIS」というプロダクトを作っています。セプテーニの広告運用のオペレータ数百人が既に使っているツールです。Facebook広告も複数のクリエイティブ規格が存在しますが、それを効率的にかつ予算も簡易にハンドリングできることで高い評価をいただいています。

大井田：

この分野は、AIが導入されたり、御社の場合だと特にビッグデータ活用でなどとネクストアクションが期待されるというのは容易に想像もできるのですが

荒井：

そうですね。広告予算や入札価格の調整など運用部分の自動化については、すでに機能として提供しています。クリエイティブの自動化についても取り組んでいるところです。

大井田：

開発体制について、教えていただけますか？

荒井：

日本とベトナムのオフショアオフィスで別々に開発チームが存在します。日本では複数チームが１つのスクラムチームとして動いています。

スクラムで考えるとちょっとした大所帯かなと言う感じですかね。

大井田：

では、スクラム開発のそれぞれの要素について確認させてください。まずは、デイリースクラムの実施から。

荒井：

デイリースクラムはチームごとに1日15分ほど実施しています。デイリースクラムでデジタルツールでなくホワイトボードに、各人の「今日やったこと」「明日やること」「気付いたこと」を書き記して日次更新するなんて方法をしているチームもあります。

ちょうど先日オフィスのリニューアルが行われたのですが、オフィスの壁（左右）にホワイトボードが設置され、よりコラボレーション作業がしやすい環境になりました。

大井田：

１週間スプリントなのですよね？

荒井：

はい、１週間の予定もいまではほぼ決まってきていて、

月曜日に、スプリントレビュー→スプリントレトロスペクティブ→スプリントプランニング
火曜日に、プランニング確定したチームから順次、スプリントスタート
水曜日以降は、一部の会議を除き開発作業
水曜日と木曜日には、プロダクトバックログリファインメントも実施

さらに、3か月ごとに、企画者であるセプテーニの担当者も含め、「自分たちがどういう状況になりたいのか」話し合い、その実現に向けて開発に取り組んでいきます。

少し振り返ってみると、もともとこの開発が始まった時、「スクラム開発」というものを誰もわからないまま進めていた時期があったのですが、今では全社研修や、貫名含めたスクラムマスター陣の外部研修参加というそれぞれのタイミングを通じてスクラムへの理解の底上げができてきていると感じています。

特に、週次の振り返りをするようになったことは大きかったです。
その週のスプリントでどこまで行きたいか テーマの設定と共有をみっちりしています。また、およそ1日半の工数をかけてプランニングを完了し、残りの日数で開発を進めます。この体制になってからのほうが開発スピードは間違いなく向上しました。
顧客の求めているものや課題について、エンジニア自身がいかに考えられるかが開発のスピードに跳ね返ってくると思います。

大井田：

お話を聞く限り、スクラム開発が大層首尾よく進んでいる感じがして羨ましいです。目に見えている課題はありますか？

荒井：

それでもスプリントが落ちてしまうこともあります。

そういう時は、「チームの責任はあくまでチームで負う」というのが大原則なので、 スプリントが未達成になってしまった原因の特定、解決策の検討から実行までチームに役割を果たしてもらうのが鉄則です。

エンジニアにとっての理想の環境は

貫名：

スクラム体制がうまくいっていると言っていただいたのですが、私たちにとってそれは決して成功の証ではないということを自戒しなきゃいけないとも思っています。
この会社でスクラム開発を推進してきた者としても、特にそう思いますね。

私たちも最初は「なんちゃってスクラム」のような感じでしたし。

大井田：

それが、明確にできるようになったなと思われたのはなにがきっかけなんですか

貫名：

スクラム開発そのものは、あくまでも手法でありツールの一つ。目的達成のためのツールですよね。そして、大事なのは「わかったふりをして遂行しない」ということです。私はスクラムの勉強に関しては実践も愚直に繰り返し行ってきました。

そして、メンバーも優秀なのでそれに適応してくれたことが大きいのではないかと思っています。

大井田：

ベロシティ計測などはどのようにされていますか？

荒井：

ストーリーポイントはプランニングポーカーを使っています。

大井田：

具体的には、残業ってありますか？

貫名：

当社では全社員に「裁量労働制」を適用しています。とはいえ、障害発生などにより土日に作業が発生する状況もゼロではありません。その際は、次に繋げるためにも「なぜそんな状態が生まれていたのか」をチームに持ち返って改善をしてもらう、そういう文化はできていると思います。

大井田：

では、弊社でもぼく自身が頭を抱えますが、エンジニアの評価はどのように？

貫名：

チーム開発であるが故の悩みも少しあると思いますが、スプリントプランニングに貢献した人の評価やプルリクエストに対して積極的にコメントしてくれた人の評価は難しい点があります。

会社としては以前より３６０度評価を導入して、この改善には今まさに舵を切ろうとしているところです。

取材を終えて

認定スクラムマスターでもある貫名さんは、スクラムマスター同士の横のつながりを大切にしておられます。 そのつながりにおいて、スクラムに関わる人同士で学び合い、適切なスクラムを使いこなせるチームが広がっていくということを考えているからです。

日本国内では、まだスクラム開発を採用している現場がそれほど多くありません。「スクラム」を知らない人も少なくありません。今回直接お話を伺って、セプテーニ・オリジナルでは随分きっちりとスクラム開発を進めておられるということもよく理解できましたし、その秘密がアナログに帰依するみたいなお話も非常に印象深かったです。

デジタルツールを開発するものとして、大きなヒントをいただきました。どうもありがとうございました。
開発現場にスクラム開発を忠実に適用するためには、越えなければならないハードルがいくつもあるのは事実でしょう。
でも、そのハードルは現実のものなのでしょうか？ いたずらに作られた幻影ではないでしょうか？ そんなことも思いました。

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