スクラッチとマッシュアップ

ダラダラと長文になった。
マッシュアップという開発方法がある。

マッシュアップ (Webプログラミング)

マッシュアップ（Mashup）とは、複数の Web サービスの API を組み合わせ、あたかも一つの Web サービスのようにする機能のこと。
IT の深い知識がなくても、既存の Webサービスを組み合わせて、短期間でアプリケーション開発ができることから、新しい開発技法として注目されている。

Web開発に限らず、最近はデバイス・ツールのAPIやオープンソースのライブラリなどの開発リソースが充実しているので、それらを組み合わせるだけでもそこそこのアプリケーションが出来上がる。
開発者がコアとなるアルゴリズムやコンテンツを持っていなくても、リソースの組み合わせ方など、「作った枠組み」がオリジナリティを持ち、価値を生み出す。時代と共に機能の実装方法・性能がコモディティ化して、「アプリケーション」という概念が1段階抽象化した。開発するものがより「目的」に近づいたということではある。これを「サービス」とか「プラットフォーム」と呼んだりもするみたい。
これからの技術者に求められるのは、個々の技術・アルゴリズムに精通するよりも、それらを統合して価値を生み出す力だ、なんて話も聞く。この手の話ではiPhoneが良く例に上がる。

こういう話は何となく理解できるが、マッシュアップで作られたものを「イノベーション」とか言われると少しモヤっとすることもある。
マッシュアップの対義語は何かと考えると、上手くフィットする言葉が浮かばない。スクラッチだろうか。

スクラッチ

コンピュータのソフトウェア開発を、パッケージソフトウェア等を使用することなく個別開発することを「スクラッチ開発」と表現する。

マッシュアップ的な考えからして見ると、スクラッチは非効率なものに見えてくるけど、マッシュアップ万歳とも思わない。

電通と博報堂は丸投げで中抜きしかやらない

誰もが名前を知っているような大手企業のメディアやキャンペーンの仕事は、電通や博報堂がまず一次請けになる。そして二次請けに中小の制作会社がつく。三次請けに孫請けの制作会社やフリーランスがつく。二次請けの制作会社はディレクションや進捗管理を担当する。実際に実務としてCMSやキャンペーンサイトの開発や制作を行うのは三次請け以降の会社の仕事である場合が多い。

では、電通や博報堂は何をしているのか。「丸投げ」と「中抜き」だ。時々、二次請けの会社に電通や博報堂の担当者が電話やメールで連絡を取って圧力を掛ける。あと、ナショナルクライアントから予算とスケジュールを取る最終決定を行う（その規模感は二次請けの会社が調整して提出する）。そしてプロジェクトを二次請け以降に丸投げして、予算を中抜きするのだ。

この構造はSIerのシステム開発に近い。誰もが名前を知っている政府や商社や銀行など大手クライアントの仕事はまずNTTデータが請ける。そして、実際のシステム開発業務は何とかシステムズとかいう社名のシステム開発会社に丸投げされ、三次請け以降がそれに連なる。最後に開発するのは末端の派遣エンジニアであったりする。そのWEBメディアバージョンが電通と博報堂の構造だ。

非常に極端で大きな釣り針ではあるが、学生の頃の自分なら賛同していたかもしれない。この記事に対して以下の記事。

本当に「電通と博報堂は丸投げで中抜きしかやらない」のか

さて、
博報堂は何をしているかをざっくり言えば
1. 大きな枠組みを設計すること
2. 核になるアイデアを考えること
3. アクションを細分化し、制作部隊へ発注
という3つかなと考えています。

「チーム・マイナス6%」で具体的に書いていけば
1は、「チーム」というフレームをもってきたことです。これがおそらく、競合プレゼンの大きな勝因だと思います。「チーム」という言葉を持ってきて、企業も個人も一緒になって、実現していく「民主型のスキーム」にしましょう。という提案だったのだと思います。あの頃企業のWEBサイトに行くと「みんなで止めよう温暖化」とかなんとかスローガンがおいてあったりしました。そんな大きな枠組みづくりを、博報堂の人間がよってたかって考えます。

こう言ってしまうと「簡単そうじゃないか」と思えるけど、これは意外に大変な作業でして、訓練された組織でなければ、なかなかきれいに全体を設計することができません。そのあたりが大手広告代理店が持つ（数少ない）特有の能力だと考えています。このチーム・マイナス6%という枠組みは、細部まで作り込まれたすばらしいものだったと今でも思います。

さて、次の２ですが、ここで言えば「クールビズ」という、個人のアクションを生み出したところだと思います。これはすごかった。温暖化対策を個人が参加しやすいアクションにしただけでなく、ネクタイを外すことが参加表明であり、可視化され、それぞれ個人が広告塔になってくれるわけです。

(中略)

3つめは言わずもがなですが、
「チーム・マイナス6%」というビッグスローガン(大きな枠組み)と、「クールビズ」というアクションを考えたあと、
「じゃー具体的にどうやんの？」「メディア買うの？」「テレビはどれくらい？」「新聞は？」「いやいやWEBメディアもうちょいいるでしょ」「イベントの役割は？」というようなメディア設計やら、それぞれのメディアにどういう役割を持たせるかなどの詳細を詰めて行きます。
そしてそれらがだいたい出来上がったら、すべてスケジュールひいて、予算配分考えて、誰に頼むかを考えて、タレント使うなら事務所とつながって……、と、実際に進行管理をしながら、クライアントである環境省の方と毎日のように打ち合わせをし、一緒になって巨大な企画をつめ、PDCAだってそれなりにまわしながら実行していきます。

かなりざっくりした説明ですが、こんなようなことをやっている(はずです)。

俺の書き方の問題で、簡単そうに見えるかもしれません。実際にはかなり大変なことをやっています。大きなひとつのアイデアを決定するために何度打ち合わせするかわかりません。アイデアという正解のないものは、網羅的にべつの可能性を追求しないかぎり、確信をもった提案に昇華できないからです。
すべての進行管理だって、大変です。本当に。営業は、制作とクライアント、そして外注先の間を一日いったりきたり、月曜から金曜まで家に帰れないなんてことだってざらにあります。

もちろん、見直すべきとろこもたくさんあります。もっと効率よくできるところだってあるはずです。

大ざっぱに言うとこの2つの記事、「仕事」と捉えているものがそれぞれ違っていて、前者はスクラッチ開発、後者はマッシュアップ開発なのだ。前者の立場で見ると確かに丸投げだが、後者の立場で見ると、外注に作業をお願いした時点で仕事はほとんど終わっている。
枠組み作りや組織の割り振りなどは、実制作・開発するスタッフに話が来る頃にはほぼ完成していて、もう個々の部品造りの段階だ。後者は「製造ラインを作る仕事」と言える。ラインができたら、後は工程管理≒コミュニケーションに専念する。キャンペーン企画というジャンルは同じものを大量生産し続けるわけではないので、はっきりとラインには見えないけれど。

この「ラインを作る作業」を効率化するのは確かに難しい。おそらく色々な要素の組み合わせ(マッシュアップ)をシミュレートして予算と期間のバランスから決定しているはず。この作業は様々な工程のスケジュール・予算感を把握している人間でないと難しい。ここに当てはまるのが広告代理店のような組織だ。

そして、作るものの規模が大きく多岐にわたるようになって、二次請け、三次請けと、だんだん工程のスケジュール・予算感が把握できなくなると歪みが生じる。これは組織体制の問題も含んでいて、構造的に直接交渉が難しい上、中間にいる窓口担当が調整下手なイエスマンだと歪みが加速する。
また、色々な枠組みの可能性を考えたけど、現実に落とし込んだら結果的にいつもと同じ枠組みに落ち着いた、とか、作業の実態が見えづらくなることも。枠組み作りに時間を割いた結果、実制作の時間が圧迫されてしまったり。大抵デスマーチはこういう構造から生まれるよね。特にキャンペーン企画は、基となる商品やサービスに付随するものだから、締切をずらしづらい。商品発売日に宣伝サイトが用意できていないなんてなかなか許してもらえない。
前者の視点だと、これらの悪い条件が揃った状態で依頼が来て「無茶なスケジュールで丸投げしてくる奴ら」にしか見えなくなる。

ついでに言うと、SIerが絡むシステム開発と広告代理店が絡むWebメディア開発ではタイムスパンが違うけどね。

と、ここまで書いて、「マッシュアップ開発でイノベーション」ってのが持てはやされる理由がちょっとわかった。
実開発の工数を極限まで削って、枠組みを考える時間を目いっぱい取れる。継続よりも瞬発力が重視される業種向きで、技術の詳細を理解しなくて済むのも企画業務と相性が良い。
技術を積み上げて強みを作るような長期的視点が必要ない、キャンペーン企画開発程度のタイムスパンで結果を出したい人には好まれるのかも。
製造業でこれをやってしまうとすぐにキャッチアップされちゃうけど。

キャンペーン関係の開発が五月雨実装化するのもちょっと納得。そして、自分は基幹系とキャンペーン系両方の開発を体験できていることに気づいた。

追記：後者の引用元が削除されちゃったけど、論点の違いを整理している記事↓
http://mubou.seesaa.net/article/396393583.html

ああ、確かに、論点が違うまま不幸自慢で返しちゃっただけだ。