フルスタックな人たち

35歳定年説より怖いフルスタックエンジニアしか生残れない未来とは - paiza開発日誌

最近の求人で注目されている人材は"フルスタックエンジニア"と"UI/UXデザイナー"であるという話をどこかで聞いたことがあります。私はエンジニア畑ではないので、最初聞いたときは「フルスタックって？？」と思ったのですが、どうやら解決方法や技術をたくさん持っているエンジニアをイメージしているようです。

一方私は現在UXデザイナー的な肩書きで仕事をしているため、LinkedIn経由でいろいろなポジションの紹介を受けることがよくあります。そこでは前述の"UI/UXデザイナー"と書かれている案件もあり、その時点で「この会社はこのポジションに何を求めているのかな？」と疑問に思うのですが、さらに読み進めると、ユーザーリサーチからUXデザイン、ワイヤーフレームやUIデザイン、さらにはフロントエンド開発まで、、ともりもりにスタックされたJob Descriptionだったりします。

いうなれば"フルスタックデザイナー"ですね。いやひょっとしたらWebディレクター的な要素も多分にふくんでいるので、"フルスタッククリエイター"なのかもしれません。言うならば、ね。

思えばWebディレクターという仕事もフルスタックです。顧客の要求整理と課題特定。市場分析・競合分析・現状分析などなどを経てソリューションを企画・提案します。決裁を得れば具体的な詳細設計。もちろん見積もり作成やスケジューリング、およびハンドリングと顧客へのレポーティング。制作フェーズ・実装フェーズに入ればデザイナーやエンジニアとの協業。リリースとかその後のPDCAプランのための仕組み作り・・とかもありますが、書いていて気が滅入ってしまいました。なお、これらはあくまでプロセスであり、それを遂行するためにはコミュニケーション能力、ドキュメンテーション力、マルチタスクや長時間労働に耐えうる強い体が必要なのは言うまでもありません。

ちょっと書いていることが散らばってきましたが、これだけフルスタックだと全てにおいて手を抜かざるを得ず、自然とクオリティは下がってしまうので、自分のフォーカスポイントを見つけるキャリアプランと、一所に注力できる環境を作ったほうがいいかも、ということが言いたかったのです。

おそらく"フルスタック"は積んである状況を言っているだけで、その引き出し全てを100%使いこなして活躍できる人材、というのは雇う側も望んではいないのではないでしょうか。スキルが幅広いことは器用貧乏を意味します。経営課題が複雑になればなるほど、より深い専門知識や知見が必要になるのは当然なので、そうなったときに広くて浅い人材だと、課題解決の可能性を狭めてしまう可能性があります。

ただ、いろんな分野において経験や知識があるということは、他領域のスペシャリストと会話をするのにとても役立つのも事実です。同じ言語で話ができるので、コミュニケーションがスムーズに進み、信頼関係が簡単に築けます。

アンブレラ型の人材を探せ！ | 月刊「事業構想」2014年1月号

多分こんなイメージなんだと思います。

さて、あなたの引き出しはどのくらいスタックされているでしょうか？ 

フルスタックエンジニアを雇うには、まず経理•プロマネ•法務•営業•トイレ掃除•メンタルケアを全部やってくれるフルスタック経営者か必要。話はそれからだ。

— 深津 貴之 (@fladdict) 2014, 5月 14

 はは、確かに。フルスタックを望んでいるあなたのボスはどのくらいフルスタックでしょうか？

うまくいかないデザインレビューとWebディレクターとしての役割

デザインレビューとは

Webディレクターという仕事の中に「デザインレビュー」という避けては通れないプロセスがあります。クライアントの要件をヒアリングして、コンセプトを決め、そのコンセプトのもとデザイナーにデザインを作ってもらい、そのアウトプットをクライアントにお披露目するレビューです。関係者各位に「今までみんなで話して決めたことってデザインとして表現するとこういうことだよね、OKだよね」という確認の場です。

Webディレクターとしては確認および承認を取りたいだけなので、そのレビューでデザインの細かい部分に関して意見は求めていません。というかそれはデザイナーの仕事であって、ディレクター＆デザイナーが裁量と責任を持って遂行しているつもりです。

うまくいかないレビュー

しかしこのレビューにおいて、往々にして、クライアントの方々からとんでもない意見が出てくることがあります。

「この色は好みでない」とか「このアイコンはよくわからない」とか「競合ではこうやってるんだけど・・」とか。

デザインにもロジックがあり、事前に決めたコンセプトと表層デザインをつなぐ道筋をこちらが説明します。ディレクターとしてはこのロジックこそが価値発揮のポイントであり、それが仕事であると同時に、それを関係各位に理解してもらうのもまた大事な仕事です。

そもそも表層のデザインは眼に見えるものです。それまで決めてきた要件やコンセプトは眼に見えないものであり、そのイメージはデザイナーがデザインをおこすまでは具体化される機会はありません。なので、関係各位がそれぞれ抱えていたイメージの差異がレビューの場に集められるのです。

根本的な部分で考えの違いが発見され、それを補正すべしということになれば、そのレビューはまだ有意義だと思います。（そもそもの話が違う、ということになりますので、そのディレクターは解任されるかもしれませんが・・）

しかし、デザインそのそものレビューは、非デザインの方が抱くアイデアは、ほとんど素人考えなので、それに時間を多く割いてしまうのは有効ではありません。

人は眼に見えるものに口を出し、理解できるものに時間を使う

パーキンソンの法則に自転車置き場の理論というものがあります。原子炉のような巨大で複雑な専門家が必要なものについての議論において、一般人は理解を越えていたり誰か別の人が決めてくれるだろうと思い、あまり口を挟まないため着々と進む。しかし自転車置き場のような身近はものは、皆がイメージ付きやすいためトピックが些末な点に陥りやすく、本質的な議論がないまま時間だけが膨大に必要である。

難航するデザインレビューにおいて発生している事象とよく似ているように思えます。

このような事態を避けるため、本来であれば前段である戦略とか要件とか仕様などをじっくり関係各位で議論をして合意を得るべき-- というウォーターフォール的なアプローチと、前段でのプロセスを行いながら同時並行でデザインを作っていく-- アジャイル的なアプローチのどちらかを取ることになります。

流行り、でいうと最近では後者がよく話題に登っているように思えます。ただ私個人的にはまだ圧倒的に前者が現場に適応しやすく、（まぁまぁ）成功することが多いです。チームが大きく、関係者が多いと、すぐアウトプットしてフィードバックもらうまでのリードタイムが長くなってしまうので（下手すると社長にまでデザインを見せないといけないこともある）、どうしても土台をしっかりしてから・・となってしまいます。

眼に見えないものを見えるようにするチカラ

デザイナーやエンジニアの「それまでなかったものを作るチカラ」「見えないものを具現化するチカラ」はかけがいのないスキルです。クライアントはそのチカラを事業推進に使いたいし、Webディレクターはその意図とデザイナー・エンジニアのチカラをうまくブリッジすることに価値を発揮させなければなりません。

そのためには事業・デザイン・エンジニアリングの素地が必要ですし、またどのようにして具現化するかの道筋を整える必要もあります。小さいチームには小さいチームなりの、大きいチームにはそれなりの、最適な方法と場を作ること。関係各位お互いの責任範囲を定義する。などのプロジェクトマネジメントとしての役割も必須です。

パーキンソンの法則 (至誠堂選書)

概念的に考えるということ

サイト改善の仕事をしていると、ペルソナを作ったりジャーニーマップを作ったり、いわゆる「モデル化」をすることがよくあります。これはユーザーインタビューや顧客アンケート、ログ解析など事実から共通項を取り出し「それらしいもの」を一つに仕上げたアウトプットになります。

しかし、これをクライアントさんに見せると「（別の）こういうユーザーの場合どうなんだ」とか「うちのサイトはこういう使われ方もある」と言われてしまうケースがたくさんあります。

このようなことを言われてしまう背景として、我々の方での説明不足が多いことが挙げられると思います。特に「数あるパターンを概念的に考えてモデル化し、問題をシンプルに捉えるためにこういうことをするんです」ということに納得いただけてない。

これをご納得いただくためにどのように説明すればいいかな？と思っていたところ、ある本からインスパイアを得ました。

知的複眼思考法　誰でも持っている創造力のスイッチ (講談社＋α文庫)

 本書は概ね「常識にとらわれずに多角的に物事を捉えて考えよう」ということが書かれているのですが、概念的に考えるということについて以下のように書いていました（うるおぼえのまとめです。抜粋ではありません）

目の前の具体的な事例にとらわれ過ぎると思考停止に陥る。当面の問題は親しみを感じてしまうだけにそれを当たり前に発生していることと見なしてしまい、そのケースを越え出る問題の広がりに目が向かなくなってしまう

UXに関連するアウトプットはおおむね問題を可視化することだと思っています。Design Thinking Method的にいうと、共感して（Empathize）課題を定義する（Define）するためのものです。決して網羅するためのものではありません（そういう使い方はそれで有効なこともあるかもですが）

運営側の持っている中から見た問題点だけに固執せず、利用者側視点での問題を抜き出し、どこが一番ネックになっているのかを知るためのものです。

このような考え方には3つのメリットがあると本書にかかれています。

1. 物事どうしの共通性を高め、個々の出来事をシンプルに捉える
2. 一つの概念から新しい考えを産み出す。「ジェンダー」を例にとると、以前は性差は生物学的な違いにフォーカスがあたっていましたが、ジェンダーの発見により社会的役割（女性が子育てをするべき）という常識から抜け出し、社会的に作られた性差という新しい発見がなされた
3. 概念同士に新しい共通点を見つけて定義しなおす。「セクシャル・ハラスメント」を例にとると、以前は性犯罪にいたるほどにならないと問題にならなかったが、セクハラの概念ができることによって、女性が不快に思ったかどうかに目が向けられるようになった。またさらに発展して男女間で起こる嫌がらせ、というように定義された

 UXがサービスおよびサービス運営者にもたらすメリットとよく似ています。課題をシンプルにとらえリソースを投下すべきフォーカスポイントを見つけ、内在する課題を発展させたり取捨選択する過程で新しいアイデアが発生する。

サービスを運営していると機能的なアイデア（この機能があればユーザーは使うはずだ）が真っ先に出てきてしまいますが、その前になぜそれが必要なのか、抽象度をあげて考えると視野が広がるのだと思います。

左脳右脳、点と面、およびストーリー構築について

物語の作り方／感動させる技術 - デマこいてんじゃねえ！

読みました。インスパイアされたもの、自分の中で繋がったものを3つほど書きます。（この記事に関して何か言うつもりはまったくありません）

「あたしセンスないんですけどー」という言い訳

物語に必要なのはセンス、と考えている人が多いが、実際は技術あってのセンスである。と述べられています。ここで技術とは「フレームワーク」と言い換えることもできます。仕事においてもフレームワークをガリガリ使って未知のものを理解しやすく分解できる人は尊敬します。反面、ひらめくような直感で常人では考えられないスピードと確度で仮説を構築してしまう人も尊敬します。

フレームワークと直感、技術とセンス、左脳と右脳。行ったり来たりしながら何かを創ったり仕事したりするのですが、中にはセンスがないというだけで技術の研鑽を怠る人がいます。

デザインの仕事をしていると、一緒に仕事をする非デザイン出身の人（プロデューサーなど）がデザインアウトプットをレビューするときに

「あたしセンスないんですけどー」

と前置きした上で、とんでもなく的外れなフィードバックを返してくることがあります。こういう人は自分なりのロジックを説明するわけではなく、ただ単に自分の感性（センスはないと自称しているのだが）のみを頼りに訳の分からないことを言ってきます。

これは自省も含め、自分の専門外の分野に何か口をだすときは必ずこれまで自分が培ってきた自分なりのロジックで相手に説明をするようにしたいものです。

UX デザインにおける「要素」と「配列」

そもそも物語は、「要素」と「配列」から成り立っている。

映画館を出たときに友人とどんな会話を交わすだろう。「あのセリフがよかった」「あのシーンが楽しかった」「あの役者の演技にしびれた」……それらは物語の「要素」だ。しかし、どんなにいいセリフも、タイミングを外せば寒いだけだ。どんな名シーンも、話の筋と無関係に提示されたら観客は混乱するだろう。「要素」を詰め込むだけでは物語は完成しない。それらを適切な「配列」に並べて初めて、観客を感動させられる。

評論家は、物語の「要素」に注目する場合が多い。「配列」に言及する場合はまれだ。「要素」と「配列」のどちらに興味を持つのか。これが物語を創作する人間と、それを消費するだけの人間との分水嶺になるのだろう。

「要素」と「配列」を「点」と「面」と理解しました。Webやアプリデザインにおける点は「画面単位のユーザビリティ」、面は「サービス全体を利用前後も含めた体験」と置き換えることができそうです。画面単位でどれだけ頑張っても、ナビゲーションが悪ければ体験は損なわれるし、そもそもサイトにどうやって来たのか？がサービスを使う動機付けやユーザーの期待値に影響します。

よく、体験をデザインする人は指揮者のように全体を俯瞰すると言われます。評論家のように点だけで品質を見るのではなく、ユーザーの理解を通じて全体を設計する。どちらも時と場合によって使い分ける必要がありそうです。

ヒーローズ・ジャーニー

記事の中で言及されている「ハリウッド式三幕構成」とはヒーローズ・ジャーニーと呼ばれるものだと思います。以前の記事でもご紹介した本「全脳思考」でこのモデルが紹介されていました。物語は一次関数的直線的にクライマックスへ向かうのではなく、いくつかの山なりをギザギザに形成しながら進んでいきます。おおよそ33%時点と80%時点で大きな転換があるのが常なようです。

手書きのメモで恐縮なのですが、ヒーローズ・ジャーニーは以下のステップを踏みます。

1. 偏狭な今までの認識
2. 変化への拒否
3. メンターとの出会い
4. 変化への一歩
5. 最初の変化の試練
6. 大きな変化への準備
7. 大きな変化・試練
8. 進歩と後退
9. 変化への再挑戦
10. 最後の変化
11. 解決

ここまで細かいと起承転結よりもだいぶ扱いやすそうですね。

また本書の中では、このモデルはストーリーだけでなく、プロジェクト進行にも当てはまると説明されています。予め33%と80%時点で大きなトラブルが起きる、など予見の参考に、また意図的にストーリー仕立てにすることでメンバーのモチベーションアップに、など使えそうです。

全脳思考

ソシオメディア UX 戦略フォーラム 2014 Spring

ソシオメディア UX 戦略フォーラム 2014 Springに参加してきました。FIt Associates LLCの創設者である Marc Rettig 氏をメインスピーカーに向かえ、3月10日と12日の二日間に渡って開催されたフォーラムです。

ソシオメディア | ソシオメディア UX戦略フォーラム 2014 Spring

近頃は UX に関するメソッドやプロセスなどは日本語でも十分に拾うことができ、また 経営陣が UX そのものの価値について理解があるというシチュエーションも珍しくなくなってきていると思います。UX という概念の認知としては、ある意味成熟期に入りつつあると言っていいのかもしれません。しかしそういうフェーズならではの課題 -- 組織的に取り組むにはどうすれば -- が浮かび上がっています。そういう経緯からか、UX がプロジェクトマネジメントもしくは組織経営といった文脈で語られる場面が多いと感じます。

本フォーラムの呼びかけもそういった色が強く、また参加者についても同じような課題を持った方が多かったような印象を持ちました。

詳細については上述したリンクを参照していただくことにして、以下私が個人的に持ち帰ったインサイトを紹介いたします。

Design for Experience

Marc Rettig 氏が「UX ではなく Design for Experience」と言っていたのが印象的でした。User にフォーカスを当ててしまうと、何か利用者や顧客をモデル化する（ペルソナを作る）のが目的になってしまいがちで、デザインにおける重要なプロセス（課題を発見する）が欠落してしまう可能性があるとのことです。

一時期はペルソナをパーソナリティまで詳細に定義していた時期がありました。しかし最近では Lean や Agile の流れもあり、より素早く作れて周囲にも共感を得やすい要素に絞ったプラグマティックな方法が一般的です。

ユーザー定義に過度にこだわるよりも、体験が解決すべきターゲットであるという課題設定の仕方は納得感が高いです。

人は見ようとしているものしか見えない

これはデザインリサーチの文脈で語られていました。Awareness Test という動画があります。

Test Your Awareness: Do The Test - YouTube

人は予め問題が定義されていると、それ以外のものに目を向けなくなるようです。逆にいうと人間の集中力が発揮されているのかもしれませんが、顧客の潜在的なニーズに目を向けて課題を解決していく UX の文脈においては、それが制約になってしまいます。

リサーチの設計をするときは「何を知りたいか、リサーチの目的をちゃんと設定してから設問を設計する」というのがセオリーです。ただ、これは旧来然とした、例えばマーケットリサーチなどにおいては有効なものかもしれませんが、デザインリサーチにおいては必ずしも当てはまるわけではないようです。

デザインリサーチについて、もっと理解を深める必要があると感じました。

バブル

対象物を見る際のパースペクティブを、氏は「バブル」と呼んでいました。プロダクト／サービスには企業のバブルから見る面と顧客のバブルから見る面があります。その融合点を「タッチポイント」と表現していました。そこにあるのが UX だと思うのですが、UX デザイナーはそれら二つのバブルを仲介や翻訳して橋渡すのではなく、二つを大きなバブルで包むことが役割であるようです。

この表現はとても分かりやすく、最近よく聞く「顧客をメンバーに加えたチーム」などといったテストドリブンなチーム編成や開発手法のベースにもなっているように思えます。

またこのバブルは組織間にも存在しています。「タコツボ」とか「サイロ」などで言われることが多いのですが、組織のバブル同士があまりに離れていると、セクショナリズムに陥っていまい、UX の根幹である協調デザインに支障をきたします。UX デザイナーという職種は、企業と顧客をつなげるだけでなく、組織における関係者をもつなぐことも、大事なミッションです。

複雑さをどう理解するか

人々の生活は日に日に複雑になってきています。その生活の中で抱える問題も同じく複雑になっており、それらの課題をどう解決するか、新しい未来やビジョンをどう提示するか、が企業の存在価値になってきています。

一昔前までの Product Design 的手法では顧客の複雑さが把握できない・・その問題を乗り越えるために出てきたのが UX です。

では、その複雑さをどう理解すればいいのでしょうか。

Marc Rettig 氏は複雑さを3つに分解し、それぞれに用いるべきアプローチを紹介してくれました。

問題の複雑さの類型

• Social: 考え方や興味の多様化
• Dynamic: 因果関係の弱化（時や場所によって様々に変わる）
• Generative: 予見性の低さ

それぞれへの対応アプローチ

• Participantory: 顧客をまきこんだデザインプロセス
• Systemic: 体系だった俯瞰。個別対応ではなく。
• Emergence: 活動や組織のたえまないadjust と improvement

上記のように、顧客の課題やニーズは絶えず変化し、再現性・予見性が低いゆえに旧来のアプローチでは顧客を理解することはできず、またこれまでのベストプラクティスや成功事例の適用も難しくなっています。我々企業側はこれを深く認識し、メソッドやプロセスなどについても本質まで噛み砕いて学習し、コンテキストにあわせて柔軟に適用する必要がありそうです。

Everything depends

質疑応答では参加者が抱える課題が Marc Rettig 氏に投げかけられました。彼の回答はほとんど以下の言葉で始まっていました。

"It depends（場合によるね）"

黄金則が機能しない状態、つまり環境の複雑化やソリューションの多様化を彼のこの言葉がよく表していると感じました。もちろんその後彼は自分の経験に基づいて我々にヒントを与えてくれました。興味深いことに、ほとんどの質問への答えは「傾聴すること」「謙虚になること」に集約されていました。

謙虚に傾聴すること

彼は「組織の幹部がUXの価値を理解してくれないときにどうすれば良いか」という質問に対し、こう答えていました。

「UX の価値を説得しようとするのではなく、相手の課題を理解することが大事」

顧客の課題が複雑であるように、企業内における問題も複雑になってきています。エビデンスを用意して幹部を説き伏せるのではなく、経営者が抱える課題を聞いて相互理解を深める、人間関係を築く、意見交換をする、といった姿勢が大事なのです。

顧客について何も知らないことを謙虚に認めるところからスタートし、観察を通じて課題を発見する。解決策の創出にあたっては独善的に進めるのではなく他部署・社内外と協調してそれぞれの立場からの見解を取り込んでいく。

フレームワークを駆使したり、ビックデータから行動を分析したりといった方法とは全く違うアプローチです。

まとめ

前述しましたが、UX デザインについてメソッドやプロセスなどはもはや語りつくされた感があります。実践者が現場でそれらを適応する中で、これまでと違った壁に突き当たり、その中から組織的な転換や根本的な考え方の変化が求められて「UX 戦略」といった文脈でディスカッションが展開されているのだと思います。

普段、業務の中では目の前のタスクに追われてなかなかここまで意識することが難しいです。しかし本フォーラムで生の声を聞くことができ、自分が変化の真っ只中にいること、そして自分が変わっていかないといけないことを再認識できました。複雑化した環境だからこそ、小手先のテクニックを追い求めるのではなく、マインドセットのような本質の部分や自己変化への準備こそが実践者として大事にしないといけないことだと感じます。

蛇足ですが、フォーラムの中で語られたうちのいくつかが最近読んだ（UX とは関係ない）本に書かれていたこととリンクしていましたので紹介したいと思います。

ファシリテーション入門 (日経文庫)

 バブルを繋げるために必要なスキルとしてファシリテーションがあります。本書は入門書だけあって簡潔ですが、リーダーシップという意味でファシリテーションを捉えているのが印象的です。テクニックではなく「なぜそうする必要があるのか」にも言及しています。本書の「支援型リーダーシップ」は本フォーラムで紹介された「協調型リーダーシップ」とびったり符号します。

戦略の本質 戦史に学ぶ逆転のリーダーシップ

 名著「失敗の本質―日本軍の組織論的研究 (中公文庫)」の続編にあたる本です。この本でリーダーシップの形として「賢慮型リーダーシップ」が挙げられています。特徴は

• 環境・現場を直感し、その中に身を置いて細部の語りかけを察知する
• 総合したビジョンにおいて直感を対局と関係付けて現実の本質を洞察する
• 他者とコンテキストを共有して、共通感覚を醸成する
• コンテキストの特質を察知する
• コンテキストを言語・概念で再構成する
• 概念を公共善に向かってあらゆる手段を巧みに使って実現する
• 賢慮を育成する

そのほとんどが現在におけるデザイナーの役割です。偶然でしょうか。

プロフェッショナルの条件―いかに成果をあげ、成長するか (はじめて読むドラッカー (自己実現編))

 農業社会から工業社会、情報社会を経て知識社会へと移り変わる現在をドラッカーは早くから提言していました。そしてそれは周知の通り現実になっています。本書におけるプロフェッショナルの条件および考え方は、Marc Rettig 氏が提示した "Past", "Present", "Frontier" における "Product design", "Experience design", "Ecosystem design"の遷移と類似する点が多くあります。

全脳思考

 Marc Rettig 氏は抽象具象のレイヤーとして、"Form", "Structure & Process", "Identity & Purpose" の3つを定義していました。具体レイヤーだけで考えるのではなく、抽象レイヤーまでさかのぼって、それからまた具体レイヤーへ戻ってくる。いわゆる U理論 の応用なのですが、本書ではそのU理論が詳しく説明されています。