メールのデザインについて考えてみた

たまたまJavaMailを実装してみる機会があり、メールのデザインについていろいろ考えさせられました。デザインといってもメールの仕様（設計といってもいいですね）についてです。

少し突っ込んでメールの仕様を見てみると分かりますが、インターネットメールのデザインは非常に興味深いものがあります。

その特徴をざっくり一言で表せば「歴史的にややこしい。数学的には美しい。実用的にはいまいち」というところに落ち着くでしょうか。

どのあたりが歴史的にややこしいのか。
あまり突っ込んで調べてはいませんが、BASE64とかMIMEのあたりがややこしいですね。メールは基本的に7bitの文字しか送れなかったとか（これは技術的な制約だったのかそれとも初期の誤った意思決定によるものなのか・・・）、その辺に由来すると思われます。

どのあたりが数学的に美しいのか。
メールは複数の部分（MULTI-PART）を持つものとして定められています。メッセージの本文自体がPARTであり、そのPARTが別のPARTを含むことができます。PARTはさらに別のPARTを含むこともできます。
いわばファイル－ディレクトリ階層に似た再帰的な階層を取ることができるわけです。そしてプログラムで処理する場合も、再帰的アルゴリズムでメールメッセージを処理することができます。（再帰的アルゴリズムイメージ）

parseMessage(Message) {
 if (Message.isMimeType("text/plain")) {
  print(Message.getText());
 } else {
  parseMessage(Message.getContent());
 }
}

例）メールにファイルを添付したり、別のメッセージを添付したり（そして添付されたメッセージが添付ファイル／添付メールを持つことも可能）

実用的にいまいちなのはなぜか。
メールの仕様によればいくらでも添付ファイル／添付メール／添付ファイル付きメールの添付ができてしまいます。
誰が100個の添付ファイルを必要とするでしょうか。誰が100階層の添付ファイル階層を必要とするでしょうか。
再帰的に処理できるのは確かに美しい。しかし、日本語の文字化けの問題やMIME指定のわずらわしさ、それにブラウザやメーラによる（勝手な）解釈を考慮に入れるとはっきり言ってカオス状態です。

確かにデザインは美しい。しかしその結果メールシステムの実装をややこしくしているとすれば、そのデザインは「美しくない」と言わざるを得ないのです。

ではなぜこのようなことになったのか。予期できない偶然によってか。結果的にややこしいと（日本の一開発者から）言われるようになったメールのデザインが、優れたデザインだと呼ばれる可能性はあったのか。

何だかわけの分からない問いになってしまいました。

私の思うところ、メールの仕様にはひとつ問題があります。それは「割り切らなかった」ということです。

例えば「メール本文はUNICODEテキストとして送ること。添付できるファイルは1個だけ。」という仕様だったとして、誰が困るでしょうか？

#まあUNICODEは極端ですけどね。欧米の科学者が7bitASCIIしか頭にないのは残念ながらしょうがないですしょう。あくまでおとぎ話です。

おそらく誰も困りません。それにメールの実装が簡単になり、誰でもメールソフトが作れるようになります。

#それがいいことかどうかも微妙ですけどね。

まあ、結論として言いたいのは、よいデザイン（＝結果的に成功するデザイン）というのは必ずしも数学的に美しいかどうかそれだけではなく、どう割り切ったか、どこを切り捨てたか、という観点も重要になるのだなあ、とそういうことなのです。
まさにセンスですね。

これもJava （小ネタ）

これもまたJavaのパワーです。

C:\cygwin\home\hoge\java>dir
ドライブ C のボリューム ラベルがありません。
ボリューム シリアル番号は A884-83CA です

C:\cygwin\home\hoge\java のディレクトリ

2008/08/20  23:29    <DIR>          .
2008/08/20  23:29    <DIR>          ..
2008/08/20  23:22               202 あ.java
               1 個のファイル                 202 バイト
               2 個のディレクトリ  37,727,498,240 バイトの空き領域

C:\cygwin\home\hoge\java>type *.java

あ.java


public class あ {
        public static void main(String args[]) {
                String 文字列変数 = "こんにちは";
                出力(文字列変数);
        }
        private static void 出力(Object obj) {
                System.out.println(obj.toString());
        }
}

C:\cygwin\home\hoge\java>javac *.java

C:\cygwin\home\hoge\java>java あ
こんにちは

さあ、皆さん、これから遠慮なくクラス名、変数名、メソッド名に日本語を使いましょう！！


え？嫌？
どうして？？

日本語でプログラミングできたら楽しいでしょう。だからどんどん使うべし。

つーか、Javaベースの日本語プログラミング環境作ったらウケるんじゃないかな。え？お前が作れ？

すみません。軽率でした。

なんというトラップ Tomcatでの文字化け

今更文字化けでハマるとは・・・
しかもトラップのような仕様です。

以下が条件です。
▽　jstlのc:url c:paramなどを使って日本語のパラメータをJSPのエンコーディングでエンコードする。
▽　GETで送信する
▽　JSPのエンコードがwindows-31jである　（おそらくUTF-8以外はダメでしょう）

TOMCAT5以降は、GETで送信された文字列は問答無用でUTF-8で解釈するそうです。

Tomcat 5.xにおいてこの問題を解消するには、同コンテナの設定ファイルserver.xmlのConnector要素にて、useBodyEncodingForURI属性を以下のように指定すればよい。

詳細は以下参照
@IT Javaの文字化け対策FAQ（3）

何という・・・

どう「見せる」か（プロジェクトの人間学)

【この「プロジェクトの人間学」投稿シリーズは（後略）　初回投稿：はじめに（プロジェクトの人間学）】

下手に話をややこしくしないこと。これに尽きる。Simple is the best. 真理は単純である。ただしむやみに抽象化・汎用化してはならない。適用範囲が広がってしまう。具体的な前提を定義することが重要である。具体的かつ単純。これがコツである。自分を利口に見せることにこだわってはならない。バカでした。ごめんなさい。これで話が早く済むのならさっさと謝ってしまうのがよい。

Javaで開発しているプロジェクトで障害が発生した。障害の原因がNullPointerExceptionだった。NULLチェックを入れ忘れていた。このように見せてしまうと、影響範囲は甚大である。NULLを取りえる全てのコードにチェックが必要となる。Javaが分かっている人間であればNULLチェックはするし、ほとんどのは単体テストか結合テストで分かる判明するはずのトラブルである。しかしNullPointerExceptionが一人歩きしてしまうとただひたすらこの例外にフォーカスが当たってしまう。原因への対処には不釣合いな、膨大なリソースが投入されてしまう。NULLチェック漏れではなく、さまざまな要因が重なっているはずである。条件があるはずである。そこをちゃんと見せなければならない。そうすればそのトラブルをクローズし、次のトラブルにリソースを投入することが出来る。

また政治的な問題を軽視してはならない。現場から見れば大したことがない修正でもマネジメント層や顧客からすると大変なハードルとなることがある。現場が「大した変更じゃない」と思っても、政治的にはその選択はありえない、という可能性がある。例えば顧客の他の部署に依頼する必要がある変更である。絶対に変更を受けつけてもらえない。顧客はまず青い顔をし、次に現場を恨み始める。現場は「顧客の問題であって俺たちは知ったこっちゃない」と思う。どんどん関係が悪化し、プロジェクトがまずい方向に進む。健全にプロジェクトを運営したいなら、決して政治を軽視してはならない。

見せるにあたってはスコープを広げないこと。むしろ狭めるよう努力する。スコープとはタスクの範囲を指す。タスクの範囲を下手に広げてしまうと、完了させることが出来なくなる。あれはどうなった？と聞かれて常に状況を報告する羽目になる。タスクはシンプルに、ピンポイントで定義すること。そして何をどうしたら完了できるか、そこまであらかじめ射程に入れておくこと。完了までの道筋を見極めることなく、課題を定義しないこと。ついうっかり不安をそのまま課題にすると、却って政治的に厄介になる。重要度が最終的に低いと判明したとしても、だ。また課題を提起する際にその完了条件まで射程に入れておくと課題をクローズする効率が全く違ってくる。スコープを広げないこと。特に広げさせないこと。これが重要である。

やたらと宿題のキャッチボールをしないこと。決定事項のやり取りをキャッチボールに例えた。顧客に決定権をゆだねるとさしあたりは自らのタスクではなくなるため安心する。また待ち状態となるため、責められることがない。少なくとも決定を依頼すれば、作業を進める責任は顧客にある。だがこれは単なる作業の先送りに過ぎない。未来から時間を借りているだけである。下手に先送りすべきではないのだ。顧客への意思決定依頼は最小限にする。適切に提案し迅速にクローズ。結局はそれが一番早くて体力が掛からない。

管理されるが故に完了困難になることもある。重箱の隅が突付かれ、優先度の低いタスクが山ほど発生する。課題のクローズに完璧さが求められる。なんてことはない課題がどんどん広がり、収集がつかなくなる。最後には原型を留めないほどに課題が変質してしまう。そんなことにならないよう、出来る限りクローズを急ぐことだ。

数値化は見える化ではなくむしろ見えない化である（プロジェクトの人間学)

【この「プロジェクトの人間学」投稿シリーズは（後略）　初回投稿：はじめに（プロジェクトの人間学）】

数値化の危険もメリットも抽象化にあることはすでに述べた。だから過度の数値化は危険である。細かい情報がそぎおとされる上に意識が数字という現象＝みせかけに強くこだわる傾向があるからだ。

何のための「見える化」か。それはトラブルの予兆に気が付くためである。数字を眺めてトラブルの予兆に気付くか。進捗の遅れやトラブル数から分かるのはせいぜい「今トラブルが起こっている」程度であろう。その発見すら遅れるかもしれない。数字の向こうを見なければトラブルの予兆は分からない。いや今起こりつつあること全ては数字だけからは分からない。数字は意識的に抽象化された結果に過ぎないからである。すなわち質的な事象を意識的にそぎおとすことができてしまう。数字だけを信頼できないのはそのためである。トラブルを抱えたチームのテスト消化数も極めて順調に進んでいるチームのそれも「同じ一件」である。しかしその質は大きく異なるはずである。例えば前者のテストはテスト結果の確認が甘いかもしれない。前提環境の整備ができていなかったかもしれない。これが後から手戻り作業の大小につながる。順調に行っているプロジェクトですら予定外作業や小さなトラブルが日常茶飯事なのだ。そこに前フェーズ由来の手戻りが発生すると簡単にタスクオーバーフローとなる。後は品質が下がり納期が遅れて行くだけである。

ましてやメールの本数、ソースチェックイン回数、バグに関する数、そんなものをムリヤリ数値化したデータを使って、何かが出てくるはずがない。むしろ現状が隠れるだけである。日本の自殺者年間何万名。内何％が経済的理由でうんぬん。年齢別内訳が・・・そのデータで自殺者が救えるのか。残された人間の何が分かる。数値化しなければ始まらないではないか。そしてあらゆる方法でデータの分析を行う。それをお役所仕事という。他にやるべきことなど、いくらでもある。

プロジェクトを一度徹底的に数値化して管理してみれば、結局何も分からないことが分かるであろう。そればかりか下手をすればプロジェクトが壊れる可能性すらある。

「数値化＝見える化」したい要求の裏にはプロジェクトに対する無理解がある。すなわちそのままのプロジェクトを見ても分からない、評価できない。現場の人間と話をしたくない。何を言っているか分からないから。トップマネジメントも一度ありのままのプロジェクトを見てみたらどうか。たまにはメンバーといっしょにプログラムを書いてテストしてみるのも悪くはない。メンバーの抱えている作業負荷が、実感として分かるであろうから。またプロジェクトの状況も、下手に数字の分析に体力をかけるよりは良く見えるのではないだろうか。

「心ここにあらざれば 見れども見えず 聞けども聞こえず」という。気が付く力が重要である。何か変だと気がつく。納得が行かない。どうして？と思う。だがその先に行くのが難しい。ま、いっか。俺知らねーぞ。私のせいじゃない。思考停止である。次が重要なのだ。それは間違っていると思います。何故ならこれこれこうだからです。確かに嫌味なしに指摘するのは難しい。だが指摘しなければ、将来のトラブルはなくならない。「見える化」の前には「気づき」があり、次に「見せる化」があるのだ。問題を取り出し、顕わにすること。おかしいと指摘し、その理由を示すこと。それが「見える化」の本質なのだ。数値化は現象の解釈に過ぎない。しかも極端に抽象化した解釈である。ゆえにほとんどの数値化に認識としての力はなく、射程も浅い。だからよく考えられていない数値化は単なる「見えない化」なのである。「見える化」の本質は人間の有限なパースペクティブ（見晴らし）をチームで共有化することなのである。

パースペクティブとは何か。人間は一時にすべてを見渡すことが出来ない。現象は常にある立場から見た現象に過ぎない。人の立場にはさまざまな制約が働いている。時間（いついつか）、空間（どこで）、バイアス、偏見、好み、経験 etc。おのおののパースペクティブから課題あるいはトラブル以前の課題を引き出し、言葉にして共有化するのが見える化である。そして課題を正しく言語化することが出来れば、問題は解決したも同然である。あとは管理可能なTODO（いつまでに誰が何をするか）が残るだけである。

「見せ方」というとなんだかネガティブなイメージがあるかもしれない。客観的な事実をある政治的観点から「見せる」。偽りのイメージ。プロパガンダ。そうではない。事象が発生するとまずは解釈しなければならない。神であれば解釈の必要はないであろう。あるがままを全方位から捉えることが出来るに違いない。しかし人間は神ではない。その人の持っている背景（制約。時間空間バイアス・・・）からその事象を解釈せざるを得ない。数式を眺めて相対性理論を思いつくか否か。人によってそのくらいの違いがある。ウィスキーが半分残っている。まだ半分あると思うか、もう半分しかないと思うか。人は皆年を取る。４０歳になったとしてどう生きるか。何も思わないか。それともそれをきっかけにまったく新しいチャレンジをするか。「客観的」な事象などない。「見せる」前には「解釈」がある。そして「解釈」は力なのだ。力を持った人が解釈し得るのである。すなわち（残念ではあるが）力を持たない人間に力強い解釈はできない。力のない人間は力のある人間の認識を鵜呑みにするか、弱々しい自らの認識にすがる他はない。解釈とは自分を変え、世界を変えることなのだ。解釈にはそれほどの力がある。極端を言えば資本主義だって経済学だって物理学だってそれぞれが世界の解釈なのだ。

今そこにあるトラブルに気が付くこと（プロジェクトの人間学)

【この「プロジェクトの人間学」投稿シリーズは（後略）　初回投稿：はじめに（プロジェクトの人間学）】

トラブルの原因は、トラブル発生の後に分かる。「後になって分かる」それが実は「原因」という概念の本質的な属性である。あの判断が誤っていた。あのドキュメントをチェックすべきであった。全て後から作られる「物語」である（原因も結果も存在しない、ことは以前にも述べた）。

こういった「原因と結果」物語によって意識化された経験は、実を結ぶ時期の早い遅いはあるにせよ、その人固有のノウハウとして蓄積される。そのノウハウが次のトラブルの予知につながる。しかし性急な意識化はトラブルの予知能力には結び付かない。ある程度の熟成期間が必要である。方法論だけではトラブルを事前につぶすことはできない。「何か変だな」と気が付くこと、そしてその「おかしい」という感覚を言語化する能力が必要である。さまざまな予兆がある。誤った意思決定。問題の先送り。担当者が全く見落としている場合もあれば隠している場合もある。ある種のトラブルは不可避である。事前に全ての情報を得ることも、全ての可能性を検討することもできないから。早い話が「やってみるまでわからない」そういう状況が確実にある。だったらトラブルは起こって当たり前じゃないか。その通り。トラブルを許容しなければ、先に進まない。リスクも同様である。
全てのトラブルが不可避だなどと言っている訳ではない。予防できるトラブルがあり、マネージできるリスクがある。だったらそっちに注力したらいい。起きてしまった事は起きてしまった事である。しかるべき対応をとり、妥当な再発防止案を検討したらよい。

予防できるトラブルとは何か。それは事前にトラブルの予兆を知りえたトラブルである。からかっているのか。そうではない。一寸先は闇と昔から言うではないか。未来は未だ来ぬ故に存在しない。だから未来は分からない。だが将に来るべき将来なら分かることがある。どのようにして分かるのか。過去も未来も存在しないと前に述べた。すべてのヒントは現在にある。妙な流れに向かっているミーティング。本質から離れた論点で執拗に繰り返される議論。担保の取れていない不確定情報を垂れ流すメンバー。その不確定情報を元に意思決定されそうになっている。オーバーワークで深夜残業を繰り返すメンバー。すでにその品質に疑義がある。以上の事象は数字には決して現れない。すべてがトラブルの予兆である。その中のどれが実際のトラブルになるか。それはその時になってみなければ分からない。だが経験と勘がそれを助けることがある。筆者の経験では上の例はすべて明確なトラブルの前触れであり、後のトラブル発生は必至である。

筆者の妻が皿を洗う時、洗い終わった皿を水きりカゴにやたらと積み上げる。そんなに積んだら崩れるぞと何度も警告するのだがほとんど言っても無駄である。たいてい聞き流されるし、ひどい時には逆切れされる。何ヶ月かに一度、皿の山が崩れ妻の悲鳴と共に皿が割れる。これもまた仕方がない。見る目が無かった。それだけの話である。「どうしてあの人と結婚したの？」これもまた因果律の本性を省みない、厳しい質問である。だってもう仕方がないじゃないか。

だから何とか我慢しようとしてみる。頑張ってミーティングの流れを補正しようとする。議論を本質的な流れに戻そうと頑張ってみる。不確定情報は「確認しろ」と指示を出す。意思決定ではなるべくリスクとコンチプランを検討する。それで上手く行くこともある。だが残念ながらすべてが上手く行くわけではない。所詮は人間のやることである。

また予兆を知ったとしても必ずしも手を取れるわけではない。明らかにオーバーワークのメンバーがいたとしても、コストがない、権限がないなどの理由で体力の投入ができない場合がある。その場合は今できることをできるだけ行い（例えばそのメンバーをできるだけ雑用から守るなど）、大きなトラブルが次のフェーズで発生するのを覚悟するほかはない。

PDCA(Plan Do Check Action)だけでは足りない。Planの前に問題に感覚的に気が付かなければならない。そして問題を正確に定義しなければならない。また最後のActionは余計である。事後作業が不要になるようにPlanし、念のためCheckして問題が無ければクローズである。だから正確にはFPDC(Feel Plan Do Check)である。PDCAで回るほどプロジェクトは簡単ではないし、悠長でもない。Feelとは、今現に何が起こっているのか把握することでもある。これは会議では把握できない。会議で把握できるのはこぎれいに抽象化された情報であり、生のデータではない。だから現場で実際に見る必要がある。

しかし残念ながらマネジメント層や顧客は、現場を見ても何が起きているのか分からない。不祥事を出す会社の役員が、現場を知らないのと同じである。現場を見ても分からないし、解釈もできない。だから現場から適切な情報も上がらなくなる。確かにシステムは余りにも複雑である。だがマネジメント層もなるべく低いレベルまで状況を押さえるべきなのである。

ドキュメント軽視の理由（プロジェクトの人間学)

【この「プロジェクトの人間学」投稿シリーズは（後略）　初回投稿：はじめに（プロジェクトの人間学）】

なぜある種の開発方法論がドキュメント軽視を生むのか。時間をフェーズで区切りそれぞれの成果物を定義する。あるフェーズの終わりに納期が来る。プロジェクトのある一時点の状況を考えてみる。それは詰められた要件と漠然とした希望レベルの要件が混在する状況であろう。プロジェクトの途中で全ての話が煮詰まっているなどありえない。そして設計書の記載レベルは当然粒度の粗いほうにできるだけ合わせることになる。要するに煮詰まっている要件でも細かいレベルまでは記載しないような動機付けが働いてしまう。

ウォーターフォール型プロジェクトがドキュメント軽視を生む理由がもう一つある。それはドキュメントの納期が過ぎた後の修正作業に負のインセンティブが発生することである。成果物は納期を過ぎると一旦FIXしたものと見なされる。一般に過去の蓄積に対する変更は好まれない（前述のトラブルの定義参照）。つまりドキュメントの変更が好まれないから、詳細に設計を紙に落とすことも、まめにメンテナンスすることも結局は好まれないのである。これもまた本末転倒の類であろう。

システム構築プロジェクトが必然的にドキュメント軽視を生むとは思わない。ただし、そうしないためにはリリース直前までドキュメントの変更を励行しなければならない。それができるマネージャがいるだろうか。そんなことをしたらウォーターフォール型開発の前提が崩れるではないか。筆者はそこは崩しても問題ないと思っている。事実、マイクロソフトの開発プロジェクトはリリース直前まで設計書を更新すると「ジョエル・オン・ソフトウェア」（オーム社）にあった。正しいと思う。常に設計書を最新にしておくことは、最善の実践としか思えないではないか。

トラブルを恐れるからさまざまな本末転倒が生まれるのだ。トラブルを自然なものと受け入れ、その上でベストの対応を取ればよい。設計書の修正もその一つである。

タガの外れた面白さ （崖の上のポニョ）

崖の上のポニョを見ました。

凄かったです。

言葉で語られるべきではないですね。あれは。

ぶっとんでいるというか、脳みそが海水に浸ったような面白さでした。

何で？どうして？？あれあれあれ？？？？

すさまじいばかりのおとぎ話パワーと申しましょうか。

そこかしこで広がりのあるイメージが爆発しています。

あっという間にぐいぐい引き込まれて、最後もあれれれれ？とにかく何だか凄かったな、という余韻が２，３日は続きます。この歳になってこんなインパクトを受ける映画はそんなにない。

さかしらに言えば突っ込みどころ満載なのでしょが、あのパワーとセンスは凄い。トータルのインパクトも凄い。あの作品を語る言葉は存在しないのでは、という気がします。

踏み込めば宮崎さんのトラウマまで行くと思いますが、そんなことをしてもしょうがない。

とにかく面白かったです。