chachaki::Blog::main()2013年04月2013年04月27日ソフトウェア分野における「パターンメーカー」にたぶん私はなりたい服飾分野にデザイナー(ファッションデザイナー)という職業があって、その隣には「パタンナー」という職業がある。パタンナーという言葉は和製英語らしく、正しくは「パターンメーカー」や「モデリスト」と言うらしい。パタンナー:Wikipedia服飾分野については自分の美的センスや造詣がないこともあり、気後れしてしまうのだけれど、どうしてもこのパターンメーカーについてはすごく興味があって、何度も検索してしまう。どこかに歴史をまとめた資料はあるのだろうか...そもそも、パターンやモデルといった言葉は、ソフトウェア分野でもよく使われる。私の解釈だと、「モデル」は分析・設計段階において実装にできるだけ依存しない形で抽象化したシステムを描くものだと認識している。「パターン」はデザインパターンという形でソフトウェア分野に溶け込んでおり、よく引用されているのはGoFのデザインパターンだと思う。デザインパターン(ソフトウェア):Wikipediaパターンについてはパターンランゲージという形で井庭さんを中心に研究と実践が進んでいる。ある時期にはパターンランゲージ3.0という言葉で推していたけど、たぶん最近は違う形にまとめるのを模索していると思う。3つのCでまとめた中の創造社会、なのかな。井庭さんは常にアップデートがかかっているのがすごい。Solutionは、セットで考えなくてはいけない。Solutionだけ、という状態ではデザインとは言わなくなるのだろう。(だから、最近webで話題のデザインにおける中間生成物問題については、コンテキストに依るの一言で終わっていると思っていて、あまり反応できていない。)上記とは別のルートで、服飾における「パターンメーカー」に興味を持った。こちらで言うパターンは型紙という意味が強いと思われる。優秀なファッションデザイナーの陰には優秀なパターンメーカーが居るらしく(ソースはWikipedia)(要出典)、どんな仕事なんだろうか。検索して見つけたページがステキだなぁと思った。■Mパターン研究所http://www.m-pattern.com/aboutMPL/aboutMPL.html「パターンが良ければ必ずきれいな服は作れる。作るなら既製服よりも美しい服を」http://www.m-pattern.com/aboutMPL/aboutMPL.htmlこの一言だけ見ると、ステキな言葉だと思った。今自分が考えて悩んでいることにとても近くて。私は人間中心デザインを学んだりした/しているけど、HCDの専門家になりたいという訳ではない。これは資格として取得しないという意味ではなく、HCDのエッセンスを絡めて、いいものを作りたいという意味が強い。私には綺麗なものを作るスキルが足りないから、そういった綺麗なものを作るための「道具」を、スキルを磨こうというモチベーションが大きいように思う。デザイナーがこういうものをつくりたい!と言った時に、それを「型紙」としておこせること。ソフトウェアで言えば、デザイナー(やユーザーが)欲しいと言ったものを、ソフトウェアアーキテクチャで実現すること。そこは今、できる人はできるのだけど、属人性が高くて、おそらく一般化してないのだけど、「デザイン」と「エンジニアリング」を繋ぎたいという私の言葉は、たぶんそういうことなんだと思う。~IncrementalとIterative~某人とfacebookチャットで盛り上がったのでログとして残そうかと。「繰り返し」または「反復」の重要性はみんな認識しているけど、それを聞く人のこれまでの文脈がエンジニアリングかデザインかで意味が大きく異なるのではないか、という背景的な話からしていきます。繰り返しの種類についてhttp://www.infoq.com/news/2008/01/iterating-and-incrementinghttp://d.hatena.ne.jp/wayaguchi/20111030/1319926043上記のモナリザの例で示されているように、「反復的につくろう」という時にはIncrementalとIterativeの2つが存在します。これはどちらも正しいし、しかし相容れないものだと考えています。これは「全体」と「部分」に関する捉え方が大きく作用していると思います。思想的な話に広げてみますざっくりと西洋思想と東洋思想に分けた時、西洋思想では部分の集合(積み上げ)を全体と捉えて、東洋思想では全体と部分は関連するものの不可分なものと捉えているように思います。...と分けて人間に起こる病気や疾患など「全体」を各診療科という「部分」に分けていく考え方、他方は足つぼを押すと肩こりが治った、漢方を飲んだら◯◯が治った、といった身体を分割するのではなくある「部分」の作用が「全体」に影響を及ぼしていく、といった考えであると思っています。(ここは私自身掘り下げて考えてないので、間違っていたらご指摘いただけるとありがたいです。)上記のような考えのもとに整理すると、「Incremental」は「全体は見えないのである程度目星がつく規模の部分を作って、見て、徐々に全体を見よう」とする態度における反復であり、「Iterative」は「ある対象物のおぼろげな全体をまず見て、それが作用するものを壊さないように部分を見ていく」という態度における反復である、というのが現時点での私の理解です。ソフトウェア開発におけるプロセスの話に縮小してみますこういった視点から見ると、「繰り返しが大事だよ」だけでは済まない違いが出てきてしまいます。(製造...?)→単体テスト→結合テスト→総合テストといったプロセスにおいては、まず全体を把握した上で部分に分け、その部分を作ってテストし、組み上げてテストし、全体をテストする、といったプロセスを踏んでいると考えられます。これは全体を見るという意味ではIterativeなのですが、部分から作りあげるといった部分ではIncrementalであり、どっちつかずである印象を持っています。どっちつかずというと悪い印象になってしまいますが、あるチームやマネージャの能力によって、最適な反復ができる、という意味かもしれません。アジャイルなプロセスナウでヤングなソフトウェアエンジニアリングでよく出てくるプロセス。アジャイルなプロセスでは、設計→実装→テスト、といったプロセスというよりは組織単位で見た「学習」のプロセスであるように感じています。それはさておき、全体を一気につくろうとするとこの学習に対するフィードバックがなくなってしまうので、必然的に問題を小さくし、部分をつくっていく方策がとられるように思います。この意味でアジャイルなプロセスの本質はIncrementalであるように思います。Iterativeな要素も最近は入ってきているような気がしますが、インセプションデッキの内容を見ていると、本当に大事な本質の部分(コンセプト)を共有しつつ、分解可能な単位を見極めるための全体を見ている、という感じだと思います。対する設計の評価」という4象限をクルクル回しましょう、というのがHCDプロセスになります。デザイン思考などでも若干の修正はあるものの、概ね同じようなものだと思っています。(※私はエンジニアなので、他にデザインプロセスというものがあれば教えてください。これはIterativeなアプローチだと考えています。明示で明確化して共有し、全体を形づくります。それを解決策の作成でざっくり作ってブラッシュアップ、という形でおこなっていきます。このプロセス自体はプロダクトデザインの領域から出てきて受け入れられているという点からすると、反復のポイントとしてはIterativeであるように思います。アイデア発想のプロセス広義のデザインにおいてアイデア発想の重要性は高くなってきていると感じています。ここはこれまで明確なプロセスがなく、属人性の高い領域だったと思います。私が強い影響を受けている石井力重さんのスライドを見ると...(URL)「設定する」→「拡げる」→「絞る」→「強化する」というプロセスがあるようです。他にもあるように思いますが、これだけを見ると、あるアイデアの全体像ではなく、あるテーマの周辺における全体像を出しているように思います。いや、その前に...他の図ではありがちなループ構造がありません。そもそも「繰り返し」についてアイデア発想ではどう捉えているんでしょうか。どこかで聞いてみよう...どうプロセスの中で反復をしていくか脱線しました。ここからはどう開発プロセスの中で反復していくかといったことに焦点をあてたいと思います。現時点で私が持っている案としては「チームでIncrementalかIterativeかを選択する・合意して進める」かと思います。不用意に混ぜない、ということがシンプルかなぁと。どちらが正しくて間違っているというものではない以上、変に混ぜてしまう危険性があるような気がします。これはエンジニアリングとデザインの融合を仕事のテーマとしたい私としては「ぬーん」となってしまう点なのですが。アジャイルの説明に、ホールケーキをつくるとしてスポンジ→重ねる→クリーム→イチゴと層ごとの部分をつくるのではなく、ショートケーキのようなスポンジ~イチゴを含んだ完成したセットとしての部分をつくる、というものがあります。(最近聞かないですがHCDなどのデザインのプロセスは、「そもそもホールケーキ作るんだよね?だよね?」という部分に多くの時間が割かれているように思います。「お菓子をつくる→ホールケーキをつくる」の部分を指していると思います。そもそもどの程度つくろうとしている対象についてイメージがあるか、といったことがあるように思います。分からないから作るならIncrementalになるし、分からないから考えるならIterativeになるし、といった具合です。「試作」に関する知見を整理するとよいのではないかあとは試作についての知見の整理が必要な気がします。そもそも試作に関する言葉もプロトタイピング界隈(そんなのあんのか)での意図がつかめてないような気がしますが、「モックアップ」(使い捨ての試作)と「プロトタイプ」(本番でも使う試作)と「スパイク」(アジャイルでいう調査用の試作)、などなどがあるように思います。「ペーパープロトタイピング」もあるので、ごちゃまぜになるのですが。某コミュニティのメンバーがやっている研究でプロトタイピングに関するものがあるのですが、それを見ていると、プロトタイピングの手法の広がりは求める効能によって分岐していたりします。検討段階でのイメージ共有であったり、もう少し進んでインタラクションを暫定的にでも確認したいものであったり。いった試作に関する知見を整理すると、IncrementalとIterativeの違いを認識しつつも融合する一つの方法であるように思います。おわりに以上、モヤモヤしていたので違いを考えるために吐き出してみました。最近はグラフィックからインタラクション、情報構造、それを考えるための組織、サービス、社会...とどんどんデザインの対象が大きくなってきているように思います。するとデザインであればIterativeな考え方・方法がフィットするようになっていく感じがしています。ソフトウェアエンジニアリングではどうなのでしょう。アジャイルの文脈はIncrementalを軸に、Iterativeな部分に切り込み始めている気がします。・IncrementalとIterativeはどちらも有用なアプローチであり、どちらかを選択する方がよいように思う。・プロジェクトに関わる個人の立場からすると、反復を求められている場合にIncrementalとIterativeのどちらを求めらているのかを意識する必要がある、また、現在はどちらに傾いているのかを見極める力が必要なのではないか・IncrementalとIterativeはどちらかを選択するのが現状の最適解に思う。Vision』という手法を解説した本があります。見る背景の背景これは制作中心メンバーの一人である千葉工大の山崎先生のブログに書いてある通り、「ビジョン提案型デザイン手法」という「構造化シナリオを核とした、新しい製品やサービスを提案するための手法」です。Visionとは「ユーザーや顧客の先見と展望(Vision)を探り、これを実現すべく、企業や組織がこれに沿った経験や体験をモノやコトを通して提供すること」と定義されています。この本は上記のブログに記載の通り、日本人間工学会アーゴデザイン部会のSIGで5年の歳月をかけて研究会・セミナー、ワークショップを積み重ねた上で執筆されたものです。そんな大きな年月をかけて作られた成果を利用できるなら是非使いたいところです。私個人としてはaiithcd2010(2010年11月頃)に一通りの流れを体験することができました。その頃はまだ本は完成していなかったので「構造化シナリオ法」までの体験でしたが、その後2012年の7月に著書が発売されました。Visionが実務に活かせるのかといった視点で【素振り】を行なうワークショップを6人で5回ほど(約半年間で)行いました。そのメンバーの1人である滝川さんのまとめはこちら。いった形で、書籍が出版されてからだいぶ経っておりまして(やっぱりというかなんというか)みんな熱が冷めて注目していないところではあるのですが、(でも熱狂がいいわけではないので当然のことなんですがね!)そんな中でワークショップをやっていてあーこうやってみたいなーと考えてみたことがあります。本題で、このツール・手法は「発想」のためのものだと認識していて、ToBeシナリオを創出する、そのように使うものだと持って本を読んでワークショップ素振りをしてきたのですが、これは後ろから遡って「分析」に使う、AsIsシナリオを描いたほうがいいんじゃないかなぁという考えが浮かんでいます。そこに至るまでのこれまでの流れ先日「デジタルゲームの面白さ分析ワークショップ」(講師だった中村さんは分析シートを公開しています)というものに参加し、面白いゲームを作るための方法2つについて考えていました。一つは実際にゲームを作ってみて、試行錯誤していく方法。世の中のゲームの大半はこうした試行錯誤の知見で作られているそうです(一部のスタープレイヤーがうんぬんという話は置いといて...)。一つは、面白いゲームのどこが面白いかを分析する、という方法だそうです。こちらはあまりオープンではなく、各社でやっているようですが、それをオープンにやりましょうということで、それが上記のワークシートを公開している意図なのだろうと思います。Canvasやピクト図解といったビジネスモデルを描く手法も多数出てきていますが、これらは本来ビジネスモデルの発想、ToBeを描くことに力点を置いているように思っています。現状はAsIsの分析に用いている人が大半というのが実情ではないかと思っているのです。Mapの価値が分からないところで、なんとか2周した今でもモヤモヤしたものが残っているのが正直なところです。道具に縛られてんじゃねーよ!という話もあるのですが、ここは一歩進めて、AsIsの分析に使ったらいいのではないかと思った次第です。Visionの方法を「逆回し」にやります。インタラクションシナリオ→アクティビティシナリオ→バリューシナリオ→(ユーザー設定・ペルソナ)→本質的価値の抽出→プロジェクト目標、といった具合に具体から抽象へ戻って分析していく形にしたいなーと思っています。いうのも、バリューシナリオ→アクティビティシナリオ→インタラクションシナリオというところで成功体験がなくて、意外とインタラクションシナリオベースで考えてしまっているワークが多いなーと思っています。結局行きつ戻りつ、という話で、それが推奨されているのですが、スタート地点がバリューシナリオか、インタラクションシナリオか、については大きな差があるように思います。(バリューシナリオからできないのは発想が貧困だからだ!と言うのは簡単なんですが、そもそも「デキる人」ならこういったフレームが必要ないし、私のようなできない人向けのフレームだと思っているので、その辺の使い勝手をよくしていきたいなぁと思うわけです。)というわけでこういったことをやってみたいので、そのうちコミュニティか個人的にか何か言い出すかもしれません。気になった方は各種SNSでお声掛けください。きTweet書いてる人ちゃちゃき。デザイン」に関わって得たもの。(1)「Amazonライブリンク」は提供を終了しました。