webプログラマーとして仕事をしていると、ディレクターに対したくさんの不満が溜まっていきます。ディレクターの方で、プログラマーとうまくコミュニケーションが取れず悩んでいる方は多いのではないでしょうか。
また、プログラマーでも、ディレクターのあれこれに疲弊し会社を辞めてしまう方も多いのではないでしょうか。
本記事では、全てのディレクターとエンジニアが幸せに暮らすため、ディレクターがしてしまうとエンジニアに嫌われてしまうことや、逆にディレクターにして欲しいことをまとめました。
ディレクター経験もある現役プログラマーのぼくの実体験を元に書いていきます。
・プログラマーから見たディレクターの嫌なこと10個
・それらはお互いの
目次
クライアントの言ったことを全部鵜呑みにする
受託開発だとある程度仕方無い時もありますが、それでも限度があります。
クライアントは、開発がだいぶ進んでいるにも限らず「通ったらラッキー」精神のダメ元で、無茶な新規要件を追加で言ってきたりします。
それらを「クライアントが言っているから」という理由で全部受けてしまい、さらにはスケジュールのお尻は決まっているのでずらせず、結果的に開発陣が終電や徹夜対応になってしまうというパターンは、結構あります。
本来開発の仕様は実装前に固まっているはずです。実装の後半で新しい機能を追加するとなると、DBの設計やコードの構造を大きく変えなければならないことがあり、バグも生まれやすくなりますのでやりたくない。
ディレクターには、その追加要件が「本当に必要なのか」ということをクライアントとしっかり議論したのち、今このタイミングで必要かどうか判断し、それでも必要ならスケジュールをずらす交渉をして欲しいです。もしくは社内のリソースを増やすとか。そこまで頑張ってくれた後、それでもやらなければいけないなら、プログラマーもそれに応え頑張るはず。
「クライアントが…」という言葉を大義名分に、思考停止し全部対応するというのは、生産的でもないですし一発でエンジニアに嫌われます。
ディレクターがやるべき業務を大量に頼む
プログラマーは一旦開発に入ると、できるだけ開発に集中したく他のことはしたくありません。
納期に間に合わせるため予定工数分の作業をしないといけませんし、スケジュールも1日8時間開発した際のスケジュールで組まれています。
ですが、話の流れやディレクターの考え方によっては、資料作成やクライアントとのやりとりなど、本来はディレクターの業務を頼まれてしまいます。
頼まれた以上できるだけ対応してあげますが、あまりに量が多く高頻度ですと、ぼくたちプログラマーのストレスがどんどん上がっていきます。歳や年次が上な先輩ディレクターに「それはプログラマーの業務ではないのでご自身でやっていただけますか」とはなかなか言えないですもんね。
もちろん相談やプログラマーの手元がとても空いている時なら、多少やってもらうのもいいかもしれませんが、「この仕事は誰がやるべきなのか」を考え仕事を割り振ることが大切です。
作業にかかる工数・難易度を、自身で見積もり「簡単」と判断する
プログラマーがディレクターに言われて「むっ」としてしまう言葉に「クライアントの修正依頼来てたけど、簡単だから大丈夫だよ」というのがあります。
こういうことを言うディレクターは、技術に理解がなかったり自身で制作をしたことがない人が多いです。実際にシステムを組んでみるとわかりますが、表は簡単な修正に見えても裏では大変ということが多々あります。
例えば、「入力フォームに1項目追加する」という修正依頼がクライアントからあったとします。項目の追加なんて、たかが一項目ですし簡単な作業で15分くらいで終わるだろうと思うかもしれません。
しかし実際には、そこの項目を追加するためにその他たくさんの関係ある部分を調整しなければいけなく、ちょっと大変な作業の場合があります。もちろんディレクターの見積もり通り簡単な場合もありますが。
それを判断する(できる)のは実装者のプログラマーであり、技術に乏しいディレクターの場合はわからないことが多いです。それを表面的な判断で「簡単」と決めつけ言ってしまうのは、プログラマーの反感を大きくかってしまうので避けてください。
簡単に見える作業でも、「簡単そうに見えるけど、実際どのくらいかかりそうな作業？」 と言葉を付け足すだけでだいぶプログラマーの心持ちも変わります。
クライアント要望ではない修正をいつまでも要求する
制作物へのこだわりが強いディレクターにあることですが、クライアントからオーケーが出て納品間近にも関わらず、ディレクターが思う新規の修正依頼をプログラマーやデザイナーに頼む時があります。
これが、クライアントもディレクターも見過ごしていた大事な修正だったり、実装前やデバック時の修正依頼なら全然いいのですが、「それ本当に必要…？」と思うようなことを、全てが終わったタイミングで依頼してくるディレクターがいます。それもいっぺんにではなく小刻みに。
プログラマーとしては、やっと案件が終わりほっとし、場合によっては別のプロジェクトがスタートしています。そのタイミングで、本来やらなくてもいい(かもしれない)修正内容をちょくちょくやることはストレスで、疲弊してしまいます。
制作物のチェックのタイミングは事前に決めその時に本気でチェックする。極力その時以外には修正依頼をしないようにしましょう。
しなくていい作業をさせられる
クライアントと直接話をするのは基本的にディレクターです。プログラマーは、クライアントの話を聞いたディレクターの指示の元、コードを書いていきます。
なのでディレクターの指示出しがとても大事です。
そこで避けたいのが、指示ミスによる「やらなくてもよかったはずの作業をやってしまうこと」です。
頼まれて実装したにも関わらずそれが実はいらない機能で、コードを消してしまうのは、我が子を殺してしまうようでとても悲しいです。無駄な時間を過ごしてしまった感覚が強い。
もちろん、クライアントによる急な仕様変更や、単純な指示ミスによる無駄な作業の発生は仕方ありません。
しかし、ディレクターは「今プログラマーに頼んでいる作業がやらなくてもいい」とわかった際、なるべく早くそれを伝え、無駄がないよう最善を尽くして動いて欲しいです。
そこの危機感が甘く、プログラマーが半日かけて実装した後に「その機能やっぱりいらなくなったんだよね。」と一言で済ませるのは絶対に避けましょう。
資料を完全に横流しする
クライアントからきた様々なドキュメントを、自身で確認せずそのままプログラマーに転送するようなことは、絶対にやめましょう。
中には煩雑で読み解くのに時間がかかるドキュメントもあるので、そこを読み解きある程度情報の整理をすることもディレクターの業務のうちです。
技術メインのドキュメントの場合わかりづらい部分もあるかと思いますが、全てを理解しなくてもいいので「どんなことがどれくらい書かれているのか」全体像くらいは最低限把握しましょう。
でないとクライアントに適切な質問もできませんし、質問に応えることもできません。
専門的な話は完全に拒否
ディレクターの方で、技術的な話がでると完全にシャットダウンで話を聞いていない人がいます。ひどいとその打ち合わせにでなかったり。
技術的な話は難しくプログラマー並みに理解をする必要はありませんが、それでも何を話しているか理解する努力が大切です。
そしてわからないことは調べるなり聞くなりすると、プログラマーやクライアントも安心です。
技術的な話が全くわからないディレクターと話をするのは、なかなかコミュニケーションコストが膨らみますし、1から話をするのに骨が折れてしまいます。
元プログラマーのディレクターさんと一緒に仕事をする機会があったのですが、サーバー周りや実装の際のボトルネックとなる部分がすぐに伝わり、とてもやりやすかったです。
作業を高頻度で中断してくる
進行する上で気になる点を、逐一口頭で確認するディレクターがいます。
それはとてもいいことで、それによりディレクターとプログラマー間のミスマッチは減ります。しかし、人に話しかけるというのは人の時間を奪うもの。
集中して複雑なプログラムを組んでいる際に、ディレクターから30分ごとに質問をされると集中が途切れ作業が思うように進みません。プログラマーは自分の実装に集中するときはとことん集中してやりたいものです。
なので、質問する際は他に質問はないか、そして急用でないなら口頭ではなくタスク管理ツールで質問を投げておくなど、なるべく作業の邪魔をしないような配慮をしてもらえると助かります。
口頭で指示をたくさん伝える
上記の「作業を高頻度で中断してくる」でも記載しましたが、指示を「口頭で伝える」というのはメリットとデメリットがあります。
テキストで伝えるよりも、口頭で身振り手振りを使って伝える方がわかりやすく楽な場合もあります。
しかし、口頭で説明するとテキストに残らず、時にはあの時言った言ってないの水掛け論が起きる場合があります。
状況によりますが、なるべくタスクの項目としてredmineなりbacklogなりspreadsheetなりタスク管理ツールでテキストに残してくれた方が、ミスも少なく脳のキャパシティをコードの記載に割くことができます。
プログラマーは面と向かって話すのが苦手な人も多いですしね。
状況を判断せず100%完璧なものを求める
制作物の品質を担保するのもディレクターの仕事。完璧な制作物を作り納品することはとても大切で、クライアントの信頼にもつながります。
しかしそれも、その案件や人員の状況によりけりだと個人的には思います。
受託の仕事だと、本来は1週間かかる案件を3日で納品しなければいけないような場合もあります(本当によくないですが…) 。そうすると、土日出勤や終電帰りや、最悪徹夜の日々になることもあるでしょう。
そんな中、クライアントの品質チェックに耐えられるだけのコードを書けたにも関わらず、さらに完璧を求めるばかりに自身で修正の上乗せをするディレクターさんがいます。
姿勢としては立派で正しいのかもしれませんが、そんな非人道的な納期の中、非の打ち所がないコードを書くのは至難の技です。納品できることを第一に考え、多少汚いコードであったり拡張性に乏しかったりしても、そこは目を瞑ることも時には大切なのではないかと思います。
まとめ
プログラマーがディレクターに抱く不満を包み隠さず書きました。ディレクターの方は、そんな風に思っていたんだと驚くこともあったのではないでしょうか。
プログラマーの方は、多くは共感して頂けたのではないでしょうか。
プログラマー視点100%で書いていて、全てプログラマーにとって都合のいいことを書きました。ディレクターからしたら「そこはこっちにも言い分があって…」「そんなこと言うならプログラマーに対してだって不満はたくさんある」というのもあったかと思います。
それは、今後出会うプログラマーさんと直接話して仲を深めて頂ければと思います。
ですが会社によっては、ディレクターに知識が全くなく後輩ディレクターを育てる社風もないようなところもあります。そうなった場合、いちプログラマー一人が頑張ってディレクターと意思の疎通を取ろうとしても限界があるので、ちゃんと技術に対して知識があるディレクターが多い会社に転職するのも一つの手ですね。
そうした方がストレスは解消されますし、プログラマーにとって周りの非プログラマーが技術者に理解あることはなかなか大切なのではと思います。
世のディレクターとプログラマーが平和にストレスフリーで暮らせますように。
