攻めの品質保証へ -1

今、新製品を企画して思うこと。の記事の中で以下のように書きました。

現時点では目的を達成できる最小限の仕様と構造を検討し、ユーザに要求するオペレーションもシンプルに目的が達成される使い方を提供すべき

今、新製品を企画して思うこと。

また別の記事では品質は開発の初期段階から積み重ねることもお話ししました。

品質が定義できないのはそもそも初期段階で目標が決まっていない、つまり製品が社会に与える価値が見えていないということ

品質とは定義されるべきもの

逆に、この2つを抑えると、過去に類似製品の開発経験がない(アップデートの形式ではない)製品の開発についても、アプローチしやすいハードウェア製品の開発プロセスが作れるのではないかなと思っています。

今回は、2019年9月現在弊社で開発している製品で対応している方法を踏まえてお話ししたいと思います。

・新規の開発はわからないことだらけでもお客様のことを考えて

今までに自社内のみならず社会的にも開発実績のない製品というのはわからないことだらけです。そもそも「 社会的にも開発実績のない製品 =社会に存在しない製品」ですから、それというのは作れないか、欲しい人がいないかのどちらかだと思うのが普通でしょう。

本当に新しい製品で市場があるかどうかわからないレベルの物であれば、企画上中心になる機能などでサンプル品や簡単な調査などを計画して、一部のユーザを対象に意見を募った程度の情報しかないこともあります。そのような状態だと中心機能以外はどうしたらいいかとか実際に購入したお客様はどんなところでどんな使い方をするかとかの情報はまだ入手できません。

ですので、昨日達成する最低限の仕様を設定します。その状態ではお客様が実際に製品を使うときに行う行為をできるだけコンパクトにしてわかりやすいようにします。それによってお客様がスムーズに使用状態にたどり着けます。今までにない製品であればお客様は使うのが初めてですから使い方がシンプルでないと対応できない可能性があります。また、説明書は必ずつけます。そこには使い方もそうですが、まず製品仕様上絶対にやってはいけないこと、やってほしくないことの記載が必要です。

ユーザは必ずメーカの想定外の使い方をします。想定外のことなのでどんな使い方をするのかは実際にそういう使い方をして起こった故障品を見たり、実際にクレームを受けてみないと分からないのですが、どういうときにどういう故障が起こる可能性があるのか、それによってお客様にどのような不利益があるのかは説明書に記載が必要です。

・開発を最短距離で実施する

試作品をできるだけ早く作り機能検証をすること、実際に量産用の部品形状を早めに確定し組立ての仕方や梱包の仕方を確認することがより早い段階で必要です。ここが遅くなるとリリースのための検証が遅くなります。

開発上のポイントは機能開発と製品開発を分けることです。機能が実現できるかどうかと、その機能が製品に実装できるかどうかは別の問題だからです。また、実装できるかどうかとそれを組み立てる工程が成立するかどうかも別なので、厳密に言うと工程設計も別に必要です。下の図のように、必要があれば工程設計の段階で生産技術開発も実施します。

矢印がそれぞれ途中から始まっているのには理由があります。できるだけ早く検討は始めたいものの、機能の開発がある程度進まないと製品に乗せられるかわからず、製品のイメージが固まらないとどう組み立てるかも検討できません。一方でそれぞれの仕事が終わってから次に進むのでは遅すぎますので、ある程度のタイミングまで前倒します(フロントローディング)。

この時、何機種か製品を開発していると、どのような状態になったら次の段階に進めるかがわかってきますので、次の段階に進む条件を定義します。そうすると自社にとっての開発プロセスが定義できます。

・評価は検討できる最小限でもいいからする

上記の使われる範囲の制限を設定すると、その周辺の使ってほしくない条件が出てきますので、それらの条件で評価用の試験を検討します。新規の試作品だと台数も作れず破壊ができないので、実施するのは後回しになると思います(試作品を壊してしまったら他の確認ができませんので)。

簡単な製品だとそんな評価なんてする必要ないと思われる方もいるかもしれませんが、全く評価が0の状態で試作を終了するというのは考えづらいです。使用環境や使用条件が考えられる以上、その条件での動作耐久試験など、何らかの方法はあるはずです。

そして何らかの評価は必ず実施しておくべきです。なぜなら、販売後に市場で不具合や品質事故が発生した場合に、試作品でどうなっていたかを後から確認することは不可能だからです。逆に試作品の時点で確認できている不具合が販売後にも発生しているのであれば、試作時の対策が不十分だったことが考えられますので、対策を打つべきポイントを見つけるのが早くなるなど、クレーム対応や在庫商品への対応が早くなります。

企業は製品と通じて社会とかかわります。ということは製品の品質のうち ユーザから見える部分とは、企業が社会に訴えかける主張の部分になります。そこで可能な限り不備なく、また余剰のない開発リソースを無駄にしないような開発プロセスの構築を目指すことを考えるべきなのだと思います。

品質とは定義されるべきもの

今、新製品を企画して思うこと。の中で以下のように書いた部分があります。

現時点では目的を達成できる最小限の仕様と構造を検討し、ユーザに要求するオペレーションもシンプルに目的が達成される使い方を提供すべき

今、新製品を企画して思うこと。

これは企画者が考えるべきことじゃないのか?と思われた方、正解です。そして、まだ企画段階だから品質保証の出る幕じゃないと思われた方、不正解です。

・企画を考えた段階から品質を考える

品質保証を実行できるようになろうとした場合、ここで「企画者が考えているから」で放っておいてはまずいことがあります。それはなぜかというと、企画者がそこで何を考えているか、そもそもマーケティングデータでどのようなデータを見ていて、なぜその考えが商品になるといいのかというポイントがそこにあるからです。

逆を言えば、その考えが商品に入ってないと商品をリリースする意味がないということになります。商品企画とは、その商品をリリースする意味の原点であり、それを元に要件定義や仕様が作られます。仕様になったものは図面化され、実際の品物になります。

つまり、最初に企画上の意図や意味だったものが、仕様により性能化され、図面上の管理ポイントに落とし込まれます。品質保証はこの段階を追っておく必要があります。もし仕様に不足があれば実際に図面になったり試作品を作った時にミスが発覚し、設計変更になります。

更に恐ろしいのは量産性を確認するための評価に移行し、試作品の台数を増やした時です。例えば、試作品の数台での評価では何も問題なかったはずが、量産性確認のために台数を増やしてみた途端、 性能を満たさない個体が多数発生してしまったとしましょう。検証の結果、量産工程の組立て時の工程能力では性能を達成する組立てができないとなってしまったらどうでしょう。その仕様は量産条件に合わなかったということになり、仕様設計までさかのぼる必要が出てきます。

こうなったらほぼ作り直しと同じことになり、予算が更にかかる上、発売時期が伸び開発中の製品で売り上げが立つタイミングが遅れます。開発で工数がかかりますのでその製品で利益を出すハードルは更に高くなります。実際に自社で製品を企画・開発・生産している完成品メーカなどの製造業はこのリスクに常にさらされます。

・そもそも論を歓迎する

もし開発が進捗してから問題が起こった場合、上に書いたように大幅なコスト増になることがあります。それを避けたいのは当然なので、詳細の原因究明をして、手戻りが最小になるようにするのですが、 本来は 最小にするための努力は初めから必要なところを明確にして確認を重ねていれば済むはずです。ただ、漏れがない仕事をすることが不可能なのも現実です。

また、ここで手戻りを少ないからということで、上に引用した「 目的を達成できる最小限の仕様と構造を検討 」し直そうという話になるかもしれません。この時よく起こるのは、手戻りを最小限にすることが目的にすり替わることです。そのために企画で決めた目標を下げるということが検討の選択肢に入ってくるかもしれません。

現実的な話にしてリリースを目指すのも方法の一つですが、ここで必ず確認しておかなければいけないのは「自分たちはそもそも何を作ろうとしていたのか」「変更後の目標で最初に企画した時の目的は達成可能なのか」を検討することです。リリースすることは大事ですが出して意味のない製品になるのならば、開発を中止した方が余計な予算を消化せずに済みます。

また、そもそも実はユーザの使用条件に対して 企画立案時や仕様検討時の内容に抜けや漏れがあったという可能性もあります。 開発が進むにつれてより具体的に製品の形が見えてくることで見えてくることもありますが、企画立案時の製品の概要や性能が使用シーンに合ってないのであれば企画の見直しが必要です。企画者が抜けもれなく仕事をしている保証はありません。また企画者には可能な限り具体的な使用シーンがイメージできている必要があります。

・初期から品質を定義する

組織として開発に際して注意することは適正なコストを投下して適切な結果を得ることです。その適切な結果とはユーザへの価値提供であって、製品のリリースではありません。品質が定義できないのはそもそも初期段階で目標が決まっていない、つまり製品が社会に与える価値が見えていないということなので、その開発自体を見直す必要が出てくるかもしれません。

品質はユーザに関連する部分以外にも多くあります。次機種の開発で使用する可能性のある機能や要素部品、生産工程の効率化に必要な要素などにも品質の定義が必要です。しかしこれらは製品の形が具体的になるにつれて検討の必要性が増してくるものでもあります。言い換えれば開発が進み具体的な話になればなるほど初期に決めた大きな要素の変更が困難になります。

開発開始時における品質とは、その製品を通じて達成すべき目的を定義することそのものです。

今、新製品を企画して思うこと。

実は弊社では2019年中のリリースを目指して現在映像関係の新製品を企画中です。詳細はまた別途コーポレートサイトとブランドサイトにてお知らせしたいと思いますが(こちらでも何らかのご連絡はしたいと思います)、改めて自分で試作(というか工作?)したり、製品企画したりしていると、製品化と事業化の難しさと同時に心の底から楽しさ沸き上がってくる感じがします。

・その製品は使っていて楽しいか

B to C製品だったら主に使うのは個人のお客様です。仮にお仕事で使うとしてもオペレーションするのはお一人でしょう。そんな時でも、私は使っていて楽しい製品が作りたいなぁと思います。使っていて楽しいとは、(1)その製品に触れているとき(2)その製品を使っていて得られる結果が楽しい のどちらかは最低欲しいと思います。

(1)の場合は製品の出来がよくて、触ったり操作したりが心地よかったり、見た目がカッコよかったりして見てると嬉しくなる、などがあると思います。他にも操作している中で、目的の昨日の面接の至るまでの操作が合理的で使いやすいなども、使用時のストレスの軽減のみならず使ったときの楽しさにつながるんじゃないかなと思います。

最近の製品でそれを実現できているのはやはりiPhoneでしょう。最近は賛否両論聞かれますが、それでもApple製品とその中でもiPhoneはOSまで含めてですが洗練された使い勝手という点で特徴があるように思います。ちなみに筆者はWindowsとAndroidユーザなので厳密には知らないんですが。笑

(2)はまさにこんなことができる、あんなことができるというような機能の部分です。その部分が製品の本質で買う理由でもあるのでとても重要なのですが、その中でもある程度機能のバリエーションがあったり、これは場合によっては機能の制約条件だったりもします。 製品によっては(1)と複合するものもあるでしょう。

例えば、初心者向けのカメラなどは「スポーツモード」や「夜景モード」など、これを使えばそのシーンが上手に撮れそうな名前がついている機能があります。あれはカメラの露出制御を、そのシーンを撮る時に使われる設定値以外は設定できないようにしています。これは(2)のアプローチで、初心者のユーザが困らないようにしているわけです。

・その製品は作っていて楽しいか

作り手にとって、製品を作ることは楽しいことです。ただ作り進めていく中で考えるべきこと、自社でできないことが必ず出てきます。実は今の私もそうです。正直その事実に行きあたると気分は重くなります。でもこの時、自社でできないから、やり方が見つからないからやらないとするのはやっぱりもったいないと思います。

何か一つでも成立する方法があればそれで一度実現させてみる、ユーザにとってもっといい方法があるかもしれないと思うかもしれません。もっとカッコいいものになるはずだと思うかもしれません。同時に作る方にももっとシンプルな物、性能を保証しやすい加工方法などを考えなければとプレッシャーを感じます。

もっと良くするべき、良くできるはずという気持ちはよく理解できますし、筆者もそうしたいと思う人間です。でもそこで一度立ち止まることも必要なように思います。特に今まであまり製品として存在しないニッチな物、新しい物であればあるほど、完璧主義に近いこだわりは機会損失かも知れません。まず新しい価値を早く製品を通じて体現し社会に問いかけることで、ユーザにその価値を届けることができます。

そのバージョンアップやモデルチェンジを前提にした構成や構造がもし検討できるなら、実はその方がいいかもしれないのです。最初の製品の開発初期の段階で考えることを止めていいということではありません。現時点では目的を達成できる最小限の仕様と構造を検討し、ユーザに要求するオペレーションもシンプルに目的が達成される使い方を提供すべきだと思っています。

筆者は品質保証の業務経験がある機械系エンジニアですが、品質保証の人間がこんな割り切ることを是とするようなことをいうイメージは日本の製造業の方には少ないかもしれません。でも私が本当に製品開発でおもしろいと思っているのは、企画が技術的に達成可能であるかどうか、それを自分が扱いきれるかどうか、ユーザに提供する形にパッケージできるかどうかの3つがバランスして「これしかない!」と思える形に収まる瞬間がものすごく好きだったりします。

実現しなければいけない価値を実現するのがエンジニアリングであるべきなのですが、それが必ずしも達成できない場合には次の落としどころを探らなければいけません。その次の落としどころを探る行為が上記の3つのバランスを取ることだと思うのです。

全ての製品開発には困難があり(新しいことをしているのですから当たり前です)、それを何らかの形でクリアしなければいけないならば、その困難を乗り越えるか、できないなら回り道を見つけるか、何かをしなければいけないのです。

その何かが見つかった時が自分にとっては至上の喜びであり楽しさです。

そんな風に、作り手にとっても使い手にとっても楽しめる製品を作り、作り手も達成感を感じ使い手も新しい道具を手に入れた喜びを感じられるビジネスがしたいなぁと思います。