AD | all

24時間Illustrator「愛(Ai)はクリエイティブを救う」

[119] エクスペリエンス・エンジニアリング

ソフトウェア開発環境展(SODEC)に参加した。三日間の会期中、一日二回、計六回のミニセミナーで話す。座ってくれる方ゼロの回もあり、なかなか精神的にタフなもの。広い会場の路地裏で話すようなものだから、しょうがない。

タイトルは、「エクスペリエンス・エンジニアリング」。テーマは、「体験は工学(エンジニアリング)的に生産可能なのか」。それに絡めて、Experience Design(XD)的開発手法について自分なりにまとめてみた。

●仕様変更に耐えられる開発プロセス

開発プロセスを考えると、昔ながらの「ウォーターフォール型」を否定できない。要求仕様/概要設計/詳細設計/開発/テスト、そんな感じで進んでいければいいに越したことはない。

でも、要求がどんどん変わっていく。クライアントの担当者が、こちらの提案に感化されて、そこから勉強始めるんだもの。そして、こちらもこちらで、その横揺れに応じて、よせば楽なのに提案を重ねてしまう。

そんな仕様変更に耐えられる、開発プロセスって何だろう。一般的には、要所要所に、スパイラル(試行錯誤的な巡回運用)を取り入れる形が主流だろうか。それはWebの世界だけでなく、他のアプリケーション開発でも同じ流れになってきているように思う。

最初に作った設計図(仕様書)が、最後まで有効であると考える方がおかしいという風潮にもなってきている。でも、最初にしっかりとした設計書を作らなくてもいいんじゃないかという、言い訳にも聞こえなくもない。だから、個人的にはウォーターフォール型を捨てきれない。王道だと思うから。

じゃあ、RIA(Rich Internet Application)システム開発のプロセスは、何も違いがないんだろうか。RIAコンソーシアムでも何度も話した内容だ。単純に、スパイラル部分が付与されただけで、本流部分は同じなのだろうか。

●「ユーザー」が見あたらない

SODECの会場で、そんな話をする。最初のプレゼンではいまいち自分でも答えが見えなかった。でも回を重ねるごとに、その間にSODEC会場で見聞きしたことが重なってくる。

ここ数年、SODECはほぼ毎年見には行っていた。コード生成やテストツール、タスク管理ツールや、デバッグ手法。毎年注視していたのはほぼ同じ領域だ。根本的に、どうやったら開発が楽になるのか。もちろん、全部を見れた訳じゃない。ご近所しか探索できなかったが、雰囲気は感じ取った気がする。

すぐそばで、派手なオネエさんを従えた大企業が、「リッチクライアント」製品のデモをやっていた。簡単にリッチクライアントが開発できます。エクセルなどの定型フォームに情報を入力して、クリック一つで、はいっ生成。ドラッグ&ドロップで部品をはめ込んで行けば、ほらリッチでしょ。

よどみない、きれいな台詞を暫く聞いていて、胸がむかむかしてくる。その開発プロセスのどこに、ユーザーが求める姿を考慮する部分があるのだろうか。こ難しい技術を並べて、作り手の生産性だけを、高めただけに感じてしまう。

RIA型開発で火が付く「仕様変更」は決まって、ユーザーとの接点だ。そこで作り手のエゴや短絡思考や配慮のなさが、開発/製造工程にまで影響して、大火事になる。なのに、SODECで語られる言葉に、「ユーザー」が見あたらない。

そうしたユーザを見つめる部分で、ブレがあったとしたら、その後の工程でどんなにきれいなプログラムコードが出来上がったとしても、無駄なんじゃないだろうか。そのブレを何とかするのが、今必要なトコなんじゃないんだろうか。

CASE(Computer Aided Software Engineering)がキーワードだった時代から、下流CASEの部分だけがどんどんと深化していったに過ぎない気がしてくる。もちろん、上流工程の大切さは誰もが言うし、専用のツールも体系も語られるんだけれど、何か観点の違いを感じてしまう。Webの現場と違う匂いしかしない。

そんな予感を覚えつつ、RIA型開発プロセスを、設計段階が「概要+詳細」という不可分なプロセスで、下記の特徴を持つものと説明した。

  • ビジネスゴールをエンジニア的に支援するすることを忘れない
  • 押し付けにならないように、エンドユーザの享受できるものを考慮する
  • 感覚だけではなく、学術的にも裏付けられた手法も多用する
    • ペルソナ/人間中心設計手法
    • ワイヤーフレーム/モックアップ/プロトタイプ
  • 常にユーザビリティテスト(自分はモルモット)
  • 局所的なスパイラルではなく、設計段階全体をスパイラル可能に
  • 様々な部分で「検証」可能なように作り込み、検証する

●エンジニアリングの本質

同時に、根本である「エンジニアリング」についても調べて、新たな発見があった。克元亮氏は、その定義を「技術を組み合わせて統合し、顧客に利便性を提供すること」としている。見つけたとき、少し目を見張った。
< http://allabout.co.jp/career/swengineer/closeup/CU20030106A/ >

何が新鮮だったかというと、「エンジニアリング」とは「?を提供すること」という部分。とかく、エンジニアリングとは、何かを「作ること」と定義されがちだけれど、この定義では違う。ソースコードを提供することでもない。利便性を提供することだとある。

まぎれもなく、これはビジネスゴールにどこまで加担できたかが、エンジニアリングの本質だといっている。つまり、使われないシステムを納品することは、エンジニアリングですらない。プログラム書きました、のレベルなのだろう。

システムがシステム単体で存在できた頃、人はその操作を無理やり覚え、システムに合わせて生きてきた。しかし、そんな時代はもう過ぎようとしている。システムは、それを操作する人間に合わせて作られるべきで、システム単体のデータの流れの速さが大切なのではなく、人間の操作も含めた上で付加価値をどれくらい生み出せるかが語られる時代になりつつある。

本来、企業が行なっている「システム投資」の意味はそこにある。ソフトとハードだけの世界で高性能を誇っても、企業としては価値はない。記録上の数字競争をしている訳ではない。社員(人間)が使った上での、生産性が向上しない限り、投資をする意味がない。

Webはそういった意味で、使いにくければ無視され忘れられるという過酷な環境で、次世代のアプリケーション開発の試行錯誤をしているのかもしれない。システムはデータに仕え、データは人間に仕える。忘れがちだけれど、Webでは当たり前の常識だ。原点に立ち返りつつ、セミナーで話をしつつ、自分の方が何か新しいことを得たような気分になった。SODECに感謝。

以上。/mitsui

ps. コンクリの上に立ちっぱなしはやはりキツイ。足から腰まで棒のよう。