【メイキング】ジャンヌ・ダルクの生涯（ピクトグラム４コマ）

「たのしいインフォグラフィック入門」櫻田潤(BNN新社)の影響を受けて、情報編集の訓練のため、ピクトグラムの四コマ式トレーニングをやってみました。題材は、まだ記憶に新しい「傭兵ピエール」からとって、「ジャンヌ・ダルクの生涯」としました。

Step 1: ４コマのコマ割りを決める

Step 1-1: エピソードを洗い出す

最終的に使う使わないは深く考えずにエピソードを洗い出します。

1. フランス東部に、農夫の娘として生まれる
2. 神の啓示を受ける
3. ニシンの戦いでのフランス軍敗北を予言し、的中させる
4. シノンで王太子シャルル7世に謁見し、軍の指揮官に任命される
5. オルレアンでイングランド軍に逆転大勝利する
6. （首都パリではなく）ランスへの進軍を提案する
7. ランスにてシャルル7世の戴冠式を実現させる
8. パリへ進軍するも石弓の矢が当たって脚を負傷、撤退する
9. 家族とともに貴族に叙せられる
10. ブルゴーニュ公国軍の捕虜となり、イングランドへ引き渡される
11. ルーアンでの異端審問裁判により、異端の罪で火刑に処せられる
12. 百年戦争の終結後に、復権裁判が開かれ無罪となる
13. 20世紀になってローマ教皇により列聖される

Step 1-2: 始まりと終わりを決める

物語になるのは「2. 神の啓示を受ける」から「11. ルーアンでの異端審問裁判により異端の罪で火刑に処せられる」までなので、この２つを始まりと終わりに設定してみます。

Step 1-3: １番のエピソードを決める

ジャンヌ・ダルクを語る上で絶対に外せないのは、オルレアンでの奇跡の逆転大勝利でしょう。百年戦争の分水嶺となった戦いをジャンヌ・ダルクが勝利に導いたエピソードですので、「5. オルレアンでイングランド軍に逆転大勝利する」を１番とします。

Step 1-4: ２番のエピソードを決める

シャルル7世が王位に就いたことで、フランス王国は名実ともに復活しました。また、以降、負け戦も続いたことから、この辺りがジャンヌ・ダルクの絶頂期です。そのため「7. ランスにてシャルル7世の戴冠式を実現させる」を２番のエピソードとします。

Step 1-5: ４コマのコマ割り完成

ということで、４コマのコマ割りは以下のようになりました。

1. 神の啓示を受ける
2. オルレアンでイングランド軍に逆転大勝利する
3. ランスにてシャルル7世の戴冠式を実現させる
4. ルーアンでの異端審問裁判により、異端の罪で火刑に処せられる

Step 2: ピクトグラムを作成する

Step 2-1: ラフスケッチを描く

絵心ゼロの私としては、難しいステップです。まぁ、有り体に言えば子供の落書きですが、グラフィックデザイナを目指すわけではなく情報編集のトレーニングが目的なので、えいやっと恥をさらしてみます。

ラフスケッチ

１コマ目：神の啓示を受ける

天使がメールを届ける図で、神の啓示を表現してみました。雷マークも考えましたが、天罰っぽくなってしまったの却下しました。

２コマ目：オルレアンでイングランド軍に逆転大勝利する
有名なドラクロワの「民衆を導く自由の女神」から採りました。ジャンヌ・ダルクが旗を振り、フランス兵が槍を振るい、イングランド兵が長弓を捨てて逃げるという、ちょっと詰め込みすぎの図です。なお当時のフランス王国の旗は右の（槍の穂先の）紋様でしたが、フランスであることを分かりやすくするために現在のトリコロール(三色旗)を使用したいと思います。また従軍中、ジャンヌ・ダルクが男装をしていたことは有名ですが、それも無視して赤三角のスカートにしたいと思います。

３コマ目：ランスにてシャルル７世の戴冠式を実現させる

戴冠式でジャンヌ・ダルク自身がシャルル７世の頭に載せたわけではありませんが、まぁ、イメージということで。

4コマ目：ルーアンでの異端審問裁判により、異端の罪で火刑に処せられる

安易ですが、火刑です。

Step 2-2: 清書する

ということで、Web上で無料頒布されているピクトグラムなどを切り貼りしました。サイズや余白の調整が必要そうですが、そのあたりのグラフィック的なトレーニングは目的外ということで、割愛して完成ということにします。

The Life Of Jeanne d'Arc

ピクトさんと２杯めのコーヒーを

積読本解消ノ記録、其ノ参。

今週は２冊だけしか消化できませんでした。

１冊目は、「たのしいインフォグラフィック入門」櫻田潤(ビー・エヌ・エヌ新社)。日経サイエンスでも「グラフィック・サイエンス」というコーナーが設けられている通り、最近見かけることが多くなったインフォグラフィックの入門書です。
情報をコンパクト圧縮して、なおかつ分かりやすく表現するという能力は、グラフィックデザイナだけでなく、多くの人にとって有用な能力かと思います。ということで、「ジャンヌ・ダルクの生涯」を題材に、書中で紹介されていた４コマピクトグラムの作成トレーニングをやってみました（３冊目が読み終わらなかった原因です）。

The Life Of Jeanne d'Arc

２冊目は、「珈琲店タレーランの事件簿 2 彼女はカフェオレの夢を見る」岡崎琢磨(宝島社文庫)です。前作に引き続き、アマゾンの書評では毀誉褒貶があるようですが、軽い読み物としては個人的には１作目より高評価です。ミステリィというよりはサスペンス色が強いということもあるのでしょうが、前回のメインであった叙述トリックが、読者に対してというより、登場人物間の駆け引きとして使われているので、前作に感じたアンフェア感もなかったです。また京都駅、伏見稲荷、金閣寺、銀閣寺など、知っている土地が舞台になっているというのも楽しいです。

ソフトウェアの３つのインターフェイスThe 3 Interfaces of Software

ソフトウェアは以下の３つの存在に対して境界面を持ちます。

1. ユーザ
2. コンピュータ
3. 開発者

もちろん、

1. ユーザにとっては使いやすく
2. コンピュータにとっては計算しやすく
3. 開発者にとっては、保守も含めて開発しやすい

ソフトウェアが理想です。

必ずしもこれらは互いに対立するものではありませんが、

1. 全てを1つにまとめる必用があること
2. 人とコンピュータとでは得意／苦手なデータ構造やアルゴリズムが異なること
3. 人は立場によって欲する情報が異なること

等の理由よって、トレードオフの関係になることもあり、

なかなか理想通りにはいきません。

これだけでも大変なのですが、ソフトウェア開発においては、

ユーザと顧客とが異なる場合も少なくありません。

たとえ顧客とソフトウェアの間に直接の接点はなくても、

何分お金を出して頂くスポンサー様です。

開発者は顧客を満足させるために、

いろいろと考えなければなりません。

開発者は、(コンピュータも含む)４種類の異なる方々を

満足させるソフトウェアを設計／実装する必要があります。

大変なわけです。

構造化/クラス指向/オブジェクト指向/サービス指向Map Methods to the Abstraction Plane

先日のとある雑談のまとめ。その２。

前回の抽象化の基本２軸と照らし合わせながら
ソフトウェアの設計手法について、少し考えてみます。

1. フローチャート
2. 構造化設計/構造化プログラミング
3. クラス指向
4. オブジェクト指向
5. サービス指向

1. フローチャート
　「フロー」という名前の通り、
　動的な振る舞いを記述する手法です。
　条件分岐や繰り返し等もありますが、
　基本的に上から下に流れる１本道です。
　小さなバッチ処理であれば、これで十分ですが、
　構造の記述が容易ではないため　(つまり設計者に構造について考えることを促さないため)

　ソフトウェアの規模が少し大きくなると、
　使い辛い手法になってしまいます。

2. 構造化設計/構造化プログラミング
　階層的に抽象化されたプログラムの組み合わせとして
　プログラミングを記述する手法です。
　簡単に言えば「本の目次」のように
　プログラムを設計/実装することです。
　鳥の目から虫の目に段階的に変化していくということです。
　但し、「本の目次」であるため、前から順に読んでいくという
　フロー(=振る舞い)の記述も含んでいますが、
　１本道であるという点ではフローチャートと変わりません。

3. クラス指向
　さしあったって、クラス指向では
　　構造化プログラミングでの構造化を助けるために、
　　クラスという枠組み(箱)を提供している
　と考えれば良いでしょう。
　オブジェクト指向言語を導入したバッチプログラムで、
　よく見かける形態です。

4. オブジェクト指向
　バッチ処理の場合、振る舞いはほとんど１本道のため
　設計上は余り問題にはなりませんが、
　ユーザー対話型のイベントドリブン処理の場合、そうはいきません。
　様々な状態での様々なイベントに対して、
　適切な振る舞いを提供するというのが、
　大きな設計課題となります。
　そこで、構造とともに振る舞いをモデル化する
　オブジェクト指向設計が、もてはやされているわけです。
　とはいえ、イベントドリブン処理といえども
　一度振る舞いが決定されれれば、
　そこから先は(比較的短い)１本道です。
　構造化が重要なことに変わりはありません。

5. サービス指向
　鳥の目で、静的な構造を決定するときの手法の一つです。
　業務全体を鳥の目で見て、業務上の一処理を基本粒度として
　ソフトウェア群を構造化するという手法です。
　ソフトウェアの大規模化とクラウドコンピューティングの台頭により
　全体の構造がどうあるべきかということが、
　昨今のホットな話題になっているのでしょう。

ということで、雑談のまとめはこれで終わりです。

設計と抽象化The 2 Axises for Abstraction

先日のとある雑談のまとめ。その１。

そもそも(ソフトウェアの)設計とは何でしょうか？
広辞苑によれば、設計とは

　　…或る製作・工事などに当たり、その目的に則して、
　　工費、敷地、材料および構造上の諸点などの計画を立て
　　図面その他の方式で明示すること。…

とのことです。
「その目的」とは、何らかの問題解決でしょう。
「図面その他の方式」とは、実物を作るのではなく、
モデルを作るということでしょう。
「設計」のインスタンスが「実装」という考えです。
そこで、ここでは設計を
　「問題を解決する解(案)のモデルを作ること」
と定義して、
少し考えてみることにします。

1. 解(案)
2. 抽象化
3. 解はどこから来るのか？

1. 解(案)
　「解」ではなく「解(案)」としたのは、
　実際に作ってみるまでは、それでうまくいくのか
　わからないことも多いからです。
　なお、問題にはいくつもの説明が可能であり、
　そのため、解もいくつでも存在しえます。
　もちろん、解の良し悪しはありますが、
　最終的にはそれも価値判断でしかありません。

2. 抽象化
　実物を作るのではなくモデルを作るということは、
　抽象化するということです。
　抽象化とは、思考方法の一種で、
　　対象から注目すべき要素を重点的に抽出し、他は捨て去る方法
　です。
　そこで、何に着目し、何を捨てるかが問題になります。
　決まった答えはありませんが、ソフトウェア設計に限らず、
　抽象化に以下の２つの軸が広く使用されています。

　(1)鳥の目 <-> 虫の目
　(2)静的 <-> 動的

　(1)鳥の目 <-> 虫の目
　　鳥の目は、全体像に着目し、細部を捨て去ります。
　　虫の目は、細部に着目し、全体像を捨て去ります。
　　巨視的／微視的、マクロ／ミクロ、等呼び方は色々です。

　(2)静的 <-> 動的
　　静的な視点は、構造に着目し、振る舞いを捨て去ります。
　　動的な視点は、振る舞いに着目し、構造を捨て去ります。
　　データ構造とアルゴリズム、と言った方が判りが良いかもしれません。
　　会計でのストック／フロー分析も同じ手法です。

3. 解はどこから来るのか？
　これが一番問題なのですが、
　設計解を得るプロセスは明確ではなく、
　設計者の思いつきや閃きといっても過言ではありません。
　とはいえ、ゼロからでは思いつきや閃きは生まれません。

　設計中は、虫の目 <-> 鳥の目  静的<->動的 を
　行ったり来たりしならが、
　知識と経験を基にしたパターンマッチングや
　演繹／帰納／アブダクションを行っているのだと思います。

ということで、続きはまた明日。

RESTfulWebサービス設計課題 #04 リソースの特定とURI

ちょっと間が空いてしまいましたが、４回目の今日は、前回作成したER図等を元にリソースの特定とURIの設計を進めたいと思います。

0. 前回までの目次
#01 最初の構想
#02 要求
#03 提供データの特定とER図


1. リソースを特定する
(1)西暦年リソース
西暦年で各国の年号情報を串刺しするというコンセプトからして、西暦年は外せないでしょう。１つの西暦年に対する各国元号年の情報を持たせます。
なお、持たせる情報の詳細は次回予定のリソース表現の検討で考えます(以下、同様)。

(2)検索結果リソース
検索は機能で情報ではないですが、検索結果は情報ですのでリソースとして扱います。元号名、元号名の読み、天皇名、及び天皇名の読みで元号情報を検索した結果の情報を持たせます。

(3)元号リソース
元号の情報を持たせます。

(4)時代・王朝別元号リソース
時代・王朝ごとの元号一覧を持たせます。

(5)地域・国別元号リソース
各国/地域ごとの時代・王朝・元号の一覧を持たせます。

(6)地域・国別西暦年リソース
最初は日本しかありませんが、他の国の対応後は国指定で元号を取得したくなりそうです。その時、(1)の西暦年リソースだと余分な情報も含まれてしまいますので、国も指定出来た方が良いかもしれないと思いました。

(7)トップレベルリソース
このWebサービスのスタート地点。西暦年の指定、地域・国別元号リソースへのリンク、検索フォームを持たせます。


2. リソースにURIで名前を付ける
仮にアプリケーションのURLを「http://gengo.appspot.com」とします。
(1)西暦年リソース
西暦年リソースは西暦年で一意に識別できるので、西暦年がそのまま使えそうです。例えば、1092年は「http://gengo.appspot.com/1192」です。「年」は付けないことにします。可読性に問題はないのでプログラムで扱い易くするためです。

(2)検索結果リソース
まず、「/search」を検索クエリを受け取るリソースのURLとします。問題は、クエリパラメータです。
(a)文字表現はどのように扱うべきか？
　(a1)元号名と天皇名の漢字表現をどうあつかうか？
　　UTF-8で%エンコードした漢字表現を、そのままURIに使用します。
　(a2)元号名の読みと天皇名の読みは、ひらがな/カタカナ/ローマ字？
　　和暦だけをターゲットにするのではなく、中国/朝鮮/ベトナムまで含めるとどうすべきかちょっと悩むところです。ローマ字表記も各国ごとにばらばらで、いろいろな方式があるためどうしたものかと。
各国/地域の表音文字表現は下記の通りです。

• 日本：ひらがな、かたかな、ローマ字
• 朝鮮：ハングル、ハングルのローマ字表記
• 中国：ピンイン（ローマ字表記）
• 越南：クォック・グー（ローマ字表記）

中国やベトナムのように独自の表音文字がない(？、よくわかりません)ケースを考えると、ローマ字表記での統一が良さそうですが、実際にはアクセント記号も込みのため、単純にアスキー文字列で表現できるわけではありません。日本人ユーザーによる入力のし易さから考えて、今回は日本用には「ひらがな」(UTF-8の%エンコード)を採用することにします。つまり、ローマ字による表現の統一は諦めるため、読みによる串刺し検索ができなくなります。但し需要があるとは思えないので良しとしました。
その他の国は機能拡張時の検討事項として残しておきます。

(b)名前検索と読み検索とで検索結果リソースを区別すべきか？
名前は漢字で、読みはその他の文字になるため、使う側としては名前と読みとをことさら意識しないと思われます。ルールは分けないで同じ仕組みでのリソースとします。

(c)元号検索と天皇検索とで検索を区別すべきか？
リソース表現を工夫することで対応出来そうな気がしますので、一旦は区別せずに進めます。但し、天皇名は最初の機能からは落とすつもりですので、機能追加時には再検討を行います。ということで、クエリパラメータは慣例に合わせて「q」とします。

(d)地域・国別に検索したい場合はどう扱うか？
串刺しをデフォルトとし、国・地域別は階層を落として分けましょう。国/地域はUTF-8の%エンコーディングでは可読性が落ちるため英語表記とします。
「japan」「china」「korea」「vietnam」
なお、串刺しでの読み検索は、ローマ字表記を諦めたので、地域・国を省略できるということ以外にはあまり意味はなくなります。
まとめると、URIは以下のような感じです。

• 串刺し：「http://gengo.appspot.com/search?q=建」
• 日本　：「http://gengo.appspot.com/japan/search?q=建」
• 　　　　「http://gengo.appspot.com/japan/search?q=けん」
• 中国　：「http://gengo.appspot.com/china/search?q=建」
• 朝鮮　：「http://gengo.appspot.com/korea/search?q=建」
• 越南　：「http://gengo.appspot.com/vietnam/search?q=建」

(3)元号リソース
同じように考えます。但し、時代・王朝名と元号でのリソース重複を防止するため「gengo」を挟みます。元号と地域・国では、地域国を上位概念とします。理由は、使うときに「建長の日本」ではなく「日本の建長」で探すことの方が多いと思うからです。串刺しについては、各国が中国の元号をまねて付けたものもなくはないため、もしかしたら良い結果を産むかもしれません。

• 串刺し：「http://gengo.appspot.com/gengo/建長」
• 日本　：「http://gengo.appspot.com/japan/gengo/建長」
• 中国　：「http://gengo.appspot.com/china/gengo/建長」
• 朝鮮　：「http://gengo.appspot.com/korea/gengo/建長」
• 越南　：「http://gengo.appspot.com/vietnam/gengo/建長」

(4)時代・王朝別元号リソース
串刺しの情報は存在しません。「時代・王朝」は「era」として、それ以外は元号リソースと同様です。なお「＊＊時代」の「時代」は冗長なため含めないことにします。

• 串刺し：なし
• 日本　：「http://gengo.appspot.com/japan/era/鎌倉」
• 中国　：「http://gengo.appspot.com/china/era/明」
• 朝鮮　：「http://gengo.appspot.com/korea/era/李氏朝鮮」
• 越南　：「http://gengo.appspot.com/vietnam/era/阮朝」

(5)地域・国別元号リソース
同様に

• 日本　：「http://gengo.appspot.com/japan」
• 中国　：「http://gengo.appspot.com/china」
• 朝鮮　：「http://gengo.appspot.com/korea」
• 越南　：「http://gengo.appspot.com/vietnam」

(6)地域・国別西暦年リソース
「(1)西暦年リソース」の下位データと考えて

• 日本　：「http://gengo.appspot.com/1192/japan」
• 中国　：「http://gengo.appspot.com/1192/china」
• 朝鮮　：「http://gengo.appspot.com/1192/korea」
• 越南　：「http://gengo.appspot.com/1192/vietnam」

但し、例えば「http://gengo.appspot.com/japan/1192」のように西暦と地域・国の逆順は代理リソースとして、「301 Moved Permanently」で上記URIにリダイレクトします。

(7)トップレベルリソース
「http://gengo.appspot.com」


ここまで考えると、「(3)元号リソース」は串刺し用と地域・国別元号用とに分離した方がすっきりしそうですね。リソースの表記順も順番をかえた方が分かり易そうですし。まあ、正式なURIの仕様書は動くものができてからきちんと整備することにして、こんな感じで進めていきます。

あ〜、今日も文字ばっかりでした。

JIS規格ピクトグラムあれこれ

「JIS T0103 コミュニケーション支援用絵記号デザイン原則」に収載されている絵記号例（いわゆるピクトグラム）が(財)共用品推進機構のサイトで無償ダウンロード可能なことを知りました。それで早速ダウンロードして確認。

基本的には全部良く出来ていて、よく感じが出ている「204005 歌う」とか 

「303001 しょうゆ」と「303002 ソース」の区別の仕方とか、好きですね。

ただちょっと気になったこともあります。

1. ユニバーサルデザインを志向すべき

まず、JISの規格概要を引用します。

話し言葉及び文字表現によるコミュニケーションが困難な高齢者，障害のある人などが，絵記号を利用して自分の意思及び要求を相手に的確に伝え，正しく理解されることを支援するために必要とされる基本的な絵記号及びそれらの作図方法について規定。

対象者の中心が、高齢者と障害のある人となっています。観光立国を謳うのであれば、外国人をもっと意識すべきでしょう。また、そもそも視覚表現の強力さを考えれば 「話し言葉及び文字表現によるコミュニケーションが困難な」人に対象を限る必要はなく、全ての人をターゲットにすべきかと思います。
文化や風習の異なる人々は異なるメンタルモデルを持っているため、全世界での完全標準化は難しいでしょう。ユニバーサルデザインをベースにローカルデザイン(?)を上乗せする形で、世界標準を提案するぐらいまでいけると良いのでしょうけど...

2. 看護師のナースキャップは必要か？

「102004 看護師」です。非常に分かり易いかとは思います。ただ職業を外観で表すのは難しく、これを外すと分かり辛くなってしまいますが、ナースキャップが気になってしまいました。既に有名な話ですが、現在多くの病院でナースキャップは使用されていません(Dr.鷲崎の健康エビデンス 第３回 なぜナースキャップは廃止されたのか)。
ステレオタイプとして有効というのは分かります。しかし現実と乖離した(時代遅れとなった)メンタルモデルを維持/強化する方向に働くアイコンを使い続けるべきか、考えどころかと思います。

工業デザインの超略史

かなり乱暴ですが、工業デザインの超略史をまとめてみました。

　18世紀：産業革命
　19世紀：粗悪な工業品
　　　　　 アーツ・アンド・クラフツ運動(工業製品に伝統美術/伝統工芸を適用)
　　　　　 アール・ヌーヴォー(工業製品にオリジナルのデザインを付加)
　20世紀：モダンデザイン(工業製品を均質化/標準化することで社会格差の解消を狙う)
　　　　　 ポストモダン(無機質なモダンデザインからの脱却を狙うが奇抜なだけで終わる)
　21世紀：情報デザイン(人間中心の体験デザイン)

情報デザインとは、工業デザインにおけるルネサンスなのかもしれませんね。

参考文献


「情報デザインの教室」情報デザインフォーラム編(丸善)
Chapter1 情報デザインとは
1-1 情報デザインとはなにか
1-1-4 デザイン史から見る情報デザイン