エンジニアからディレクターになって考えた、最良のコミュニケーション

こんにちは、あけましておめでとうございますまみたすです。
1月全く記事書いてなかった…つまり2018年になってから書いていませんでしたが、何をしていたかというとベトナムに渡って新しいお仕事を始めました。
受託開発会社のwebディレクターというか、プロジェクトマネージャーというか、そんな感じです。

完全に開発から離れてディレクション側にまわるのは初めてで、色々試行錯誤してます。
とりあえず1ヶ月たったので、エンジニアからディレクターになって得た気づきを書いていきたいと思います。
(本当はベトナム人とのコミュニケーションという切り口にしようと思ったのですが、あげてみたら日本でも共通してたのでその切り口はやめました)

エンジニアとディレクターがお互いに意識すると良いこと

この記事では、うっかりするとお互いにイガイガしかねないエンジニアとディレクターがお互いに歩み寄り、最良のパフォーマンスを発揮できるようなコミュニケーションについて書いていきたいと思います。

現時点で、こうするといいんじゃないか?と思っている程度のものですので、もっといいTIPSがあればぜひコメントを。
    
目次  

  • 起こりがちな問題
  • ディレクターが気をつけること
  • エンジニアが気をつけること
  •       

    起こりがちな問題

    私がやっている仕事内容としては、クライアントからの要望を聞き要件定義、エンジニアに伝え、案件の進捗確認とテストをやってる感じです。
    (最近はちゃんとできてるか不安でコードレビューもするようになりました。)

    これをPMと呼ぶかどうかはわからないですが肩書きがwebディレクターなのでディレクターと言ったり言わなかったりします。

    このお仕事をしていると、主に以下のような問題が発生します

    • 要件定義のもれが多く、追加修正を重ねて期限をぶっちぎる
    • バグやエラー案件に対応しているうちに、本当に終わらせたかった案件の期限をぶっちぎる
    • 期限を守ろうとするあまり、質の低いものをリリースしてしまう(あとでバグる)
    • エンジニアが何をどう実装したかわからない(テストしづらい)

      

    ディレクターが気をつけること

    ディレクターとして今気をつけていることは以下です。 

    目的を意識する

    まずは目的を聞き、それからやりたいことを聞き出すことが重要となります。

    クライアントのやりたいことが先行してしまうと「アレやりたいんですよね。できる?」というコミュニケーションになる時がありますが、目的を聞くことでエンジニアからもっと良い方法を提示できるかもしれません。

    エンジニアからすると、「クライアント様がアレやりたいんだって。やってよ」と言われてしまうと、開発モチベ0になってしまいます。(結構「いや、そもそもそれ必要?運用で十分カバーできるよ」という結論になってしまうこともありますがそれはそれで)

    「こういう目的で、こういうのが欲しいと言われているんだけど、どう?」と一緒に話してくれるディレクターは良いディレクターだと思います。

       

    期限には余裕を持って

    当たり前と言えば当たり前なのですが・・・。
    開発って「これ、軽そうだな」と思って調べてみるとめちゃくちゃ重いことがあります。

    「開発」の中には「調査」「設計」「実装」「テスト」(「修正」)「リリース」という手順が入っているので、エンジニアにはそれぞれどのくらいかかるかを聞いてください。

    というかそもそも工数を出す調査に割と時間がかかることもあるので、それを加味してクライアントと話さないと痛い目を見ます。
    データ操作系の案件だと「ちょっといじるだけで終わるっしょ」と思う人も多いかと思いますが、割と気を使うことが多かったりして私は結構時間をかけていました。

    絶対に何でも「すぐできま〜す」なんて言ってはいけない…。
    でも頼んでくる側はだいたい、重いか軽いかとりあえず聞きたいということも多いので、この辺の答え方は本当に迷う。
    (エンジニアだったときは「こういう処理をする感じでできそうだったら、このくらいの時間で終わりますが、ちょっと調べてみますね」と答えてました)

       

    要件定義時にはあらゆる状況・条件を想定する

    「〇〇欲しい」と言われた時に、例えばwebサイト開発案件ならどのページで必要なのか、除外する条件があるのかなどきっちり確認しないと手戻りが発生することが多いです。
    社内SEとかお付き合いの長いクライアントさんだと特に、暗黙の了解的な感じになっているところもあるかと思いますがその辺もきっちり確認して定義書に書いておきたいものです。

    ただどんなに想定して決めても変更になるときはなるし、漏れるときは漏れる。
    クライアントがやっぱこれ変更で!って言ってきたら意味ないし…。
    それはもう諦めるしかない…これみんなどうしてるんだろう。

       

    後から手をつけても大丈夫なものは、一旦置いておく

    クライアントから要望が来た時に、ついすぐにエンジニアに投げてしまっていたのですが、「あとでいいから」と言ってあってもエンジニアが急ぎの案件だと思って優先してしまったり、それに気を取られて現状やっているものが雑になってしまったりすることがあったので、後からで大丈夫なものはエンジニアのタスクが落ち着くまで置いておくようにしています。

    ここはタスクマネジメントの意識がディレクターとエンジニアで統一されていれば、そんなに気を使うところでもなさそうかなと思いますが。   
     

    エンジニアが気をつけること

      
    ディレクターとしてはこれやってくれると嬉しいなあ、みたいなことですが。  

    要件は一度全部一緒に見直す

    できれば、要件をもらった時に一度全部見直すと良いです。

    要件をエンジニアと一緒に確認しているうちに抜け漏れに気づくことが多くあります。

    手戻りを防ぐためにも、さらっと着手してしまうよりは面倒でも一度一緒に確認!

       

    実装した内容は具体的に説明する

    何かを実装完了した時、「完了しましたー確認お願いしまーす」で終わらせてしまうことも多いのですが、

    • 何をどう変更したか
    • どんな挙動が正しいのか
    • 条件によって挙動が変わることはあるか

    を言ってくれる人は本当に偉い!!!と思います。

    ディレクター側もこれを言われることにより、「あ、ここに気をつければいいのね」と注意して見るようになるので、動作確認がしやすいです。   

    できないときはできない理由を説明する

    当たり前のような気もするのですが…実装するのが難しい時に「技術的に難しいっすね」で終わっちゃう人も結構います。

    細かい技術まで説明しなくていいとは思うのですが、大まかな理由を噛み砕いて説明してくれると納得できるし、できないことをできないとしっかり言ってくれる人に対しては信頼も増します。

    もちろん代替案も出してくれるとだいぶ嬉しいのですが、もう理由をわかりやすく説明してくれるだけで「色々考えてくれてありがとう!」という気分になります。

       

    無茶振りされたら、恩着せがましくしよう

    ディレクターの立場からすると、これはさすがに無茶振りだな〜と思うタスクを、無理を承知でエンジニアに振った時に「わかりました!やります!」と言ってくれる人ってすごくありがたいです。

    エンジニアの立場からすると、「うわ!無茶振り!」と思っても、でも向こうも困ってるんだし、と快く(見えるように)引き受けているのですが、、これは後々めちゃくちゃ困ることになります。

    特に技術がわからない人にとっては、エンジニアがそうやって快く引き受けてくれると「あ、実は無茶振りでもなんでもなかったのかな」「実は軽いものだったのかな」と思ってしまうきっかけになり、どんどんお願いのハードルが低くなっていくことがあります。

    これは私がディレクターになってから思ったのですが、一度快くやってもらうと、次の無茶振りも快くやってくれることを密かに期待してしまい、いざエンジニアから断られるとなぜかがっかりしてしまうのです。悪いのは無茶振りしているこっちなのに。

    なので、エンジニアは断っても良さそうな無茶振りは断っていいですし、もし無茶振りに答えるときはちょっと恩着せがましくやってあげるのが良いと思います。

    「ああ〜、これすごく難しいですね…できるかなあ…でも今困っていらっしゃるんですよねー、うーん。ちょっと頑張ってみますね。今回だけですよ!」て感じでやってくれると、「やってもらっている」感がディレクター側に出て、エンジニアへのリスペクトが増します。

     

    ここで「ハァ?もったいぶってないでいいからやれや」というディレクターは悪いディレクターなので全部断って良しです。   
     

    全部書いてみて見直すと、今書いたこと全部当たり前のことのような気がしているのですが、とりあえず1ヶ月試行錯誤して特別気にしていることを書いてみました。
    また時間が経ったら見直してアップデートしたいと思います!

    The following two tabs change content below.
    まみたす

    まみたす

    1992年生まれ。知識ゼロ文系女子からSEになっているところ。 カメラ、猫、お酒、旅行がすきです。
    この記事の内容が役に立ったと思ったら、SNSで記事を共有してもらえると幸いです。

    コメントを残す

    メールアドレスが公開されることはありません。

    日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)