Posts Tagged ‘コミュニケーション’

WCAF Seminar Vol.3 開催します。

2010/03/03(Wed) Diary

いわごろが代表をさせてもらっているWCAF(ウェブ・クリエーターズ・アソシエーション・福井)。Vol.1、Vol.2と単体でのイベントを開催した後は、去年11月のCSS Nite、今年1月のWeb・IT技術者大交流会と他のイベントに乗っからせてもらって活動していたのですが、久しぶりに単体でのイベントを開催します。

今回は、デザイナーとエンジニア、二つの視点でのセッションを行います。デザイナー側は、グラフィックからウェブまで手がけるヒュージの中村さん。エンジニア側はRIAの分野を追いかけている伊藤さんです。

詳細は、下記のような感じです。

◎WCAF Seminar Vol.3のご案内

日時:2010年3月20日(土) 13:30開始(13:00〜受付)〜17:00終了(交流会込)
場所:AOSSA 607研修室
内容:
・ごあいさつ(5分)

【セッション1】
・『コミュニケーションの視点から考える
Graphic designerのweb design』(45分)
Graphic designとWeb designを行き来しながら日々仕事で考えている事。コミュニケーションの視点から考える双方媒体の得手不得手や、現場から見る違い、クライアントに関わる時に必要なデザインという考え方を1つの案件を追いながらお話しします。

スピーカー:中村 文信(株式會社 ヒュージ)
中村文信
ブランド構築からコンサルティングまでデザインというフィールドで幅広く活動しているデザイン会社「株式會社ヒュージ」所属。良いデザインで世の中を良くするという考えの基にグラフィックデザインとウェブデザインを中心に手がけている。また実験サイトの設立など、個人としても精力的に活動中。

【セッション2】
・『ぎゅ〜っと濃縮、HTML5』(45分)

開発者の視点から、現在仕様策定中のWeb標準技術であるHTML5、JavaScript APIについて紹介します。新たに追加される要素群、アプリケーションプラットフォームとして重要な機能を担うGeolocation、Web Workers、Web Storage、Data Cache API…etcまで、デモを交えて解説します。HTML5を使うためのTipsも。

スピーカー:伊藤 祥 / shoito
伊藤祥
福井で働くソフトウェアエンジニア、Flex(Flash)を使ったWebアプリケーションやソフトウェア設計ツールの開発をしている。RIAの分野に興味津々、デザイン/開発スキルを兼ね備えた二刀流エンジニアを目指している。HTML5-FITという北陸のコミュニティを主催。

・交流会(60分)
交流会セミナーと同じ部屋で、
ノンアルコールでお菓子をつまみながら情報交換など。

参加費:500円(場所代とおかし代)

定 員:30名

申 込:申込フォームからお申し込み下さい。

興味のある方はご参加くださいませ。

仕事するのにオフィスはいらない

2009/08/15(Sat) Book

仕事するのにオフィスはいらない 表紙
仕事するのにオフィスはいらない
佐々木俊尚 (著)

「オフィスがない」「フリーランス」「契約で仕事をする」と聞くと、そういうイメージでとらえられてしまうのは否めません。しかし本書で明らかにしようとしているノマドの生活はそのような「弱者」としてではなく、あくまでも個人としての矜持を保ち、そして自宅やカフェや外出先などでテレワーク的な仕事をこなす独立独歩な人たちを指して、ノマドと呼んでいるのです。能動的に行動し、何のために仕事をしているかという価値観をしっかりと持って、新たなワークスタイルを実践している人たちが、ノマドなのです。

東京から福井に帰って仕事をし始めてもうすぐで1年になるけれども、なんとなく感じていた福井で仕事をする感覚というものが具体的にまとまってきた。東京の会社と福井の会社での一番の違いは、仕事の幅が福井では多くならざるを得ないという事ではないかと思う。僕が経験した会社は数社しかないので以下それが前提になりますが。

東京の大きめの会社だと、会社自体はいろんな事業をやっていたとしても、プレーヤーであれば一つの事業や一つの業務を担当しそれに責任を持つわけで、ポジティブに見れば専門性を磨きやすく、ネガティブに見れば歯車となりやすい。僕が福井に帰ってきて良かったことの一つが、大変ではあるけれど一人で広い範囲を見れる事。

ただ福井だと当然市場や金額が小さいので、一つの事業を同時にたくさん行うか、専門以外の事もやるパターンが多い。専門以外の事というのも二つあり、一つのテーマに集約される(サイト構築でディレクションもコーディングもする)のならまだしも、いわゆるなんでも屋(ネットやってるならPC詳しそうだからプリンターの設定もやってよ)になりがちである。特にネット・IT分野は。この二つは「幅が広い」と同じように定義できるかもしれないけれど、実際の所かなり違う。いくらプリンターの設定がうまくなってもウェブ構築にはまったくプラスにならない。クライアントとのコミュニケーションという意味では否定しないけれども、実際の所それでは収まらないものがある。

そんなわけで、フリーランスになる事は考えていないけれども、会社の中にいながらノマド的な働き方って出来ないだろうかという視点でこの本を読んだ。とはいえ、最初から福井でそれは難しいだろうなと思っていた。自分自身、ディレクターという立場でデザイナーが隣にいて一緒に作業できる「場」を共有することが仕事のしやすさという意味でも制作物のクオリティという意味でもプラスになっている事を実感しているから。

デジタルツールやクラウドを使ってのコミュニケーションと言っても、発信する側だけではなく受け取る側にもそれなりのリテラシーが必要になるので、そう簡単にはできない。それに、社内からもクライアントからも、同じ「場」を共有することをストレートに求められるし、その有用性は僕も感じているので、本書を読んでも、福井という場とディレクターという僕の職業上、可能なのかどうかはいまいちまとまらなかった。

ただ、最近今のままのスタイルで仕事をしていくのはしんどいなぁと思う機会が増えてきている。地元に帰って知り合いとの交流が(これでも)前に比べれば増え始めていたり、地方だからといってクライアントが求めるレベルが下がるわけではなくより具体的で効率のよい対応を求められる。絶対的に東京の時より仕事に割く時間が増えているし、時間があるときも気持ちの余裕が減っていて、結果的に新しい事を学んだり知識を深めたりする時間が減ってしまっている。

仕事のやり方を変えないとなんだか持たない気がしているけれど、ノマドは本人の変化よりも周りがノマドを受け入れる事の方が労力が大きいように感じるので、その変化が直近で起きるとも思えない。それに、場を共有することのメリットを僕自身が実感しているというのもある。が、近視眼的な事を続けても僕も周りも誰も得しないのでなんとかしたいのだけれど、どうしたものか、という堂々巡り。

ヱヴァンゲリヲン新劇場版:破

2009/08/09(Sun) Movie

序をたいして期待せずに見たのにかなりおもしろかったのでつい破に期待しすぎてしまったのか、最初見たときはかなりガッカリした。しかも、見た劇場のスクリーンがかなり小さくて絵が汚いのにもガッカリ。そしてそして、今回のアスカの処遇。僕の中ではエヴァはアスカとミサトがメインなので、アスカの悲劇は次回かなと思っていたのに今回こんな形で出てくるとは。。。

なんかもうそのアスカがショックすぎて、他のストーリーが全然入ってこなかった。戦闘シーンもたしかに凄かったんだけど全然覚えてなくて、ついもう1回見た。そして、今回のアスカは「惣流・アスカ・ラングレー」ではなく「式波・アスカ・ラングレー」なのだと、若干強引気味ではあるけれど、整理してなんとか落ち着いた。

で、2回目に見たら、ストーリーがずいぶんシンプルになっている気がした。3部作の2作目というつい繋ぎとしてだれてしまう所を、旧世紀版のセリフやシーンを使いながらもそれの意味がまったく違う意味を持っており、旧世紀版があってこそ出来る事ではあるけれども、ずいぶんとわかりやすいストーリーになっている気がする。まさしく破。

しかし、どうこの話に結論を出すのか。旧世紀版でいい意味でも悪い意味でも特徴的だった他者依存や自己否定や不完全なコミュニケーションが、破ではことごとく解消されいているように感じる。そういった要素を排した中で、この時代に再構築された答えが何なのか。その新しい答えを見たくて、結局Qも見てしまう気がする。

26歳。

2009/03/16(Mon) Diary

26歳になりました。毎年誕生日にはブログを書いてると思ってたんですが、23歳を最後にここ2年ほどは書いてなかったみたいです。でもまぁ、最近ブログあんまり書いてないので、考えている事を整理がてら残しておくことにします。たぶん散漫でまとまりがない文章になると思いますが。

今の自分の頭の中で漠然と思っているのは、福井で暮らしながら、福井のクライアントと生活者のために、チームとしてはコミュニケーション、いわごろ個人としてはインフォメーションアーキテクチャを軸に、顔の見える個人に向けて一つ一つ丁寧に仕事をしていきたいなぁということです。これまでこのブログに書いてきたいくつかの目標の中から、こぼれ落ちている物(ex.技術)もあれば変わらずに持ち続けている物(ex.ウェブ)もあり、いろいろ形を変えながらではありますが、今に至ります。

なんとなくではありますが、思い通りになる事よりも、思い通りにならない事の方が最近増えてきたように思います。そのおかげかどうかは分かりませんが、以前に比べるとだいぶん寛容になったと思いますし、どうせいろいろこぼれ落ちてしまうのだからと自分の考えや想い自体は以前にも増して刺々しくなっているようにも思います。

また、自分を壊そう壊そうと意識的に動いていたりもします。今までの自分が作りそうな物をいったん否定してから物を考えていくようにしたり、新しい分野になるべく顔をつっこんでいろいろなことを覚えたり、これまで得たことを学び直したりということも意識的にやっています。若干散漫な感じもしていて、フォーカスがゆるんでいるという風にも思っていたりはしますが、仕事でもスケジュールやクオリティを守れる範囲であえてカオスにカオスになるようにしています。今後のためには、無駄なことではないだろうと思って。

僕が仕事をし始めたときの初めての上司というか、先輩的な人と僕が初めて会ったとき僕は17歳でその人は26歳くらいだったように思います。1・2歳間違ってるかも知れませんが、まあその人はそのぐらいの年でした。その人みたいになろう、なんて事は今は思っていませんが、これまで仕事をしてきた中で、26歳になったときに、26歳の時のその人を超えられているだろうか、みたいなものが心のどこかにずっとありました。

超えるも何も時代や社会の環境も違うし、何をもって超えたとするのかという明確な基準があるわけでもないです。そしてその人はそのときから8年くらい経ってまたどんどん先を走っていっているので、永遠に追いつくことはないでしょうし、距離が縮まっているのか、差が開いていっているのか、それさえもよく分かりません。

ただ、けして縛られているという意味ではなく、これからもずっとどこかでその人の影を追いかけていくような気がしています。向こうにしたらはた迷惑な話かも知れませんが、個人的にはその人のような羅針盤的な人と出会えたことはとても幸せなことだと思うし、僕が言う話ではないと思いますが、東京でどんどん先を走っていって欲しいと勝手に思ったりしています。僕もその背中を追いかけて、若干向かう方向は違うのかも知れませんが、福井で走っていきたいと思っています。ちっぽけではありますがこれまで蓄えてきたスキルと経験と17歳の時の初心を両方忘れずに、明日もまずは目の前のことをきちんと形にしていきたいと思います。不束者ですが、26歳になったいわごろを宜しくお願いします。

「集団」と「チーム」

2009/03/09(Mon) Diary

偉そうなことを書きますが、毎度のことなのでご容赦下さい。野村監督と桑田投手の対談を見ていて、「ただ頭数だけが揃っているのが集団」で、「人が互いに機能するのがチーム」だという野村監督の言葉を聞いた。福井で仕事し始めてもうすぐ半年で何となく福井の事情みたいなものが分かってきたり、会社からどこまで本気かどうか知らないけれど別にビル建ててウェブのチームを作れみたいなことを言われていて、自分の中で禁句に近かった「チームをつくる」事への意欲が少しづつ沸いてきた。

福井の人は、とにかくまとまらない。「日本一社長が多い県」というのも、「独立心の強さ」ではなく「協調性の無さ」から来るものだと思うんだけれど、とにかく独立したり個人事業主という人が多い。それはそれでひとつの生き方だからいいんだけれど、チームになればもっといろんな事が出来たりクオリティを高めたりできるだろうにと、もったいない感じがしている。

個人的にはチームみたいなものを作ろうとして一度勝手に失敗しているのでトラウマ的な感じではあるんだけれど、今の会社でウェブを専属でやっているのが僕だけという状況が拍車を掛けているのか知らないが、仲間がもっとほしいと思う機会が増えた。それはウェブの人だけで固まろうという意図はなく、逆にそれは嫌で、コミュニケーションというひとつの軸でウェブもマスも関係なくクライアントとユーザを繋ぐことができるチームを作りたいなぁ、というかそういうチームで働きたいなぁと思う。

それは独立して社長になりたいとか、マネージャーになりたいという意味ではなくて、それは前述のトラウマもあってどちらかというと嫌だし客観的に見ても適材ではないと思う。必要であればやることは拒まないけれども、そういうチームがあって、その一員としてきちんと現場で動いていたい。今の会社はそれのベースにはとても最適だと偉そうに勝手に思っているけれど、まだまだ足りない要素が多いとも感じる。何も急ぐことはないので、ゆくゆくの目標。そのために、目の前のことをしっかりやります。

巧告。

2009/02/11(Wed) Book

巧告。 表紙
巧告。
企画をヒットさせるために広告クリエイターたちが考えること
眞木 準 (著), 副田 高行 (著), 中島 信也 (著), 山本 高史 (著), 京都広告塾 (編集)

「表現」という営みに参加しているぼくたちが達成すべき目的は何なのかといえば、それはやはりコミュニケーションをつくることではないでしょうか。

会社の人に借りて読んだ本。会社の環境上広告系の、これまで自分が買おうと思っていなかった本がいっぱい転がっているので、ちょくちょく本棚を覗かせてもらっては借りている。

最近よく言っている言葉だけれど、ウェブを作る人は、まあウェブの知識も必要なんだけれどそれはあくまで最低限やるべきことなので、それ以外にグラフィックデザインとか広告とか認知社会学とか宗教とか、そういうウェブ以外の知識を仕入れた方が良いと思う。本でも映画でも人に会うのでも良いけど。

ウェブの人は、どうも思想を持っている人が少ない。たまにいるのだけど、そういう人はたいていどこか違う分野でそういった思想を確立させてからウェブに来ている人が多いように思う。じゃあお前は持ってるのかと言われれば持ってないのだけど、持とうとしてるからもうちょっと待って。

以下返してしまうので付箋を付けたところの書き出し。

クリエイティブディレクター 山本高志
・受け手の言って欲しいことを言ってあげる。
・大きな声を出すこと、相手の知らないことを言ってあげること、受け手が言って欲しいことを言ってあげること。
・ふつうの人であること。
・世界最小最軽量のバカ
・「20本のバラからのぞく妻の顔は20年前の笑顔でした」これははっきり言ってしまえば嘘です。

アートディレクター 副田高行
・写真、タイポグラフィ、イラスト、タレント

CMディレクター 中島信也
・「あなたは頭は悪いが足が速い。コースは私が考えるから、そこをつっ走れ。(佐藤雅彦)」
・「表現」という営みに参加しているぼくたちが達成すべき目的は何なのかといえば、それはやはりコミュニケーションをつくることではないでしょうか。
・「すぐれた才能にすごい努力を掛け算して、さらにそこに「悪」を掛けてしまえば、社会にとって役に立たないどころか、その仕事は社会に対して悪い影響を与えるものになってしまいます(稲森和夫)」

コピーライター 眞木準
・キャリアを生かした社会貢献は、当然の責務だと考えているからです。

受託開発の極意

2008/11/09(Sun) Book

受託開発の極意 表紙
受託開発の極意
–変化はあなたから始まる。現場から学ぶ実践手法
岡島 幸男 (著)

要件を定義するには、ユーザと同じ視点を持つ必要があります。つまり、どうやって作るか(How)ではなく、何を作るか(What)、なぜ作るのか(Why)という意識をもたなくてはいけません。

開発者は視点を切り替えなくてはいけません。システムを作る立場ではなく使う立場で考え、お客様と一緒に考えを整理していく必要があります。

そこに必要なのは広い意味での問題解決能力であり、プログラミングや設計のスキルだけでは足りません。業務に対する知識はもちろんのこと、要件を引き出すために高いコミュニケーションスキルが必要となります。

同じ福井の永和さんの本。ちょっと前にネットの中でもいくつか取り上げられていたので、受託の現場に帰ってきたら読もうと思っていた。「SEの教科書」とだいたいの主張は同じなんだけれど、クライアントとの接し方、見積もりの作り方、要件定義の仕方と具体論に踏み込んでいる。

こういういろんな本を読んでいると、あるべき受託開発へのイメージがだいぶハッキリしてくる。今の時点でイメージしているのは「結果に責任を持って物も作るコンサル」といったところ。コンサルと書いたのは、コンサルって口だけなイメージがあるので(失礼)、実際にそれをクライアントと一緒に作っていくサービス業のようなイメージ。

クライアントから言われたシステムをクライアントから言われたとおりに作ったり、いかに他社より安い金額で開発するかに心血を注いだり、自分たちのやりたい技術のエゴを振り回してクライアントを放っておくのではなく。クライアントの求める物と自分たちが持っている技術の間を探り、必要とされているニーズを解決する事が、本来の受託開発という仕事なんじゃないのかなぁという気がする。

この本では最終的には組織を変える事にまで言及しているけれど、できればクライアントを変えるという所にまで踏み込んで欲しかった。安かろう悪かろうのシステムを求めるクライアントは最終的にクライアント自身が損をして、システム開発に対するイメージがどんどん悪くなって次の案件でも同じような事を繰り返してしまう、というのはどう解決したもんだろうか。

SEの教科書2

2008/11/09(Sun) Book

SEの教科書2 表紙
SEの教科書2
~成功するSEのプロジェクト計画・運営術
深沢 隆司 (著)

読者の皆さんの会社のプロジェクトが、必ずと言うほど遅延したりコストオーバーになったり、多くの仕様変更やバグが発生しているとして、それを読者自身が「仕事とは、プロジェクトとは、そういうものだ」と考えているとしたら、あなたの脳の仕事で使っている部分は、すでに誰か他人のものになっている(あなたの思考パターンではない)かもしれませんので、そう自覚してください。(中略)

そして、これが行われていないために、本来は頭脳労働のはずが、実際には体力勝負、頭脳勝負の業界になってしまっているのではないかと思います。

前作のSEの教科書を借りて読んですごく面白かった記憶があったので、本屋でこれを見かけて即買ってみた。前回に引き続き結構面白くて、スケジュールを立てるタイミングやその組み立て方は参考になった。

これを読んでいると、SEとかプログラマーに必要なスキルというのは、もちろん技術も必要なんだけれど、コミュニケーション能力な気がしてくる。まあコミュニケーション能力はどんな仕事でも大事なんだけれど、SEやプログラマは他の業種に比べてその辺を軽視しているような気がしてくる。

陳腐な例だけど、クライアントがとんでもない要求をしてきてその実現方法を必死に考えていたのに、営業がシンプルに実現できる代替え案を提示したらあっさりOKをもらってしまったりと、技術だけ、自分たちだけで考えてしまう傾向があるように思う。

そこで大事なのは、やっぱりクライアントが何を求めているのか、どういった課題を解決したいのかという「何が問題なのか、どうしたいのか」を技術手法ではなくニーズというレベルで把握する事なのかなぁと思う。

Re : プログラマとコミュニケーションの取れるディレクターになるには

2008/11/06(Thu) Clip

プログラマとコミュニケーションの取れるディレクターになるには – あと味

静的Webで通用した時代と違い、今はプログラマとコミュニケーションが取れるスキルは必須です。技術について朝までプログラマと語り合えるぐらいの知識を持っていた方が、私は良いと思っています。技術なくして提案はできない。

id:jdgがプログラマとディレクタの関係について面白い事を書いているので、補足というか、別視点というかそういう事を超上から目線で自分への戒めも含めて考えている事を書いてみる。新潟の方のダムが好きなプログラマから「よくお前が言えるな」といわれそうだけれどとりあえず書く(汗。

そもそも、「プログラマとコミュニケーションの取れるディレクター」というのは間違ってはいないのだけれど、それをちょっと誤って解釈すると「プログラマと仲良くなる」というような解釈になってしまいそうなので、「ディレクタはクライアントとプログラマ(orデザイナ)の通訳であるべきだ」と解釈した方が正確ではないかと思う。

で、id:jgdか量を書いて主張している「何を使えば何ができるかだけ把握し使用方法は捨てる。」には同意。「できることと出来ない事」についてはかなりの精度で把握している必要があり、仮にどれだけ時間かかってもいいから自分(ディレクタ)でやってみろと言われたときに出来る事の範囲で案件を着地させなければならない。

それから、ディレクタはプログラマやクライアントと常にフラットな立場であるべきだと思う。時にはプログラマが要件を満たした後でも納期を考えずクオリティを追求したり、クライアントのニーズを考えずに技術トレンドに走りたがったりしたときに、客観的に判断して制御しないといけない。

とはいえ、それはプログラマに対して高圧的になると言う意味ではない。プログラマが納期がこれだけかかるといわれればそれを問答無用で納期を理由にハードワークさせるのではなくクライアントと要件を調整する責任がある。じゃなきゃ伝書鳩だ。まあこれは当たり前ですが、けっこう無視されているのも事実。

具体論に進むと、プログラマほど属人的な性格が高い仕事もないのではないかとおもう。ある人が10日かかる事もある人は1日で出来たりする。なのでディレクタとしては、「プログラマ」として認識し人区勘定するのではなく、「プログラマのAさん」「プログラマのB」さんと別の職種のようなレベルで区分けをし、その人の得意な分野や好きな事、苦手な分野を把握してアサインする必要がある。要はプログラマはプログラマというファンクションではないという事。

また、前にやった案件の焼き直しでは、優秀なプログラマほど飽きる。クライアントのニーズを前提として、技術トレンドやその人の志向にそった「燃える」ワンポイントな機能や技術を盛り込んだりして、プログラマ(orデザイナ)を楽しませる事も、ディレクタのとても大切な仕事のひとつだと思う。

細かい話としては、プログラマにはまずワークフローを共有しお互い納得するまで議論する。本人が意識していないレベルでフォーターフォールを前提に考えて仕事をしている人が多いので、ウェブには沿わないのではないかという事は説明する。なので、要件を伝えるときには、「決まっている事」「決まっていない事」「変わる可能性がある事」をきちんと説明する。そうすれば優秀な人ほどいい意味で手を抜きながら開発をスタートしてくれる。

以上書き散らかしましたが、これがまったく出来ていない時に僕の無茶に答えてくれた新潟のダムが好きなプログラマや、なんだかんだでつきあいの長いインプレッサが好きなプログラマに全て教わったことです。心から感謝しています(棒読み)。というわけで、ツッコミ大歓迎。(酔った頭で書いています。その点ご考慮下さい。)

同期はしたいが統合はしたくない。

2008/07/03(Thu) Mac

iPhoneを手に入れてからのネット環境をどうしようかと考えている中で、懸案だったのがメール。ソフトバンクから提供されるいわゆるケータイメールとGmailなどのいわゆるPCメールを統合しようかどうかという点。

やろうと思えばMobileMeというデータシンクサービスを使ってアドレスを一つだけにしてPCローカルでもブラウザからでもiPhoneからでも同じ一つのアドレスで送受信することは出来るんだけど、いろいろ考えてやっぱりやめてみた。

PCメールはなんとなくの共通認識としていつもPCの前にいるわけではないから返信は遅いこともあるという扱いだと思うのですが、ケータイメールはいつも携帯している電話に送っているのだから返信は早く来ると思って相手は送ってくると思うのです。

そういう、極端に言えば電話にするかメールにするかぐらいの用途分けで相手が送ってくるメッセージを一つにまとめるのは受け取るこちら側が混乱する。一つにまとめてiPhoneに届くたびにバイブする設定にすることも出来るけれど、PC向けメルマガが届くたびにバイブされても面倒。というわけで、おそらくiPhoneを手に入れてもPCメールとケータイメールは別々で使う予感。やっぱりコミュニケーションサービスの運用ルールは環境や使う人の国民性に大きく依存するのだ。