Archive for 2010年7月

デザイン思考ワークショップで富士ロック子さんをつくった@DevLOVE

7月 25, 2010

最近、勉強中のデザイン思考について、昨日(2010/07/24)、DevLOVEでワークショップが開催されました。
ワークショップの講師は、棚橋弘季さんでした。
『ペルソナをつくってそれからどうするの?』や『デザイン思考の仕事術』の著者としても知られている方です。

最初に「デザイン思考とはなにか」という説明を棚橋さんから受けました。
デザイン思考によるプロダクトの作成においては、ペルソナとシナリオの2つ成果物が大きな役割を果たします。
ペルソナというのは、つくろうと思っているプロダクトや解決しようと思っている問題に関わる「仮想」の人物像です。
一方、シナリオというのは、「仮想」の人物がプロダクや問題の状況下においてどのような行動をとるか、を考えるものです。

今回のワークショップでは、旅行サイトの集客を増やすことを目的としたサイトリニューアルを想定し、ワークを行ないました。
大まか流れとして、まずは3人の実在の人物の調査結果から2人を選択し、1人のペルソナを考え、シナリオを抽出します。
情報の抽出と整理には、KJ法を使用します。
その後、KJ法によってペルソナとシナリオを活かしながら、理想となるサイトについてペーパープロトタイプを作成し、終了、というものです。
だいたい1チーム5から6人に分かれて作業を行ないました。KJ法は以下のように壁に大きめの用紙を張っておこないました。

その分析の結果、私たちのチームはいかのようなペルソナを作成しました。

富士ロック子さん
-ライブ好きでネット好き
-アイスクリーム作りが趣味
-ライブがゆくのが目的で旅行する
-時間があって興味がそそられたら観光名所もゆく
などいうペルソナを作ったのですが、この時点ですでに講師の棚橋さんからは「アドバイスできない。笑」と言われてしましまた。

というのは、3人から2人を選択した時点で、あまりにも共通項の少ない人物を選択したために、2人の人物像がうまく統合できなかったためです。
ちなみに、課題終了後には、このペルソナづくりは非常に重要で、ここの誤りはプロダクトでは取り戻せない、というお話がありました。
考えてみると、ペルソナを作成されると、このペルソナ(富士ロック子さん)へ向けて、プロダクトを作成するのですから、当たり前ですね。
ということで、私たちのチームは、この失敗ペルソナ、富士ロック子さんの呪縛から逃れることはできず、ちゃんとしたプロダクトを作ることができなくなってしました。
ただ、個人的には、KJ法を使用して富士ロック子さんを作成するくだりが一番、面白かったのですが。

ちなみに、本来のプロダクトを作成する際には、実在の人物の調査は5人程度、この調査結果をKJ法により分析すると、分析だけでも1日ちかくかかるらしいです。

その後は、抽出したシナリオからユーザー(富士ロック子さん)要求や要求を満たすためのコンテンツを考える作業に移りました。

ユーザーの要求については、作成したペルソナや抽出したシナリオからあまりにも離れすぎてしまうと、ごくごく一般的なプロダクトになってしまいます。
こうなるとペルソナやシナリオを作った意味はなくなってしまいます。
と同時に、あまりにペルソナにこだわり過ぎると、偏ったプロダクトが生まれそうな恐怖もあります。
実際に、私たちのチームは、そもそも富士ロック子さんが偏ったユーザー像だったために、プロダクトが偏ったものになりました。
良いペルソナやシナリオがないと、よいプロダクトを生むことができないのでしょう。

最後に、上記で抽出した要求から考えだされたコンテンツを元にペーパープロトタイプを作成しました。

ペーパープロトタイピングは楽しんでやることが重要ですね。
あんまり「絵ごころないしなぁ」とか考えてやってもプロトタイプが作られませんし、作ってゆくたびにうまくなってゆくはずです、きっと。

以上が、私たちのチームで作成したペルソナ、シナリオ、ペーパープロトタイプです。
これらの一連の作業は、思ったよりも疲れると同時に大変楽しいものでした。

と、これだけで終わってしまうのはなんので、ワークショップを通じて学んだことを以下にまとめます。

<エンタープライズでもペルソナを書く意義はある>
ペルソナやシナリオを作成する価値はどの程度あるのでしょうか。
iPodのようなクリエイティビティあふれる商品を生み出したい、と考えるのならいざしらず、エンタープライズなシステムを開発するうえでどれほど価値があるのでしょうか。
想像の段階ですが、価値の1つに教育のコストの低減が考えられます。

棚橋さんいわく、デザイン思考の目的の1つは、イノベーションを起こすこと、すなわち、新しい価値観や生活の様式をユーザーに提案することです。
デザイン、としていまappleなど注目を集めているのは、この点についてでしょう。

そして、もう1つの目的は、ユーザーの”?”、疑問をなくすことです。
たとえば、なにかの道具、アプリケーションを目の前にしたユーザーが「いったいどのように使えばよいのだろう?」という疑問をなくす、これは非常に大切な事です。
というのは、エンタープライズ向けのシステムを刷新すると、今まで使い慣れていたシステムを捨てなければならないからです。そして、新たなシステムを使用するためには、その使い方を覚えなければいけません。
システム屋の目線からは、そのほうが情報管理もシステムの構成もすっきりと使いやすいシステムを作ったつもりなのですが、それを使うユーザーからしてみると今まで使い慣れていたシステムが使いづらいものになってしまうのです。
そのために、ユーザーの側では教育期間をもうけてシステムの使用方法をユーザーが覚えなければならず、システム屋は(システム屋の)みんなが嫌いなドキュメント作業にとりかかり、それほど質の高くない操作マニュアルを作らなければいけません。

現状、こうした教育コストを減らす試みの1つは、「元のシステムと同じ画面」で作る、というものです。
たとえば、汎用機上に載っていたシステムを、マイグレーションする際には、使い慣れているように「TAB」と「ENTER」で移動し、マウスでのクリックは出来ないようにするのです。
たしかに、それも1つの手段ではありますが、たとえば今年、新入社員で入ってくる人にとっては、操作方法がほとんどわからないでしょう。

新入社員、にフォーカスをすると、既存の社員との相対的な数は少ないうえ、教育費もある程度、見込まれているので教育という観点からは痛手を感じることはないかもしれません。
とはいえ、今後はダイバーシティという価値観から、目が見えないなどのハンディを抱えた人やそもそも日本語を母国語としない人々が増えたり、一斉、定期的な新卒採用がなくなったりした場合は、スキルセットも経験もバラバラで、一括で教育を施すことが難しくなってゆくでしょう。
そうなると、システム屋が書いた分かりにくい日本語のマニュアルをポンっと渡して、「使い方を覚えておいて」などとは言えなくなります。現在でも、そのようにできない部分はやはり先輩社員や上司が、その目的と使い方を教えなければならないのです。

そうしたちょっと遠い未来においては、誰でも直感的に使用方法がわかるシステムは教育のコストを減らすためには有効なのではないでしょうか。

ただ、「誰でも」というのは、ちょっと曲者な言葉です。
受託開発のシステムにおいては、法律など各業界の標準に則る必要がありますし、各会社の業務に則る必要があります。
もちろん、業務についても業界における標準のようなものがあるのですが、標準を越えた独自の部分は存在するのです。
その独自の部分を取りこぼさないことが、ユーザーのシステムの使いやすさに、通じるのだと思います。
なぜなら、その点が他の人たちにはなにその人達が固有に抱える問題であり、共有している価値観であるからです。
そして、その問題を解決し、価値観に訴えることが、使いやすさに通じると思うからです。
そのため、やはり「誰でも」というよりは、ターゲットとする「誰か」に届ける必要があるのです。

たとえば、教育のコストを下げるため、直感的に使いやすいシステムを、考えても、

・PCをよく利用する人なのか、全く使用しない人なのか
・業務知識がある程度ある人なのか、ない人なのか
・席に座ったま使用するのか、工場や売り場などでたったまま使用するのか

など、システムを使用するユーザーの使用状況や知識レベルを理解する必要があります。
ペルソナやシナリオはこうしたユーザーの行動や性質を理解するために作成されるのです。

棚橋さんの言葉で感銘を受けたのは、

同じものでも使用状況によって価値が変わる

という言葉です。
そのために、ユーザーが一体どのような人たちで、どのような状況のおいて使用するのか、をインタビューなどのユーザーへの調査やKJ法による分析、そして、ペルソナとシナリオをづくりと通じて理解するのです。
そして、こうした理解の先に、システムのコンセプトが生まれます。
ワークショップでも、どのようなユーザーに向けて、どのようなシステムを作るのか、というコンセプトを、ペルソナとシナリオを描けたチームのペーパープロトタイプは、しっかりとしていました。
ちなみに、ペーパープロトタイプの良さは、「たくさんの質問、疑問が発生すること」だそうです。
そのようなペーパープロトタイプは、ワークショップでは1チームしかできてきていませんでした。

情報収集→KJ法による分析→ペルソナ・シナリオづくり→プロトタイプの作成→プロダクトの作成、という流れの中では、1つ1つの作業が重要になります。
そして、前段の失敗は、後段ではなかなか取り戻すことできません。そのためにも、早めの失敗が重要です。
ペーパープロトタイピングはまさに、失敗に早く気づくための方法の1つでしょう。
また、直接、触れられてはいませんでしたが、安上がりに失敗する、という視点も必要なのでしょう。
早めに失敗しても、その時に大金を失っていては、失敗を取り戻すことはできません。
紙を使う、というコンセプトが、安上がりに失敗する、failcheapという観点を含んでいるのだと思います。

また、デザイン思考において、固定的なプロセスはない、と棚橋さんはおっしゃっていました。
なんだか、アジャイル開発に通じるものがありそうです。
ということは、知ることは簡単でも実践は困難ということでしょう。
今回、ペルソナ作りに失敗したことは、難しさに触れることができた、良い経験なのだと思います。

ランキング参加中。気に入ったら一押しお願いします!
人気ブログランキングへ

『パーフェクトソフトウェア』を作りたいなら読みなさい

7月 19, 2010

メディアマーカー用に文章を書いていたのですが、悪い癖で長い文章になってしまいました。
ということで、その文章をブログにしようと思います。

取り上げたい本は、ジェラルド・M・ワインバーグ氏の『パーフェクトソフトウェア』です。

私は、とくに以下の文章には感銘をうけました。

良いテストにするためには、リスクを軽減したいという要求と、過剰に情報を集めようとするリスクのバランスをとることだ。(p.6)

一般的にテストと呼ばれるものは、「品質を作り込む」ものではなく「品質を確認する」ものなのです。
テストをするだけでは、ソフトウェアの品質は上がらりません。
当間ですが、テストの結果を受け、ソフトウェアを修正しなければならないのです。
テストは、どこを修正すべきか、どのように修正すべきか、そして、その製品は出荷されるべきか、という判断のための情報を収集するための活動なのです。

ビジネスアプリケーションを作る世界では、ウォータフォール開発であろうが、アジャイル開発であろうがテストの必要性は疑いもないことです。
そして、開発現場における「テスト」としてTDDが出現してきた昨今、「品質を確保する」という使命は品質保証(QA)やテスターだけのものではなくなりました。
もちろん、今までも開発現場の主役である開発者にとっても、「品質の確保」は責務の一つであったのですが、TDDによりそれがより明確になったのです。
なにより、各々が携わる現場において、品質に目を向けて作業をする、という点は、品質の良いソフトウェアを作り込むうえでよいことです。
しかし、各現場において「テスト」という概念が生まれてことにより、開発現場や品質保証の現場、そこに携わる人々が混乱していることも事実です。

ワインバーグ氏が本書で取り上げるテストの概念は、そうした現場の混乱を解きほぐすものになるでしょう。
ワインバーグ氏は、テスターの仕事として以下の作業を取り上げています。

・発見のためのテスト
ソフトウェアを動かし、そのソフトウェアについて新たな情報を得るためのテストです。
たとえば、想定される業務シナリオをどおりに動くか、データ異常が起きた場合はどのようにアプリケーションが振舞うか、などをチェックします。

・絞り込み
想定される挙動とはことなる動きをソフトウェアがした場合、その原因はどこにあるかを調べます。
そのために、そのバグの再現方法と条件を調査し、バグの潜む箇所を絞り込みます。

・特定
バグがコード上のどこにあるか」、デバック作業などで確認します。

・重要度の決定
特定されたコードを修正することと、その修正のために入り込むリスクなどを判断します。
また、修正を行わなかったときのリスクも考慮に入れる必要があります。

・修正
修正を決定したコードを変更し、バグを取り除きます。
修正後は、バグを発見した時と同様のテストを行ない、バグが発生しないことを確認します。

・トラブルシューティング
トラブル発生時に、その障害を取り除いたり、回避したりするのための対策を行います。

・学習のためのテスト
バグを発見することを目的するのではなく、自らの興味に従ってソフトウェアの挙動を確認します。
ハッキングやリバースエンジニアリング、「遊び」ともいいます。

アジャイルな開発プロセスにかかわらず、こうした作業をいったい誰がやるのか、という点を明確化する必要があります。

TDDを例にあげれば、TDDで書かれるテストが本当に「発見のためのテスト」となっているのか、をよく検討する必要があるでしょう。
TDDのテストが、「発見のためのテスト」として機能しえない、と判断されるなら、別でその保障をする必要があります。
また、TDDが「発見のためのテスト」の一部と考えられるのであれば、TDDのテストコードの規約がひつようになったり、システムテストに含めるべきケースも変わったりするはずです。

また、システムテスト時には、「発見のためのテスト」はテスターがやる、「特定」については開発者がやる、など線引きを行う必要があります。
トラブルシューティングなどもどの立場の人間が行うか、またどのような順番で持ち回るか、などを検討しておく必要があります。
プロダクトに関わるすべての人が、責任を持つべきだ、といえば格好がいいのですが、責任の所在があいまいになります。
なによりも、「自分の仕事である」という自覚がない仕事をやらされると、その仕事を矯正されていると感じられ、メンバーの士気は大幅に低下します。

また、テストのコミュニケーションについて、以下のようなプロセスを取り上げています。
上記が、テストの作業を示すものならば、テストにおけるコミュニケーションにおける注意点と原則を示したものです。

・取り込み
能動的に情報を吸収する段階です。
この段階でもすでに情報そのものだけでなく、伝える人物や方法によって情報の取捨選択が行われている可能性があることに注意が必要です。
積極的に情報を収集するとともに、優先度による情報の整理も必要になります。
ただし情報にたいする「意味づけ」は行ないません。
そのためにも、1つの情報が意味することを3つほど考えて1つの意味にとらわれないように心がける必要があります。

・意味づけ
テストによって集められた情報を解釈し、情報が「何を意味しているか」を検討し、決定する段階です。
テストにたいする具体的な期待を明確にしていることが重要になります。
なぜならプログラムが「なにをするべきか」という目的によって、プログラムの動作がバグか否かが決定されるからです。
この作業は1人だけで行わず、複数のメンバーで集まって行なったほうが複数の観点から検討する必要があります。

・意義づけ
意義とはバグにたいして割り当てられる重要度のことです。
バグが製品にとってどれだけ深刻なものか、優先順位をつけ管理し、重要なものから対処してゆきます。

とくに修正の難しさと意義を混同して、難しいものを意義の高いものとして判断してはいけません。

また、意義は個々人の立場によって異なってきます。
それらの多くは、合理性よりも感情に基づいているからです。
そして、人々の感情は立場や受けているプレッシャーによって変化します。
この点を無視してはいけません。特に、意義づけを行うときは、自分自身の感情に目を向けることが必要です。

・反応
バグにたいする反応は、3つのフェーズに分けられます。
-見つけ(find)
-考え(figure)
-直す(fix)
難しいのは、このシンプルなプロセスを維持することです。

そのためには、なによりもプロジェクトの初期段階から正しくプロジェクトが運営されていなければいけません。
正しく運営されないプロジェクトは、終盤での混乱を招き、テストおよび修正のための時間を奪ってしまいます。
そして、とくに品質確認段階のテストで、その点を挽回することはとても難しくなります。

また、テストおよび修正のための見積を正確に行える準備が必要です。
プロジェクトの終盤では特に、「修正するに足るリソースが残されているか」を判断するための見積が重要です。
「修正のためのリソースがない」と判断されたバグが製品にとって深刻な場合は、その機能を外して出荷するか、最悪の場合は出荷そのものを取りやめる判断をする必要があるからです。

以上のようなテスト作業について、プロジェクトのどの段階でどのような立場の人々が責任をもって行うのか、そして、どのようなコミュケーションプロセスがテスト、ソフトウェアの品質に関わってくるのか、を考えてゆくことで、現場の混乱も緩和できるのではないでしょうか。
本書はそれらを整理し、実践することのヒントを与えてくれるはずです。

ソフトウェアの品質向上を目指す人達には、是非、手にとっていただきたい一冊です。

ランキング参加中。気に入ったら一押しお願いします!
人気ブログランキングへ

非忠誠の誓いとOut of Border

7月 11, 2010

twitterのタイムラインを眺めていたら、

「非忠誠の誓い(Oath of Non-Allegiance)」

という気になる言葉を発見しました。

調べてみると、アジャイル開発の手法の1つであるクリスタルを提唱するアリスター・コバーン(Alistair Cockburn)氏が提唱している議論や問題解決などにおける宣言のようです。
以下は原典からのページからの引用です。

I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation.

私は、現在の状況に一番適したアイディアを探すために、どんなアイディアもその発信元によって排除することなく、流派や派閥(schools and heritages)を超えて議論することを約束する。

共感を覚えると同時に、問題解決において常に意識をしておきたい言葉ではないでしょうか。

ちなみに原典はこちら。
http://alistair.cockburn.us/Oath+of+Non-Allegiance

平鍋健児氏による和訳はこちらです。
http://blogs.itmedia.co.jp/hiranabe/2010/07/oath-of-non-all.html

 コバーン氏が提唱する誓いを守ることは、非常に難しいでしょう。
問題解決のためにアイデアや考えを議論する場においては、どうしても自分の立場を守りたくなるものです。
そして、立場を守るということは往々にして「問題を解決する」ことで行われず、持論が支持されることや相手のアイデア、ときには人間性を否定することで行われます。

問題解決を目的に行われる議論は、議論することそのものや自身の有能さを示すために行われるわけではないのです。
コバーン氏の提唱する誓いは、問題解決における議論を目的と心構えを端的に表した良い誓いだと思います。

もう一つあわせて覚えておきたい言葉あります。
それは、「Out of Border」という言葉です。
この言葉は、NHKのテレビ番組で、雅楽師の東儀秀樹氏がお話されているなかで出てきたものです。
その言葉を意訳すると以下のとおりです。ただし、テレビ番組で録画をしていないこと、そして、文脈を私が補ったものですので、正確ではありません。

Out of Borderに似た言葉にBorderlessという言葉ある。
ただ、この2つの言葉は決定的に違う意味を持っている。
Borderlessは、境界を取り払いすべてを1つにすることで、理解し合おうとする。
しかし、境界は必要だからこそ存在している。
Out of Borderはその境界の存在を認め、自らが境界を越えることで、境界の向こう側にいる相手を理解しようとする。
だからこそ、境界の向こう側にある相手の価値観や大切しているものが尊重できる。

私には、この東儀氏が「Out of Border」という言葉に込めた思いが、コバーン氏の提唱する「非忠誠の誓い」の根底にある思想につながるように思えます。
我執を捨て、こだわりにたいする固執を捨て、相手の価値観と思想を尊重しながら、相手の境界へと踏み込む。
そうした地点で行われる議論が、多くの問題を解決するのでしょう。

この「非忠誠の誓い」にサインしたい方は、上記の原典のページに行き、コメントを付けてください。
過剰なこだわりを捨て、豊かな議論により、素晴らいアイデアを産み出してゆきたい方は、サインを是非。

ランキング参加中。気に入ったら一押しお願いします!
人気ブログランキングへ

ソフトウェアのコモディティ化を防ぐデザインの力

7月 4, 2010

私は、これからのシステムの受託開発業において、デザイン的な要素が必要だと考えています。
私の言う、デザイン的な要素とは、
・デザインにおけるものづくりのプロセス
・デザインにおける思考や発想法
・デザインにおけるユーザーの体験志向
などをさします。

こうした要素の1つ1つがいったいどのようなモノなのか、という言及は今回は避けます。
今回は、こうしたデザインが志向する価値観がどうしてシステムの受託開発に必要だと考えられるのか、について書いてみたいと思います。

システムの受託開発において、デザイン的な要素が必要である理由、それはソフトウェアがコモディティ化されているからです。
たとえば、私はwebの無料サービスで家計簿をつけています。
また、レコーディンダイエットでも無料のwebサービスを使用しています。
一昔前であれば、無料で使用できなかったようなサービスが、web上ではすでに無料で提供されています。

また、salesforce.comが代表するようなクラウドのSaaSと呼ばれるサービスも、ソフトウェアによるサービスのコモディティ化を推し進めています。
SaaSとよばれるサービスでは、たとえば、簡単な勤怠管理システムや社員情報の管理、または顧客情報の管理などのシステムは、すでに利用可能な状態で用意されています。
これまで、ユーザーは、使用したい機能を自社で内製できない場合は、アプリケーションという単位で業者に発注し、その機能を使っていました。
しかし、SaaSと呼ばれるクラウドサービスでは、本当に必要な機能をサービスという単位で手に入れることができるようになりました。
たとえば、社員情報が管理したければ、アプリケーションをつくるような手間を掛けず、すでにあるサービスを利用できるようになったのです。

くわえて、いままでアプリケーション単位でサービスを享受しようとすると、そのアプリケーションを動かせるリソースをユーザーはみずから用意しなければなりませんでした。
これは初期費用が非常に高く、また、そのメンテナンスが必要なことから、場所、電気代など維持費も高くつきます。
さらにメンテナンスを自社で行えない場合は、外部に委託しなければならず、人件費もかかるのです。

受託開発会社は、そのユーザーのリソースやサービスの維持を、保守業務という形態で請け負うことで安定的な収益を確保してきました。
保守業務は、受託開発を行う会社にとって、ストックビジネス、として扱われてきました。
そのため、システムの受託開発は、ネットワークやハードウェアなど、俗にインフラ周りといわれる知識をもつことが重要であり、その知識が付加価値となっていました。
しかし、クラウドサービスでは、とくにインフラ周りといわれる業務は、クラウドサービスを提供する業者の仕事になります。
こうした点からも、システムの受託開発をしていた会社の持っていた価値は、失われてしまうのです。
このようにアプリケーション、およびシステムの受託開発における価値がコモディティ化されてゆく中で、システムの受託開発はどのような付加価値を提供するべきでしょうか。
私が考える最良の付加価値は、

ユーザーが抱える問題を発見し、解決する

ということです。
受託開発において、よく言われ、肝にも命じなければならないことは、

ユーザーは往々にして自らの要求を理解していない

という事実です。
こうした状況に対応するためには、よく言われるたとえですが、ドリルを欲しがっている人はドリルを欲しがっているのではなく、ドリルで開ける穴が欲しいのだ、という考え方が必要なのです。
こうした考えに対応するプロセスをもっているのが、デザイン、という要素なのです。

つまり、ユーザーが「勤怠管理システムが欲しい」といったとして、本当にそのアプリケーションを開発し、提供することは依頼した顧客の利益なるかは不明です。
上述したように簡単な勤怠管理システムなら、SaaSとして提供されているものがありますし、管理項目がすくないのであればエクセルで十分、ということもありえます。
また、自社特有の業務について、コストダウンを図るためのシステム化を考えている顧客の要望が、実はシステム化することで他の業務が煩雑化することもありえます。
システムにより業務を自動化して効率を図ろうとする顧客の要望が、実は他の業務がボトルネックとなっているため他の業務をシステム化したほうがより有効な場合もありえます。

このように、ユーザーなど本当に問題意識を持って解決に当たっているにもかかわらず、その方向がユーザー自身で理解できていなという場合は、少なくないでしょう。
そして、こうしたユーザーの状況を解決すること、解決の手助けをすることが、システムの受託開発の大きな付加価値であることは間違いありません。
すくなからず、この価値は、「今後」ではなく、「すでに」、そして、「常に」ユーザーから求められてきたものであるはずです。
私がデザインがシステム開発に必要である、と考えるのは、この点についてです。
すなわち、ユーザーの課題を掘り起こし、整理し、解決する、という点にこそデザインの力、思考が必要であると考えています。

ランキング参加中。気に入ったら一押しお願いします!
人気ブログランキングへ