非エンジニアがエンジニアとおしゃべりするときに知っておいて欲しいこと

こんにちは。@inase17000です。アイキャッチと内容は何も関係ありません。

さて、ぼくは新卒から約10年、開発畑で働いてきました。これまでを振り返ってみても、かなり再現性高く起きたことがあります。

コミュニケーション上で、ちょっとしたキャッチボールのコントロール精度の問題です。

1人では成し遂げられない仕事をするときに、他人と協力しながらミッションに向かって進まなければなりません。その時必ずコミュニケーションが必要で、全部が全部スムーズにいくとは限りません。

とくにインターネットサービスなどのビジネスに関わっていると、生産工程の最後はエンジニアに任されることがほとんどです。

よって、これまでもこれからもエンジニアがものづくりしていくことになるわけですが、非エンジニアとエンジニアの間の会話でもっとよくできるポイントがあるので僕の考えをシェアしたいと思います。

想定する対象

非エンジニアの方。
(とくに普段エンジニアと一緒に仕事することがないような方に知ってもらえると嬉しいです)

ある日常の一コマ

会社でこんな場面を目にした(経験した)ことありませんか？
ここで、Aさんは非エンジニア、Bさんはエンジニアです。

A「Bさん、ちょっと相談いいですか？」
B「はい、なんでしょう」
A「ここの画面に、こんな装飾つけて、こんなデータを取り込んで、ここで加工して表示するのって可能ですか？」
B「...」
A（あ、無理なのかな。それとも、わかりづらかったかな...）
B「...」
A「これが難しい場合は、逆にここをこうして、こんなふうにする案も考えてるんですが、そっちはできますか？」
B「...」
A（反応なくて、何考えてるのかわかんないな...）
B「最初の案の場合、こんなリスクがありますけど容認しますか？」
A「つまり、実装は可能ってことだね。リスク面はあとから対策考えるから大丈夫！前者の案でいくね！」
B「ちょっとまってくださ...」
A「ありがとう〜」

こんな風な相談をすることってよくあると思いますし、非エンジニアの方がエンジニアとの距離が近いことはめちゃくちゃ良いチームの証拠です。

上記の会話には改善できる点が3つ潜んでいます。せっかくコミュニケーションを取れるのならば、ちょっとしたコツを知っておいてもらうだけで生産性のあるやり取りができるといいですよね。

どんなポイントかというと、

1.開発の目的から話す
2. 「可能か」の質問は制約条件も一緒に伝える
3.エンジニアの回答により何が起きるのか知らせる
というものです。

それでは、それぞれ詳しく解説していきます。

1.開発の目的から話す

開発をしてプロダクトに機能追加や改変を加えるときには必ず目的が存在します。目的が定まって入れば、それに合った解決策をいくつか洗い出し、その中から最適なものを選ぶというアプローチで進めたくなるのが人情です。

そしてエンジニアは、その解決策を考えたり実現することに楽しさを感じる種族です。

元来、システムというのは、構造化・最適化・効率化が得意なもので、それを実現させるのがエンジニアの仕事。

つまり、どうやって難題を解決してやろうかというとこに腕まくりするプロフェッショナルなので、解決策の話をいきなりしても自分の価値は発揮できず積極的になれない性格の方が多いのです。

エンジニアにインプットする情報は、なぜその改修を考えるに至ったかの背景、目的を厚めに話すことを強くオススメします。

エンジニアに限った話ではありませんが、目線を合わせてからのコラボレーションを意識しましょう。

2.「可能か」の質問は制約条件も一緒に伝える

こういった相談事項があるとき、ほとんどの場合実現可能かでいうと「可能」であると即答したくなります。それはシステムの構成や業務フローの理解があれば答えることができる内容ではあります。

ただし、現実問題なかなかエンジニアが答えづらくなってしまう要因が２つあります。

①時間をいくらでもかけていいならできるけど、期待するスケジュール感に応えられないかもしれない。
②将来の拡張性を考えるともっと良い解決策があるかもしれない。

必ずと言っていいほど、こんなことが脳裏によぎります。

こういった相談を受けるエンジニアはそのシステムのことをよく知っていたり、まわりからの信頼があるから意見を求められるわけで、人一倍責任感を感じて「期待に応えたい」「もっと良いアイデアを考えたい」と前向きに思考を巡らせています。

その思考を手助けするには簡単で、制約条件を追加してあげるだけです。たったそれだけでエンジニアは面白いように回答しやすくなります。

制約条件の例を挙げておくと、
・リリース予定日
・効果検証レベルなのか、本運用レベルなのか
・投じて良いコスト感
・他案件との優先度の違い
などがあります。
必ずしも全てを言える状況にはないことではありますが、一個でもピースを足してあげられるとスムーズに回答が得られるでしょう。

エンジニアの脳内では、考慮すべき事項がどんどん除外されることになるので、本来この会話の本質的な部分である「実現可能か」の部分にフォーカスすることができます。

3.エンジニアの回答により何が起きるのか知らせる

最後のポイントは、開発現場の組織体系や開発プロセスによるところが大きい話なので、当てはまらないことがあるかもしれません。
質問者が経営層やプロダクトオーナーレベルの意思決定者だった場合に起こりがちのポイントです。

簡単に言うと、意思決定者からの質問にはエンジニアは身構えます。度合いはチーム内の心理的安全性の確保レベルによります。

エンジニアの脳内では、
・これを適当に答えたら何か大きな意思決定に繋がってしまうからちゃんと考えて答えたい
・いまやっているタスクよりも優先度が高い新しいタスクの予兆なのではないか
・できると言って実際できなかったらやばい
など、心配事がぐるぐるするわけです。(熟練のエンジニアには余裕があるのでそんなことはないですが、若手のエンジニアに起こりがち)

これを防ぐには普段から意見を言いやすい空気を作るのはもちろんのこと、「あなたの意見は考慮に含めようと思っている」と明確に伝えてあげるか、「まだ雑談レベルなので、本気でやるときは改めてしっかり相談するから、いまは所感だけ聞かせて」と緊張を和らげてあげる工夫が必要です。

会話が終わった後に話す機会を設けて「この間相談したあれだけど、、、●●とする結果になったよ」と結果をフィードバックすることもお互いの関係性構築に重要だと言えます。

焦って結論に急ぎたい気持ちをぐっと抑えて、エンジニアが話しやすい環境を作ってあげる工夫をしてあげてください。

改善された会話の例

それではこれまでお話しした観点を盛り込むとどんな会話になるか考えてみました。

A「Bさん、ちょっと相談いいですか？」
B「はい、なんでしょう」
A「ここの画面から次の画面の遷移率が現状20%程度なのですが、今月中にこの数値を5ポイント改善したいと思ってます。」(今月中という制約、目的の説明)
B「なるほど、どこに課題があると？」
A「このボタンの位置と表示の仕方に問題があると仮定して可能性を探ってるところです。」(まだ検討段階であることを伝える)
B「ボタンの位置か。それなら変更は結構簡単で1日くらいあるとリリースできるかな。あとはA/Bテストの仕組みもあるからそれで実験でもありだよね」(解決策をエンジニアから引き出す)
A「A/Bテスト、ありですね。それだと工数どのくらいかかります？」
B「あ、すでにA/Bテストの基盤は揃ってるから、ほとんど工数変わらずでいけると思います」
A「いいですね。それじゃその線で考えてみます。実際に実装するか決めるときに改めて相談しますね」(何が起きるか伝える)
B「わかりました。お待ちしてます！」
A「ありがとう〜」

生産的な会話になりましたね！

以上の観点を胸にエンジニアと向き合ってあげてください。今までしっくりこなかったあの人との会話が絶対スムーズになります。

僕の役割上、両者の間に立つことが多いため、橋渡しをうまくするためには相互理解が必要だと感じています。つまり、今回はエンジニアのお気持ちの話をしましたが、逆に非エンジニアの気持ちを語る場も作るべきだと思いますので、別の機会にまとめてみます。

それでは今日はこの辺で。