# 写真撮るの忘れた。今回はタイムキーパー役と受付の手伝いしてました。

レポートがまだ上がっていないので、とりあえずこちら(告知ページ)にリンク貼っておきます。

追記:
レポート上がってます。

キーノートスピーチ：Open Source CMSへの誘い

モデレーターの蒲生さんによる開催の趣旨等の説明。開催するに至った理由、OSSの定義とか。今回は僕も何度かMtgに参加したからもちろん内容についても聞いていたのですが、今回のイベントのユニークなところは単に開発者によるプロジェクトの紹介というのではなくて「ビジネスモデル」の話なんかも織り交ぜた話になっているところ。

余談ですが、蒲生さんに限らずモデレーターの皆さんの活発で真面目な議論には頭が下がる。隔週1回夜数時間、ずーーーっとやってるんですよ。忙しい方達が。いやほんまに驚きます(3次会で飲みながら和田さんに「何なんですか〜」とか話してたというより殆ど絡んでたみたいですね。失礼いたしました)。

おっと話がそれた。

第1部：Open PNEその魅力～「これはSNSになる」という発想～

1つめはSNSエンジンの「Open PNE」です。ええ、あのOpen PNE。手嶋屋の手嶋守社長による紹介。

ご自身で運営しているコミュニティの炎上頻発とmixiやgree等が普及し始めたことが開発のきっかけとのこと。フルタイムで約2名相当のリソースを割いて開発。

以前V1.0の時に少し触った事があるのですが、テンプレート数の多さとデザインのCSS化が出来ていないことでちょっとこれは...という印象を持っていましたが、これは既に現バージョンでは改良されてるみたい。

ビジネスモデルとしては「高速道路を無償で提供してレストランやガソリンスタンドで収益を上げる」「レシピを公開するレストラン」というたとえ話の通り、OSSビジネスのいわゆる王道的? なモデルのお話でした。とにかく、SNSというニーズがあってここまで普及すればコンサルティング等でも収益につながるということ。

個人的にはOpenPNEのテンプレート管理をMTOSでやったら面白いだろうなぁ、と思っていて、ちょっと久しぶりに見てみようと思った。

しかし、「少し後ろめたいようなテーマのSNS」が流行るってのは納得(少し笑った)。僕も僕の後ろめたい趣味(そんなのあんのか?)のSNSを作って流行らせようっと。

手嶋さんの温かい人柄(存じ上げないのですが)が感じられるやさしい語りクチが印象的でした。手嶋屋さんに入社するともれなく社員旅行で「フジロック」行けるそうです。当日も話が終わったら「今からフジロックです」とおっしゃってました。

第2部：EC-CUBE〜日本発のOpen Source ECサイト構築用プログラム〜

今回一番(良い意味で)期待を裏切ってくれた話でした。ロックオンの岩田社長によるEC-CUBEの紹介とEC-CUBEのビジネスモデル。僕の会社とある意味で似ていてある意味で違う。受託からはじめてSaaS事業やOSS事業、ASPとかにシフトしていきつつ、受託は残している点(でないと現場のニーズと離れてしまうし)、自社のサイトや製品のサイトを非常に丁寧に作られている点、「Impact On the World」という強いメッセージ、製品のネーミングとかサイトにちょっとしたユーモアがある(アドエビス)等、似ているというよりこれからウチが頑張って行きたいところをすごく丁寧に実践しているイメージを持ちましたね。同じく大阪だし。

すごく分かりやすくビジネスモデルを図解して説明していただきました。非常に戦略的な思考を持った人という印象も受けましたが、逆に言えば社長がこのくらいは考えてちゃんと説明できる会社でなければ伸びないよな、と思いましたよ。サイト見たら僕よりほぼ一回りも若い。これからも伸びて行くだろうな。

ウチはECサイトの受託はこれまでも(多分これからも)あまりやらないのですが、考え方等大いに参考になりました。ありがとう!

第3部：Web制作者に身近なCMS〜MODxの魅力を語る〜

実はウチの会社で最初にCMSを扱う必要があった時に最後まで検討のテーブルにのっかっていたのが、MTとTypo3とMODxなのです。当時からコンセプトの面白いCMSだなぁと思っていたのですが、Ajaxを活用した管理画面とTinyMCEを使ったWYSIWYGが印象的だった記憶があります。

あともう一つ、0.9.xになってからが長いなぁ〜という印象も持っていました。

MODxフォーラムJapanese Community(どこにリンクしたらいいかわからないな... MODx - Org wikiに張っておきます)モデレータの与刀招音(あとう しょうと)さんによるお話。

こちらは第1部、第2部とは違ってCMS自身の紹介がメイン。但し最初に開発者のライアンさんから貰ったコメントの紹介があって、オープンソースにした理由等も聞くことが出来ました。

テンプレート変数? がノンプログラマでも分かる、というあたり強調しておられましたが(あれが実際にノンプログラマでどうなんだろうという感想もありますが)、「思考を妨げない」「システムにあわせるために思考が止まってしまうのが嫌」というユーザーならではのことばがMODxの魅力を物語っていると思います。

ウチの会社では結局MTを選択してその後色々あって現在に至るわけですが、あの時MODxを選択しない理由が大きく2つあって、1つは(当日質問も出ていましたが)「静的ファイルが吐けない点(実際はプラグインで出来るとのこと。但し、当時僕らが調査した限りではMTでいうところのアーカイブマッピングの柔軟性がないように思えました)」もう1つは「ベータ版であるところの不安」でした。

MODxを取り扱うのであれば静的ファイルは自前で実装するか、とまじめに検討していたのですが、もしあのままMODxで走っていてMTやっていなかったら色々変わっているだろうなぁと思うとちょっぴり感慨深いものがありますが、こちらも久しぶりに触ってみたくなりました。1.0も出ないあたりから既にVer2系の開発が進んでいるとの事。

確かにあのツリー型のサイト管理とかDrag&Dropでの管理とか魅力的です。気になるのはサイトが大規模になってきた時のレスポンス低下(DBよりもむしろJavaScriptライブラリでの管理画面の処理速度の低下)ですかね。ちょっと気になっています。

全体としての感想:OSSのビジネスモデル

プログラマとしての自分、というよりも人間の本能なのか「良いものを作ってたくさんの人に使ってもらいたい」という気持ちが開発のモチベーションにつながって行くってのは当然あると思います。そしてどうしても本業が「スーツ」なのでこういう視点になってしまうわけですが、OSSのビジネスモデルについても今一度考えてみたいと思っています。ウチの場合は「パッケージビジネス」というものを昨年から始めたわけですが、次の仕掛けとして何かやってみたいというのは思っています。現状だとMT(MTOS)に関する何か、になる可能性が高そうですが、それに限らず今回の3つのプロジェクト等も少し触ってみて何かできる事があって面白そうと感じられたら何かするかも。

少し現状忙しすぎるから、まずは時間作らないといかんねぇ。

• 少なくとも俺の知ってる人間たちでいえばスーツとギークは融合しない - the cycles of activity

で、「ギーク」って何かっていうと、

• ギーク - Wikipedia

そもそも良い意味では使われなかったが、インターネットが注目されるようになると共に、コンピュータやインターネット技術に時間を費やし、深い知識を有する者もギークと呼ばれるようになった。現在ではけなす意味合いも薄れてきており、自称としても用いられている。

なるほど。たださ、ブロゴスフィアの言及における(上記エントリのような)「ギーク」って基本的に「出来る人」「肯定的な表現」指してるんだよね。で、そいつに「アルファ」がつくと「アルファギーク」となって、

「産業を変化させる力を持つ新しい技術に早いうちに飛びつき、ああでもないこうでもないといじくっているうちに、技術が進むべき方向性を示し始める、先鋭的で飽きっぽいエンジニア」(Tim O'Reillyの定義による)。

となるのだそうだ(またTim O'Reillyかよ!)。

えーっと、話を元に戻す。テーマは「スーツ対ギーク」か「スーツ対アルファギーク」か。後者だったらそりゃ噛み合ないよな。前者だったら、そりゃまぁ仕方ないだろうな。だって逆もあるもん。「アルファスーツ対ギーク」だったらそれも噛み合ないよ。スーツにだって「アルファ」ってのはあるんだからさ。

というのは実は前振りだったりするのですが、今日のネタはこれ!

• 見積もりが高いといわれたら。Noという交渉術 | Web担当者Forum

「はてブ」とかに脊髄反射するなよって最近良く怒られるのですが、一応。

• はてなブックマーク - 見積もりが高いといわれたら。Noという交渉術 | Web担当者Forum

「スーツ」とかひと言も書いてないですけど、まぁWebとかITとかの「営業」という目線でツッコミを入れるならば、

ですが需要からアプローチするSEO（正しくはSEM）も重要です。この重要性を2時間にわたり説いたのですが「まずは社名だけで」と押し切られました。そして納品したときには無意味と断じられました。

納品のときに話が変わっていることは多々あります。こんなときには「No」といいましょう。

のっけからすげぇな。僕が上司だったら怒鳴りつけてるだろうな。

2時間で何故切らなかったのか?

不条理な事を言われる事はあります、ええ。そして、時には「No」と言うことも必要です。それはわかる。

それでもこのケースであれば、最初の2時間の説明で「右!」って言ったのに「左!」って言われたわけで、それを受け入れた時点で既に半分負けてるじゃない。「左」で受けてきてる時点で制作現場無視してるよね。この場合は、その段階で「No」と言えなければならない。そりゃスタートがこれだもん、後で「やっぱり右!」って言い出しかねないよね。

お客様は神様なんかじゃない

いや、神様ですよ。普通に。逆に言えば「神様なんかじゃない」人を顧客にしないことです。そもそもこのケースでは、顧客も自分たちもハッピーになれてない。ただの愚痴じゃないの?

「失敗談」としておもしろおかしく書くのならそれはわかる。でもね、決して「交渉術」なんかじゃないですから! 良い子は真似しないように。

そして、先ほど引用した箇所ですが、再び引用。

納品のときに話が変わっていることは多々あります。

ないよ! 多々あるかよ。どんな営業だよ。

ええと(冷静に!)、ないですよ。多々あってたまるか。つまり、こんな営業の仕事やらなきゃならん時点で制作現場は不幸です。もちろん受発注時の擦り合わせってのもあります。Webとかやってる以上、少なくとも受託者側のWebサイトとか顧客が見て「こいつらは何をする会社やねん」ってのが明確に分かり理解いただいて発注貰ってることが前提なわけですよね。え、違うの? ならそこが間違ってるし。

プロセスって何さ?

先ほど「僕が上司だったら怒鳴りつけてるだろうな」と書きましたが、僕は決して顧客に「No」と言ったことをとやかく言っているのではありませんよ。

「納品のときに話が変わっている」のならば、プロセスの途中段階でそれを把握できない(どこで話が変わってるのかが見えない)営業は無能であって、その段階で「No」を言う言わないってのは本質ではないのです。

一体何のために打ち合わせたり中間レビューしたり、プロジェクト用のメーリングリスト立ち上げたりプロジェクト管理ソフト入れたりしてるわけ? 要所/勘所で顧客に確認もらってコンセンサスを形成しながら物事進めるのって基本じゃないの?

もう一度書くぞ。

納品のときに話が変わっていることは多々あります。

どの口が言う?

ということならよく理解できる。プロジェクトを進めながら顧客と適切なコミュニケーションを図って、軌道修正が必要ならそのあたりを調整して行く、ってのは普通の会社なら普通に教えられるよね。もちろん工期やコストの調整も含めて落としどころを探りつつ最終的には双方ハッピーになるのが大切だよね(普通じゃね?)。その辺がなくて納品のときに話が変わっていることは多々あるから、そんときゃ「No」と言えっての? すんげぇ、これがWeb2.0なのか(かなり驚きだよ)?

「不条理」を防ぐにも手はある。

この記事とは逆のケースかもしれないけれど、発注担当者とスムーズに進めてて、最終的に社長とか上長の「鶴の一声」でひっくり返るケースとかもあるよね。このあたりは経験している人も多いだろうよ。

でも、これだって防ぐ手はある。仕事スタートする時点で最終決済するのが得意先の社長だってのなら、仕事スタートする時点で「すいません、社長にちょっとだけごあいさつさせてください」ってな感じで最初にきちんと話しをさせてもらって、「危ないんじゃね!」って感じたら担当者に角が立たないように気遣いながらちょっと社長に報告入れておくとか、窓口はあくまでイチ担当者であっても重要なポイントでは「すいません、お手数おかけしますが社長にも一応念のためご確認いただいてください」といって抑えておくとかして、方針が変わるならいち早く察知して傷が膨らむ前に対策立てるってのが「普通の」営業ってもんだ。だから、繰り返すけど、 納品のときに話が変わっていることは多々あります。 って平気で言ってるような営業と仕事する制作の人はちょっと考えた方が良いと思うよ、いやほんまに。

なんだか久しぶりのエントリーで話まとまらなくて恐縮ですが、「スーツ」つまり「営業」にだって「アルファ」もあれば「ベータ」もあるし、それはギーク(と呼んでいる範囲が今イチわかってないけども)にもあるやんか。

まぁ、きっとこの記事はネタですよ。多分嫌な事があったんでしょう。だから、(良い子の皆さんは)「なるほど」とか「参考にする」とかタグ付けたりコメント付けたりしないように。

F's Garage：全国規模で見たスモールビジネスとしてのWeb屋のありかた

東京と大阪がほぼ 2 : 1
続いて、北海道・東北、九州・沖縄、東海がほぼ同数です。

ううむ。想定の範囲内? の数字ですね。圧倒的に東京が多い。

でね、これみて「やっぱ東京集中だよな、地方のマーケットは...」と考えた地方のWeb業界人はとっとと引っ越し準備を始めればいいのですが、ちょっと待って欲しい。

カラメルって東京の会社のサービスが北海道とか東北、九州(に限らず全国)のお客さんと取り引きしてるわけです。

おそらくこのサービスを使う際に北海道のお客さんが東京でカラメルの担当者と打合せしたわけじゃないだろうし逆にカラメルの担当者が北海道に営業に行って打合せしたわけでもないでしょう。まさにネット的なビジネスモデルがそこにある。

だったら別にその会社は北海道にあっても沖縄にあっても、はてまたインドにあってもいいわけです。

カラメルの運営会社はpaperboy&co、東京の会社といっても、沿革を見ると東京に本社移転したのは2004年、それまでは福岡。つまりはこういうサービスこそ地方のWeb屋さんのロールモデルのひとつなのではないかということ。

受託業界との事情の違いっていうのはあるわけですが、地方において「Web」というフィールドの技術云々をウリにしてどうやっていくか、ということを考える時に、こういう数字を見て「やぱり地方はマーケットが小さくて...」とか思ってるようではいかんよね、というお話でした。

* このあたりの件(地方とWeb業界ネタ)については近々また書くつもり。なのでこれは「予告編」ということで。

当日は僕の誕生日だったのでお祝いしてもらってこっぱずかしかったですよ(嬉しかったですよ。ありがとうございました)。

当時発表したものですが、こちらにて公開しました。WYSIWYGエディタのTinyMCEをMTのリッチテキストとして使えるようにするプラグインです。基本的にはウチの会社のF君の成果(曰く、胃が痛かったけど何とかやってみました、という仕事の成果)をプラグイン化したものです。

もうひとつ、画像のアップロードと管理を簡単にするSideBarImageのCSS微調整版もこちらにあげておきます。

• SidebarImage.zip(12KB)

小川さんの話を聞いて、英語ベースのコミュニティでも逃げてちゃいかんよな、ということを改めて思ったのと、小山さんの話が面白くも中途半端で言いたいことが一杯あった一日でした。

グループワークの時間はやっぱり短い。一日ガリガリコードを書いて夕方発表、くらいがちょうど良いような気がしました。僕は事前に大分準備してたので、それなりに発表とか出来ましたけど。

• CSS Nite shuffle

いやぁ、面白かったですよ。笑わせていただきました。切込隊長さんと住太陽さんで「Web衰退時代をどう楽しむか」とかやってるんだもん。

# そのまま飲みに行ったらもっと面白かったんだろうけど、ハードな一週間で疲れもピークだったのでとりあえず昨夜はそのまま宿へ直帰でした。

*トークの内容についてはここらへんで見てくださいね。

• F's Garage：Webが若干衰退気味かもしれない時にもっておくべき考え〜CSS nite Shuffle行った

要するにここは東京

トークの中でぶっちゃけ隊長の名指し発言とか住さんの過去とか、そんなのは大人だから僕は書かない :-p

会場における数少ない大阪人的な感想として、第一にあげておきたいのは『あぁ、ここは東京で「ど真ん中」な業界の話でもって「衰退」ってのを語ってるんだなぁ』ということだ。地方零細のWeb業界人としては (一応東京には出てるけど) 霞のようなものを食って生きているわけで、正直この部分の衰退を語られても関係ないなぁというのが前提。但し、田舎のひがみとかでは全然なくて、「大手クライアント→広告代理店→業界」って流れがやはり東京のマーケットの構造の大きな部分を占めているのであって、衰退も何も (トークの中にもあったけど) 効果があるかないかわからんし検証も出来ないものを何となく提案して好きな仕事やって金貰ってたツケが回ってきてるんだ、東京では。

大阪とか名古屋では

何でこんなことを第一に思ったかというと、週の前半は大阪・名古屋のCSS Nite(日、月曜)行ってたわけで、そのギャップがすごくて面白かった(っていっちゃ怒られると思うが)から。

「名古屋(大阪)の大手クライアントが東京に発注投げて名古屋(大阪)で下請けやってる」とか「仕事がない」「予算がない」とか、おまけに「元気がない」とか。

# しかし参加人数が違うとはいえ、東京開催との反響とかフィードバックとの数の差はどうだ?

で、木曜日あたりに某所でのMtgで話していたことにも絡むんですが、「地方格差」みたいなことを言うわけです、地方の人は。ところがところが、衰退の時代、変化の時代には地方だろうが何だろうがチャンスはごろごろ転がっていて、例えば以下の住さんのエントリーにある「供給過剰と業界の成熟から単価が下落し続けている」「CMSや外国人の労働力が、一層単価を引き下げる」とかに注目してみると...

• そろそろWeb制作業界の成長も頭打ちか | 住 太陽のブログ

CMSや外国人の労働力が、一層単価を引き下げる

面白いのは「地方」では「格差」で「国際」になると「競争」になるんだな(もちろん国際的な地域格差ということも当然あるのだが、この手の話の中では「国際競争」とか「グローバル化」という話になる)。

「地方競争」という言葉はあまり聞かんのだよな。大阪と名古屋で東京のマーケットの仕事を奪う、とか聞かないものね。単価が下がったら物価の低い地域の方が有利だったりしないか? CMSが単価を引き下げるのなら、格安のCMSをマーケットに投入してもっともっと単価を下げてやって、成熟した? 東京の競合から仕事奪ってやるとかそんなこと言う人がもっと出てくると面白いと思うんだけど。

供給過剰と業界の成熟から単価が下落し続けている

そうなの? 業界が成熟しているとはどうにも思えなかったりするな。実感がない。一例だけど例えば「Webディレクター至上主義」的な考え方とかに違和感があるんですよ。

• ウェブ業界はどこを向いているのか、は知らんのだけれど。 (Junnama Online (Mirror))

発注側は確実に変化していて、事業に本気なところ程社内にそういった部門をツクり、組織化しようとしているように感じます (そういったクライアントと仕事をすることが増えています)。

これは即ち「制作会社の人間にそんなものを期待しない」という流れです。そうなった時に、クライアントが制作会社、制作プロダクションに求めるものは何でしょうか? 大した力もなくクライアントの担当者程本気でもない上流工程の『知識集約型』人材でふくれあがってコスト競争力の無くなった制作会社を切る * ことか、数少ないウェブ業界の『知識集約型』仕事をこなせる人材を引き抜くかです。

* そのかわりに (例えば) クライアント自身の立てた事業戦略をスムーズに理解し下流工程までをカバーできてコスト競争力も高い発注先をピンポイントで新たに見つけるのです。

人材が引退しない業界

この業界に限らないのだけれど、新しい業界には (若いのは流入してくるけど)「人材が引退しない」という構造的な欠陥(?) があって、元々ディレクターってのはそこから生まれたポジションではないかと思っているのです。

どういうことかというと、大きな会社(というより、社歴の長い会社)なら定年でリタイアする人がいて新入社員が入って来てという流れがあって、その中で会社の成長を描いていけばいいわけです。新陳代謝ってやつですね。ところがこの業界、せいぜいが僕と同世代とか少し上の人が上の世代。まだリタイア出来ないししたくもないよね。

単価が右肩あがりであれば、現場そのままやっていって成り立つわけですが制作単価はむしろ低下していく(若い人の成長も速い。高速道路もあるし :-p )。であれば「ツクルより人やカネを動かす仕事をやれ」(高木さんの話にあったような)ということになって、そこからディレクターというポジショニングが出てくる。

でもね、それってクライアントの都合じゃなくて制作者の都合で生まれて来たポジションなんですよ。より効率よく「人やカネを動かす仕事をやれ(そういう組織をつくれ)」、いいかえれば「中間管理職を設けて、より多くの金を生み出せるようにする」ということ。

それこそマーケットが拡大するか会社が成長するから成立する考えだと思うんですよ。リタイアする人がいなかったら「人が成長し、上に立って複数の人を抱えて仕事をハンドリングしていく」ってのはすぐにポストの不足を招くじゃない。ポストを不足させないためには一定のスピードで成長することが前提になるのです。

現実問題として、大きくならない会社で人材の入れ替わりがなかったら5年後には平均年齢が5歳上昇しているということだし、普通の会社だったら人件費コストが上昇して価格を上げないと辛くなってくる。

では、どうするか

これは東京も地方も変わらんと思うのですね。だから「衰退」や「格差」といって悲観する必要は全然ないのですね。東京が特別上手くやってるわけじゃないし、まだまだ成熟なんてしていないと僕は思うのです。そして「変化」と「チャンス」は必ずセットです。

では、どうするか...なんだけど、ここでは書かない(そのうち書くかもしれないけど、自分で考えるべきことだ)。書かないけど僕は考えてるつもりだし、社員に聞かれたらちゃんと答えてる(というか聞かれてなくても喋ってるかな)。

「衰退」つまり何も考えていないところはもたない。だから、業界で働いている人は社長に聞いてみたらいいと思う(フリーランスの人やトップの人は自問すれば良いし)。「Web衰退時代をどう乗り切っていきますのか?」って。納得できる答えが返ってこなかったら...身の振り方を考えた方がいいかもしれないと思うよ。

# 取り敢えず池○のヘ○スにでも言って恋愛小説(官能小説?)書くための取材からでも始めてみよう w (←当日会場にいた人向けのネタですよ)

実際問題、これはどうしようもないと思います。MT3→MT4で管理画面カスタマイズ系のプラグインの多くがそのままでは動かなくなったことは記憶に新しいと思うわけですが、それでも「壊れにくい」「修正対応しやすい」カスタマイズの方法とか注意点とかがそれなりにあるのでそのあたりを少しご紹介します。

可能な限りプラグインで拡張可能なアクション、ウィジェット、メニュー等として登録するように

例えばボタンひとつ追加、とかの場合は以下のようにMTのプラグインによって拡張する方法が提供されているので、基本的にバージョンアップ時にもそのまま使えます。実際list_actions, page_actionsはMT3系の時も提供されていました。ただ、メジャーバージョンアップの時に仕組み自体が変更になるかならないかはわかりません(menu等はMT4で導入されているし、その辺のしくみが変更になる可能性はないとはいえません*)。

* ただ、これまでの流れを見る限りMTの場合移行の際の互換性には最大限の気配りがされているので、少なくともバージョン一つアップして使えないってことは考えにくいと思います。

プラグインアクション(list)

sub init_registry {
    my $plugin = shift;
    $plugin->registry({
        applications => {
            cms => {
                list_actions =>

プラグインアクション(page)

sub init_registry {
    my $plugin = shift;
    $plugin->registry({
        applications => {
            cms => {
                page_actions =>

メニュー(dialog)

    my $plugin = shift;
    $plugin->registry({
        applications => {
            cms => {
                menus => {
                    'create:ui_sample_dialog' => {
                        dialog => 'foo',

メニュー(mode)

sub init_registry {
    my $plugin = shift;
    $plugin->registry({
        applications => {
            cms => {
                menus => {
                    'create:ui_sample_mode' => {
                        mode => 'foo',

ダッシュボード(widget)

sub init_registry {
    my $plugin = shift;
    $plugin->registry({
        widgets => {
            my_widgets => {
                label    => 'My Widget',

カスタムインポートフォーマット

sub init_registry {
    my $plugin = shift;
    $plugin->registry({
        'import_formats' => {
            'import_ctsv' => {
                label => 'CSV or Tab-Separated Values',

クイックフィルタ

sub init_registry {
    my $plugin = shift;
    $plugin->registry({
        applications => {
            cms => {
                list_filters   => {
                    entry => {
                        next_approval => {
                            label => 'Next revision awaiting approval',
                            order   => 1000,
                            handler => sub {
                                my ( $terms, $args ) = @_;
                                $terms->{next_status} = 6;
                            },
                        },

template_paramコールバックのDOMScriptingで拡張する

template_param, template_source, template_output コールバックで管理画面に変更を加えるときは正規表現でソース等を書き換えるよりもtemplate_paramコールバックのDOMScriptingで拡張するほうが(比較的)壊れにくい。正規表現で置換とかやらないと実現出来ないケースも多いとは思うけれど、その場合でもソースの書き換えは最小限ので済ませ、template_paramで値をセットしたり書き換える箇所が後から変更になっても柔軟に対応出来るようにalt-tmplと組み合わせる(テンプレートにソースを挿入するポイントにコメントを入れるとか)等、工夫次第でメンテナンス性の高いカスタマイズとすることもできるでしょう。

BlogBody, BlogMore, BlogKeyword, BlogExcerptフィールドを追加する例

sub init_registry {
    my $plugin = shift;
    $plugin->registry({
        object_types => {
            'blog' => {
                'text' => 'text',
                'keywords' => 'text',
                'text_more' => 'text',
                'excerpt' => 'text',
            },
        },
        callbacks => {
            'MT::App::CMS::template_param.cfg_prefs'
                => ¥&_blog_extras_param,
        },
   });
}

sub _blog_extras_param {
    my ($cb, $app, $param, $tmpl) = @_;
    my $pointer_field = $tmpl->getElementById('description');
    my $nodeset = $tmpl->createElement('app:setting', { id => 'keywords', label => $plugin->translate('Keywords') , required => 0 });
    my $innerHTML = '<div class="textarea-wrapper"><textarea name="keywords" id="keywords" class="full-width short" cols="" rows=""><mt:var name="keywords" escape_html="1"></textarea></div>';
    $nodeset->innerHTML($innerHTML);
    $tmpl->insertAfter($nodeset, $pointer_field);
    $nodeset = $tmpl->createElement('app:setting', { id => 'excerpt', label => $plugin->translate('Excerpt') , required => 0 });
    $innerHTML = '<div class="textarea-wrapper"><textarea name="excerpt" id="excerpt" class="full-width short" cols="" rows=""><mt:var name="excerpt" escape_html="1"></textarea></div>';
    $nodeset->innerHTML($innerHTML);
    $tmpl->insertAfter($nodeset, $pointer_field);
    $nodeset = $tmpl->createElement('app:setting', { id => 'text_more', label => $plugin->translate('Extended Page') , required => 0 });
    $innerHTML = '<div class="textarea-wrapper"><textarea name="text_more" id="text_more" class="full-width short" cols="" rows=""><mt:var name="text_more" escape_html="1"></textarea></div>';
    $nodeset->innerHTML($innerHTML);
    $tmpl->insertAfter($nodeset, $pointer_field);
    $nodeset = $tmpl->createElement('app:setting', { id => 'text', label => $plugin->translate('Text') , required => 0 });
    $innerHTML = '<div class="textarea-wrapper"><textarea name="text" style="height:150px" id="text" class="full-width short" cols="" rows=""><mt:var name="text" escape_html="1"></textarea></div>';
    $nodeset->innerHTML($innerHTML);
    $tmpl->insertAfter($nodeset, $pointer_field);
}

alt-tmplの書き換えでは追加・変更箇所をできるだけ外部ファイルとしてインクルードする

alt-tmplにコピーを置いて直接手を入れる場合は「テンプレートの見通しを良くする」「変更箇所がわかりやすいようにする」というオーソドックスな考え方でメンテナンス性向上とバージョンアップ時の対応コストを下げることができるでしょう。

例えば以下のようにして変更箇所をインクルードファイルにしておけばバージョンアップの際にそのまま使えるかもしれない(CSSとかid/class名の変更くらいは必要かもしれないけれど)。

<mt:include name="include/edit_entry_extra.tmpl" id="edit_entry_extra">

テンプレートの変更箇所にコメントを入れる

お約束ということで。

<mt:ignore>======拡張フィールドの追加======</mt:ignore>
<mt:include name="include/edit_entry_extra.tmpl" id="edit_entry_extra">

なんででしょうね? いや、部外者の僕にわかる筈もないのですが。

• MarkeZine：◎間違いだらけの「SEO批判」～なぜSEOは嫌われるのか？

1. 相手の会社のことも調べないで電話で営業してくるから(制作会社に...)
2. 御社にはノウハウがないでしょうから我が社のパートナーになりませんか、とか言ってくるから

というのは半分は冗談だけど(いや、半分と書いたのは実際にそういう営業が結構あるので)。

「なぜSEOは嫌われるのか？」と言っているということは、嫌われてる自覚があるわけですよね、きっと。

もし（1）から（4）のすべてが正しいと納得がいく方は、論理的思考に向いていないと思うべきである。

おいちょっと待てw 何このあげ足取りのような表現。検索ユーザーAさんのケース、サイトオーナーBさんのケース、SOHOビギナーCさんのケース、ブロガーDさんのケースって書いてあるわけで同一人物が言っているわけじゃないんでしょう? すべて正しいかどうかはともかく、(1)も(2)も(3)も(4)もありがちなことだよね。うん、あるあるって(笑)。

という人は論理的思考に向いていないって...で、結びがこれ?

W3C勧告とか論理構造とかWeb標準とか

昔の記事の再掲載ですかこれ。もはや(X)HTMLの構造をいぢくりまわしたところで効果がどれほどあるのか疑わしいと思うのは僕だけか?

追記(強調は筆者):

Internet ExplorerやFirefox、Safariでほぼ同じに表示されないページ、見出しや段落、リストで構造化されていないコンテンツは、どんなに内容が深くても、良いとは言えないのである。

ブラウザ毎にほぼ同じに表示されること? が良いコンテンツの条件だって?

このブログとかウチの会社のサイトのページランクが上がった経緯

もはやページランクがどうって話じゃないと言われているみたいだし僕も別にGoogleのランクを上げることに腐心しているわけじゃないのだが、最近ページランクがひとつ上がりました。

で、これはSEOとか気にした結果でもW3C勧告とか論理構造とかWeb標準とかを気にして「最適化」を図った結果でもないのです。

ランクが上がった理由はだいたい分かっているのです(この「だいたい」ってのが結構重要で、アクセス解析とかもそうだけど、サイトの運営や方向性を考える時には「木を見て森を見ず」にならないよう、限られたリソースと時間を割いてあまり細かなところを見過ぎないってのも大切かと思うのですね)。細かな数字の分析もそりゃ余裕があればやれば良いですが、大きなところを見て、あとはさっさと手を打っていくことが大切かと。

えー、ランクが上がった理由は、ひと言でいえば被リンクが増えたからでしょう。これもノウハウとか言う程のもんでもなくて、ちょっとでも検索エンジン/SEO(←SEO言うな)に興味のある方なら知っていることですよね。

では、どうやって?

• ブログに数多くエントリを上げた。で、時々SBM等で炎上した。

違! (違わない?) いや、でもエントリを数多く上げたのは事実で、それは去年の4月くらいに「ちょっと(ほぼ)毎日書いてみようか」と思って意図的にやってみたのだ。

それはまぁそうとして、他には...

1. サイトのデザインと内容をリニューアルした。但し特にSEOとか気にしてリニューアルしていない。事業の方向性が少しずつ変わって来たので(また、これからこっちにシフトしていくよ、という部分を反映して)それにあわせて再構築したということ。
2. 会社のサイトにちょっとしたプログラムを置いたりウェブサービスを作ったりした(このゲートウェイはいくつかのサイトの運営者の方から自分のサイトにリンクつけていいですか? といった問合せをいただいたりして、そこで紹介していただいたり)。
3. セミナー(セミナーなのかどうかわからんのですがこれとか)とかイベント(これとか(大阪も))呼ばれたものは出来るだけ参加して、呼ばれなくても自分で出たり(これとか)。
4. はじめて製品というものを作って、プレスリリース代行サービスを利用して投げ込みをしたり(利用したのはこちらの会社さん。他にもいくつかあって、特にどうしてもこの会社っていうポイントは見つからなかったけど、きちんとサイトが作られている印象だったので)。
5. シックス・アパートさんのProNet Japan (拠点登録ってのもしたので大阪も) への加盟とかAcc04(2006 - 既にページがないみたいだけど)の協賛とかWeb制作者年鑑への登録 (リンクは稼げてないけど) とか、普通に販促に少しばかりのコストをかけたということ。
6. アワードにエントリー。2006年は小口の協賛だったけど、今年は応募者として参加(入賞)(エントリーには費用がかかったけど、大した値段じゃないし、そういうコストをきちんと払うということを行った)。

結局、意図的にお金を払って被リンクを増やそうとして行ったのは 4.のプレスリリースくらい(この4にしても、被リンクというより単なるリリースだし、5.はまぁそれにあたるかもしれないけれど、リンクが目的ではないし、6.は入賞しなきゃどうにもならんかったわけで)。

1.のリニューアルにしても、こういう会社(制作会社)だからWeb標準とか丁寧にコーディングすることは前提なわけですが、考えていたのはビジュアルをがらっと変えることによるブランディング(主に人材採用面を考えて)と、事業の再構築、実態にあわせた内容の見直しというもので、キーワードがどうとかたいして考えちゃいなかったのです(サイトに「SEO」という言葉が消えていた、というのも本当に後から検索して気づいた)。

ウチはネットショップでもないし、業種とか仕事の実態次第ではもっともっとSEOとか言わなきゃならんこともあるのでしょうけど、結局SEOっていってもこうした施策(普通に事業活動とか広報活動ともいう)を行った結果起こること(被リンクの増加、特定キーワードへの最適化)をトレースしているだけであって、費用(コストだけじゃなく手間とか社内のリソースを使うことも含む)かけ方として、SEO会社に依頼するのがいいのか、経営の中で考えて適切な施策を打つのが良いのかは、それぞれが判断すればいいことじゃない? と思うわけですが。

ちなみに、プレスリリース代行会社に払ったコストは5万円もかかってませんし、もちろん製品の開発やウェブサービス、サイトリニューアルは内製とはいえ無料なわけじゃないのですが、継続してかかるコストもほとんどなかった、というのが現実です。

だから、SEOってのは経営であり広報であり事業活動であって、一般的に言われるSEO技術やテクニックってのはあくまでもそれによって起こる事象をなぞる技術なんではないでしょうか(だから事業活動が伴わずに事象だけがなぞられると嫌われる、ということじゃないでしょうかね)。

SEO生業にしている人が本当に怖いのは「◎間違いだらけの「SEO批判」～なぜSEOは嫌われるのか？」で書かれているような「批判」じゃなくて「検索エンジンに嫌われる」ことだと思うわけですが、嫌われないか気にしながらやる商売ってのもあんまり精神に宜しくない商売じゃないかと思うわけで、僕はやりたくないなぁ。

結論

結論は、ありません。いや、強いて言うなら僕の会社ではSEOはやりません。経営の戦略に沿って、どのようにアウトプットしていけばいいか、その中でウェブをどう活用していけばいいかについての提案やそのための仕組みづくりや戦略の遂行はサポートします。SEOはやりません。

追記：何か以前にも同じようなこと書いてたな。

• 第1回　Perlの文法の基本：ITpro

何か古い記事が再掲載されてるということであれこれツッコミが入ってますね。

• ベアワードのファイルハンドルをつかわない方がいい理由 - TokuLog 改めChumbyとどきました日記
• 404 Blog Not Found:perl -　勝手に添削 - Perl入門#1@ITPro
• Perl 2008年のファイルオープン - てっく煮ブログ

ベアワードのファイルハンドルはグローバルということですね。とはいえ、Googleとかで調べると実際出てくるのは比較的古いものが多いようで。

• Perl ファイル - Google 検索

Movable Type(4.1)はどうしているんだろうと思って覗いてみたらみたらこんなコードが(App:CMSのcreate_dashboard_stats_file部分)。

    local *FOUT;
    if ( !open( FOUT, ">$file" ) ) {
        return;
    }

「local *FOUT;」とな。で、まぁそれは本題ではなくて、MTの場合はFileMgrを使うということなんだろうな。

use lib $ENV{MT_HOME} ? "$ENV{MT_HOME}/lib" : 'lib';

use MT;
use MT::FileMgr;

my $src    = 'Hello FileMgr!';
my $updata = 'Hello FileMgr! (Updated)';
my $out    = 'hello.txt';
my $put    = 'put.txt';
my $rename = 'rename.txt';
my $dir    = 'directory';

$out       = File::Spec->catdir( $dir, $out );
$put       = File::Spec->catdir( $dir, $put );
$rename    = File::Spec->catdir( $dir, $rename );

my $fmgr = MT::FileMgr->new( 'Local' ) or die MT::FileMgr->errstr;

print $fmgr->mkpath( $dir );

# directoryを作成する (成功した場合「1」)

print "¥n";

print $fmgr->exists( $dir );

# directoryが存在するか (存在する場合「1」)

print "¥n";

print $fmgr->can_write( $dir );

# directoryが書き込み可能か (書き込み可能な場合「1」)

print "¥n";

print $fmgr->put_data( $src, $out );

# directory/hello.txt に 'Hello FileMgr!' を書き込む (戻り値はバイト数)

print "¥n";

print $fmgr->put( $out , $put );

# directory/put.txt に hello.txt の中身を書き込む (戻り値はバイト数)

print "¥n";

print $fmgr->content_is_updated( $out, ¥$updata );

# directory/out.txt の中身(Hello FileMgr!)と $updata(Hello FileMgr! (Updated)) を比較する (値が異なる場合「1」)

print "¥n";

print $fmgr->rename( $put, $rename );

# directory/put.txt を directory/rename.txt にリネームする (成功した場合「1」)

print "¥n";

print $fmgr->get_data( $rename );

# directory/rename.txt の内容をprintする

実行結果

1
1
1
14
14
1
1
Hello FileMgr!

MT::FileMgr->new( 'Local' ) のところ、 MT::FileMgr->new( 'FTP',@args ) (@argsにFTPホスト、ログイン名、パスワードを入れる)とFTPサーバー上のファイル読み書きができる(らしい。そうなんだ...知らなかった)。

参考:

• Movable Type オブジェクト・リファレンス - MT::FileMgr

2回目? で既に恒例となった感のある討論会ですね。あんまり真面目に読んでないのですが「10年は泥のように」って言葉が話題のようで。

誰も「我が社に入った人は...」とか言ってるんじゃないんだと思うのだけど、「入社して最初の10年は泥のように働いてもらい、次の10年は徹底的に勉強してもらう」という言葉は会社が20年後も同じくそこに存在していることを前提にした言葉だよね。

もちろん「転職とか会社が存続しなくなって別の会社にいるか独立してるか別にして、10年は...」という意味にもとれなくはないけれど。

ひとつ言えるのは「10年後、その会社、その業種が同じ姿でそこにある時代ではない」ということ。10年後、20年後を考えるのは無駄なことじゃないけど、モノゴゴロ付いて20年も経っていない若い時期に10年20年後を考える必要もない。せいぜいが5年。5年経てば (会社は存続しているまでも) 勢力図は全く変わっているかもしれない。それはどこの業界に行っても同じ。

だからその5年は会社のために働くのではなくて、「自分のために *」仕事の基礎体力をつける時期くらいではないか?

* 勘違いして欲しくないのだけれど、自分のためってのはもちろん「会社で与えられた役割、課せられた責任を果たすことを通じて」ってこと。自分勝手に自己の利益のために働けってことじゃない。

もし初めて働く(働こうとする)会社で20年、30年間スパンのキャリアパスや働き方の話をされたら、ひいちゃっていいと思うよ。だって何の保証もないんだから。僕なら「5年後 (3年後) 会社がなくなってても困らない仕事力をつけろ」くらいに言ってるけどな (実際いつも言ってるな)。

もちろん、会社の規模も歴史も全然違うわけだけど、既に「会社が大きいから安泰」なんて時代じゃないのだと思う。

そして、一方で「個々人の突出したスキル」で勝負したいのであれば、10年、20年を睨んでこんなキャリアパスなんですよ、ってな場所を選ぶのが間違っているのであって「本当に自分が売れると思う人は、そういう個々人のスキルが最大限に生かせる企業に行くといい」というのは全く持ってその通り。そういうところでは、10年20年30年なんてレールがそもそも存在しないのだから、10年後20年後どうなっているかは自分が切り拓いた結果次第 (会社が存続しているかどうかだけではなくて収入とかも結果によって大きく変わる *)。そして、その場合の会社選びは「この人たちと一緒に切り拓いて行きたいかどうか」という視点で選ぶといいのではないかな。

* そのかわりその時になって結果が良くなかったとしても「大手はボーナスが良くていいよな...」とか言うなよ。大きなリターンが得られるチャンスもあるわけだから。

Movable TypeをEnterprise CMS的に使う場合に、生成されるファイルの取り扱いに注意が必要。エントリーの削除、非公開の際には静的生成されたファイルは削除されるけれども、例えば以下のような場合に静的に生成されたファイルが残ってしまう (場合によっては残したくないファイルが残ってしまい、意図しないファイルが検索にひっかかってしまったりする (ここでは「ゴミ」と呼ぶ) )。

1. テンプレートが削除された時
2. ブログの公開パスが変更された時
3. カテゴリーのベースネームが変更された時(且つカテゴリーアーカイブ (カテゴリー - 日付別) が指定されていてベースネームがアーカイブマッピングに含まれていた時)
4. カテゴリーが削除された時(且つカテゴリーアーカイブ (カテゴリー - 日付別) が指定されていていた時)削除されるようです。すいません。
5. 特定のエントリーを削除または非公開にしたことによって、特定の日付アーカイブにエントリーが存在しなくなった時
6. ユーザーが削除された時 (且つユーザーベースのアーカイブが指定されていた時)
7. ユーザーのdisplay-nameが変更になった時 (且つユーザーベースのアーカイブマッピングにdisplay-nameが含まれていた時)

* 最新版のMTOSではどうなるか試していない。

これらの各タイミングで、静的に構築されたファイルを削除し、再度再構築を行うことで(ゴミが残らずに)正常なファイル構成となるよね。

面倒なのは「5 (特定のエントリーを削除または非公開にしたことによって、特定の日付アーカイブにエントリーが存在しなくなった時)」だろうな。その他は何とかなるだろう。

むしろ、ステージングサーバー上でファイルを生成して、そのファイルを公開サーバーへ反映させているような運用の場合は、fileinfoテーブルを元に一旦生成されたファイルをクリーンアップしてしまって再構築し直した方がはやいかもしれない。ということで、今からちょっとだけ書く (かも)。

ちょっと書きかけ段階でメモ追記:

まとめて削除するならば、 fileinfoテーブルもどきを作って構築日時を記録するようにしておいてから、

• template,category,entry,authorのidが既に存在しないもの(blogは除外して考える) は削除対象
• 何らかのオブジェクトを修正した後、全再構築をかけて、(DB上の)構築日時が更新されていないもの (Indexアーカイブは除く)は削除対象
• Indexアーカイブは、再構築直後に同じテンプレートIDの他のアーカイブを削除

でいけるか...な? だんだん混乱してきたよ。最初はfileinfo見て処理しようと思っていたけど、エントリーアーカイブのマッピングを修正した時なんからは重複するfileinfoレコードを丸めて? しまうから削除すべきファイルのチェックには使えないので。

ウチのスタッフに良く「ブログを書けよ」っていうんだけど書いてるのは数人。

「書くこと無いですよ」とか「書く時間無いんですよ」とか言うし。

ひとつはコスト(書く労力) の問題。これは改善すれば宜しい。それが我々の仕事でもあるんだから、現在のブログシステムにブログを書くコストが馬鹿にならないのだとしたら考えればいいのだ。

もうひとつは「書く意味」と「テーマ」の問題。書く意味はつまりアウトプットの意味なんだけど、これが見つけられず意味を見いだせないのもちょっと違うかなぁ、職業的にさ。

ウチの会社のクライアントはすべてアウトプットの意味を考えに考えて発注してくるんだし、個人と会社と仕事とは違うってのもそりゃそうかもしれんが、たまにはそのあたり真面目に考えてみるといいと思うな。

あと、携帯もそうだ。ウェブの制作者である前に、やはり何かを買う立場とかウェブやテクノロジーやユーザーが触れるものの立場に立つことを忘れてはいかんと思う。

で、タイトルのことだけど、ふと思った。

ブログにエントリーポストするインターフェイスもそうなんだけど、例えば毎日ブログを書くということを「一日の終わりに世の中に向けてメールを1通書く。」くらいの感覚にして書いてみて、それでどんな変化が自分の周りと自分自身に起こるのか、っていう体験を観察する、くらいの軽い感覚でやってみてはどうだろう。

メールの何通かくらいは毎日書くだろうし、メール一通書くのにそんなにエネルギー割かないよね。

ということで、↓これでも仕込んで、

• 携帯からMTにメールで投稿するMoblogプラグイン「Moober」。

この程度でも構わないので↓書いてみたら? (あ、まだベータのままだった。入れ替えないと)

• Junnama.com