2008年10月06日

MTEntryNumberByDayプラグイン。

Q(Staff):MTのブログ記事アーカイブで基本的には、%c/entry%Y%m%d.html(category/subcategory/entry20081006.html) としているのですが、同日に2つ以上のエントリがある場合には、category/subcategory/entry20081006-2.html とかにしたいのです。

A(Junnama):ブログに上げといたよ!
プラグイン(EntryNumberByDayプラグイン)をインストールしてアーカイブマッピングを%c/entry%Y%m%d<$MTEntryNumberByDay prefix="-"$>.html としてください。

カテゴリー: MovableTypeプラグイン

2008年10月04日

MTFutureEntriesプラグイン。

もう帰ろーよ、週末やし飲みに行こーよ〜

え、再構築時点から日付ベースで未来の5件のエントリーを取り出したいの? タスク実行して毎日更新するの?

3分待ってね。

これでどーよ。

えーっと、もう帰ろーよ、週末やし飲みに行こーぜ。

カテゴリー: MovableTypeプラグイン

2008年09月19日

「Web時代の受託」を考えよう。

受託ビジネスには先がないのか?、とかいう話題についてのお話です。もちろん受託にもいろいろあって、SIerさんの言う受託開発と私の属しているWeb(制作)系の受託では少々異なる事もあります(でも、ある意味で当社はCMSベンダーでもあると呼べなくもない、そんな立場です)。それでも各業界に共通しているところは多いんじゃないかと思って書いています。あくまでも私見です。そしてこれは特にWeb業界、特に中小のWeb制作系プロダクション、そして地方のWeb業界を考える上での私の意見でもあります。

なぜ、お客さまはあなたの会社を指名するのか?

あなたの会社は受託のWeb制作(システム構築でも良い)会社だとします。なぜ、お客さまはあなたの会社を指名するのでしょうか? 例えばコンペであってもそうなのですが、なぜコンペの参加要請をあなたの会社にするのでしょう?

これは会社によってもちろん違う筈です。そして、この問いにはっきり答えられ、且つその理由が誰が聞いても納得できる場合、それは良い会社だと思います。

例えば私が採用面接をする際、応募者の多くはこの業界で且つて他社で働いていた人です。もちろん会社のトップや経営にコミットできるポジションにいた人ばかりではありません。

それでも、例え一デザイナーであれ「あなたが以前(現在)いた会社のお客さまは、何故あなたの会社を指名するのですか?」という問いにはっきりと答えられない場合、その会社は良い会社ではないような気がします。

「なぜ、お客さまはあなたの会社を指名するのか?」というのは、会社の強みである以前にその会社の「受注のしくみ」そのものです。「受注のしくみ」が末端のスタッフにまで行き届いていれば、社員は受注の理由やしくみを意識した行動(仕事)が出来ます。

特に顧客との直接の接点を担当する人(ディレクターや営業に限らず、例えメール一通であっても顧客とのやりとりが発生する人すべて)にそこへの理解がなければ、「お客さまがあなたの会社を指名した理由・期待」に応えられない行動となってしまう可能性があります。「期待と違う」。

その理由は納得出来るものですか?

さきほど、「この問いにはっきり答えられ、且つその理由が誰が聞いても納得できる場合、それは良い会社だと思います。」と書きました。そう、理由を答えられるだけでは駄目です。

例えば、

「社長が〜〜出身で、その時に築いた人脈で仕事を受けている」

という理由はどうでしょうか? こういう理由は「理解出来ても納得出来ない」と私は思います。本当に良いものを作らなければならない時、付き合いを重視して発注しますか? 人は常に変わるものです。信頼関係は脆いものだし、お客さまと付き合いがあるのはあなたの会社の社長だけですか?

こういうものは、例えば「お客さまの社長の息子が受託の制作会社を作った」なんて理由ですぐにひっくり返ってしまいます。

実際は人脈はきっかけに過ぎなくて、仕事の中で信頼関係が築かれているのかもしれませんし、会社の強みを理解いただいているのかもしれません。

であれば、その強みとは何か? それが本来の理由である筈です。で、それは目に見えていますか? 見えていれば冒頭の問いに「社長が〜〜出身で、その時の人脈があって仕事を受けている」という答えは返ってきません。

なぜこんなことを書いているかと言うと、実はこのような理由を挙げる人(応募者)が意外と多いのです(事業撤退とか会社が倒産して転職活動をしているといった人も少なくありません)。

社長の仕事は営業ではない

社長や、社長を含む経営陣のトップ営業ってのは(小さな会社にありがちなことですが)経営層の本来の仕事ではありません。会社を回して行くために時には必要なことかもしれませんが、そういった営業に頼った経営は早晩行き詰まると私は考えています。

トップの仕事とは何か?

多分この業界に限らないと思うのですが、トップの最初の仕事は冒頭にあげた「なぜ、お客さまはあなたの会社を指名するのか?」をつくることです。もちろん、絵に描いた餅では意味をなしません。自社が持っている強みや弱みを理解した上で、あるいは強みを作るシナリオを描いた上で(シナリオには時間を捻出したり必要な資金を調達したり人材を調達したり育成したりを含みます)、「なぜ、お客さまはあなたの会社を指名するのか?」を作り上げます。

これが、「受注のしくみ」です。

そして「お客さまがあなたの会社を指名する理由」に応える力をつけるのです。そのためには当然「なぜ、お客さまはあなたの会社を指名するのか?」の本当のところを現場の末端の人間に至るまで、徹底して理解させなければなりません。

そう考えると、全員に理解(うわべの理解では駄目で、納得という言葉のほうが適切でしょう)させるためには、その「お客さまがあなたの会社を指名する理由」が分かりやすく明快である必要があります。また「その理由は納得出来るものですか?」という問いに自信を持って Yes! と答えられるものでなければなりません。

受注のしくみをWebにのせる

ここからWeb業界固有の話になります(やっとかよ!)。

「なぜ、お客さまはあなたの会社を指名するのか?」が出来て、その理由が納得できるものになりました。では、あとはどうやってそれを未来の顧客に届けるか、です。きっかけは人脈でも何でも良いのですから、人脈をフル活用して営業しても良いでしょう。世の中には「営業」というものがありますから、スーツの皆さんの出番です。様々な方法で営業攻勢をかけていけば良いわけです。

でも、やはりあなたの会社の主力製品はWebですよね。だったらそれをWebにのせていかないと嘘だと思うのです。Webで何かを解決するのが仕事だったら、まずは自社の何かをWebで解決すること。これが出来ないと嘘だと思います。

「紺屋の白袴」って言葉はこのブログでも何度か書きました。自社のウリが自社のWebにきちんと反映されていない理由は何でしょうか? お客さまの仕事で精一杯で時間がない? そうなのであれば、それをWebで解決しましょう。

例えば営業が飛び回ってるとか電話でアポをとって営業しているとしたら、Webで勝手に受注が飛び込むサイトにしてみましょう。既に付き合いのあるところから「仕事はくるけど忙しすぎて自社サイトの更新が出来ない」のだとしたら、より利益の高い仕事がくるような自社サイトにして、仕事を減らして利益を確保しましょう。

おそらく、これが出来ない理由の多くは、投資を伴うからです。受託型のサイト制作なんかでは(特に小さな会社の多くは)積極的な投資を行えない、というケースが多いと思います。例えばCMSのライセンス料は払えないからOSSのものを使う、とか。

でも、投資をしなければ改善しないのだとしたら投資すべきです。極論を言えば、Web制作を生業としている会社が外注して自社サイトをリニューアルしても良いわけです。

投資をすると必要な売上げが増える、とか、自社サイトにとりかかるとお客さまの仕事に手が回らなって売上げが追いつかないとか。どっちも鶏と卵の関係ですよね。前者の場合は、必要な売り上げが増えた分を取り返し、何かを改善するためにやるわけです。後者の場合も同じ。

少なくともお客さまは私たちの仕事(Webサイト)に対して投資しているわけです。自分たちはWebサイトに投資することの意義をわかっていないで仕事しているのでしょうか?

もちろん、人材への投資についても同じです。

捨てて、得る発想が必要

必要な売上げがあがらない時期が出てくるのが嫌ならば、必要な売上げを一時的に減らせば良いわけです。

例えば給料を下げる。従業員のモチベーション? いや、そうではなくて、いるでしょ? 会社を一番変えたくて一番給料の高い人が。潔く社長が自分の給料下げちゃえばいいんですよ。その覚悟がないから変わっていけないと思うのです。

もしくは一時的に仕事を断る勇気とかもそうです。より大きなものを得るために、何かを捨てなければ。

会社こそが「作品」であり社長とは映画監督兼プロデューサーのようなもの

私は最近こう考えています。社長の本当の仕事とは、「シナリオを書くこと、シナリオに必要なキャスティングをすること、必要な予算を確保すること」そして「監督としてシナリオを元に作品を作ること」。企画が悪くてシナリオが悪ければ作品は売れません。予算がなければ作品は作れません。もちろん優秀なタレントも必要ですが、シナリオがなくて勝手にタレントが何かを演じていても作品は出来ません。

別の軸で語られるテーマですが、受託のデザイナを「クリエーター」と言ったり、受託で制作した広告を「作品」と呼ぶのはおかしいんじゃないの? という話がありますよね。僕もある意味そう思います (そんなに拘らなくてもいいとも思いますが)。

さてそれでは、私たちにとっての作品とは何か? それは会社自身だと思うのです。別に自分が社長でなくても、シナリオに沿って自分の演技をしたことで全体として出来上がるもの。それが会社であるならば、それこそが自身の作品と呼ぶに相応しいものである。私はそう思います。

「シナリオ」の中に「Web時代」らしさを含ませる

で、結局受託がどうとかWebサービスがどうとかっていうのは、この「シナリオ」次第なのだと思います。まともなシナリオがなければ、それが受託であろうがなかろうが関係ありません。

そして、この「シナリオ」の中に「Web時代」らしさ(情報という財の新しさは、ほぼ限界費用ゼロで劣化なく無限に複製できるということ)をちゃんと含ませることが大切。

例えば、生産された財は、最も低水準なサービス財と同様、たった一人の顧客に届けられる。」という文章の一語を変えてみます。

加工された財は、最も低水準なサービス財と同様、たった一人の顧客に届けられる。」

それが必ずしもパッケージ製品である必要はないけれど、Web系の受託であればなおさらです。「フルスクラッチ」案件でも何らかのフレームワークを使ったり「シナリオ」を元に作られた再利用可能な自社のデータが使われているでしょうし、個々に度合いは違うにせよそれは「生産」ではなくて「加工」なのではないでしょうか(そうでなくとも、例えば「作るためのものを作ってそれを複製して売る」っていうアプローチもあります)。OSSの活用(やコミット)ってのもその一つだと思います(デザインも例外ではありません)。

そうした「Web時代」らしさの上にモノを作って行く受託ビジネスっていうのは十分に「Webらしい」し、それが受託ビジネスのひとつの利益モデルの確立の仕方ではないか? と私には思えるのです。

カテゴリー: Web制作・ビジネス, 駄文・雑文

2008年09月02日

スタッフ募集(東京オフィス)の件について。

少しブログにも書いておきます。

※年齢とか書けないのね。求人広告って。

広告の方にかなりメッセージ性を持たせたつもりなんですが、もう少し本音の部分等を書いておきます。

色んな人と話をしていて「会社をどうするの?」「拡大するの?」「上場するの(笑)?」とか聞かれることがあります。

最初の質問はともかく、「拡大」「上場」など全く考えていません。

考えているのは「拡大」ではなく「成長」です。規模の問題ではない。

よく、「人が足りない、人が要れば、よい人材がいれば...」などと言う人 (経営者に限らず) がいますが、僕の考えは「できるだけ人を増やさず、現在の人数でどれだけパフォーマンスを向上できるか」が基本です。マシンを買い足して行くのではなく(人はマシンじゃねぇ! とかw)、CPUをアップグレードしてメモリを増やして(例えが違うかな?)、ソフトウェアを最適化してインターフェイスを改善して、できるだけ拡大せずに成長曲線を右肩あがりにする。

そうではなければ、受託中心の仕事では人が増え仕事が増え売上げが上がっても利益が上がりにくい(特に一人あたりの利益はあがりにくい)。広告にも書きましたが結局徹夜の連続、報酬も上がらない、というスパイラルに陥りがちです。

さて、本題です。

以前、別のエントリーにも書きましたが。

今回イメージしているのは、未経験者も含む若い原石というか、バリバリの実務経験があるFA選手ではありません。若くやる気と夢のある人を育成したい。

「拡大」ではないのに何故増員? に応えるならば、レベルを上げるためです。すべては 「成長」のため。但し、それは「出来る人」に来てもらって全体を上げるのではなく、若いスタッフに参加してもらい、現在の弊社のスタッフを一つ上のレベルに上げて行くためです。つまり下を育てることで全体を底上げして行く。

現状、幸いなことに、弊社パッケージへの引き合い・売上げも一定ありますし、サイト構築(特にMTを使ったCMS込みの構築)も多くあります。新しいサービスや製品のアイデアも計画もある。また、既存の顧客に対してもよりパフォーマンスとクオリティ(この、クオリティというのは制作物のクオリティに限らず、サービス全体としてのクオリティ)を上げて、よりよいサービスを提供して行きたい。そのためにはやはり人が必要です。ただし、制作するためのしくみやクオリティを高める仕組みはかなり整備できてきたと考えています。だから、「若くやる気と夢のある人」に、現在の力以上の力を発揮していただける環境は備わっていると思います。そしてもちろん力を付けていって欲しいと思っています。

そういうことですから、僕の話をセミナーとかで聞いたりブログを読んだりして「難しそう」とか思っている人も興味があればご応募ください。できるだけ多くの人にお会いしたいと考えています。

そして、職種は「マークアップエンジニア」としました。

職種・用語の定義には色々諸説あるのでしょうが、どういう意味を指しているのかってのは是非面接の際にでも聞いてください。

それでは、良い出会いを楽しみにしています。

とにかく、制作スキルや取り組み方としての+αをきちんと提示していきますから、のっかっていただいて損はない、とここに宣言しておきます。

カテゴリー: Web制作・ビジネス

2008年08月29日

出来てほしいことが、ちゃんと出来ること。

リリースしました。MT4.2対応に加え、新しい機能も追加しています。

CMSツールの選定とか、MT関係のセミナーの質疑応答とかで良く話しに上ることに、「時系列型」「ツリー構造型」とかいう話があるのですが、確かにMTベースで組みやすい、適しているサイトってのがあると思います。

例えばニュース系ポータルサイトなんかはぴったりじゃないかと思うわけですが、これまでは規模とかパフォーマンスがネックになる場合もあったかと思います。MT4.2の登場でパフォーマンスが向上していますから、こうしたサイトを組む時にはさらに適したツールになったと思います。

で、このあたりも意識して、例えばニュース系ポータルサイトを作る時に必要な機能は何だろう? というのを今回は意識しました。

で、表題の「出来てほしいことが、ちゃんと出来ること。」ってのは、製品のコピーを検討しているときの没案です。社内で一番人気のコピーだったんですけど、よく考えたら出来てほしいことが、ちゃんと出来ること。」ってあたりまえですよね。

とはいえ、MTなり他の製品なりで構築している時に、「出来てほしいことが、出来ない」っていうケースは時々(時々で済まないかな)あります。そのあたりに応えるソリューションということで作りました。ちなみに、コピーは「Web制作現場から生まれたCMSの新しいスタンダード。」と続く案でした。そう、100%現場で出来ています。

あとは例のごとく? ワークフロー、承認フローです。弊社のお客さまからの要望でおそらく一番多いのではないでしょうか。ほとんど毎週相談を受けてカスタマイズしている感覚です。

ということがあり、今回の目玉は一つのプラグイン(名前はEntryNextRevisionというもの)です。

詳細はこのページにある弊社のM君入魂のムービーを見ていただくとして、簡単に説明すると、単に「下書き」→「承認依頼」→「公開」だけではなくて、公開中のエントリーを公開したまま「修正」→「承認依頼」→「差替え(公開)」という流れを作れます(もちろんメールで通知、差し戻しも可能)。

上位/下位のユーザーでワークフローを組む時に、下位の権限のユーザーは一旦エントリーが公開されてしまうと修正できないんですよね。修正するためには一旦下書きに戻さないといけない。下書きにすると当然ながらサイトからは一度消えてしまいます。

ということで作ったというのが当初ですが、今回のように当社のサイト更新する時も便利なことがわかりました。つまり製品がバージョンアップする時に、次のバージョンのエントリー群を用意して下書き、承認待ち状態で置いておけるのです。指定日にバージョン差し替えとか、一括公開もできますので、日時が来たらごそっと差替え、というような運用もできます。

ここでは、1点のみご紹介しましたが、他にも新しいフィーチャーが色々あります。是非サイトをご覧ください!

カテゴリー: Web制作・ビジネス

2008年08月22日

Movable Type Developer Conference.

Movable Type Developer Conference参加してきました。Lightning Talksも喋って来た。5分だから笑いとることだけ考えた(何か間違ってるかな?)。

ちなみに、朝MT4.2でPagerプラグイン動かん、てのでちょっと修正して帰って確認したら他にも動かないところがあって(ブログ記事リストでエラー吐いてた...4.2内部的に結構変わってる)修正しました。4.1と4.2で動作確認済み。

イシザカさんが撮影してくれたビデオ。当日の内容はこちらのページからビデオで見られます。

会場の風景。Lightning Answer? 中。

会場風景

いただいたUSBメモリ(InstaMTが入ってたら面白かったのに。Macユーザーだから入ってても使わないけどw)。あとTシャツも貰いました。

USBメモリ

yujiroさんCHEEBOWさんたちと丸の内ランチ行きました。みなカレー食べてましたが僕はダイエット中なのだ(絶対奇麗になってやる!)。

丸の内ランチ(シーザーサラダ)

カテゴリー: MovableType, MovableTypeプラグイン

2008年08月15日

Googleストリートビューの件(続き)。

先日書いたエントリーの続きです。

南港ポートタウンの話を書いたのですが、他の街はどうなんだろうということでちょっと見て回っているうちに気になったポイントがあります。

晒しちゃうこと自体がどうなのか、という話もあるのですが、このポイントです。

大阪の千里ニュータウン (既に「ニュー」でもないのですがw) の、とあるポイントです。このポイントの周辺は対象エリアから外れています。ところがこのポイントだけ「飛び地」みたいになってる。

ここだけ歩いていって撮影した? ってことはさすがにないと思いますが、どういう判断でこうなったのかちょっと気になります。

「映っていないところ」が気になるという視点については、以下のエントリー等でも取り上げられています。「団地」問題とは違う視点ですがそういわれると確かに気になりますね。

カテゴリー: 駄文・雑文

2008年08月14日

Movable Type 4.2 リリース、Movable Type 4.2 Perfect Guide。

お待たせしました! って、ええ、待ちましたよほんま。で8月14日ってさぁ、どういうことさーーー。

Movable Type 4.2は私の大事なもの(夏休み!) を奪って行きました w

ってな感じですね。

Movable Type 4.2 Perfect Guide

ほんでもって、これに先立って勇次郎さんから献本いただきました。拙作のプラグインも紹介いただいています。ありがとうございます。

いたいたからには、早速読んで感想とか書かないと、と思いましたが...思い、思い......重い! 正直まだ読めていません。読むの覚悟いりますよ。っていうか、これは読む本というより、リファレンスまたは学習本ですね。帯に「最強解説」とありますがまさに最強。インストールからプラグイン作成まで、とにかく網羅してます。

丁度先月から新人が来ているので、ほんと丁度いいです。全部読ませます。ありがとうございました。

MTづかいなら一冊、会社で扱うなら会社に一冊、必要でしょう。ちょっとだけ書評的なことを書くならば、この本は「MTでつくる○○○なWebサイト」という種類の本ではなく、「みっちりMTを学ぶ」「MTでわからないこと、こんなことをやりたいと思った時に開く」タイプの本です。

Movable Type Developer Conference

あと、こちらのイベントにも参加することにしました(お祭り? ですからね)。

Lightning Talksも申し込みました。今回はテンプレート寄り? みたいなので、Pagerプラグインでのページ分割について紹介する予定です。

それでは皆さん(誰?)会場でお会いしましょう。

カテゴリー: MovableType

2008年08月10日

同一カテゴリーの前後のエントリーを出力するPreviousNextInCategory互換プラグイン。

1,000ページ程のブログの再構築で500エラーが出るってんで原因を探していてPreviousNextInCategoryプラグインが怪しいっぽかったので同様の動作をしてより軽量(? 高速?) なものを作成しました。

おそらく500エラーになったのは以下のエントリーと同じ理由と思われます。

プラグインは2種類あります。4.1のコードを眺めていて「$terms->{by_category} = 1;」ってのが使えんの!? で使ったらいけたんだけど、4.2rc2でエラーが出てしまってあら残念。仕様変更でなくてバグだったらいいなぁ、と思いつつちょっと最新のベータとかで試せてなくてまぁ両方晒しておきます。

4.1で使える版の該当部分のコード。シンプルで書きやすくて素敵。残念ながら4.2rc2ではエラーに。

sub _hdlr_entry_nextprev {
    my( $meth, $ctx, $args, $cond ) = @_;
    my $e = $ctx->stash('entry')
        or return $ctx->_no_entry_error($ctx->stash('tag'));
    my $terms = { status => MT::Entry::RELEASE() };
    $terms->{by_category} = 1 ;
    my $entry = $e->$meth($terms);
    my $res = '';
    if ($entry) {
        my $builder = $ctx->stash('builder');
        local $ctx->{__stash}->{entry} = $entry;
        local $ctx->{current_timestamp} = $entry->authored_on;
        my $out = $builder->build($ctx, $ctx->stash('tokens'), $cond);
        return $ctx->error( $builder->errstr ) unless defined $out;
        $res .= $out;
    }
    $res;
}

4.2でも問題なく動くコードはこちら。制限として、タイムスタンプが全く同一の場合はうまくいかないっていうのがあります。割り切って使えるならこれでもいいか。

sub _hdlr_entry_nextprev {
    my( $meth, $ctx, $args, $cond ) = @_;
    my $e = $ctx->stash('entry')
        or return $ctx->_no_entry_error($ctx->stash('tag'));
    my $category_id;
    if (my $c = $e->category) {
        $category_id = $c->id;
    }
    return '' unless $category_id;
    my $entry = _hdlr_neighbor_entry( $e, $category_id, $meth );
    my $res = '';
    if ( $entry ) {
        my $builder = $ctx->stash('builder');
        local $ctx->{__stash}->{entry} = $entry;
        local $ctx->{current_timestamp} = $entry->authored_on;
        my $out = $builder->build($ctx, $ctx->stash('tokens'), $cond);
        return $ctx->error( $builder->errstr ) unless defined $out;
        $res .= $out;
    }
    $res;
}

sub _hdlr_neighbor_entry {
    my ( $entry, $category_id, $meth ) = @_;
    my $direction = 'ascend';
    if ( $meth eq 'previous' ) {
        $direction = 'descend';
    }
    return MT::Entry->load({ blog_id => $entry->blog_id,
                             status => MT::Entry::RELEASE() },
                           { sort => "authored_on",
                             start_val => $entry->authored_on,
                             direction => $direction,
                             limit => 1,
                             'join' => [ 'MT::Placement', 'entry_id',
                                       { blog_id => $entry->blog_id,
                                         category_id => $category_id },
                                       { unique => 1 } ],
                           } );
}

ダウンロード

テンプレートタグの記述はPreviousNextInCategoryプラグインと同じです。

カテゴリー: MovableType, MovableTypeプラグイン

2008年08月09日

そろそろGoogleストリートビューにひとこと言っておくか。

Google の中の人へ

Googleストーリービュー、便利で大変面白いのですが、私の住んでいる街が撮影されておらず残念に思います。大阪市内ですから対象範囲地域でもないでしょうし。一度ご検討いただけませんか。

ただし、車で街に入るには許可証が必要です。警察署で通行目的を添えて申請し、許可証を発行してもらってください。


本気で書いたわけではありませんが、僕の住む街が撮影されていないのは事実です。通行には許可証が必要なので、勝手に車で入ることはできません。歩行者は勝手に入れますから、撮影は可能です。撮影してたらどんな目で見られるかは分かりませんけど。

日本の都市生活者のモラル

「公道からの風景だから公開を前提としているはずだ」ではなくて、「公道を通る者はその鼻先の生活空間はのぞき込んではいけない」というのが、日本の都市生活者のモラルなんです。

僕にはこの感覚はわかるし理解できます。これは法的な問題ではなくモラルの問題。モラルの低下は法的な問題を引き起こしやすくするかもしれません。

都市でなく田舎ならどうか

日本の田舎の場合、こんなもんですみません。「どこそこの路地で○○さんとこの旦那と△△さんとこの嫁が一緒に映っとるで」ってのはアレゲですが、田舎の場合は情報が広まるスピードにおいてネットよりリアルの方が凄まじいってもんです。

女性の視点

ここ数日色んな人とこのサービスの話をしていたけれど、Googleストリートビューの件を話題にした時、全体的に女性(特に一人暮らしの女性)が嫌悪感を持つ割合が多いように思います。

「モト彼(女)」の家、見ちゃったよ」と言ってる同僚がいてドン引きしちゃった女性とか(実際に聞いた話)、ネット上でのそんな書き込みとか見た時にすごく嫌な気分になったとか。

嘘だと思うなら、一人暮らしの女の子と一緒にGoogleストリートビューを見て、ベランダの洗濯物表示して「これ絶対女性の一人暮らしだよね」とか言ってごらん。気味悪がられる事間違いなし(瞬間的に気味悪がられるのはGoogleではなくてあなただけどね)。

例えば何らかのきっかけで異性の住所を知った人が家を確かめに行ったり待ち伏せしたりする行為とGoogleMapで住所を調べ、ストリートビューで「あぁ、ここに住んでるのか」という行為では、後者の方が圧倒的に行動に移しやすい(行動コストとリスクの問題、つまり実行しやすくバレにくいから)。

それが犯罪につながるかどうかは全く別の問題として、それを「嫌」と感じる女性は多いのではないかと思います(統計とってないけど)。

ネットのコミュニティはどちらかと言えば男性中心社会でしょうから、そういった女性の声は目立ちにくいという面もあるでしょうし。

親の視点

一方、自分の家の近所を見ていて、小学生くらいの自分の子供とわかる姿がくっきり映っていたとしたらどうでしょう。あの程度のぼかしであれば自分の子供の判別等簡単につくでしょう。これも法的にどうとかいう問題でなくて、映っているという事実について違和感というか嫌悪感のような感情が生まれるかもしれません(僕はやはり何となく嫌な感じになるだろうと思います)。

決定権を住民が持つ街

さて、冒頭の話に戻ります。僕が住んでいるのは大阪の南港ポートタウンというところです。この街は今となっては既に新しい街ではありませんが、当時としては進んだコンセプトで造られたのではないかと思っています。例えば電線が地中化されて電柱がない、とか。 大きな特徴のひとつに、車の通行には許可証が必要という点があります。車はそのまま入れない。だから街の中を走っているのはスーパーやコンビニに商品を搬入するトラックとか、深夜のタクシーとか、せいぜいがそんなもんです。
子供たちは比較的小さな年齢の時から交通事故等を気にすることなく伸び伸び遊べますし、街に緑が多くて環境も良い。少々不便(地下鉄中央線が伸びてからはさほど不便は感じませんが)なことをのぞけば、僕は概ねこの街が気に入っています。

許可をとった車両しか入れないわけですから荷物運ぶときなんかは警察で許可をとるわけです。理由が「Googleストリートビューの撮影」だったら警察は許可を出すのでしょうか? もしくは住民に諮るのでしょうか?

理事会の議題に「Googleストリートビューの撮影の許可について」ってのがあがったらどういう結果になると思いますか?

私見ですけど、住民に諮るとしたら、住民の多くは反対しそうな気がします。 もし本当に住民の多くが反対するのだとしたら、(少なくとも生活道路における) Googleストリートビューって果たしてどうなの?

大阪市内なのにGoogleストーリービューの対象外の街に住んでいるからこそ、そんな風に考えてみました。

撮影の許可は住民が決定権を持っていて、拒否する事も出来る=プライバシーに関する自衛が可能)という街の作り自体が価値になる時代になるのかもしれません。南港ポートタウンのコンセプト考えた時代にそんなこと考えてなかったでしょうけど。


追記:
感覚としては、このくらい (外周道路は見えるけど街の中は見えない) がちょうど良いバランスだと感じるわけです。ただし南港ポートタウンのようにはっきりとわかりやすく境界が別れている場所は希有なので、要するに「可能なものはすべて」ではなく「どこまでやるか」の線を引くことを考えてみてはどうでしょうか。

カテゴリー: 駄文・雑文

アーカイブ(このブログの全てのエントリーの一覧)

最近のエントリー

このブログのフィードを取得
[フィードとは]