大切なことはだいたいコールセンターのアルバイトで学んだ

サークルを途中で抜けたこともあり、大学の頃は結構時間があったのですが、貴重な学生の時間を無意味なアルバイトで浪費したくなかったので、自分なりに色々考えてバイトを選んでいました。

楽天のショップの運営を通常店舗の裏でやるバイトもなかなか経験としてはよかったのですが、一番やってよかったとおもっているのが、某放送会社のコールセンターのバイトでした。これから先、AIにコールセンターの仕事はどんどん置き換えられていくと思うし、いま経験しないと先々同じような経験はバイトではできなくなるのかもしれない。15年近く前の話だけれども、いまバイトを探している学生の参考になったらいいかなと思い、何が役に立ったのか、メモしておきます。

（15年前のこととはいえ守秘義務は有効なので、以下適当にぼかして書きます）

教育システムが洗練されている

コールセンターのスタッフは、バイトだろうがその企業の顔として顧客に向き合うので、相応の事前研修を行った上で送り込まれます。しかも大規模なコールセンターでは、受託している会社が複数いて、私の入った会社と敵対会社が、あからさまに座席数を増減させられながら同じフロアに座っているようなこともあります。したがって、品質向上のためにも初期研修はかなり力の入ったものになります。

とはいえ研修中も給料は発生するので、あんまり悠長にやっている場合でもなく、座学とロールプレイがコンパクトに10時間ぐらいにまとめられていたと記憶しているのですが、いまやっている事業で新しいメンバーに事前研修をしていてもあんな風に手際よく教えられていないな、と思うことがあるし、よい研修を設計するには、自らよい研修を受けるしかない。いまもう一度あの研修を真面目に受けたら、学ぶことはもっと多いだろうなぁと思う。

ナレッジシステムの整備方法を学んだ

サービス系のコールセンターなので、常に状況が変化するし、対応にはイントラネットで最新の情報をチェックしながら迅速正確に回答することが求められる。そのために、「当日業務に入る前にぱっと目を通すべき情報」とか、「この問い合わせを受けたらこれもちょっと見ながら答えろ」みたいなリンクがすごく充実したイントラネットが構築されていくわけです。これに近しいものを目にしたのは、新興IT企業に転職したときに、最初に見た社内WiKiで、あれはどうやらその年の新卒社員が入社時研修で更新作業をすることになっていたらしい。こういうものをセンス良くまとめ上げるのは結構ノウハウが必要だし、いま私のいる会社は「全員が違うことをやっている」会社で、こういうものを整備するモチベーションがなかなか湧きにくい（結果として、引き継ぎの時に苦労するのだけど）ので、今でもああいうものをちゃんと構築しなきゃなぁ、と思い出すことがある。 

外国人の問い合わせ対応の課題がリアルにわかる

 扱っている商材の関係で、複数言語のネイティブのオペレーターが常駐していて、外国語サポートデスクが運用されている現場でした。IVRで自動的に適切な言語のオペレーターにつながるのだけど、たまに操作を間違えた人が日本語オペレーターに繋がったりしてくるわけです。日本人オペレーターには外国語で対応することは認められていなくて（当時私は大学で中国語をちらっとかじっていたので使ってみたい気持ちもあったのだけど、会社として適切な対応ができているか保証できる体制にないからそれは仕方ない）、もう少し近くで対応を見てみたいなぁとも思っていたのだけど、終日複数言語のオペレーターを常駐させるというのはコスト的にも結構大変なことで、インバウンドって気軽に言うけど、その対応体制の構築ってすごい大変なんだなぁと当時も思っていました。いまはもっと外国語の問い合わせは増えているだろうし、どういう風に対応しているのか、機会があればもう一度見にいってみたいところ。

どんな問い合わせが来そうか、事前予測しながら商品設計できるようになる

会社員になってから何度か、ウェブサイトや説明書に記載する「よくあるご質問」を想像で事前整備したり（そう、始まったばかりのサービスは自分でそれを想像して書くしかない）、有人のコールセンターをBPOで立ち上げるにあたって、事前にFAQを渡すような業務をしたことがあるのだけど、これが本当に複雑な想像力を要するわけです。サービスを作った本人には見えない疑問点って無限にあって、商品を使う前から解約・廃棄までの時間軸、使う人のリテラシーや思い込み、環境の違いなど、複数のパラメータを脳内でいじくりながら、ひねり出して、それを普遍化して出していく。複数人担当者がいればブレストしたり、カスタマージャーニーを描いてみたりしてもいいけど、大抵の場合、ベンチャーの新規事業にそんな悠長な時間はないので、勘でつくるしかない。けど、結局出しきれなくて、問い合わせコストが爆発する。

結局、いろんな問い合わせに晒される体験をすることが、このスキルを伸ばす一番手っ取り早い方法だと思うのです。よいFAQは、サービスの信頼度をぐっと引き上げます。

商品ラインを統廃合することの重要性を理解する

私のいたコールセンターは、複数のサービスが合併してできた事業を展開していて、過去のサービスが展開していた契約体系をまだ引きずっている時代でした。しかも現時点のサービスも毎年新しい料金プランとかサービスが増えていて、A3の紙に6ポイントぐらいで印刷された料金表とにらめっこしながら回答するわけです。

私はこういうのを暗記するのが結構好きな方なのでいいのですが、お客さんも自分が何を契約しているのか正確に理解できていないことが多いし、戦略的な商品をリリースしても、過去のサービスとの整合性の調整で、コールセンターにはものすごい対応コストが発生するわけです。

戦略性を損なわないために、ときどきばっさりと旧プランの廃止を行う必要があるわけで、そういうときはコールセンターはクレームと問い合わせの嵐になりかねないわけですが、とにかくこれを怠るとどんどん自分の手足を縛っていくことになるんだな、 と痛感しました。

音声で対応しやすい商品企画、について想像力が深まる

 最近のPCのサポートは遠隔操作なんかもあったりしますが、ほとんどのコールセンター業務は電話かメールでやりとりするわけで、これがとにかく難しい。

まず、相手が何を見て話しているのかを把握することが、会話の食い違いを避けるために重要です。ウェブサイトを見ているのか、チラシを見ているのか、情報誌を見ているのか。しかもそれも複数種類あるし、最新のものを見ているとも限らない。

機器の操作を必要とする問い合わせの場合はさらに難しくて、同じ機器がこちらの手元にあるとも限らないし、相手は必ずしも型番などを把握しているわけでもないので、外形的な特徴からなんとなく探ったりするものの、機器の裏側などは見える位置でもないので、手探りで操作してもらうことにもなります。

そうすると、チラシや機器を設計する段階で、資料番号や発行日、情報の有効期限を見やすいところに書いておこう、とか、操作の重要なポイントになるところでは特徴的な色使いや、区別しやすい形を作っておこう、といった工夫をしておくことが重要になります。数字や記号に見分けにくい文字を使わない、などの工夫もとても大事。

散々この対応で苦労したので、私がいま作っているサービスでは、複数のページがあって最終申し込みがあるフォームではボタンを他のボタンと違う色にしたりとか、ヘッダーの色使いをサイトごとに変えておいて、とりあえず「何色のホームページをみていますか？」と尋ねたりするような細工を入れています。

つまり、トークスクリプトとはUXそのもの

 こういったノウハウは、電話のコールセンターに限ったものではなくて、たとえばウェブサービスやアプリは、サービスの画面内で完全に説明を尽くしながらユーザー自身に操作をしてもらわなければならないし、最近のアプリは「操作しながら段階的にサービスを自然に理解する」のが常識だし、ユーザーはどんどん「問い合わせる前に諦める」ようになっているから、本来はコールセンター以上の知見を導入しなければならないはずなのです。それを世の中ではUXと呼んでいるのだと思うのですが、どうにもそこまで考えきっているとは思えないサービスがとても多い。

特にO2O系の、リアルとネットが融合するサービスが増える昨今では、現場で発生するオペレーションも強く想定しなければならないし、過去に大規模なO2Oサービスを私がローンチさせていただいたときには、現場オペレーションマニュアルの作成で大変この知見は役に立ちました。日々お客様と向き合っている店舗の方々に安心して施策に取り組んでいただくためには、クレームを受けた時にどんなことが起きるのか、想像するチカラは重要です。

さらに、スマートスピーカーの分野でも、このノウハウは役に立っていくのではないかと思います。スムーズなコールセンター対応を、さらに日々使い続けたいと思えるくらいスムーズにしたものがスマートスピーカーの音声インターフェースなわけで、何をどういう順番でやりとりするのが答えやすいか、どこに考える間を用意するか、待たされている感をどう減らしていくか、など、コールセンター分野の人材や知見は、スマートスピーカーやAIと競合するのではなく、発展的に融合していくのではないかと想像しています。

【PR】ジャパンマルチメディア放送グループでのお仕事にご関心のある方は、表立ったポジションの募集は現状ありませんが、LinkedInで私を探してください。

スマートスピーカーが日本のラジオ業界に与えるかもしれないし、与えないかもしれない影響

必死にi-dioのサービス開発をやっていたら１年更新をサボってしまいました。サボったというか、面白い発見や知見は日々山のようにあるのですが、公共分野・防災分野の事業開発がメインになりつつあるので、公開できる情報が極端に少ないです。

さて、ラジオ業界ではGoogle Home買ったぞ！という声が結構びっくりするぐらい多くて、LINEのClova WAVEの先行提供版を買って「うーん、まだまだだなぁ」と思っていた私としては、なんとなく先走りすぎた感があります。
Google Homeが出来るラジオ関係の機能は、日本国内では

• OK Google, radikoで（放送局名）を聞かせて　でradikoを起動（ログイン不要のエリア限定版に限る）
• OK Google, （放送局名）のニュースを聞かせて　で特定のPodcastを再生（紐付けされている一部のコンテンツに限る）

のようです。純粋に、いわゆるラジカセ（ラジオの聴取や音楽の再生に特化した機器）が売れなくなっている今、スピーカー型の機器で単体完結したものが市場で売り場を確保すること自体が、聴取シーンの拡大になってありがたい、という目線で見ている人も業界内には多いと思うのですが、結構いろいろな影響が今後あるはず…いや、そこまで思考が至らないのかもしれないけど…ので、思いつく限りの影響について列挙して、数年後に正解だったかどうか、自分でも答え合わせをしてみようと思う。ちなみにココでは「日本人はシャイだから音声検索は余り使わないんじゃ』とか、既に語り尽くされている論点には触れず、音声メディアとデジタルサービスに関わる人間として興味のあるところを集中的に検討してみる。

本来ラジオが持っているバリアフリー性について再度考えなければならない

言うまでもなくラジオは視覚障がいのある方が最も頼りにしてくださっているメディアであって、元来その点のバリアフリーには強い意識を持っている人が局員にも多い。TBSラジオなどは今でも点字番組表（これは凄く印刷費が高いので大変）を発行しているし、ウェブサイトに音声読み上げバージョンを用意している局も多い。radikoにも最近音声読み上げ版ができた。i-dioアプリは視覚障がい者に優しい作りになっていない、というご指摘も既に頂いている（コレが凄く難しいのだ）。
一方、最近のラジオ番組は様々な趣向を凝らし始めた結果、バリアフリーから遠のいているところがなきにしもあらずで、再度、音声だけで動作するサービスと連動することを契機に、もう一度バリアフリーについて考えなければならないのかもしれない。番組ウェブサイトはもちろんのこと、例えば音声認識でメールを書くような習慣が定着したら、リクエストもウェブサイトのフォームではなく、メールアドレスで募集したりする時代に逆戻りするとか、もっと高度にLINEとかでメッセージを受け付けたりすることになるのかもしれない（TOKYO FMや一部の若年層ターゲットの局では、すでにLINEでメッセージを定常的に募集している番組も増えてきた）。
　

radikoの連続聴取時間は拡大するだろうが、スマートスピーカーで「初めてradikoを使う」人は当面限られる

スマートフォンでラジオを聞く人が増えてリスナーが増えたでしょう、とよく聞かれるのだが、ラジオの聴取率は聴取人数×時間で決まるもので、元々のラジオは何時間もつけっぱなしにすることを前提にしているので、１０分とか２０分とか、チラ聴きされることの多いスマホは、リーチ人数の拡大にこそ役立つにせよ、ラジオ全体のレーティングを大幅に押し上げる要素にはなかなかならない（そう、ラジオ業界からすれば、スマホで１０分間何かを視聴するというのは「短い」のだ）。そういう観点で、スマートスピーカーでradikoを使ってくれれば、スマホよりは長時間聞いてもらえるのではないかという直感的な期待は、業界内には早晩生まれるのではないかと思う。
一方、いまのところGoogle Homeは「radikoで」●●を聞かせて、と頼むと動くようになっているらしい（もしステーション名だけで動くならどなたかご教示ください）。radikoという単語をラジオを聴く習慣が全くない人が想起できるかはちょっと厳しいと思うし、結局、スマホ版のradikoからの併用というのが一般的な利用シーンになるのかなと思う。
「radikoで」と言わなくても使えるそうです。ご指摘ありがとうございました。（10/27追記）

そもそも、クラウドだからプリインストールという概念もないし、ガンガンサービスが増える一方、純粋想起で機能名を言わないとその機能を呼び出す事ができないのがスマートスピーカーの恐ろしい特徴だけれども、どうやってその機能を認知させればよいのだろう。放送波でラジオを聴いていて、一生懸命radikoの告知をしているところを聴くと「なんで放送で聞いてくれてる人をわざわざウェブサービスに誘導してコストかけなあかんねん」と私は想うのだけれども（もちろんLISMO WAVEやドコデモFMのように課金サービスに誘導するならわかる）、そのうち「スマートスピーカーでもradikoが使えます」っていう局報が入ってくるのだろうか。Googleをはじめとするプラットフォーマーにとっては、究極的に八方美人がやりやすい、素晴らしいプラットフォームだなぁと想う。

周波数ではなく放送局名の純粋想起がいよいよ重要になるのか

これまでのラジオ局はとにかく周波数を覚えてもらうことがとても重要で、わざわざステーション名に組み込んでいるところもあるし（NACK5とか、HELLO FIVEとか）、TOKYO FMも「80.Love」と毎日何百回も言っている。ワイドFM…という名のFM補完放送を始めたAM局は「FM90.X MHz AM 10XXkHz」とわざわざ両方読み上げていたり。コレの意味はいよいよなくなるのかもしれない。ステーション名を純粋想起していただかねば、聴いてもらうきっかけが今のところない。
起動のきっかけになるステーション名はどの定義を拾ってきているのかわからないのだけど、InterFM897は「897」まで発音しないとだめらしい。検索キーのブレを吸収するのが得意なのはGoogleさんでしょうと思いつつも、これはたぶんradikoアプリと連動する側の処理の問題なので、最近ステーション名を変更したステーションさんは頭を抱えつつ、radikoにそろそろ相談が殺到するのかもしれない。一方、TOKYO FMのように「番組名はいくつか知られているけど、地元のネットワーク局のステーション名がぱっと思い出してもらえないことがある」といった局はそっちで苦しむのかもしれない。

タイムフリーの導入に向けては業界を挙げてのEPGの高度化が求められるが結構たいへん

最終的にステーション名ではなく、キーワードで該当する番組を（過去を含めて）探してきてくれれば一番ステキだなぁと思うのだけど、そもそもradiko自体にも、現状さほど高度な検索機能は存在しない。これはそもそもラジオ業界にEPGという概念がなく、radikoの普及に伴って各局なんとかかんとか番宣らしきものを統一したフォーマットで整理し始めた端緒にある、ということと、生放送番組を中心に、「番組が放送されないと中身が判明しない」番組が多勢、という事情もあったりする。最近はTOKYO FM＋をはじめとした「ラジオ番組の書き起こしメディア」が定着しつつあって、これらのメディアはradikoタイムフリーへの誘導をつけるのが定番になってきているので、こういったものを肥やしにできればまた違うのかもしれないけれども、今のところは「OK Google, 横浜ベイスターズの試合を聞かせて」と言っても、ニッポン放送ショウアップナイターが再生できたりはしないし、「OK Google, たかみなの出てるラジオを聞かせて」と頼んでも、TOKYO FMは再生されない。特にTOKYO FMは「ステーション名では認知されていないが、出演者で認知されている番組」が多く、番組サイトが出演者名で検索されたときにSEOできているかとか非常に気にしているのだが、こんどはまた戦地が変わるということか。

ホームIoTの中心機器としてのスマートスピーカーが成長すると、音声広告のコンバージョンポイントが変わるかもしれない

最近のラジオCMはすっかり「●●で検索！」みたいな内容が浸透しているし、ラジオとテレビで検索ワードを変えていたり、みたいなゆるやかなコンバージョン計測も増えているけれども、ウェブ検索への誘導ではなくて、直接スマートスピーカーやSiriに「これを頼んでみて」という訴求のCMが出てきたら、音声広告としての意味がだいぶ変わるなぁと思う。「いますぐ”OK Google, 過払い金請求を相談させて"といいましょう！」みたいなCMが流れ始めるかと考えるとぞっとするけど。いまはテレビでGoogle自身が大量に「こう使うんだよ」という広告を出しているけど、日常的に刷り込むにはラジオしかないんじゃないか。

デジタルオーディオアドの日本での市場化はあるか

そういう観点で音声広告の価値が見直されると、ラジオCM制作部門が局内にある珍しいラジオ局であるTOKYO FMとしては、ウェブ広告にもいよいよ音声広告の出番が増えるかも？と、デジタルオーディオアドの米国プラットフォーマーと資本提携したりしながら将来を探っているようですけれど、果たしてどのくらいニーズがあるのかはまだよくわからない、少なくとも、スマートスピーカーが広告を頼んでもいないのにべらべら喋ることはないだろうから、当面は再度乱立するかもしれない音楽系サービスの差し込み広告枠としての活用からスタートになるのかしら。

まずはひとしきり思いついたところまで。また加筆するかもしれません。

【2018年1月31日まで・販売開始記念キャンペーン商品】Clova WAVE + LINE MUSICセット

Google Home: Over 100 of the funniest questions to ask Google Home (English Edition)

KMD&CiP ビジネスコンテストに参加してきた。日本の若者が公共分野を目指すのは嫌儲なのか？

株式会社エフエム東京はCiP協議会というものに属していまして、竹芝地区に国際ビジネス拠点を作って、イノベーション特区を構築しよう、という壮大なビジョンを掲げています。i-dioも放送行政上の特区からスタートしていますので、そういう制度面から変えていこうという取り組みを一箇所に集約することにはメリットがあります。

そんなCiPですが、今後インキュベーション機能も強化していきたいということで、ほぼ初となるビジネスコンテストが開催されました。私も支援団体の一人として、さてどんなものが出てくるのか、と出席してきました。

cipbusinesscontest2.wixsite.com

どんなチームが出場したかは説明を割愛しますが、まぁとにかく夏野剛さんが飛ばすわけです。「起業家の９割は詐欺師ですからね！」と、何度言ったことか。

ただ、この言葉は結構重要な示唆を含んでいて、夏野さんがその言葉に込めて言いたかったことは、
「ビジネスモデルとして完成していないものを売りつけるのは、相手を騙しているのと同じ」
「ITリテラシーの低い地方の高齢な経営者を救いたい、と高所からいうのは、相手を騙している田舎のコンサルとほぼ同じ」
「BtoBでビジネスモデルとして完成していないからといって自治体をビジネスの相手に置くのは、逃げているのと同じ」
「現状誰も参入していないビジネスを、自分ならできるというのなら、ブレイクスルーがどこにあるのか明確に説明できない限り、出資者を騙しているのと同じ」
ということなんですよね。

特に日本は領土が狭くてビジネスが東京に集中しているからなのか、営業モデルの部分が薄くて、人間関係で売り込もうとしたり、無意識にリクルート的なビル倒しアプローチを前提としていて、まったくその企業の営業力に見合わない商品を開発したりすることが多いような気がします。（これは全国に営業網があるから、という理由でそこに甘えがちな弊社もよく考えないといけないポイントですが）その割に泥臭い営業活動に尽力しているベンチャーってほとんどなくて、なんとなく見栄えのいいLPを作って、「俺たちかっこいい」で終わってしまう。リクルートにバイアウトしたいからそうしている、というならそれでもいいんですけど。

さらに気になったのは、課題解決＝ベンチャー、課題といえば地方の課題、みたいな流行がどこかに感じられるところで、地方創生といえばなんでも許されるきがする今の国策がそうさせるのかしら。夏野さんはここでも、「基本的に日本の人口が減る限り、地方の問題は解決しないと思った方がいい。地方経済がそのソリューションで救われるなんて、詐欺師と同じですよ」とぶった切るわけです。さすがにそれは言い過ぎだとは思うけど（地方の「経済が活性化する」は確かによほどの施策でない限り無理だけど、地方の「減少する人的／経済的資源の中で、どうやってその地域を維持していくか、スモールな解決策」はあってもいいんじゃないか）。

そういう身も蓋もない講評を見ながら（横で森川さんは平和そうな顔で眺めていた）、もしかしてこの登壇したベンチャーの皆さんには、どこか嫌儲思想があるんじゃないかしらと不安になったわけです。僕らの年代（80年代後半生まれ）はインターネットのアドテクのブームに乗っていろんなものを「広告収益でまかなう」変なムーブメントがあって、なんでもかんでも無料になっていく中でモノを売ったり、個人からお金をとったりするビジネスモデルを組むのが苦手な人が多い気がするのだけど、広告のプラットフォームがだいたい海外勢に巨大なシステムとして回収されていって、日本固有のカルチャーとして残った記事広告スタイル（それを人によってはネイティブアドと呼んだりするけど、その定義の話に踏み込むのは今はやめておこう）は「ステマ」とか呼ばれたりするし、ということで、「じゃあもう、霞でも食って生きていくか」みたいな世代が、個人からもお金とりたくないし、広告では飯は食えないしで、とりあえず誰も傷つけない分野として、公共分野になんとなく活路を見出そうとしている気がするんです。それでいいんだろうか、と漠然とした不安を覚えました。

ところでこのコンテスト、CiPの連携の取り組みとして、韓国コンテンツ振興院から推薦された韓国ベンチャー２社（この２社は立派に第１弾の投資を受けて、これからまさに成長するところ）のプレゼンもあって、会場が息を飲む立派なプレゼンを英語でこなしていました。古川享さんが興奮して自分の持ってきたデバイスを振り回しながら「もっとこういうのと接続できるように作ってみせてくれ！」とまくし立てていたのが印象的だった（古川さん、脳梗塞の後遺症で歩くのが大変そうではあったのだけど、お元気でなによりでした）。

一社は「絵文字は今や英語より使われている文字だ！」と、絵文字やスタンプをストリーミングできるAPIでアプリに提供する事業者。文字列を適切なスタンプに変換して即時に提示していて、文字コードの壁を超えてスタンプの国際流通を確かに進めそう。ノンバーバルなので発展も早そう。課題は国ごとに異なるスタンプの好まれるデザインをどう考えるか。

もう一社は「ビデオナビゲーションが次の時代はくる！」と、地図ではなく、動画で行き先案内をする映像をクラウドソーシングで集めまくって提供する事業者。AirBnBにすでにSaaSとして提供しているそうで、確かに猛烈にわかりやすいし、こういうものを本気で集めている会社ってなかった。動画とGPSから自動的に「ここを曲がる」とか、編集点を抽出してナビゲーションらしく仕立てるところまでできていて、これは流行すると思った。Googleがまだ入り込んでいない分野をうまく突いてると思う。

最初から国内市場が小さすぎて、海外にいくことを前提に考えている人たちは、視点が１つも２つも高いし、課題設定の説得力が違う。ドメスティックな放送事業を展開している我々も、その点見習わなきゃいけないなぁ。

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的であるが故に、世界の最新のナレッジを放送に導入しやすくなっているようにも思う。きょうで３３歳になったけれども、３０代を費やす事業として、引き続きプロダクトの進化に力を注いでいきたい。