早く大きく進めるためのプロジェクトとメンバーについての認識
株式会社Da Vinci Studio デザイン部 フロントエンドテクノロジストのshibaです。
メンバーのパフォーマンスを担保しつつプロジェクトを早く大きく進めるには何ができるだろう？と考えるのが最近のテーマです。
きっかけについては以前の記事にかるーく書いています。
うまくやれば組織としてのアウトプットを加速させる
「うまくやれば」ってなんやねん、ということでそれに活かせそうなことを色々勉強しています。
というわけで、「プロジェクト」と「メンバー」についての知識をまとめてみました。
今回はプロジェクトとは複数人で一つの課題に取り組む個人の集まりであること、それを早く大きく進めるためにはチーム単位と個人単位での認識の統一が重要であること、そのための知識とテクニックを紹介します。
プロジェクト
プロジェクトの定義
なにかの成果目標をもって複数人が集まって進める実践共同体
求められるもの：作業
進める人：メンバー
進め方の文化・それを形成する活動：ファシリテーション
こうやって整理すると、学生の頃にこなしたチームでの課題や展示活動など
、もしかしたらやったこともないですが会社経営もある意味プロジェクトと定義できるかもしれません。
ここでの整理では決定よりも作業にフォーカスしていますが、作業は決定に紐付いて発生するものなので意図的に省略しています。
では、プロジェクトで良い成果を生み出すための条件は何でしょうか？
各メンバーによる作業に意味付けができている
作業の意味付けには作業や課題に対する共通認識が求められる
プロジェクトに必要な作業、課題に対する共通認識を持てていることは本当に大切な条件だと思います。
なぜそれが必要かがわからなければ、どうアプローチしていいかもわからない。
デザインであってもエンジニアリングであってもいろいろな基準をもとにアプローチを選択するのであって、基準（この場合は共通認識）がブレるとメンバーの活動に一貫性が失われてプロジェクトとしてうまく進めなくなるおそれがあります。
メンバー
では、その共通認識をもたせる対象となる「メンバー」とはどういった存在でしょうか？
例えばデザイナー
細かく分ければいくらでも分けられてしまいますが、最低限2つに分けてみました。
造り手がユーザーに主張したいことを感じさせることが得意なデザイナー
ビジュアル, ロゴ, コンセプト, ブランディング...
重視する概念：美しさ、オリジナリティ、主張
ユーザーがわかりやすい/使いやすいと感じさせることが得意なデザイナー
UI, IA, インタラクション, 問題解決...
重視する概念：ユーザー視点、客観性、ユーザービリティ
この2つの一番の違いは、作業の目的となる根本的対象が異なることです。
前者は「造り手」。
IT業界であれば発信者であって、得意な作業は発信者の意図をユーザーに主張するための活動です。
後者は「ユーザー」。
得意な作業はユーザーが混乱や違和感を感じづらくするための活動です。
UCDやHCD、UI/UXデザインなどの言葉は基本的にこちらのデザイン活動に関連します。
これらは決して優劣はなく、関わるプロジェクトやプロジェクトへの関わり方によって得意分野を活かせるかが変わります。
前者と後者がチームを組めたりすると速度感・クォリティともにすごいことになりそうだな〜とか妄想する今日このごろです。
余談：後者のデザイナーは本当に「ユーザー」を根本的対象にとれているか
死ぬほど難しい問題で、言い換えると「[後者のデザイナー]がわかりやすい/使いやすいと感じるデザインを作っているだけじゃないか？」という問題提起です。
それを避けるために、自分の主観から目線をずらしてユーザーを客観視するための手法（ペルソナ、シナリオ、カスタマージャーニーマップなど）や活動（ユーザーインタビュー、アンケートなど）が確立されてきました。
後者のデザイナーにとって大切なのは主観より客観であることは確実であるものの、手法や活動で本当に実現できるのか？ということを考えて突き詰めていくと、最終的には「人間を知る」という哲学的な領域にまで足を突っ込むことになります。
いや、すべての人類・日本人に限っても知ることなんてできるわけない、けどいろいろな人を知らなければならない…という葛藤に対する諸々は「デザインの逆説」という本が面白かったので紹介しておきます。
例えばエンジニア
超脱線したのでそろそろ「メンバー」の話に戻して、エンジニアにも注目してみましょう。
こちらは2つに分けられると言うよりは、マトリクス的にいくらでもカテゴリが存在する気がしています。
例えば担当領域。
インフラ、サーバーサイド、フロントエンド、マークアップ。
例えば得意分野。
設計を得意とする人、構築を得意とする人。
技術体系も背景に必要な知識も領域や得意分野によって様々です。
改めて、「メンバー」
デザイナーとエンジニアでバッサリ分けただけでも色んな種類があることは明らかで、個人単位で見るともっと細かく差が出てきます。
メンバーは個人であり、それぞれが個人の目標を持っています。
プロジェクトの方で「作業の意味付け」という言葉を使いましたが、メンバーが個人である以上「個人がそれぞれ作業にスキル/経験・時間・目標を意味づけられる必要がある」ということになります。
このプロジェクトに参加する上で、自分は何を経験・学習・実践したいのか。
それがプロジェクトに求められる成果に合致しているか、どう重ね合わせるか。
これらはしておかないとモチベーションの低下に直結してしまう重要な検討です。
一方で、メンバーは個人であるもののプロジェクトは実践共同体です。
共同体である以上、個人的主張ではなくプロジェクトチームの一員としてプロジェクトに意見を出せるようにすることが求められます。
これが「作業や課題に対する共通認識」であって、同時に「判断軸の共有」でもあります。
では判断軸とはなにか？
これは「プロジェクトにとって大切な価値観」として捉えると考えやすいです。
連絡躊躇病を治す2つの質問 でも使ったテクニックですが、主語をプロジェクトにした価値観を共通認識とすれば個人の主張がぶつかる前にプロジェクトメンバーとしての判断をするか、プロジェクトにとっての価値観を見直す議論ができるはずです。
読んでくださりありがとうございました。
Da Vinci Studio は積極採用中なので、興味がある方はぜひ見てみてください。
またデザイン部のNoteマガジンもよろしくおねがいします！
この記事が気に入ったらサポートをしてみませんか？