お堅いqmail

カスタマサポートから、「メールが届かないって言ってるんだけど、調べてくんない？」という調査依頼が舞い込んできました。
「へー、また勘違いなんじゃないの？」なんて思いながら、調べていました。

—

実際にメール配信でエラーになっているのは本当で、該当するエラーメッセージは、

CNAME_lookup_failed _temporarily._(#4.4.3)

というものでした。いろいろ調査していくと、どうやらDNSを引いた際、結果が512バイトを超える場合にこういうエラーが発生しているらしいです。（参照：DNS拡張EDNS0の解析「512バイトの壁」）

・・・qmailらしいな。月末のパッチネタですかね。

—
qmailはRFCに忠実に作られている（本当？）ということで、ちょっとお堅い実装なんですよね。
そういえば、昔いた開発チームにも手こずっていた人がいたのを思い出しました。

A message consists of header fields (collectively called "the header
of the message") followed, optionally, by a body.  The header is a
sequence of lines of characters with special syntax as defined in
this standard. The body is simply a sequence of characters that
follows the header and is separated from the header by an empty line
(i.e., a line with nothing preceding the CRLF).

メッセージはヘッダフィールド（集合的にメッセージヘッダと呼ばれる）と、
それに続く任意のボディからなる。ヘッダはこの標準に定められた特殊な構文
による文字列のシーケンスである。ボディはヘッダに続く、ヘッダと１つの空
行で区切られた（つまり、CRLFの前に何もない行）単なる文字のシーケンスで
ある。

これはRFC2822のGeneral Descriptionの一節です。

「ボディとヘッダは一つの空行で区切られている」という決まりが書いてあるのですが、qmailは二つの空行は許してくれませんでした。

ということは、Bodyは改行から始まってはいけないということになっちゃうんですけどね。

アプリケーション作っている身としてはいやはや、苦笑しちゃいますよね。

2009
01/31
CATEGORY
system-enablers
コメントを書く

要件定義フレームワークを使う

私の今のお仕事は、ひとつのインスタンスを複数のユーザが利用する「ASPサービス」の保守・運用・開発です。
ですが、最近はこの「共用仕様」に飽き足らないお客様のために、個別にインスタンスを立ててカスタマイズする案件が複数並行しています。
そういうわけで、最近は営業やユーザからのヒアリング内容をうまくまとめて、「要件定義」として記述するという作業シーンが多くなっています。

—

そもそも要件定義って、みなさんどうしていますか？プロジェクトが終わった後で、

「要件定義があいまいだったために、多数手戻りが発生した」

なんて反省をしていませんか？

私見ですが、要件定義が失敗しやすい理由としては、

  • ユーザからのヒアリングが上手にできない（対機械の作業ではなく、対人間での「情報を引き出す力」が問題）
  • スケジュールがタイトで、気づいたら要件定義のフェーズを終了させられた。（まだできてないってば。）
  • そもそもユーザ自身が自分でニーズを分かっていない（引き出せないから、書きようがない。あと出しされる）
  • というか、そもそも自分自身が要件定義の書き方をよくわかってない（すみません。）

なんて感じではないでしょうか。ちなみにこれらは全て私の実体験なんですけどね。

—

さまざまなやり方や書き方があると思うのですが、私は、RDRAという要件定義のフレームワークをベースに書いています。

RDRA(Relationship Driven Requirement Analysis)

こちらのページにいくと、Enterprise Architectのテンプレートがダウンロードできます。
（うちは、このEnterprise Architectが標準の設計ツールです。）

RDRAの作者が書いた「顧客の要求を確実に仕様にできる要件定義マニュアル」を買ってもよいのですが、無料でダウンロードできるテンプレートの「メニュー」「レビュー」の内容を読む（見る？）だけでも結構いい感じです。

ただ、全部まじめにやろうとすると、「気付いたら要件定義のフェーズを終了させられた」コースに乗ってしまうので、
自分でこの中から書くべき部分をしっかり選ぶことが大事ではないでしょうか。そもそも、「書けないものは書けない」と自覚することが大事です。また、このあとアジャイルな開発手法を用いて不足分をコミュニケートしながら補っていく、なんていう方法もありでしょう。

—

ちなみに、RDRAのHPにある、要件定義にまつわる問題とその解決に向けてには、以下のような問題が挙げられています。

  • 全体像が見えてこない
  • 顧客との打ち合わせをリードできない
  • まとまらない会議
  • シーズ中心
  • 議論がすぐ袋小路に入る

みなさんには思い当たる節がありますか？詳細はＰＤＦをダウンロードして読んでみてください。

また、「顧客の要求を確実に仕様にできる要件定義マニュアル」では、それぞれの分析シーンでの失敗パターンや成功へのプラクティスが書いてあります。この本はお薦めで、私も持っています。一度買って読んでみるのもよいでしょう。（私はamazonや神崎さんの回し者ではありません。）

2009
01/29
CATEGORY
RDRA
system-enablers
コメント ( 3 )

UIデザインパターン

前回は、UIデザインガイドラインについて書きました。
今回は、UIを設計する際の「ユビキタス言語」の候補として、ソシオメディアのUIデザインパターンについて書いてみます。

ソシオメディアのUIデザインパターンは、

の５つに分かれていて、それぞれで様々なパターンを提供してくれています。
中身を見てみればわかりますが、「ああ、こんなパターンあるよねー」とうなずくものばかりです。
そういったありきたりなものでも、このUIデザインパターンのように、

  • 集める
  • 名前を付ける
  • 整理する

といったことをやってくれると、本当に価値があがります。

開発設計現場で、
「ここの機能はユーザが連続編集できるようにM-E展開パターンで作ろう」
とか、
「この画面がこのユーザの興味の中心だから、この画面を中心にハブパターンで考えてみよう」
なんて会話が設計時に出てくると、イメージが各人で共有されて、すごくスムーズにコミュニケートできそうです。

このサイトには、各パターンごとにページがあり、

  • 効能
  • 用法
  • 注意書き

の３つで構成されています。中でも注目は、「注意書き」です。

たとえば、「シングルウィンドウ」のページでは、こんな注意書きがあります。

  • シングルウィンドウは基本的にモーダルな印象をユーザーに与える。
  • ひとつのウィンドウに多くの機能や情報を詰め込むと、作業状況が把握しにくくなる。
  • ひとつのウィンドウに多くの機能や情報を詰め込むと、ウィンドウサイズが大きくなり、他のアプリケーションも同時に使いたいユーザーには邪魔になる。
「ひとつのウィンドウに多くの機能や情報を詰め込むと、作業状況が把握しにくくなる。」
ので、このような作りは、
「この画面をどう使って何をするか」が良く分かっている、「プロフェッショナル向け」にはうける作りになります。
逆に、誰でも使えるように作りたければ、「ウィザードパターン」のほうがよいでしょう。ただし、ウィザードパターンには
  • 入力項目が多く、なおかつ手続きの意味（作業と結果の因果関係）が分かりにくいと、かえって作業完了までのストレスが高まる。
  • ユーザーが自分で操作手順を工夫することができないため、学習による効率化は期待できない。

という注意点があるので、なんでもかんでもウィザードパターンにすればよいというものでもないでしょう。また、「手続きの意味」「作業と結果の因果関係」を名前付けして整理して、分かりやすく示してあげることは必須条件になります。

このように、「UIデザインパターン」を勉強してみると、今までの知識が頭の中で名前付けされて整理されます。また、使っていくにしたがって、パターンの用途もだんだんと体（頭？）にしみこんでくることでしょう。

2009
01/28
CATEGORY
UIデザインパターン
system-enablers
コメントを書く