LEAN ENTERPRISEに学ぶ、新放送サービスi-dioの開発の今後

LEANシリーズを順番に読んでいたのだけど、なかなか日本文化にはなじまないと思われるものもあって、どこを学べばと思っていたら、「LEAN ENTERPRISE」はまさに今読みたい一冊だった。ページ数の割に短時間で読むことができるのだけど、関係者に推奨したいと思うので、弊社の事例をなぞりながら、内容を復習したい。関係外の方々においては、こんなアジャイルな開発手法を取っている放送局があるんだぁ、ということでご笑覧いただければ。

なお、新放送サービスi-dioのシステム概要については、日本ITU協会が発行する「ITUジャーナル」に近日寄稿する予定なので、そちらも合わせてご参照されたい。（英文版も出るそうです）
ITUジャーナル | ITU-AJ

リーンエンタープライズ ―イノベーションを実現する創発的な組織づくり (THE LEAN SERIES)

前提：新放送サービスi-dioのシステムについて

• 世界でも前例のない放送システムで、フルスクラッチでの開発が必要であった。開発期間はごく短い。
• システムのうち、ソフトウェア部分は50万行規模。内製でグループ会社がインテグレーションを担当。
• ハードウェア部分は複数ベンターの既存機器の組み合わせで構築されており、放送システムとしての採用事例がないものも多い。
• マスター機器、送信所、受信ソフトウェア、放送運行システム、それらを支える運用ルールが同時多発的に平行開発される。
• 放送の仕様は柔軟で、常時新たな技術的なチャレンジが導入される。つまり、仕様が動的であるために、ウェブサービス的な開発手法を導入せざるをえないが、「地上基幹放送局」なので、その運用安定性は飛躍的に高いものが求められる。

この段階で気分が悪くなった方は、そっとブラウザを閉じよう。逆に「面白そうだな」と思った奇特な方は、当社の扉を是非叩いていただきたい。

以下は「LEAN ENTERPRISE」の章立てに従ってまとめてみる。

２章　企業ポートフォリオのダイナミクスを管理する

i-dioは「なんでも送ることができる放送プラットフォーム」であり、現状は音声、映像、それに連動した高度なデータ放送、自治体向けの防災情報の適時配信が行われているが、さらにIoT機器向けのデータ一斉配信、ファームウェア等のOTA更新、デジタルサイネージ向けの更新データ情報配信など、さまざまな用途が開発途上にある。それぞれ、標準化された仕様がまだない世界なので、開発も個別に動いているし、開発がどんどん横に広がる上に、それらが収益化するタイミングもまちまち。その優先順位を保ちつつ、既存のサービスの保守運用を行なっていくために、個別の実験事例をできるだけリーンに立ち上げていく必要がある。企業ポートフォリオとしての管理手法は今まさに大きな課題となっているし、今週からでも改善を試みたい。

３章　投資リスクをモデル化して計測する

上で述べたような企業ポートフォリオの健全化には投資リスクのモデル化が重要である、という当たり前のことを述べているのだけど、既存事業の改善では計測しやすいものの、市場化そのものから立ち上げようという社内ベンチャー的な（自らもベンチャーなのに！）事案が多いと、リスク管理はとたんにむずかしくなる。一番シンプルなのは、エンジニア兼ディレクターが自らモックアップを作りながら検証することなのだが、アントレプレナー的なマインドセットを極めて高く要求するので、そういう人材はいない（と、後ろの方ではっきりご丁寧に書いてある）ことを前提に、社内で育成するしかない。

４章　不確実性を探索して機会を見つける

よくある「MVP（Minimum Viable Product）を作って製品の市場価値を磨きましょう」というくだり。i-dio自体も、最初にリリースした受信アプリはMVP的な要素が強く、各コンテンツプロバイダ（i-dioにおける放送チャンネルを運営する企業のこと）の仕様上の要請や今後の予定を最小公倍数的に集約した実装となっている。しかしこれが当初、すこぶる評判が悪かった。その理由はこの章でしっかり分析されていて、「実用最小限の製品とは、パブリックベータのことではない」ということだ。単に「実現できること」を最小限実装したものではなく、「顧客が使用もしくは購入したいと思う」「顧客が使い方を理解出来る」「必要なときにリソースを活用して届けられる」、つまり「最初からそのプロダクトの魅力を一部分でもしっかり表現したものを出せ」ということだ。「作ることができるか」ではなく「作るべきか」を問え、ということを肝に銘じて、今後の開発順位を決めていきたい。

５章　製品／市場フィットを評価する

私はコンテンツプロバイダ（我々運用事業者から見ると「電波帯域を買ってくださるお客様」）の営業開発と、コンテンツプロバイダと我々の放送設備を接続する部分のプロダクト（センター設備と呼称される）のPMO業務に加えて、サービス全体のマーケティング（toC分野を含む）と分析も担当しているのだけれども、この部分の人的リソースが全く足りていないので、この章はとても耳が痛い。
意味のないKPI（たとえば受信アプリを何人がダウンロードしたか）ではなく、価値あるKPI（例えば継続的にサービスを利用している顧客がいるか、それによってコンテンツプロバイダの収益は向上しているか）にフォーカスしよう、という活動は最近経営層にも積極的に働きかけながら軌道修正を図っているところだけれども、加えて次のような点にも留意したい。

• 機能を実験から検証へと進めるときに、積極的に技術的負債の返済を始める必要がある
• プロダクトは複数のホライゾンに分けて管理すること。現時点で実証され拡大されつつあるプロダクトと、明日のためのシーディングは別々に管理しないと、不確実性の高いものに投資しすぎたり、無理な移行を行うことで危険が生じる

放送でありながら市場のニーズにあわせて変化していく「i-dio」は、日々新たなプロダクトのリリースに追われる宿命にある。まだ安定していないものに一気に移行することにはリスクが高いし、かといって、今の収益源となっているプロダクトを危険に巻き込んではいけない。どのくらいの速度でそれが入れ替わるのかはまだ誰にも予想がつかないので、慎重に予測していく必要がある（2016年になっても「ワンセグ」が廃止されないぐらい、過去の放送は硬直的であった。それに対してi-dioは、放送開始から6ヶ月の段階で、すでに放送フォーマットの（法的手続きを伴わないレベルの）細かい変更は、すでに誰にも気づかれないところで、何度も行われているのだ）

６章　継続的改善をデプロイする

当初の想定を大きく超える規模のシステムとなったi-dioは、テストとデプロイの自動化が放送設備ゆえに非常に困難で、どうしても週に１回の「放送休止帯」にサービスをリリースしたりすることが多かった。また、変更承認のプロセスも当初は行き届いておらず、意図しないデグレにも、放送開始直前には悩まされた。みんな大嫌いにちがいないRedmineのチケットを毎日何百枚も読みながら、全容を把握することに必死だった初期が懐かしい（まだ開発リーダーになってから１年しか経過していないのに！）。
現時点では、大きな変更を伴うコミットのみにセルフチェック的な申請メモを添えてチケットを送付すれば、24時間以内にリリースが承認される体制が概ね整っている。子会社側での体制の改善も効果を出していて、おそらく、世界で一番アジャイルな放送機器開発チームなのではないかと自負している。今後の課題はソースコードが肥大化しつつある受信アプリのオープン化で、複数のメーカに開発参入していただくためにも、改善をさらに加えていきたい。本書でHPの事例から説明されている、「企業のエンジニアのほとんどが、新機能の提供にリソースを費やすことができていない」状況は恐怖でしかない。リソースの付け替えを行うためには、根本的な構造変革（主にソフトウェアの）が必要だ。

７章　価値を明らかにしてフローを増やす

限られたリソースの中で山のような新規開発と現行システムの保守業務を進めていくことは、いちラジオ局を母体にスタートしたこのプロジェクトとしては未知の領域に近い。初期開発の中期には、プロジェクト間の調整が失敗し、手戻りの山で仕様策定のやり直しが大量にスタックする、といった、大規模プロジェクトにありがちな事象もかなりあった。やはりそういったときに有効なのはカンバン方式で、私はミクシィ社に在籍していたころにこの手法の有効性を強く実感したが、i-dioでもかなりお世話になった。特に「WIPを制限する」という観点で、特定のプロセスに課題が積み上がっていることを可視化できるメリットは大きい。あえてこの章に学びを足すとすれば、「カンバンはマネジメント層の目に見えるところに大きく掲出しておくと良い」。i-dio開発プロジェクトでは、部屋の真ん中、通路の中央にホワイトボードを置き、そこにチケットをすべて手書きして貼り付けるところからプロジェクトの立て直しがスタートした。カンバンの前に差し入れのお菓子をおいたりして、ちょっとした隙間時間にその前にエンジニアが集まる習慣を作るとなお良い。全体像を1日に何度か眺めるだけでも、何が課題で、今自分たちがどこにいるのかを理解しやすくなる。「未アサイン」「アサイン済み」に分けて「未アサイン」をゼロにすることだけを管理するPM、「ASAP」「Doing」「Next ToDo」「実装延期」の４つにトリアージして、優先順位を入れ替えたり、潔く諦めることに集中するPM、と役回りを分担して縦横の管理を徹底したことも効果を出した（主に私は「実装延期」にチケットを動かす、悲しい役回りに専念した）。更新の追いつかないWBSよりもホワイトボードのほうが信憑性が高いので、今では本社で開催しているデイリースクラムは、このホワイトボードの写真撮影のカラーコピーで代替されている（これによって削減された人的コストは計り知れない）。
ところで、ポストイットでカンバンを作るときには必ず「強粘着」のものを選ばなければならない。よくチケットが知らないうちにはがれ落ちていて、与件ごと見落としたことがあったのだ。今では強粘着以外は買わない。

ポスト・イット 強粘着ノート 75x75mm 90枚x5個 蛍光 654-5SSAN

来週からはこの手法を、放送マスター設備から会社全体に広げていきたいと思う。放送局の技術業務には「送信設備の設定変更」から「山を切り開いでアンテナを建築する」まで、１時間程度の粒度から半年スパンまで様々なプロジェクトがあるのだが、それぞれすべてが有機的に関連しているので、それを可視化しながら経営判断に有効に役立てることが、今後のミッションの肝だ。

８章　リーンエンジニアリングプラクティスを導入する

テストの自動化は今一番頭を悩ませている要素の一つだ。ふつう、テレビやラジオはその規格が変更「されない」ことを前提にしているので、ARIBが発行する仕様どおりに送信も受信も行えばいいのだが、i-dioは「仕様自体がかなりの自由度を持っている」。従って、受信ソフトにも我々が関わっている現状はよいが、普及期に入ると、その動作確認は、ガラケーの悪夢を思い出すような状況になることが予想される。
ひとつ救いなのは、i-dioはその初期における制度上の要請から、「３セグメント×３ブロック」の電波体系で設備が分離されていることだ。うち２つのブロックをマルチメディア放送会社が担当し、２ブロックを「Ch−Lo」「Ch-V」と呼び、残りの１ブロックはまだ免許が割り当てられていない（新規参入事業者に割り当てられる予定）。このLoとVで、我々は「放送波自体を用いたA/Bテスト」に近いことが実現できる体制にある。実際に、Ch-LoとCh-Vは、運用上問題のない範囲で別のバージョンのソフトウェアで運行されることがある。

９章　製品開発に実験的手法を使う

いまの我々に一番求められているのがユーザーインタビューなどの手法だと思われる。放送局はエンドユーザーに直接商品を提供できる立場でありながら、実はユーザーとのコミュニケーションがあまり上手ではない。思い込みで製品開発を行わないように、必要なフィードバックを提供するのも私の仕事なのだが、果たして手があと何本あれば足りるのか。この分野で知見をお持ちの方は、ぜひ当社の扉を（以下略

10章　ミッションコマンドを実行する

放送開始半年で、すでにi-dioにはレガシーなプログラム、というものが存在している（それだけ進化の速度が速いのだ）。それらを除去していくことは極めて困難なのだけれども、ビックバン的な入れ替えを目指すのではなく、「ストラングラーアプロケーション」パターンを用いて、次第にレガシーな部分を周囲から絞め殺していくアプローチには、いくつかの不問律がある。「既存の機能を移植しようとせず、新機能から植え替えていく」「テスト可能性とデプロイ可能性を考慮して設計する」「早く届ける」。これらのルールは新PMOチームは忠実に実行してくれているように思うので、安心して推移を見ていきたい。

11章　イノベーション文化を育てる

この章にある至言はひとつ。「安全に失敗できるようにする」。失敗した場合、ひとつの根本原因を特定しようとしてはいけない（もっと複雑である）。原因と対応策を整理することはもちろんだが、世の中はそんなに単純に出来ていない（単純化して、誰かに責任を集中させたがる経営者がよくいるが、あれは何も解決しないし、組織は萎縮するし、害悪でしかない）。

12章　GRCにリーン思考を取り入れる

コンプライアンス的な重要ポイントを明確に分離して、それ以外の部分について権限移譲を進めていくべき、という章。当社では意図していなかったのだが、最も重要な設定を司るシステム（放送に向けてデータの多重化を行う装置の一種）が特定の職能のエンジニアにしか設定できない難易度のものであったが故に、うまく機能していたように思う。しかしその設定部分は本来オープンに他のシステムと通信するように出来ているので、今後はこの部分をオープンにしていく活動が、事業の進化を司っている。

13章　財務管理を進化させて製品イノベーションを促進する

i-dioはハードウェア、ソフトウェアの先行投資が極めて大きい事業なので、この部分は極めて専門的な対応を求められるのだが、それに怯えて判断が遅れると致命的なので、2017年の最大の課題はこの章にあるかもしれない。年次予算編成やシステムのパフォーマンスではなく、そのサービスがデリバリできないことによる遅延コストや、プロダクト単位での積み上げでの思想を定着させるには、現場レベルでコスト意識を明確に持つことが事前に必要だろう。

14章　ITを競争優位にする

この章の中に「災害に備える」という章がそっと入っているのだが、i-dioにおいてはこれこそが要だ。そのための対応は、システムの多重化や復旧手順のドキュメント化などの点では、放送局としてのノウハウの蓄積があるので法令を遵守して対応できているが、今後はシステムの複雑化を前提に、「復旧手順や検証の自動化」がキモになる。通常の放送局に比べて圧倒的に設備のIP化が進んでいるので、遠隔監視もかなりの深度で進んでいるのだが、そこから原因を特定し復旧するまでの部分は人的なノウハウに依存する部分もあり、これを自動化することが重要だと思われる。

15章　今いる場所から始めよう

言わずもがな。「いつやるの？」「今でしょ」。

改めて振り返ってみると、放送局の業務とは思えないことがたくさんあるけれども、それが比較的IT的であるが故に、世界の最新のナレッジを放送に導入しやすくなっているようにも思う。きょうで３３歳になったけれども、３０代を費やす事業として、引き続きプロダクトの進化に力を注いでいきたい。