製品開発と技術開発

技術中心設計から人間中心設計へ

従来の技術中心設計では、新技術が開発されたり、技術の性能が向上したりすると、それをもとにして新製品の開発を行うという傾向があった。その際、どのような技術をどのような方向に開発してゆけば良いかということは、技術者の直感にゆだねられていたといっていい。技術開発の会議などでは、会議の参加者が直感的に了解可能な方向性であれば、そしてそれなりに納得性の高い応用事例が示されれば、それでゴーサインが出された。ただし、その会議に出席しているのは基本的には技術者であり、技術者が考えたことを技術者が審査し評価するという形になっていた。いいかえれば、それを応用して作り出される製品が本当に利用者にとって有用なものになるのかということは考慮されていなかった。

こうした技術中心設計の動きが飽和状態に達したとき、人間中心設計の考え方が注目されるようになった。やはり利用者のニーズが重要なのだ、顧客が何を求めているかをまず考えることが重要なのだというその主張は、それなりの合意をもって受け入れられた。それは、同じdesignという言葉を使いながら、「設計」から「デザイン」へのイニシアチブの遷移であったともいえる（参考： ニーズ指向とシーズ指向）。

人間中心設計の考え方はISO 13407やISO 9241-210だけではない。IDEOの活動やスタンフォード大学のd-Schoolでも同様の考え方をまとめて方法論として提示している。こうした概念整備や手法の整備が進むにつれて、人間中心設計の普及に拍車がかかった。

分離している製品開発と技術開発

ところで、人間中心設計の活動を行う際、設計をまとめることに力点が置かれると、というか、それが自然なことではあるのだが、どうしてもすぐに利用可能な既存の技術を利用してプロトタイプなどをまとめあげることになってしまいがちである。その結果、それなりの製品のイメージが具体化できたとしても、そうした製品開発の活動は、技術開発とは別の場所で行われることになっていまう。

何が問題かというと、折角、人間中心設計でユーザ調査が行われていても、将来の人間中心設計で利用されるであろう技術開発は相変わらず技術者の思考の枠内でしか行われないことになってしまうという点である。製品開発と技術開発が分離したままでは、技術開発の担当者はいつまでたってもユーザや利用状況に関する適切な情報を得ることができないことになる。もちろん技術開発を行う部署にも企画担当部門が備わっていて、そこそこの市場動向を見据えながら技術の開発方向を見定めようとしているが、その企画担当部門で満足できるユーザ調査が行われているかどうか、という点が問題だ。

他方、製品開発の現場では、いま利用できない技術はあてにならないからと、現有の技術だけで製品を開発しようとする傾向がある。そして、将来の可能性については、いずれ技術が成熟してから検討するということでフェーズⅡに位置づける形で保留としてしまう。しかし、このフェーズⅡが後日、真剣に議論されることは少なく、結果的に顧みられることのない情報の山を作ってしまっていることが大半である。しかし、このフェーズⅡの情報が技術開発部門に環流されたなら、技術開発部署における企画担当部門が持っているものよりも精度が高く、より実際の生活や業務に近い情報を技術開発の担当者が手にすることができる。

製品開発と技術開発、2つの現場の交流を

そうしたフェーズⅡの情報を技術開発者に共有してもらうやり方としては、たとえばユーザ調査を行った結果を討議するブレインストーミングの場に技術開発の担当者を参加させ、共に議論をするのも良いだろう。プロトタイプを構成する場に参加してもらうのもいいだろう。そして、製品開発担当者が、ここはまだ技術がないからとあきらめようとした点について情報をかき集めるようにするのが良いだろう。

技術開発に関与している技術者や研究者は、どのような方向に向けて開発を行えば良いのかについて真剣に悩んでいる。決して、自分たちのアプローチが完璧だと思っているわけではない。しかし、その解決法について適切な手立てを持っているわけでもないのだ。製品開発と技術開発の間に双方向の情報の流れを作り出すことができれば、開発費を無駄に使ってしまうこともなく、有効で効率的な技術開発ができることになるだろう。