誇りある仕事

PCデポのサポートサービスや抱合せ的な商法について批判が相次いでいる。

PCデポ 高額解除料問題 大炎上の経緯とその背景(ヨッピー) - 個人 - Yahoo!ニュース

このPCデポの件から思い出されたのが、以前、知人のスマートフォンの買い替えに付き合ったときの不快な体験だ。

予期はしていたものの、いろいろな余計なサービスを付加した形でしか契約ができず(実際にはできないわけではないが、その場合はディスカウントが効かずに高額の契約となる)、使いもしないものを付与せざるを得なかった。

この時は、かなり色をなして怒った。単にスマートフォンを買いたいだけなのに、なんで必要ないものを勝手に付けて、そして付けたほうが安価になるんだと。それはあなた(対応してくれている店員)の判断なのか、ショップの判断なのか、それともキャリアの判断なのかと。今考えると、そんなことをそこで色をなして怒っても仕方ないのだが、あまりにも頭にきたので、少し激昂してしまった。

いくら話しても埒が明かないので、いくつものサービスを付与したまま契約したのだが、わかったのは、それらは1ヶ月間(期間はサービスごとに違ったかもしれない)は無料で、その間に解約してくれれば料金はかからないこと。この点は解約料などが必要とされた今回のPCデポと異なる。

この時は無事に1ヶ月後にサービスを解約できたのだが、解約を忘れて契約を継続してしまうユーザーを期待しているのは明らかだ。なんといっても、店員が「1ヶ月後に解約して構いません」とはっきりと説明した。好意的に解釈すれば、1ヶ月のいわゆる試用期間中にそのサービスを気に入ったら、そのまま正式契約になるので使い続けて欲しいという狙いだとも思えるが、契約させられたいくつものサービスが本人に必要ないことがその内容から明らかだった。万人に向けて試用して欲しいというのを考えていたとは思いずらい。

長々と書いたが、このような不快な体験はすでに多くの人がしていることだろう。このようなことでしか利益をあげられない構造もどうにかして欲しいと思うが、もっと不幸だと感じるのは、そのサービスを企画し、設計し、開発し、運営している人たちだ。

抱き合わせ契約のために使われ、そしてほとんどの人に1ヶ月で使われもせずに解約されるサービスであっても、商品として企画され、設計され、開発されている。1ヶ月を超えて使い続ける人もいるので、運営に携わる人もいる。自分たちの作ったものが、単に契約内容を理解しないか、解約を忘れたことで使い続けさせるためのものだと知っているのだろうか。知ったとしたらショックだろうし、知っていながら仕事をしているとしたら、そこには誇りはまったくない。

ものづくり日本と言われるが、そこには作り手の誇りがある。自分の作ったもので解決したいもの、作り出したい新しい価値がある。

消費者を騙すような形で利用されることを主眼においたものに、誇りのかけらも無いし、もし、作り手の意図と反した提供のされ方をしているならば、それは作り手が自分の誇りにかけてでも、それをやめさせるべきであろう。

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

ソフトウェア開発、すなわち、アジャイル開発プロセスアーキテクチャ設計、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:ここには宅配業者にすでに確立されたノウハウもある

ベンダーロックイン排除のためにオープンという議論

自治体などの入札においてベンダーロックインを避けるため、特定のベンダーや技術に縛られないようにする。最近、このような方針を掲げる自治体や団体も出始めている。

これ自体は良い方針だが、ここで考えなければならないのが、何をもってオープンとするかである。

Web系であれば、利用者の多いLinuxのディストリビューションにApacheとMySQL、それにPHPやJavaのフレームワークを使うということになるのだろうか。ここのApacheはnginxでも良いし、MySQLはPostgreSQLでも良い。フレームワークもあくまでも例なので正直オープンであればなんでも構わない。

だが、この「なんでも構わない」の部分を明確にしておかないと、実際に調達を行う場合、入札仕様書(RFP: Request For Proposal)が書けないので、どっかでオープンの定義を明確にしないといけない。

その定義の難しさもさることながら、どこまでドグマチックにオープンを追求するべきかはさらに悩ましい。

例えば、IaaSを使うことを想定している場合、各クラウドベンダーが提供する独自サービスを一切使わないということは果たして現実的であろうか。そのクラウドベンダーがマイナーであるならともかく、AWSをAWSの良いところを用いないのは開発効率やコストの面でも本末転倒だろう。また、開発内容によっては、IaaSにこだわらないほうが良い場合もあろう。GAE(Google AppEngine)やMicrosoft Azureをベンダーロックインになるからと言って、選択肢から外すのが得策とは思えない。もっと言うと、オープンソースではないが、ここまで普及しているWindowsを排除するのもどうだろう。いたずらにオープンの追求にこだわるとピューリタニズムに陥りかねない。

ベンダーロックインを排除するという場合、結局はどこまで潔癖にオープンにこだわるかということと、そのベンダーや開発元のオープネスを信じられるかというところになるのであろう。

せっかく、自治体などでの入札においてオープンが意識されるようになったときに水を指すようであったら申し訳ないが、ベンダーロックイン排除という言葉がひとり歩きせず、意味ある形でオープンでサステイナブルなシステムの開発要件を考えられるようになることを願う。

年末に某システムの要件を見たときに、ちょっと行き過ぎではないかと思ったことからの雑感。

[更新:2015/01/05 8:06]Facebookにて、オープン性よりもポータビリティを主眼に置いた方が良いんじゃないかとかインターオペラビリティをどの層でやるのかが問題だろうというコメントをもらった。なるほど。

DEC Alphaの夢と現実と日本経済

かつてDEC(Digital Equipment Corporation)という会社があった*1

DECは1990年代前半まで世界第2位のコンピューターメーカーとして、ミニコンという小型コンピューターを武器にIBMを脅かそうとしていたが、さらに小型のワークステーションやパーソナルコンピューターに業務を任すダウンサイジングの波に乗りきれず、部門の切り売りをした挙句に、別の会社に買収された。

経営が傾き始めた1990年代後半、起死回生の一発とばかりに開発されたのが、Alphaプロセッサーだ。21世紀のコンピューティングを支える高速64ビットプロセッサーとして*2期待されたが、残念ながら、その後もDECの経営は改善しなかった。

当時のDECの技術者たちは、このAlphaに期待した。経営は悪化していたが、自分たちの技術に誇りを持っていた技術者たちは、もしかしたらこれで本当にDECは復活するかもしれないと夢見た。

しかし、Alphaを軸としたマルチOS戦略もAlphaのライセンスビジネスもすべて失敗した。後から知ったのだが、このAlphaの開発がDECにとって致命傷だった可能性もあるという。プロセッサーの開発には膨大なコストがかかる。工場への出費もバカにならない。世界トップレベルの技術を標榜する会社としては難しい決断だったかもしれないが、プロセッサーは他社からOEMで対応すべきではなかったか*3

さて、日本を取り巻く環境も厳しさが増している。少子高齢化に改善の兆しが見られない。

そんな中、2020年の東京オリンピック開催が決まった。オリンピックを契機に多くの社会問題を解決出来るのではないかと考えるむきもある。

だが、この東京オリンピックの開催への期待とDECのAlphaに対してDECの技術者が抱いた夢が重なって見えてしかたない。

今から振り返ると、DECが重視したハードウェアは早晩コモディティ化し、当時のライバルであったサン・マイクロシステムズもオラクルに買収され、DECを買収したコンパックコンピュータも今はもう無い*4DECはソフトウェアやサービスなど、従来とは異なる分野でのイノベーションを模索すべきであった。例えば、グーグル登場前に多くの支持を集めていた検索エンジンであるAltaVistaもDECが運営していたものだった。

箱物を中心とした投資は、オリンピック後の維持コストなどを考えた場合、それが日本経済にとって致命傷になる可能性もある。前回の東京オリンピックの時は首都高速道路や東海道新幹線などの箱物のインフラに投資し、それがその後の日本経済成長の礎となったが、今同じことをしたならば、資産ではなく負債になるだろう。竹下政権下のふるさと創生事業で作られた建造物が負債となっている地方自治体も多いが、それを国家レベルで繰り返す必要はない。次の東京オリンピックは、あれがターニングポイントだったと将来振り返った時に言われる歴史的なイベントになるかもしれない。どちらの意味でそう言われるかは今の我々にかかっている。

12月14日は総選挙。そうだ。選挙に行こう。

f:id:takoratta:20141207225038j:plain
(https://twitter.com/Eguchinn/status/540362229757906944)

*1:このブログでも何度か取り上げたこともあるが、私が新卒で入社した会社だ

*2:そのため、モデル番号も21064などとなっている。

*3:当時、プロセッサーはCISC型からRISC型への移行期にあり、DECも当初はMIPSテクノロジーのプロセッサーをOEMしていた

*4:ヒューレット・パッカードに買収された

買って応援

VAIO株式会社が始動した。

各種報道によると、まずは国内市場に専念し、2015年度で30万~35万台の販売を目指すと言う。これは2014年度の2分の1ほどの販売数だ*1。世界出荷分では600万台前後を昨年売っていたことを考えると、20分の1ほどの規模にまで縮小したこととなる。社員数も1,100人から240人に縮小。

PC市場自体が停滞すること、もはやコモディティとなってしまったPCを開発/生産する上でこの販売台数規模では効率の追求も難しいことを考えると、極めて厳しい門出となったと思うのだが、私の周辺では極めて好意的に受け止めている人が多い。

それだけSONYとVAIOを愛している人が多いのだ。

このブランド価値が生きているうちに、どのような製品を出せるかが勝負だろう。

かつてアキアというPCメーカーがあった*2。元DELLの日本法人社長であった飯塚氏が立ち上げたメーカーで、デザイン性に優れたPCをダイレクトマーケティングで販売していた。その先進的なデザインなどから一時は少なからぬファンを集めるに至ったが、現在はすでに存在していない。不吉な予想になってしまったとしたら大変申し訳無いのだが、どこかこのアキアのことが私の頭の中に思い浮かぶ。

当時よりも、さらにコモディティ化が進んだPC市場の中で生き残るのは並大抵のことではない。

VAIO株式会社の始動を喜ぶVAIOファンは、「食べて応援」ならぬ「買って応援」したほうが良い。お手並み拝見などと言っている余裕は無いのかもしれない。

私自身はVAIOを購入したことが無い*3のでそこまでの思い入れは無いし、今はWindows PCを買う予定は無いので、しばらく購入することは無い。

だが、そんな私でも思わず買いたくなるような製品を出してくれることを期待している。そのためにも、VAIOファンの方々は今買うべきだ。他人任せで本当に申し訳ない。

VAIOに1つお願いするならば、余計なプリインストールアプリは一切外したモデルを用意して欲しい。家電量販店などで触ってみるとわかるが、現在のPCには多くのアプリケーションがプリインストールされている。

中にはユーザーの利便性を考え、プリインストールされているものもある。アンチウィルスソフトやユーザーサポート用のツールなどはそうだろう。

だが、それ以外にも多くのアプリケーションがメーカーの収入源確保のためにプリインストールされている。インストールされた台数やアクティベーション回数に応じてアプリケーションベンダーから収入が得られるということもあって、多くのPCメーカーがこのビジネスモデルを採用している。

昨今の厳しいビジネス状況を考えるとしかたないと思いつつも、闇雲にプリインストールアプリを増やすことは激しくユーザー体験を悪化させ、商品価値を下げる。

少し前になるが、知人からPCの調子が悪いからと言われて見た某社のPCには、アンチウィルスソフトが複数インストールできるようになっていた*4

VAIOには是非、このようなところからこだわり、価格が高くても、さすがVAIOと言われるような製品を作って欲しい。

そのためには、まず、買って応援 ;-)

 

【追記】SONYロゴのないVAIO:“新生VAIO”で変わること、変わらないこと (1/2) - ITmedia PC USERによると、「ムダなものをそぎ落とし、(PCの)本質に近づくその過程で、人の心に突き刺さるVAIOらしい製品」を目指している模様。プリインストールアプリに関しても、「これまでプリインストールされていたソニー純正アプリの大部分が省かれた」とのこと。期待できるかもしれない。

 

*1:IDC調査では昨年度の国内販売は73.4万台

*2:今でも同名で再建された会社はあるが、液晶モニターのメーカーとなっている

*3:一度購入しようと思ったことはあるのだが、Sony Styleでの悪い体験があって購入を断念してしまった

*4:本来はプリインストールの契約でそれを禁止すべきだろう