メイン

デザイン思考で業務システム開発 アーカイブ

2013年9月29日

デザイン思考で業務システム開発

先日、「デザイン思考と経営戦略」(奥出直人著 NTT出版)という本の紹介をした。デザイン思考を使って、イノベーションを生み出し、経営戦略に組み込む方法を提言している。この対象は、ビジネスに供する新たな製品やサービスを創造することなのであるが、翻って、業務システムという商品を作るのもデザイン思考でやったらどうなのだろうかというのがこのエントリーの趣旨である。

このことを考えていた時に、そもそも業務システムって商品っていう意識でつくっているのだろうかと思ったのである。パッケージやソフトウエア製品はそうかもしれないが少なくも受託開発のものは作ったシステムは商品ではない。この場合の商品は人月だからである。パッケージやソフトウエア製品にしてもそれだけで通用しないから、アドオンだとかカスタマイズをするから、半分は人月サービスとの組み合わせだ。

ユーザは商品を買ったという意識があるのだろうか、何となくしっくり来ないのである。もちろん特定のお客さんに対して新商品開発のようなやり方は適さないのかもしれないが、従来の開発方法を見直すヒントになりやしないかと思うのである。デザイン思考でイノベーションを起こそうという会社の経営のための業務システムをデザイン思考からかけ離れたやり方で作っていていいのだろうか。ということで、もしドラではないが「もし、もし中小企業向けITコンサルが『デザイン思考と経営戦略』を読んだら」というトーンで連載してみます。

記事では、デザイン思考ワークショプ(中級編)に収められているステップでやるとどうなるかを書いていきます。ちなみにワークショップは11回、ステップとしては27あります。ワークショップの内容は下記のようになっています。

デザイン思考ワークショップ(中級編)
第1回 チームを作る
第2回 誰のために作るのかを考える
第3回 解釈学的民族誌
第4回 メンタルモデルを作る
第5回 創造性のジャンプ ― アイディエーション
第6回 コンセプトを作る
第7回 ペルソナを作る
第8回 スケッチからプロトタイプへ
第9回 フレームワークを作る
第10回 ポジショニング・哲学・ビジョン・ターゲット・セグメント・SWOT分析
第11回 プロトタイプを見せてビジネスを考えよう

なお、最後の2つは商品化というフェーズなので今回のものにはマッチしませんが、できたものの横展開をどう考えるかという見方もあるので言及しておくつもりです。さてどうなることやら。
  

デザイン思考と経営戦略
奥出 直人
エヌティティ出版
売り上げランキング: 70,324

  

2013年10月 9日

デザイン思考で業務システム開発(第1回 チームを作る)

さて新シリーズの第1回目です。チーム作りです。ステップに従って見ていきましょう。

ステップ1.自己紹介
参加メンバーが友だちになることが大事です。これは、作り手側と使い手側の交流という意味もありますが、部門をまたがるようなプロジェクトの場合、案外ユーザ同士がお互い良く知らなかったなんてこともありますから、最初によく理解し合うことが必要になります。

このあとは、デザインとは何か、デザイン思考とは何かを講義します。どういった考え方、どのような手順でつくっていくのかといったことをきちんと説明しておきます。この時点でわからなくても後でわかるようになるのでもかまいません。講義を行ったあとにチームメーキングを行います。

ステップ2.哲学とビジョンを作る
チームができたあとは、哲学とビジョンを作っていきます。この哲学とビジョンづくりは大変大事なステップなので十分に議論する必要があります。哲学とは信念でありニーズで、ビジョンは欲望でありウォンツである。これを文章にする。
哲学であれば、「こうありたい」ということを肯定文で表わす。難しかったら「問題意識」と言ってもいい。「これからの日本の会社では、個人の存在が大きくなるとともにその結集が必要となるため、組織能力が最大限発揮できるような業務システムを確立する」てなものでしょうか。

ビジョンは、「何を実現したいか」を一言で表現したものである。単純で明快で一つの文章で表わすことができないといけない。語尾は必ず「〜したい」となる。例えば、アップルのiPodの例で言えば「どこへでも自分の音楽を持ち歩いてもっと音楽を楽しみたい」である。

ここで大切なことは問題点の発見であり、その定義をすることではないということである。通常は、問題を考えようとすると、どうしても問題を定義して解決するという方法になる。システム開発でもほとんどがこの問題解決型の手法で進める。ところが、現実には定義できない問題が数多くあるような場合も少なくない。そうした場合にはデザイン思考アプローチが有効なのかもしれない。

当事者に今の問題点は何かとインタビューしても出てはくるかもしれないが、それが個人的な感想でしかないとか、本質から外れているかもしれないとか、ごく一部の意見で全体意見にはなっていないなんてことが起きる。ですから、最初にいくら一生懸命議論してもなかなか確定しない。定義できない「やっかいな問題」があるのだ。

そのためにはのちのち議論していきますがデザイン思考では、問題を定義する代わりにプロトタイプを作って当てはまることをします。最初は失敗するが、そこから多くのことを学んで再度挑戦することを繰り返すわけである。従って、哲学とビジョンは何度でも書き直すので、最初から完成度を上げる必要がないのだが、非常に大切であることには変わりはありません。
 

2013年10月17日

デザイン思考で業務システム開発(第2回 誰のために作るのかを考える)

前回では、チームメーキングを行い哲学とビジョンを作ることをしました。今回は、「誰のために作るのかを考える」です。また、ステップに従って見ていきます。

ステップ3.ステークホルダーを決める

ここは、業務システム開発では必ずやるところというか、プロジェクトを編成するような場合はステークホルダーの要求をきっちりと把握することが大事になります。PMBOKでは、ステークホルダーをプロジェクト・マネジャー、顧客・ユーザー、プロジェクトの母体組織、プロジェクト・チーム・メンバー というふうに規定しています。

デザイン思考では、もう少し顧客に寄せて考えているようです。ビジョンではこれからどんなものを作るかをウオンツで表現してありますが、それを使うのは誰なのかといったことが重要になるわけです。

ステップ4.技術の棚卸しを行う

技術の棚卸というとついビジョンを表現する技術を探すというように捉えがちですが少し意味が違います。アイデアや技術をたくさん集めて並べ、そしてそれをビジョンに割り振ってみるというやり方で、それによって自分たちの技術で実現可能なものを見つけるのだ。なおかつ哲学やビジョンがしっかりあるので、足りない技術やできないことが認識できる。

こうした考え方からいくと、パッケージありきでそれをどうアプライするかといったアプローチはやってはいけないことである。そもそも、アイデアや技術をたくさん集めてなんてこともあまりやらない。ただひたすら自分の持っている技術を使ってもらおうというやり方になってしまう。以前はこういうのをソリューションと言ったのだが。

ステップ5.フィールドワーク計画を立てる

技術の棚卸しと前後してフィールドワークに出かける計画を立てる。自分のビジョンを実現してくれるだろう「師匠」を探しに街に出るためのものだ。やみくも行くわけには行かないので誰のところにいくのか、利用者を特定していく。

業務システム開発では、現場ですよね。現場ではある現象が起こっているが、それは自分では経験したことがないことが多く、起こっていることを理解すればユーザーの生活がわかってくる。開発プロジェクトでは、よく現場ヒアリングとかアンケートといったことを行いますが、これはフィールドワークとは違っていて、大事なのは自らの目で観察して経験を拡大していくことで、この考え方はシステム開発でも同じです。生産管理システムなどの開発には取り入れられたりしていると思います。
 

2013年10月23日

デザイン思考で業務システム開発(第3回 解釈学的民族誌)

デザイン思考で大事なものがフィールドワークです。そのフィールドワークを行うのに解釈学的民族誌という手法を使います。民族誌というのはエスノグラフィーと呼ばれていて、いくつかの手法がありますがここではこの解釈学的民族誌という手法を採用することにします。ステップとしては次のようになりますが、いちいち説明するより全体の流れとして議論しましょう。

ステップ6.フィールドワークの準備をする
ステップ7.濃い記述を書く
ステップ8.フィールドワーク・マスターの記述をする
ステップ9.フローモデルを描く
ステップ10.シークエンスモデルを描く
ステップ11.アーティファクトモデルを描く
ステップ12.物理モデルを描く
ステップ13.文化モデルを描く

フィールドワークというのは参与観察(調査対象となる人たちとともに時間を過ごし彼らの世界を知ること)ですが、そのポイントは、観察対象と距離をおいてただ観察するのではなく、観察する相手の行動に自ら参加することが大切なのである。改善活動で生産現場を観察するなんてことはやられていますよね。それ以外のシステム開発でもユーザーの人たちを観察するのが大事でしょうね。

調査対象を「師匠」として考えてそこに弟子として入門するという感じになります。そして、観察した結果を時系列に従って観察したことを文章にする。これを「濃い記述」という。それが書けたらフィールドワーク・マスター(調査対象の師匠)についての情報を整理する。顧客プロフィールを作るみたいですね。

次に、5モデル分析になる。①フローモデル、②シークエンス(時系列)モデル、③アーティファクトモデル、④物理モデル、⑤文化モデルの5つである。それぞれ簡単に説明すると、フローモデルというのは、ワークフローなのだが、仕事を行うのにあたって必要なコミュニケーションの流れのといったほうがいいかもしれません。シークエンスモデルは、特定の人のどのような行動がどのような流れで行われているのかを時系列であらわしたものです。アーティファクトモデルというのは聞き慣れない言葉ですが、顧客がタスクを遂行するために作成し、利用するものです。物理モデルは活動を行っている現場を描いた図です。最後の文化モデルは、行動が行われている環境の文化を「影響者」と「影響」という形で図示したものである。

こうして見ると何やら、システム開発における現状分析、要求分析、課題分析といったものに近いように思いませんか。観察やキーマンへのインタビューにより、業務機能、業務フローを書き、タスクを整理して、現状システム図を準備するといったことに相当しますね。

いま挙げなかった最後の文化モデルというのが、つい軽視しがちになりますが非常に重要であると思います。企業文化とか組織風土といったものかもしれませんが、システム開発ではしょっちゅう利害対立や変革への抵抗といったことが起きます。これを解決するには文化的な力に負うところ大だと思います。

これはどちらかというと内部的な問題ですが、顧客との関係でも結局共感できるかどうかがカギで、それは共通した文化的空間に同居するということが大事なような気がします。これからのシステム作りは、単に私作る人、あなた使う人といった関係でないところまで行く必要があるのではないでしょうか。
  


2013年11月 6日

デザイン思考で業務システム開発(第3回 解釈学的民族誌(続きその1))

前回、解釈学的民族誌ということで、フィールドワークを行い、それをもとに濃い記述による民族誌を作成し、それを5つのワークモデルを分析する方法を述べた。調査者は複数のイベントやユーザーを観察することで彼らの間に共通する仕事のパターンをみつけることができ、そこから彼らの日常生活を支えるシステムを解釈することが可能になります。このパターンを特定の見方で具象化したものをワークモデルといいます。

5つのワークモデルとは①フローモデル、②シークエンス(時系列)モデル、③アーティファクトモデル、④物理モデル、⑤文化モデルの5つでした。この5つのワークモデルは業務システム開発の場でやっていることとの類似性に気がつきます。そこでシステム開発という観点から見ていくことにします。

①フローモデル
デザイン思考では、フローモデルを一つの仕事が複数の人間に分割され、それぞれが仕事を終えるためにどのように調整しているかを定義することです。仕事を行うにあたって必要なコミュニケーションの流れを示したものです。見出すべきは次のようなことです。

・ 仕事の責務はどのように任されるか
・ 一つの仕事を実行するために人はどのような違った役割を担うのか
・ 新しいタスクはどのように人に渡さられるか、誰から助けをもらうか
・ 仕事を完了するために一緒に仕事をする相手は誰か
・ 調整のために利用する物理的環境とアーティファクト(メモやメールなど仕事の途中で生成されるもの)は何か
・ 誰に結果をどのような形で報告するのか

これを見てどう思われますか?まさに業務プロセスだと思いませんか。ただ、組織的な仕事と個人の作業もいっしょくたに「仕事」と言っていて混乱するのですが、ある案件(これも仕事)があると、それをどのようなアクティビティ(これも仕事)に分割して、それを誰が責任を持つのか、また誰と一緒にするのかがあり、どのようなコミュニケーションにより遂行するのか、そして完了したら報告するという流れである。つまり、プロセスフローとタスク、参照情報、ロールなどを定義するという「プロセス要素表」を作ることとほぼ同義なのです。

②シークエンス(時系列)モデル
シーケンスモデルというのは、特定の人の行動がどのような流れで行われていたかを示すもので、時系列で表されます。行動の手順は、行動を起こすきっかけ、行動する人の戦略、達成されるべき目的、何を重要だと考えているのかを明らかにします。このモデルの特徴は、シークエンスの目的とトリガーを示すことにあります。

このことも業務システムでも大事なところですね。業務オペレーションをどのようにしたいかということです。業務プロセスでは、ユーザーの依頼に答えることが目的になり、案件という仕事レベルでは依頼の来方がトリガーとなり、タスクレベルだと、通知機能となります。ただ、このモデルは概略的なところは事前に決定できますが、細かなところはプロトタイプを動かしながら定義していくことになると思います。
 

2013年11月18日

デザイン思考で業務システム開発(第3回 解釈学的民族誌(続きその2))

前回は、フローモデルとシークエンスモデルについて見てきましたが、今回は残りの3つのモデルについてです。

③アーティファクトモデル
アーティファクトという言葉はなじみがないと思いますが、その意味は、顧客がタスクを遂行するために作成し、利用する有形のものすべてのことです。人は、目的を果たすための行動であるタスクを行う中でものをつくり利用し、行動に合うように修正を加えていく。

そうしたアーティファクトをフィールドワークに行った時に集める。それを絵や写真に、構成、戦略、目的といった情報をコメントとして入れたものにする。現場に行ってそこで作業する人たちが自分たちのタスクを実行しているのを観察しながらどんなアーティファクトを利用しているかをみてモデルを作成するのである。

④物理モデル
物理モデルというのは、簡単に言うと活動を行っている現場を描いた図です。行動というのは、物理的な環境の中で行われるわけで、その環境は行動の支援となる場合もあるし、逆に妨げとなる場合もある。つまり、すべてのシステムは、物理的な制約のもとにあるのでそこを観察していく必要がある。

業務システムを考える上でも注意すべきところで、どうしてもシステム的な観点が勝ってしまい、物理的な観点、例えば端末の位置とか移動の状態、あるいはセンサーの配置などを忘れがちになるので注意したいものだ。また、新たな業務システムがユーザの働く場所を再構成させることもありえるだろう。

⑤文化モデル
すべての行動は文化の中で行われます。行動が行われている環境の文化を「影響者」と「影響」という形で図示したものが文化モデルです。期待、要求、ポリシー、価値、そして行動に対する取り組みなどを定義します。影響者とは、組織内の個人、グループ、あるいは概念上の集団、外部などの行動に影響を与えたり、制約したりするひとのことで、システム開発などではステークホルダーなんて言われたりします。

もし、顧客に提供したりするシステムが顧客の文化やセルフイメージと矛盾したり、彼らの制約を考慮しないものであれば、そのシステムを利用しても効果が出ないので文化モデルは重要です。ただ文化モデルというのは目に見えない力を目に見える形にするのであるが、組織図と対応しないという点を留意する必要がある。システムと組織との関係はシステムが主で組織が従なのです。

こうした5つのモデルから調査を行ったメンバーで解釈ためのセッションを行って重要な事柄について理解するのだが、システム開発の要求分析の入り口となりますよね。顧客志向だとかいう時に作り手側がどれだけ顧客としての目線を持てるかという観点からも大事なところではないでしょうか
  

2013年11月29日

デザイン思考で業務システム開発(第4回 メンタルモデルを作る)

第4回は「メンタルモデルを作る」です。このメンタルモデルって何なのかを説明する必要がありますよね。説明的に言うと「人間が世界の中で起こるイベントを理解したり予測したりするために作る内面的なモデルのこと」となる。人々はそれぞれに持つメンタルモデルに基いて行動したり、反応したりするわけで、そうしたメンタルモデルをエンジニアやデザイナーが作るために民族誌調査を行ったのである。

メンタルモデルから新しい商品やサービスが生み出される。このことは業務システムの開発にとっても大変重要なことで、システムの行動やふるまいがユーザーのメンタルモデルと合致していると使ってくれるからである。われわれはメンタルモデル使って日常生活を営んでいるわけで、われわれが道具を認識して使う時にはメンタルモデルにしたがっている。コンピュータシステムはあくまで道具であるからメンタルモデルからの視点で捉えなくてはいけない。

メンタル・モデル作成のステップはつぎのとおりである。
ステップ14.ターゲット・ペルソナを作る
ステップ15.メンタルモデルを作る

誰のメンタルモデルなのかを明確にするためにターゲット・ペルソナを作成する必要がある。ペルソナとは簡単にいうと仮想ユーザーのことで抽象的な設定ではなくより具体的に設定するとよい。例えば不特定多数を設定すると多くの機能を詰め込んでしまい使いにくくなるので注意する。ただ、業務システムの場合はある程度幅広くしないといけないので難しいところだが、上手くバランスのとる必要がある。何でも言うことを聞いてこだわりの機能が増えないようにしたいものだ。

さて、ペルソナを決めたらメンタルモデルを作ることになる。そこで気をつけなくてはいけないのが、例えばコンピュータシステムを作る場合、民族誌調査から得るべきことは、どのようなコンピュータシステムが必要とされているか、ではなくて、調査した日常世界に新しい道具が導入されると、どのように人々の経験の可能性が広がるか、なのである。そこをデザインするわけである。

このあたりの考えかたは非常に参考になる。どうしても要件定義という形で必要とされるものを設計してしまうからである。そうではなくて業務システムはあくまでビジネスの現場の人びとの経験の拡大に寄与できるかなのだ。

つまり、メンタルモデルは分析を重ねた結果として、「発見」することではない。観察をしていると、「師匠」がある認識をすると、ある行動をすることがわかる。このセットにことなのである。何やらとらえがたいものであるが、文字による思考と視覚の思考もよって経験を目に見える形で表現することになる。システム開発におけるユースケースのようなものですが、先述したようにメンタルモデルを意識して記述したらよいのではないでしょうか。
  

2013年12月 5日

デザイン思考で業務システム開発(第5回 創造性のジャンプ ― アイディエーション)

ここまでは、ビジョンを作り、技術の棚卸しをして、民族誌調査と分析が終了し、さらにメンタルモデルを作り出した。この段階まででアイデアを生み出すための抽き出しができているはずである。この抽き出しにあるものを組み合わせていくうちに突然創造の瞬間が現れるのだ。アイデアを作るだけではだめでそれを統合するところまでもっていかなくてはいけない。ここから、アイディエーションに入るがそのステップは下記のようになる。

ステップ16.ポスト・イットによるブレーンストーミング
ステップ17.紙粘土によるブレーンストーミング
ステップ18.実物大モデルによるブレーンストーミング

要するに、目に見えるような形をだんだん実物に近づけながらブレーンストーミングを繰り返していくことになる。ここで注意しなくてはいけなのが、アイデアを出すのがブレーンストーミングだと勘違いしないことだ。その前にすでに技術の棚卸しだとか民族誌調査もしているし、哲学やビジョンも作っているから、それをふまえればアイデアはいくらでもでてくるのだ。それらのアイデアを統合してコンセプトにもっていく。

ここで話は脇道にそれるが、サッカー選手で感覚的で想像力豊かなプレーをする選手を"ファンタジスタ"と呼ぶ。ブルーノ・ムナーリは"ファンタジア"というアイデアを生み出す方法を提示している。ちょっと面白いのでその法則をあげておく。

①ある状況を逆転させたり、相反するもの、正反対なものを利用する。あべこべの世界。
②ある部位を何の変更も加えず増殖させる。
③ 視覚的類似の関係を見つける。
④ 色彩の交換。
⑤ 素材の交換。
⑥ 場所の交換。
⑦ 機能の交換。
⑧ 動きの交換。
⑨ ディメンジョンの交換。
⑩ 一つの身体に異なる要素を融合させる。
⑪ 対象の重さを変える。
⑫ 関係の中の関係を作る。

これは、視覚的なデザインの世界というふうに見がちであり、また発明というとつい工夫といった側面に目が行くが、それも大事だがドキドキ感ワクワク感のような感情に訴えるようなことも考えながらアイデアを作り出さなくはいけない。アップリとかダイソンなどの商品を見ているとそう思いますよね。業務システムもそんな風になったらいいなあ。
  


2013年12月11日

デザイン思考で業務システム開発(第6回 コンセプトを作る)

前回でアイデアをどんどん出すことを行いました。こんなことができたらいいなあとかこんなものがあったらいいなあというものをどんなものでもいいからためておきます。アイディエーションの段階ではこれがいいとかあれにしょうとか選別はしません。こうして作った大量のアイデアをいくつかまとめてコンセプトを作ります。

ここでちょっと戻るような話になるが、アデアを出すには特別な知識を持っているとか頭がよくなくてはいけないとか思いがちであるが、このデザイン思考のアプローチに準ずればフッツの人でもできてしまう。そんなに難しいことではないのだ。要するに大事なことは論理的な枠組みにとらわれないことなのだ。既成の概念や枠組みから離れることが重要である。

デザイン思考では問題発見までは論理思考で行う。今まで述べてきたように哲学とビジョンと技術の棚卸しを通じて問題の領域を探し出し、民族誌的調査を行ってそれを分析して問題を発見するが、これらは論理的思考によるものである。こうして発見した問題を解決するためのアイデアを得るのは創造的思考になる。そしてそのアイデアをコンセプトとして統合するのである。

さてそのコンセプトつくりのステップはつぎのようになる。
ステップ19.コンセプトを作る
ステップ20.コンセプト・チェックリスト

コンセプトを作るための統合化作業は、アラン・クーパーが提唱してこの方法は、目的主導型デザインと呼ばれる代表的な統合思考法である。フィールドワークを終え、魅力的なアイデアがいっぱい出てくる。魅力的かどうかはまず自分で主観的に評価する。そのときコンセプトが魅力的かどうかを確かめるためのガイドラインを紹介する。

(1) コンセプトの図を描いたときに、そこに人間が含まれているのか
(2) コンセプトをユーザが利用するときのコンテキストがきちんと描かれているのか
(3) 提示されているコンセプトはユーザのコンテキストに置いてみて、今まで存在していなかったものであるかどうか
(4) コンセプトが加わることで、コンテキストが魅力的になったかどうかを確認する
(5) コンテキストを明確にしてコンセプトを描く

これでビジョンからアイデアを出して、コンセプトにまとめるところまできましたが具体的にどうなるのかイメージできない人もいると思うので、皆さんがよく知っているiPodを例にして考えてみましょう。それぞれの定義と具体例は次のようになります。

「ビジョン」
 ユーザーがこれからつくるモノを使って叶えたいこと
「アイデア」
 ビジョンを実現するための個別具体的なアイデア。いくつもある
「コンセプト」
 アイデアを束ねるもの。ひと言で作るモノを言い表すフレーズで表現される

iPodの場合
「ビジョン」
 どこへでも自分の音楽を持ち歩いてもっと音楽を楽しみたい!
「アイデア」
  - 所有している曲のデジタルデータを持ち歩けるようにする
  - ディスプレイとコントローラだけの小さいデバイス
  - 専用のソフトウェア(iTunes)で曲を管理し、デバイスと同期させる
  - アルバム別だけじゃなくてアーティスト、ジャンル、年代別などで再生出来る
  - 再生中は曲のアートワークをかっこよく表示する
「コンセプト」
 持っている全ての曲を持ち運べるカッコいいポータブル音楽プレイヤー

どうでしょうか。だいぶイメージがわいたのではないでしょうか。カッコいい業務システムを作りたいなあ。
  

2013年12月19日

デザイン思考で業務システム開発(第7回 ペルソナを作る)

前回の作成したコンセプトをもとに、利用者が目的を達成するまでのストーリーを書くのがこの回の課題である。その方法がペルソナ・シナリオ法でアラン・クーパーが提唱しているものである。ちなみに、アラン・クーパーはマイクロソフトのVBを開発し、Windows3.1をWindows95へと再デザインしたことでも有名である。

その方法は、最初にペルソナ(=登場人物)を設定するが、ペルソナとは、それまでの調査などによって考えたモノを使う仮想のユーザである。ただ漠然とした設定ではなく、名前や性格も考えて特定の個人をイメージする。ここが大事なところで幅広い顧客に満足してもらおうとすると多くの機能をつめこんでしまい非常に使いづらいものになってしまう。ぼくは、いまだにテレビ・ビデオのリモコンが使いづらくてしょうがない。

だから設定したペルソナ一人を完全に満足させるモノをデザインするようにする。業務システムなんかだと割と使う人が限定されるからペルソナも設定ししやすいかもしれない。ペルソナを設定したら、そのペルソナが目的を達成する物語を作る。要するに「どんな人が、どこで、どのような使い方をするのか」を明示することを行う。

このとき気をつけなくてはいけないのが、技術とか社会関係とかの制約に縛られないようにすることである。この段階で、制約をかけてしまうとおもしろさだとか、楽しさだとかが失われてしまうからである。何でもできるはずだと思って進める。これを「魔法のシナリオ」という。これが書けると一気に商品の設計が具体化する。この魔法のシナリオを何度も修正していくうちに作ろうとしているモノの大きなアーキテクチャが浮かび上がるのだ。ステップとして書くと次のようになる。

ステップ21.コンセプトが利用されるコンテキストに関係する人々を明確にする
ステップ22.コンセプトを利用する具体的なユーザーを明らかにする
ステップ23.複数のペルソナを作る
ステップ24.スキットを行う

ここのところがデザイン思考の方法で最も大切なところである。デザイン思考はある問題を解決する具体的な道具を作る方法あるが、それは実践のなかで目的に到達するわけで、つまり機器と人間がインタラクションすることで、問題解決プロセスをシナリオとして記述する必要があるというわけだ。

業務システムの場合あまりこうした考え方が希薄なような気がする。つまり、ユーザがITを使って問題を解決するプロセスを動かすというシナリオを想定していないことが多い。機器と人間のインタラクションといっても、データを登録してエンターキーを叩けば自動的に解決してくると思っているからだろう。
  

2013年12月27日

デザイン思考で業務システム開発(第8回 スケッチからプロトタイプへ)

前回までにペルソナを設定してシナリオを書き、ある程度コンセプトの妥当性が検証できると、インタラクションデザインに進む。シナリオで詳細な動きの記述をしたら、実際に工作を行って、実践の中でコンセプトが検証できるプロトタイプを作ることになる。デザイン思考によるインベーションはこれの繰り返しになる。次のようなステップとなる。

ステップ25.コンセプトの詳細化
ステップ26.ビデオスケッチ

これまでは、まだ絵を描くように気楽に形やプログラムを作っていたが、こうした作業はいわばスケッチである。プロトタイプはスケッチで確認しは要素を組み上げて一つのシステムにしたものである。大事なのは、スケッチでインタラクションデザインの可能性を拡げ、プロトタイプで使えるかどうかを検証することである。そういう使い分けを行うのだ。

粗々のプロトタイプができたらターゲット・ペルソナからフィードバックをもらいながら、コンセプトをどんどん改善してゆくのだ。その時、全体性をともなうプロトタイプを完成させるまでの開発期間中、仲間うちだけで評価してはいけない。できるだけいろいろな人たちに見せてフィードバックをもらうようにする。

こうしたステップは、業務システム開発でも有効なやり方になるだろう。というか、従来に方法では考慮されていなかった部分である。ターゲット・ペルソナというのはシステムユーザだから、もちろん想定はするのだが、プロトタイプを作って、それを見てもらいフィードバックをもらうというのはやられていなかったと思う。

ここに書いたように、まずプロトタイプという概念がないし、ましておや早い段階で全体性を伴ったものがみられることもなかった。こうして、業務システムでもプロトタイプを繰り返し改善していけば、できあがったものが使いものにならないなんてことにはならないのだ。それが、開発期間中は開発者がそれぞれ部分的なシステムを抱え込んで開発し、最後につなぎあわせてできましたとなっても、結果使われないということがしばしば起こる。

これまでできなかったのは、プロトタイプが作れる技術、ツール、ソフトウエアなどが揃っていなかったこともある。製造業なんかでもそういう面はあったが、最近出てきた3Dプリンターでそのあたりが格段に改善されてきたので、IT業界でもシステムの3Dプリンター的なもの(ぼくの推奨はサイボウズ社のkintoneです)を使うことを薦めたい。

アイデアを形にするのがスケッチングで、そのアイデアを組み合わせて作るのがプロトタイプである。この統合作業には創造性が要求される。そのためには作ってから考えることが大切なのであるが難しい。作業自体は難しくないのだが、統合したときに「生きられたもの」にするのが難しいのだ。業務システムではこれができればビジネスの役に立つものになるのだ。
  

2014年1月 8日

デザイン思考で業務システム開発(第9回 フレームワークを作る)

コンセプトができたら、フレームワークの作成にとりかかる。この場合のフレームワークというのはコンピュータの世界でいうものとはちょっと違う。実際にどんなものになるのかをかなり詳細に決定することである。具体的には、スケッチングとプロトタイピングを繰り返して作り直しながら、徐々に作りたいものの輪郭を明らかにしていく。次のステップになる。

ステップ27.コンセプトを詳細化する

従来はデザインというとここから始まっていた。それをデザイン思考では上流から一連の流れとして捉えている。コンセプトを評価デザインのプロセスへと受け渡すためにフレームワークを構築することが必要なのだ。そこでの注意事項は次のようになる。
1. 全体を意識してコンセプトを作る
2. スケッチングを繰り返して失敗を恐れない
3. 構造に注目して、細部にこだわらない

このことは、システム開発の場合にも注意すべきことである。要するに全体観が大切なのだ。日本では割りと細部にこだわって、そこの完成度をあげようとする傾向が強い。木を見て森を見ないということになる。これができるためには、構造化、概念化ができるかどうかにかかっている。全体観がしっかりしていれば失敗を恐れずに細部がどんどん作り変えることができる。

日本人はこうしたことが弱いために、製品づくりにしてもシステム構築にしても細かいところの機能なんかは素晴らしいものをつくるのだが全体としてどうかと見た場合、余計なものがいっぱいついていたりする。大事なのは、全体の構造を考えて、部分をインテグレートして、それが調和するかを見ていく態度である。

コンセプトを構築するためにはデザインスキルが必要になる。それには、インタラクション・デザインとプロダクト・デザイン、グラフィック・デザイン、サービス・デザインの技法が必要になってくる。それらの技法は次のようになる。

技法1  スケッチングと物語を作る力を確認しよう。
技法2  コラボレーションを行い具体的なアウトプットが出るように、効果的なミーティングを行う。
技法3  コンセプトのゴールは明確に定義できているか。
技法4  良いアイデアを選んで残そう。すべてを生かしてはいけない。
技法5  アイデアができかけているときにそれを阻害する質問を思いついたら、それは別にあとで考えるようにする。
技法6  意思決定したらその理由を明確にしておく。
技法7  同じテーマで15分以上議論しない。

これも、プロダクト・デザインだけではなく、システム構築にもあてはまりますね。システム作りが単に機能の埋め込みに終わっている場合があって、そうなると担当がひとりでアウトプットを出してしまうことがある。繰り返しになるが、全体性の見極めと細部の詰めをバランスよくやるということだろう。そして、その結果をすべて説明できなくてはいけないのだ。

こうして、詳細化されたコンセプトが作られていく。手にとって使える道具であること、実践を見せること、デザインの三要素、統合、調和、輝きのすべてがあるかをチェックする。
  

2014年1月16日

デザイン思考で業務システム開発(第9回 フレームワークを作る(最終回))

フレームワークができるとそれを使うことができ、ユーザーが納得してくれたら成功である。初めのほうでフィールドワークに出て「師匠」を探して観察しましたが、メンタルモデルが「師匠」のものと一致したら、その瞬間からそのプロトタイプはあたかも以前からあったように使われだします。このようにフレームワークを作ることはプロトタイピングでは重要な作業である。この流れは次のようになる。

ステップ1 インスピレーションの源を探す。いろいろな事例や素材やデザインを探してコレクションする。分野を超えてかまわない。
ステップ2 デザイン言語を開発するいつかの方向を検討する。いくつもの要素をまとめて、ある方向性を決めてデザイン言語を開発する。例を作って試行する。
ステップ3 要素が何を意味するかを決める。イメージやノブなどの要素のデザインが決まってきたら、それぞれが何を意味するのかを決めていく。
ステップ4 実際の利用シーンでどのように要素が提示されるとよいかを決める。この作業を何度も繰り返す。
ステップ5 フレームワークとデザイン言語を一致させる。利用者にフレームワークを使ってもらって、そのときにどのようなデザイン言語を利用するかを決めていく。デザイン言語とはアクションとグラフィックな表現あるいは音の表現を組み合わせたものである。
ステップ6 デザイン言語が完成したらフレームワークに組み込み、デモができるような状態にする。これがプロトタイプである。

ちょっと、難しいところもあるがシステム開発でも実際に動くものを作ってデモすることが必要になってくると思うので基本的な流れは抑えておきたいものだ。こうして、できたプロトタイプを実際の現場のなかでさらに検証を重ねながら要求仕様を確定して、製造に向けて設計を行うことになる。

さて、要件には、データ要件と機能要件がある。データ要件とはシナリオに登場する人や物や行為の「形容詞」である。機能要件は人や物や行為の「動詞」と考える。シナリオをもとに簡単なフレームワークを作り、次に要件を探していく。絵に描くのだがこの段階では簡単でいい。ここで、インプットとファンクションとアウトプットを確認する。このあたりはまさにシステム開発と同じですね。こうしたものはスケッチとして絵にしておく。それらを時系列に合わせて整理する。これをキーパスシナリオと呼ぶ。

これもぼくは以前から「プロセスコンテ」とよんでいるものに近いような気がする。次の作業がビジュアル・デザイン・フレームワークの確定である。大雑把には上述したような形で進めていき、できあがったフレームワークをもとに実際のプロダクトが作られる。こうした作業はシステム開発の場ではなかなかやれていないところではないでしょうか。形式的にはアジャイルに似ているが、プロトタイピングというところの重要性を強調しておきたい。

ただ、最近では重要なこととしてただ単にものを作っただけで終わらせるのではなく、ビジネスとして受け入れられなければ意味がないというふうになってきている。すなわち、ビジネスモデルを書いて、分析評価するステップも必要なのだ。このプロセスは別のエントリーで書くので、このシリーズはここまでで終了とします。デザイン思考でシステム開発を行うことの有効性を感じていただけたでしょうか。
  

About デザイン思考で業務システム開発

ブログ「mark-wada blog」のカテゴリ「デザイン思考で業務システム開発」に投稿されたすべてのエントリーのアーカイブのページです。新しい順番に並んでいます。

次のカテゴリはオペレーション志向です。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。

Powered by
Movable Type