Re : プログラマとコミュニケーションの取れるディレクターになるには
プログラマとコミュニケーションの取れるディレクターになるには – あと味
静的Webで通用した時代と違い、今はプログラマとコミュニケーションが取れるスキルは必須です。技術について朝までプログラマと語り合えるぐらいの知識を持っていた方が、私は良いと思っています。技術なくして提案はできない。
id:jdgがプログラマとディレクタの関係について面白い事を書いているので、補足というか、別視点というかそういう事を超上から目線で自分への戒めも含めて考えている事を書いてみる。新潟の方のダムが好きなプログラマから「よくお前が言えるな」といわれそうだけれどとりあえず書く(汗。
そもそも、「プログラマとコミュニケーションの取れるディレクター」というのは間違ってはいないのだけれど、それをちょっと誤って解釈すると「プログラマと仲良くなる」というような解釈になってしまいそうなので、「ディレクタはクライアントとプログラマ(orデザイナ)の通訳であるべきだ」と解釈した方が正確ではないかと思う。
で、id:jgdか量を書いて主張している「何を使えば何ができるかだけ把握し使用方法は捨てる。」には同意。「できることと出来ない事」についてはかなりの精度で把握している必要があり、仮にどれだけ時間かかってもいいから自分(ディレクタ)でやってみろと言われたときに出来る事の範囲で案件を着地させなければならない。
それから、ディレクタはプログラマやクライアントと常にフラットな立場であるべきだと思う。時にはプログラマが要件を満たした後でも納期を考えずクオリティを追求したり、クライアントのニーズを考えずに技術トレンドに走りたがったりしたときに、客観的に判断して制御しないといけない。
とはいえ、それはプログラマに対して高圧的になると言う意味ではない。プログラマが納期がこれだけかかるといわれればそれを問答無用で納期を理由にハードワークさせるのではなくクライアントと要件を調整する責任がある。じゃなきゃ伝書鳩だ。まあこれは当たり前ですが、けっこう無視されているのも事実。
具体論に進むと、プログラマほど属人的な性格が高い仕事もないのではないかとおもう。ある人が10日かかる事もある人は1日で出来たりする。なのでディレクタとしては、「プログラマ」として認識し人区勘定するのではなく、「プログラマのAさん」「プログラマのB」さんと別の職種のようなレベルで区分けをし、その人の得意な分野や好きな事、苦手な分野を把握してアサインする必要がある。要はプログラマはプログラマというファンクションではないという事。
また、前にやった案件の焼き直しでは、優秀なプログラマほど飽きる。クライアントのニーズを前提として、技術トレンドやその人の志向にそった「燃える」ワンポイントな機能や技術を盛り込んだりして、プログラマ(orデザイナ)を楽しませる事も、ディレクタのとても大切な仕事のひとつだと思う。
細かい話としては、プログラマにはまずワークフローを共有しお互い納得するまで議論する。本人が意識していないレベルでフォーターフォールを前提に考えて仕事をしている人が多いので、ウェブには沿わないのではないかという事は説明する。なので、要件を伝えるときには、「決まっている事」「決まっていない事」「変わる可能性がある事」をきちんと説明する。そうすれば優秀な人ほどいい意味で手を抜きながら開発をスタートしてくれる。
以上書き散らかしましたが、これがまったく出来ていない時に僕の無茶に答えてくれた新潟のダムが好きなプログラマや、なんだかんだでつきあいの長いインプレッサが好きなプログラマに全て教わったことです。心から感謝しています(棒読み)。というわけで、ツッコミ大歓迎。(酔った頭で書いています。その点ご考慮下さい。)
たまに、工数マイナスのプログラマも居ますので、気をつけて :-)
ディレクターの責務は、無茶な要求を突きつけるクライアントの防火壁となる事。複数の案件で進捗に応じてプライオリティーを付け、間に合わなさそうな所には納期調整をするか、人員を組み直すか、外注に出すかといったQCDを調整する事。クライアントが言いたい事の要件を明確にする事。といった所かな？
プログラマー的な思考(没頭？)と、ディレクター的な思考(俯瞰？)は別物だからよほど特殊な人で無ければこの二つを効率的に回す事は難しいと思います。
>373@dp3
>プログラマー的な思考(没頭？)と、ディレクター的な思考(俯瞰？)は別物だからよほど特殊な人で無ければこの二つを効率的に回す事は難しいと思います。
あーそれはありますね。
風呂敷を広げる人とたたむ人みたいなw。
クライアントの妄想とプログラマの恍惚は意外に相反することは少なくて。
どちらかと言えば、コストや納期といった現実との相談が殆どだと思うこの頃。
そういった諸々の現実や思惑を集めて、ゴールを指し示すことがプログラマとのコミュニケーションではなかろうか？
ただ、コミュニケーションの前提は信用なので、プログラマに信用されることが先なんだろうけどね。
少しくらいは、騙すけど（鬼）
騙すというか、知らないふりをするというか(謎