コーディングモンキージレンマ
これは、技術的な背景と役割を持つ開業医へのインタビューからの引用です。
開発者はみな賢い人です。これがあなたがしなければならないことであり、これがあなたがそれを行うつもりであると誰かが彼らに言った場合、彼らは彼らの仕事を楽しんでいません。コーディングサルのように感じたくはありません。
これを「コーディングモンキージレンマ」と呼びます。 UXを使用する多くの方が、UX担当者、インタラクションデザイナーなどの役割が、開発者の職務満足に対する「脅威」と見なされている同様の状況を経験していると思います。 UXなどの新しい専門知識を導入することは、責任を分担し、他の役割の一部の領域で力を失うことを意味することに同意します。
私の質問は、「コーディングモンキージレンマ」を克服するために、UXエキスパート、インタラクションデザイナーなどの仕事でどのようなアプローチ（プロセス、ツール、メソッドなど）を使用していますか？
参考文献をご存知の場合は、こちらについてもお読みください。
方向ではなくダイアログを使用し、
強制ではなく会話を使用する
コードモンキーはお粗末な設計と開発プロセスの症状であり、方向性/管理対対話/コラボレーションを強調しています。
この種類のプロセス（ウォーターフォール、線形、ディレクティブなど）には多くの名前がありますが、その中心にあるコードモンキーシンドロームは、開発者が指示されるリソースと見なされる設計/開発モデルから生まれますではなくプロセスのパートナー：
ディレクティブのアプローチは、多くの十分に文書化された理由で弱いです。
- 開発者は、権限を与えられず、関与せず、過小評価されていると感じていますプロセス中。
- このプロセスは、上方へのフィードバックを抑圧するか、遅くします。
- フィードバックと反復メカニズムがないため、速度が遅く、非効率的です...
共同開発
コードモンキーを共同編集者に変える 
共同開発モデルは通常、共有所有権、会話、および反復開発の概念を使用して、いくつかの目標を達成します。
- コードモンキーシンドロームを避ける開発者（およびその他の利害関係者）に所有権と意思決定における積極的な役割を与えることによって。
- 双方向通信を改善壁、サイロ、機能的な障壁を打ち破り、オープンな協力を遅らせることができます。
- 開発のスピードアップ線形プロセスではなく、実験/プロトタイピング/反復を提供することにより、故障/エラーの検出が速くなり、製品の進化が速くなります。 ...およびその他の利点
共同開発モデルでは、Xプロフェッショナルは、ディレクターではなくファシリテーターになります製品のアクティビティです。
- UXプロフェッショナルチームの参加者の貢献を最大化チームのリソースを仕事に向ける代わりに、コラボレーションデザインプロセス、ガイド付きアイデア、促進された会話、製品開発プロセスの共有所有権を促進することにより、.
共同開発を促進するために、ここで参照する多くのツールとフレームワークがあります。
Frameworksアジャイル、スパイラル、リーンなどは、共同製品開発の全体的な構造とガイダンスを提供します。
行動モデルFlow 、 Hyperfocus 、 ニーズの階層 、 N-Ach など他の人たちは、チーム環境で開発者やデザイナーをやる気にさせる心理モデルを提供するのに役立ちます。
チームプロセスの方法設計面接、ストーリーボード、構造化されたアイデアなどは、制作ワークフロー内の特定のタスクを実行するための共同ガイドラインを提供します。
うまくいけば、これらの用語/概念は、あなたのさらなる研究のための出発点を提供するでしょう。
私が一緒に働いたほとんどの開発者はUXについての意見を持っています、そしてしばしば彼らは有効でありえます。多くの場合、彼らは必要以上の頭痛を引き起こしますが、それは主にチーム全体のコミュニケーションの欠如に起因します。 コミュニケーションはこの場合の解毒剤です。このジレンマに対処するためのいくつかの戦略を説明するのに役立ついくつかのベストプラクティスと理想的なシナリオについて説明します。
良い開発者
優れた開発者は、ユーザーに影響を与える可能性のある問題が発生した場合はUXチームに任せます。彼らが何をすべきかわからないサルではなく、問題を調査して解決することがあなたの役割であると彼らが信じているからです。彼らが解決策についての意見を持っている場合、彼らはそれを共有する必要がありますが、UXerと同様に、問題の解決方法について考えているかどうかを尋ねる必要があります。それはあなたがそれで走らなければならないという意味ではありませんが、多分それは史上最高のアイデアです！あなたは、決して知らない。
良いデザイナー
同様に、優れたチームでは、UXデザイナーは開発者をプロセスに含めます。いつもではなく、必ずしも毎日ではありませんが、確かに重要なポイントで。開発者は当然のことながら好奇心旺盛な問題解決者です。答えに集中していても背後にある考え方が見えない場合、彼らはあなたの動機や仕組みに疑問を抱きがちです。長期的には、UXに自由に質問しなければ、恨みを抱くでしょう。
実際には
特定の機能を調査するUXサイクルでこれまでに行った（適度に大きな機能ですが）1つの例は、1人または2人の開発者を最初のキックオフミーティングといくつかのワークショップに招待することです。そうすることで、彼らはあなたが達成しようとしていることとその理由についての良い洞察を得て、インプットとフィードバックを提供する機会があります。これは彼らに結果の所有権の感覚を与え、それはチームの士気を維持する上で非常に貴重です。その後、設計は進化し、POなどからフィードバックが求められているので、設計の反復に取り掛かるために、開発者を時折再訪させていました。これは常に理想的であるとは限りませんが、この部分をスキップする場合は、少なくともプロジェクトを設計から開発に引き渡すときにミーティングを手配することをお勧めします。そうすれば、すべての当事者が懸念を表明し、プロセスにおけるそれぞれの役割をお互いに思い出させることができます。 （私が言うことの引き継ぎミーティングが言うまでもありません...しかし、あなたは驚かれることでしょう！）
さらに：旅に沿って、さまざまなユーザーテストセッションと関係者からのフィードバックがあり、誰もがアクセスできる場所にこれらすべてを文書化することが重要です。私が一緒に働いた多くの開発者は、UXドキュメントをざっと見て、何が起こったのかを理解して楽しんでいます。
参考文献
UXとチーム全体の関係に関するセクションがあるUXに関する本当に素晴らしい本の1つは、Cennydd BowlesとJames BoxによるUnder Cover User Experience Designです http://undercoverux.com/ 。それはいくつかの面で少し古いですが、それは素晴らしい洞察と時代を超越したアドバイスで満たされています。
これは、組織構造と古典的なサイロの考え方についてです。
サイロを失う
サイロは、組織の目標ではなく個人の目標を強調しています。戦略は、エンドユーザーの利益のために全体像の一部となるのではなく、断片化および内部化されます。
あるグループから別のグループに仕事の塊を渡すことは、仕事をうまく行うための正しい方法ではありません。できるだけ多くのプロセスを通じて、できるだけ多くの人々を巻き込みます。
共通の目標（ユーザーの目標）を持つ1つのチームとして、オープンなコミュニケーションと知識の共有を行います。チームの他のメンバーの強みを知り、彼らがあなたの強みを知っていることを確認してください。
読み物：
スマッシングマグ：サイロを壊す、パート1：隔離作業の結果
Leisa Reichelt：今誰もが戦略を行っている と 戦略はサイロに住んでいない（または、 UX戦略）
FoolProof：Breaking Organizational Silos
「コーディングモンキー」でも「ピクセルモンキー」（グラフィック/ビジュアルデザイナーの場合）ジレンマでも、問題は同じままです。ある程度の専門性を持つ役割には、基本的に2つの側面があります。最初のインスタンスでは、ドメイン領域の問題を解決できるようにし、2番目のインスタンスでは、ソリューションを実装します。
コーディングモンキーのジレンマは、あなたが思いついていないソリューションを実装することに関するものであり、したがって、結果に個人的な関心がないか、それが問題の正しいソリューションであることに同意しません。
「コーディングゴリラ」は、（おそらく彼らがより上級の立場にあるか、またはより経験があるため）これらの問題について胸を打つが、変化に影響を与える場合とそうでない場合がある。
ソリューションは、実際に、要件を満たすように役割/ポジションに期待を設定することです。実装せずにソリューションを考えて満足している場合は、コーディングモンキージョブは適切ではない可能性があります。疑いなく誰かのソリューションを実装してよければ、コーディングモンキージョブは完全に適切です。
追伸多くの人がUX実践者が実行する研究とテストの作業の非常に論理的な一見はある種の「ダーク/ブラック」マジックであると考えているため、UXの人は「マジック」モンキーの説明に該当するかもしれません。
ここにはすでにすばらしい答えがあります。
このトピックについては、少しプロセスベースの少し異なる視点を提供したいと思います。
テスト駆動開発
ソフトウェア開発のさまざまな戦略から、テスト駆動開発（TDD）は現在最も人気のあるものの1つです。
これは、コードを書く前に before テストを書くべきだと主張しています。しかし、パラダイムはさらに進んで、多くの人がテストをシステムのドキュメント、要件、および仕様の中核と見なしています。
テストは以下をキャプチャする必要があります：
- 代替パスを含む使用例。
- さまざまなユーザーアクションに対して期待されるフィードバック。
- ビジネスロジック。
- 等.
これの多くはUXerの仕事によって定義されます。
テストは、かなり自然な言語（ Cucumber を参照）で、または（おそらく）プログラマー以外の人が理解できる形式でプログラミング言語を使用して記述できます。このようなもの：
describe( "distance converter", function () {
it("converts inches to centimeters", function () {
expect(Convert(12, "in").to("cm")).toEqual(30.48);
});
it("converts centimeters to yards", function () {
expect(Convert(2000, "cm").to("yards")).toEqual(21.87);
});
});
人間中心のTDD
人間中心の設計（UXがシステムの設計を駆動することを意味し、したがって、その実装も行う）とTDDの組み合わせは、ますます普及しています。
プロセスはおおよそ次のようになります（明確にするために、また重要なメッセージに焦点を合わせるために、多くは省略されています）。
注意すべき重要なことは、テストが設計と実装の間の橋渡しとして機能することです。議論はしばしば誰がテストを書くべきかを中心に展開し、オプションは次のとおりです：
- Xデザイナー-いずれにしても、テストがカバーする内容の多くを文書化する必要があるため、1か所に何かを書き込んでからテストに変換するのではなく、実際に構文で2回だけ書き込むだけで十分です。簡単にテストに変換できます。
- QA担当者
- 開発者-多くの場合、開発者は内部コードユニットの追加テストを作成する必要があり、構文に最も精通しています。
私の主張は、往復のエンジニアリングを考える場合、UXerは彼らの仕事の多くを捉えるテストを書いているべきだということです。
開発者にとって何を意味しますか？
- まず、優れたテストは十分に説明された仕様を提供します。
- 開発者は多くの時間を節約できます開発者が変更ごとに以前のすべての動作をテストする必要がなく、コードが自動的にテストされるため（たとえば、私が設計した構造化された日付入力フィールドに64が含まれる）テストは、ほとんどが「ユーザーが日部分にあり、Tabキーを押した場合、選択は月部分に移動する必要がある」などのアトミックユースケースを表します。開発者が以前のすべてのユースケースと一緒に実装した後、各ユースケースを手動でテストする場合は、実行する2080テストがあります）
- テストバグを減らす。
- 開発者はテストを使用して、コードが壊れるのを恐れずにコードを改善できるため、開発者はより優れたコードを書くを実行できます。
わかりました。これを実現するには、何が必要ですか。開発者は、テストの形式で、十分に指定された要件に対するコードを記述しなければなりません。
これは、「何をすべきかを言われている」という意味ですか？はい、ある意味ではそうです。しかし、代替案を検討してください-必要な機能の短い文を提供し、開発者が適切な設計作業を行うことを望みますおよびテストを記述しますか？
開発者は、これらのコンポーネントのいずれかまたは両方を省略した戦略よりも、HCID/TTDプロセスに参加するほうが幸福であると私は主張します。
もちろん、これはデザインプロセスに関与させないという意味ではありませんが、システムのペルソナとパースペクティブの両方がユーザーやUXデザイナーのパーソナリティと視点とは当然異なることを覚えておく必要があります。
UXで開発者を関与させる
開発者は賢く、一般になぜを理解したいと考えています。「仕様に含まれているため」は別の合理的な質問を作成しますなぜ仕様に含まれているのですか？すべての助けを説明し、擁護し、尊重することですが、レバレッジを作成するために私が見つけた特定の活動は次のとおりです。
開発者にユーザーの問題を見て感じてもらいます
ユーザーテスト、インタビュー、バグレポートと表示と伝えるは、開発者が理解するだけでなく、すべてが自分の重要性を感じる機会ですユーザーに働きかけます。彼らはUXを高く評価するだけでなく、より良い仕事をするためのモチベーションが高まっています。
共同デザイン
適切にセットアップされたデザインワークショップでは、さまざまなアイデアが集められるだけでなく、明確にコミュニケーションが行われます。双方向の対話の重要な部分は、後で現れる可能性のある「隠れた下駄」と汚染のデザインが早期に明らかになることです。このようにして、デザイナーは「表面的な」ものとしてではなく、核心のある荒削りなものを扱うチームの一部と見なされます。
開発者が意見を獲得できるようにします
堅牢なフィードバックサイクルを備えたアジャイル環境では、いくつかの詳細な決定を行うことができます。後でコースの修正が必要な場合はそれを行うことができ、それでも素晴らしいユーザー結果が得られます。開発者のお気に入りのデザインを許可すると、2つの結果が考えられます（a）ユーザーに対して非常によく測定され、何か新しいことを学ぶ（b）ユーザーに対してはあまりよく測定されない、そして開発者はUXステアリングをより良くすることを学びます。 UXには「拒否権」が必要ですが、適切な場所と時間でこれを行うことが重要です。
実装の設計
これは議論の余地があるかもしれませんが、内部のプレッシャー（ツール、タイミング、スキルセット）にやさしいUXオプションについて、開発者と全体的な品質の作業に妥協することなく取り組みます。時々、この配信用に最適化されたUIは、一貫性、シンプルさ、実装の正確さにおいて恩恵をもたらすことができます
教育
おそらく、開発者を刺激する最も考えられているのは 受刑者が亡命を実行している：ハイテク製品が私たちを狂わせる理由とアランクーパーによる正気を回復する方法
また、非技術的なテイクから始めるのも魅力的かもしれません ドナルド・ノーマンによる日常のデザイン
開発者の関心ごとにエンゲージメントレベルを調整します
開発チームでは、通常、UXへの関心が混在しています。一部のユーザーはUXに密接に関与することを望んでおり、一部のユーザーは固定された仕様に取り組みたいだけです。 どちらにしても重要なのは、クエリが通信を通じて解決されるときです-独立したアクションではありません。
私の人生の中で最も憂鬱な時間のいくつかは、他の誰かが設計したものを実装しなければならなかったときでした、そして彼らはそれを不十分に設計しました。多くのエネルギーと時間をあなたが知っている何かに完全に役に立たない（またはさらに悪い）ものにすることは、私たちの仕事が得ることができるのと同じくらい心を砕くことです。これらすべての設計決定が通常行われるプロジェクトの開始に近づくほど、私は幸福になりました。
だから私の解決策は共同設計を実践するです。開発者はプロジェクトの利害関係者です。 UI/UXプロフェッショナルとしてのあなたの仕事は、実装するための仕様を開発することではなく、プロセスを導くことです。上司、クライアント、弁護士、ユーザー、開発者をテーブルの周りに連れて行き、彼らの議論を形作ります。それらすべてを同じページに表示し、それぞれが独自の観点から同じ目標に向かって作業していることを確認します。
ユーザーストーリー、ワイヤーフレーム、ペルソナなど、私たちが持っているすべてのツールは、これを行うのに役立つように設計されています。非デザイナーが設計プロセスに貢献できるようにし、意見の違いをエレガントで創造的なデザインの選択肢に変えます（ボスが最も安いオプションを選択したときに解決されます）。
この種のミートインを作成し、人々が時々ファンダメンタルズに戻るようにすると、製品がそのように設計されている理由を理解しているので、本当にやる気のある開発者を喜ばせることでしょう。共通の目標を達成するためにどのように役立つか。
ここで重要なのは、何を行う必要があるかを開発者に伝えることと、それを行う方法を開発者に伝えることを区別することだと思います。
UXデザイナーは、どのユーザーエクスペリエンスがよりポジティブになるかを理解することを専門としています。これには、とりわけ、学習のしやすさと使いやすさが含まれます。開発者がUXデザイナーを尊重する場合、開発者は通常（常にではありません）、ユーザーが直面するシステムの外観に関するUXの意見を尊重します。そしてUXはその意見を表明するべきです。
UXデザイナーが開発者を尊重する場合、UXデザイナーは開発者にその方法を伝えることを避けます。開発とは、実行する必要があることを実行する方法についてです。インターフェースに焦点を当て、実装は開発者に任せます。
鍵は相互尊重です。これがなければ、適切な組織構造でさえ、横ばいになるでしょう。お互いを尊重すれば、片方のパーティーがもう片方の芝生をたまに踏み鳴らしても、うまくいきます。
私の質問は、UXエキスパート、インタラクションデザイナーなどの仕事で、「コーディングサルのジレンマ」を克服するためにどのようなアプローチ（プロセス、ツール、メソッドなど）を使用するかです。
履歴書を更新して新しい仕事を見つけました。
残念ながら、コーダーとUXの両方の人々にとって、あなたの役割を「コーディングモンキー」の役割にするのは組織文化です。私が見つけた最大の赤旗は、a）組織が巨大であり、b）組織がウォーターフォール方法論で立ち往生していることです。
ウォーターフォールを使用すると、UXが非常に有給のメモを取る役割になることがわかりました。 （まあ、うまくいけば高給）。私たちの唯一の仕事は、管理のために絵を描くことです。
アジャイルへの移行が役立ちます。これは万能薬ではありませんが、UXチームと開発チームの両方にとって、より多くのコラボレーションをもたらします。
私の現在の課題は、長年モンキーのコーディングに洗脳されてきた開発チームを獲得しようとしていることです。 「開発者の皆さん、どう思いますか？」と尋ねても、彼らはもう何をすべきかわかりません。 :)
PS（これは素晴らしい質問です！）
教育とコミュニケーション。これはすべてのサービス関係で発生します-弁護士に何をすべきか、または配管工が何をすべきかを伝えることは、時々有効であるかもしれませんし、他の時に有効ではないかもしれません。
クライアントが悪い仕事を求めているとき、彼らが求めていることが適切ではないことを明確に伝えることがエキスパートの仕事であり、その理由-そして、それが続く場合は、書面でリクエストを形式化し、彼らがそれを認めることを認める専門家に彼らの専門知識に反対するように求めています-そして仕事をして次に進みます。
あなたは彼らとの関係で彼らが期待すること、彼らがあなたに何を期待するべきかを彼らに伝え、彼らがあなたが伝える仕事の間に押し始めた場合、あなたは教育し、あなたはあなたがあなたのクライアントと一緒に考え出した方向に前進します。それは実際には、関係を壊すことかもしれません。妥協するかもしれません。
ただし、重要なのは、関係を構築するためにそれらを使用して作成した最初の基盤です。彼らがあなたを専門家として信頼していない、またはあなたが彼らが何を求めているかを知るクライアントとして信頼していない場合、あなたはこれらの問題に頻繁に遭遇するでしょう。
次に、新しい関係を構築し、必要に応じて機能していない関係を終了します。
共同ではない共同設計
コレクティブデザインとコラボレーティブデザインは、2つの完全に異なる結果につながる可能性があるため、明確に区別することが重要です。
Collaborativeは、さまざまな役割からの入力を意味します：（人+経験+知識+視点など）共有ターゲットまたは目標を達成します。結果は問題に対する強力で実行可能な解決策
Collectiveは、全員が関与しているが、目標を共有することではなく、発言することを意味します。これは、多くの意見に応えようとしたため、希釈され、妥協され、貧弱なソリューションになります。
UXは方法とプロセスについてであり、意見についてではありません
コーディングモンキーのジレンマを解決する方法があります！ここで重要なのは、チームメンバーが疎外感を感じず、より良いソリューションを提供できるようにする方法論とプロセスを用意することです。
-明確で標準化された入力と出力を備えた明確な共同開発モデル（アジャイルが最適）を用意します。
-提案されたソリューションを適切に検証します：ユーザージャーニー、ペルソナ、テスト、調査、ヒューリスティックレビューなど常に明確に構造化された根拠を提供および共有し、他のメンバーがそれらを読むように奨励します（簡単ではありません：）
-関係者全員をチームに参加させ可能な限り早期のリファインセッションと外部化UXの作業：当然のことながら、誰もその地位になりたくない彼らは常に誰か他の人に反応しているところです！人々は、自分が何をしているのかを知ることよりも、相談を受けることを自分でコントロールしたいという気持ちがあります。
-聴覚障害者の会話に参加しないでください代わりに、すべての意見をボードに取り、仮説に変換してテストします。結局のところ、私たちがすべてユーザーの利益のために取り組んでいるのであれば、テスト結果は予約の誤配置に対する非常に説得力のある議論になるはずです。
-いくつかの設計プリンシパルについて合意を得て、さまざまなユースケースを文書化するパターンライブラリを作成します。（クイックゲイン）
このリストは完全なものではありませんが、原則として、初期段階から最終リリースまでの開発プロセスに全員が積極的に貢献していることを確認する必要があります。
本当の人種差別と闘うのと同じように、役割人種差別は人々を集めることによって最もうまく取り組まれます。同じチームで一緒に働きます。
私はおそらく人種差別を軽視するつもりはないことを認めるべきであり、魔法のように私が人種差別を取り除くことが許されたなら、本当の意味で最初に行くでしょう。
問題の一部ではないことから始めます。ステレオタイプを信じたり、参加したり、広めたりしないでください（自己完結型です）。 UXカンファレンスに行ったことがある場合は、少なくとも1人のスピーカーが、猿や穴居人のように振る舞うことで、エンジニアや開発者をからかっている可能性があります。それは通常意図された悪意ではなく、おそらく意図された皮肉で行われます。それは大笑いします。参加しないでください。
他の回答には、コラボレーションを促進する方法論に関するいくつかの優れた提案があります。
組織全体では、組織全体を変更する立場にない可能性があります。マイクロに影響を与えることで、マクロに大きな違いをもたらすことができると思います。計画/スタンドアップに参加するよう依頼してください。問題に取り組むとき、おそらくワイヤフレームはラップトップを持って開発者と一緒に座り、30分ほど共同作業を行います。開発者を批評に招待します。
あなたは時々ばかに見えるかもしれませんが、誰が気にするかもしれません。また、人のつま先を踏む可能性があるので、気を付けて控えめに（ただし、それを続けてください）。少しの習慣が当たり前になると、より大きなものを提案し始めることが時々可能です。