本記事の概要

非エンジニアの私ですが、これまでエンジニアと働く上で、「コミニュケーションが難しい」「言っていることがさっぱりわからない」みたいなよくある悩みを感じたことがないのですが、なぜなのかが最近言語化できた気がするので記事にしてみました。

結論、エンジニアのやっていることが「なんとなくわかる」というのが大事なんじゃないか、という記事です。

※本記事を読んでいただいたエンジニアの方、「いやいやこれくらい知っておいてくれ」「こんなレベルじゃ話にならない」等あればツッコミお待ちしております！

前提

これまで一緒に働いたエンジニアがいい人たちすぎて「わかりやすいよう歩み寄ってくれている」みたいなありがたい環境ということは大前提
Qiita株式会社でマーケティングやセールスに従事する私自身のエンジニア経験はゼロ
- Progate、ドットインストール等でHTMLやCSSをかじったことがある程度
業務上必要に応じて知識のキャッチアップはしているが、体系的にきちんと学んだことはない
- ググりながらだと問題ないですが技術用語を言われて、瞬発的にそれはプログラミング言語、あれはフレームワークみたいに即答できるレベルではない
- なんとなくは分かるがSQLがゴリゴリに書けるわけではない

1. エンジニアの使っている言葉が「なんとなくわかる」

どの仕事にも共通して言える月並みな内容ですが、コミュニケーションを取るうえで相手の言葉を理解するというのは間違いなく重要です。
まずは「なんとなくわかる」くらいが重要だと思っています。
もちろん、エンジニアと同等の知識、スキルを持っているに越したことはありませんが、そう簡単にキャッチアップできるものでもないと思いますし、より細部の知識はアップデートされ続けるので、片手間では難しいです。
どちらかというとトレンド性のない恒常的に使える知識を身につけておくほうが一緒に働くという観点では役に立つのかなと思います。

なんとなくわかるために

エンジニアリングに関連するものだけではないですが、基本「調べる」「聞く」は徹底します。
以下のように普段会話やテキストで見聞きしたものでわからなければ一旦さくっと調べて、そこがどこにカテゴリーされるものなのかふんわり理解しておくだったり、片隅に情報をいれることで理解はできなくても2回目以降聞いたときに情報にアクセスしやすかったりするかなと思います。

エンジニアが「デコードできない」とか言ってるけど、ああエンコードの逆みたいなことか
dumpってなんだ、ああちょっと違うけどbackup絡みに近い感じのやつか

ここで肝なのはわからないことをわかるまで調べようとしないことです。
エンジニアリングについて非エンジニアが学ぼうとするときわからないことを調べだすと、その周辺のわからない単語が無数に出てくるので完全に理解するのは無理だと僕は諦めています。

2. エンジニアの考え方、思考プロセスが「なんとなくわかる」

エンジニアリングにおける問題解決のプロセスは、一見複雑に見えますが、基本的には「問題を特定し、原因を探求し、解決策を実装する」というステップに分けられます。このプロセスを理解することで、エンジニアがどのようにして問題にアプローチし、解決していくのかが「なんとなくわかる」ようになります。

新機能をリリースした際などにWebサイトで予期せぬバグが発生した際に、エンジニアが最初に行うのは原因の特定、つまり、ログや最近の変更点を確認したり、どういう状況下で発生しているのかを調査します。
非エンジニアの私たちも、このようなアプローチが行われていることを理解していれば、「これ直して」といった無茶ぶりにならず、端末やOSのバージョン、ブラウザなど必要な情報を提供することが可能です。
また、特定の課題を解決するために機能開発する際にも、コンテキストを提供することで、エンジニアがニーズをよりよく理解し、解決するための最適なアプローチを検討することにもつながるのではないかと思います。（そもそも機能で解決するのではなく、オペレーションだけで解決できるかも、みたいな発見もあったりするかと思います）

なんとなくわかるために

エンジニアに何か依頼したときにされた逆質問を噛み砕いて理解する、みたいなことは常にやっています。
過去、Qiitaに寄せられた不具合報告やお問い合わせがあった際に、問い合わせ内容を丸ごと引用する形で「これわかります？」みたいに雑に聞いてましたが、よく「どういう環境で起こってる？」「PCだけ？SPも？」「ブラウザは？」みたいな質問をもらっていました。
ああ、確かに「体調が悪い」みたいなときにそれがそもそも「頭なのか、お腹なのか等、どこで起こっていて」「痛いのか、重いのか等、何が問題で」「飲みすぎてなのか、打撲なのか等、なぜ生じているのか」みたいに順を追ってアプローチしないと適切に解決できないのと一緒のような感じか、じゃあ次からそのあたり確認したうえでエンジニアに渡したほうがいいよなみたいに改善するようなことをしています。

3. エンジニアが作るシステム、処理が「なんとなくわかる」

システム全体や機能などがどのような処理が行われているのかが「なんとなくわかる」と、機能開発などを進める際に実現可能性や工数の感覚が「なんとなくわかる」のではないかと思います。
例えばQiitaの記事フィードのようになにかのデータをAとBとCという複数の条件をかけ合わせたロジックで表示させたい、みたいな機能を作るケースではかなり雑に書きますが、思いつくだけでも以下のような処理があるんじゃないかということが予想できます。

それぞれの条件はどのケースに当てはまるのかを考える
- 投稿時間みたいな記事に紐付くデータなのか
- 投稿者のContributionみたいな記事に紐づいたユーザーごとに紐付くデータなのか
どうやってデータを持ってきて並べるのか
複数の条件をかけ合わせる場合、どの条件を優先するのか

上記は正直正解かどうかはわからないのですが、いくらかの処理が必要で、複雑性があるということを理解できるだけでもさっと開発できる機能ではないなということが「なんとなくわかる」はずです。

もちろん「これ実装できなさそうだな」と勝手に解釈して相談しないのは本末転倒ではありますが、「なんとなくわかる」ことで、顧客との商談中に「これすぐ開発できますよ」みたいな無茶な約束を取り付けてくるようなことにはならないはず。

このようにプロダクトの個々の機能やコードの断片を見るだけではなく、システム全体がどのように機能し、相互にどのように影響し合っているかが「なんとなくわかる」ことで、この機能開発は少しリスクがある、などの嗅覚なども自然と身につくのではないかと思います

なんとなくわかるために

上述のように、なにかを開発するときにどんな順番、どんな処理でやるんだろうなを自分なりに仮説を立ててみる、みたいなことはよくやっていると思います。
それをもとに「こういうこと？」みたいによくエンジニアに聞いたりして答え合わせしてもらっていたりします。
あとは、特に自分が依頼した内容が技術的な観点でどのように進行しているのかを、GitHubのIssueやPull Requestを覗きに行ってプロセスを学んだりしていることが多いので、そうすると自然と「なんとなくわかる」ようになっている気がします。

4.まとめ

なにか言っているようでなにも言ってないみたいな記事になってしまいましたが、記事を書きながら「やっぱりお互いがお互いのことをなんとなくわかる」ことがまずは１番かなと思います。
非エンジニアの自分の視点であれば、営業やマーケティングのテクニックやノウハウを理解してもらうよりは、どういったプロセスで物事が進んでいくのかをエンジニアに知ってもらえれば十分ですし、その逆もそうかなと思います。

抽象化すればエンジニアでも、非エンジニアでもベースとなる考え方や進め方も以下のようなイメージで一緒だなと思いますし、得意なことは得意な人といっしょに取り組むというだけで本質的な差はないのかもとも思ってきました。

課題や実現したいことを特定し、定義する
現状との差分を認識する
その差分を埋めるためのアプローチを検討する
細かな粒度まで行動や実装の手順を細分化する
細分化した行動を実施する

結論、非エンジニアはエンジニアのやっていることが「なんとなくわかる」というのが大事なんじゃないかなと思います！

本記事の概要

前提

目次

1. エンジニアの使っている言葉が「なんとなくわかる」

なんとなくわかるために

2. エンジニアの考え方、思考プロセスが「なんとなくわかる」

なんとなくわかるために

3. エンジニアが作るシステム、処理が「なんとなくわかる」

なんとなくわかるために

4.まとめ