1. インデックスを使わないと検索が遅すぎる
2. インデックスを使うとメールの量が多くなったときにメールクライアントのパフォーマンスが全体的に低下する

とという課題が出てきてしまって、メールを削除してインデックスを作り直すという作業が対策が必要になっていました。

その解決策として昨日から「メールサーバーにsshターミナル経由でログインして、コンソールアプリで直接メールストレージ上で操作する」というやり方を実践しているのですが、そこで気がついたのが（今更的な部分はありますが）僕らがGUIの使用のために払っているコストの大きさです。

僕も日々のメール処理には検索速度の速いMail.appを使用していますが、よくよく考えてみると、CUIよりGUIを選ぶ理由は：

• マウスによるポイント＆クリックによる個別選択
• コピー＆ペーストによる繰り返し編集
• ドラッグ＆ドロップ（DND）によるファイルシステム連携

の操作性の部分にあるんだなぁ、ということに気がつきました。そして、これらの機能を実現するためにGUIアプリはCUIアプリに比べて圧倒的に大きく、そして遅くなってしまっているのです。

ウェブを使った情報操作が僕の主な業務ですが（響きは悪いね）、そこで上記のようなGUIの操作性はかなり重要な役割を果たしているので、だからだめなんだ、って言う事ではないですが、業務内容・要件によってはCUIを見直す必要があるなぁ、そして、GUIのコストって改めて高いんだなぁ、という事をつくづく実感しました。

ちなみに上記で使用しているCUIメールクライアントはmuttです。ソフトウェア技術者以外の人だとあまり聞き覚えの無いアプリかもしれませんが、メール処理のスピードという観点ではかなりの優れものです。

muttはMUAに徹した設計になっていて、メールをローカルストレージから読み書きして表示する以外は基本外部アプリに依存する形で開発がスタートしたため、その部分の機能が非常に軽快に、かつ的確に動作します。特に正規表現によるタグと、タグされたメールへの一括処理機能は、大量のメールを処理する際に重宝しています。

1. 検索、転送、タグなど業務内容もメールの要件と一致している
2. syslogをメールに転送するlogwatchやWindows EventLogをメールに転送するアプリも充実している（文字化け多いけど）
3. 新たなサブシステムを学習、保守、運用しなくて済む

などがその理由かな。

ちょっと気をつけないと行けないのは、通常業務で利用するメールとは切り離す必要があるという事。結構なメール量になるので、他の業務への影響が出てしまうので。僕はその辺に気づくのが遅れて、いたい目に遭いました。それとそのメールシステムの監視や、遅延への対応ポリシーを事前に策定しておく事。まぁ、ログ監視はアラートと違うから、そこまでリアルタイム性は必要じゃないけどね。

RoundCube

Ubuntu 9.10上でv0.3.1を実装して、OS Xから使っているのですが、IMAPサーバーと同じマシン上においているからか、非常に軽快で素敵です。ただ、以下の機能欠落が致命傷：

1. UTF-8以外のエンコーディング（特にOutlook Expressユーザーがいる日本語環境では）
2. （１）と関連して、件名でBase64のサポート
3. （１）で関連して、返信／転送時の元メールのエンコーティング引き継ぎ
4. 署名の位置指定
5. キーボードバインディング
6. 検索の条件と制度

（４）までは自分でなんとかなりそうなので、いつかパッチを公開してみます。（５）はハードルたかすぎかな。（６）はIMAPサーバー（Dovecot）が問題なのかも。

Thunderbird

Ubuntu上の3.0（Shredder）はなかなかさくさくなのですが、OS X上での3.01はなんかもっさり間がありました。2.0系の方がよかったかも。やっぱりどのアプリもクライアント側で検索をSQLiteで実装するのは限界があるみたいですね。今４０万通ほどのメールを整理しようとしているのですが、やはりサーバー側でどうにかしないといけないみたい。

Mail.app

２万通ぐらいまでのメールなら、こちらがやっぱり一番しっくり来る。早いし、検索がいけてる。Todo管理の部分がもうちょっといけてたら、iCalも一緒に使うんだけどなぁ。

Zimbra

Prismで実装されたオフラインクライアント（Zimbra Desktop）は本当にごみに近いんだけど、Luceneなどのオープンソースコンポーネントで構築されたサーバーは行けてるので、メールの検索エンジンとしてウェブメールクライアントは使える。

結論

• Ubuntu上でfetchmail＋procmailでPOP3経由で拾ってきたメールを一度Dovecotにいれる。これにより、IMAP4経由でBlackBerryやMail.app、RoundCubeを使って、いつでもどこでも同じメールが見れる。
• ThunderbirdはUbuntu上で使って、アカウント間の整理や、Macダウン時に使用。
• 日々のメール処理はMail.appで行って、性能維持のために定期的にメールをアーカイブアカウントに移動し、インデックスを再構築する。メールの移動に使用するコマンドは：

find <メールフォルダ名> -mtime +14 -exec mv <アーカイブフォルダ名> {}

• アーカイブされたメールはPOP3でZimbraに移動し、ZCSのウェブメールから検索や転送などを行う。

上記の設定ファイルをどこかにポストしますねー。

1. DNSサーバー：everydns.net（Dyn, Inc.に買収されましたが）
2. メールサーバー：Google Apps
3. ファイル共有サーバー：Google Apps
4. アプリサーバー（VPS）：Slice Host

Google Appsを使う事によって、サービス開発時に使うWikiや書類作成ソフトも提供されるので、超便利です。

1. メインフレーム＋端末（全機能がサーバ側にあり、サーバが少ない）
2. サーバ＋ワークステーション（サーバ台数が増えると同時に処理がユーザー側にシフト）
3. P2P（ユーザー側がサーバー機能をも担うようになった）
4. クラウド＋クライアント（サーバ単体を認識せずに接続

といった感じでユーザー側デバイスの進化と低コスト化によって徐々に役割がユーザー側にシフトする傾向にあったのが、最近の「ネットワークの進化」「サーバーデバイスの低コスト化」という二つのトレンドで逆行している。だから「クラウド コンピューレィング」って「クライアントサーバ コンピューティング」の言い換えただけだよね。

僕の中で、ソーシャルネットワークサービス（SNS）はまず第一に「ネットワークサービス」であり、そういう意味ではLive MessengerやSkypeなどのIM/VoIPサービスや、携帯電話ネットワークと同じものだと考えています。なので：
「『ソーシャルネットワーク』サービス」
ではなくて
「ソーシャル『ネットワークサービス』」
という捉え方の方が正しいという意見です（歴史的にはどうか知りませんが）。

各ネットワークの違いは：

1. 提供しているコミュニケーションサービスの種類と数
2. 各ユーザーの住所録公開制度
3. 他のネットワークとのゲートウェイサービス数
4. 提供しているネットワークアクセスAPIの種類と数

であって、SNSの場合はこれに

クローズドネットワーク上でのコミュニケーション権限を住所録で管理するシステム

という機能が足されるのではないでしょうか。

こうしてみると、Mixiの最大の脅威はGREEやFacebook、Twitterではなくて、日本の三大モバイルネットワークサービスプロバイダって気になりますね。docomoが今提供している「電話帳お預かりサービス」なんかを通じて、携帯端末内の住所録共有できるようにしたら、それこそ一気に最強のSNSプロバイダになっちゃいますし。

そして、今後ののインターネット上での競争は：

• SNSを含むネットワークサービス
• データベースサービス（受発注を含む）
• ユーザーインターフェイスプラットフォーム
• ビジネスプロセスサービス（課金、商品配送手配など）
• コンテンツマテリアル

の各要素をデベロッパーが組み合わせ、ユーザーにとって使いやすく魅力のあるアプリケーションの開発をとおして行われるように見えます。

みなさんはどう思われますか？

1. サービス改善を実感できる体制をCEOを補佐する形で実現する。
2. CTOだけではなくて、CIO的技能をより充実させ、他業務部門が必要としてる情報技術を企画できるようになる。
3. サービス開発をよりアジャイルに行えるように体制を改善し、新サービスの実現や既存サービスの改善がより短いスパンでリリースできるようにする。

技術者として

1. プライベートおよびパブリックのクラウドインフラ上でサービスを立ち上げる。
2. 複数のLLを連携できるウェブアプリインフラを実現する。
3. Pocket Computerフォームファクタのプラットフォームでアプリケーションを開発する。
4. オープンソースプロジェクトを立ち上げる。

個人として

1. 短気を減らす。
2. 海外での人脈を揺るぎないものとする。
3. 新しい生活を立ち上げる。

これらの取り組みの結果として http://ideapad.jp/64627fd9/show/ に載ることを目指します！

クライアントから案件内容をどのように聞き出しているか、というトピックにおいて、ごく一部でしたが、ヒヤリングシートを活用しているという方がいらっしゃいました。私も時間に制限のある取材などでは事前にヒヤリングシートを作成して送っておくようにしています。

そもそもクライアントが忙しくて記入している暇がない、というケースは多々あるかと思いますが、口頭で要件を引き出していく場合もヒヤリングシートをベースに漏れなく確認を進めていくことができるかと思います。プロジェクトが進んでから確認漏れで大きな軌道修正が必要になることは避けたいですしね。そんなリスク回避にも役立つかな。

このヒヤリングシートは、woobzineの以下の記事を翻訳したものです。質問には作成した方特有のものもあるようですので、自分用に使いやすくアレンジしていただければと思います。

もとの記事：
http://bit.ly/3TtDsU

————-
■クライアント企業に関する質問

＜連絡先＞

１．企業の正式名称
２．住所
３．都市
４．都道府県
５．郵便番号
６．電話番号
７．ファックス番号
８．URL
９．連絡先窓口（担当者）
１０．担当者の名前
１１．担当者の名字
１２．担当者のメールアドレス
１３．担当者の電話番号
１４．担当者の携帯電話番号
１５．適した連絡手段（メール、電話等）
１６．連絡する時間帯、タイムゾーン
１７．最終的な決断権は誰にありまますか
１８．他にも関連する連絡先を教えてください

＜一般的な企業情報＞

１９．会社の目的は何ですか
２０．長期目標は何ですか
２１．年齢層、企業規模、成長率など簡単に教えてください
２２．提供しているサービスや製品について教えてください
２３．企業文化や企業精神について教えてください
２４．競合企業について教えてください
２５．競合とどのような点で異なりますか
２６．競合より御社と取引するべき理由は何ですか

————-
■プロジェクト関連の質問

＜全体像と戦略＞

２７．サイト名、ドメイン（例：www.woobxine.com）
２８．新規制作ですか、それともリニューアルですか
２９．サイトの主要な目的を教えてください
３０．競合のサイトに比べてどのように目立たせたいですか
３１．なぜサイトを作るのか教えてください

・ウェブでのプレゼンスを確立する、もしくは改善するため
・ブランドイメージの向上、ロゴへの認知度アップのため
・サービスや製品説明をするため
・顧客サポートやアフタケアをするため
・市場シェアと企業認知度向上のため
・EC機能を提供するため
・情報収集のため（アンケートや調査など）
・既存の広告キャンペーンやマーケティング戦略を後押しするため
・テクノロジー企業としてのリーダーシップを裏付けるため
・資金調達のため（寄付、募金）

３２．このサイトを通して達成したいゴールはありますか
３３．サイト訪問した結果としてユーザに求める行動は何ですか

・製品やサービスの購入
・店舗に足を運ぶこと
・電話、ファックス、メールといった形の連絡
・より詳細な情報を求めること
・ユーザ情報を教えること
・製品やサービスへの評価をすること
・サイトのメンバーになること
・情報を探すこと
・その他

３４．これらのゴールの達成をどのように計画していますか、サイトは企業の長期目標にどう貢献しますか

＜ブランド＆ターゲット顧客＞

３５．サイトを訪問してほしいユーザ層を教えてください
（年齢、性別、業界、ネット利用頻度、収入、購入傾向、PCスキルなど）
３６．ターゲット顧客にとって、サイトはどのように必要とされますか
３７．既存顧客はどのように情報収集をしていますか（ラジオ、口コミ、新聞など）
３８．ターゲット顧客は御社をどのように評価していますか
３９．ターゲット顧客いアピールしたいメッセージは何ですか
（例：コストパフォーマンスの高さ、安全性、効率など）

＜アイデンテティとデザイン＞

４０．御社が提供するものを簡潔に説明するスローガンやキャッチコピーはありますか
（例：Just do it, Think smallなど）
４１．サイト訪問者に伝えたいメッセージやフィーリングは何ですか
４２．オンラインの競合を調査して、したいこと/したくないことはわかっていますか
４３．ロゴはありますか？あればデータでください、ロゴがなければ新たに制作しますか。
４４．ヘッダーにはどんな情報をいれたいですか　（企業名、サイト名、ロゴなど）
４５．好きなサイトを３つ教えてください
４６．嫌いなサイトを３つ教えてください
４７．形容詞と短いフレーズを使って求めるサイトのテイストを教えてください
（イラストを使った、プロっぽい、カラフル、落ち着いたトーンなど）
４８．企業カラーはありますか
４９．使用したいカラーはありますか
５０．使用を避けたいカラーはありますか
５１．パンフレットなどの印刷物でサイトがテイストを揃えるべきものはありますか
（テキスト、広告、写真、イメージなど）あればデータでください
５２．他にデザインに反映すべき資料があれば提出してください
５３．製品や社員などの写真撮影をする必要はありますか

＜マーケティング＞

５４．御社のサイトを探すために検索エンジンで入れるキーワードは何ですか
（１０以上、優先順位をつけて書いてください）
５５．検索エンジンに手動でインデックスされるようにしますか
５６．検索エンジン以外のマーケティングプランはありますか
（新聞や雑誌広告、バナー広告、相互リンクなど）
５７．プロモーションの一部もしくは丸ごとこちらで対応することを希望しますか
５８．サイトの他に名刺、封筒など一緒にデザインを希望するものはありますか
５９．サイトへの再訪をどのように促しますか

＜コンテンツ＞

６０．サイトのページ数はどれくらいにしますか
６１．サイトに入れたいページをリストしてください
（例：ホーム、記事、コンタクト、FAQ、サイトマップなど）
６２．可能であれば簡単なサイト構成（マップ）を作ってみてください
６３．サイトに入れたい要素や機能を選択してください

* JavaScript (jQuery)
* 検索可能なデータベース＆フォーム
* Flash
* チャット/フォラム
* Streaming audio
* ニュースレター/メルマガの登録
* ストリーミングの動画
* アンケートや投票
* イラスト
* 製品レビュー
* 証言、証明
* ランディングページ
* 地図
* 資料請求のフォーム
* カスタマー登録、ログイン
* イメージギャラリー
* 賞品/景品の抽選
* EC機能
* フォラム
* オンライン決済
* イベントカレンダー
* ブログ
* RSS フィード
* ポートフォリオ
* アップロード機能
* ミニコミ
* ダウンロード機能
*　カスタマイズしたデータベース

６４．他に希望する機能があれば教えてください
６５．上記について質問があればしてください
６６．サイトに入れたくないコンテンツはありますか
６７．毎月追加するページは何ページくらいを考えていますか
６８．新しいコンテンツの素材（テキスト、写真）はどこから入手しますか
６９．サイトの更新を担当するのは誰ですか
７０．素材はスグにでも使える状態ですか

＜ホスティング＞

７１．ドメインは取得していますか
７２．取得していない場合は、何を希望しますか
７３．既にホスティング会社と契約していますか
７４．していない場合は、こちらで対応することを希望しますか

＜更新＞

７５．サイト更新の頻度はどれくらいを予定していますか
（毎時間、毎日、週1回、月1回など）
７６．更新内容はどんなものですか
（デザインやレイアウト変更、コンテンツの追加や変更など）
７７．更新は弊社と御社どちらで対応しますか
７８．特別なソフトウェアやコーディング知識がなくても更新できることを望まれますか
７９．もし希望する場合は、使用するCMSなどで特定のものはありますか

＜メンテナンスと改善＞

８０．メンテナンスを担当できるウェブマスターはいますか
８１．担当者のスキルを確認できるようページのURLを教えてください
８２．サイト訪問者のどういった情報が欲しいですか（ページビュー、国、訪問の経由など）
８３．ログ解析をして、それを元にサイトを改善するのは誰ですか
８４．サイトの成功を決める指標（KPI）は何ですか
８５．サイトのユーザビリティテストの実施を希望しますか
８６．将来的な運営などを考えたスタッフのトレーニングを希望しますか

＜サイトリニューアル＞

８７．ターゲット顧客は現状のサイトをどのように評価していますか
８８．既存サイトで成功しているエリア、またその理由は何ですか
８９．既存サイトで改善、改修が必要なエリアはどこですか
９０．リニューアル後のサイトにどういった効果を期待しますか

＜ロゴデザイン＞

９１．新しいロゴの制作もしくはリデザインは必要ですか
９２．ロゴの具体的なイメージはありますか
９３．タグラインがある場合はそれをロゴと一緒に配置しますか
９４．ロゴをもっとも的確に表現する形容詞は何ですか
９５．テキストのおき方はどういった形を希望しますか
（スペースあり：ロゴ デザイン、スペースなし：ロゴデザイン）
９６．テキストにどういった効果をつけますか
（例：太字、手書き、オリジナル）
９７．魅力的に感じるロゴはどんなものですか。またなぜですか

＜弊社に関する質問＞

９８．弊社のことを何で知りましたか
９９．このプロジェクトに弊社を選んだ理由は何ですか
１００．もっとも重要なものは何ですか：制作費、質、スピード
１０１．適切な見積もりが出せるように以下からひとつ選んでください

高い＝すばらしい＋はやい
ゆっくり＝すばらしい＋やすい
低い＝はやい＋やすい

１０２．プロジェクトの成功・失敗を決める要因は何ですか

＜予算と時間＞

１０３．ご予算はどれくらいですか
１０４．月の運用予算はどれくらいですか
１０５．月のマーケティング予算はどれくらいですか
１０６．プロジェクト単位で世の中のサイトの進展のために寄付を呼びかけますが関心はありますか
１０７．制作費の25%～50%を前払いでいただいています。当然仕事を完遂できない場合はお戻ししますが、問題はありませんか
１０８．希望される納品日を教えてください
１０９．プロジェクトの進捗はどれくらいの頻度で希望されますか

＜まとめ＆フィードバック＞

１１０．プロジェクトの簡単な説明をしてください
１１１．他に何か質問や言いたいことはありますか
————-

以上です。

少しでも参考になれば嬉しいです。

————-

“If I had my life to live over”　by Nadine Star　(Version 1)

If I had my life to live over again，
I’d try to make more mistakes next time，
I would relax，
I would limber up，
I would be crazier than I’ve been on this trip，
I know very few things I’d take seriously any more.
I would take more chances，
I would take more Trips，
I would scale more mountains，
I would swim more rivers，
And I would watch more sunsets.
I would eat more Ice cream and fewer beans.
I would have more actual troubles
And fewer imaginary ones.

You see…
I was one of those people who lived
Prophylactically and sensibly and sanely，
Hour after hour and day after day.
Oh， I’ve had my moments
And if I had it to do all over again.
I’d have many more of them.
In fact， I’d try not to have anything else，

Just moments，

One after another，

Instead of living so many years ahead of my day.

I’ve been one of those people
Who never went anywhere without a thermometer，
A hot water bottle， a gargle，
A Raincoat and a parachute

If I had it to do all over again，
I’d travel lighter，
Much lighter， than I have.
I would start barefoot earlier in the spring，
And I’d stay that way later in the fall.
And I would ride more merry-go-rounds，
And catch more gold rings，
And greet more people，
And pick more flowers，
And dance more often.

If I had it to do all over again.

But you see，
I don’t.

————-
“If I had my life to live over” by Nadine Star (Version 2)

If I had my life to live over，
I’d dare to make more mistakes next time.
I’d relax， I would limber up.
I would be sillier than I have been this trip.
I would take fewer things seriously.
I would take more chances.

I would climb more mountains and swim more rivers.
I would eat more ice cream and less beans.
I would perhaps have more actual troubles，
but I’d have fewer imaginary ones.

You see， I’m one of those people who live
sensibly and sanely hour after hour，
day after day.

Oh， I’ve had my moments，
And if I had it to do over again，
I’d have more of them.
In fact， I’d try to have nothing else.
Just moments， one after another，
instead of living so many years ahead of each day.

I’ve been one of those people who never goes anywhere
without a thermometer， a hot water bottle， a raincoat
and a parachute.
If I had to do it again， I would travel lighter than I have.

If I had my life to live over，
I would start barefoot earlier in the spring
and stay that way later in the fall.
I would go to more dances.
I would ride more merry-go-rounds.
I would pick more daisies.

もともとはHTMLというドキュメントフォーマットのビューアにHTTPプロトコルをサポートするファイルダウンロードツールを組み合わせたものだったと思う。その時点での特徴としては：

• ダウンロード元を指定する仕組み（ナビゲーション）がビューア内のUIだけでなく、ドキュメント内にもあるということ。
  まぁ、そもそもそれがそれがハーバーテキストの定義なんだろうけど。
• HTMLが他のメディアを内包して表示できるドキュメントフォーマットであるということ。

だったんじゃないかな。

でも、ここで終わってたら単なるハイパードキュメントビューアでしかなかった。それがアプリケーションプラットフォームにまで躍進した理由は：

• JavaScript実行エンジンが追加され、HTML内にJavaScriptの記述と、そのプログラムと連携する仕組み（DOM＋イベント）が追加された。
• 他のメディアを描写するためのプラグインアーキテクチャがウェブブラウザに実装された。

だったと僕は思う。

もちろん表示履歴や、ブックマーク、ツールバーなどのUIの改善や、HTMLとHTTP自体の進化（CSS2のサポートはこの一環）、他の通信プロトコルのサポートなども、いろいろすごかったりするけど、やっぱり「ウェブブラウザは最低限この機能が無いとウェブブラウザって呼べないんじゃね」っていうのは上記の４点な気がする。

後者二つの発展が特にすごいと僕が感じるのは、大抵の技術革新がコンピューターの性能を最大限に使おうとする中、逆に制約を課したことによって、「ユビキタス＋クラウド」というコンピューティングアーキテクチャの実現を推進したって言うところじゃないかな。

それまでのネットワークコンピューティングはよりクライアント側に演算責任をシフトし、データのガラパゴス化をしてしまっていた。それを、手元のデバイスはこのレベルでいいはずって決め、逆に演算責任の大半を「あちら側」にシフトすることによって、それまで分散化されていたデータが連携できる場所に集約され、新しいサービスを可能にしてる。

その上、演算責任の制約によって、P2Pモデルでは貧弱すぎるとされるデバイスクラスも主役レベルで利用できるようになって、電源や通信の両方での発展とあわせてユビキタスコンピューティングも実現できるようになった。

普通は足して伸ばすところを、押さえ込んで伸ばした感じ。いまさらかもしれないけど、ウェブブラウザすげー。