企業システムとユニバーサルデザイン

通勤の往復で『「誰でも社会」へ―デジタル時代のユニバーサルデザイン』を読んだ。一日で読めるとはなんとお手軽。

ユニバーサルデザインって、数年前に社内の新規事業アイデア公募で「自社の提案に必ずユニバーサルデザインを盛り込むっつーのはどうです？」と提案して、もののみごとに丁重にお断りされた経験がある。その頃もっと張り切ってたら、もしかしたら著者である関根千佳さんに会いに行ってたかもしれない。

バリアフリーは、まずターゲットの人たちに向けてデザインし、その後で対象外の人にも広げていくこと。
これに対してユニバーサルデザインは、もっとも障害のある人間でも使えるように最初からデザインすること。

分かりやすくて優しい文章の中に、はっとさせられる文があった。
「最初から画像を見ない超ハイパーなネットワーカーのニーズと、視覚障害者のニーズは一致しているし、片手に電話を持ってキーボードだけでデータを探したいビジネスマンのニーズと、片麻痺の方のニーズは一致しているのだ。」

そうなのだ！完全な人間がいないように、「健常者」もまた障害者なのだ。
障害者に対する壁は、まだ大きく存在している。しかし障害者の姿という分かりやすいものしか見えないのも、視野が狭いというものだろう。

ユニバーサルデザインやバリアフリーの考えが企業システムの設計で議論されているのを見たことがない。
メーカーは自社のサイトで大々的に謳ってはいるが、現場レベルではまったく話を聞かない。

たとえば色盲の人たちに対する配慮をしているだろうか。
ダム端末の画面は黒地に緑色の文字だが、エラーが赤色で表示される。
株価ボードは緑と赤で示される。
会議の資料に載せた表は、セルの色の違いだけで差を表現している。

ちょっと文字を添えてあげるだけで、色盲の人を困らせることがなくなる。
色盲は通常生活にそんなに困難をきたさない。会社でも周りにいくらかいることだろう。しかし当人達はあえて言わないだけで、さっき述べたような状況に出くわすと困った顔をする。

僕はとりわけ色盲の人がどう感じるかについて敏感になることが多い。
それは、学生時代の友人が原因だ。
対戦落ち物ゲーム「ぷよぷよ」を彼と初めてプレーしたとき、彼は「こんなん分かるかよ！色盲をばかにしてんのか」と言った。
なるほどその通りだ。画面上部から落ちてくる「ぷよ」は色でしか判別できない。細かく見れば色によって形も異なっているのだが、分かりにくすぎる差だ。

何か新たにインタフェースを設計するとき、色のコントラスト、とりわけ緑と赤の差を考える癖がある。
本当ならもっと色々と考慮すべき点はあるのだが、いかんせん自分の経験の範囲でしか考えられず、自然に出てくるのはこれが精一杯だ。

ユーザー(いわゆるペルソナ)をどこまで具体的に想定できるかが、よいデザインを生むもとになる。
「誰のためのデザイン？」と問われて「あなたのためのデザインだよ」と答えたいが、自分の中の“あなた”は、なるべく多く揃えておきたい。

null を返してはいけないのかなあ？

「nullを返してはいけない理由(Saisse's Wiki 2004-04-06)」について。
面白く読みました。
確かにnullを返そうかどうしようか、迷う状況も数多くあります。ただ、ちょっと反対意見を。

すごくありきたりな結論だけど、null を返すことはアリでしょう。
理由は「null は取り得る値の範囲の一部」だから。

安易に null を返すことはモデルのバグの放置につながる、というのはすごくよく分かります。
ただ、それも「安易に」というただし書きレベルのような気がします。要は契約をどこで交わすかという話ではないかと。

サンプルコードに次のようなインタフェースが挙げてありました。

Hoge getHoge();
boolean isHogeGettable();

これはすなわち次のコードと(意味的には)同義だと考えます。

/**
* @return Hoge オブジェクト。存在しない場合には null
*/
Hoge getHoge();


「(1)あるかどうかを判定し、(2)ある場合にのみ値を取得する」というプロトコルをクライアントに規定するという意味では、差がないように思います。

また、isHogeGettable()メソッドがあろうとなかろうと、getHogeメソッドは null を返すべきでしょう。getterメソッドに assert が書いてありますが、これは setter 内もしくは getter のクライアント側コード内に配置するべきだと思います。

逆に null を返せないと困る状況があります。たとえば範囲クラスの類です。

class DateRange
  Date getStart(); //日付の最初を返す
  Date getEnd(); //日付の最後を返す
}

class IntRange {
  int getStart(); //最初の数値を返す
  int getEnd(); // 最後の日付を返す
}

範囲の片方が開放されているRangeももちろん存在します。その場合は null を返すようにしたい。しかし IntRange クラスの値はプリミティブ型で扱いたいので、返すのに適当な値がありません。
Integer 型を返すのも嫌に感じて、hasStart()/hasEnd()メソッドを追加しました。
(「null を返すべきじゃない」という立場にたつと、DateRangeクラスでも hasXXXXメソッドを採用することになるはずです。ただし、それでも getter は null を返すように設計したい)

もちろん、次のようなインタフェースで null を返されるのは非常に困りもの。
0件のCollection を返して欲しいところです。
(速攻で NullPointerException が出ることでしょう)

/**
* 指定の条件で問い合わせた結果の一覧を取得します。
* @param criteria 検索条件
* @return 見つかった Foo オブジェクトのコレクション
*/
Collection queryFoo(Criteria criteria);

groovy を俯瞰できるページ

groovy のシンタックスを一覧できるページ。
http://viva.sourceforge.net/talk/jug-mar-2004/slides.html

クロージャとかMarkUpとか。
惚れ惚れするよ。

『Core Java Servedr Faces』(途中まで)

あとで読む。
http://horstmann.com/corejsf/

アウトプットするのは気持ちいい

きのうのPoEAA読書会は楽しかったです。
kdmsnr さんを含めた素敵な方々に会えて幸せでした。

感想は大きく2つあります。
・読書会ではあるが、PoEAAを触媒にした理論、理想、実践を語れたらなお素敵じゃないか
・読書会でも酒を飲みたかった…

いやはや、アウトプットするのは純粋に楽しいですね。
改心して、ほぼ1ヶ月更新してないblogをちゃんと書くことにします。

みんながいいって言うものを片っ端から触ってみます。
とりあえず第一弾として、今日はオフィスでサボリ気味にGroovy三昧。
「！」

惚れました。

アジャイルプロセス協議会定例セミナーに行ってきました

アジャイルプロセス協議会定例セミナーに行ってきた。
前半は豆蔵の羽生田さんの講演。
後半はコーチングのトピックを絡めたアジャイルのプロジェクトマネジメント論(論というほどではないけれど)。
アジャイルに向いている判定がでて、いちおう安心。

メタファを補うために身体を動かす
メタファは重要なのにあんまり使われていない。ならば身体を動かそう。ということでダンスに仕立てるというトピック。
実際、身体を使って表現するというのは効果的でしょう。ダンスに仕立てるまではしないけど。

そういえば自分も、分かりにくいアーキテクチャを説明するときには身体を動かしてもらっている。
たとえば Messaging Queue の説明なら、キュー役やキュークライアント役を立てて、紙をメッセージに見立てて動いてもらったり。
会議でこれをやると、アーキテクチャ上実行できないプロセスや矛盾をすぐに理解してもらえる。
もっと重要なのは、身体を動かすと期せずして笑いが起きるので雰囲気が柔らかくなること。

建築のパターンランゲージの実践例としての盈進(えいしん)学園東野高校
この協議会のセミナーではよく出てくるようですが、僕には初耳でとても興味深かった。
なかでも面白いと思ったのは、次のような合意形成プロセスがあったという話。

建設予定地は全体的に窪地が多い
→ 窪地をどうしようか困っている
→ 生徒から「池にしよう」と提案が出る
→ 学校側は反対したが、先生が生徒に丸め込まれた
→ 池として完成し、橋がかけられた

結果として造られた池はとても優雅で、「*偉い人が考えたわけではない* 要望」を拾うことは重要だ。

DOAとOOA

MSはDOAの夢をどうして見るんだろうか (L'eclat des jours(2004-02-24)) について。

DOA と OOAのせめぎあいは、今まさに僕にとってもホットなトピックです。
DOAをきっちり勉強したことがないと excuse してから。

DOAだろうがOOAだろうが方法論であり、状況に合わせて用いるべきだと考えます。
その状況とは何かといえば、あたりまえの話ですがデータベーススキーマが先に存在するかどうかだと思います。
少し付け加えるならば、「ユースケースの洗い出しより先にデータベーススキーマが存在するかどうか」です。

ニワトリ卵みたいな話になりますが、例を挙げてみます。
単一システムが新規に単一DBスキーマを構築する → OOA
既存システムを再構築するが、DBスキーマは流用 → DOA
複数システムが単一DBスキーマを直接使う → DOA
EAレベルで全社DBを構築し、全社DBスキーマを直接使う → DOA
全社DBスキーマを使うが、各システムとの間にはドメインモデルへのマッピング層を設ける → OOAが可能

ユースケースによってドメインモデルを自由に設計できる状況では OOA に何の障害もないでしょう。
ただ、すでにモデルがDBスキーマとして実装されてしまっていたら、DOAに流れていかざるをえません。

全社DBを構築するような場合、利用側を単一技術(言語、フレームワーク)に縛っておくのは得策じゃないので、CRUDのビジネスロジックもStoredProcedureとして実装します(自分ならそうする)。こうなると、OOAはEAよりも小さな粒度で適用することになります。
J2EEも含めてEAとして確立するという判断をアーキテクトが行えれば、全社レベルでOOAを適用できるのでしょう。

その意味で、DevSummit2004で紹介された次の事例はとても興味があります。
フレームワークを利用した電子自治体共通基盤の構築－地方から全国へ[pdf] (溝江言彦)

DOAの定本を知りたい今日この頃。

アジャイルセミナー

アジャイルプロセス協議会の定例セミナーに行ってきます。

勉強会の演目が「アジャイルに向く人・向かない人」というそうな。
自分が向かないと分かったらどうしましょう。

Subversion 1.0 released!!!

Subversion 1.0 がリリースされた！
啓蒙にも力が入ります。

Subversion を業務に使いたい

「Subversion 批判に対する反論」は、開発者の落ち着いた言明が素敵でした。

Subversion は1年ほど前に知ってから、なんとか業務で利用しようと考えています。
ただ、自分の中で評価が終わっていないので周りに薦めにくく今日に至っています。

移行に踏み出せない1番の理由は、業務では CVS を使っていること。またUTF-8を内部コードにしていることから、日本語のサポートを検証しきれていないのも大きいです(CVSのように8ビットコードをそのまま触らないというほうが、まだ限界がわかりやすい)。あとは頻繁なバージョンアップの最中であったとか。
つまりは障害を含めた運用ノウハウを蓄積できていない自分が原因です。
3ヶ月くらいの手頃なプロジェクトで思う存分試したいなあ。

僕はCVSを使い始めて3年ほどになります。
思い出すと、『達人プログラマー』の次の記述を読んで猛烈にCVSを勉強したような記憶があります。

でも今のチームはソースコード管理システムを使っていないんだけど…
恥ずかしいと思ってください！そして、これが伝道師となる機会であると受け止めて欲しいのです。(以下略)
(89ページより)

当初は自分一人で使い、運用管理も含めたノウハウを貯めていきました。
次のプロジェクトには技術リーダー的な立場で参加したので、半ば強制的に「お前ら使え～」とCVSを使わせました。
そのうち、他のプロジェクトでもCVSを使っているところがあることを知り、CVSリポジトリを複数プロジェクトで共有する形に変えました。
最終的には部門が共有リソースとして運用するようにして、オフィシャルなソース管理環境に仕立て上げることができました。

ここまでやるのに3年かかったのは、いわゆる「設計書の変更履歴一覧なんて飾りです。偉い人にはそれがわからんのです」ということでしょうかねえ。

PoEAAの読書会だって

PoEAAを読みに談話室滝沢へ行こうオフ。というのがあるらしい。
激しく行きたい！
でも第1回は日程が合わない。次回の開催を待つことにしましょう。

『PoEAA(Pattern of Enterprise Application Architecture』 は通しで二度は読んでいますが、読書会なんてアプローチでもう一度味わうのも乙だなあ。

それはそうと、Martin Fowler の bliki 邦訳サイトはとても素敵。もうかなりの記事が日本語になっていて、kdmsnr氏はよい仕事をまとめていらっしゃるとつくづく感心します。

ビジネスシステムとMDA

Martin Fowler 御大の"Model Driven Architecture"を読みました。

全面的に賛成です。
僕も普段は UML をスケッチとしてしか扱っていません。だからこそ顧客というドメインエキスパートと話ができると思っています。
もしも UML 2.0 のような厳密さで描いていたら、そこから顧客に見せる資料を再作成しなければなりません。おそらくそれは スケッチとしての UML のような図になることでしょう。

僕は CASE ツール華やかなりし頃を知りません。
ただ、ビジネスシステムに「すべてを統合して扱うリポジトリ」を導入することの無力さは充分分かっています。

組み込みシステムや数理モデルなど、シミュレーションや系を扱うソフトウェアには MDA はとても有効だと思います。
情報システムの内部にモデル化することができる世界だからです。

一方ビジネスシステムは、情報システムを含む社会システムの一部を抽象してモデル化しています。
外在するものを MDA で *充分なレベルで* 扱えるとはとても思えません。「すべてを抽象できていること」を前提とするには、ビジネスシステムは可変要素が多すぎます。

MDA や xUML は夢として語りたくなる技術ですが、末端で適用する者としては着実を優先するしかありません。

【かつての某掲示板への投稿】

現状の普及帯のツールでは実装とシームレスにつながっているモデルは作れない。作れるのかもしれないが、残念ながらそのためのノウハウをまだ持っていない。
MDAの方向に進むのは確実だと考えているけど、いま使えるわけではない。
ツールを無理に適用するためにGenerationGapなりのパターンに沿ってモデルを描くのも本末転倒だと思う。

ネーミングの2chスレッド

仕事柄、２ちゃんねるのプログラム板をよく見る。
その中でかなり好きなのが、ネーミングを話題にするスレッドだ。気が向くとつらつらと長文を書くことも多い。

◆ネーミング倶楽部◆
クラス名・変数名に迷ったら書き込むスレ
クラス名・変数名に迷ったら書き込むスレ。Part2
クラス名・変数名等に迷ったら書き込むスレ。Part3 (現行)

「ネーミングに悩め」にも書いたように、分析や設計において名前による分類はとても重要な作業だと思う。
システム開発に特化した辞書やシソーラスがあってもよいかもしれない(パターンの一環になるかも)。

ときどき英語の綴り間違いをそのままにしているケースがあるが、見ているこちらが恥ずかしくなってしまう。チームメンバが間違えているのを見つけると、あの手この手でプライドを傷つけないように修正を図る。

【発見して切なくなった例】
  character → charactor
  level → lebel

でも開発が進みすぎていて直すには遅すぎる時は、そっと見ないふり…

「例外処理をなくす」？

「例外処理をなくそう」と題されたページを見つけました。

要旨はこんな感じです。

• 場合分けをプログラムするのは面倒だ


• ダミーデータを設けることで、場合分けの記述を減らそう

いわゆる「番兵法」みたいな発想です。

これって一般的な手法なのでしょうか。寡聞にしてこういう記述の設計を思いついたことがありません。
アルゴリズムを簡素化するためにデータを改竄しているようで、これでは本末転倒です。

NullObjectパターン的にも見えますが、データとアルゴリズムが分かれている手続き型構造で採用する考えではないでしょう。
(番兵法はNullObjectパターンと本質は同じです)

データとアルゴリズムのどちらが stable かといえば、もちろんデータです。
もしデータとプログラムの片方だけしか得られない場合にどちらを選ぶかといえば、もちろんデータです。
今のコンピュータはどこまでいっても所詮データプロセッサであり、データを生み出すわけではありません。

判断として「条件判定が必要」ならば、素直にそれをソースコードに表現してあげるべきだと思います。

例外への対処方法を分類してみる。

システムを設計する上で避けて通れない例外処理。
例外処理について、汎用的な枠組みの整理を試みます。
なお、プログラム文法としての記述がターゲットではなく、あくまでシステムの論理的機能を設計するのを目的にしています。ただ、実際にはプログラム言語上の実装に直訳に近い形で翻訳されるとは思います。

今回は「例外状況への対応方針」です。
なんらかの例外状況が発生した場合に、システムはその例外に対して何らかの対応を実施しなければなりません。
この記事では、その対応方針を分類します。

なお、下の記述内でプログラムコードで例えていますが、すべて説明のための仮想コードだと考えてください。

(1) 無視
何が起きても無視無視無視です。
VB(バージョン 6 以前) の On Error Resume Next に相当します。
あんまり使いたくありませんが。

(2) 継続
例外状況をそのまま無視します。つまり、例外を無視する例外ハンドラが定義されている状況です。
Java でいえば、こんな感じです。

try {
  1st process
  2nd process
} catch (FooException e) {
  // Do nothing.
}

無視するといっても、発生した例外に関する情報はどこかのコンテキストに保存しておく必要があるでしょう。

(3) 伝播
該当処理に設定された例外ハンドラに処理を委譲します。
例外ハンドラは階層関係に構成でき、上位層に処理を委譲することもあります。
Java でいえば、こんな感じです。

try {
  1st process
  2nd process
} catch (FooException e) {
  throw e;
}

もっとも一般的な状況だと思います。

(4) 再実行
該当処理を先頭から再び実行します。

• パスワード獲得→照合という一連の処理


• RDBでロック獲得に失敗して INSERT を実行できなかった場合

などの状況が当てはまります。この例外ハンドリングには、「最大実行回数」の属性を設定できる必要があるでしょう。

(5) 中止
該当処理が中断されるのは「伝播」と同じですが、例外ハンドラが設定されておらず、デフォルトの例外ハンドラが対応するような状況です。
システムで言えば、「DB必須のシステム利用中にDBMSに異常が発生したためデフォルトの「利用停止案内」画面を表示する」みたいなことです。

(6) 停止
システム自体の稼動を停止させるような対応です。
具体的な状況を思いつきませんが、必須の暗号がクラックされた場合などでしょうか。

上記のほとんどは、論文 "Exception Handling versus Fault Tolerance(Jorgen Lindskov Knudsen)" 内の分類そのままです。

一般的な情報システムを設計する際には、これくらいの分類でほとんどまかなえると思います。

Lotus Notes では困難な TestFirst

プロジェクトの合間で、何ヶ月か Lotus Notes のプロジェクトを手伝っている。
何年かぶりに Lotus Notes を触っていて思うのは、開発環境の貧弱さだ。

XP でも喧伝されている回帰テストをどうにか実施しようといろいろ画策してみたが、
IDE(Notes Developer)がそれを拒絶する。

xUnit 的なライブラリを作ろうと思えば作れるのだが、
プログラムのコンパイル自体は Notes 純正の IDEでないと行えない。
UI を通じてしかコンパイルできない時点で論外なのだが、
ライブラリの依存関係すら面倒を見てくれない。

たとえば「ライブラリA→ライブラリB」という依存関係があったとして、
ライブラリBをコンパイルしたら、ライブラリAを改めて編集・保存しなければならない。
これを "手動で" 行わなければならない。

海外のデベロッパで、Notesで TestFirst をあきらめてしまったことを Blog に書いている人もいる。
http://www.invisible.ch/archives/2003_07.html#000137

Notes を導入している企業では、なんでもかんでもフロントエンドを Notes にしたがる。
たとえ RDB が最適で Notes が不適当であっても。

Notes というプロダクトの設計思想はシンプルだし、アーキテクチャも嫌いではないから、
はやく本来の姿(不定形データの WhiteBoard 的なストレージ)に戻してあげたい。

ネーミングに悩め

たとえば要件分析するとき。たとえばコードを書くとき。
名前付けに悩む時間が一番長い。
逆にいえば、名前をかっちり決められれば、その後はスムースに運ぶ。

かつてかなり悩んだのはコレ。
---
ワークフロー内で発生するいろんなアクションを履歴として保存します。
アクション自体と一緒に、その実行を担当した者も記録します。
この「担当者」をなんと呼びましょう。
---

半日くらい悩んで performer としましたが、いまでも正解が何なのか分かりません。