2007年2月アーカイブ

アンチ東京。Macユーザー。まぁとにかく、マイノリティでありアンチであることは楽しいのだ。

とにかく「Web2.0言うな」キャンペーン? は成功した。職場の風景写真、特に可愛い女の子が笑顔で「私と一緒に働きませんか?」とか訴えかける広告は死んでも出したくなかった。

何を求めて会社を選ぶのだ? くだらない。(関西から江戸へモノが流れることを「下る」といい、江戸へ持って行っても売れないモノを「くだらない」といった)

とにかく、「大手の実績の豊富なWeb専業プロダクションに負けない品質を、彼らよりはコストも含めてパフォーマンスよく提供できる」から仕事が途絶えないし、ウチの会社の「格」や「規模」とかを考えると「考えられない」顧客とお付き合いさせていただいているこの状況は...、

「楽しい」。このひとことにつきる。

こんにちは! Macです。

| コメント(0) | トラックバック(0)

「最近ホームページ作ったんだ。」
「ちなみに作業工程は?」

  • Step1「デザインする。デザインを選んでテンプレート化する。」
  • Step2「データをスプレッドシードでリスト化する。」
  • Step3「...CMSにデータをインポートして「再構築」ボタンをクリックするくらいかな。」
  • Step4「おしまい」
  • Step4は〜...!
    「確認をする。当社は簡単なんだ。終わったら、生ビールを飲む。」

こんな感じ...が理想。近いような遠いような、だけど。近づいては来ているな。

メモ程度の内容だが、ちょっと仕事(会社)について考えているところを書く。

売上が年々増えて行き、人数も増え規模も大きくなっていくことを目指すのではなく、規模は必要以上に大きくせずあらゆる面で実力・効率を向上させることを目指す。
そのためには「品質のさらなる向上とワークフローの改善、人材育成」がその"キモ"になる。

ビジュアル表現のクリエイティブ、Webアクセシビリティ、Web標準等当初からこだわって来たクオリティのコア部分について全員が同じ目線を持ち、同一レベルのクオリティ基準について意識を共有することが大切。新しいスタッフもいるので、まずはここを普段の仕事や教育を通じて取り組む。

当社は「受託制作」中心であるため、会社が大きくなり人数が増えポジションがあがり、職域や責任が増えて給料も増えるという流れをつくるのでなければ(あくまでも「良いものを創る現場に居続けたい」のであれば)、選択肢は多くない。

  • クオリティレベルを上げて顧客の評価を向上させ、相応しい報償を得る(対価を上げていく)
  • 難易度が高いあるいは専門的領域であり付加価値の高い仕事にシフトしていく
  • ワークフローの改良と技術力の向上により生産性をあげる

これまでにも設立当初から実績を積み重ねて来た電子展示会(ギャラリー、デジタルアーカイブ関連制作案件)の制作ノウハウ化、MovableTypeをベースにした高機能CMSの開発、大学等の教育機関向けのWebシステムの開発等を進めて来た。教育・各自のスキルアップについても積極的に進めていると思う。そしてチームプレーによって各自が自身のスキル以上のものを他人の力を借りながらつくりあげていく姿勢・制作スタイルを今後も徹底していく。

もちろん小さいとはいってもある程度の規模は必要だし(むしろ去年より少し人数が減った)もう少し人手が欲しいのは事実だが、規模は殆ど変わっていないものの事実数字は伸びているし、もっと「強い」会社を目指して今後も走って行きたいと思う。

初めてプログラムを書いたのはいつ? って聞かれて、いつだろうと思ってたら、恥ずかしい? 昔の記憶にひっかかった。まだ10年も経たないのだね。
以前のエントリ。

証明書の警告

こんなのが「日本のWeb2.0」だってんなら...もういいやって感じかな。

# もう少しレベル上げろよ。

Web標準準拠サービスで検索してみる。

  • Web標準準拠サービス の検索結果 約 952,000 件

何だかここ数年で増えたなと思う。JIS X 8341-3の影響なのかウェブアクセシビリティへの関心の高まりという面もあるしSEOという側面もあるのだと思う。しかし制作会社がこれをメニューとして掲げることがどの程度ビジネスに繋がるのだろうか。

これらのサイトを見ていると、多くのサイトが以下のような説明をしている。

  1. XHTMLとCSSで文書構造とデザインを分離する
  2. アクセシビリティが向上する
  3. ファイルサイズが小さくなりサーバースペースと帯域を食わないようになる
  4. ページの読み込みとレンダリングの高速化
  5. メンテナンス性の向上
  6. SEO効果

1番目はメリットというより「何をするか」の説明である。
2〜6は確かにメリットとしてそういう面もあるかもしれないが、どうなんだろう。「アクセシビリティ」については、見出しをきちんとマークアップすることで音声ブラウザ等の使い勝手は向上するが、Web標準イコールアクセシビリティ向上とは言えないのではないか。仕様に準拠すること以外にやることはたくさんあるはずだし。
3,4はメリットとしてはいかにも弱い。容量の数キロバイトの節約より大切なものは沢山あるというクライアントは多いだろう。
最近の高性能なPCと優れたレンダリングエンジンは、フルCSSのレイアウトも複雑なテーブルレウアウトも「その差がわからない程高速に」レンダリングしてくれるだろう。

「6.SEO効果」はもはや効果があることすら疑わしい。もちろん意味が無いとは言わないが、コンテンツの価値(=順位)は仕様への準拠度で変わるものではない。

何がいいたいかと言うと、「制作者の自己満足でサービスを企画しているだけではないのか」ということを感じずにはいられないのだ。

「私たちはこんなことが出来ます」といっているだけで、クライアントにきちんとその効用を伝えられているところ、またそのメリットをクライアントの利益につなげることができるところはまだまだ少ないのではないだろうか。

その点では「5.メンテナンス性の向上」が唯一わかりやすいメリットか。

ただしオーサリングツールの問題からか「フルCSSでレイアウトしたらいつも使っている○○(←オーサリングツールの名称)で編集できなくなった」とか、「レイアウト調整が難しくなった」とかのケースも出るかもしれない。こうなるとやはり「制作者の自己満足」なのだ。本末転倒。

それでは、Web標準準拠サービスは無意味なのか? いや、そんなことはもちろん無いと思う。でも、それをメニューとして掲げるのであれば、もっと明確にわかりやすいメリットがないと自己満足に見えてしまう。

では、お前はどうなんだ?

ウチの場合制作のクオリティのひとつとしてWeb標準やアクセシビリティを強調することはあっても、「Web標準準拠サービス」なんてサービスメニューなんてつくろうとは思わない。

「わかりやすく構造化されたコンテンツは再利用しやすく、色んなデータに転用しやすい。リニューアルなんかすごく楽。携帯用に変換するのも楽だし、例えば全文検索の精度を高めることでユーザビリティも高めることが出来る。」くらいのことは言う。

例えばWebサイトのリニューアルにおいて。

  • 用意されたデータの構造を分析し
  • リニューアル後の姿へ持って行くための処理を検討・設計し
  • 何をどうリニューアルするかを定義し
  • そのためのしくみ(プログラム)を書き、実行する
  • リニューアルデータはプログラムによってCMSにインポートされ、その後の修正も楽に
  • データはCMS/DB化され、高速で精度の高いサイト内検索も可能に

と、こんな仕事が最近増えている。
このような仕事がスムーズに進むかどうかは、ひとえに「リニューアル前のデータがきちんとした設計のもとに(それこそ「Web標準」に準拠して)つくられていることがとても大切である。

結局、こういう場合の効果が一番分かりやすいな、と最近つくづく思う。以前はそんなにしっかりした「リニューアル前データ」なんて無かった。最近はそういうケースが出て来ている。工数もコストも短縮できるから、クライアントのメリットとしてはこれほど明確なものはない。つまり「Web標準は安くつく」のだ。

もちろん、「それ相応の実力」があっての話であるけれども。

あくまでも「Web標準」は手段であり「目的」こそが最も大切、そこへどんなソリューションをどんな技術(とコスト)で提供するかが受託制作の本質なのだ。

ブログのアクセシビリティ向上を支援するMovableTypeプラグインです(テキストを読み上げやすく変換します)。
テキストフィルターに特化するものにして新しく書き直しました。

何せ初めて書いたプラグインだし、汚いというかかなり無理矢理な処理だったというのと、余計な変換をされてしまうという報告をもらっていたこともあり、今回はPerl5.8、Encodeモジュールと use Unicode::Normalize; の「正規化」を利用して素直なコードに書き直しました。
Perl5.8 , MT3.3 環境で動作確認しています。文字コードはUTF-8である必要があります。

ダウンロード

利用方法

<$MTEntryBody jaccessibility="0"$> のように指定します。

処理の概要

  • 全角英数字は半角に変換される
  • 半角カタカナは全角カタカナに変換される
  • (株)(有)等の記号は括弧付き文字に変換される
  • 1/2 等の記号も同様に変換される
    (注:Ⅰ, Ⅱ, Ⅲ (ローマ数字)は「I」(アイ)等で表現される(I,II,IIIのように)
  • 円,ユーロ,ドル,ポンド,セントは日本語に変換される
    (例:$10,000 → 10,000ドル)
  • 日付(らしき)文字列は日本語フォーマット化される
    (例:2007.2.9 →2007年2月9日)
  • スペースで分割された日本語は詰められる
    (例:東   北 → 東北 , 北 海 道 → 北海道)
    (注:「2007年2月9日 新着情報...」等とすると「2007年2月9日新着情報...」のように詰められる
    「<span class="date">2007年2月9日</span> 新着情報」は詰められない)

属性値について

  • <$MTEntryBody jaccessibility="1"$>:正規化(全角→半角や記号の置換等)
  • <$MTEntryBody jaccessibility="2"$>:日本語の分割を詰める
  • <$MTEntryBody jaccessibility="3"$>:通貨の変換
  • <$MTEntryBody jaccessibility="4"$>:日付の変換
  • <$MTEntryBody jaccessibility="0"$>:上記すべてを有効にする

明示的に複数の属性を指定する場合は、

  • <$MTEntryBody jaccessibility="1,2"$>

のようにカンマで区切ります。

「カテゴリ」セレクトボックスを非表示にしている時にエントリーを編集→「保存」した際にカテゴリー情報が保存されないバグを修正しました。

今後当面はこのページにてアップデート情報等をお知らせしていく予定です。

最新版についてはこちらを参照ください。

更新履歴

  1. 2006年12月31日:バージョン0.0.1公開
  2. 2007年01月01日:0.0.2すべてのBlogを再構築する際の不具合修正
  3. 2007年01月03日:0.0.3再構築のフィードバックを受け取るように
  4. 2007年01月05日:0.0.4エントリー編集→「保存」「削除」の際の再構築処理のバックグラウンド化
  5. 2007年01月08日:0.0.5エントリー一覧→「再構築」,「その他の操作」→「公開する」「非公開にする」のバックグラウンド化
    エントリー編集→「保存」の際にカテゴリー情報が保存されないバグを修正
  6. 2007年01月14日:0.0.6エントリー一覧→「削除」の際に複数エントリーが削除されないバグを修正
    エントリー一覧→「その他の操作」→「公開する」「非公開にする」のアラートメッセージを修正
  7. 2007年02月09日:0.0.7「カテゴリ」セレクトボックスを非表示にしている時にエントリーを編集→「保存」した際にカテゴリー情報が保存されないバグを修正
  8. 2007年03月20日:0.0.8「エントリー一覧」→「バックグラウンド再構築」が効かない問題を修正
  9. 2007年04月23日:エントリーの再構築時にトラックバックの指定がある場合送信できるように
    再構築の結果を電子メールで受け取れる機能の追加
    再構築の順番を変更 (インデックス・テンプレートを先に再構築するように)

既知の問題点

  1. エントリー保存の際にTrackBackが送信できない

この件については、割り切った対応をする予定(TrackBackを有効にする場合はエントリーの保存時にバックグラウンド処理をしないオプションを設定で選択可能にする予定)。

尚、新たに動作確認環境としてMT3.34-ja、FastCGI上での動作を確認しました。

License:

『クリエイティブ・コモンズ・ライセンス(表示-非営利-継承 2.5)』とします。
商用利用・設置代行等はお問合せください

Facebook

Twitter

このアーカイブについて

このページには、2007年2月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2007年1月です。

次のアーカイブは2007年3月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

Powered by Movable Type 6.2.6