社会システムや業務の改善にソフトウェア開発的思考を用いる

ソフトウェア開発、すなわち、アジャイル開発プロセスアーキテクチャ設計、UXデザインなど、における発想をソフトウェア開発以外に用いても役立つことは多い。

少し前になるが、ある事業の相談を受けたことがある。ここではそれを架空のコンビニ事業に置き換えて説明しよう。架空なので、現実的ではない部分も多いが容赦願いたい。

コンビニ各社は店舗で買い物するのが出来なかったり、店舗を訪れるのが面倒に感じる顧客のためのデリバリーサービスを持っている。このデリバリーは実際はいわゆる通販であり、宅配ピザのように短時間で配達されるものではない。だが、ここでは例として、コンビニがある特定の商品に限っては極めて短時間で配達するというサービスを展開していると仮定する。また、(出来るだけソフトウェアとは遠い処理の例にするため)注文はコールセンターで電話で受けるものとする。

この短時間での配達を約束している特定商品を「アルコール飲料A」とし、配達サービスエリア内であれば5分で配達することをコミットしているとする。5分でなくても、3分でも10分でも良いのだが、普通に考えると実現が難しいような時間を想像して欲しい。

おそらく普通のオペレーションはこうだ。

  1. 顧客がコールセンターに電話をかける。
  2. コールセンターのオペレーターが電話を受ける。ここから5分以内に配達を完了させるというタイマーがスタート。
  3. オペレーターはコンビニデリバリーのコールセンターであることを伝え、顧客の住所や氏名を確認する。
  4. オペレーターは顧客からの注文を受ける。
  5. オペレーターは顧客に注文を再確認する。
  6. オペレーターは顧客との電話を終了し、注文をシステムに入力する。
  7. 注文に「アルコール飲料A」が含まれていた場合は、その商品だけを別便で至急届けるように、店舗または配達員に通達する。
  8. 配達員により顧客宅へ配達される。

わざと少し冗長にしたが、まったく最適化をしていない場合はこのようなオペレーションになっていてもおかしくない。

このコールセンターと顧客との対話やコールセンターからシステムへの入力、さらにはシステムから配達員に連絡され、配達が完了するまでの流れは、ウェブシステムにおけるブラウザとサーバー、そしてバックエンドからDBにデータがエントリーされ、処理が完了するまでと極めて類似性が高い。

処理速度が最優先されるシステムであれば、多少のコストは許容される。となると、少なくとも次のような最適化は考えられる。

オペレーターは顧客の住所を確認するのと同時に、「アルコール飲料A」が含まれているかどうかを確認する。ここで、もし含まれていた場合には、それをシステムに入力し、その地域の配達員に短時間配達のリクエストが入ったことを伝える。配達員はその商品の手配と顧客宅までの最短ルート確認、場合によっては実際に移動を始められる。その後に、オペレーターは氏名や他の注文を確認すれば良い*1。もしかしたら、その後の顧客とオペレーターとの対話で注文が取り消されるかもしれないが、処理速度を最優先する場合にはこのくらいの無駄は許容する*2

この高速化技法はブラウザのプリフェッチの処理と同じだ。見ているウェブページにURIが埋め込まれていたら、それらをバックグラウンドでDNSプリフェッチ*3し、ユーザーがクリックする前に名前解決は済ませておく。Chromeでは検索結果からの表示の場合にはバックグラウンドでレンダリングまで済ませておくこともある*4。もしユーザーがそれをクリックしなかったならば無題になる処理であるが、高速化がそのコストよりも優先される場合にはこのような選択がされるのだ。

配達がどのように行われるかは、在庫をどこに置くかと、配達員がどのように配置されているかに関係する。簡略化のために、配送センター → 店舗 → 配送車または配送バイクという流れで商品は流れていくものとする。配送車が担当エリアを常に回遊し、必要な在庫を常に積んでいることがもっとも速く配達を完了することに繋がるが、この設計はキャッシュヒット率を高め、ディスクのシーク時間を短くすることと同じだ。配送車の配置と店舗により在庫を補充するタイミングが鍵となるだろう*5

このような最適化は机上でシミュレーションすることも可能だ。その結果を見て、さらに最適化の余地が無いかを考えると良い。実際、GoogleChrome OS/Chromebookを発表した際に、蓋を開けてから10秒でインターネットにアクセスできるようにすることを宣言したが、そのためにはファームウェアからChromeの起動プロセスに至るまで多くのところでマイクロ秒の最適化を積み上げて、その10秒を実現した。

社会システムや業務においてもこのようにソフトウェア開発的思考が活かされることは多い。ソフトウェア開発経験のある人は、開発以外の身の回りのオペレーションもソフトウェア開発的視点で見直してみよう。もっと最適化できるところもあるだろう。

*1:間に合えば、他の商品の配送も配達員に伝えれば良いし、そうでなかったら別便とする

*2:投機的実行

*3:DNS プリフェッチの制御 | MDN

*4:インスタントページ - Google Japan Blog: 検索をもっと便利に、もっと速く

*5:ここには宅配業者にすでに確立されたノウハウもある

エクスビジョンに遊びに行ってきた

今日はマイクロソフト時代の上司である加治佐さんにお会いしてきた。現在はエクスビジョンの取締役をされている。

無職になったので遊びに行って良いですか*1との依頼を快く聞いていただいた。

まずはオフィス見学。普通のマンションの部屋と言ってもおかしくないような部屋を2つ借りている。とてもハングリー感あふれていて、気持ち良い。近いうちに引っ越して1つにまとまるとおっしゃっていた。

f:id:takoratta:20151109130435j:plain

f:id:takoratta:20151109133141j:plain

エクスビジョンの代表取締役マイクロソフトディベロップメントの代表取締役をされていた藤井さんだということは事前に知っていたが、他にもマイクロソフト時代に見た顔や元同僚が何名かいた。日本のマイクロソフト出身者でスタートアップに行く人は少ないかなと思っていたが、最近はそうでもないようだ。良いことだ。

さて、このエクスビジョンは東京大学石川渡辺研究室で開発された超高速ビジョン技術を応用した製品を開発している。ジェスチャーシステムをデモして頂いたが、Kinectなどでは不可能な高分解能により両手でのツーフィンガーUIを実現していた。


Reflex Development

このデモ動画でもわかるように、右手と左手がそれぞれ2つの指となる。まず、顔が認識され、その状態で手を顔の横に挙げることで、手も認識される。手を閉じる(軽くつまむような)動作でタップに相当するイベントが発生する。手の移動はそのまま指の移動となり、スマートフォンではスワイプに相当する動作となる。

 

f:id:takoratta:20151109132939j:plain

現在のシステムはCMOSカメラですべて処理しているため、Windowsスマートフォンなどに接続した場合はただのHID(Human Interface Device)となり、ホスト側の負荷はまったく無い。また、手での動作はツーフィンガーとしての動作に置き換えられるので、アプリケーションなどに手直しは必要ない。また、100〜120fpsという高分解能を実現しているため、細かな動作も認識される。

デモでは、Windows 10とAndroid*2での操作を見せて頂いた。自分でも試させてもらったが、少しコツがいるものの、操作は極めて直感的だ。緊張してしまったため、空中で手を動かすのに疲れてしまったが、慣れると多少長時間でも特に問題ないとのこと。

今年のゲームショーにも出展されていたようで、その時の記事がいくつかサイトからリンクされていた(以下参照)。確かにゲーム分野での利用はすぐに思いつく。後は、サイネージか。

cyclestyle.net

game.watch.impress.co.jp

www.4gamer.net

SXSWにも出展していたようで、その時の様子のビデオを見せてもらったが、米国人の子どもたちにも評判は良かったようだ。

この超高速ビジョン技術をさらに進めると、人間の目では判断できないような素早い動きも認識できるようになり、工場や社会システムなどでの応用も可能だろう。期待したい。

*1:無職になったことと、オフィスに遊びに行くことに因果関係は無い

*2:デモではWindows上でのエミュレーション

スタートアップの脅威の一つは感染症

最近、東京をベースにしたスタートアップのオフィスに遊びに行くことが増えている。

会社によっては、広々としたオフィスにゆったりと席を配置しているところが無くも無いが、多くは人口密度が極めて高い。財政的なゆとりがない(あっても、オフィススペースに資金を回さない)かオフィススペースの拡張が人員増加のスピードに追いつかないのだろう。

このような環境だと、一番怖いのはインフルエンザとかの感染症だよね、と一緒に訪れた友人と話した。確かに少数精鋭で事業を進めるスタートアップにとっては、人材が一番の重要だ。数人の社員がしばらく稼働できないだけでも大変な事態になりかねない。

感染症が怖いのはスタートアップに限らないが、スタートアップで特に心配なのは、人口密度が高いところが多いのと、業務に対するモチベーションが高いのが逆効果となり無理に出社してしまうことが多そうだからだ。

インフルエンザやノロ、O157などの感染症の初期症状を社員全員に理解させ、少しでも疑われる場合には自宅待機。リモートワークを認めておくことがここでも役に立つだろう。罹患していた場合には医者から出社して良いとの許可が出るまでは出社を許さないくらいの強いルールが必要だろう。

何よりも、自分1人の感染が、無理な出社によって会社全体に広がる可能性があることを徹底する必要がある。

そのあなたの行為はバイオテロだから。

これを標語にしても良いくらい。

寒くなってきました。インフルエンザの予防接種はもう済ませましたか?

 


参考:感染症だけでなく、社員の健康管理が企業の経営の根幹にもなってきているようです。

zuuonline.com

 

Twitterの★が♥に

f:id:takoratta:20151105100356p:plain

 

Twitterの★が♥に変わった。「お気に入り」という機能が「いいね」に変更されたわけだ。

すでに巷ではいろいろと騒がれているので、何か書くには出遅れ感があるが、少し思うところを書いておきたい。

私は以前、以下のようなブログ記事を書いていた。

takoratta.hatenablog.com

これは「お気に入り」という曖昧な名前と機能について考察した記事だった。当時は、ツイートを(ブックマーク的に)記録するという用途のために「お気に入り」捉えており、永続的か一時的かという記録期間で使い分けがまだ定まっていないと書いていた。

それからしばらくして、今回、公式にこの機能は「いいね」であると決められ、名称もアイコンも変更されたわけだ。私の考察とは異なり、単なる感情を表す機能と再定義された。正直、「お気に入り」という名前はブラウザのそれを想起させ、ブックマークとして利用していた人も多かったのではないかと思う。

提供側の意図はわかるが、この変更は結構悩ましい。

一度、曖昧な形で提供し、利用者にその意味合いや使い方を委ねていたものを、今になって用途を明確にしても、それは支持されるだろうか。関連サービスなどもあったろう。

支持されるも何も変更されたので、感情を表現する機能として使われていくようになるのだろうが、一度提供した機能を再定義することの難しさと是非を考えさせられる。

さよなら、インタフェース

f:id:takoratta:20150916154323j:plain

 

インタフェース*1を考える前に、本当にそれが必要なのかを考えるべきだということを、Golden Krishnaのブログを紹介する形で3年ほど前に書いた。

takoratta.hatenablog.com

その後も勉強会のライトニングトーク(LT)でこの考えを面白おかしく紹介させて頂いたりした。

www.slideshare.net

そのオリジナルのGolden Krishnaの考えが本になった。「さよなら、インタフェース -脱「画面」の思考法」というタイトルだ。 

さよなら、インタフェース -脱「画面」の思考法

さよなら、インタフェース -脱「画面」の思考法

  • 作者: ゴールデン・クリシュナ,武舎るみ,武舎広幸
  • 出版社/メーカー: ビー・エヌ・エヌ新社
  • 発売日: 2015/09/17
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る
 

内容は以前のブログ記事で紹介したものとほぼ同じだが、さらに多くの事例が示される。例えば、私は歩きスマホが大嫌いなのだが、 「第9章 スマホはケツポケットにしまっとけ」には激しく同意した。

また、原書の英語は少し癖があるのだが、日本語訳が秀逸だ。原語のテイストを活かしながらも、大変読みやすい日本語になっている。最初は少しびっくりするかもしれないが、この文章も著者なりのインタフェースなのだろう。是非味わって欲しい。

参考になると思うので、目次を下に示す。日本語版への序文は僭越ながら、私が書かせて頂いた。

目次 

日本語版への序文 及川卓也
推薦のことば エリス・ハンバーガー

●本書の概要
第1章 はじめに
第2章「まず画面」の思考法

●実情と問題
第3章 インタフェースをくっつけろ!
第4章 UX ≠ UI
第5章 中毒というUX
第6章 注意散漫
第7章 バックライトの光で不眠に?!
第8章 スクリーンレス・オフィス

●NoUIを実現するためのルール その1
(画面なんかに頼らず、解決したい問題につきものの「いつもの手順」をしっかり理解しよう)
第9章 スマホはケツポケットにしまっとけ
第10章 怠け者の長方形

●NoUIを実現するためのルール その2
(科学技術を活用し、ぼくらをこき使うシステムじゃなく、ぼくらに使いこなされるシステムを創り出そう)
第11章 コンピュータはまるで駄々っ子
第12章「ユーザーインプット」じゃなく「マシーンインプット」を
第13章 アナログ仕事とデジタル仕事

●NoUIを実現するためのルール その3
(ひとりひとりに合わせる)
第14章 ひとりひとりに焦点を当てた情報処理
第15章 事前対処型コンピューティング

●今後の課題
第16章 変化
第17章 プライバシーの問題
第18章 自動化
第19章 不具合
第20章 例外

●むすび
第21章 こんな日が来るといい

後注
索引
訳者あとがき

*1:3年前はインターフェイスと書いたが、ここでは書籍に合わせてインタフェースとする。