技術がわからないデザイナーやディレクター、プロダクトオーナーとのコミュニケーション
コミュニケーションのAdvent Calendar 16日目です。
みろなるさんがコミュニケーションのAdventCalendarやるから書いてって言われたので、つらつらと書いてみます。
今年春にSI屋さんをやめて、デザイン事務所のような会社で唯一の常駐エンジニアとして、アプリの技術なんかほとんど知らないWebデザイナーさんやディレクターさんとのコミュニケーションについて思ったことを書きます。
経緯
今年の春に2年務めたSIerをやめました(参考:退職しました)。
SIer時代には、基本的にどこの現場に行っても周りはSEかPG。
お客さんもSEかPG。
エンドユーザーがSEなんて仕事も。
多々ストレスは有りましたが、話す方も聞く方もエンジニア。ある程度の共通の認識や知識を持ってコミュニケーションを取れることが多かったです。
そんな会社をやめて、今いる会社はWebデザイナーやディレクターがメインのメンバーの、IT企業というよりはデザイン事務所のような職場で働いています。
アプリエンジニアどころか、エンジニアと呼ばれる人間で常駐してるのは僕だけです。
退職を期に個人でも小さなアプリ開発案件を請け負い始めたので、デザイナーさんと話す機会は増す一方です。
なので、ディレクターさんとコミュニケーションを取らなければならない状況に置かれた僕の、ここ数ヶ月の気づきを書いていきます。
まず徹底的にわがままを聞く
SI屋さんにいると、まず要件定義を作って、設計して、作ってテストして・・・・。なんてことをしますよね。
でもせっかくプロダクトオーナーもデザイナーもディレクターも同じ部屋にいるんだから、そんな手間は掛けたくないですよね。
だからと言って、ろくに要件も決めないままいきなり作り始めるとろくなことにはなりませんよね。
さらに言えば、「じゃあ要件定義をしていきましょう。」なんていきなり始めてしまうと、プロジェクトを進めるのに慣れてない人は、
割りと萎縮してしまう場合なんかもあります。
そこで魔法のコトバ 「まずわがままを書きまくってください」です。
このわがままは、「こんな感じの機能がほしい」「この画面はかっこいい感じにしたい」といった抽象的なものから、
「この画面のここのフォントは◯◯にしたい」「このボタンはこのデザインがいい」等の具体的なものまで、とにかくなんでも列挙してもらいます。
これが出来上がれば、かなりスムーズに要件定義やタスクの分解ができます。
例えば「この画面はかっこいい感じにしたい」というわがままの場合、わがままの定義付けと実現方法を考えます。
- どのような画面デザインで、どのような機能がどのように動けばかっこいいかを決める。
- かっこいい画面をデザインする。
- かっこいい機能を作る。
- かっこいい動きを作る。
という過程を踏めば実現できることがわかります。
つまり「かっこいい画面」という抽象的な表現の定義付けと、この機能の要件の決定、タスクの分解ができるわけです。
具体的なわがままについては、定義付けやタスクの分解どころか、そのままissueにすらなってしまう場合があります。
大きなチームではわかりませんが、プロダクトオーナーのわがままをリスト化することで、要件定義に近いもの、もしくは要件定義を作るための足がかりになります。
わがままに優先順位をつける
次にわがままに優先順位をつけます。
これは言わずもがな、要件定義ができたらスケジュールを決めたいですよね。
わがままをタスク化した時点で、ある程度ですが工数の見積もりも見えてきているはずです。
つまり、後はわがままに優先順位をつければ、ざっくり開発スケジュールが出来上がるわけです。
無駄なドキュメントは作らないけど、必要なドキュメントはちゃんと作ろう
デザイナーさんとおしゃべりするのは楽しいです。ついつい長話してしまうことも多々有ります。
そんな長話のさなかに、隠れわがままが出現することがあります。
隠れわがままは、我々の天敵である「仕様変更」「機能追加」である場合があります。
仕様変更や機能追加をしたくないわけではないです。いいものを作るために必要なことならば積極的にやりたいです。
問題なのは仕様変更や機能追加がふわっと現れることにあります。
ふわっと現れたタスクをふわっとさせておくと、なんの機能なのか、いつやるのかが曖昧になったまま、結局忘れさられるといった悲劇がおこることがあります。
これは、デザイナーさんとのおしゃべりに限らず、仲の良い開発チームやタスク管理が苦手な人達のチームで起こりやすいことでもありますね。
これを避けるために、めんどくさいですが機能について正解を示すドキュメントは、機能毎やわがまま毎に作っておきましょう。
会話のさなか隠れわがままが出てきたら、このドキュメントと照らし合わせながら仕様変更や機能追加をしましょう。
このわがままの再設定的な作業をしておけば、隠れタスクは生まれないはずです。
急がせないでやりたいようにやらせる
たまにあるんですけど、「この画面のデザイン、とりあえず手書きでざっっっっっくりでいいので下さい」って頼んだのに、
きっちりしたデザインが上がってくることがあります。なんか手書きでざっくりみたいなのが苦手らしくて、
ちゃんとした完成形のデザインじゃないとイメージができないらしいです。
最初は、「まじかー。とりあえずざっくりデザイン見ながら、機能だけ作っちゃって後でデザイン反映するかー。」なんて思ってましたが、
無理なものは無理らしいので、諦めましょう。というか諦めました。テストでも書きながら待ちましょう。
無理に急かしてもモチベ下がって、逆に遅くなることもあるし、急がば回れです。
デザイナーさんに限らずこういう人っているよね、って話なんですけども。
ただ、スケジュールに遅れが生じる可能性があることなどはちゃんと説明しましょう。
専門用語を避けない
非エンジニアと話すとき、こちらから専門用語を避けがちになってしまっていませんか？
専門用語を避けて、話すことで正しく意図が伝わらない事があったりしませんか？
そういった自体をさけるために、僕はあえて専門用語は専門用語のまま使っています。
ただ、そういった専門用語を使う前に必ず「今から技術の話をします。」というようにしています。
急に知らない単語がいっぱい出てくるとびっくりしますので。
なので、専門用語を使って正しく意図を伝えるために
「今から技術の話をします。この機能を実現するには、データベースに○○のためのテーブルが必要です。ここでいうテーブルとは〜〜」
といったように、はっきりと専門用語である事と、その意味を伝えましょう。
これにより、正しい意思の疎通と、その後のコミュニケーションコストの軽減が見込めます。
また、これについては逆も然りで、エンジニアも相手が使う専門用語を理解しようとすることが大事ですね。
甘いものやごはんを与える
定期的にシュークリームやらワッフルやらを買い与えましょう。
糖分は頭を活性化させるような気がします。
あとうちのデザイナーは茶碗蒸し与えると頑張ります。
出汁と卵と具を混ぜて、器に入れて、アルミホイルかぶせて、器が半分浸かるくらい鍋に水を入れて沸騰させて、鍋に器を入れて鍋に蓋をして10分くらい蒸せば出来上がりです。簡単ですね。
🍣や🍕や🍖なども有効です。
おわりに
技術がわからないデザイナーやディレクターとのコミュニケーションと題しましたが、非エンジニアとプロジェクトを進めるにあたっての気づきみたいな事を書いた気がします。
長々と書きましたが、大事なのは相互の歩み寄りと仲良くすることが、チーム内で最もコミュニケーションコストを下げるのに大事なことだと思います。
こういう考え方もあるんだー。程度の参考にしていただければ幸いです。
