LogoMark.png

Project の変更点


#author("2020-09-12T15:06:33+09:00;2019-10-24T10:17:54+09:00","default:inoue.ko","inoue.ko")
*プロジェクト
人と社会の未来のために、pro + ject = 前方(未来)に向かって投げかける
~

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

//[[九州産業大学プロジェクト型教育>http://www.kyusan-u.ac.jp/guide/kiku/]]

~
#contents2_1
~

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

***プロジェクトの目的を確認・共有しましょう
-何のために
-誰のために
~

***プロジェクトの遂行には時間計画が必要です
-プロジェクトの完成予定(締め切り)をまず確認しましょう
-''遂行スケジュールを立てましょう(最も重要な作業です)''
&size(12){[[参考:プロジェクトの遂行に必須>ガントチャートの様々なイメージ>GoogleImage:ガントチャート]]};
~

***プロジェクトの遂行には空間計画(確保)が必要です
-プロジェクトを実現する場所は?
-遂行に必要な空間(作業・会議スペース等)
~

***プロジェクトの遂行にはメンバーの役割分担の明確化が必要です
-プロジェクト・マネージャ
--全体を見て指示を出す''コンダクター''です
--締め切りまでにすべてを遂行する全責任を負います
--自分自身は特定の「作業」を抱え込まない方が良いでしょう
-サブ・マネージャ
--プロジェクトの遂行に関わる各種''データの管理''
--会議の''議事録''、イベント時の''写真記録''等、補佐的な仕事
-現場監督
--「作業項目(タスク)」ごとの代表(大きなプロジェクトの場合)
--当該タスクの全体のとりまとめ
--他のタスクとの連携
-スタッフ
--現場で実際の制作等にあたります
--個々の作業について即戦力となる技術と知識が必要です
~
~

**テーマ決めについて
デザインプロジェクトは基本的に長期的な視点に立って計画する必要があります。以下の点に留意して、テーマを選定して下さい。
~

***そのテーマはあなたにとって「面白い」ですか?
長期の取り組みです。プロジェクト自体があなたにとって「面白い」ことであるかどうかが重要です。「単位を取るために・・せねばならない」というスタンスだと辛いだけです。どうせ取り組むなら、面白いことにしましょう。
~

***プロジェクトのゴールがイメージできますか?
-最終的な成果物を頭に思い描くことができていればOKです。
-ただし、ゴール(目標)を「決め打ち」するのは賢明ではありません。プロトタイピングとテストを繰り返すうちに、まったく異なる解決案が浮上してブレイク・スルーが起こることがあります。チャンスを逃さないためにも、ゴールは「ゆるめ」に設定するのがオススメです。
~

***プロジェクトの先に誰かの笑顔がイメージできますか?
-誰からも共感されないプロジェクトは、おそらく途中で頓挫します。
-よく「自分のやりたいことが見つからない」という相談を受けることがありますが、そもそも「自分のやりたいこと」というものが本当に存在するのかを疑う必要があります。
-簡単な思考実験でわかることですが、「人類が滅んで、あなた一人が生き残った」その状況で、人は何かプロジェクトを起こしたいと思うでしょうか? 言葉が不要になれば、意識・思考も止まります。おそらく人という生き物は、自分自身の中に「やりたいこと」があるのではなく、''他者との関わりにおいて「やりたいこと」が生まれてくる''・・そういう生きものなのではないかと思います。
-あなたが作ったもので、誰かが喜ぶ様子が思い描けるか。これはプロジェクトをブレないものにするために、最も重要なことではないかと思います。
~

***そのテーマは、あなたの知識・技術で実現可能ですか?
-現時点でその技術がなくとも、短期間学習コストをかけることで、実現できる目処があればOKです。
-できるかどうかわからない・・というプロジェクトに着手してしまうと、途中で挫折>テーマ変更>成果が不十分・・となりかねません。
-高度な技術を駆使することがデザインではありません。画期的なデザインというのは、もっと上流のコンセプトレベルで生まれるものです。
~

***プロジェクトに身につくスキルに将来性はありますか?
私自身、最新の技術や、専門的な技術が、数年で陳腐化して使えないものになるという事例を何度も見てきました。「最新のプログラミングライブラリー」や「最新のソフトウエアの使い方」など、「誰かが作った仕様・ルール」というのは、世の中の変化や、メーカー都合によって「不要」になることがあります。そうしたものに振り回されないよう、プロジェクトで使用する技術の将来性を十分に検討して下さい。
例)[[Google:Flash 将来性]]
~

***失敗しても構いません
-失敗を前提に無謀な取り組みをするのはよくありませんが、真摯に努力を重ねた上での失敗から学ぶことは多々あります。
-当初の予定どおりの成果が実現しなかったとしても、成果報告の際に、なぜ失敗したのかについて、きちんと説明でき、それが将来同じ失敗を繰り返さないための糧となるのであれば、良しとします。
-失敗できるのは、学生の間だけです。失敗を恐れずに積極的に新しいことに取り組んでください。

~
~

**具体的な手順

***プロジェクト・マネージャー(リーダー)を決める(仮でも可)
-誰かが進行を務めなければ何もはじまりません
-「船頭」が多いと収集がつかなくなるので「ひとり」が原則です
-プロジェクト遂行経験がありメンバーとの面識も豊富な人物が適しています

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

~


***メンバー間連絡先情報の交換 ・ 情報共有手段の確保
-メンバー間の連絡手段の確立も、まず先にやっておくべきことです
-ガントチャート、議事録など、あらゆる情報をクラウドで共有します
-プロジェクト専用のGoogleアカウントを取得。Gmailがあることで、
--Googleドライブ等で、各種ファイルの共有が可能
--フリーサーバーのアカウント
--YouTube動画チャンネル
//--USTREAMチャンネル
--Facebookアカウント
--Twitterアカウント
--LINEアカウント
など、プロジェクトで利用する様々なサービスを集中管理できます。
~

***要求分析(現状把握)
クライアントが存在するプロジェクトの場合(大半がそうですが)、まず何をして欲しいのかということを、聞き出す必要があります。ここでクライアントの希望を聞き損ねないよう、しっかりインタビューしてください。
-要求されていることは何か?
-解決しなければならない問題は何か?

~

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

例えば、「卒業制作」(一人プロジェクト)でも、最低限以下のことを確認しましょう。
-完成した作品は展示・公開できるのか(アウトプットの場はあるのか)?
-自分の今ある技術で実現可能なのか?
「見通しの立たない見切り発車」はデザイナーのすることではありません
-作品制作、また展示に必要な、材料や道具は調達できるのか?
~

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

-''5W2Hの確認''
--''何を''
--''誰が''
--''いつまでに''
--どこで
--何のために
--どのような方法で
--想定される費用(予算)は
~

-''1) 何を(What 遂行すべき「作業項目(タスク)」)''
--この項目がプロジェクトの日程計画における基本要素です。「ひとつの作業項目には必ずひとつのアウトプット(成果物)がある」と考えて、その成果物をイメージしながらやるべき作業項目を抽出していきます。「Webサイト」という大きな単位のアウトプットもあれば、「ページに掲載される商品の写真」という小さな単位のアウトプットもあります。規模の大小にかかわらず、機材や労力またお金がかかるので、作業項目としてはきちんと明記していく必要があります。そして、これらは最終的には視覚的にもわかりやすく「階層的」に整理される必要があります。
--最初にプロジェクト全体を大きく4〜7項目程度に分けてからさらに分解する・・・というトップダウン(幹から枝葉へ)的な発想で項目を洗い出すこともあれば、逆に、思いつく限りの「作業項目」をすべて付箋紙等にリストアップして、次にそれらをグルーピングして整理していくというボトムアップ(枝葉から幹へ)的な発想もあります。私の経験では、思いつく限りの項目を無作為に並べて、ボトムアップ的に整理していく方が「抜け」がありません。「キャッチコピー決め」、「〇〇さん取材」、「商品撮影」、「搬入・搬出用トラックの手配」、「イベント当日の弁当の手配」、「バッテリーを充電」など、プランニングの初期段階では、付箋紙を用意して、思いつくことを躊躇なく書きだすことからはじめましょう。
--あと、忘れてはいけません。「プロジェクト管理(アウトプットはガントチャート)」という「作業項目」自体も忘れずに・・・。これはプロジェクト・マネージャに課せられた最も重要なタスクです。

-''2) 誰が(Who 担当者)''
--上の「作業項目」の次に重要な項目です。「誰がやるの?」これが決まらないと、その先の詳細な計画ができません。「作業項目」のおおまかな整理が終わったら、担当を決めて個々の項目ごとに詳細な計画を立てましょう。
--ひとつの「作業項目」に対して複数の担当をあてる場合は、責任者を一人決めます。「〇〇さんがやっていると思ってた・・・」というような「抜け」を避けるためにも、一項目一責任者が基本です。
--また、一人の人物を複数の「作業項目」に兼務させる場合も注意が必要です。「キャッチコピー決め」と「〇〇さん取材」など、時間差で作業が可能でな場合もありますが、同時刻に異なる場所に出現するようなことはできません。チャートの中では、メンバーを色分け表記するなどして、同一人物の動きがバッティングしないよう配慮することが必要です。

-''3) いつまでに(When 締め切り)''
--プロジェクトのガントチャートの基本は時系列になります(横軸が時間)。よって当然ですがこの部分がチャートの中で、最も大きな面積を占めます。例えば30日のプロジェクトであれば、30列。すべての「作業項目」について、開始日〜終了日を横長の棒状に書き込むことで、プロジェクトの進行が視覚的に見えやすくなります。

-4) どこで(Where 作業場所・実施空間)
--忘れられがちな項目です。会議ひとつとっても、事前に会場を予約しておかなければ先に進みません。「どこでやるの?」ということも付記する必要があります。

-5) 何のために(Why プロジェクトの目的との整合性)
--一見不要に思える項目ですが、すべての「作業項目」はプロジェクトの目的を達成するためにあるべきです。思いついた「作業項目」がプロジェクトの目的に合致していることを確認・付記しておくことも大切です。
--後になって「これは作る必要なかったね」というような資源の無駄遣いを未然に防ぐためにも、「目的との照合」は重要です。

-6)  どのような方法で(How 必要な技術・ツール)
--「作業項目」ごとに必要な道具と技術を付記します。「商品撮影」といっても、それには「カメラ」や「照明」といった道具と、撮影技術が必要です。「撮影」の担当者は、「そもそも与えられたカメラを使いこなせるのか?」、「撮影したデータはどのようにして取り出して引き渡すのか?」。「商品撮影」に求められた「写真」というアウトプットを得るためには、ひと通りの作業を体験しておくことが必要で(この話は、学生によるプロジェクトを前提としています)、そのためにも、「必要な技術や・ツール」についても付記する必要があります。

-7) いくら(How match 予算)
--人が動くとき、モノが動くとき・・・必ずお金がかかります。移動にかかる「交通費」なども大きな出費のひとつです。「作業項目」ごとに、想定される経費を洗い出して付記しておきましょう。
~

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

***計画の遂行/管理・コントロール Do
-メンバーは、個々の「作業項目」について、各担当者が責任をもってその計画を遂行します。他の「作業項目」の進捗をお互いに情報共有しておくことも重要です。

-リーダーは全体を管理・コントロールします。計画どおりに事は運ばない・・・というのが常です。当初の目的・計画と照合しつつ、「作業項目」ごとにチェック、OKをくりかえし、必要に応じて修正をしながらプロジェクトを進めていきます。リーダーの管理能力が問われる場面です。
~

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

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

~
~


**用語

***プロジェクトの3要素
プロジェクトには「鉄の三角形」とも言われる以下3つの要素が存在します。
-時間
-資源
--ヒト
--モノ
--カネ
-スコープ((スコープ=規模、範囲。プロジェクトの成果として求められるものの「範囲」を意味します。つまり、成果として必要なものと、そうでないものを見極める…ということです))

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

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

タスクは、以下の3つの概念で整理することができます。
-(1)マテリアル
-(2)リソース(人的資源と物的資源)
-(3)情報

製造つまりハードをつくる仕事と、設計つまりソフトを作る仕事では、様子が異なりますが、例えば、
-製造系のタスクでは、部品という「マテリアル」をインプットとし、労働力+機械設備という「リソース」を占有して、製品という「マテリアル」がアウトプットされます。
-設計系のタスクでは、要求仕様書という「情報」をインプットとして、知的労働力という「リソース」を占有して、設計図という「情報」がアウトプットされます。

例えば「商品撮影」という作業項目を例にとると・・・
-商品という''マテリアル''と撮影アイデアという''情報''をインプットとして
-カメラや照明(機械設備)とスタッフの労働力という''リソース''を占有して、
-撮影した写真の画像データという''情報''がアウトプットされます。
~

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

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

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


**ツール

-プロジェクト管理ソフト
--Google Drive に追加してして利用できるツール  [[Gantter>http://gantter.com/]]
--オープンソースの「プロジェクト管理ツール」 [[Redmine>http://redmine.jp/]]

-スプレッドシート 
いわゆる表計算ソフトのことです。プロジェクト管理専用ツールでなくとも、表が書ければスケジュールの管理は可能です。多くの人が使用経験のあるものなので、専用ソフトに比べて誤操作のリスクは減ります。

-付箋ソフト
企画段階でのブレストに便利 参考 [[KJ法>GoogleImage:KJ法]]

-アンケート用紙サンプル
http://www.bizocean.jp/doc/category/208/
http://econavi.owners.ne.jp/template/file/065-00000000773
~
~

**研究室関連プロジェクト
|[[九州産業大学 生命科学部>http://lifescience.kyusan-u.ac.jp]]|公式サイト制作(3年・制作中)|
|[[NPO芸術の森デザイン会議>http://afdn9.com/main/]]|公式サイトリニューアル(2年・運用中)|
|[[船小屋温泉郷Webサイト>http://www.funagoya.org/]]|公式サイトリニューアル(2年・運用中)|
|[[ArtSpace+Library>http://art.kyusan-u.ac.jp/artspace_library/]]|図書館プロジェクト(2年・運用中)|
|[[長住大通り商店街>http://nagazumi.webcrow.jp/]]|公式サイト立ち上げ(4年・運用中)|
|[[九州クリエイターズマーケット>http://afdn9.com/9kuri/]]|[[つくりびと応援プロジェクト>Project/9kuri]](4年)|
|[[9クリ・アーカイブス2014>http://www.afdn9.com/archives2014/]]|[[つくりびと応援プロジェクト>Project/9kuri]](3年)|
|[[9クリ・アーカイブス2013>http://www.afdn9.com/archives2013/]]|[[つくりびと応援プロジェクト>Project/9kuri]](3年)|
|[[芸術の森デザイン会議>http://afdn9.com/]]|Webシステムの導入支援|
|[[9クリ・アーカイブス2012>http://www.afdn9.com/archives2012/]]|[[つくりびと応援プロジェクト>Project/9kuri]](1-3年)|
|[[鞍手町歴史民俗博物館>http://kurate-museum.com/]]|Webシステムの導入支援|
|[[ARTSPACE+50>http://www.kyusan-u.ac.jp/J/art/ArtSpacePlus50/]]|キャンパスに50のアートスペース(4年)|
//|[[芸術学部アーカイブス>http://www.kyusan-u.ac.jp/J/art/Archives/]]|[[学部情報のアーカイブ>Project/KYU-GEI]](2-4年)|
|[[アートスペース貘>http://artspacebaku.net/wiki/index.php?%E5%B1%8B%E6%A0%B9%E8%A3%8F%E8%B2%98]]|Webシステムの導入支援|
//|[[芸術学部Webサイト>http://www.kyusan-u.ac.jp/J/art/]]|[[PukiWiki]]による情報共有(4年)|
//|[[SpreadBlender>http://www.kyusan-u.ac.jp/J/art/main/index.php?Spread%20Blender]]|Blenderの普及促進(1-4年)|
|[[船小屋温泉郷Webサイト>http://www.funagoya.org/]]|公式サイト制作(2年)|
|[[FT4(2009)>http://faam.city.fukuoka.lg.jp/FT/2009/jpn/]]| 福岡アジア美術館2009(4年)|
//|[[九産大美術部>http://93art.blog102.fc2.com/]]|美術部ブログ(3・2・1年)|
~
~
~