物作りをする人たちが最終商品の品質についてどこまで考えられるかについて

ネタ的には、出版界の恥を晒してしまった書籍「アインシュタイン その生涯と宇宙 下」が機械翻訳だったため回収へ - GIGAZINEという記事について制作という立場から思うことを書いていたら、8月4日に発生した東海テレビのテロップ表示の放送事故、同日開催されたグラフィックコミュニケーションズ工業組合の電子書籍セミナーが本題に関わるのでまとめてみる。

まず、機械翻訳で出版したものが後で発覚して自主回収という、なんだそれ、状態の話。別に糾弾するつもりはない。
これは謝罪文によると7月1日となっていて、発行されたのは6月末頃らしい。ネットで機械翻訳の噂がというか、もうあからさまなんだけど、いろいろと盛り上がって、ここ数日前に投稿された多くの記事でそのひどさについて書かれている。

書籍を制作している自分の立場から考えても「？」が多いこの話。出版社内部で制作してんのかな。
普通だと著者（今回は翻訳者）←→編集←→制作でこねこねしながら、権限のある人が校了フラグを立てるまで、数回「校正」という工程があるはず。
その後印刷に回るわけだけど、そこでも誰かが間違いに気づいたりして印刷機を止めてもう一回その版だけ刷り直すとか、そういうあんまり効率的ではないと思われるほど、完成物に対して神経を尖らせている、そこまでやらないと自分たちの仕事は完結しない、のだとこの話を聞くまでは思っていた。

実際自分でも印刷入れした後に、「はっ！やべえ！」って気づいて印刷屋さんに青くなりながら連絡したりとかあったんだけど、そういうのもなしで、あんだけの本を刷っちゃうんだなあというのがあると、よっぽど腹が据わってるかと思えば自主回収だし、、、て考えていくと、まさか売るためのネタ作り？とか思ってしまうのだった。ま、そんなわけ無いけど、中古本が高値になってるらしいので。
んでもって、早急に修正しますってあるけど、ここまできたら時間よりも内容だと思うんだけどなあ。

著者、編集、制作、印刷という分担作業の中、データでのやりとりが普通になったことで、システマチックな制作フローが組めるようになって、右から左に流れていくようになっている。
それでも、各工程で、今回のような「校正」以前に内容についての推敲や議論がされない状況では、出版社における編集という価値が低下傾向にあって、世の中の出版不況が活字離れとか言ってたけど、それって違うよねと。根本的なところに立ち返る必要がある気がする。

で、これは出版社に対してだけじゃなくて、制作する自分たちも、「これはおかしいよね」と普通に言えるようにならないといけない。
分業で、いつのまにか制作担当者の地位は、「ただ言われたとおりにやればいい作業者」として扱われるようになっている。
内面的な意識も「自分たちは言われたとおりにやればいいだけ」「余計なことをする（言う）と怒られる」とか、そうなっている傾向が見受けられる。当然、そうでない人もいっぱいいる。
それは意識だけの話じゃなくて、行動で示さないといけないわけで、ことの顛末の記事を見ると、編集長から延期を社長に申し入れして、却下されてとにかく出版した、ということらしいけど、編集長さんだけじゃなくて、もしそこに自分たちが関わっていたら、物作りをする立場の人間として「これじゃ絶対に出してはダメです！」って言えたかどうか。。。

東海テレビの放送事故も考えられない失態なんだけど、制作スタッフが先行して作って、あとはダミーデータにしておく、ということはよくあることで、これは印刷物やWEBなどの物作りに限らず、システム開発なども一緒。作っている最中にちょっとした遊び心（今回のは度が過ぎるけど）でダミーを仕込むことがよくある。そういう「緩さ」というのが命取りになるということを制作に携わる人がよくよく理解していないといけない。話によると、番組は打ち切りかもしれないらしい。

ここだけの話じゃなく、企業組織やビジネスの中で普段は軽視されがちな制作のちょっとしたことかもしれない作業が、とんでもないところまで波及する可能性を孕んでいるということを理解できているかどうか。
やっちまったなー、って傍目で見ていていい話じゃないと思うのです。
印刷物やWEB、メディア関係の物作りという仕事における今現在のひとつの象徴である気がするのです。

DTPオペレーターもアニメーターもデザイナーもWEB屋も放送メディアの制作スタッフも給料がめちゃ安いという話を聞いたことがある。
DTPは知っていたけど、他もそうなんだと。これでは育てる環境が作れない、それが作れないということは良いものが作れるはずがない。
そういう中で、物作りの仕事することはもちろんのこと、楽しく仕事するのも大事、でもその領域をちゃんと理解できる良識を持った人材を年代に関係なく教育していくこともとても重要な仕事だと思います。
どうも日本は古来からの営業スタイルによって営業が強すぎる気がするんだよな。それは他業界は違って良いかもしれないけど、物作り、クリエイトする仕事において、価格が営業主導で決められるってのはどうなのって思う。

本日のセミナーによると、一般書（印刷）からeBookになったところで、出版社が痛手を被ることは少ない、若干良い方向へ向いていくが、その中で、「品質を保つ、アップさせるという工程の価値が高まっている」とのこと。

製版・制作会社が多いGC（グラフィックコミュニケーションズ工業組合）に対して、JAGATの小笠原さんが総括的におっしゃっていたが、今まで「印刷物を作る」ということが、データを作って印刷は別のところがやるということで、誰かの手が加わったものが商品になっていたが、電子書籍などを作れば、今自分たちが作っているものが、最終商品になる。
そこにはチャンスがいっぱいあるわけだけど、そのためには、今とは違った意識で取り組む必要があると。その商品の責任がすべて自分たちにかかってくるということ。それは、お客さんの商品だけど、それをどうやれば売れるのか、ということに本気になって向かっていけるかどうか。そういう面で意識を変えないといけないということだった。

「校正」というものが、専任の担当者がやる仕事、という理解ではいけないわけで、「これでいいのか」ということは携わる全ての人が意識をしないといけない。印刷がただ刷るだけでいい、制作もデータ流せばいい、あとは知らん、という意識が浸透してきている気がするのと、物作りが、なんだか歪んだ、ふざけた感じで、いいんじゃね、しらね、という意識が表面化してきている気がする。
そうなると、工賃作業から自分たちの価値を対価に変えることができるというせっかくのチャンスを取り逃すことになりかねない。
もっと、物作りという行為や、商品というものに対する意識を高く持たなければ、自分たちの環境などその上に成り立っているわけで、よくなるわけながない、と思う。

最初の３つが繋がったかどうか、、、

花火を見て思ったこと〜お客さんと一緒にシステムを作る試みのプチまとめ

40も近くなると、忘れてしまうことも多くなる。

でも、今日の出来事はちょっと胸に刻みたい。
そして、受託開発ではない「お客さんと一緒にシステムを作る試み」の一つの区切りなので、
それをまとめておきたいので書いている。

今日は、うちのdot3（旧WPS）の導入先のお客さんが、
情報誌の誌面リニューアル、WEBサイト公開にこぎつけたので
出版記念パーティをするからおいでと声をかけていただいていた日。

サーバ移行もあったので前入り、後入りで総勢4人。

パーティは総勢80人ぐらい。
海が見える素晴らしいロケーション。

が、しかし、、、

花火を打ち上げる予定があったけれども、
午後から降り出した雨が開始早々いっそう激しくなり、
海はおろか外の景色も見えないような状況で、
これは無理だなと。。。

5年ぐらいのお付き合いの会社さんで、
1年ぐらい前、このリニューアルにかけて当時使っていたWPSを廃止して、
自社開発でやろうかなと。でもまだ迷っているので、ちょっと何ができるか
相談したいんだが、、、というお話をいただいた。

WPSもその頃には、安定期を超え、
次のPA^N（WPSを柔軟な仕組みに切り替えたもの）へと
開発フェーズも移り、さらに練り直しをはかろうかというところだった。

その間、僕らは営業というものが
社内で確立していないことを言い訳にしてしまっているが、
既存のお客さんへのレビューなどほとんどしてこなかった。

だから、新しいものを見せたとき、
「それだよ！なんで教えてくれなかったんだ！」
というような、お叱りでもあり感嘆でもある言葉をいただいた。

しかし、僕たちの見せる技術は、海外では当たり前であっても、
日本国内ではかなり先駆的な技術。

大手であれば、必ずNoと言われる。
そんな知らない技術は、採用できない、
まずは外部設計と、詳細設計がないと受け入れられない、などなど。

技術なんて日々変わっていくものだ。
余計な時間をかけるだけ、日本はどんどん遅れていく。

Web入稿、自動組版やWEBサイト連携という仕組みなので、
入稿したものが出ればいいし、その他付随する機能は、
どんどん付けて、いらなければ外せばいい。
そもそも、お客さんが思う範囲、言われたことしか開発できないなら、
その大元のアイディアはお客さんにあるわけで、
開発者ではない。ただのコードがかけるプログラマ。

お客さんが言うことを覆せとは言わないが、その先を考えて、
いいものを提供する、お客さんがどういおうがそれを説得するだけの力を持つのが、
開発者という立場じゃないだろうか。

ここで、いつも問題となるのが日本の確固たるシステム開発におけるビジネススタイル。
「最初に明確な要件定義とそれに基づく見積もりありき。」
「設計書が全部そろってから開発開始」

これだけビジネスのスピードが速く、技術の進歩も早いなかで、
最初に決めることへのリスクがどれだけ高いかというのは、
多分、開発という行為を「価値」にかえて売るのではなく、
開発した「もの」を売る商社的な人たちには分からない。

そこで、やってみたのが、
「お客さんと一緒にシステムを作る」試み。
今思えば、よく納得してくれたなと思う。

現在では、数本このようなプロジェクトが社内で走っているが、
1年前というつい最近でもまだ認知されるものではなかった。
世の中がアジャイルという手法に取り憑かれ始めた頃だったと思う。

その主な内容は、
・システムリリース、サービスインが納品ではなく、
プロジェクトの開始から月額決めた金額をいただく。
・短期間で区切って進める。
・お客さんからも開発メンバーを出してもらう。サーバ構築、プログラミングを覚えてもらう。
・要望の変更、追加は随時受け付ける。もちろんこちらからも企画を出す。
・金額の範囲内で、動かせる人員、工数が出るので、そこで出来ることを基本として優先順位を決めて動かす。
・ハードウェア、サーバ構築は、スタートアップとしては小さくしておいて、システムがベータ版になるぐらいで導入検討を行う。
・設計書は書かない。動くもので確認して、さらに進めていく。

つまり、両社で納得しながら順番に進めましょうという試み。
アウトソースというよりは、業務提携に近い。
うちからは、アーキテクト、サーバ、プログラム、サポートに関わる専門知識を持つ人間が、
それぞれの役割を、そして、お客さんも開発を投げっぱなしではなく、分からなくてもそこに加わる。

僕らが、やっていくうちに業務を理解できてくるのと同様、
お客さんも僕たちの世界を垣間見る。
そうすることで、あーそういうことか、とか、
ここは自分たちで決めないと先に進まないな、とか
意外と大変だ、これはプロの力を借りないと無理だなとか、
意外と簡単だ、これなら自分もできるなとか、
そういうことが見えてくる。

あんときああ言ったじゃないか、というのがプロジェクトが炎上するときの発火地点。
言った言わないになるのは、「最初に明確な要件定義とそれに基づく見積もりありき」に
全員が縛られるから。そこがあるから、という頭にどうしてもなってしまう。
見積もり段階で、点の技術検証はとれていても、複雑に絡み合う機能になった場合に、
その立証は、動かしてみないと実際のところできない。出来るはずがない。
それが言えない状況がシステム開発にはよくあることだと思う。

納得するというのは、お互いの気持ちを理解する、これが重要だと思う。
そうすれば、柔軟な方向転換が可能になる。

そうやって、お客さんと一緒に、
何でも言い合えるチームというのを確立することで、
開発側も今すべきこと、この先にすべきことが見えて、
意見を言うことができるようになる。

これがパートナーシップに基づいたビジネスだと思う。

といいつつも、、、

すべてが順調に行ったわけではない。
技術コンサル的な位置付けもある中で、お金をもらっている以上、
中途半端なことはできないから、今までよりもさらに
リサーチと検証を注意深く重ねなければいけないこと、
手法の柔軟さから、お客さんの方が決めかねるシーンがあったり、
最初の思惑と違うことが出てきたり、
いや、やっぱりちゃんと決めた上で動かさないといけないんじゃないかという意見が出たり、
今回はなかったけれど、人の問題や、外部要因（震災の影響とか）も入ってくれば、
柔軟でなければ、なんともならない。
プロジェクトがストップしてしまうことが、一番の痛手であって、
大抵の場合、拘りを捨てれば前に進める。

そういう中で、右往左往、試行錯誤しながらも、
無事出版され、WEBサイトも公開され、終わってはないが、
一段落したところで、振り返ってみると、
今後を占う良い事例になったんじゃないかと思う。

それが良かったかどうかは、
こういった場で、関わった人たちが一堂に介し、労をねぎらい、
次への意気込みを語り合うことで確かめられる。

ビジネスである以上、お金ももちろん大事だけれども、
それを生み出す人たちが、同じ方向を向いていないと、何も生み出せない。
そうしなければ単発の意味のないものに終わるだろう。

パーティは、来賓の方のご挨拶や、スタッフの紹介が終わったところで、
いつの間にか雨がすっかりあがっていた。

そして、予定通り（なのかな）花火が打ち上がった。

花火大会でみる花火とは違って、ここにいる人たちのためだけの花火ってのは、
感動もひとしお。

うちの人たちも、時には技術的な面、気持ち的な面で叱責を受けながらも、
夜遅くまで、土日問わずやっていたときもあっただろうし、お客さんの方も、
リニューアルっていう不安の中で、営業の人も制作の人も、
毎晩遅くなってもあきらめずにがんばっていた人たちがいっぱいる。

でも、こうやって一つの結果を出すことができたというのは、
力を合わせれば、あきらめなければ、やればできるっていう証明。
そりゃあ涙も出ます。

開発メンバーの他にもうちには制作もいるわけで、
この話は今苦しんでいる制作にもちかえってやりたいと強く思った次第。

僕たちがやっている開発や制作というのは、縁の下の力持ち的な部分が大きい。
時にその存在を忘れられることもある。

WEBサイトやアプリは華やかにレビューされるが、
そこにデータを渡す仕組みを開発することや、
リスクを考えたサーバ構築や、
コンテンツを作るという作業自体には、あまりスポットがあてられない。
いや、これは見えない世界だから仕方ない。

出版物やサイトが正常にできあがって当たり前。
当たり前を当たり前のようにやる。

それでも、ちょっと悔しかったな。
華々しいことを期待するわけじゃない。

もっと自分たちが認めてもらえるように、
それを個人ではなく、チームとして、会社として認めてもらえるようになりたい。
ここで、自己満足してる場合じゃない。
もっともっとできることがいっぱいある自分たちだからこそ、
それを発揮して、今度は自分たちのためだけの花火をあげてみたい、
と思った一日でした。

来月また行くことになりそうなので、
がんばれば道がひらけるんだという勇気をもらったこと、
この感謝の気持ちを忘れないようにしよう。

あいかわらずぐだぐだなブログだけど、
そろそろちゃんと書き始める。

ということで、4時やん。。。寝よう。。。

PDFの電子書籍アプリ化サービス「NCView」のリリースで、何が言いたかったか

NCViewは、PDFがあるなら、
それパックしてアプリにしちゃおうよ、というもの。
EPUBとかとはまた別の世界。
すでにあるもの（ここでいうのはDTPの成果物であるPDF）を販売したい、
というニーズを満たすために存在する。
、、、とはオモテの顔で、
実は、「これほんとに必要なの？」という意味もあったりする。
電子書籍ってもんが、どうもこう違うんじゃないって
方向に進んでいくのを感じてしまう今日この頃。。。

うちは、ソフトウェアを開発するけど、
一過性のニーズを満たすものなんかは手を出さない。
電子書籍を開くと、びよーんってうちのロゴ出したいわけでもない。
なのになぜ、今さらViewerを開発したのか。

PDFが読めるViewerと言えば、iBooksやi文庫HDをはじめとして、
たくさんの会社が出している。
アプリとして生成するツールやサービスをやっている会社もたくさんある。
なんならXCodeでビルドしてみなよ、という本を出してる人もいる。
アプリにできる人たちは、そこにビジネスチャンスを見いだしたわけだ。

その機能はすでに成熟している。
電子書籍を「読む」という欲求を満たすにはすでに事足りる。

というか、一番シンプルに考えれば、
まず読めることであって、それ以外は実はいらない機能だったりする。
あればいいなを付け足しただけ。
しかし横並びになれば、あっちはあれがついてて、
こっちはこれがなくて、、、という話が盛り上がる。

そんなところで差別化されたくもないし、
そもそも自分たちの方向性、
いろんなデータ形式へのコンバートやコンテンツ管理
に合わせて作りたいだけで、
大抵のニーズは、分かってることであえてやってない。

作ろうと思えば作れるものであって、そんな小さな世界で競争したって
お互いに疲弊するだけだ。

ストアにしたってそうだ。
AmazonやGoogle、Appleみたいな世界規模でやっているところに勝てるわけがない。
彼らが本気出したら終わりだ。
ただ日本の小さな、言語的にも閉鎖的な世界へ本腰入れないから、
そこがチャンスだと思うなら良いかもしれない。
いずれにしろ、彼らに勝てるわけがない。

その先にやりたいことがあって、そのためのステップとしての機能ならつける。
先々をみたときに必要な機能を、ニーズとして受け取ってしまうならば、
それはどちらかというと遅い。

だから、欲しいと言われた機能をこばんだりする。
「今それ必要？」と。

例えばiPhone版もいると言われたときに、
その誌面がiPhoneでみたら見づらいなら、
ユーザは買わないと思う。

買ってもクレームを言うと思う。
だから、いらないと思うのでやらない。
お金積むからやってよ、っていわれても気持ち的にやらない。
すんごく積まれたら、あっざーす！ってやる。

でも大抵、違うんじゃないのって思ったことをやってしまったときほど
そのプロジェクトが失敗の道へ進む確率が高くなる。
だからやりたくない。
わがままに思われるかもしれないけどやらない。
これがあれば売れるんだよとか後出しするのは、大抵いらない機能。

まあ、こういうのを「とっきとき開発」という。

電子書籍をアプリにする必要があるのかを
もう一度ふらっとな気分で考えてみる。

すでにアプリにしなければならない、
という位置にいるならちょっと前の自分を召還してください。

電子書籍を出す理由
・書店で売れないから
・書店に出しても売れないから
・そもそも売れないから
・流行だから

ちょっとまってね、、、
売れないものは売れないです。
売れなかったもののアプローチを変えるなら別だけども。。。

電子書籍で売れるもの（勝手な想像）
・売れるはずがないと思い込んでたもの
・超新書
・どっかのコミュニティで盛り上がっちゃったもの
　つまり、特定の分野の人たち向け
・そもそも小さな範囲でいきたいと思ってるもの

売れないものが売れるのはたまたまです。
売れてたものがさらに売れるかもしれないけど、
その理由は従来の理由とは違うところにあると思われる。

だから電子書籍うんぬんの前に、営業的な感覚では出す理由がない。
だって売れるかどうかわからんものに販売計画などたてられない。

電子書籍なら売れるかもしれない、というのは多分幻想。

しかし、夢がある（。。。ポッ）

そして、紙がない、インクもない。
被災者の方ごめんなさい。ここではそういう話ではないので許してください。

販売を期待できる読者にも届けられない。

電子書籍、ありですね。

それから、在庫がいらない。
これが端から見て大きいと思うんだけどあんまり言われないな。
そこにどれだけコストがかかってるかしらないけど、
最初に見込み数をたてる必要がないし、
電子書籍の場合、初期投資の回収だけだから、
中長期でみればうんぬんかんぬん。
これは話がずれそうなのでやめよう。

もうひとつ。
提供者と供給される側の感覚は違う。
売れると思ったものが売れず、売れないと思ったものが売れる。
頼みの綱は、書店ではなく、買ってくれた読者。
読者様がどんだけ満足してくれるか。そこに集約される。
電子化は、間がすっとばされた分、本来在るべき姿の、
著者と読者がもっと近づけるチャンス。
今までは一冊ずつぶったぎられた販売を、
なにか連続的なもの継続的なものに変えられる可能性がある。
これも話がずれるのでこのへんで。

まあ、そういうのは期待できる。

だから、とりあえずやってみればいい。
そして、そこにいたる仕組みとか、反応とかそういうのをリサーチするための
テストマーケットだとおもってやればいい。

マーケットは常にテストマーケットであって、
正解なんて存在しない。
今存在しないマーケットをどう作るかであって、
既存マーケットへ投げ込んだって、従来の下をいくだけ。

成功するか分からんけど、それはおいておいて
とりあえずやってみる、というところを開発側として応援する。
だから、機能は最小限。
そこにこだわってちゃだめだよ、というメッセージ。
その反応を一緒にみて、この先を一緒に考えていきたいと思うのであります。

無駄な開発は、評価もされない。
どんだけ時間かかったとしても。
そんなもの作り手側としてやりたいか？
それより既存のもの・技術を利用して、少し先をみて
ユーザを引っ張る方がよっぽどイノベーション？

あなたの欲しいものは、すでにあります。
iBooksとかいろいろ。
だったらPDFにすればいいんじゃない？
いろんな会社が頑張って作ったものにのっかればいい。
DRMは、その人のメアドとかつけてさ。
そんな署名埋め込みなんてAcrobatでできるし。
決済はPayPal。多分明日からでもできるよね。
ほんとは電子書籍って、ちょっと覚えれば自分でできるぜ！すごいぜ！
っていうことが発端じゃないのかしら。

うちはコンテンツホルダーじゃない。
出版社さんたちはその点うらやましい限りだ。
なぜ、すぐにでもやらないんだろうってすごい不思議な感じ。

でもPDFにも限界がある。PDFはPDFであってそれ以上のものではない。
そうすると新しいマーケットの開拓という意味ではちょっと。。。
開拓が決められた仕様によって遮られるのでは、進歩なんかできない。

リサーチして、反応を試しながら機能をつけられる。
それによって違う世界を作り出すことができるかもしれない。

だから違うスタンスでアプリにしてみた。
作ってリリース情報を流すぐらいなので、やるなら本気。
こんなよた話するぐらいなので、さらに本気なのかもしれない。
そういうことじゃないかな。