地方エンジニアが感じる地方・中小企業での悩み

辿りつくのは大きな力

»

 海外と日本の大きな違いの一つには、品質に対して求める度合いが違うというのがあると思います。海外では風土や組織の違いか最低限必要な機能を求めそれ以外については徐々に対応していくことが多いように感じますが、日本においては最初から異常なまでの高品質を求めているというところがあります。

 システム開発に携わる方ならわかると思いますが、日本においては「バグがない」が当然であり、「提供するすべての機能において問題があってはならない」というのを遵守させられることが多いです。新しい事を導入するにしても、それは絶対大丈夫なのか、と過剰なまでに安全性を求める人が多いのは事実ではないでしょうか。

 いかに IT システムであろうと、それを作るのも同じ人間なのですからどこかにミスやバグがあっても何ら不思議ではありません。しかし何故か、日本においてはそこに絶対性を求め、ありえない 100% という数字を求めてくるのです。

 Web を見ていると「もうかなりの間プログラムを直し続けているのにバグがなくならないのはおかしい」と、本気で考えている人もいるようで、このあたりに機械に対するある種の幻想があるのかな、とも感じられます。機械は確かにミスを起こしにくいですが、それでもその機械を作るのは人間ですので、完璧なように見えても完全にはなりえません。それが理解できているにも関わらず、いつになっても機械は完璧に動作すると二律背反的に思い込んでいるのです。

 人が行うことでミスが発生しやすい、だから IT を導入してミスを減らそう、というのが本来のあるべき姿なのですが、何故かここで、ミスを無くそう、という間違った考え方にたどり着いてしまうのは何故なのでしょうか。

 以前にコラムに書いた、ミスをダブルチェックなどで防ぐ思想に近いものがると思いますが、日本においては特に「ミスは起こしてはいけない」と考えがちです。起こさないための仕組みを、起こさないための対策を常に考え実行しているところも多いのではないでしょうか。

 その考え方には非常に問題があるのも、皆さんご承知の通りです。1% を 10% にあげることと、99.9 % を 99.99% にあげることでは、かかる手間も費用も時間も段違いに必要です。このあたりもあるので、私の中ではミスが発生することは許容すべき、という考え方を抱いています。ミスをなくすことは、ほぼほぼ不可能に近い事でありそこに労力を究極まで割くのはメリットがそれほどないのです。

 少し前に話題になったウォーターフォールとアジャイルの話も、根源は近いところにあるのかもしれません。ミスを許さない体質を求める日本人的思想には、手戻りを良しとしないウォーターフォール的方法論がものすごくフィットします。例えそれがうまくいくことが少ないとわかっていても、感性的にもフィットするウォーターフォールは日本人にうってつけなのです。そこには理屈は通じません。

 たとえアジャイル的方法論で上手くいく可能性があったとしても、このような風土で育った人間にその方法論はなかなか受け入れられるものではありません。日頃メリットやデメリットを考えている人たちですら、そうなのです。ここから抜け出すことができている僅かな人たちから見れば、これは非常に滑稽なことでしょう。このような状況からどうすれば抜け出せることはできるのでしょうか。

 色々考えてはみたのですが、どうしても極論的なところにたどり着いてしまいます。

 それは黒船のように、海外からの圧倒的なまでの勢力が上陸することです。最近ではポケモン GO がいい例で、国内企業が同じことをやろうとしても色々な理由で頓挫してしまいそうなものでも、海外からであれば何故かそれに従います。品質的には日本企業が作る方がきっと品質はよかったと思われますし、もっと多くの機能を備えた形でリリースできたかも知れません。
 しかし現実にはそこまでのものでなくとも、ユーザーは受け入れることが可能でした。日頃考えられている品質でなくとも、十分に利用してもらえるという実績がここに誕生したのです。

 むしろこれまでの思想でやり続けることが、いかにタイミングを逃していたか、いかにアピールポイントとして成り立っていなかったかを顧みる良い機会なのではないでしょうか。

 たかがゲームと思われるかもしれませんが、この衝撃は非常に大きな出来事です。ビジネスの世界においても、今回の事例から色々と学ぶことを怠ってほしくはないものです。圧倒的なまでの力の差こそが、今の私たちが状況を打破するためには必要なのではないでしょうか。そしてそれだけが、今後をよりよい方向へ導いてくれることを願ってやみません。

Comment(1)

コメント

山無駄

難しいのは、我々システム側がいくら100%品質の幻想と無益さを考えても、お客様がそう
考えるかは別のところにあります。
特にややこしいのは、お客様の中でも考え方は様々で、経営層は多少のバグがあっても安く
早くシステムを導入し効果を出したいと考えていても、担当は現場に文句を言われたくない、
自分たちが責められたくないという思いから、100%品質を求めてくことがあります。
システム側は、担当を窓口に作業を進めるため、それがどんなに無益であったとしても従わ
ざる得ない場面も多々あります。
ひどい場合は、契約上の納期は運開前に設定されますが、十分な確認をしたいからと検収期
間を一か月ほどとり、納期は運開前1ヶ月に設定されます。その納期に対して十分な試験を
したいからとスケジュールは現場試行1ヶ月、担当確認1ヶ月と設定され運開の3ヶ月前には
物をもってこいという事になり、その3ヶ月前の担当者確認時にリリースしたものが100%
の品質ではないため、確認できないと突き返されるようなことも。
品質を確保する作業はしんどい作業です。作って、試験して、改修して、また試験して。
その中で、新しいバグあり、デグレあり、延々と時間と労力をかけて品質をあげてゆきます。
それでいて、100%にはならない。いくら十分な試験をしても、運開後には必ず何かが起こ
ります。W/Fにしろ、アジャイルにしろアプローチは違うものの、100%にならない品質の
リスクを如何にヘッジするかを求めている事には変わらないと思います。
設計通りになっているかを段階段階で試験し、運開後の障害をなるべく回避するW/F。途中
段階のものをなるべく早くリリースし、致命的な障害を早目に片づけようとするアジャイル。
どちらのアプローチをとっても、100%の品質などありえないことはシステム側の人間は痛い
程知っています。
そんなしんどい作業を、お客様がやりたくない気持ちはよくわかります。開発先に押し付け
た方がどんなに楽か。しかし、それではとても100%と言わずとも十分な品質を確保するこ
とはできません。品質はお客様とシステム側が協力して作り込むしかないのですから。
そのことをお客様に知ってもらうことが、一番難しいことではないかと思う今日この頃です。

コメントを投稿する