LogoMark.png

Project

プロジェクト

人と社会の未来のために、pro + ject = 前方(未来)に向かって投げかける

はじめに

プロジェクトとは、何らかの具体的な目標を掲げた「計画」と「遂行」を意味します。一般には、複数のメンバーで協調的に行うものですが、一人で目標を掲げ、一人で遂行する場合もあります。「卒業制作」などに一人で取り組む際も、ひとつのプロジェクトと考えて、進行管理を行うとよいでしょう。
尚この記事は、教育を目的として(専門家ではない)学生が協調してプロジェクトを遂行する場合を想定しています。プロ集団で形成されるプロジェクトとは、取り組みの前提が異なる点をあらかじめご了承下さい。



プロジェクトを推進するにあたって

プロジェクトの目的を確認・共有しましょう

プロジェクトの遂行には時間計画が必要です

プロジェクトの遂行には空間計画(確保)が必要です

プロジェクトの遂行にはメンバーの役割分担の明確化が必要です

具体的な手順

プロジェクト・マネージャー(リーダー)を決める(仮でも可)

リーダーとは
ここでいうリーダーの仕事とは「自分のやりたいことを部下に指示する」ことではありません。メンバーそれぞれが才能を発揮して最大の成果が得られるように調整するのが仕事です。
 生命体という組織をイメージしてください。例えばヒトの60兆個の細胞の中に全体に指示を出すような細胞はありません。個々の細胞は、基本的には「お隣の細胞」とケミカルな情報交換を行なっているだけですし、中枢にあるように見える「脳」も、複数の細胞が連携して、いわばサーバーのように全体の情報交換の中核を担っているだけです。個々の細胞には全体は見えていません。それでも、情報がスムーズにやりとりされていれば、全体はうまく動くのです(自律分散協調系)。
 企業にも地域にも、社会組織というものにはリーダーが必要ですが、自分の思い通りに事を運ぶためにメンバーを使うようなリーダーでは組織の内部にガンが発生して内側から破綻します。個々のメンバーがイキイキとなるように、情報の流れを調整すること、それこそがリーダーの役割だと思います。


メンバー間連絡先情報の交換 ・ 情報共有手段の確保

要求分析(現状把握)

クライアントが存在するプロジェクトの場合(大半がそうですが)、まず何をして欲しいのかということを、聞き出す必要があります。ここでクライアントの希望を聞き損ねないよう、しっかりインタビューしてください。


実現可能性の確認

具体的な「計画を立てよう!」という段階に入る前に一旦冷静になりましょう。
 このプロジェクトは「今ここに集まった資源(人、モノ、カネ)で実現可能なのか?」ということを確認しておく必要があります。つまり最終的なアウトプットができるのか?ということです。ホワイトボードなどに軽く全体像を描きながら、技術的に実現不可能なプロセスはないか、必要な道具はすべて揃っているのか、お金は足りるのか・・・途中に大きな落とし穴がないかメンバー全員で確認して下さい。着手してしまってから「実現不可能」となったのでは、そこまでに費やした時間や労力無駄になってしまいます。メンバー全員で「実現可能性の確認」をしておきましょう。
 特に出口(アウトプット)の確保は重要です。グループ展であれば、まずは「会場と日程の確保」、Web制作であれば「サーバーの確保」、ホテルにチェックインしたらまずは非常口の確認・・。要するに最終的な出口(アウトプット)に至るプロセスと可能性をまっ先に確認する必要があるということです。

例えば、「卒業制作」(一人プロジェクト)でも、最低限以下のことを確認しましょう。

計画をたてる Plan

GanttChartAnatomy.png

クラウドで共有できるプロジェクト管理ツールスプレッドシートを活用して、作業全体のイメージをガントチャートのかたちに記載してメンバー全員で共有します。
 プロジェクト管理ツールでは、プロジェクトの性質に応じて、何をどのようにチャート化するか、いくつかのプロトタイプが用意されていますが、要は5W2Hを意識しながら縦軸に作業項目、横軸を日程として整理すればよいので、普通の表計算ソフトで管理する方法でもまったく問題ありません。むしろ、メンバー全員が使い慣れたものを使う方が誤操作のリスクを減らすことができます。
図版:ガントチャート by Malyszkz  en.wikipedia.org/wiki/File:GanttChartAnatomy.svg

補足 : 「作業項目(タスク)」はどこまで細かく掘り下げるのか

例えば「商品撮影」という作業項目を例にとると、それを遂行するには、その階層下に「スタジオの手配」、「カメラの準備」、「機材運搬のための車の手配」、さらにそれらの下には「カメラのバッテリー確認」、「車にガソリンを入れておく」など、「それを言い出したらきりがない・・・」というぐらい詳細な項目が出てきます。しかし、「バッテリーが切れていた」というだけで、すべてが無になってしまうので、油断は禁物です。
 とは言え、これをすべて一人の人間が把握して計画するというのでは、負担が大きすぎます。実際には「商品撮影」を担当するメンバーが、「商品撮影」を遂行するために必要な詳細項目をすべて把握・実践できればいいことなので、全体のチャートには「商品撮影」とだけ書いて、あとはメンバーにまかせる・・・。要は、ひとつの「作業項目」を「ひとつのアウトプット」と考えて、そこまで分解したら、あとは個々の担当者がそれぞれのアウトプットを期日までに確実に遂行できるようにすればよい・・・ということです。
 では、個々の担当者はその作業をどこまで分解して管理するか・・ですが、「これ以上分解すると、逆に管理の方が面倒になる」・・・というレベルで止めるのがふつうです。「撮影」経験豊富な担当者であれば、わざわざ書きだして管理する必要はありません。「撮影」の経験が乏しい場合は、「交換レンズは準備したか?」、「バッテリーの充電は?」など、その準備に必要な項目を「ここまで書けば失敗しない」というレベルまで洗い出してチェックリスト的に記載する必要があります。
 ちなみに、「撮影」に慣れた人でも油断は禁物です。「頭に入っている」というレベルで忘れ物をしないのは、せいぜい7項目程度です。数十項目に及ぶ準備が必要な場合、「出発前準備確認>チェックシートの提出」のようなタスクを明記するのがいいでしょう。



計画の遂行/管理・コントロール Do

検証する Check

成果を発表して終了・・・ではありません。最終成果の成り行きを追跡調査し、プロジェクトが目標を達成したか否か、客観的な検証が必要です。

運用と改善 Act

プロジェクトは「生き物」です。実際に運用すると、様々な問題が出てきます。これらは継続的に改善しつづけることが必要です。




用語

プロジェクトの3要素

プロジェクトには「鉄の三角形」とも言われる以下3つの要素が存在します。

時間、資源、スコープは、相互に影響しあうもので、ある要素を変更すると、他の 要素も変更する必要が生じます。
 例えば、「一日前倒しして早く仕上げる」つまり「時間の短縮」には、人を増やす・道具を拡張する・消費電力を増やす(お金をかける)などの「資源の増強」か、完成品の規模や機能を減らすといった「スコープの縮小」が必要になります。
 また例えば、 製品に機能を追加する、すなわち「スコープの拡大」 には、「時間」の延長 か、作業人員を増やす・機材を追加投入するといった「資源の増強」が必要です。一定の品質を維持するには、これらの3要素のバランスを考えながら、プロジェクトを遂行することが求められます。

タスク Task

プロジェクトを構成する個々の「作業項目」のことです。タスクは、プロジェクトと同じで、「インプット」と「アウトプット」また「完了条件」が定義されるのがふつうです*2。つまり、タスク自体「小さなプロジェクト」と考えることができます。
 さて、実際にプロジェクトに着手した場合、「何をひとつのタスクとして括るか」が悩むところだと思います。ここで重要なのは、全体が見通せるか、人間の頭でそれがわかりやすく整理できるか、ということです。したがって大枠としては、プロジェクト全体を誰が見ても自然な3〜7項目程度のタスクに分割するのが良いでしょう。なぜなら、人間の頭が同時(一挙)に把握できる項目はせいぜい7±2(G.A.ミラー)程度で(学生プロジェクトの場合は、4±2程度が理想です)、これ以上項目が多くなると見落とし(エラー)が多くなってしまうからです。
 で、大枠が決まったら、さらに下位の「サブ・タスク」に分解し、階層化して整理します。大きなプロジェクトではこの階層が深くなるので、タスクのレベルごとに「中間管理職」をが必要になります。要するに会社と同じです。
 ここで次の疑問が生じます。「サブ・タスク」はどこまで分解すればよいのでしょうか?。作業を分解していくと「鉛筆を持つ」とか「線を引く」といったところまで行き着くのですが、一般的な目安としては「これ以上分解すると、管理の手間がかかってかえって効率が悪くなる」という線で分解を止めます*3。この線引きは、個々のタスクを抱える現場のスタッフの経験によって異なる、つまり経験が豊富なら「ざっくり」でいいので、トップダウン的に全ての現場に同じレベルの管理を求めるのではなく、上司は現場を信用してまかせる、それができるだけの信頼関係が非常に重要だ・・・ということになります。

タスクは、以下の3つの概念で整理することができます。

製造つまりハードをつくる仕事と、設計つまりソフトを作る仕事では、様子が異なりますが、例えば、

例えば「商品撮影」という作業項目を例にとると・・・

WBS Work Breakdown Structure

WBS_sample.jpg

プロジェクトを構成する個々のタスクを階層的に分類して図式化したものを、WBS=作業分解図といいます。「タスク」の項で書いたイメージと同じですが、例えばひとつのプロジェクトが、「企画」、「設計」、「生産」、「販売」の4つからなる場合、例えば「設計」は、「基本設計」と「詳細設計」の2つのサブタスクに分割可能、「詳細設計」は、さらに「機械設計」「回路設計」「外装デザイン」などに分解できます。「設計」はレベル0、「詳細設計」はレベル1、「機械設計」はレベル2、などと階層化される・・・というぐあいです。「タスク」の項でも書いたように、管理が煩雑になって逆効果にならない粒度で分解は止めます。大きなプロジェクトでもタスクの階層は4段階程度に収めます。
図版:WBS by Masaqui ja.wikipedia.org/wiki/ファイル:WBS_sample.jpg

アクティビティ Activity

開始と終了の日時が定義された作業。要するに「タスク」とほぼ同義語なので、詳細は省略します。区別して使う人もいますが、その場合は感覚的には、アクティビティがより期間の長い取り組みで、タスクはもっと細かな作業(デイリー・タスク)というような意味で使われているようです。

リソース Resource 資源

材料以外に、「タスク」を完成させるために必要なものをリソースといいます。人的労働力、機械設備、電力、燃料、水等、資材などさまざまな種類のリソースがあります。ちなみに、リソースにはエネルギーや資材などの消費されるものと、機械設備のように再利用可能なものがあります。



ツール

研究室関連プロジェクト

九州産業大学 生命科学部公式サイト制作(3年・制作中)
NPO芸術の森デザイン会議公式サイトリニューアル(2年・運用中)
船小屋温泉郷Webサイト公式サイトリニューアル(2年・運用中)
ArtSpace+Library図書館プロジェクト(2年・運用中)
長住大通り商店街公式サイト立ち上げ(4年・運用中)
九州クリエイターズマーケットつくりびと応援プロジェクト(4年)
9クリ・アーカイブス2014つくりびと応援プロジェクト(3年)
9クリ・アーカイブス2013つくりびと応援プロジェクト(3年)
芸術の森デザイン会議Webシステムの導入支援
9クリ・アーカイブス2012つくりびと応援プロジェクト(1-3年)
鞍手町歴史民俗博物館Webシステムの導入支援
ARTSPACE+50キャンパスに50のアートスペース(4年)
アートスペース貘Webシステムの導入支援
船小屋温泉郷Webサイト公式サイト制作(2年)
FT4(2009)福岡アジア美術館2009(4年)






PAGES

GUIDE

DATA


*1 スコープ=規模、範囲。プロジェクトの成果として求められるものの「範囲」を意味します。つまり、成果として必要なものと、そうでないものを見極める…ということです
*2 逆にいえば具体的「アウトプット」や「完了条件」やがない事項、例えば「定例会議」などは「タスク」としては扱いません。いわゆる会議の類は、何らかのタスクの一部と考えた方がいいでしょう。
*3 ちなみに「製造管理」では、「鉛筆を持つ」とか「線を引く」といった「動作」レベルまで分解することがあります。
添付ファイル: fileWBS_sample.jpg 491件 [詳細] fileGanttChartAnatomy.png 553件 [詳細]
Last-modified: 2019-10-24 (木) 10:17:54