そうじゃなくても、必ずしもプロジェクトで成果を出すのはむずかしいわけですから、せめて最初の定義と計画はきちんとしないとね。
プロジェクトのデザイン
大なり小なりプロジェクトを行う上では、ざっと下記のリストのようなことを検討する必要があるでしょう（リストはできるだけいろんなプロジェクトに対応するよう一般化してみました）。最初の「定義」の部分で、タスクと役割とスケジュール、その他リソースが紐づいた状態でプロジェクトをデザインしておかないといけないと思います。
- 定義
- ミッションとヴィジョンの明確化
- 目的と測定可能なゴールの設定
- ターゲットの明示
- 必要なタスクの洗い出し
- メンバーの選定と役割分担
- スケジュールの作成
- 実施においてのコミュニケーション・ルールの決定
- 関係部門と影響の洗い出し
- リスクの洗い出し
- 現状把握・分析
- 3C分析などのフレームワークを使った現状の把握と整理
- 必要な調査の実施
- ミッションと現状のギャップの分析
- ヴィジョンの再検討
- 戦略・コンセプト
- ギャップを埋めるための戦略の検討
- 各ターゲットとのコミュニケーション・シナリオの作成
- シナリオからの要件抽出・構造化
- 設計
- コミュニケーション・シナリオと要件リストに基づくモデリング
- モデルをベースにした具体的なデザイン案（プロトタイプ）の作成
- プロトタイプを使ったシミュレーションの実施
- 検証・修正
- プロトタイプによるデザイン案の検証
- 検証データに基づく問題点の抽出～改善案の作成
- デザインの改善
- デザイン・フィックス～設計図の作成
- 実装・オペレーション
- 実装計画またはオペレーション計画の作成
- 実装またはオペレーションの実行
- 効果の検証・リフレクション
これができてないと、どんなにそれが重要であろうと共同作業を行うこともままならなくなります。『ペルソナ作って、それからどうするの？』
のなかでも書いてますが、プロジェクトのデザインが最初に行われていないと、みんなで手を使って作業をするワークショップベースのデザイン･プロジェクトはまわりません。だって、計画がなければ、いろんなメンバーがワークショップの場を共有することがむずかしくなりますから。
でも、多くのプロジェクトがプロジェクトというものを舐めているのか、最初の「定義」の段階で、目的やゴールの明確で具体的な設定や、タスク－役割－スケジュールを紐づけるプロジェクトのデザインってことをしないんですよね。それで場当たり的にはじめちゃうと、ぜんぜん作業は進まないし、手戻りは多いはで、最初に期待した成果のほんのすこししか達成できないか、途中で頓挫してしまうこともしばしば。
プロジェクトそのものもデザインの対象なんですけど、そもそもデザイン感覚がない人が多いんでしょうね。
関連エントリー
- 作業を共有することの重要性と可能性
- 横浜デジタルアーツ専門学校・Web科箱根合宿 リフレクション
- ユーザー中心のデザインは「みんなで手を動かしながら考え」なきゃ進まない
- みんなで手を動かしながら考えるということを図にしてみました。
この記事へのコメント