DTP効率化のためのシステムとは？（草稿）

最近、自分で文字を書いていて、ふと思った。
「自動組版」と「自動作成」って違うよなと。

どっちかというと、完全に印刷用データ（今ならPDF）を作ってしまうのを「自動作成」、DTPアプリに依存度を残すことができるものを「自動組版」と言った方がいいんじゃないかな。
ま、自分のことなので、どうでも良いかもしれないですが。

えー、本題。まだ草稿です。ご意見いただきたいな。
毎回言いますが、ヤワな生き物なので、優しくお願いします。

「はじめに」
DTPの効率化を、「コスト削減」という入り口から入ってきた場合、要は、かかる時間を削減する、ということなので、じゃあ、組版するところを、自動でやればいいじゃん！なんてところがゴールだと考える。入稿（In）も出稿（Out）もパターンが一定ならOKです。言われれば100％完全自動「作成」システム作ります。入力してボタン押したら、PDFが数秒で出てくるの作れます。でも、今までかかってる「コスト」ってそこじゃない。そんなところなら、みんなが真剣に考えて、統一してしまえば終わりです。
※InOut理論はTyamaリスペクトです。

「つまり要求はない、ってことになる。」
でも、みんなが望んでいることは、そうじゃないのが現実。
入稿もいろいろ、出稿もいろいろ。InもOutもバラバラということです。
つまり、Inするものがバラバラである限り、Outもバラバラです。
「コスト」がどこにかかっているかというと、この「バラバラ」部分です。
この部分を、解決することを考えなければ、「コスト」はいつまでたっても削減できません。
そしてもうひとつの重大な過失「使い回しができない、つぶしの効かない（将来性のないという意味で）データにしかならない」ことです。
そうそう、こういうシステム構築で、要件定義をまともにやろうと思うのは、そもそも間違いです。システム開発の世界で、要件がその時点の要求でしかないことで、意味がないことであることもさることながら、どんなものをInするか、どんなものをOutするかさえ、使ってみないと決まらないということだからです。ここを追求すると、ガチガチなシステム構築か、全部手動か、というゴールにしかたどり着きません。

「InとOutを統一しなきゃコスト削減のための自動化って無理ってこと？」
んー、そうなんだけどちょっと違う。
DTPの効率化は、基盤となる環境の整備、作業ルールの整備、技術の整備を確立して、実行できれば必ず実現できる。
そこを補完するのがシステムなんじゃないかなと。
ここでいうシステムってのは仕組みであって、大仰な物ではない。
普段使っているテキストエディタだって、十分な力を持っている。
ただ、それが、自分のものだけになっていては意味がない。
入稿、出稿、校正、印刷などをスムーズに流すには、使い方が統一されていなければならない。

「でも、人がカムと事故が起きる…」
そう思うなら、システム化する。ただし、人を排除するということは、人の感覚による命令ってできなくなる。例えば、「したい（希望）」というニュアンスは無理。「する（命令）」でなければならない。「する」と言った時点で、他は排除されるということになる。（この中に分岐を書くのはアリだが）ここを「割り切れます」というハンコが無い限り、システム化は失敗する。

「じゃあやっぱり制約がありすぎて、使えない」
キタ！これがこの業界で必要な仕組みなのに導入されない理由。
かみ砕いて言うと、「いろんな物を投げるから、ちゃんと組版してね」ということです。
どうどう巡り開始です。コスト削減とかデータベース化とかしたいのに、したくない、と言っていることになります。

「DTPの効率化でコスト削減できないのは、システム化以前の問題」
コスト削減命令によるDTP効率化のためのシステム化は、前述から無理なこと、ということが分かるでしょうか。要は、したいのに、したくない、っていってる事になるということです。
で、その解決がどこに落ち着くかというと、ま、オペレータが頑張ればいいんじゃね？ですか。

「困るのは誰？」
そんな「適当さ」が目立つ業界ですが、そもそも不景気なんて言うとる前に、そこをちゃんと解決することが、今後に繋がるんじゃないですか。価格競争は、資本主義社会として仕方ないかもしれないけど、その制作作業、現場の問題・課題を置き去りにして、価格を下げたところで、モノがなければ印刷できないのでは？あぁ、海外でやりますか。勝手にやってくれ。物作りにおける重要なポイントを放棄するなら、ホントにこの業界終わりです。いか〜ん、盛り上がってきた。落ち着こう。この話になるといつもムキになる。分かるんですよ、僕も現場だから。そう簡単にはいかんぜよと。でも、そこをハナッから「できん！」じゃなくて、解決を導くために「やってみる！」と、敢えて挑戦すべきじゃないでしょうか。多分そう思う人の考えは正しいのです。でも正しい道を阻む何かが潜んでいるんです。それは人を殺してしまうような宇宙から来た未確認生物なのでしょうか？せいぜいビフィズス菌でやっつけられる悪玉菌じゃないかと。（結構手強いか）
うんまあいいや。そう。つまり困るのは自分だゼ、ということです。

「DTPからクリエイティブ的な要素は外せない」
ここでいうクリエイティブは、モノを作るときの基本である「センス」という要素が大きい。
モノを作るには、「センス」が必要です。
そして、そのセンスは、レイアウト、デザインのセンスもさることながら、めんどくさいことをしたくない、と思えるかどうか、そのポイントを発掘してアピールして解決できるかどうかのセンスだと思う。
システム開発で言われている「Don't Repeat Yourself!(DRY)」と同じ。
だから、システム開発だって、クリエイティブだと思う。プログラマはエンターテイナーであるべきだ。これは長くなるのでまた今度にします。
クリエイティブとコスト削減は、相反しているようで、実は、クリエイティブの先にコスト削減がある、とも言える。そして、コスト削減の先に、クリエイティブはない。

「コスト削減という入り口がウマくない」
つまり、DTPの効率化を考えたときの最初の入り口が「コスト削減」というのがよくないということだ。「めんどくせぇ」を時にはエレガントに、エンターテイメントに、クリエイティブにこなした先に、コスト削減がある。ここでそうじゃないと思ったら、もう一回上述を読んで欲しいです。つまり、DTPにまつわる仕組み作りで、クリエイティブさを外したら、何も成り立たんということです。「効率化」は、「コスト削減」のためのものではなく、「DRY」になるためのもんだと思うわけです。ここで目指すクリエイティブさは、無駄なく結果を出せる技術ということです。じゃなきゃずっとイラッとしっぱなしです。

「でも解決しなきゃいけない、解決してやるゼ、という気合いはどこに持って行けば。。。」
作業している人で、真剣にやっている人であれば、こんなくだらんことを何度もやりたくない、と思ってる人だけが、この行にたどり着いてるんじゃないかと。勝手に想像しつつ。。。
すでに世の中には、数多くのソフトウェアやシステムが販売されていますが、「お、なんだか、これでできそうだ！」と思ったとしても、実際上手く使えなかったりします。
ここまで言って、そんな都合のよい仕組みはないので、手作業でお願いします、というと殺されそうなので、下記あくまで指針です。
では、何を解決できるシステムならいいのか。。。
前述の「いろんな物を投げるから、ちゃんと組版してね」という要求に応えられるシステムが必要ということですね。

「システムに頼りたい部分をちょっとまとめてみる」
・登録した人は誰なのか？
・登録した日はいつなのか？
・更新出来る人、した人はだれなのか？
・削除出来る人、した人はだれなのか？
・ステータスによって状態を変えたい。例えばロックするとか。
・データの閲覧・編集に人の制限をつけたい。
・テンプレートを共有したい。
・WEB（ブラウザ）から入稿させたい。
・入稿されたものは、指定されたテンプレートでPDFを自動作成したい。
　または、入稿されたデータをダウンロードしたい。（CSV,XMLとかTextとか）
・入稿フォームを登録、編集したい。
・テンプレートを登録、編集したい。
・画像をアップロードしたい。
・データを検索したい。
・過去のデータを複製して使いたい。
これ以外あるのかな？

「ちょっと欲張りになってみる。」
・アップロードされた画像を管理したい。
・権限や制限を編集したい。
・校正紙を出したい。
・データをページに配置してページアップしたい。
・別マスタデータを用意して関連付けたい。（企業マスタから住所を抜くとか）

「そして人はもっと欲張りになる。」
・テンプレートを簡単に作成したい。
・入稿フォームを簡単に作成したい。
・画像のトリミングをしたい。
・入力する文字に字数制限をつけたい。
・WEBサイトのコンテンツと連携したい。

「このへんで思うこと」
あれ？こんだけだっけ？まだある気がするが。。。
上記がすべて網羅されたら満足、解決できるのか？
そうじゃない気がしませんか？
要は、本当の満足、解決というのは、システム化によって、「いろんな物を投げるから、ちゃんと組版してね」という「、」の間に、「いろんな物を投げるから、あとは設定されているシステムのルールにのっとって、ちゃんと組版してね」の「システムの設定部分」だと思う。ここを思うように設定できればよいということだ。しかも、制約なしに。だから柔軟な仕組みが必要だということで、そして、その仕組みは、変わり続ける要求に対応していけるものである必要がある、ということです。

「ということでPA^nが出来たと」
WPSは今もお客さんから絶大なる人気を誇ってますが、なぜ使い続けられているかということを考えると、ユーザもうちもモノを作ると言う点において、真剣だということです。最初からコスト削減しか頭に無いなら、モノを作らなければ良いと思う。その方がよっぽどエコだ。
でも、WPSは、いわゆる決め打ちシステム。変更は加えられるとしても、こちらの手がいる。それは完全に、安全に出版されないといけないからです。とは言っても、これには、お互いにストレスが溜まる。変更するには、人の手がいる。そこにはコストが発生する。これは仕方ないことです。うちも「ぐへへ」ってよだれを垂らして待ってるわけではないのです。そこを排除しようとしたのが、「PA^n」。これは、仕組みを準備するので、後は使う人で決めて作ってというもの。
勘違いしてはいけないのは、「WPS」で、こちらが決めた仕様を、自分たちで作れるということだが、その裏には、自分たちでルールを確立しなければいけない、ということです。そのリスクを背負えるところには、オススメします。
決して「あんまりうるさいから勝手にやってや」ではないです。クリエイティブさを必要とするDTPのシステムでは、ここに行き着くしかない、という頂上（今のところ）なのです。

「PA^nの開発コンセプトは、何でも入れられて、何でも出せること」
つまり「バラバラ」を許容した上で成り立っている仕組みということです。入稿フォームも自由に作れる、テンプレートも自由に登録できる。組版エンジンも自由に選べる。簡単に使うこともできるし、スクリプトを覚えれば、もっとやりたいことができる。やりたいと思うことは、やりたいと思った人が試して、実現させるべきだと思うんです。いちいち仕様がどうのこうのってやりとりはイヤですよね。ただ、リスクを背負うことを忘れないように。

「まだ途中ですけど、土台はほぼできた感」
PA^nになって失敗もあったけど、稼働2社目、ともにタウン情報誌です。不可能を可能にするウチならでは。モノを作るシステムを作ることも、モノ作りです。そして、結局は人が作り、人が使うわけなので、そこには将来に描く方向性を見失わない、課題を常に解決へ導ける強いチームが必要です。
従来のシステムは、仕様ありきだから、限界が先に見えてきます（比較的早い段階で）が、ウチのシステムは、限界を見るよりは将来を見るシステム。だって色々と変わるから。そういうコンセプトを理解してもらうには、時間がかかるのが課題。でもそれはどれだけ信頼してもらえるか、信頼してもらえるような対応や結果を出すか、だと思ってます。
半年運用で調整に調整を重ねて、軌道に乗りました。次のステップに入るところです。

「来年2009年2月に行われるPAGE2009でババンと」
行こうかなと。
ただ、従来のようなシステムですよ、アプリですよ、ではないアプローチで。

賛同する方募集中です。

ふぅ〜疲れた。。。PAGEまでにはまとめていこう。

Groovyコンファレンス2008 すんごいおもろかった

IBMのセミナーとして行われたGroovyコンファレンス2008に、山本が参加しました。
わたくしは、ただの付き人ですが。

2時間で発表が「15」コマなので、1コマ11分という短さ！
これが、なんとまあ、こりゃいわゆる「ライブパフォーマンス」ですよ。

この日のために用意してきた新曲とかリミックスした曲、過去の名曲を、その場で演奏するよな、そしてそれをドキドキしながら聴く。まさにライブを見に来たような感じです。

こういうのすごく「アリ」だと思う。Groovyって名前が良かったのかな。rubyだとこれまた違うんだろうか。ま、いいや。

とにかく、技術云々も大事ですが、ノリとセンス、これがこれから必要とされる要素だと思いました。

もともと、GCRで、「そろそろGrailsデモ大会でもやりますか」みたいな安易なノリで企画してたのが、いつのまにか大がかりな感じになってしまった今回のセミナー。
とりあえず感想など述べてみたいと思います。
自分自身よく分かってない部分もあるので、解釈が間違ってたらごめんなさいです。
違うなと思ったら、優しく突っ込んでください。ヤワな生き物なので。

１．Opening　根本さん
さすがプレゼン慣れしてるよなぁ。どちらかというとそこにすごく惹かれました。
SOAを推進するIBMとしてのGroovyとかGrailsの位置付けの説明や、Javaソースコードが、Groovyソースコードになると、ほらこんなに簡単、シンプルなんですよ、と、すごく分かりやすかったです。やっぱりSOA（とりあえずエンタープライズなアーキテクチャと理解した場合）とRubyOnRailsを対極と考えると、中間的な位置にいるのがGroovy/Grailsであるとそういう感じでした。

２．Groovy でつくるお手軽RIA　IBM須江さん
一度、GrailCodeReadingで「WebFlow」について発表されてたのを聞いてたのですが、
そうだ、須江さんはIBMの人だった。なんか雰囲気ちょっと違うなあ。
やっぱり本（Groovy in Actionの共著者）を書くと、すでに知識を持ってるのに、さらにすごく知識が増えるんだろうな。なんだか、遠い存在に見えてしまう感じです。
でも、そんなことより「Groovy in Action日本語版」買います！
発表内容は、「Remember The Milk」のWebAPIの操作を例に、GroovyでBuilder書いてSwingでRIAしてみようぜ、という内容でした。
うちは、印刷出版系なので、RIAっていうと、どうしてもAdobe様に行ってしまう。
まさに今それ。GrailsとFlexとAdobe InDesign連携などです。そしてクライアントアプリは、Adobe AIRにしてしまおう、です。
といっても作ってるものは業務系アプリとなるわけで、今まではブラウザアプリケーションとしてしか提供していなかったけれども、もともとVBなんかでクラサバアプリと比較されてしまうと、速度的な課題とか、CSSの表現範囲（ブラウザの表現能力）までしか見た目を調整できない、というのをやっぱり諦めてもらうしかなかった。でも、RIAの経験も増えてくれば、またクラサバみたいなイメージに戻るかもしれないけど、開発はまたアジャイルにいける可能性を含んでいる、というところを模索しつつ進めてます。なんだ、おい、ウチの話かい。

２．AntからGantへ　IBM宇野るいもさん
後で聞いたのですが、Strutsプログラミング講座他の著者の方でした。ウチにもあります。
Antだとビルドルール書くのが大変になるときがあるけど、GantならGroovyでスクリプトがたたき込めるから、すごい楽だよ、という話でした。
堀り下がっていろいろ調べて、人に言えるまでのまとめに辿り着ける人ってすごいなあと。AntとGantの違いとか、すごくよく理解できました。後日サイトに資料がアップされるそうです。

３．Web サービスを使ったスカッフォールド拡張　CIJ笠原君
Grailsでプロトタイピングするときに、Scaffoldを使うわけだけれど（実際僕も、プロトタイピングではControllerには、scaffold = Domainclass以外を書かない。Generate-allもしないので、Viewも出さないでいこうと思っている）、そんなときScaffoldの結果は、当然DomainClassに書いた名称なので、英語になってしまうわけだが、それをGoogleTranslateで日本語（多言語化）にしてしまえ、という、面白い発想。i18n-template使えばいいのに、と思いつつ、それさえもめんどくさいと。素晴らしい。思いついてやってしまう辺りが素晴らしい。日本語が微妙に変換されるあたりが、ちょっぴりユルいあたりも笠原君らしい。

４．UML エディタを使った Grails アプリケーションのプロトタイピング　CIJ杉浦さん
あ、二人続けて愛知県出身横浜在住ではないですか。他にもいるのかな。どうでもよいですね、はい。
タカハシメソッドライクなプレゼンをいつも作ってきて楽しませてくれる杉浦さんです。
JUDEでモデリングしたものをそのままScaffoldさせようという発表でした。
DomainClass.Groovyに書けば、それでいいんじゃないかなとも思いますが、最初の段階でウォーターフォールっぽいことを要求されたり、こういうやり方の方がなじみやすい人もいるんだろうなと。確かにHasManyとかBelongsToとか慣れてこないとよく分からなくなったりするから。
これも上と同じくPlugin化してました。

５．GrailsPlugin による印刷・出版業界向けWEBアプリケーション開発の事例　NCヤマモト君
前日「どうしよう…」という裏舞台を知っている自分としては、出版される「Grails徹底入門」の宣伝までしっかりとこなし、素晴らしいデキだったと思います。
AcegiPluginのコミッターとして活躍しておりますが、GroovyとかGrailsって、概念とか哲学とか、そういったことを最初に理解すべきなんじゃないかなと、彼の話を聞くとよく思います。技法がどうのこうのというより、結局は人が欲しいモノを人が作ってるわけで、開発、構築というところで、従来のウォーターフォール型の進め方よりも、もっとコミュニケーションを豊かに、人と人が作り上げていくモノというところを前面に押し出した、アジャイルの特性を活かした進め方ができるんじゃないかなと思います。第一その方が、楽しいし。

６．Grails 開発事例 -Java から Groovy へ　ディライトテクノロジーズ綿貫さん
AJAXも使わない、とりあえずピュアなGrailsアプリ開発について、
「宇宙刑事タケポン」を例に紹介してもらいました。
「宇宙刑事タケポン」ですよ。しかもロゴが素晴らしい。
後で聞いたら、ロゴに2日ぐらいかけてるらしい（山本氏と一緒です。彼も「まず重要なのはロゴ！」ってよく言ってます。）です。どっかでひろってください。僕はいただく約束しました。
綿貫さんのを見て、この人「センス」あるな、と。そしてロゴとかメッセージの「ノリ」。
すごく重要だ。そしてアプリが簡潔している。このぐらいで十分だと思うんです。その方が、あとあといろいろやりやすい。ご本人も言ってましたが、要求をすぐに反映できる、そこが素晴らしいなと。
あとは、プリント用のページをCSS通して作ってたり。そうだよね、PDF作るときもFOもいらないときだってあるんだ。Acegiもログイン画面とかそのまま。よりシンプルに作ることの見本を見せてもらった気がしました。

７．携帯カメラでお手軽ミニブログ - 携帯百景（ケイタイヒャッケイ）　フリーエンジニア　キムゾーさん
有名な方ですよね。一度GCRでお見かけしました。技術ネタが薄い自分としては話すことができなくって残念な思いをした記憶があります。技術といよりは、独特な雰囲気があるので、どんなヒトなんだろうと、素朴な疑問だけなんですが。
キムゾーさんのユル〜い発表を見て思ったのは、まず、「あー、こんなん作りたいな」と、創造力と意欲をかき立ててくれること。その感覚に襲われたのは、昔音楽を聴いて、「あー、こんな曲書きたいな」と思ったのと似ている。なんか、創造（想像ではなく）させるというか、難しい説明ではなくって、こんなもの作ってみました〜、みたいなノリがすごく相手をワクワクさせるというような不思議な感じでした。あんまり凄くないですみたいな感じで話すのですが、いやいや、いろいろ知ってないと、あと検証とか経験とか実績とかないとできないっす、と自分は思うわけで。でもそんなのをさらりとやってしまう。かっこえーと思う人でした。懇親会で隣に座るときが一瞬あったので、写真とってもおうかなと思いましたが、あまりにミーハーなんでやめました。

８．sMash(ProjectZero)と「Reflex」で構築するお手軽営業支援システム　Virtual-Tech　竹嵜さん
全然違う歴史もつ言語を連携させるには、という説明でした。こういう結構ガチなところを、効率的、効果的にやってやろうという気合いが垣間見られる内容でした。あとでsMashと「ぶいてく」で検索して見てみようと。実際動くところが見れなかったのが残念かなと。でもこういうハプニングも臨場感があって、ありですね。

９．Grails 開発事例 - Groovy/Grails で作るエンタープライズアプリケーション　CIJ永井さん
　ここ私用により退席してしまって聞けなかった。残念・・・。でもウチに修行にきたK君が、冗談で言ってたんですが、ホントにとっても明るくなっているので、それだけでも良かったなと思いました。全然関係ないですけど。Grailsのセミナーされるらしいので、行ってみようかなと思う次第です。

１０．Grails による社内システムの開発　NTTソフトウェア　上原さん 中野さん
　ここも退席ぎみで微妙に聞けなかった。言語オタクな上原さんたちなので、さぞ面白かったんだろうな。最後の方のまとめだけですが、Groovy/Grailsを使うことで、開発過程において「劇的に」変わったことがいくつかある、と、あと皆さん感じていることですが、その中でも変更を反映しやすいというのがすごく惹かれるところです。それから要求仕様言語として「ちなみに」を正式に認めるかどうか、また議論したいところです。

１１．groovy/grails でのライヴコーディング　法規書籍印刷　渡辺君（通称だいちゃん）
前から分かってることですが、この人は「オカシナヒト」です。ライブコーディングっていうから、何やるのかなと思ってたんですが、カメラ通して自分の映像を流したり、ベクトルデータをがんがん回したり、、、それをブラウザ上でスクリプティングしながらやってしまうというパフォーマンス。しかもGroovyのおもしろさ、柔らかさを取り入れて、です。大丈夫かしら、と親心で見てたのですが、これこそGroovyなのかなと、彼なりの思いが伝わりました。一緒に仕事をしてて楽しいと思える数少ないヒトです。

１２．WebSphere sMash でお手軽マッシュアップ　IBM水野さん
sMashの話。前の席をみたら、さっそく山本氏が説明を読んでた。あー、YahooPipeだ。分かりやすいUIですよね。sMashをあまり知らないので、受け売りですが、サポートするスクリプト言語はPHPとGroovyと。Rubyはないんですね。あと既存コンテンツをRESTFulに使うということで、連携の話ってよくあるので、ちょっと調べてみようとおもいました。

１３．Closing　メタボリックス　山田さん
ようやく8月26日「Grails徹底入門」出版されますね。Groovyコンファレンス2008も無事終了。とりあえずお疲れ様でした。
山田さんと出会えなかったら（僕ではなく山本ですが）、僕らはここまで来れなかったわけで、すごく感謝してます。懇親会ではいつのまにか帰られてしまったのでご挨拶もできず・・・またGCRでお会いしましょう。

新連携／モノ作り〜東京国際フォーラムに行ってきました

新連携／モノ作り（東京国際フォーラム）が8月5、6日に行われています。
あまり知られていないですが、我が社も実は認定企業になってます。
ビイサイドプランニングさん（滋賀）がコア企業となって登録されてます。
「新連携」というのは、経産省の中小企業基盤整備機構が募集して認定する、別事業体が連携して新しいモノ作り、ビジネスを生み出すことを支援するものです。現在全国300社あったと思います。

僕たちは根っからの自動組版屋さん、今ではそれをひっくるめて、データをどう流して欲しい形を得るか、とういうことにシフトしていますが、その事業体と、広告会社であるビイサイドさんのサービス（今はとりあえず求人情報に特化）をくっつけた新連携です。

中小企業と言うことで、いつもの展示会のように大手メーカーが40小間占領するというような派手な演出もなく、でも地味じゃないところがステキでした。

いつもは現場で職人としてやってるんだろうな、という人たちが発する自信に満ちた受け答え、とてもマニアックな会話がとても心地よかったです。

展示会に参加していつも思い出すのは、「君たちが、自分たちがやりたいこと、やろうとしていることをきちんと形にして説明できるってのは素晴らしいことだね」という、ある巨匠のありがたい言葉です。
やりたいだけではダメだし、やろうとしているだけでもダメ。0を1にして、形にして説明する、ということの大変さと、すばらしさをこういうところにくると、再確認して、また頑張ろうと思えてきます。

また、今日久しぶりにお会いした方から、もう4年前にリリースして、今も全国各社で何百人という方たちが日々使っているシステムがあって、まだそこの会社さんは導入してないんですが、「やっぱりいいんですよね、結局ここに戻ってくるんだよね」と、言われました。

そうなんです。

モノの本質をシンプルに捉えてこそ、そして、いろんな気持ちをそこに注入し、それを提供する側として、「本来こうあるべきだ」というある意味わがままを貫き通すことも必要で、その真剣さが使う人にも伝われば絶対にいいモノになるんだということも再認識させてもらいました。

何が正しいのか、何が良いのかは誰にも分からない。
でも本当に正しいんだ、という自信と誇りを持たなければ、使っている人も不安になる。
当然お互いが知っていること、知らないことには違いがあり、お互いの思惑もある。
モノを作る側も使う側も一緒になって考えていく「協調」「共生」が今後のモノ作りのビジネスには絶対に必要だと思います。