Audibleが最近のお気に入りになった

最近、Audibleが気に入っている。

オーディオブックは以前から知人に勧められたりもしていたのだが、聴きながら他のことをするだろうことを考えると、聴き逃すことが多いだろうと予測して、実際に試すことは無かった。

きっかけは年末年始の課題図書だった。

昨年末、支援先の1つの社内イベントでその会社の役員と対談した。イベントは社員の方々にお勧めの本を紹介し合うというものだったが、役員の方が推薦した本の1つが「サピエンス全史」だった。

サピエンス全史については、このイベント以前にも他の方からお勧めだというのは聞いていた。しかし、上下巻合わせて600ページを超えるというボリュームに圧倒されて、読む機会を逸していた。だが、年末年始。時間はたっぷりある。COVID-19もオミクロン株でまた感染拡大が見えており、旅行に行く予定などがあるわけでもない。自分を追い込むにはベストなタイミングだった。

その役員の方や普段良く打ち合わせをしている社員の方々に約束した。年末年始で完読すると。

さっそく、Kindleで購入し読み始めた。確かに面白い。さすがベストセラーになるだけはあると思ったものの、どうにも冗長に感じた。冗長というのはネガティブな言い方だが、豊富な事例や人類の歴史をまるでその当時に戻ったかのようにイメージ豊かに饒舌に語る様が、ビジネス書を読むように結果を性急に求める自分には合わなかった。少し読んでは飽きてしまい、他のことをやり始める。せっかく時間があるのに、このままでは読み終わらない。

焦りを感じ始めたころ、Amazonが絶妙なタイミングでAudibleを勧めてきた。目と耳から読み進めるという戦略に活路を見出すべく、すぐにAudibleで購入して、読み始めた(聴き始めた)。

Amazon オーディオブック audible

最初はどうなることかと思ったが、思いの外頭に入ってくる。当初心配した通り、ボーッとしていて音声が先に流れてしまっていることも多々あったが、大意を掴むには全く問題ない。もし興味があるなら、Kindleで読むか、音声を聴き逃したところまで戻して、また再生すれば良いのだ。聴き逃しても良いと割り切ることで心が楽になり、とにかく先に進めた。

すると面白い現象が起きてきた。

Audibleを聴くために積極的に散歩やランニング、ドライブをするようになったのだ。

リモートワークが中心になった当初、移動が不要になった浮いた時間を仕事で埋めてしまい、すっかりインプット時間が無くなってしまっていた。しかし、その後、不要だったのは通勤電車での移動という苦痛な体験であり、その時間で行えていた仕事以外の体験、特にインプットは残すべきなことに気づいた。これについては私がダイヤモンド・オンラインで持つ連載でも説明している。

diamond.jp

通勤や移動に相当する時間はしっかりと確保し、そこを自分時間としてインプットに活用する。そう考えてからは積極的に散歩をするように心がけていたのだが、しかし寒い。そんなときにAudibleが自分を部屋から引きずり出すモチベーションとなるものとして登場した。

サピエンス全史を聴くために散歩やランニングやドライブをする。それが楽しみとなり、いつしか日課となり、そして無事聴き終えた。

すると、次の書籍をまた聴きたくなった。タイミング良く、1月下旬からはAudibleがAmazon Primeビデオのように聴き放題サービスとなり、12万冊がその対象となったので、その中から気になるものを次から次へと聴いてみた。Kindle Unlimitedと異なり、聴き途中の本が何冊あっても良いようなので、つまみ食いのように色々と聴いた。中には期待外れだったり、難解で途中で聴くのをやめてしまったものもあるが、結構何冊も聴いた。

実は、もう1つのブログで紹介したデールカーネギーの「人を動かす」もAudibleで聴いたものだ。

takuyaoikawa.blogspot.com

「人を動かす」のような古典的な名作や、ベストセラーになっていたけど、読んでいなかった本など、Audibleで聴いてみるというのも良い体験だった。Kindle Unlimited対象となっていないものもAudibleでは無料で聴けるのも多いようだ。

また、夜、なかなか寝付けない*1ときや夜中に起きてしまったとき*2など、以前は良くないとわかっていても、スマホを覗いてしまい、余計に寝れなくなってしまっていたのだが、最近ではこんなときはAudibleを聴くようにしている。こういう寝付けないときは、柔らかい内容の本にするか、逆に思いっきり難解*3にしている。

このように最近すっかりAudibleにはまっている私ではあるが、たまに「読み」が間違っていたり、わかりにくいものがあるのが気になっている。例えば、リーンスタートアップの本で、「配送」って読んでいるが、これは「デリバリー」とカタカナで読むのが正しいはずだ*4。あと、目次がわかりにくく、本をペラペラめくって、あたりをつけて該当箇所だけ読む(聴く)というのがしにくい。しっかりと内容を把握するには、やはり書籍(電子書籍を含む)との併用が必要と感じている。実際、「人を動かす」はそのようにして、Audibleの後に書籍も購入した。

音声メディアにはPodcastなどを以前から注目していたが、オーディオブックもかなり使えるということがわかり、色んな形でのインプットが可能になった。技術の進歩とメディアの多様化に感謝したい。

*1:これでも悩みがあるときもあるのだ

*2:早朝覚醒とか。もう老人なので

*3:自分の興味とかけ離れたもの

*4:おっと、これはオーディオブックの問題ではなく、元の翻訳の問題か

商材とは

以前一時的に支援していた会社では、プロダクトのことを「商材」と呼んでいた。微妙に違和感がありながらも放置していたのだが、少しこれについて考えてみた。

実は、決して短くない私の人生の中でも「商材」という言葉を聞くことは、この会社の支援をするまでほとんど無かった。

この種の用語としては、外資系にいたこともあり、「プロダクト」という言葉が一番馴染みあるものだった。その次にプロダクトの日本語として一番適切な言葉であろう「製品」、そして「商品」だ。

「商品」という言葉でさえ、違和感があり、以前に 製品と商品 - Nothing ventured, nothing gained. というブログ記事を書いたことがある*1

商品と製品とプロダクトの違いさえ微妙なところに、商材と来た。これは一体なんだ。

調べてみると、商材は売る側が使う言葉であり、商品は売る側と買う側のどちらも使う言葉だという説明があった。確かにそうだ。客が「その商材をください」とか「この商材について質問があります」とかは言わない*2

商材とは「材」という言葉が示すように、部材であり、通常はこれに何らかの付加価値を追加して、売り物とする。わかりやすくいうと、完成品ではない。他の何か、または誰かによる補完される必要があるということだ。

確かに、商材という言葉を使っていた支援先は、その商材を単体で売ることはほとんど無かった。他商材と組み合わせたり、SI事業としてソリューションを提供する場合の部材として使っていた。

一方、昨今声高に叫ばれるようになったProduct-Ledという言葉。これはプロダクトがそのプロダクト自体の力により売れるようになるということだ。営業からのアプローチが無くとも、顧客がフリーミアムなどからプロダクトの魅力を認知し、それにより利用を開始し、契約に至るというパスを経るパターンだ。

f:id:takoratta:20220303222838p:plain

PLG

これがすべての事業において主流になるわけではないが、商材と呼んでいる会社からはこのPLG (Product-Led Growth) が起こることはない。

商材という言葉で説明される事業形態には人が確実に介在する。スケールさせるためには人的リソースの投入が不可欠である。労働集約モデルに依存し続ける。

商材という言葉を社内で使っている会社はここまで考えていないだろう。しかし、言葉には魂が宿る。何気なく使っている商材という言葉から、他の何かにより補完されることを前提としたものしか作らないというマインドセットが醸成される。

PLGが正義でもないし、従来型の営業活動が否定されるものでもない。PLGから始まった事業でも、さらにスケールさせるためには従来の営業的なアプローチであるSLG (Sales-led Growth) と組み合わせたハイブリッドが必要になることもあると言われている。

しかし、商材と言い続けることにより、PLG的な発想をすることをすることを停止しまっていて、PLGで殴り込みをかけてきている新興企業と戦うことができるのかは真剣に考えた方が良いであろう。

*1:今読むと、周りくどくて、これはこれで何を言っているか意味不明だが

*2:客が卸問屋でも無い限り

Chrome OS 10周年

Chrome OSが10周年を迎えたようだ。おめでとう。

Chromebook turns 10

東京にChromeチームが立ち上がりかけていた頃、将来計画などを説明に来ていた本社マウンテンビューのディレクターからOSを作ることを考えているという話を聞いた。Webに最適化されたOSが必要だと熱く語ったそのディレクターは東京のChromeチームの設立の支援者でもあり、東京にもそのOS開発チームを作りたいと言っていた。六本木ヒルズ近くの居酒屋だったと思う。2009年の頃だろうか。本気かなと思いながら聞いていたが、どこかワクワクする自分がいた。

その後、その話はいったんは立ち消えとなり、東京のチームはHTML5と呼ばれるWeb APIChromeに実装するチームとして立ち上がった。

しばらくして、Chrome OSが正式にアナウンスされる。

ブラウザのChromeは当時停滞していたWeb*1の進化を加速させるために開発された。"Living on the Web" --- Webに暮らす人達のために -- これがミッションだった。朝にオフィスに出社したら、自分のPCでFirefoxを立ち上げ、メールはGmail、スケジュールの確認はGoogleカレンダー、ドキュメント作成などは(まだ当時は機能も少なく、極めて不安定だった)GoogleドキュメントやGoogleスプレッドシートで行う。自宅ではYouTubeで動画を楽しみ、Twitterでどんなことが話題になっているのを知る。今となっては当たり前だが、当時はアーリーアダプターと言われるような人たちだけが使っていた環境がやがて未来になると我々は信じ、それを開発ミッションとした。

Chromeはそのリリース直後から、圧倒的な速さと安定性、そしてシンプルな操作性からWeb開発者などの熱狂的な支持を得る。以前から、HTML5という形でWebをアプリケーションプラットフォームとして進化させていたFirefoxMozillaとともに、そして後からはIE(後にEdge)とともに、Webは再度進化を始めた。

しかし、ブラウザだけでは、Living on the Webは実現できない。オフィスでPCを立ち上げるとき、特にコールドスタートという電源を完全に切った状態からの立ち上げでは、当時のWindowsは3分や下手をすると5分も待たなければいけない。私も当時インタビューで答えた記憶があるが、これでは文房具のような手軽さでスケジュールを確認したり、メモを取ったりすることは不可能だ。デバイスやOSもWebに最適化しなければならない。そのようなコンセプトで立ち上がったのがChrome OSのプロジェクトだった。

Chrome OSは完成前にアナウンスされた。オープンソースプロジェクトとしてスタートしたからというのも理由の1つだろう。そのアナウンスの場で、Googleは次のように宣言した。

「電源オフの状態から電源を入れて、10秒でGmailを使えるようにする」

10Xという言葉がある。10%向上ではなく、10倍を目指せという言葉だ。この「10秒でGmailを使えるようにする」というのはまさに10Xを目指すゴールだ。当時のWindows PCが3分かかっていたものを2分にするとかであれば、既存の方法の延長線上で可能だ。しかし、10秒となると要らないものを削ぎ落とすなど抜本的な発想の転換が必要だ。

正直社内にいた人間であっても、本当に実現できるのかと思ったが、その1年半後に最初にChromebookがお披露目されたときに、その約束は見事に実現された。

東京にいた私がChrome OSに関わるようになった時期を正確には覚えていないが、マネージャーとしての組織戦略的な理由もあり、早い時期に手を挙げ、いくつかの機能を担当するようになった。

国際化は前職*2で十分やり尽くした感はあったが、誰かがやらないといけないと思い、表示周りと入力周りで、FontとIMEに手を挙げた。前者はChrome側でのWeb Fontsの実装を行った実績があり、後者はすでにリリースしていたGoogle日本語入力を持っていたことも強みとなった*3

Fontは最初はIPAフォントで、その後はモトヤフォントを用いた。契約なども担当した。当時、ご協力頂いた方には本当にお世話になった。

IMEは日本語だけでなく、他東アジア言語も対応した。ちょうどこの頃、NHKのプロフェッショナル仕事の流儀の番組が撮影されていた。少し脱線するが、あの番組に私が出ることになったのは、私がGoogleを代表する人間だったわけではまったくなく、単に外部に公開することが可能なオープンソースプロジェクトを担当していただけの理由だ。それはともかく、あの番組で紹介されていた開発のいくつかはChrome OSIME周りの話だ。

ChromeChrome OSの開発で何度も本社に出張していたが、ちょうど本社にいるときハードウェア担当の人間から相談があった。英語版以外のキーボード配列を考えないといけないのだが、どうすれば良いだろうかという内容だった。ヨーロッパ言語についてはだいたい考えられているようだったが、日本語を含む東アジア言語はさっぱりわからないと言う。そのとき、つい以前に日本語キーボードを開発したことがあると口を滑らせた。それを聞き逃さなかった担当者から、お前やれと言われ、考えたのが今のChromebookの日本語キーボード配列だ。製造元となるOEMの事情など、色々と制約がある中では悪くない配列なのではないかと思う。今でもネタっぽく話すことがあるが、自分の中でもユニークな実績として語れるものとなっている。

IMEに関しては、台北Chrome OSチームを訪れたときに、繁体字簡体字には様々な入力方式があり、1つのデフォルトIMEを定義するだけではユーザーに満足頂けないことを知った。そこで始めたのがIME APIだ。これはChrome OSChrome Extensionの枠組みを使ってIMEの実装を可能とするものだ。Chrome OSはWebアプリしか動作しない*4ので、この方法しかなかった。

東京のChrome OSチームが自分の手を離れた(巣立っていった)のがいつだったのかは覚えていない。しかし、Chromeとは兄弟プロジェクトのようなものだし、なによりも自分がユーザーだったので、その後も社員だったときにはずっと関わっていた(と言いたい)。

自分自身がユーザーだったと書いたので、デバイスについても書いておきたい。最初のデバイスはCR-48だ。しかし、今だから言うが、このCR-48はとてつもなく使いにくかった。個人差もあるだろうが、私としてはタッチパッドの操作性が許せなかった。しかし、自分で自分のドッグフードを食べるという方針*5のもと、使い続けた。

これは素晴らしいと思ったのが、Chromebook Pixel。大きかったので携帯するのは苦労したが、ほぼすべての事務作業はこれで行うようになった。

www.google.com

その後、Googleを辞めて、ChromeともChrome OSとも正式には関係なくなったが、それでもChromebookは常に所有している。今ではAndroidアプリも動作し*6Linuxも動作する。

そして、文部科学省GIGAスクールで採用された。冒頭で挿入したツイートは小学校のプログラミング教育必修化に先立ち、準備を進めていた小学校の公開授業に参加したときのものだ。iPadで音楽の授業を行っていたり、フィジカルプログラミングとして手で触れるガジェットで体験をしている子どもたちもいた。そして、小学校2年生か3年生の授業だと思うのだが、Codemonkeyでゲームづくりをしている子どもたちの使っているマシンを見たら、なんとChromebookだったのだ。蓋にChromeのロゴが入ったマシンを2人か3人で覗き込んで、楽しげにプログラミングしている様子を見て、不覚にも涙が出そうになった。

その授業で使われていたマシンは半分がChromebookで、もう半分はWindows PCだった。落ち着いて考えると、Windowsも自分が開発に関わっていたので、同じくらいに興奮して良いはずなのだが、何故かそのときはそのことをまったく思い出さなかった。

プロダクトに対する愛情の違いかとも思ったが、おそらくそうではない。今でもWindowsのことを否定されると色をなして怒る。立ち上げに関わったかどうかで思い入れに違いが出たのだろう。

今は私はまったく関係ない部外者だ。オープンソースプロジェクトへの貢献も行えていない。しかし、あの10年前の夢が実現され、当時は考えもしなかった世界が広がっていることを知るのは自分ごとのように嬉しい。

おめでとう。

*1:主にブラウザ側。これまた私の古巣で、しかも私が担当していたIEが進化を止めていたのが原因だ

*2:MicrosoftでのWindows開発

*3:余談となるが、Googleに転職したときは、OSやブラウザなどはMicrosoftで、WebがGoogleとレイヤーが異なるプレイヤーであり続けると思っていた。辞めたとはいえ、Windowsには愛着はあったし、下世話な話だがMSFT株は持ち続けていたので、古巣のMicrosoftGoogleは競合せずにいてくれればと思っていた。しかし、実際には、OSにブラウザにIMEとすべて古巣でやっていたことを再度Googleでもやることになり、知人からはなんで古巣に牙むくようなことばかりやるのかと揶揄されたりもした

*4:今は違う。Androidアプリも動作する

*5:Eat your own dogfood

*6:最初の仕組みは私が在籍時にすでに提供されていた

東日本大震災から10年

10年前の今日、東日本大震災が起きた。このブログ記事ではこの10年を振り返る。

2011年

3月

3/11の震災当日。1ヶ月前に行われたデブサミでのベストスピーカー賞を受賞していたことを知るなど、忙しく仕事をしながらも、周りの同僚やチームメンバーなどと普通に会話をしていたときだった。

本社から出張に来ていたPMとW3Cのスタッフと小さい部屋でミーティングをしていたときに地震が起きた。当時は六本木ヒルズの26階。ビルが倒壊するのではないかと心配する本社からの出張者にこのビルが倒れるようだったら、東京は壊滅だよと、不安を解消しようと声をかけたが、そう言いながらも自分でも不安だった。

地震が治まっても気持ち悪くなる感じの揺れが続いた。外に出ていた同僚がオフィスに戻れないと言っている。しかし、六本木ヒルズは丈夫だった。しばらくするとエレベーターも動き始め、一緒にミーティングしていた2人はホテルと自宅へと帰っていった。

NHKYouTubeに流し始めた中学生のおかげでオフィスにいながらニュースを見ることができた*1。ビルから下を見ていても人が溢れているし、Twitterでもあちこちの路線が止まっていることや駅が入場制限していることがわかった。入場制限が緩和されたかと思うと、それを知った人が殺到するということが繰り返し起きているようだった。こりゃ、しばらく帰れないなと覚悟を決めて、オフィスで情報収集に務めた。幸い、食材をかき集めてくれたカフェテリアスタッフのおかげで夕飯にもありつけた。

Twitterで情報を見ていると、渋谷まで歩けば、その後は公共交通機関で自宅までたどり着きそうとわかったのが午前2時。いろんな人から情報を提供して頂きながら、無事早朝の4時半に帰宅。携帯電話もメールも届かなかったので、初めて家族の無事を確認。

twilog.org

twilog.org

当時の自分のTwitterを見ると、記憶が蘇る。ソーシャルメディアに感謝。震災は金曜日だったので、その翌日と翌々日は休み。休みではあったが、本社との連絡やチームメンバーの状況把握などを行っていた。

当時は、Google Latitudeという自分の位置を事前に承諾したユーザーにリアルタイムで共有するサービスがあった。これで自分のチームのメンバーの位置を把握した*2

Twitterで業務連絡をしていて笑う。

実は、この最初の週末、震災の翌々日に、Twitterには書いていなかったが、横浜の赤レンガ倉庫にライブを聴きに行った。さすがにキャンセルだろうと思っていたのだが、来日していたHolly Coleはライブを行ったのだ。行くかどうか激しく迷ったが、結局は行った。その時の様子はしばらくしてからブログに書いた。

takuyaoikawa.blogspot.com

その後はあまりに目まぐるしく時が流れた。

ご存知のように、福島第一原発事故が起きた。翌週の月曜日と火曜日はオフィスに出社していたが、仕事どころではなかった。水曜日は海外に修学旅行に出ていた娘が成田空港に帰ってきたのだが、東京に不安を覚えていた私は帰国した娘をそのままピックアップして、妻の実家の九州に行くことにした。Googleはどこから働いても良いと言ってくれていたので、九州を選んだ。娘はなにが起きたかわからなかったようで、なんで自分だけ友達とは別行動になるのか不満そうだった。

その時の成田空港の状況は今でも思い出す。空港は外国人でプチパニックになっていた。空港までは早朝だったこともあり、タクシーで行ったのだが、降りると同時に外国人家族が我々が乗ってきたタクシーで第2ターミナルまで行きたい。ドライバーに頼んでくれと言う。ドライバーに聞くと、このまま都内に戻るので、乗せられないと言う。外国人家族にシャトルバスがあると伝えるも、いっとき争うのか、必死な形相でお願いだと言う。ドライバーもしぶしぶと認めて乗せていった。

ターミナルビルに入ると、あちこちに外国人が座り込んでいる。こんな光景は初めて見た*3。まるでクーデターが起きた国から逃げ出す人々のようだった。

 

九州へ移動する前後から、開発者コミュニティで被災地支援ができないかを計画し始めた。Hack For Japanという名前になるコミュニティだ。このあたりのことは以下のブログに書かれている。

www.hack4.jp

takoratta.hatenablog.com

Long story short,
コミュニティとしての支援のために、ハッカソンを行おうということになったが、首都圏は計画停電でとてもリアルイベントは難しそうなので、オンラインイベントと西日本でのリアルイベントを組み合わせることになった。震災の1週間後に京都リサーチパークで最初のハッカソンを行った。

togetter.com

そういえば、3月の下旬には台北にも行っていた。落ち着かない東京は避けたいし、かといって他の場所では開発のためのマシンなども準備しにくい。ひらめいたのは台北のオフィス。台北のエンジニアリングマネージャーに「10人程度行けるスペースを用意できるか?」と聞いたら、どうにかすると言ってくれた。自分も含め、何名かが台北から仕事をした。東京、福岡、京都、大阪、台北20日程度の間にいろんな場所を回った。

この震災ではGoogleの底力を感じた。この会社の社員でいて本当に良かったと思ったし、誇りに思った。

4月

その後もミーティングで支援方法を考えたりしていたが、被災地を見ないことには、ニーズを把握できないと、4/6の夜に東京を出発し、東北自動車道で宮城へ。途中、東北方面から来る車は自衛隊車か救急車で、災害の最前線に向かっていることを否応なしに理解させられる。

4/7に仙台から石巻などを視察し、東京から持っていった支援物資を配った。仙台に戻り、自治体や地元企業のヒアリングなどをした後、夜は東北の開発者の方々と顔合わせするために仙台の居酒屋で食事をした。そのとき、東日本大震災後最大の余震が発生した。

takoratta.hatenablog.com

5月

その後も精力的にHack For Japanによる活動を続けた。記録はサイトのブログ記事で今でも見ることができる。ミーティングは毎週のようにやっていただろうか。議事録もブログで公開し、それどころかミーティングはustreamで配信していた。

もちろん、Hack For Japan活動はあくまでもボランティア(プロボノ)活動。本業は続けた。

ちょうどこの頃からNHKプロフェッショナル仕事の流儀の撮影が始まったのではないかと記憶している。なので、番組には、Hack For Japan活動も触れられている。

5月には福島にも拠点をということで、会津大学の知り合いがいた会津若松を訪れた。その後、福島のITコミュニティであるエフスタとも繋がった。

6月~

夏には、ITで日本を元気に!という活動の一環で、仙台から女川や石巻南三陸町などを回った。

12月は復興庁の企画だったと思うが、Hack For Japanなどとの協力で再度石巻に向かった。池袋を深夜に出て、翌日の夜にはまた東京に戻るという強行軍。現地でボランティアの方々などと繋がった。

石巻には、この年は4月と8月と12月の3回行った。その後も数年間は、毎年2回から3回は行くようになる。1年経って見ると、最初から更地のように見える土地も、最初は津波の爪痕がしっかり残っていたり、車がひっくり返っていたり、それこそ一時はテレビで何度も放映されたタンカーが道を塞いでいたり、ビルの上に車が乗っかっていたりしたのを自分は見ている。匂いを嗅いでいる。その意味で毎年なんども訪れたことは、まるで定点観測しているかのような感情になったのを覚えている。

12月には今のMaker Faireの前身となるMakt Tokyo Meetingが開かれた。会津若松のG Clueの佐々木さんはHack For Japanのスタッフでもあったが、彼らとガイガーカウンターで出展した。

2012年

Googleの同僚から相談に乗ってやって欲しいと言われて紹介されたのが、イトナブの古山さん。なんかちゃらい兄ちゃんだなと思ったが、しっかりしていた。人を見た目で判断してはいけない。

itnav.jp

震災から10年で1,000人のエンジニアを輩出するという。とても良い目標だと思った。この年からしばらく夏は石巻ハッカソンというのが自分の中で必須イベントとなった。

takoratta.hatenablog.com

この時に教えた高校生ももう立派なエンジニアになっている。もう技術ではまったくかなわない。

そういえば、Yahoo! JAPAN石巻に開いた石巻ベースにもお邪魔した。(いつものことだが)記憶をなくすまで飲み、気づいたらYahoo!のTシャツを着ていて、眼鏡が壊れていた。

toyokeizai.net

2013年

Hack For Japanの活動はアプリやWebサイトの開発から開始されたが、イトナブを始めとする被災地の若年層へのIT教育にも手を広げていた。その中でわかったのは、被災地への支援は「開発」という枠組みだけでは足りないこと。むしろそれ以外での支援が必要なこと。そこで、かねてから情報交換などをしていたiSPP (情報支援プロボノ・プラットフォーム) と協同して、ITで震災復興や防災・減災に取り組んでいる個人や団体を集めた会議を開くこととした。ここで情報交換したり、協業が進めばと考えた。

それがIT×災害会議だ。

www.ispp.jp

www.itxsaigai.org

このIT×災害会議は2013年に1回目を開催した後、2015年まで3回の開催をした*4

2014年

世界銀行主催でRace for Resilienceというイベントが行われることになり、石巻が会場の1つに選ばれ、そこで審査員をすることとなった*5

raceforresilience.org

当日は大雪。東京でも大雪だったそうだが、石巻も1日目の夜から積もり始めた。翌日は会場である石巻商業高校に行くまでが一苦労。雪かきもハッカソンの一環だと冗談を言うも、当日に東京に戻ることは不可能となり、開き直って、夜ははちゃけた。

南相馬の小高に移住した森山さんと知り合ったのものこのときだ。東京の会社を辞め、京都かどこかで街づくりにでも関わろうかというようなことを言っていたので、その直前に南相馬の街づくりに参加してくれる若者はいないかと言っていたのがリンクした。「森山さん、南相馬に行くと良いよ」と酔った勢いで言ったのが本当に実現した。

しかし、当然いろいろと苦労があり、その後も(背中を押した責任もあって)ずっと応援している。

fukushima-hook.jp

石巻から帰れなくなったことを笑い話にする間もなく、同様のことがまたしても起きる。Hack For Japanスタッフの佐々木さんのいる会津若松で町をハックするイベントをRace for Resilienceの翌週に開催したのだが、これまた悪天候に襲われたのだ。

前日に郡山入りし、郡山の友人(主に、エフスタの仲間だ)と懇親を深めた翌日、始発の磐越西線会津若松に向かう。ところが途中で大雪のため長時間停止。どうなることかと思ったが、いつのも倍くらいの時間かかって、どうにか私は会場に到着。

当日東京から参加する予定だった方々は郡山で足止め。急遽駅ビルのスタバかどこかからリモート参加。初日が終わりかけたころ、郡山にいる人たちを会津若松市役所の職員が車でピックアップしに行ってくれるという。正直迷った。この雪の勢いでは、来たら最後帰れなくなるのはわかっていた。しかし、私はすでにその状態。どうせ足止めになるなら、仲間が多い方が楽しい。彼らを迎えに行ってもらった。

2日目の翌日、ハッカソンは無事進行。最後、イベントが終わるとともに、東京帰還イベントがスタート。郡山に行くよりも、新潟に出たほうが分がありそうというのがわかり、新潟まで車で送ってもらうことに。新潟はまったく雪がなく、最終の新幹線で東京へ。途中遅れはあったものの無事都内には到着。私は作戦ミスで上野で降りてしまい、最終電車との接続に失敗してしまったが*6

 

togetter.com

www.hack4.jp

2015年

2015年は、IT DART (情報支援レスキュー隊) を発足させた。これはHack For Japanの経験やIT×災害会議での議論を踏まえて生まれた、発災後の情報支援を行うための団体だ。自分は発起人および発足当時の代表理事となった。

IT DARTはその後、2016年の熊本地震から支援活動を開始。災害支援団体への後方支援活動やIT機器の手配など、さまざまな形での支援を行っている。

itdart.org

この年はHack For Town in Aizuも再度開催。

hack4.jp

あと、この年は自分が南相馬行きを進めた森山さんの元を訪れた。秋だったと思う。この年に常磐道が再開し、それで向かった。しかし、うかつなことにカーナビの地図が更新されておらず、途中のICで降ろされてしまう。普通ではない町並みがすぐに広がる。通行止めの封鎖ゲートがあちこちにあり、警官も立っている。引き返せと言われるのだろうと思っていたら、いけいけと指示を出される。ここでUターンするのも不自然なので、そのまま進む。このようにして意図せず、6号線を北上することとなる。結果、福島第一原発のすぐ横を通ることとなった。

ゴーストタウンというのはこういう町を言うのだろう。道路はあり、町もあるものの、そこに生物反応は無い。窓を締め、エアコンを循環に変えて急ぐものの、途中立っている警官はマスクもしておらず、普通の制服だ。

やっとコンビニなど人の気配がするところまでたどり着いたが、正直、嫌な汗が出っぱなしだった。

南相馬で森山さんに案内してもらったが、彼らにとっては、私の6号線北上の経験は日常だった。あちこちにピンクのリボンをつけた棒がある。なにかと思ったら、除染がまだ済んでいない土地だった。あちこちに線量計があり、そこが危険であることを示している。

震災から4年経ち、石巻などの他の被災地は復旧から復興へと確実にフェーズが変わっていたが、ここだけは時間が止まっていた。津波の被害がそのままの場所も多くあった。

小高地区ではその後、2016年3月と2017年1月にハッカソンを行った。2018年2月にも開発合宿を行っている。いずれも現地の高校生に参加してもらい、次代に繋げる形としている。

2016年~

ここ数年はあまり活動ができていない。

Hack For Japanは開店休業状態。これで良いと思っている。また必要になったら必要な活動を再開すれば良い。

IT DARTは精力的に活動しているが、私は理事も退任し、今は運営委員として関わっている。本業が忙しいこともあって、裏方に徹している。

石巻にはしばらく行けていない。夏の風物詩となっていた石巻ハッカソンは日程が変更になってから、タイミングが合わず行けていなかったのだが、昨年こそはと思っていたものの、あいにくのCOVID-19。

会津若松も毎年1回以上は行っていた。会津若松愛が通じたのか、2年前からパソコン甲子園の審査員に選んでいただいた。しかし、これもまた昨年はCOVID-19によりリモート開催。

web-ext.u-aizu.ac.jp

当初は毎年何回か訪れていた石巻会津若松も行けていないのは残念だ。COVID-19が収まったら、是非とも訪れたい。

 

以上、10年の記録として、これでもほんの一部であるが、残しておきたい。

*1:やがて正式にネットで同時配信されるようになった

*2:会社からそのように指示があったため。リアルタイムの必要は無いので、許諾してくれた人だけ

*3:それから8年後の2019年に、LCCで北海道に向かおうとしていた自分が台風で直前キャンセルになり、帰宅困難者となって同じ経験をすることになるとはそのときは思わなかった

*4:震災10年目の今年にまたイベントを企画中

*5:メンターだったかもしれない

*6:東京まで行けば、接続されたものと思う

プロダクトと宗教の危険な関係

プロダクトは宗教である。

Emacsvim、各種プログラミング言語などの例でもわかるように、プロダクトは宗教だ。各宗教や宗派に属するものが自らの信じるものを他者に広める。

 昔話

筆者が20代を過ごしたDEC (Digital Equipment Corporation) という会社はVMSという自社OSが主力プロダクトだった。VAXというプロセッサーと合わせて、あらゆる規模のシステムにも同一アーキテクチャで展開できるその柔軟性や分散処理に優れている点などが支持され、一時はIBMに次ぐ世界2位のシェアを誇った。

しかし、やがてオープンスタンダードによるマルチベンダープロダクト間のインターオペラビリティが求められるようになる。標準化団体による標準化が進むも、実績にまさるUNIXTCP/IPデファクトとして普及する。

そのように時代が動き始めたとき、社内で起きていた議論が次のようなものだ。

VMS派「お客様がUNIXTCP/IPが欲しいと言っていても、お客様は何が本当に必要か理解していない。より技術的にも優れているVMSとDECnet*1をお勧めするべきだ」

UNIX派「それは、蕎麦が欲しいと言っているお客様にうどんを出すようなものだ(* DECもUNIX製品は持っていた)」

歴史はUNIXに味方した。UNIXは科学技術計算だけでなく、一般企業の業務システムのサーバーとしても使われるようになる。

この例は、VMSという宗教を信じる者がUNIXという宗教を信じている者に改宗を迫り、失敗したという話だ。

その後の歴史を見る限り、VMSは邪教と言われても仕方ないのかもしれない。だが、中にいたものとして、あれを邪教とは呼ばせたくない。たとえ、行き過ぎた勧誘(営業)活動があったとしても、そのときは本当に正しいことだと信じていた。信じるに足る理由があった。

しかし、世の中、本当に何が正しいかはわからない。宗教がそうであるように。

私ごとになるが、その後、筆者はWindowsに魅了される。最初はおもちゃと言われていたOSであったが、そこに未来を見た。1日に1度リブートをしなければいけないとなじられても、将来の可能性を信じた。

Windowsはその後、ミッションクリティカルなシステムにも使われるようになった*2

このWindows邪教だろうか。Windowsに対しては一族郎党皆殺しにされたかのように毛嫌う人がいまだに多くいることを考えると、Windowsさえなければと思っている人も少なくないのだろう。しかし、そのような人であっても、Windowsが社会に与えた影響を考えると完全には否定できないだろう。

 伝道と勧誘

自社技術を啓蒙する技術スタッフのことをエバンジェリストと呼ぶことを考えても、プロダクトは多分に宗教的である。

また、AARRR (Acquisition, Activation, Retention, Referal, Revenue) モデルにReferal=紹介があることからもわかるように、今日のプロダクトでは利用者によるバイラル効果を生み出すことがユーザー獲得の重要な手法だ。信者獲得と同じであろう。

このように、宗教が人類に必要とされるのと同じく、宗教と同じように人を引きつけるプロダクトは社会に不可欠だ。しかし、時として過激な教義を持つ宗教が社会問題化するように、プロダクトへの過剰な盲目的な信仰心は害をもたらすことがある。

 戦争ではなく

宗教との類似点は数多くあれど、プロダクトの場合は宗教が持つ負の側面を持たないようにすることができる。

宗教の中には、他宗教の存在を認めない教義を持つものがある。プロダクトで言うならば、他プロダクトを認めないということだ。競合を否定することで自らの優位性を訴えることだ。

しかし、プロダクトの目指すべきものは、競合を打ち負かすことではなく、結果的にそうなるにせよ、プロダクトを使うユーザーへの価値を最大化することだ。ユーザーの課題を解決することだ。攻撃の源泉である怒りは競合に向けるのではなく、ユーザー課題に向ける。これを守れれば宗教の持つ負の要素を排除することができる。

プロダクトづくりを行うものは、類似性を持つ宗教と同じ過ちを侵さない努力は必要だろう。

美味しいお店

以前、JR中央線沿線の小洒落た和食居酒屋に以前訪れたことがある。飲み物は何を飲むかと聞かれたので、焼酎が好きな筆者は焼酎をお願いした。すると、何を飲むかと聞いてきたにも関わらず、「任せてもらって良いですか」と店主は言ってきた。良くわからぬままお任せすると出てきたのは日本酒だった。食事もお任せしていたので、その後の料理に合わせてペアリングされた日本酒が最後まで続いた。

焼酎を好み、普段あまり日本酒を飲むことがなかった筆者であったが、美味しく頂け、その夜は大変満足した。日本酒も悪くないと思った。

所変わって墨田区。元は豚肉が売りだったので、店名もそれにちなんだものとなっているが、今は牛肉の焼肉屋。これが美味しい。豚を食べるつもりで入って、牛を食べさせられても、ここだったら大満足だろう。

この2例から考えるに、蕎麦を求める客にうどんを食べさせること自体が絶対に悪だということはないのかもしれない。ただし、客が満足するのならば。

筆者のいたDECはうどんを売ったことで失敗したのではない。そのうどんで客を満足させられなかったから失敗したのだ。

*1:DECのネットワーク体系

*2:Datacenter Editionが日本でも地銀やネット証券などに使われるようになった