コンセプトとものづくりの振り子
こんにちは、レタスです。
今月は積ん読になってた書籍を読もうと思い立ち、先輩から（ずっと）借りてた『takram design engineering｜デザイン・イノベーションの振り子』(2014年、LIXIL出版)を読んでみました。
第1章から第4章までで構成されており、デザインヒストリーや問題の性質、デザインエンジニアリング（takramさんがよく使う「越境」の概念）、プロトタイピングについて...など様々な点について書かれています。
ざっ・・・くり概要に触れますと、現代には職能や教育面での専門領域の分断や、複雑で解決するのが困難な問題（細分化した一つ一つを解決するという手法だけではアプローチしづらいような）が存在しますが、そんな中でも自由自在に新しい創造をするには？そのあり方とは何か？について書かれている本です。（すみません、あまりにもざっくりしてしまったので詳しくは本編をお読みください^^;）
今回は書籍の感想を述べるのが目的ではありません。ほんの一部をピックアップさせてもらって、自身が担当したプロジェクトの中で重なったこと、本を読んでもっとこうすればよかったのかもと感じたことについて書きます。
ちなみに取り上げるのは第3章で書かれていた「ストーリーウィービング」について。
ストーリーウィービングという概念
当書の第3章では「メソドロジー」と題して「プロトタイピング」「ストーリーウィービング」「プロブレム・リフレーミング」の3部から、ものづくり、あるいは問題にアプローチする方法論について述べられています。
この中で現在の私にとって"ワオ!"な概念だったのは「ストーリーウィービング」。はい、私自身も単語の意味がわかりませんでした...。ので、テキストから説明文をまるっと引用しますね。ストーリーウィービングとは？
一言でいうならば「コンセプトにおけるプロトタイピング」である。プロジェクトの初期に設定したコンセプトをその後も柔軟に練り直し続け、よりよいものに洗練させていく手法だ。
とあります。(同書 p48)
引用なんてしたの何年ぶりだろう、修論思い出すぜ、くっ...
苦い思い出はさておき、なぜその「ストーリーウィービング」の概念が自分にとってワオ！な発見だったのか？
それは私が直近で担当したプロジェクトの中でコンセプトメイキングからプロトタイピング、デザイン、プロダクトのリリースまで携わっていたのが大きな理由です。
（詳しくはこちらの記事でご紹介していますのでよろしければお読みください〜）
2018年8月の発足当初から2019年2月のリリースまでの間に、理想を描くフェーズとアイディアを具現化するフェーズ両方に関わり、コンセプトなりプロトタイプなり、各段階で考え得る"最適解"を（チーム全員で）つくりあげる経験をしたわけですが、それは同時に、コンセプトと実際のプロダクトとの乖離を感じる経験でもあったのでした。
わくわくする理想像を描くこと
上記プロジェクト、「jopus scout」にアサインされてラッキーだったこと。それはジョインのタイミングがサービスの企画発足後で、コンセプト決めに参加できたこと。
ほぼ何も決まっていないまっさらなプロジェクトを始動するにあたり、開発チーム（プロマネ、エンジニア、デザイナー）で、指針になる軸や立ちもどれるポイントをつくって共有＝言語化しておきたいよね。という意見が出ました。そのため代表を交えてサービスのコンセプトや開発バリューを最初の段階で練りました。
（全て書くと長いので詳しくはこちらの記事で）
「jopus scout」は日本で働きたい外国人採用専門のスカウトサービスです。外国人採用という特性から、日本人とはガラリと違った人材のtalentedな部分をアピールできたり、また、企業側の採用活動のあり方自体もどんどん楽しい体験に変えていけるプラットフォームになったらいいよね。などなど思考を発散させて言葉にしました。
最終的にはコンセプトは「The first step to Japan」、開発バリューは6項目にまとまり、バリューの中で「ウィンドウリクルーティング」という造語も作成しました。人事の方が気軽に、例えば電車に乗るような時間でいい人いないかな〜♪と採用活動ができるようなプラットフォームを作ることが理想だねと。メンバーと代表含めて「いいね！」と納得して決定できた実感がありました。
実際目にして気づくこと
そんな感じでわくわくしていた一方、要件定義やプロトタイプ作成をガシガシ進行していくと、諸々の矛盾点が発覚。「画面一覧で見たい情報量からすると、従来のデスクトップ型で見るのがベストじゃない？モバイルの画面では収まりきれない（=モバイルが最適解じゃない）よ。」「そもそもターゲットはモバイルで採用活動する年齢層となのか？」「ターゲット企業の業界が途中で変わった...」など数え上げるとキリがないほど、、
プロトタイピングで「目に見える」形にしたことで確認できた点でもあるのでその点は良いのですが、当初の開発バリューからはどんどん違った仕様に。同時に開発バリュー自体がターゲットに即して考えられていなかった面も明らかになりました。結局「ウィンドウリクルーティング」の体現はVer.1.0では見送りに。
ターゲットの見直しやサービスを利用するのに必要なフローを考え直した上での判断なので、それ自体は悪いことではないのですが、サービスの方針にしたかった事柄とユーザー側のニーズ（仮説ですが）があまりにも一致しませんでした。
当初の開発チームにあった「求職者にこんなチャンスが広がるといいよね」「企業側の採用活動がこう変わったら面白いよね」といった、あのわくわく感...。あの高揚感はさっぱり消えてしまい、我々が最初に考えたことって何だったんだろう？と若干の悲しみもあり、路線変更の混乱もあり。理想と現実の間をまさに振り子のように行き来しまくった開発だったのでした。
ドラえもん、もしもボックス出してよ〜
私たちのコンセプト作りは間違っていたんでしょうか？
言ってしまえばコンセプトを決めたやり方が正しかったかもわからないし、あやふや手探り状態であったことは確かにそうなんですけれども、大の大人が4人も集まって「良いね！」と感じたことを単純に「間違いだったね」の一言で片付けていいのかは疑問です。そう言い切るのはなんだか違う気がする...のです。モヤモヤが残りまくりでした。
その困惑を体験したあとだからこそ、「ストーリーウィービング」の概念を知ったときにワオ！だったのです。まさに直面したのが本の中で「従来型のコンセプトが抱える問題」(p51)と記されている通りで...。
じゃあそれはどう打破したらいいんですか、と、、
初期に設定されているコンセプトをあくまで種として扱い、その後の製品開発プロセスの中でも柔軟に形を変えうるものとして育てていく。
(同書 p53)
し、知らなんだ...そんなこと全然教わったことなかった...。コンセプトってブレない軸じゃなくて、育てるもんなんや...。プロトタイプと同じでアップデートしていくものなんだ、と目から鱗でした。ボロボロボロ。
そして「ストーリー」はその対象に携わる全員の共通認識である幹の部分と、各人の自由解釈が可能な枝葉の部分で構成されて、それぞれが自分なりの言葉で対象を語ることができることが重要とのこと。jopus scoutでいうならば「外国人が『日本への第一歩』を踏み出すサービス」であることが共通理解としてあって、そこから開発サイドや営業サイドがそれぞれの立場で解釈を肉付けして語っていけることが必要なんですね。（法人のお客様とか、共同開発者にあたるのかな？）
ストーリーウィービングのプロセスもプロトタイピングと同じように、「思想は最初から完全でなくてもよい」「あえて柔軟にしあがらも、逐次洗練させていくことができる」という着想だそうです。
今ここにもしもボックスがあったとして、「ものづくりを進めることで概念もアップデートしていく」という相互作用の考え方がプロジェクト初期からあったなら、当初の理想と現実との差が出てきた時でも、それと向き合う姿勢が全然違っていたように思います。「あれ、コンセプトが体現できない、全然違う（モヤモヤモヤ）」ではなくて「ベストと考えていた解が違っていたので更新する」と捉えられただろうし、方向転換による混乱も開発工数がかさむことによる精神的な疲弊ももっと小さなものになったはず。
そしてもっと具体的に想像してみます...、どのタイミングでコンセプト（あるいは開発バリュー）のアップデートをするために戻るか？と考えるといつがベストなんでしょう。企業側のシステムの要件定義を始めたタイミング...？また、コンセプトや開発バリューのアップデートは開発チームだけでいいのかな？また代表も含めてMTGするのかな？といった疑問も。そういえば途中からジョインした営業部長にはコンセプトや開発バリューの中身をちゃんとシェアできていませんでした。それも反省点ですが、時間がタイトなMTGの中でそういったストーリーを伝える時間をどう作り出せばいいんだろう、とか。もしもボックスは手元にないけれど、今後のプロジェクトで何かしら活かしていきたいです。
コンセプトとものづくりとの狭間で
takramさんはストーリーウィービングについて生活者やソーシャルも含めたもっと広い文脈で語ってるので、本来は上記以外のことも概要を掴む必要があります。が、まず咀嚼できるのは自分自身が体験した範囲からですよね...。コンセプトとものづくりとの狭間で揺れつつ、その相互作用について考えたのでした。
インプットとアウトプットとの間でも行き来する体験がこんなふうに増えていくといいな。
おわり。