カレンダー

« 2008年9月 5日 »123456789101112131415161718192021222324252627282930

2008年9月 5日アーカイブ

一つ前の記事では自分の理想のゴールを考えてみたわけですが、目標を立てたところでそれに対する戦略がなければ意味がないということで、それを徐々に考えて行こうと思います。

今回は、チームのメンバーに対して、どのように進めれば達成感を感じてもらえるかを考えてみました。

自 分が思うに、この達成感ってのは満足ってだけじゃなくて、次の仕事へのモチベーションにも繋がる大きな要因です。たとえ、それが失敗であってもタダの失敗 であってはならないと思います。そのためにはその失敗というのは「トライ&エラー」の「エラー」でなければならないなと考えています。ま、そのエラーが最 後に起こって事故になっては困りますが(笑)

ということで「トライ」が重要になるんですね。そのトライすべきものは自分が要件として与えるものもあるかと思いますが、それじゃーつまらない。是非自分で「トライ」するものを見つけてもらいたい。

で も、うち以外の制作会社でもそうだと思いますが、今の若手の子達は自分で考えるということが苦手な印象です。それは、それっぽいことを言えば、進学のため の勉強が主眼に置かれる教育が問題だとかという話になりますが、その理由は何にせよ、クリエイティブな仕事を生業にする以上、あまり好ましくない傾向ですね。

確かに今は、要件を実現 するのに必要なノウハウを研修なりで付ければいいわけですが、Webの世界は数年後には現状とは大きく変わった世界が待ち受けている業界。その時代で主力 になっているであろう今の若手に台頭してきてもらわなくてはたぶん会社的にも困るはず。そう考えている管理職は少ないでしょうね。

そんな思いがあるから、チームのメンバーには是非自分の案件で成長してもらいたい。

そのために何をするかですが、単純に要件を伝えたうえで「何をやりたい?」と考えさせるだけ。
企画の人、デザイナの人は考えて形に出すから比較的いい。中には要件以外のことが出来ない教えてちゃんもいるからその辺は攻めてみようと思うけど。
問題はコーダー。末端の人はほんと言われたことをやればいい。ないものを形にするんだから生産的活動にも見えるけど、個人的にはベルトコンベアーの脇に立って流れ作業をこなす量産的活動に思える(「生産的」というのもいまいちしっくり来ない言い回しですが)。
原価云々の問題がネックですが、本当にいいものってそういう活動の中でなければ生まれないと思うので、チャレンジしてみたいと思います。

あと、これはうちの会社的な問題なのですが、正式なアサインは動き出しの直前にならないと出来ないというルールがあります。それでは「トライ&エラー」の回数を増やすことが出来ない。この辺をどうにかうまく統制できないか考えてみたいです。

そういう風に考えていると、ディレクターという考え方よりも、ファシリテーターが理想かもしれない。

ひとまず、ディレクタになりたての私にとっては、これを実践するためにも、まずは当たり前のことが当たり前に出来るレベルまで到達することが最優先課題ですね(笑)
自分にとっても今はトライ&エラーの最初の「トライ」の時期。一般的なところを学んで、その中で違和感を感じるものは自分なりの解決策を見つけて、そして失敗していこうと思います。
ディレクタの業務では様々な問題に直面します。
お客様のこと、お金のこと、デザインのこと、営業のことなどなどなどなど。
どれもこれもが「これが答えだ!」とは言えないものばかりです。

コーダーだったころは、ブラウザの崩れだとかJavaScriptの作成だとか、誰がやってもその作業がゴールしたときに目に見えるものはほとんど同じだった。

でもディレクタの仕事では、同じ問題であっても担当するディレクタが違えば色々な形の解決がなされる。目に見える「デザイン」だとか「JSの動き」だとかというレベルでも、全く違うものが出来上がる。

でもそれはそれで1つのゴールなんですよね。

形は違えどゴールはゴール。

なんだかコーダー的な考えでは違和感が最初ありました。
でもよくよく考えると、その形が違うものに共通するものがあります。「顧客満足」という部分ですね。それを思った段階では、自分なりに納得できたのですが、なんと言うか違和感が残っていました。

「お客さんが満足してくれればそれでいいのかな?」
「お客さんが満足しても実際にはエンドユーザが満足しないとだめだぞ」

ということです。
じゃあ、エンドユーザが満足出来るものが完成すればそれが正しいかと言えばそうではなく(Webの性善説ではこういう論調はありますが)、やはりお客様の満足は必要不可欠な要素だなと。

となると本当のゴールは何なんだろうとなります。

今思っている範囲では次のような結論です。

・要件を満たすことは1つのタスク
・お客様の満足を得ることも1つのタスク
・エンドユーザの満足を得ることも1つのタスク
・予算内に収めて会社的な満足を得ることも1つのタスク
・チームのメンバーが達成感を得ることも1つのタスク
・自分が達成感を得られることも1つのタスク

つまり、これらの様々な要因が「納得」してくれるものはなんだろうと考えて目標を持つことがまずは大事かなと。
そしてその目標を達成するように動かして「納得」させることがディレクタのゴールなのかなぁと。

「自分との戦い」って感じに近いかな。

でも非常に難しいだろうなぁと思う。
経験が無い今だと「これを出せば納得してくれるべ」って思っても読み違えることが多いだろうしね。ま、最初のうちは失敗するタイプだし、理想を求めて試行錯誤ですね。

なので今から要件定義に入る案件ばかりなのでそこで色々な目標を立てて「納得させれるディレクション」を目標にしたいと思います!

ま、これも1年後には古い考え方になっているかもしれませんが(笑)、それは成長した後に見えてくれるものでしょうし、今の自分にとってはちょうどいい難しさの理想なのでしばらくはこれで楽しみたいなと思いまーす。
これまで景気の良し悪しなんて考えたこともなかったわけですが、最近は業務の中で普通にそういったことを目にする機会が増えた。
その要因のひとつはディレクタに異動したことが大きく、さらにはそういった環境の中で経済を知りたいと思い始めたこと、そして、会社の経営陣もそういった世の中の不況を朝礼などで口に出すようになっており、経済を知らなければならない環境になったからとも言えると思う。

正 直、経済のことがなどちゃんと勉強もしたことがなくほとんど分かりません。そんなことを言うのは新人の子達でも言えるわけで、不況下において経済を知らな いままにしておくことは、自分の首を絞める結果にもなりかねないと思い始めました。つまりは、会社の経営陣から発表される計画が、どのような戦略のもとに 決定されているのかを推測することと言えるわけで、内部要因・競合・ターゲット・自社の市場に関しては、表面的な部分かもしれないですがイメージが沸きま す。ただ、今回トピックに上げた「経済」や、「法令」などの環境要因に関してはまったく見当を付けようがないほどの知識不足な状態です。

そ こで手っ取り早く行っているのが、ロイター記事を眺めること。はっきりいってその各記事の内容なんて3割くらいをやっと理解できるようなレベルです。それ でもそういう行動をしているだけで知識欲はかきたてられるので、私にとっては経済を学ぶに当たってのよい動機になっているように思えます。

単純なところでいうと、「サブプライムローン問題って何?」から始まり、「原油価格が低下したのに何で市場が回復しないの?」などちょっとずつは知識が付いていっている、

気がします(笑)

その「気がします」を少しでも確実なものとするためには、やはりちゃんとした本での基本知識の吸収が必要不可欠だなと思います。

ディ レクタになってまず最初に自分に足りないと思ったのは「システム・ネットワークの知識」で、その次が「編集・デザインの知識」でした。後者は今案件を進め る中で、前職のコーダーの前工程という位置づけで考えることで比較的そこまで問題にはならないだろうと感じてます。前者に関しては当初感じたことのまま、 場当たり的に知識を吸収するのではなく積極的に勉強しなければならないと感じています。

そして今回の「経済」に関しては、ディレクタ云々以前にビジネスマンとして必要な知識ですね。

身 を委ねていては、後戻りの出来ない断崖絶壁の窮地に立たされる事だってありえるような状況です。「会社から逃げ出す機会を察知する」ためとしてではなく、 「会社というコミュニティの中で自分がすべきことや意見すべきタイミングを察知する」ための知識として、積極的に勉強していこうと思います。

今勤めている会社がこの不況下で倒れる会社ではないと思ってはいますが、つらい状況になる可能性はあると思っています。
そこを見識をもって自ら積極的に乗り越えたときに、自分が大きく成長出来ているのではないかと思っています。

というか期待しています、自分に(笑)

このアーカイブについて

このページには、2008年9月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2008年9月 4日です。

次のアーカイブは2008年9月 7日です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

MovableType(MT) 4.1 テンプレート 無料(フリー)
Powered by Movable Type 4.1