オルタナティブ・ブログ > イメージ AndAlso ロジック >

ヴィジュアル、サウンド、テキスト、コードの間を彷徨いながら、感じたこと考えたことを綴ります。

設計者であるための、日々の心得 ~メルマガ連載記事の転載 (2011年10月24日配信分) ~

»

この記事は、メルマガ「デジタル・クリエイターズ」に月1回連載中の「データ・デザインの地平」からの転載です。

連載「データ・デザインの地平」
第11回 「
設計者であるための、日々の心得」 (2011年10月24日配信分)

恐れの感情が、慎重さを生む

その昔、昭和半ばまでは、設計の対象は「データ」ではなく、回路や重機や鋼構造物といった「モノ」が中心でした。

それらの設計には、強度計算が必須です。巨大な構造物が風や波や地震に耐えるのも、それを作るための重機が安定を保つのも、適切な部材が使われ、適切な構造になるように、正確な計算がなされているからです。数学が安全を守っているのです。当時、まだパソコンはありませんでしたから、設計技師は頭の中でシミュレーションを行い、計算尺や電卓を使って、強度を計算していました。

計算中に集中力が途切れたり、検算を一箇所でも誤れば、製造者や作業者の生命にかかわります。時折、ニュースでは、どこかで起こった惨事の生々しい映像が流れます。その原因が、設計以外の工程にあったとしても、悲惨な映像を見れば、ヒトの生命にかかわる仕事への恐れは強まります。そして、その恐れの感情は、高い倫理観につながっていたように思います。

ところが、設計の対象がモノではなくデータになると、ユーザーの生命にかかわる物騒な案件よりも、ユーザーの生活を便利にしたり豊かにする案件が増えてきます。そのような案件では、ユーザー獲得の機会損失や経済的損失が引き起こされるケースはあるかもしれませんが、生命が失われるケースはまず考えられません。データ設計が直接の原因で生命が失われたというニュースは、筆者は見聞きしたことがありません。

生命に直結しない案件では、データ設計者は、意識的に、設計責任の重さに対する恐れの感情を持ち続けなければなりません。その感情が自ずと作業を慎重に進めさせ、設計のクオリティを高めるからです。

生活を顧みることが、仕事の姿勢に影響する

複数のソーシャルメディアを利用するユーザーが増え、全世界のサーバーに蓄積されるデータは加速度的に増えています。端末のスペックは向上し、膨大なデータを迅速に処理できるようになり、開発者もユーザーも、以前ほどファイルサイズに頓着しなくなって、データ爆発へのカウントダウンは早まっています。

データの増加からは、2つの廃棄の問題が生じます。

1つは、データそのものの廃棄の問題です。設計者は、不要になったデータを削除しやすい構造を心がけなければなりません。

もう1つは、ハード面の問題です。データが増えれば、それを格納するための設備や機器が必要になります。それらを製造するための過程では、多くの資源が使われ、多くの廃棄物が生じます。また、耐用年数が過ぎれば、設備や機器自体が廃棄物となります。
この問題は、メディアの小型化や、データ記録方法の技術革新では、解決しません。技術進化の後を追うように、さらにデータが肥大化するだけです。
技術革新とデータ増加は、薬剤と薬剤耐性の関係に似ています。

どちらの問題についても言えることですが、データ設計者は、可能な限りデータ爆発に手を貸さないように、必要最小限のデータを蓄積する構造を工夫しなければなりません。
ハードウェアのスペックも通信速度も向上しているのだから、少々ファイルサイズが大きくなっても......などと自らを甘やかしてはいけないでしょう。

こういった問題を心に留めておくために、設計者は、自らの生活を顧みる必要があります。
生活をないがしろにすると、廃棄方法など考えない、研究成果の生み出しっぱなし、新システムの作りっぱなしに、疑問を感じなくなる恐れがあるからです。

コンピュータ化を進めてきた、現在のデータ設計者よりもさらに上の世代では、男性は仕事、女性は家庭という作業分担が一般的でした。男性の多くは生活を女性に任せていました。たとえば、食事では男性は食べる工程の担当者であり、その前後の工程には我関せずでした。
こうした生活からの仕事の遊離が、設計の前に廃棄方法について考えることをしない風潮を作り上げたのではないでしょうか。
生活を実践していれば、何かを生みだすよりも、廃棄する方が難しいということは分かるはずです。

蛇足ですが、宇宙にある機器や日本に数十基ある設備の廃棄方法の問題も、生活と仕事を遊離させた結果として起こったのではないかと思われてなりません。

長期的視野が、構造への影響を防ぐ

アプリケーションの運用期間が長期にわたると、データを取り巻く環境は、データ設計時とは変わっていきます。

その変化の多くは、技術仕様には無関係なものです。
たとえば、政治経済の動きや、法律の制定や廃止といった社会システム上の変化です。
海外事情や景気や世論、投票結果などが、制度に影響を及ぼし、既存の制度に適合するよう設計されていたデータの土台が変わるということが起こりえます。
また、存在のデバイス化時代には、ニューロエシックス・再生医療・量子力学の発展による、「一意なもの」に対する社会的な承認の変化が考えられます(詳しくは、本連載の過去記事を参照してください)。

どのような変化があろうと、データ構造を見直さなければならなくなったために、実装にも影響が及ぶという事態は避けなければなりません。変化を吸収し、データ構造への影響を最小限にとどめる設計を目指さなければなりません。
それには、データの利用期間と利用範囲を予測し、その間の変化を事前に察知したうえで、設計にのぞむ必要があります。

こういった予測をする力は、コンピュータよりも、ヒトの方が優れています。ヒトは航空写真を俯瞰するように先の道を見ることができますが、コンピュータは走りながら目の前に現れる道や標識を順次見ていくことしかできません。
にもかかわらず、データ設計者は、コンピュータからの助言を信じがちです。なぜなら、データの裏付けがあると他者に説明しやすく納得してもらいやすいからです。が、データとは、データ化できた情報でしかありません。知るべきことは、データ化できないこと、語りえないことの側にあります。自分の俯瞰した結果の方がたしかだと信じられるなら、そのような変化があると見てよいでしょう。

こうした予測力を磨くには、技術に集中するのではなく、専門分野以外の本を読み、芸術を鑑賞し、異なる年代や立場の人たちと触れあうことが必要だと思います。

設計の評価は、運用期間終了時に決まる

設計者は、設計工程を終えれば自分の作業は終了したと思い、実装後納品すれば案件は完了したと思いがちです。
しかし、納品段階で、それが良い設計なのかどうか、評価することはできません。
設計自体に破たんがないことは、良い設計の前提条件にすぎないのです。

前回、処理対象となるデータを入力する際のヒューマンエラーを減らすため、データ設計者は、ヒトを知る必要があると述べました。入力担当者のスキルとバックグラウンドを知り、ミスなく作業を遂行できるような構造を考えるのも、設計者の重要な仕事のひとつです。

また、設計者は、運用担当者の人となりを理解し、彼らが背伸びしなくても無理なく管理できるように設計しなければなりません。

そして、環境負荷を最小限にとどめるよう、データ増と、それに伴うモノの増加を抑制する構造を工夫しなければなりません。

さらには、データを取り巻く環境を予測し、その環境の変化がデータ構造に及ぼす影響を最小限にとどめなければなりません。

正しいデータが登録され、つつがなく運用され、無駄なデータを蓄積せず、システムがその役割を終え、1点の問題もなく、社会に役立ったと評価できたときに初めて、その設計は「良い設計であった」といえるのです。

さいごに

私の父は、港湾構造物や造船用クレーンの強度計算と発明を手掛ける設計技師でした(父は昭和一桁には珍しく、生活を女性任せにしない人でした)。図面の中で育った私の幼稚園児の頃の夢は、ロケットのエンジンの設計者になることでした。アポロ11号が月面に着陸する数年前のことです。

ところが、小学生になり、父の仕事ぶりを間近で見ていると、父と違って集中力のとぎれることがある私が設計士を目指すなんぞは社会の迷惑にしかならないと思うようになりました。設計責任の重さに怖気づいてしまったのです。今なら、手計算ではなく、コンピュータによるシミュレーションが可能なので、もうすこし往生際が悪かったかもしれませんが。

長じて、設計士は目指さず、イラストレーターとして就職したはずが、XMLという変化を俯瞰してしまったために、蒼くなりながらヒトの生命にかかわる案件を手がけてきました。

私は、怖がりなので慎重に作業を進めます。環境問題を重視してシンプルな生活を心がけています。技術書だけでなく文学や科学の本やフリーペーパーを読み、音楽や絵や詩に触れ、20代から80代までいろいろな年代の人と話をします。この記事で述べたことを、読者に対して語るだけでなく、自ら実践する人であり続けるよう精進したいと思っています。

本連載では、11回にわたりデータ・デザインについて述べてきましたが、Windows Phone の正式な開発環境も整いましたので、次回からは、RIAまわりの話題を取り上げていく予定です。


今回の記事に関心を持たれた方は、こちらもどうぞ。「XML設計の心得」無料のPDFブックです。※この本についての補足
XML、XML Namespace、XML Schema、XPath、XQuery、XSLT、LINQ to XMLの基本知識を踏まえ、XMLデータ設計者の心得について述べています(本文 236ページ、拡大図版PDF付き、2009年公開)。セミナーの教材として自由に印刷して利用できます。学習教材や、リファレンスとしても利用できるでしょう。

Xmldesign_2


「データ・デザインの地平」バックナンバー

≪ 第1回 UXデザインは、どこへ向かうのか? (2010/12/20)
≪ 第2回 そのデータは誰のもの? (2011/01/24)
≪ 第3回 子ノード化する脳 (2011/02/20)
≪ 第4回 多重CRUDの脅威(2011/03/14)
≪ 第5回 震災は予知できなかったのか(2011/04/18)
≪ 第6回 永代使用ポータル、クラウドがつなぐ生者と死者の世界(2011/05/16)
≪ 第7回  「脳活動センシングの進化が、作曲を変える」(2011/06/13)
≪ 第8回  「死にゆく者の意思は守られるか」 (2011/07/11)
≪ 第9回 Windows Phone 7.5 に見る"ヒトとコミュニケーションの形"(2011/08/29)
≪ 第10回 データ設計者は、ヒトを知れ、脳を知れ(2011/09/26)

Comment(0)

コメント

コメントを投稿する