試行錯誤で確立したU-NEXT流アジャイル開発

日進月歩で変化していく動画配信技術。そうした状況に柔軟に対応するため、U-NEXTではアジャイル開発を導入しています。U-NEXTの新たな開発体制を整える役割を担ったエンジニアの方にお話を伺いました。（このインタビューは2016年10月に収録されました。）取材・文 / 佐治和弘　撮影 / 藤田慎一郎

エンジニアの「集団」を、ひとつの「チーム」へ

U-NEXTに入られる前は、どのようなお仕事を？

大学在学中に起業して、2年間ほど組み込みシステム系の事業をやりましたが、うまくいきませんでした。その後ソニーに入社、5年間、カメラ周りの開発、主に制御ソフト設計、トラブルシューティングなどを行っていました。スマホの普及でデジタルカメラの市場が連年縮小し、気がついたら、カメラを作っている私自身も携帯電話のカメラばかり使ってました。

スマホがデジタルカメラの領域までカバーする時代になっていたのですね。

将来性を感じたAndroidに関われる会社を探して、AOSPメディアフレームワークを提供しているPacketVideo社に転職しました。ここでは５年間ほどAndroid用メデイアプレーヤー周りの設計・実装、モバイルアプリの開発をやりながら、複数種類のメディアDRM技術を扱いました。その後、事業売却のために半年かけて全社のインフラを整理し、売却完了後に退社しました。2015年の年末にU-NEXTに入社しました。

U-NEXTへ入社してから、主にどのような仕事をしてきたのですか。

入社直後はメディア技術周りの経験を生かし、新しい配信方式の導入に関わりました。その過程の中で、開発効率改善の必要性を感じ、エンジニアのチームアップを始めました。

チームアップとは、具体的にはどのようなことを？

簡単に言えば、開発体制の整備ですね。前職のPacketVideoはアメリカ西海岸系の技術会社で、Agile的な運営やDevOpsの導入が進んでいたんです。そのノウハウと経験に加えて、当時から温めていた「こうしたらもっと良くなるのに」というアイデアを盛り込んでU-NEXTに持ち込んでみました。

アジャイル開発には、絶対的な正解はない

まず、どういった段階から始めていったのですか？

そもそも「正しいアジャイルは存在しない」という前提を皆で共有しているんです。「やってはいけない」ことは明確にあるのですが、それ以外についてはチームの状況や目の前の課題に合わせて柔軟に運用して、常に改善していかないと、実態に合わなくなってしまいます。教科書を読んでも、セミナーに参加しても、誰かの経験を聞いても、それはあくまで参考にしかならなくて、自分たちのチーム状況に合うものを作っていくしかない。「正解に至る手順書があるわけではない」ということを、まず皆が納得できるようになるまで話し合いました。

マニュアルが存在するのではなく、臨機応変さが求められるわけですね。

一方で「アジャイルソフトウェア開発宣言」やフレームワークとして採用するスクラムの「スクラムガイド」という原典があるので、アジャイルやスクラムにまつわる原理原則や専用用語を全員が学びました。そこからは試行錯誤です。開発部門だけではアジャイルになれないので、プロダクトオーナー（ビジネス部門の関係者）の理解を得られるように働きかけたり、各種アジャイルのイベントやミーティングの実施手順を整えたり、認識の違いや誤解を丁寧に解きほぐしました。

現在では、どのように？

その後、U-NEXTにはスクラムが3つ生まれて、日々開発を進めています。各々に自分たちに合うローカルルールがあって、必要があれば、すぐに変えていきます。誰かの命令に従うとかではなく、スクラムごとに改善しているんです。というのも、アジャイル用語でいう「自己組織化」、つまり自分で自分を管理するのが前提なので、自分たちで考えて、自分たちで決めることが重要になってくるんですね。「管理」を仕事にするマネージャーは一人もいなくて、フラットな組織内で話し合って、ものごとを決めています。

アジャイル開発を導入するうえで、最初に力を入れたことはありますか？

何でも開放することです。あらゆる資料、ソースコードを社内のアクセスしやすい場所へすべて公開しました。JIRAやConfluenceといったツールを導入して、すべての情報をまとめたのです。機密情報にあたるような、例えば人事情報や対外的な取引条件が載っている情報を除いて、すべてオープンになっています。入社したその日から、役職や年数に関係なくすべてを見ることができます。

新人もベテランも区別はしない、と。

コミュニケーションのやり方を透明にしたかったんです。自分の教えたい情報を、欲しい誰かに簡単に伝えられるようにしたかった。ブログやWikiみたいに、情報が欲しい人は来てください、といった感じ。情報が欲しい人がConfluenceを検索すれば、大抵のことはヒットします。誰がそのページを作って、誰が編集したかもわかるので、もっと突っ込んで質問したいときに誰に聞けばよいかも一瞬でわかるようになった。細かくアクセス制限もかけていないので、例えばエンジニアではない人も開発の情報に触れることができます。

タスク管理はどうしていますか？

タスク管理もオープンになっています。これがJIRAを導入した理由で、カンバンボードとスクラムボードを使って、各メンバーが今何をやっているのか、どんな優先順位でやっているのか、これから何をやるのかをすべて可視化しました。これももちろん、開発チームだけではなく、プロダクトオーナー（ビジネス部門の関係者）も見られる状態になっています。自分の関係するタスクが今どういう状況なのか、ボードを見ればすぐに分かる。

副次的な効果はありましたか。

ボードの導入というよりはアジャイル開発の恩恵ですが、近い将来のスケジュールが見えやすくなりました。8～9割は予定通り進むようになり、計画したタスクがほぼ計画通り完結できるようになっています。アジャイル開発では、工数という概念をポイント制にしますが、初期は解決する問題の複雑さの見積もりがうまくいかなかった。半年くらい経って、やっと全員が同じ感覚を持つようになりました。

そこは見積もりを出す上で、非常に大事ですよね。

見積もりが正しくなったことで、約束したタスクは、ちゃんと予定したスプリント内で完成できるようになりました。当たり前といえば当たり前かもしれませんが、ソフトウェア開発の世界では画期的なことです。これまではスケジュールの遅延が珍しくなく、計画では8月なのに結局12月になってしまうということが起きていましたが、見積もりが正確になって、11月に終わりますと言ったら、その時期にできるようになってきました。このおかげで、納期を変更するコストがなくなりました。

エンジニアの残業状況はどうですか。

残業の時間は減りましたね。以前は、締切間近になると残業が増加していましたが、今は忙しい時期と暇な時期の波がなくなっています。実際、ビジネス部門より開発部門の方が残業時間は短いんです。アジャイルになってチームの生産性を数値化できるようになったのではっきりわかるのですが、労働時間が長くなっても、消化できるタスクの量はあまり増えていかない。だから、職場にいる時間が短いからといって何か言われるようなことはまずありません。職場にいることが大事なのではなく、コードを書いてプロダクトを作ることが大事です。

ビジネスが成長してこそ、エンジニアは技術に集中できる

スプリントの最中に追加で開発が必要になったときはどうしていますか。

緊急性によってプロダクトオーナーと相談して、スプリントのスコープを変えます。予定していたものを外して、新しいものを加えます。例えばエンドユーザーの環境に影響が出ているバグ（不具合）は至急で対処するようにしています。

ユーザーに対するフォローは緊急性が高いのですね。

ほかには、ビジネス上の緊急性というのもあります。例えば、当初は3ヶ月後に計画していたプロジェクトだけれど、目の前にビジネスチャンスがあって直ちにやらないと機会を逃してしまう場合、ビジネス部門はコミットしたくなりますよね。こういう時は、今後予定している2～3ヶ月分のプランを変えてビジネス部門の要望を叶えるようにします。ビジネスが成長してこそエンジニアは技術的な課題に気持ち良く取り組めるので、両者の協力は不可欠です。

具体的には、どのように調整するのですか？

あるアプリケーションを開発する案件が持ち上がったとき、既存の開発案件とどのように整合を取るのかが課題になりました。リリースまで3ヶ月間という目標が掲げられたのですが、既存のタスクも山積みだったんです。そこで、あるタイミングのスプリントで6~7割の開発工数をこのアプリに割り当てて、消化ポイントの状況を日々確認しながらベストな割合を探りました。ほとんど経験者がいないOS、言語のアプリ開発だったので、実際に誰がどれくらい開発するのか細かく調整し、開発速度の予測を立てて、関係者とスケジュールを調整しました。

エンジニア主導でものごとを決めていったんですか？

ビジネス上の大きな要望をかなえるために、エンジニアが知恵を絞って現実的に解決していきましょう、という進め方になりますね。開発の工数を少なくするために機能を削るとか、創造的なアイデアを生み出すとか。2～3時間の長いミーティングを3回ほどおこないました。ブレストみたいな感じで、案件の技術的な特性を把握して、すでに持っている技術を転用したり、新しい概念を新規に持ち込んだり。みんなでアーキテクチャーを構築しました。

家族よりも長い時間を過ごす仲間として

ルートンさんはスクラムマスターですが、どんなマスターであろうと思っていますか？

スクラムマスターは、チーム間のコミュニケーターの役割を果たすべきだと思っています。社外の方やビジネス部門の人とコミュニケーションを取っているので、その過程でプロジェクトの全体図を把握することができます。一方で、プランニングや反省会などアジャイルのイベントで、個々のエンジニアが何をやっていたのか、個性も含めて理解できるようになる。そうすると、マスターと話せば広く状況が理解でき、見通しが立てられるようになるので、コミュニケーションの質と速度が高まります。結果として、U-NEXTをより早く成長させることができます。

チームの話が出ましたが、採用したい人物像はありますか？

この環境に入ってきて居心地いいと感じる人柄であること、特に自分の興味と仕事の内容が近い人がいいですね。生産性が高いエンジニアは、家に帰ってからも何らか自分のプログラムを書いています。コードを書いているのが楽しいと思える人、似たような開発を趣味としてやっている人がいい。ハードワーカーというよりは、一緒にわいわいやれる仲間を探しています。面接のやり方も、最初は雑談をして、2回目以降には将来ともに働くメンバーとしてテクノロジーについて語ったりするようにしています。2時間くらい経ってしまうこともあるんですよ。

2時間も！　じっくり話して、人柄を確かめたいということでしょうか。

残業がなくても、会社にいる時間は9時間以上。起きている時間では、家族よりも長い時間を会社の仲間と過ごすことになります。一緒に居ることが苦痛だったら、お互いに不幸ですからね。とはいえ、社交性を要求しているわけではありません。ピアレビューを楽しいと感じるとか、美しいと感じるコードの傾向が似てるとか、言葉の交流じゃなくてもソースコードの交流が持てることが大事なんです。結局、根っこにあるエンジニアのモチベーションが似ている人ということになりますね。

これからはAI技術も「使えて当たり前」になっていく

これから挑戦していく領域について明確になっていることはありますか？

ご存じのようにコンピューターの処理能力は高まる一方で、アルゴリズムも洗練されていきます。例えばAIはもはや未来の話ではなく、いま活用できる技術になりました。U-NEXTのシステムにどう適用すべきかはまだ検討している最中ですが、基礎知識を身に着けるところから開始して、使える場所を見つけていくことになるでしょう。データサイエンスと呼ばれている領域ですが、U-NEXTのエンジニアはほとんど全員この分野に関わっていくことになると想像しています。ここ数年で「クラウドサービス」が一般化したように、AI技術も「使えて当たり前」になると思うんです。

メディアテクノロジー領域、特にU-NEXTならではの面白さとは？

メディアテクノロジーは、まだまだ進化する領域です。より高画質で、より高精細な映像を追求するために、世界中の技術者が発明や改善を続けています。私たちはデバイス側の再生プレーヤーの改善を中心に技術コミュニティに還元していますが、毎日のように少しずつ改良されていくのは面白いですね。それでも、実は事業の割合で言うと、メディアテック領域は2割くらいなんです。

ほかの領域に関してはどうですか。

私たちのサービスは、大量の映像作品を取り扱って販売するというECの要素も持っているので、巨大な商品データベースを持っています。作品ごとに配信期間や解像度の設定、ダウンロード可否、視聴可能デバイスなどがまちまちで、あらゆるパターン分けをしっかり制御する必要があります。すごく複雑なので、こうしたシステムが作れるなら他のシステムも作れるようになるでしょう。どんな変化にも対応できるようなデータベースにしてありますから、普通に設計すると応答性能は悪くなってしまいます。そうならないように、キャッシュを持たせたり独自のプロキシーサーバーを挟んだりして、ユーザーが快適に感じられるような速度を実現しています。サーバーサイドのエンジニアが日々取り組むのは運用保守といった定型的なものではなくて、創造的な課題解決なんです。単純作業ではなく、毎日のように考えないといけないのは面白い。

ルーティンな作業だけではなく、クリエイティブな開発が出来るのですね。

クライアント側でいうと、UX（ユーザーエクスペリエンス）すべてに関われる環境があるのも特長でしょう。可能性とかではなく、自分がやりたいと思えばできる環境です。私たちのクライアントアプリケーションはすべてデバイスネイティブな言語で実装しているので、エンジニアの実装が使い勝手を大きく左右するんです。画面遷移の待ち時間を限りなく短くしたり、乱暴な操作をしてもなめらかに反応させたり、小気味よくアニメーションしたり。

使い勝手が良くなるというのは、エンジニアの醍醐味ですよね。

あとは、動画再生技術自体の面白さですね。映像を用いたエンターテイメントは今後もずっとあるものだと思っていますが、その映像をいかに綺麗に、安定的に再生できるかという、本当にコアな部分に関係できるわけです。U-NEXTではすべての領域を自社でコントロール可能にしていて、ノウハウを持っているので、映像分野に興味がある人にとって、関連するあらゆる技術を学べる環境があります。

自分の居場所は自分で見つけるという自主性が必要

U-NEXTの職場環境については、どう感じていますか。

居心地がいいですね。管理したり管理されたりすることがない。マイクロマネジメントからは無縁です。その反面、自分の居場所は自分で見つけるしかありません。各分野にリーダー役は存在していますが、マネージャーではないんです。だから自分が何をするのか、どうやってチームに貢献したらよいのか、教えてくれる人がいません。そのリーダー達も誰かにアサインされて決まったわけではなくて、仕事を進めているうちに周囲に認められて、自然とそうなったという感じ。役職として存在しているわけでもありません。正しい見積もりや判断をできる人が自然とリーダーになっています。周りの人間も部下というわけではなく、技術的課題を解決するときにリーダーが中心の役割を果たすだけ。自律的に働ける人にとって心地よい場所です。

プロダクトオーナーとエンジニアの関係は？

プロダクトに追加変更する機能の概要を決めるのはプロダクトオーナーですが、実装する手段の選択はエンジニアに一任されています。ゴールを達成できれば何でも良いわけです。だから、エンジニアが考える一番合理的な方法で作っていきます。細かく過程を指示されることはありませんね。逆に、開発の優先順位に関しては、プロダクトオーナーが決めて、エンジニアはそれに従います。ビジネス面の責任はプロダクトオーナーが負う。お互いの領域を尊重するようにしています。

エンジニアが持つ裁量が大きいように感じます。

開発工数の3割程度は、エンジニアが自由に使えるという取り決めもあります。ビジネス面の要求は近視眼的になりやすいので、数年単位で考えたときに明らかに非合理な選択をし続けてしまうリスクがあります。とにかく納期を優先してサバイバルコードが量産されたり、技術的革新を見逃して非効率な開発手法を放置してしまったり。だから私たちは3割の工数を使ってエンジニア目線で「良いこと」を実現します。最新技術を使ってプロトタイプを作る、あるとちょっとだけ便利になるツールを作る、リファクタリングをしっかりおこなって技術的負債を返却する、というように。

ほかに、U-NEXTならではの特長はありますか？

チームみんながアーキテクチャーの設計から実装、保守まで参加しているのは特徴的だと思います。全員が最初から最後まで関わる機会を持つので、作りっぱなしで逃げることができないんですね。いい加減な設計や実装をすると、いずれ自分が苦しみます。だから設計者が実装に興味を持たない、実装者が保守に興味を持たない、という状況になりません。自分のためになることをすれば周りのためにもなる。逆もまたしかりです。だから自然と個別最適よりも全体最適を指向するようになります。

新人にとっては、すべてをやるということは難しいのでは？

新人は、場合に応じて対応を考えますが、例えば「今から新しいアーキテクチャーのデザインをやるので見に来てください」という感じで勉強する機会から入ってもらったりします。実装段階になったら少しずつ手を動かして、初めての領域でも簡単なものからやっていくようにします。ちょっと他の環境と違うかもしれないのは、まずは保守から入ろう、みたいなことはありません。新人には保守だけやらせるというところも多いと思いますが、U−NEXTでは早いタイミングから他のエンジニアと同じように開発に加わります。その代わり、いつ誰にでも質問をしてよい決まりにしています。

入社してすぐの段階から、一人前のエンジニアとして扱っているのですね。

化学系の学部を卒業したばかりの大学生が入社して2ヵ月で、あるAndroid系デバイスに、他デバイス向けに作ったAndroidアプリを移植するという仕事をやりきったことがあります。彼はソフトウェア開発者として完全に未経験者でした。手取り足取り何でも教えてくれる先輩はいないので、自分で調べて、試行錯誤して、それでもわからないことを質問しながら達成したんですね。そういう自主性が必要になる環境です。