シナリオ手法を会社の業務に導入する

シナリオ手法に関するマガジンを作ってから少し間が経ってしまいましたが、放置していたわけではなく実際の業務の中でシナリオを中心としたプロセスにしていくための準備を進めていました。

以前の投稿でシナリオには「リアル」と「フィクション」があることを書きましたが、その枠組みの中に「構造化シナリオ」を組み込んでみたのが今回の記事になります。さらに実際の業務にシナリオ手法を導入するときの課題についても触れてみたいと思います。

現場主義・人間中心＝シナリオ手法

会社の業務はガバナンスや法規制の観点から、全体を社内ルールで構成しその中の重要な部分についてはSOP（Standard Operating Procedure：標準作業手順書）によって決められています。

ルールやSOPの中には、既にユーザーや顧客を知るためのマーケティングのプロセスが含まれているため今回のシナリオ手法をゼロから導入する訳ではないのですが、メーカーという枠組みの中では技術や物が中心であったり、サービスを含めてメーカーがユーザーに良いと思うものを提供するというメーカー中心の視点が残っているのが現状です。

それらを、全ての活動の原点として根拠となるユースシナリオをユーザー調査によって明らかにし、その中から問題点を見つけ出し、より良いユースシナリオに変えていく活動が現場主義・人間中心の開発活動であることを理解する必要があります。

分かりやすく言えば、ユースシナリオを調査していく中で事故も無く効率も良いのであれば何も変えないことが正しい答えであり、問題があったとしても解決するためにユーザーのやり方を変えるだけでよければ新製品を開発する必要は無いことになります。

何に関するシナリオを扱うのか

世界の出来事を全てシナリオとして扱うことはできないので、何らかの範囲の設定（スコープ）を決める必要があります。従来の製品開発プロジェクトではその製品の使われ方を調査したくなりますが、前のところでも書いたように新製品が必要かどうかはユースシナリオを分析した後に分かるため最初から対象デバイスを絞り込むべきではありません。

そこで最初に注目するのが「イベント」です。何らかの成果が出て価値として認められる単位が良いと思います。例えば音楽を聴いて楽しむイベントは価値が共有できますが、その中で音量を調整することは小さなタスクの一つという考え方です。

価値あるイベントを単位にする理由は、そのイベントを最適化するときに「価値が実現できたか」という上位の概念で評価することができることと、その下のタスクや操作のようなものはどんどん変更して良いと考えられるからです。

このようにイベントをシナリオの単位とした場合、通常は複数の登場人物や利用環境、装置が登場してきます。例えばIoTデバイスでは現場での出来事と同時にサーバー側でもタスクが実行されていることになります。これらを「システムオブシステムズ」と言い、私は昔しからUXシステムと呼んだりしていました。

このようにシナリオ手法を導入していくことは、同時にこれまで特定の装置のUIシナリオレベルで考えていたものを、より大きな視点としてイベントのバリューシナリオとして考えていくことになるのです。

会社の組織を変えるくらいの変化が必要

私が学生のころに「モノからコトへ」というような視点の置き換えがありましたが、ユースシナリオの導入で起きている変化は「１製品から複数製品連携へ」もしくは「ユーザーや利用環境を含めたシステム」ということであり、これまでバラバラに開発してきた製品を一つの大きなシステムとして扱うことを意味しています。

当然プロジェクトの複雑さは増し、ユースシナリオが間違うと影響範囲も広くなってきます。

しかし逆の方向から見たときには大きなメリットにもなります。もし会社の複数の製品が連携して機能するような場合に、それらを最適化させる手法としてユースシナリオが使えると言うことになります。個々の製品に目を向けるのではなく大きなシステム全体としてどのようなバリューを実現するのかシンプルンに扱うことができるようになります。

さらに製品プロジェクトから見れば、ユースシナリオからシステム内の役割を要求仕様として定義することで製品プロジェクトをシンプルに進めることができ、結果的に同じようなユーザー調査を複数の製品プロジェクトでおこなうような無駄を排除していくことにもつながるのです。