ここで開発班からメンテナンス班へバトンタッチ。
引き継がれたのは、サイトのプロトタイプと、仕様書兼顛末書（もちろん TreeMemo）。
では、仕様書のほうを見ていきましょう。

囲んではならない

お気づきでしょうか?
今回のサイトは、ひとつも囲んでいません。

10年前は、そういうページばっかりでした。

10年前のよくある個人サイト

これは、単にデザインしてないだけであって、意図もへったくれもないです。
褒められたものではないけれど、少なくとも　狭塞感　とは無縁でした。

あれから 10年。 囲みだらけです。
なぜこうなるんだろうと、書籍やサイトに当たってみると．．．

デザインの本には、囲むと感じよくなるから、囲め
アクセシビリティのサイトには、囲むと情報のまとまりがわかるから、囲め
W3C の "正しい HTML チェック" は、入力フィールドは <fieldset> で囲まないと違反だぞ、囲め

カッコいいから囲め　わかりやすいから囲め　ルールだから囲め

囲め～　囲め～　囲め～　囲め～

こりゃ囲みだらけになるわ。

幾何学的な線を使ってはならない

"囲み追放令" では飽き足らず、直線、機械的な楕円、さらには長く揃うフェースまでなんとかしろ、とのお達しです。 こんなことできるかなぁ と思いましたが、どうにか、大半の幾何学的な線を追放しました。

さすがに例外も認められていて、ライセンス購入の手順に入ったら、そこからはカチッとした印象のほうがいいとのことで、区切りの水平線や、表（罫線が直線）、小見出しの前に置く ■、などが認められていました。 また、フォームの入力フィールドやラジオボタンは、有機的なゆらゆらした線だと、ユーザーが不安になるといけないから、そのままにしました。

フォームの　送信ボタン　や、JavaScript の　戻るボタン　にも追放令が出ていました。

送信ボタン の追放には成功。

戻るボタン も追放しましたが、
Firefox については、JavaScript の機能の実装不備で、キーボードでの操作性に問題が出るので、呼び戻しとなっています。

さて、"幾何学的な線狩り" の目でウェブを見ていて、最近、見てみたくなったものがあります。 活字を使わないサイトってないでしょうか。すべて手書き文字のサイト。
ウチのようなサイトでは無理ですが、趣味のサイトで、テキストの量や更新が少なければ、可能では。 重くなりますけど、日本の都市部だけを対象と開き直れば、ある程度ブロードバンドを前提にできるので。

ページによってはガラッと変える

最近のサイトって、ホームページがわからないなぁと感じていました。 玄関のページも、カテゴリーごとのページも、統一デザインのサイトが多くて、なんだか落ち着かないのです。

理屈はあるのだと思います。 検索サイト経由で来る人のほうが多いから、玄関は要らないとか。 統一デザインのほうがいいとか。 ナビゲーションのルールを守って、どのページにも　ホーム　というリンクが明示してあるから、問題ないとか。 それはわかります。

だから好みの問題なのでしょうが、やっぱり玄関は玄関らしいのが好きです。

また、基本は統一デザインが良いと思いますが、性格の違うページでは、ガラッとイメージを変えるのもいい。 ウチのサイトでは、ライセンス購入手順のページと、カフェバー大西。

特に、カフェバー大西は、デザインだけでなく、操作性も変えろとの指令でした。 なんと

操作性を悪くして、出て行きにくくしろ
　雰囲気のあり過ぎる店に入って 「しまったぁ」 と思っても、
　　体裁があるからすぐには出て行けない、
　見ない顔だな　よく来るのか　まぁ座れ　話を聞け
　　そんな感じにしろ

ナビゲーションを落とせなんて、Web標準に真っ向から逆らってますが、そういうメリハリは面白いと思います。
さっと読んで、軽く楽しんで、すぐ出て行く、ファストフードなコラムもいいですけど、来てしまったからには、覚悟して話を聞かされる、そんなページもあっていいでしょう。

非構築の風合いを

建築はさっぱり興味ありませんが、藤森照信さんという建築家が好きです。 テレビで見た仕事ぶりが楽しくて、屋根に草生やしたり、枯れた大木の上に茶室を乗っけたような、すごくバランスが悪い建物を作って "高過ぎ庵" と名付けたり。 高過ぎ庵で昼寝してると、風で少～し揺れて、たまらなく心地いいらしい。 新聞のコラムで世界の名物建築を紹介していますが、こちらもとっても面白い。

あるとき本屋さんで著書を手に取りました。 内容は建築の素人には難しかったのですが、ひとつの言葉が魅力的で覚えてしまいました。

構造は現代　装飾は縄文　

ウェブサイトに当てはめれば．．．
構造は、最新の Web標準。ソースコードはロジカルで綺麗。 理由のないもの、無駄なものはない。 ソフトウェアのメンテナンス性向上のノウハウをウェブサイトに応用して、つねに機動性を維持しておく。
なのにブラウザで見ると、非構築的。 なんとなく歪み、意味不明のものも顔を出し、人のぬくもりがある。
そんな感じでしょうか。

余談ですが、旅先でおばあさんから聞いた話。 昭和のはじめ、キャラメル工場で働いていた。 当時のキャラメルは、ほとんど今と同じ形。 四角いキャラメルが20粒、小さな箱に入ってる。

でも、ひと粒ひと粒のキャラメルは手作り。 だからキャラメルにも個性が出る。 職人さんによって、ちょっとずつ大きかったり小さかったり。 おばあさんの担当は最後の箱詰め。 ちょっと大きくても、20個集めると箱のふたが閉まらないし、小さいと隙間ができてカタカタ言う。 傑作なのは、どの職人さんが作ると大きめなのか、みんな癖をわかっていて、「これは○○さんのだ。またふたが閉まらない」 なんて職場仲間で言いあってた。

人間がやると、ちょっとずつずれて、ちゃんとならない。 その感じを取り入れたくて、メニューでもフェースでも、少～しずつ曲げてみたりしました。

でも、非構築の味は出せてないですね。 ウチのサイトの性格では、どうしてもカチッとしてしまう。
それに、これはブラウザの CSS の実装不備が原因なのですが、左上にメニュー、上辺にページタイトルという、安全策を取らざるを得なかったことが、風合いの面では痛かったです。
難しいテーマだったと思います。

国際化を意識する

エンコード形式は UTF-8 を採用しました。 日本人は世界中にいて、その人たちが日本語版のパソコンを使っているのか、現地語版を使っているのかはわかりませんが、日本語フォントさえ入れれば、これで見てもらえるはずです。 中国、台湾などの漢字との、異体字の問題も出ないはずです。
なお、@niftyのメールデコードの制約で、フォームだけは、シフトJIS にとどめています。

当初ホームページには、Flash のアニメを考えていたのですが、今回はやめています。 先日ネットに 「ウェブサイトが嫌われる理由トップ10」 なる記事が載っていて、その中で Flash が上位に挙がっていました。
ただ、少し違和感を感じませんか。 いまやウェブの中、Flash だらけです。
この調査はアメリカの研究機関のもので、対象もおそらくアメリカや近隣国なのだろうと思います。 ブロードバンド化が進む日本の感覚とは、温度差があるのでしょう。

ブロードバンド格差という言葉をご存知でしょうか。 日本でもブロードバンド化が順調なのは都市部だけで、地方では、当初3年遅れると言われたのが、5年になり、8年になり、まったくメドが立たなくて自治体が自ら始める地域も出ています。
ソフトバンクの孫さんが、プロ野球のホークスを買い取ったとき、「宮崎キャンプのブルペンをネットで中継しよう」 とアイデアを語りました。 ニュースで聞いてて、宮崎市の郊外でしょ、大丈夫?　と思ってたら、案の定、ブロードバンドがない。
ほんの5、6年前までは、都市部にもブロードバンドはなかったのに、都会の人はもうそんなこと忘れてる。 かたや、公民館に集まって、ADSL を引いてもらうために署名を集める人たちがいる。 町長以下、議員が揃って NTT に陳情に行く町がある。 その落差。

それでも国内のブロードバンド格差はどこかで落ち着くでしょう。 国策として電話網の銅線を光ファイバーに代替する構想が約束されない以上、山間離島まであまねく広くというのは期待できないけど、地方でも市や町の中心部までは、いずれ普及するかなと思います。 そのあと目立つのは、世界のブロードバンド格差です。

そもそもブロードバンド格差は、インターネットがあるから生まれます。 インターネットがあって、ブロードバンドがあって、ブロードバンドが入る国と入らない国、入る地域と入らない地域ができることで生まれます。

通信速度の前提をどれくらいに考えればいいのか、難しいです。 都会住まいのクリエーターのように、Flash 満載のサイトを作る気には、まだなれない。 国際化していきたいので。
ともかく、軽くて、見栄えのするサイトを心がけることの重要性は、まだまだ褪せないと思います。

5年もたせる

フレームを使ったウェブページも、まだ数年は安泰なはずです。 去年暮れのバージョンで、XHTML1.0 Framset に書き換えているので、それほど慌ててフレームを捨てることはないのです。

なぜ今かというと、これから5年間、ウェブサイトに力を割きたくないからです。 国際化をはじめ、Windows や Web の標準技術のキャッチアップに、だいぶメドがたってきて、今後はソフトの作りこみに集中する方針なのです。

フレームを受け付けないブラウザが、5年出てこないかと言ったら、五分だと思います。 ここが作りこみのヤマ場ってときに、ウェブサイトの大変更なんてご免ですから、このタイミングで構造だけは新しくしておくことになりました。

現時点に限れば、Web標準の原理主義で作成したサイトは、あれこれと障害が出ます。 ほどほどに標準に準拠しながら、2年おきくらいにチューニングするというのが、いちばん賢いやり方ですが、それは担当部署や、契約業者を持っている人たちの話で、ウチにはあり得ないです。

IE7のベータ版で確認したりしながら、現時点では少し問題でも、ほどなく解決すると予想される技術は、採用しています。 1～2年後に照準を合わせ、その間の障害には目をつぶることにしました。

XHTML1.1 ですので、なんとか5年。 期待はできるでしょう。

Web標準に従う

現状、Web標準同士が少しでこぼこです。
だからこれは、ルールというよりはガイドラインだと解釈しています。

今回のサイトは、W3C の "正しい XHTML1.1 チェック" に合格しましたが、フォームを使うページで、ひとつだけ違反事項が出ています。
フォームの名前をつけるときに、XHTML1.1 では、<form id="???"> と書くのが正式です。 汎用の id属性で名前を付けるのです。 ところが、ブラウザの JavaScript1.5 の実装が、まだ id属性を受け付けません。 Safari は違うという話を聞きますが、他のものは、<form name="???"> と、従来通り、name属性で名付ける必要があります。
XHTML1.1 では、form要素の name属性は廃止なので、違反を指摘されるわけです。 こちらが悪いわけではないので、ほっといています。

なお、フォームを使わないページは、正しい XHTML1.1 ですので、W3C の例の合格マークを貼ってもよいのですが、今回のサイトのデザインと合わないので、やってません。 あのマーク、バタ臭くてね。

これは Web標準ということではないのですが、ソースコードの綺麗さは意識しました。
機械の作るソースコードを綺麗と感じたことはほとんどなく、ウェブサイト制作ソフトの書き出す HTML も、Microsoft Office の書き出す XML も、読みにくいなぁ（読めないなぁ）と感じていました。

XML などは、人が読めることも売りなのだから、やっぱり綺麗なほうがいいし、ソフトメーカーなのだから、そういう部分を見られることもあるだろうと、心がけました。

＋　＋　＋　＋　＋

ここからは、仕上げの作りこみの話。
メンテナンス班の作成日誌です。

写真を撮る

カフェバー大西の写真は買うつもりでした。
ネットの写真ライブラリに、ショットバーかなにかの、いいのがあるだろうと思ってました。

ところが、写真ライブラリの写真って、みんな　キレイキレイ　なものばかり。

ピントはばっちり合ってるし、
照明をきちんと当てちゃうから、開店前みたいに明るいし、
だいたい、いかにも成功した青年実業家みたいのや、カッコいい外人が飲んでるところが気に食わない
ラテン系の外人の姐ちゃんたちが、グラス掲げて大笑いしてる写真にいたっては、いったいこんなショットバー、どこにあるんだ！　と言いたくなる

プロトタイプで使われてた写真は、たぶん、だれかの家族の誕生日。 部屋を暗くして、小さいお子さんがケーキのロウソクを吹き消してる。 それをみんなが囲んでる。
照明的には暗いけど、明るく暖かく華やいでる。
ショットバーもそうだ。

写真ライブラリは、たぶん、お店のカタログみたいのに売るために、ああいうキレイで繁盛してやかましい写真を並べるのでしょうね。 それにあれは写真であって、作品じゃない。 あんな雰囲気のないもの、いくら集めたって写真集はできない。
ならば時間の無駄だ。 狙いを個人の写真家に切り替えます。

写真家の個人サイト狙いに切り替えて、まず参ったのが、大量のブログが検索されてしまうことです。 写真家にも手軽なブログのほうがすでに人気なのでしょう。 ただ、こういうときはブログのヒットは困ります。 中には面白い撮影日誌などがあって、ついつい読んじゃうから、余計困ります（これは自分が悪い）。

ようやく個人サイトにたどり着くと、やはり著作権にはかなりナーバスになっている様子。 ダウンロード、小売、をやってるサイトには当たりませんでした。

依頼するほどの予算はないので、仕方ない。 自分で撮ることにしました。
レコードプレーヤーや古いレコードを引きずり出し、珍しい酒瓶や陶器のグラス、フンメル人形を、メンバーや友人からかき集め、アロマ蝋燭を照明に撮影開始。

デジカメでの撮影は面白いです。
すぐに出来栄えを確認できるところがいい。
いい感じに撮れたら、パソコンに移して、カフェバー大西の背景にしてみる
ガラスの酒瓶は赤目が出るから、はずそう
jpg の画質を落とし過ぎると、人形の表情が消えちゃうな
明る過ぎて字が読みづらい、照明を遠ざけて．．．

撮影風景

かなり撮り直しましたが、蝋燭の煙で少し頭が痛くなる頃、なんとか納得するものが撮れました。
（蝋燭で頭痛とはヤワになったもんだ。昔は部屋ん中で石油ストーブ炊いたのに）

実は後遺症に悩んでいます。
蝋燭の照明でデジカメですから、シャッターを押してから撮り終わるまで、カメラが動かないようにするために、細心の注意を払いました。
それ以来、手ぶれが許せないのです。 ふつうのスナップ写真が撮れなくなって困っています。

書をつくる

ホームページの indysoft.jp は最後に書きました。 すべてのページを作り、いろいろな環境でテストもし、W3C のチェックも終えたうえで、最後に取り掛かりました。

かなりプレッシャーを感じていました。
前述のように、非構築的な風合いは不十分です。 だから、ここで失敗したら、少しばかり和風なだけの、つまらないサイトに終わるかも、という気持ちがありました。

書のアクセントを作る中でわかったことは、今回のデザインは、書に魅力がないと、なんの魅力もないということです。 書がよくないと、白は白でなく、ただの無地。 空間は空間でなく、ただの隙間。 （書道用語で白とは余白のこと。白の美しさもまた書の美しさです）
また、いくら後工程の加工が巧みでも、筆ぶりや墨の色合い、その一度限りの偶然の美しさは、あとから作り出せるものではないことも、わかっていました。 グラフィックソフトで筆や墨の美しさを増幅することはできます。 でも作り出すことはできないのです。 掛け算みたいなもので、書に魅力がゼロでは、増幅しようがないのです。

うまく書けるだろうか。 書けたとしても、書だけで作ったサイトは、寂しくないだろうか。
この期に及んで、結果が怖くなっていました。

こういうときは現実逃避に限る。 気分転換に和太鼓のコンサート。
演奏から、感じるものがありました。

太鼓という楽器は、つい没頭して乱打したくなる誘惑があります。 でも奏者からは、そんな印象を受けません。 これほど速く、クリアな音で叩ける人がいるのかと、驚きっぱなしでしたが、それは半分トランスして、どんどか叩いているのではなく、ピーンと緊張が効いているのです。 情感は溢れんばかりなのでしょうが、どう叩くか、どう見せるか、の意識を決して失わない。 それは技巧主義なんてクールなもんじゃなく、極端な例ですが、ドライバーの心得としての、自分がどうなっても最期までハンドル離すな、みたいな。
素人はこうはいきません。 そうそう、始まった頃のなんとかソーラン祭りなんかで、気持ちの高揚のまま雄々しく乱れ打ちする、"太鼓達者" がいたなぁ。

書も、太筆持って、だばっと墨つけて、勢いつけて書き殴れば、それらしいものはできます。 でも、それじゃ、お祭りの看板レベル。 今回、印象派書道の作品集を相当見たけど、書道家は、その先を行っていると思う。

　書は心だ　心の有り様が表われる

よく聞きます。 そう思っていました。
でも開発班も、書道家と話したとき、

　形のことだけ言っていた

といいます。 それが印象的だったと。

考えてみれば、書は造形の芸術です。 演者と観客が直接対峙する、演劇や生演奏とは違い、"内から内へ" の伝達はあり得ない。 伝達方法は、絵画らと同じく、"内から形へ、形から内へ"。
だから、字形の工夫、筆ぶり、墨の妙、紙の味わい、これらを醒めた感覚で構築していくことを、やめてはならないのでしょう。

書は心　それは書の究極かも知れないけれど、逆に安直に使ってはいけない "逃げ"。

精神を澄ませ、情念に没入して、無意識に筆を走らせるのも、それはそれでいい。
でも、没頭するあまり、筆ぶりが "粗雑" になっては台無し。
帰り道、そんなことを考えていました。

帰っても、まだ迷いは吹っ切れません。
書の作品集をめくりながら、筆ぶり、墨の妙を、目に焼き付ける。
墨の美しさ　筆ぶりの面白さ　変化　形　形！ 形！
そして、何通りかの　indysoft.jp　を瞼に下書きしました。

深夜、湯舟につかって目を閉じていたら、無意識のうちに、下書きのひとつが、浮かんできました。
だんだん色を帯びてきます。 ハイライトやシャドウ、エアブラシのような背景．．．　色の部分は大きくなり、グラデーション、ぼかし、次第にエフェクトの度合いはエスカレートしていきます。 「きれいだなぁ」 「これなら書だけでも、寂しくないな」 「やっぱりこういうのにしようか」 とやすらいだ気分に包まれてきたところで、一瞬それが何かと重なって見え、一気に醒めました。

よく海外の中堅ソフトメーカーのサイトなどで目にする、エフェクトをかけまくったグラフィックスと、だぶって見えたのです。

　あんなの作ってどうするよ

ウェルメイドで、誰からもカッコいいと見られるものを目指したら、ああなってしまう。
もっと非構築で、乱調美のテイストを狙って、書に賭けたのではなかったか。 書の可能性を実証するために、やってきたのではなかったか。
うまく行こうが、行くまいが、これで行ってみる。

気分すっきりで寝て、朝、ひと筆目で書いたのが、ホームページのあれです。
練習なし。 ワンテイクのみでした。

もちろん加工はしています。 まず、二度書きが4箇所。
indysoft の s は、最初からの計算で、極太筆、にじみ最大で上書きすると決めていました。 あと3箇所、修正のためになぞり直しています（習字だったら、先生からゲンコツです）。
字の位置もグラフィックソフトで動かしています。 にじみも調整しました。 回転をかけたバージョンも作りました。 どうも変形の際にアンチエイリアシングがかかると、墨の美しさが消えてしまうきらいがあり、採用しませんでしたが。

でも、字を綴ったのは一度だけ。 和太鼓観たり、書集をめくり、イメージして、なによりも何日もかけて、ハネだのテンだの書いてきたことが、生きたんだと思えました。
ソフトウェアの仕事ではなかなかこういう経験はなく、現場に詰めた時間の長さが、物を言う面があります。
自分でも驚いたし、嬉しかったですね。

＋　＋　＋　＋　＋

リニューアル後、チームで話したことを、あとがきに代えます。

ブラウザに思う

月並みな話ですが、CSS や JavaScript の、ブラウザごとの違いには悩まされました。
今回のサイトは、position: fixed という CSS の命令が、効くブラウザ用と効かないブラウザ用の CSS を呼び分ける作りになっています。 もちろん、余計な手間です。 fixed版が、私たちの作りたかったページです。 フレームの操作性を代替できているのは fixed版（Firefox, Safari, IE7用）だけです。

開発班は、総じて、CSS なら Firefox。 JavaScript なら IE が安定している印象を持っているそうです。 CSS では IE はおかしなことが目立つし、以前、Netscape の JavaScript の実行でとんでもない目に遭って以来、Netscape系ブラウザの JavaScript は信用していないそうです。 Firefox もその印象は覆せなかったようです。

2大ブラウザがそれぞれ落ち度のある中で、Opera の存在意義は大きかったらしいです。 Opera がどうなるかで、Firefox と IE のどちらがおかしいか、推察できたことが少なくないそうです。 もちろん、Firefox と IE でうまく行き、Opera だけがおかしいことも珍しくないとのこと。
ちなみに、どのブラウザが好きかと尋ねたら、今ではどれも応援したくなくなったそうです。

ブラウザの実装が乱れている、ブラウザメーカーは何をやってる、と書籍でもネットでもよく見かけますが、これだけ違うと、W3C の側には問題はないのだろうかと気になり、CSS の規格のページを見てみました。

少し問題を感じました。 事例の図が少ないのです。
たとえば、margin について。 概念の図はちゃんとあります。 これが margin、これが border、これが padding。 でも、お隣さんとの関係の図が見当たりません。

隣のブロックの margin との関係は?
それは隣が <p> のようなテキストの段落でも、<div> のような汎用的なブロックでも同じか?
隣が真横や真下にあるときも、float や position によって、斜め上や斜め下にあるときも同じか?

本文を読めば理解できることかも知れませんが、自分がブラウザの開発者だったら、心配です。 自分の本文の解釈を、図で確認したくて仕方なくなると思います。 特に、そういう部分の解釈でブラウザの表示が乱れていることは、もうずいぶん前から周知の事実です。 補足図を描いて状況が改善するなら安いもの。描くべきだと思います。

CSS に思う

CSSは、グラフィックソフトの良いところを取り入れて、こうなってくれていると楽です。

位置とサイズを指定してソースを流し込む

このパターンですべて行けると思います。
画像も、ぴったりの寸法で何パターンも用意しなくても、共用で済ませられますし。 今回もこうなっていたら楽でしたね。

HTML に思う

HTML は、ソフトウェアに比べ、モジュール化に配慮されていないと感じます。 "情報を1ページに完結して、それを検索する" のが大原則ということは、理解できます。 でも、例えば統一デザインのサイトの、共通メニューの部分などは、厳密にはコンテンツとは呼べないでしょう。 ソフトウェアがよく使う、マクロ という手段で、共用部分を別ファイルにするくらいのことは、できていい気がします。 それができないので、今回は JavaScript で動的に書き出しましたが、たまに Opera で、書き出しが間に合わないらしい症状が出て困ります。

モジュール化は、コンテンツのページのソースコードが綺麗になることにつながります。 となれば、Web標準の面でも、大切なことなのでは?

全般に HTML の規格を見ていると、これはもともと紙の書類からイメージされたのだな、と感じます。 当初は紙の書類。 今なら A4縦のワープロのファイル。 内容も論文や報告書。

ヘッダーが <h1> から <h6> までしかないのは、紙の幅の制約 → 論文の一般傾向 → たいてい見出しは3レベル、予備でその倍あればいいや、 という流れで決まったのでしょうし、コンテンツ間のリンクは考えても、操作性に関する共用部分なんて考えなかったから、モジュール化も遅れたのだろうという気がします。

<div> を論理的なまとまりとして使うべきなのか、CSS の指定範囲のような論理外への対処として使うべきなのかも迷います。 <p> がもっと偉ければ、論理的な大段落として、ある程度 <div> の肩代わりができるけど、<p> は <ul> や <table> を含めない。

いろいろ疑問は湧きますが、紙の論文を思い浮かべると．．．　あぁ　あれなら問題にはならないや

論文はもともと構造化されてる

それに、たぶん、SGML を考案した当時のアメリカ人の書く論文や報告書は、同時期の日本人のそれよりも、構造が論理的だったのでは、と想像します。
以前、アメリカのビジネスマンは、headline - detail - opinion　の三段構造で話したり書いたりするのが巧い、と聞いたことがあります。 たしかに CNN のニュースなどは、どのリポーターもその喋り方をします。 新聞社が日本人の社員を募集して、応募者の英語力は素晴らしかったけど、誰もこの組み立てで話したり書いたりできず、落とされた、なんて話も聞きます。

そういう人たちの、天然ロジカルな論文を土台にしたとすれば、SGML の策定って、基本部分はけっこうスムーズに進んだのではないか、なんて考えたりもします。

外の力を借りねばだめだ

外部委託ができなかったのは、残念でもあり、良かったとも思います。

少人数のいいところは、何のためのサイトか、何のためのリニューアルか、全員がわかっているところでしょう。 技術、デザイン、経営、を一体で判断していける。
だから、ブラウザに Web標準の実装不足が見つかっても、デザインを曲げるのか、2つデザインを作ってブラウザを判定して使い分けるのか、障害に目をつぶり問合せにはサポートで対処するのか、そういう判断は本当に速いです。

でも、もう企業サイトは、個人や少人数で作るシロモノではないですね。 システムと同じに考えねばダメです。 ウチのサイトも、数えたら 100ページ。 このうえ各国語版のページを用意したら、工数は相当なものです。 チームのコアメンバーだけで内製するのは、ここらが限界でしょう。

たまたま今回は、自分たちだけで作り上げることになり、全体を把握できています。 これを土台に、ウェブサイト制作ソフトやブログ制作ソフトを評価したり、外部委託を探っていけばいい。 視界はクリアです。

内製が増えた分、スケジュールは遅れました。 予定では 4/1 リリース。 守れなかったのは残念です。
4/1 でなきゃならない理由は、ホームページのニュース欄に、

エイプリルフールではありません

と書きたかったという、ただそれだけなのですけど。

メンテナンス＆サポート班 いいやま