この記事を読んで、思ったこと。
↓探検・渋谷駅 地下流通システム「フローベヤ」とは NHKニュース
http://www3.nhk.or.jp/news/html/20130315/k10013214741000.html
昔からある装置が建て替えなどでなくなることはよくある話で、それに対する郷愁みたいなものを感じるのはクルマに愛情を注いでいた私にとっても理解できるのですが、今回思ったのはそこではなく、この設備が作られてから５０年もの間、殆どノートラブルでその生涯を終えることができたという事実です。
これを実現できた理由として、個人的には次の要因があると考えています。
①システムの構造が非常にシンプルであったこと
②効率を追い求めすぎなかったこと
③ユーザーである人間の動きに非常に近かったこと
それぞれで内容を見ていきます。
①システムの構造が非常にシンプルであったこと
フローベアの仕組みはとても単純で、基本的にはおもちゃのスロットルレーシングのトラックのように、レール状に開けられた溝の下に、自由継手を持つフックをチェーン状に連結させて、それを途中途中にあるモーターで回して、搬入口から販売フロアまでの長い道のりを、縫うように、ときに坂道を上下しながら進ませています。
チェーンをモーター（というよりギア）で駆動させる仕組みなどは旧来からあり、この枯れたテクノロジーをうまく組み合わせて実現したからこそ、どこにトラブルが発生しやすいかが予想しやすく、定期メンテナンスの日にはチェックすべき場所や予防策として交換すべきパーツが何かもはっきりしていたはずです。
ノントラブルであったのはこういった予備的対策をとりやすいシンプルな構造であったことが大きく起因していたと思われます。
②効率を追い求め過ぎなかったこと
ビデオの中でも出てきますが、このフローベアの移動速度は何と「時速1km」。どう考えても速いスピードとはいえません。ものを移動させるという観点だけでいえばもっと速い速度で移動させたほうが効率的であったはずですが、それをしなかったのはなぜでしょうか？
確かに、「人も行き交う通路内を移動させるから」という理由はあるでしょうが、設計者が意図したかどうかは別にして、結果的にこの「遅さ」が、トラブルを低減させていたのは間違いない気がしています。
たとえば、人と同じかそれ以下の速度で移動させれば接触事故なども減らせますし、モーターのパワーも必要ありません。速度が遅く、パワーの少ないモーターで運用するということは、かごを運ぶフックにかかる負荷も少ないわけで、フックそのものの製品強度や耐久度も上げる必要はなく、かつ日々の磨耗度も下げることができます。
経路の途中で加速／原則させるなどの複雑な仕組みを作らず、常に一定の遅い速度で移動するという単純な仕組みだったからこそ、「遅いけど確実」にものを運べる堅牢なシステムであり続けることができたわけです。
③ユーザーである人間の動きに非常に近かったこと
これは、このシステムを作り上げようと思った最初の動機、つまりユーザーニーズと、それによって生まれたシステムが生み出す結果が、「それがなかった時と殆ど変わらなかった」ことを意味します。
フローベアは言ってみれば人が手で運んでいた行為をほぼ完全に代替するものであり人より素早く運ぶこともできなければ、決められた場所から外に出すこともできません。しかし、速度がおそく、ルートが決まっているからこそ安全に、かつ確実に運ぶことができ、かつコンテナ本体をほぼ加工なくそのまま移動させることが出来るため、積み替えなどの手間もなく、積載したものがなくなったり場所が変わってしまったりということも起こらないわけです。同様にコンテナ本体をレールから取り外す行為は、コンテナについているタイヤのストッパーを解除するのと殆ど同様の簡単な操作で行なうことができ、まるでそこまで人が運んできたのと同じように、シームレスにレールから取り外して売り場や搬入場所まで移動させることができたのです。
現場の人、いわゆるユーザーにとって、これまで人が運んでいたのと何ら変わりない操作でコンテナが自動的に運ばれてくるという仕組みは、驚きというよりもむしろこれで楽になった、という感謝の気持ちの方が強かったのではないでしょうか。
これをIT業界に転換して考えてみると・・・
５０年、不眠不休で動いても大トラブルが起きないシステム。これと同じものをITの現場で実現しようとするにはどうすればいいでしょうか？
ハードウェアの磨耗という点については避けられない現実なので仕方ないとしても、ソフトウェアの部分についてはいくらでも改善の余地があるはずです。
このフローベアから学んだ教訓を活かすとすれば、
・十分に「枯れた」技術を使う
・効率を求めすぎず伝送速度や実行時間が遅くとも確実な手法で実装する
・UIはこれまでユーザーが使っていたものを最適化しつつ、なるべく
変化のないように作る。
これが安定稼働しつつ、ユーザー満足度を下げないシステムということになります。
得てしてシステム開発をする場合、エンジニアや営業は「うちのシステムを導入するとXXX倍速度が早くなりますよ！」とか「データベースの導入で膨大なデータが扱えるようになりますよ！」とか「近代的なUIを導入することであたらしい操作感が体験できますよ」などと、高効率化、大規模化新しいユーザーエクスペリエンスなどを推したがりますが、こういったことが必ずしもユーザーに歓迎されるとは限りませんし、こんな売り込み文句で作られたシステムは、それを導入することで本当に現場の効率が良くなるとは限らないのです。
私の経験から言っても、製作側の人間が自分たちの得意分野に持ち込んでものづくりをしようとするあまり、ユーザーがそのシステムを導入した時に起こる「ギャップ」が無視されがちになるパターンが非常に多いです。
特にリアルな世界の動きをシミュレートするようなシステムを作成したい場合は、「現実の世界とどれだけ変わらないように作れるか？」が勝負になります。
逆に言えば、ユーザーの満足度はさほど高くないのが良いシステムということになります。システムを導入したのにこれまでと変わらず利用できることは、ユーザーにとってはなんの変化ももたらされなかったわけで、特に不満もなくかといって驚きもない。しかし見えない部分では徹底的に効率化されていたり、安全性が高まったり、データの再利用が可能だったりする。リアル世界にシステムを導入することの価値は、本当はこういった部分にこそ反映されるべきで、新しい技術や新しいインターフェースを使い、最新化されたことを自慢することが目的なシステムであってはいけないのです。
「作り手のエゴシステム」を生み出さないために
大企業はあの手この手でユーザーにシステム導入のメリットをプレゼンし、最終的にユーザーの決定（＝責任）でもってシステムを導入させますが、大抵の場合それがすぐ使えなくなってしまうことを知っています。
なぜなら、ユーザーが自ら立ち上がって作ろうとしたシステム以外は、その案件を新しい技術のパイロットに使用したり、また自分たちの得意分野の強化に使用したりすることが多く、ユーザー目線でものづくりをしないからです。
そして、すぐ使えなくなってしまうことを知っていながら、そのことを次のシステム導入を迫る手段として使うためにあえて長期的に安定稼働するシステムは作らないようにするのが常套手段です。なぜなら安定稼働してしまったら次のシステム開発をしてもらえなくなるし、保守に関しても修繕費用を出してもらえる確率が低くなってしまうからです。
要するに、安全、安心で安定的なシステムは「儲からない」のです。
しかし、我々IT技術者がお客様に対して提供するものは、技術者が最新技術を投入し、お客様も「いま流行りの○○を導入したんだ！」と感じるだけの、エゴイスティックな満足感であってはいけないと私は考えます。
派手ではない、変化もない。しかし投資しただけの価値は十分に発揮する。
金儲けが下手と言われてもいい。
人からチョーすごい！と言われなくてもいい。
自分の作ったシステムがなくなった時に、あれって実は凄かったんだね、と
あとで気づかれるような、そういうものづくりを私はしたいです。
