void chachaki::Blog::main()

2013年04月

服飾分野にデザイナー(ファッションデザイナー)という職業があって、その隣には「パタンナー」という職業がある。どうやらパタンナーという言葉は和製英語らしく、正しくは「パターンメーカー」や「モデリスト」と言うらしい。

パタンナー:Wikipedia


服飾分野については自分の美的センスや造詣がないこともあり、気後れしてしまうのだけれど、どうしてもこのパターンメーカーについてはすごく興味があって、何度も検索してしまう。どこかに歴史をまとめた資料はあるのだろうか…


そもそも、パターンやモデルといった言葉は、ソフトウェア分野でもよく使われる。私の解釈だと、「モデル」は分析・設計段階において実装にできるだけ依存しない形で抽象化したシステムを描くものだと認識している。「パターン」はデザインパターンという形でソフトウェア分野に溶け込んでおり、よく引用されているのはGoFのデザインパターンだと思う。

デザインパターン(ソフトウェア):Wikipedia


パターンについてはパターンランゲージという形で井庭さんを中心に研究と実践が進んでいる。ある時期にはパターンランゲージ3.0という言葉で推していたけど、たぶん最近は違う形にまとめるのを模索していると思う。 3つのCでまとめた中の創造社会、なのかな。井庭さんは常にアップデートがかかっているのがすごい。


少し脱線したけど、ここで言うパターンランゲージという概念は、「状況」「問題」「解決」の3つをセットで捉えたもの、になっている。「状況」→「問題」のProblem Findingと、「問題」→「解決」のProblem Solutionは、セットで考えなくてはいけない。これがこれからの「デザイン」になるし、Problem Findingだけ、Problem Solutionだけ、という状態ではデザインとは言わなくなるのだろう。(だから、最近webで話題のデザインにおける中間生成物問題については、コンテキストに依るの一言で終わっていると思っていて、あまり反応できていない。)


上記とは別のルートで、服飾における「パターンメーカー」に興味を持った。こちらで言うパターンは型紙という意味が強いと思われる。優秀なファッションデザイナーの陰には優秀なパターンメーカーが居るらしく(ソースはWikipedia)(要出典)、どんな仕事なんだろうか。ふと検索して見つけたページがステキだなぁと思った。

■Mパターン研究所

http://www.m-pattern.com/aboutMPL/aboutMPL.html


「パターンが良ければ必ずきれいな服は作れる。

せっかく作るなら既製服よりも美しい服を」

http://www.m-pattern.com/aboutMPL/aboutMPL.html

この一言だけ見ると、ステキな言葉だと思った。そして、今自分が考えて悩んでいることにとても近くて。


たぶん私は人間中心デザインを学んだりした/しているけど、HCDの専門家になりたいという訳ではない。これは資格として取得しないという意味ではなく、HCDのエッセンスを絡めて、いいものを作りたいという意味が強い。でも私には綺麗なものを作るスキルが足りないから、そういった綺麗なものを作るための「道具」を、スキルを磨こうというモチベーションが大きいように思う。


デザイナーがこういうものをつくりたい!と言った時に、それを「型紙」としておこせること。ソフトウェアで言えば、デザイナー(やユーザーが)欲しいと言ったものを、ソフトウェアアーキテクチャで実現すること。たぶんそこは今、できる人はできるのだけど、属人性が高くて、おそらく一般化してないのだけど、「デザイン」と「エンジニアリング」を繋ぎたいという私の言葉は、たぶんそういうことなんだと思う。


特にオチはないです。

某人とfacebookチャットで盛り上がったのでログとして残そうかと。

「繰り返し」または「反復」の重要性はみんな認識しているけど、それを聞く人のこれまでの文脈がエンジニアリングかデザインかで意味が大きく異なるのではないか、という背景的な話からしていきます。


繰り返しの種類について

http://www.infoq.com/news/2008/01/iterating-and-incrementing

http://d.hatena.ne.jp/wayaguchi/20111030/1319926043

上記のモナリザの例で示されているように、「反復的につくろう」という時にはIncrementalとIterativeの2つが存在します。これはどちらも正しいし、しかし相容れないものだと考えています。これは「全体」と「部分」に関する捉え方が大きく作用していると思います。

思想的な話に広げてみます

ざっくりと西洋思想と東洋思想に分けた時、西洋思想では部分の集合(積み上げ)を全体と捉えて、東洋思想では全体と部分は関連するものの不可分なものと捉えているように思います。一方は医療的な分野で耳鼻科、精神科、内科、外科…と分けて人間に起こる病気や疾患など「全体」を各診療科という「部分」に分けていく考え方、他方は足つぼを押すと肩こりが治った、漢方を飲んだら◯◯が治った、といった身体を分割するのではなくある「部分」の作用が「全体」に影響を及ぼしていく、といった考えであると思っています。(ここは私自身掘り下げて考えてないので、間違っていたらご指摘いただけるとありがたいです。)

上記のような考えのもとに整理すると、「Incremental」は「全体は見えないのである程度目星がつく規模の部分を作って、見て、徐々に全体を見よう」とする態度における反復であり、「Iterative」は「ある対象物のおぼろげな全体をまず見て、それが作用するものを壊さないように部分を見ていく」という態度における反復である、というのが現時点での私の理解です。


ソフトウェア開発におけるプロセスの話に縮小してみます

こういった視点から見ると、「繰り返しが大事だよ」だけでは済まない違いが出てきてしまいます。

W. ウォーターフォール(と信じられている)プロセス

ソフトウェアエンジニアリングでよく出てくるプロセスとして。要件定義→外部設計→内部設計→詳細設計→(製造…?)→単体テスト→結合テスト→総合テストといったプロセスにおいては、まず全体を把握した上で部分に分け、その部分を作ってテストし、組み上げてテストし、全体をテストする、といったプロセスを踏んでいると考えられます。

これは全体を見るという意味ではIterativeなのですが、部分から作りあげるといった部分ではIncrementalであり、どっちつかずである印象を持っています。どっちつかずというと悪い印象になってしまいますが、あるチームやマネージャの能力によって、最適な反復ができる、という意味かもしれません。


A. アジャイルなプロセス

ナウでヤングなソフトウェアエンジニアリングでよく出てくるプロセス。アジャイルなプロセスでは、設計→実装→テスト、といったプロセスというよりは組織単位で見た「学習」のプロセスであるように感じています。

それはさておき、全体を一気につくろうとするとこの学習に対するフィードバックがなくなってしまうので、必然的に問題を小さくし、部分をつくっていく方策がとられるように思います。この意味でアジャイルなプロセスの本質はIncrementalであるように思います。もちろんIterativeな要素も最近は入ってきているような気がしますが、インセプションデッキの内容を見ていると、本当に大事な本質の部分(コンセプト)を共有しつつ、分解可能な単位を見極めるための全体を見ている、という感じだと思います。


H. HCD(人間中心設計)のプロセス

たぶん一部でしか広まってないのですが、人間中心デザインという考え方がありまして…「利用状況の把握と明示」→「ユーザーの要求事項の明示」→「ユーザーの要求を満たす解決策の作成」→「要求事項に対する設計の評価」という4象限をクルクル回しましょう、というのがHCDプロセスになります。デザイン思考などでも若干の修正はあるものの、概ね同じようなものだと思っています。(※私はエンジニアなので、他にデザインプロセスというものがあれば教えてください。

これはIterativeなアプローチだと考えています。まず、おぼろげながら感じている問題意識を利用状況調査→要求事項の明示で明確化して共有し、全体を形づくります。それを解決策の作成でざっくり作ってブラッシュアップ、という形でおこなっていきます。

このプロセス自体はプロダクトデザインの領域から出てきて受け入れられているという点からすると、反復のポイントとしてはIterativeであるように思います。


I. アイデア発想のプロセス

広義のデザインにおいてアイデア発想の重要性は高くなってきていると感じています。ここはこれまで明確なプロセスがなく、属人性の高い領域だったと思います。私が強い影響を受けている石井力重さんのスライドを見ると…

(URL)

「設定する」→「拡げる」→「絞る」→「強化する」というプロセスがあるようです。他にもあるように思いますが、これだけを見ると、あるアイデアの全体像ではなく、あるテーマの周辺における全体像を出しているように思います。いや、その前に…他の図ではありがちなループ構造がありません。そもそも「繰り返し」についてアイデア発想ではどう捉えているんでしょうか。どこかで聞いてみよう…


どうプロセスの中で反復をしていくか

脱線しました。ここからはどう開発プロセスの中で反復していくかといったことに焦点をあてたいと思います。

現時点で私が持っている案としては「チームでIncrementalかIterativeかを選択する・合意して進める」かと思います。不用意に混ぜない、ということがシンプルかなぁと。どちらが正しくて間違っているというものではない以上、変に混ぜてしまう危険性があるような気がします。これはエンジニアリングとデザインの融合を仕事のテーマとしたい私としては「ぬーん」となってしまう点なのですが。

よくアジャイルの説明に、ホールケーキをつくるとしてスポンジ→重ねる→クリーム→イチゴと層ごとの部分をつくるのではなく、ショートケーキのようなスポンジ~イチゴを含んだ完成したセットとしての部分をつくる、というものがあります。(最近聞かないですが

HCDなどのデザインのプロセスは、「そもそもホールケーキ作るんだよね?だよね?」という部分に多くの時間が割かれているように思います。「お菓子をつくる→ホールケーキをつくる」の部分を指していると思います。

なので、そもそもどの程度つくろうとしている対象についてイメージがあるか、といったことがあるように思います。分からないから作るならIncrementalになるし、分からないから考えるならIterativeになるし、といった具合です。


「試作」に関する知見を整理するとよいのではないか

あとは試作についての知見の整理が必要な気がします。

そもそも試作に関する言葉もプロトタイピング界隈(そんなのあんのか)での意図がつかめてないような気がしますが、「モックアップ」(使い捨ての試作)と「プロトタイプ」(本番でも使う試作)と「スパイク」(アジャイルでいう調査用の試作)、などなどがあるように思います。「ペーパープロトタイピング」もあるので、ごちゃまぜになるのですが。

某コミュニティのメンバーがやっている研究でプロトタイピングに関するものがあるのですが、それを見ていると、プロトタイピングの手法の広がりは求める効能によって分岐していたりします。例えば検討段階でのイメージ共有であったり、もう少し進んでインタラクションを暫定的にでも確認したいものであったり。こういった試作に関する知見を整理すると、IncrementalとIterativeの違いを認識しつつも融合する一つの方法であるように思います。


おわりに

以上、モヤモヤしていたので違いを考えるために吐き出してみました。

最近はグラフィックからインタラクション、情報構造、それを考えるための組織、サービス、社会…とどんどんデザインの対象が大きくなってきているように思います。そうするとデザインであればIterativeな考え方・方法がフィットするようになっていく感じがしています。ソフトウェアエンジニアリングではどうなのでしょう。アジャイルの文脈はIncrementalを軸に、Iterativeな部分に切り込み始めている気がします。

結論

・IncrementalとIterativeはどちらも有用なアプローチであり、どちらかを選択する方がよいように思う。

・プロジェクトに関わる個人の立場からすると、反復を求められている場合にIncrementalとIterativeのどちらを求めらているのかを意識する必要がある、また、現在はどちらに傾いているのかを見極める力が必要なのではないか

・IncrementalとIterativeはどちらかを選択するのが現状の最適解に思う。しかし、試作領域の分野が進展すると、世界が変わる転換点になるのではないか

『Experience Vision』という手法を解説した本があります。

背景の背景

これは制作中心メンバーの一人である千葉工大の山崎先生のブログに書いてある通り、「ビジョン提案型デザイン手法」という「構造化シナリオを核とした、新しい製品やサービスを提案するための手法」です。Experience Visionとは「ユーザーや顧客の先見と展望(Vision)を探り、これを実現すべく、企業や組織がこれに沿った経験や体験をモノやコトを通して提供すること」と定義されています。


また、この本は上記のブログに記載の通り、日本人間工学会アーゴデザイン部会のSIGで5年の歳月をかけて研究会・セミナー、ワークショップを積み重ねた上で執筆されたものです。そんな大きな年月をかけて作られた成果を利用できるなら是非使いたいところです。


背景

私個人としてはaiithcd2010(2010年11月頃)に一通りの流れを体験することができました。その頃はまだ本は完成していなかったので「構造化シナリオ法」までの体験でしたが、その後2012年の7月に著書が発売されました。


私が所属する勉強会コミュニティのDevLOVEで「Experience Visionのはじめかた」と題した勉強会が2012年9月末に開催され、その後Experience Visionが実務に活かせるのかといった視点で【素振り】を行なうワークショップを6人で5回ほど(約半年間で)行いました。そのメンバーの1人である滝川さんのまとめはこちら


といった形で、書籍が出版されてからだいぶ経っておりまして(やっぱりというかなんというか)みんな熱が冷めて注目していないところではあるのですが、(でも熱狂がいいわけではないので当然のことなんですがね!)そんな中でワークショップをやっていてあーこうやってみたいなーと考えてみたことがあります。


やっと本題

で、このツール・手法は「発想」のためのものだと認識していて、ToBeシナリオを創出する、そのように使うものだと持って本を読んでワークショップ素振りをしてきたのですが、これは後ろから遡って「分析」に使う、AsIsシナリオを描いたほうがいいんじゃないかなぁという考えが浮かんでいます。


そこに至るまでのこれまでの流れ

先日「デジタルゲームの面白さ分析ワークショップ」(講師だった中村さんは分析シートを公開しています)というものに参加し、面白いゲームを作るための方法2つについて考えていました。一つは実際にゲームを作ってみて、試行錯誤していく方法。世の中のゲームの大半はこうした試行錯誤の知見で作られているそうです(一部のスタープレイヤーがうんぬんという話は置いといて…)。もう一つは、面白いゲームのどこが面白いかを分析する、という方法だそうです。こちらはあまりオープンではなく、各社でやっているようですが、それをオープンにやりましょうということで、それが上記のワークシートを公開している意図なのだろうと思います。


他方、Business Model Canvasやピクト図解といったビジネスモデルを描く手法も多数出てきていますが、これらは本来ビジネスモデルの発想、ToBeを描くことに力点を置いているように思っています。しかし、現状はAsIsの分析に用いている人が大半というのが実情ではないかと思っているのです。


で、Experience Visionの苦しいところは実際にいいアイデアを発想してみないとExperience Vision Mapの価値が分からないところで、なんとか2周した今でもモヤモヤしたものが残っているのが正直なところです。道具に縛られてんじゃねーよ!という話もあるのですが、ここは一歩進めて、AsIsの分析に使ったらいいのではないかと思った次第です。



具体的に何するのよ

Experience Visionの方法を「逆回し」にやります。

インタラクションシナリオ→アクティビティシナリオ→バリューシナリオ→(ユーザー設定・ペルソナ)→本質的価値の抽出→プロジェクト目標、といった具合に具体から抽象へ戻って分析していく形にしたいなーと思っています。というのも、バリューシナリオ→アクティビティシナリオ→インタラクションシナリオというところで成功体験がなくて、意外とインタラクションシナリオベースで考えてしまっているワークが多いなーと思っています。結局行きつ戻りつ、という話で、それが推奨されているのですが、スタート地点がバリューシナリオか、インタラクションシナリオか、については大きな差があるように思います。


(バリューシナリオからできないのは発想が貧困だからだ!と言うのは簡単なんですが、そもそも「デキる人」ならこういったフレームが必要ないし、私のようなできない人向けのフレームだと思っているので、その辺の使い勝手をよくしていきたいなぁと思うわけです。)


というわけで

こういったことをやってみたいので、そのうちコミュニティか個人的にか何か言い出すかもしれません。気になった方は各種SNSでお声掛けください。

このページのトップヘ