- トップ
- 記者に「プログラミングのスキル」って必要なの？ちなみにNHKニュースの画像生成も記者がコードを書いてます
記者に「プログラミングのスキル」って必要なの？ちなみにNHKニュースの画像生成も記者がコードを書いてます
新型コロナウイルスの新規感染者の数を示す日本地図に、毎日厳しい視線を送る男がいる。
コロナの感染拡大の今後が懸念されるが、地図がきちんと描画されているかも気になってしまう。
それは、この「NHK感染者マップ作画システム」をプログラミングしたのが彼だから。
ちなみに彼は技術部局のエンジニアではなく、いつもはテレビで解説している記者だったりする。
このシステム、記者が作りました
こんにちは、NHK解説委員の三輪誠司といいます。専門はITやサイバーセキュリティで、主に「シブ5時」や「くらし解説」などでニュースの解説を担当しています。
新型コロナウイルスの「新規感染者マップ作画システム」は、1週間で作成しました。
言語はJava、地図はSVGで、ブラウザの画面をそのまま放送で使っています。SVG形式は拡大しても劣化しないし簡単なアニメーションもできるので、4K8Kなどの高精細の流れで必ず活用される、試したいと思っていました。
地図のひな形はInkscape、ほかも基本的にオープンソース・ソフトウエアで開発しています。そのひな形をApache FreeMarkerで処理し、データをはめ込んでSVGにしてます。
デルタ株の拡大で全国的に感染者数が増えて、都道府県の枠の中に数字がおさまらなくなってしまい（大阪や兵庫など…）そのたびに細かく修正しています。
もし「これ」が無かったら…
コロナの新規感染者数は言うまでも無く重要なデータです。
しかしもしこうした自動のシステムがなかったら、
・全国から送られたエクセルなどのデータを作画の担当者に送り！
・担当者が画像ソフトで地図の都道府県ごとに数字を入れて！
・数字が間違っていないか2人でダブルチェック！
という作業が必要です。しかも毎日毎日。
データは都道府県ごとに発表されますが、中にはニュースが始まる直前に新規感染者数を発表したり、訂正したりするところもあります。
正確さを第一に、そして制作現場の負担をできるだけ減らすためにはこうした自動システムがどうしても必要でした。
このシステムには作画だけではなく、ニュース原稿を自動作成する機能もあります。新規感染者数を伝える原稿のひな形を用意して、そこにデータを入れて原稿の形式を作ります。
ただ根本的な課題は、データの入力を手作業でしていることです。
原因は各地の自治体や保健所の発表形式がばらばらで、統一のフォーマットになっていないこと。
公的機関によく見られる「エクセルからわざわざPDFに変換してメールで送る」ところや、急にフォーマットが変わるところもあります。「デジタル庁」にはこうした状況の改善を期待しています。
取材のために必要で学んだITスキル
ここまでの話で、「どうして記者がそんなことをしているの？」と思われた方もいると思います。
理由はまずNHKが「放送局」だから。放送に関する技術者は数多くいますが、まだプログラミングのスキルを持った人は少なく、スキルがある人たちは、デジタル系のサービスが増えているなかで「極めて多忙」です。
もうひとつは「万一にも失敗はあってはならない」意識が強いためか、取り組みが慎重に、きちんと体制をつくってからになりがちなところがあると感じます。
それ自体は問題では無いのですが、現場が必要としているものをちょっと手を動かして作ってみよう、トライ＆エラーしながら進めよう、という雰囲気はまだまだ少ないと感じています。
そもそも私は高校までは競泳に打ち込んだり、大学ではマジックに没頭したりで、プログラミングの経験などほぼありませんでした。
1991年にNHKの記者になって、最初に赴任した奈良県では事件取材ばかりしていました。県警の捜査のうち、二課が手掛ける知能犯やハイテク犯罪の取材に興味を持っていました。
そのあと記者7年目に「首都圏部」(現・首都圏局)に赴任したとき、同じ部署の先輩記者が「ネット社会をテーマにしたシリーズを一緒にやろう」と声をかけてくれました。
「インターネット」というものを私は98年のそのころ、全く利用したことがありませんでした。（そんなレベルだったんです！）
ただ事件取材が好きだったので「情報セキュリティー」の回を担当しました。
それが、もう大変。
ネット犯罪やセキュリティー対策の専門用語が全くわかりません。自分のコンピューターの知識はワープロや表計算程度で、マルチユーザーやらWEBサーバーやらの仕組みもわかりません。情報を繰り返し取材先に確認し、本当にビビりながらなんとか一本のニュース特集を放送しました。放送後も「表現に間違いはなかったかな」と心配で心配で。
でもその経験から、記者としてこれだ、というものを見つけました。インターネット関連の報道は国内では「未開拓」で、自分の取材テーマとして長期的に追いかけたいと。
それにはまずは取材先の話が理解できる程度になろうと、書籍で勉強するのは苦手だったので手を動かして学ぶことにしました。
自宅にあった古い2台のノートパソコンをサーバーとクライアントにして、家庭LANを構築してみました。当時はLinuxブームが始まったころで、創刊された雑誌を見ながら2日ぐらいかけてカーネルを再構築、カーネルパニックになってがっかりするなど、試行錯誤のなかでいろんなことを学びました。
Apache HTTP Serverの設定をミスるとCSVなどに保存した個人情報が世界中に公開されてしまうこと、Sendmailの設定ミスはSPAMの踏み台になってしまうことなど。
こうした手を動かした学習は確実に取材に役立ち、大きなシステムトラブルが発生した時に、原因が推測できたりするようになりました。
例えば2008年に大手航空会社のシステムが大規模な障害を起こしたとき。
会社側が発表したのは、
・Webベースのシステムで起きた。
・アクセスすらできない状態だった。
・時刻を戻したら暫定的に使えるようになった。
こう聞くとだいたい「WEBサーバーの証明書の更新ミス」かなと想像できますよね。実際そうだったのですが、見当をつけておいたことで、迅速な出稿につなげることができました。これも端末認証の知識があったからです。
行政や企業の中には、記者がITの知識が乏しいと高をくくって、明らかな嘘をついてくる担当者も少なからずいました。知識があったことで嘘を見抜いて、誤った情報を出さずに済んだこともあります。
この無駄、なんとかできるんじゃない？
プログラミングのスキルが少しずつ上がっていくにつれて、それを取材現場を効率化に役立てたいと考えるようになりました。
すごく無駄が多かったからです。
例えば台風などで大きな被害が起きると、ニュースでこのように被害の規模を伝えます。
「この台風により、午後6時現在で全国で死者は●人、けが人は●人、家屋の全壊は●戸にのぼっています・・」
こうした全国規模の集計は、国の発表を待っていると、場合によっては翌日になってしまうので、NHKでは全国の放送局で記者が取材した情報を集めて原稿にしています。
しかし放送局からの情報は「FAX」で送られ、それを見ながら社会部の記者がエクセルに手入力して集計していました。
読み上げる人、入力する人、チェックする人、情報が遅い局に催促する人など、その仕事に一線の記者が4人もあたり、1時間に1回、行っていました。
そのころ（2003年ころ）私はPerlによるCGIを覚えたので、社内のイントラにサーバーをたてて、各地の放送局の担当者がWebフォームで入力できるシステムをつくってみました。
集計が瞬時にできるようになったのはもちろん、ミスも無くなり、集計にかけていた人手が”解放”されるなどなどで、「これを外注したら、開発とメンテで数百万かかっていたな・・」というのは当時の管理職のことばです。
ちなみに現在はJSP + DBエンジンで作り直して、今も取材現場で使われています。
記者がプログラミングをする理由というのは、こういうことが大きいんじゃないかと思うんです。
この程度のツール開発に高度なスキルは必要ありません。「日曜大工」レベルで十分です。
重要なのは、ただでさえドタバタしているニュース現場をさらに混乱させないように、使いやすいUIにすること。それには、記者はどんな画面が使いやすいか、どんな情報があったら原稿が書きやすいかを把握していること。そしてもちろんスピードと堅牢性も。
通常のシステム開発では、開発担当者と現場の人が何度も打ち合わせし、要件を定義して、システムを設計、開発していきます。このため期間は長くなり、コストはかかります。基幹のシステムなどはもちろんこうした工程が必要です。
でもちょっとしたツールなら（CGIで集計する程度）ニュースの原稿を毎日書いている記者にプログラミングのスキルがあれば、必要な機能をイメージして、コストをかけずにすぐに開発することができます。
（書籍は苦手といいつつ…これは今の引き出しの中です）
いっぱい作りました
その後私はニュースデスクとして三重県と佐賀県に転勤しました。
人員が少ない地方局でよく出くわしたのは、使いやすい業務システムがないために視聴者サービスが滞るという場面でした。便利なシステムを内製できる人員もいません。
じゃあということで、簡単なプログラムを数多く自作しました。
例えば「生活情報作成ツール」。災害時にはテレビやラジオで、地域の給水の場所や交通期間などの情報、いわゆる「生活情報」をお伝えしていますが、記者が取材した情報をテレビ画面のフォーマットにあわせて入力しなおす作業が地味に大変でした。
このシステムではWebフォームに生活情報を入力すると、テレビ画面のレイアウトでパワーポイントのファイルが出力されます。それを放送システムにつなげたPCで表示して、災害時の特設ニュースなどで放送します。
このときはApachePOIで、指定した日本語フォントを使ったPPTXファイルを生成するのにちょっと苦労しましたが、これだけのシステムでも、現場の手間を格段に減らすことができました。
このほかにも「ニュース特集の構成表の自動生成」や、「テレビ画面に表示するQRコード生成ツール」など、どれもちょっとしたツールです。
でも確実に役に立ちます。ちまちました作業から記者たちを解放して、別の取材にあたってもらう。それによって視聴者にお伝えする情報が質・量ともに充実していきます。
東京に再び赴任してからは、その考えを全国に広げた新たなシステムの開発に乗り出しました。
その名も「一報くん」
もともとの発想は、やっぱり記者の労力削減でした。このときは「警戒電話」をなんとかしたい、と思いました。
NHKだけでなく多くの新聞社でもしていることですが、担当エリアの警察や消防、海上保安部などに定時に電話して、「何か起きていませんか」と聞くのです。
都会の局では一度に電話する先が数十から100か所くらいあります。一日一回でもたいがいな作業なのに、それを朝昼晩と何回もするのですから、それにかける労力たるや大変なものです。
警戒電話は、日本のメディアが重視している「一報」を支えていることは間違いないのですが、もう少し記者の負担を減らすことができないかと考えました。これが「一報くん」システムの開発動機です。
最近の消防局は、管内で起きた火災や事故などの情報を、Webサイトに掲載します。それらのサイトを自動巡回して、何かアラートが掲載されていたら、それを記者にメールや音声で通知する。クロール、スクレイピングですね。
NHKの北から南まですべての都道府県に、一報くん機能を内蔵した小型PCを送付し、（マニュアル作成も発送も記者たちがしました）全国で稼働し始めたのが2016年の冬でした。
ベースとなったのはwgetでHTMLをダウンロードし、sedによる正規表現で必要なタグを抽出、内容が更新されていればメールするという、かなり昔につくったサイト監視プログラムで、これをJavaとOpenJFXで書き直しました。
2019年には「ロボット記者」の機能も加えました。キャッチした情報から定形の原稿を自動作成し、RPAでNHKの原稿システムに送ります。
ことし8月の豪雨災害では、全国各地の河川情報や土砂災害警戒情報などの原稿を毎日100本以上、自動執筆しました。
災害だけでなくことしの7月の東京都議会議員選挙では、出口調査の結果について、41本分の原稿をロボット記者が書き上げました。
一報くんの最大の特徴は、JVM言語との連携です。Javaで書いた本体はバージョンアップごとにビルドし直さなければならないのですが、BeanShellやClojureなどのスクリプト言語を本体から呼び出すようにすれば、テキストエディタで書いてすぐに実行できます。これによって、現場の要望にすぐに応じる「高速開発」が可能になっています。
このJVM言語は、組み込みWEBサーバーの上で走るCGI的な使い方もできるようにしています。冒頭でも紹介しましたが、これを使って新型コロナウイルスの国内感染者数をまとめる「黄色い日本地図」を作成しています。
（最近はNHK内でプログラミング教室を開いたりしています）
どうして「DX」が進まないの？
ソフトウエアに詳しい方は、ここまでの内容を読んで「その程度か」と感じた方も多いと思います。
ほんとうに「その程度のこと」なんです。AIとかじゃないし、大々的に発表できるものでもなく、初歩的で地味なコードをこつこつ書いただけのものばかりです。
でもそれで仕事の環境が劇的に改善したという経験を私はいくつもしてきました。そうした地味なツール開発の積み重ねが新しいサービスの創造や、職場の「DX」といわれるものにつながるんじゃないかと思います。
今、職場にも街にも「DXを進めよう！」のかけ声があふれていますよね。
DXとは「デジタルトランスフォーメーション」、デジタル化でビジネスや社会を大きく変えることですが、ではDXが遅れるとどうなるのか？を示す「2025 年の崖」ということばがあります。
日本の企業などで今の古いコンピューターシステムを使い続けると、2025 年以降、毎年12 兆円もの経済損失が生じるという試算ですね。
また、このままではグーグルやアマゾンなどの、デジタルを使って新しいサービスを生み出している企業との差がますます開いてしまう、という危機感もあります。
ではどの程度DXは進んでいるのか。
企業へのアンケート調査の結果を見ると、DXに未着手、又は一部だけ実施しているという企業が7割近くもあります。
背景に「手を動かさない」文化
日本企業の多くがDXに踏み切れないのはなぜか。こんなわかりやすいデータがあります。
実はモバイル端末の利用者数でみると、日本は1 位。なのに、デジタル技術を持った人材は62 位と下から2 番目。
つまり日本にはデジタルが使える環境があるにもかかわらず、その人材の方に課題がある。
日本企業でデジタル人材が育成されない原因として、IT 業界の長年の慣習が指摘されています。
多重下請構造と呼ばれているもので、例えば国の省庁や企業などが新しいシステムを作りたい、導入したいと考えたとき、その開発を大手IT企業などにまず発注するというところがほとんどです。
つまり発注側の企業が自分たちで開発をしないで、すぐに下請に回してしまう。
こうした形ですと、技術力を持った人たちが命じられたことだけをやる、受け身の仕事になってしまう環境ができ上がってしまうんですね。
実際、私もITの取材を続ける中で、多くの企業でシステム開発は外部業者に任せ、自分たちは優秀な業者を探すことだけが仕事と思い込んでいる、と感じることがよくあります。
実際に手を動かして開発するエンジニアやプログラマーなどは、場合によっては5次請け6 次請けというところが仕事を担当するケースもあります。
もちろん大規模なシステムを一般企業が内製化するのは不可能です。でもちょっとしたものでも、自分たちでは作らない、作れないというところが少なくありません。そうした企業は品質についても業者に丸投げし、開発費と期間も業者の言いなりになっていないでしょうか。それぞれが胸に手を当てて考えてほしいのです。
業務のデジタル化を目指している担当者が、「自分はITの素人」と公言するような、奇妙な文化を作り上げてはいないでしょうか。自分がやりたいことは、まずは自分で手を動かしてみるというのは、IT化でなくても当然のことではないかと思うのです。
外部の開発業者は要件定義された内容に沿って開発をするのが仕事で、トライ＆エラーはできません。
無茶な要件で「そんなの無理だよ」と心の中で思っていも「頑張ります」と言わざるを得なかったり、ろくに収集できていないデータを渡されて「AI作ってよ」と言われ「とりあえず機械学習させます」と言って着手したり。
発注側にITへの理解や関心がないことによる、現実的ではないざっくりとした発注や、「これもよろしく」で、途中での要件追加や変更など。
そのようにして出来上がったシステムに、まともに使えるものがどれだけあるでしょう。
ITスキルの学習コストは著しく安く手軽になっており、今やITスキルは特別なものではありません。
なにも皆がプロのエンジニアを目指す必要はありません。
必要なことは、今の仕事の環境に疑問を持って、変えるために積極的に新しいことを学ぶ好奇心と向上心、トライ＆エラーをおそれない積極性だと思います。
今、どのような仕事をしているかにかかわらず、そうした意識を多くの人に持ってもらえれば、デジタル化で何を実現したいのかという議論が深まり、遅れていると言われる日本国内のDX化はもっと進むのではないでしょうか。
（追記）
思っていた以上に多くの方に記事を読んでいただき、誠にありがとうございました。
いただいたコメントも励みになります。特にツイッターで多くのエンジニアの方にシェアしていただいたのは、本当に感激でした。
自分の手でDXを実現したいとウズウズしている方々の思いがビシビシと伝わってきました。
デジタル庁がきのう（9月1日）発足しましたが、みなさんのコメントを読んでいると、日本の企業や官庁などの「デジタル化」につきまとう不安や不満、もどかしさを強く感じます。
わたしの記事が何かの刺激や議論のきっかけになったとすれば、これほどうれしいことはありません。
さて、いただいたコメントの中に、「属人化が課題」というご指摘がいくつかありました。
ほんとうにそのとおりで、業務システムは開発者の人事異動があっても継続しなければなりませんから、その点は大きな課題です。
私の開発したツールは「プロトタイプ」だと思っています。確かに改良しながら長く利用されているものもありますが、いずれはプロのエンジニアに改良や運用を任せます。
例えば「一報くん」。プロトタイプは私が作り、今も新たな機能は私が開発したりしていますが、ふだんは2人のエンジニアが運行管理やトラブル対応にあたっているので、私が万一倒れても、一報くんは動き続けます。
私のツールも最初から利用する人の「かゆいところ」には届きません。まずは「これがイケてると思う」というものを提供し、フィードバックを頻繁にもらって改良していきます。
仕様が固まって「ないと困る」という完成度になったら、専門職のエンジニアに運用やサポートを引き継いで、私は次のテーマを探します。
いろいろな会社で「属人化するから」という理由で開発そのものに着手しなかったというケースを聞いています。着手しないくらいなら、継続性は後で考えてまずは始めてみる、ではどうでしょう。何かに挑戦するには最初は誰かの個人的なスキルに頼ってでも始めて、それが本当に業務改善などに役に立つなら、安定運用させるための人員は後からついてくると思うんです。
ご意見、または反論など、引き続きお待ちしております！
（マジックに打ち込んでいた大学生のころです）
三輪誠司 解説委員
1968年生まれ、愛知県出身。91年NHK入局。奈良放送局、首都圏部をへて報道局科学・文化部へ。
長年にわたり情報セキュリティーや個人情報問題の取材を続けている。2014年より解説委員。
2015年よりニュースシブ5時コメンテーター。趣味はマジックと水泳。コンピュータープログラミングも多少。
