非エンジニアとして、エンジニアとのやり取りで気をつけていること
「エンジニアと非エンジニアのコミュニケーション」の記事がバズっていた。
マイシェフでも、前の仕事でもその前でも、プロダクトマネージャー、カスタマーサクセス、営業的な立場からエンジニアとやり取りが多いので、エンジニアとのコミュニケーションで、気をつけていることを思い返してみます。
エンジニアと話す・チャットするのはいつか
エンジニアと話す時は、大きく2つ。
1つは、新サービスの開発、新機能の追加、既存機能の改良など、何かしら計画して開発するとき。もう1つは、機能が動かない、挙動がおかしいなど、運営するサービスに何かしら問題・バグが発生したとき。（もちろん雑談とかもあるけど、割愛）
まずは、新たに開発する時のコミュニケーションで気をつけていることを。全体として、エンジニアリソースは相対的に希少性が高いので、浪費しないよう、手戻りがないよう、余計な開発をさせぬよう、気をつけています。
「できる？」と聞く時は、どうできるか、わかるように聞く
「これってできる？」と聞いて、「できる」と返事がある時は「技術的に実現可能」「理論上、実現可能」と解釈しています。
返事が「できる」の場合、次に「ざっくり何日くらいでできる？」と聞きます。「1週間くらい」と言われたら、「他の開発項目が何もなく、それだけを1人でやったら1週間くらい」と解釈しています。（無意識にバッファ積むエンジニアもいれば、きつきつ見積りのエンジニアもいるので、その辺りも勘案）
また、返事が「できる」の場合、「どのくらい簡単か？難しいか？」も聞きます。簡単だったり、他の開発項目のついでにできれば、見積りのズレも少ないし、多少優先度が低い開発項目もやってもらえます。難しい場合、開発が伸びるリスクが高い場合もあるし、やらなくても致命的でない開発項目なら、やるのを止める、もしくは先送りと判断します。
ここまで聞いた上で「開発する」か「開発しない」か決めて、エンジニアと話します。「開発しない」とする項目も結構多いです。
データの構造や機能モジュールの関連を聞く
見た目のデザインではなく、データの持ち方や各機能の関連性なども、随時聞きます。非エンジニアの理解でも、データ構造などが何となく理解できると、ここに手を加えるとこっちも影響しそう、ここを修正したらこちらに反映されるはず、と徐々にわかってくるので、エンジニアとのコミュニケーションロスが減る気がしますし、仕様上変な要望、余計なやり方となる機能を考えなくなる気がします。
開発は直列。優先する項目、後回しにする項目を明確に決める
「開発する」と決めたら、いつやるか話します。基本的に、全ての開発項目に優先順位を付けます。ある新規の開発項目を全体の3番目に入れこむと、それはもともと「3番目、4番目、5番目」だった項目を、「4番目、5番目、6番目」に後回しする、と同じ意味。
「全部大切」「全部急ぎで」というのは、非エンジニアの怠慢に過ぎないので、開発項目に優先順位を付け、優先度を落とすもの、後回しにするものを決めます。
なぜそうしようと思うか、なぜその機能が必要と思うか、話す
全ての開発項目ではありませんが、内容によって、その機能を追加しようと思う狙い、背景、理由を話します。
短期的には、ああなるほどとエンジニアに理解してもらえます。また、狙いや背景がわかることで、それならこういう実装方法が良い、こういう内容がいいのでは、というより良い案、エンジニアの意見が出てきます。
中期的には、こちらの考え方のクセが、徐々にエンジニアに伝わっていくので、コミュニケーションのロスも減っていくと思います。
狙いや やりたいイメージを伝えて、意見を聞く
やりたいイメージはあるけれど、自分で実装イメージや開発難度がイメージできない時は、狙いややりたいイメージを伝えて、エンジニアに聞きます。大抵、実現可能な良い案を考えて言ってくれます。
「できた」は、まだ「できてはいない」
開発がすむと、エンジニアから「できたよ」と言われます。でも、エンジニアの「できた」と、非エンジニアの「できた」は違うので、どこまでできているか確認します。
コーディングとユニットテストが終わった段階か、リリースまで終わった段階か。エンジニア的には、機能のリリース＝自分の手から離れた、なので、そこからは非エンジニアである自分の出番で、必ず本番環境で触ってみてテストします。
たまに、無茶を言うようにする
エンジニアの「できる」は、「技術的に実現可能」「理論上、実現可能」なのですが、そのエンジニアの経験や持つ知識の範囲内であり、そのエンジニアが置いている制約の範囲内で、という暗黙の制約があります。
通常はその制約の範囲内で問題ないのですが、たまに、どうしても譲れない要望、必要と考える機能がある場合は、無茶を承知で、必要性をエンジニアに伝えます。
人は誰でも、自分の範囲内でものごとを捉えますので、その範囲の外で考えるために、たまに無茶を言います。非エンジニアとしての素人考えから、ああできないか、こうできないかと案も伝えます（大抵ダメな案ですが、ごく稀にブレイクスルーのきっかけになります）。
次に、何かしら問題が発生したとき、バグっぽいと思える事象に遭遇したときに気をつけていること。基本的には、エンジニアが適切に迅速に調査・対応できるように心がけてます。
事象と、仕様に基づく本来の挙動と、自分が想像する原因や感想を、分けて伝える
動くはずのものがきちんと動かないとき、要はバグやトラブルっぽい時、いくつかの情報をまとめて、ただし情報の位置づけが曖昧にならないように伝えています。
・事象（例：男性ユーザーでログインできない。Mac Book AirでChromeの最新バージョン。他の端末・ブラウザは見ていない）
・本来の挙動（例：男性ユーザーでログインできるはず）
・想像する原因（例：以前は男性ユーザーもログインできた。前回のリリースでログインの権限に手を加えたけど、それの影響？？？）
ただし、画面が開かないなどクリティカルな場合は、細かな確認などは後回しに、取りあえずすぐ伝えます。
事象をエンジニアの手元で確認・再現できるように伝える
不具合の事象確認・再現のために時間がかかると、対応の遅れに繋がるので、不具合画面のスクリーンショットを送り、その不具合が発生した際の操作手順（バグの再現方法）を伝えます。
できる範囲で、問題の切り分けをし、原因の範囲を狭める
先の例の場合だと、問題を伝えた後に、別ブラウザで同じ操作、別端末で同じ操作、女性ユーザーでログインなど試して、非エンジニアの立場からできる範囲で問題の切り分けをし、エンジニアに追加で伝えます。
その他、気にしていることは、バズっている記事にある通り、普段はチャットで非同期コミュニケーション。追加したい機能の説明は、まずは文面や図にして渡し、その後チャットや実際に話します。
私自身、自分の時間を遮られるのが苦手（特に営業電話は大嫌い。頼んでもないし、用事もないのに、こちらの時間と意識を止められるのが堪え難い）なこともあり、エンジニアとのやり取りは、できる限り非同期コミュニケーション。
以上が、非エンジニアとして、エンジニアとのコミュニケーションで気をつけていることです。エンジニアが日本人の場合はもちろん、アメリカ人でもメキシコ人でも、イタリア人や東欧の人でも、中国人でも、同じことを気にしてきました。相手の国籍が変わっても、こちらはあまり変わらない。
インターネットの界隈では、自分で作れない非エンジニア的には、エンジニアとの良好なコミュニケーションは極めて大事な事柄。気持ちよく、スピーディーに仕事を進めるために、こういうことも気をつけると良いよ、というアドバイスあれば、ぜひぜひ教えてください。
【補足：マイシェフご利用くださいね】
そんなマイシェフは、1年前も今も、顧客の6〜7割を育児ママや夫婦が占め、子供の誕生日などのハレの日や、ママ友や友達家族の集まり・イベントごとでのご利用が多いです。
育児中の女性は、きっと役に立つサービスと思い、一度使ってみてくださいね。
■ マイシェフHP：http://mychef.jp/
■ マイシェフを利用したお客様の感想：http://mychefjp.blogspot.jp/2016/02/blog-post_7.html
■ NHK「あさイチ」にて、出張シェフサービスのマイシェフ取り上げていただきました：http://mychefjp.blogspot.jp/2014/02/nhkmychef.html
育児中の男性は、奥さんにプレゼントしてくださいね。ギフト券もありますから。
■ 結婚記念日・誕生日にマイシェフギフト券：http://mychef.jp/gift.html
■ WBSにて、新しいギフトとしてマイシェフ取り上げていただきました：http://mychefinfo.blogspot.jp/2014/12/mychef.html
法人での利用も増えています。キャンペーンの景品・賞品や、福利厚生目的での利用など。絶賛ご利用ください。
■ マイシェフギフト券 法人プログラム ：http://mychef.jp/business-gifts/case.html
個人向けの出張シェフサービス “マイシェフ” を始めた理由 - 出張シェフサービスのマイシェフ社長ブログ
組織運営、チームマネジメントなどの参考 - 出張シェフサービスのマイシェフ社長ブログ
米国スタートアップの日本参入・日本立上げ時に留意したこと - 出張シェフサービスのマイシェフ社長ブログ
