出張シェフサービスのマイシェフ社長ブログ

個人向け出張シェフ・出張料理サービス "マイシェフ" の社長のブログです

非エンジニアとして、エンジニアとのやり取りで気をつけていること

「エンジニアと非エンジニアのコミュニケーション」の記事がバズっていた。

マイシェフでも、前の仕事でもその前でも、プロダクトマネージャー、カスタマーサクセス、営業的な立場からエンジニアとやり取りが多いので、エンジニアとのコミュニケーションで、気をつけていることを思い返してみます。

hrnabi.com

 

エンジニアと話す・チャットするのはいつか

エンジニアと話す時は、大きく2つ。

1つは、新サービスの開発、新機能の追加、既存機能の改良など、何かしら計画して開発するとき。もう1つは、機能が動かない、挙動がおかしいなど、運営するサービスに何かしら問題・バグが発生したとき。(もちろん雑談とかもあるけど、割愛)

 

まずは、新たに開発する時のコミュニケーションで気をつけていることを。全体として、エンジニアリソースは相対的に希少性が高いので、浪費しないよう、手戻りがないよう、余計な開発をさせぬよう、気をつけています。

 

「できる?」と聞く時は、どうできるか、わかるように聞く

「これってできる?」と聞いて、「できる」と返事がある時は「技術的に実現可能」「理論上、実現可能」と解釈しています。

返事が「できる」の場合、次に「ざっくり何日くらいでできる?」と聞きます。「1週間くらい」と言われたら、「他の開発項目が何もなく、それだけを1人でやったら1週間くらい」と解釈しています。(無意識にバッファ積むエンジニアもいれば、きつきつ見積りのエンジニアもいるので、その辺りも勘案)

また、返事が「できる」の場合、「どのくらい簡単か?難しいか?」も聞きます。簡単だったり、他の開発項目のついでにできれば、見積りのズレも少ないし、多少優先度が低い開発項目もやってもらえます。難しい場合、開発が伸びるリスクが高い場合もあるし、やらなくても致命的でない開発項目なら、やるのを止める、もしくは先送りと判断します。

ここまで聞いた上で「開発する」か「開発しない」か決めて、エンジニアと話します。「開発しない」とする項目も結構多いです。

 

データの構造や機能モジュールの関連を聞く

見た目のデザインではなく、データの持ち方や各機能の関連性なども、随時聞きます。非エンジニアの理解でも、データ構造などが何となく理解できると、ここに手を加えるとこっちも影響しそう、ここを修正したらこちらに反映されるはず、と徐々にわかってくるので、エンジニアとのコミュニケーションロスが減る気がしますし、仕様上変な要望、余計なやり方となる機能を考えなくなる気がします。

 

開発は直列。優先する項目、後回しにする項目を明確に決める

「開発する」と決めたら、いつやるか話します。基本的に、全ての開発項目に優先順位を付けます。ある新規の開発項目を全体の3番目に入れこむと、それはもともと「3番目、4番目、5番目」だった項目を、「4番目、5番目、6番目」に後回しする、と同じ意味。

「全部大切」「全部急ぎで」というのは、非エンジニアの怠慢に過ぎないので、開発項目に優先順位を付け、優先度を落とすもの、後回しにするものを決めます。

f:id:smasa0810:20160430165942p:plain

 

なぜそうしようと思うか、なぜその機能が必要と思うか、話す

全ての開発項目ではありませんが、内容によって、その機能を追加しようと思う狙い、背景、理由を話します。

短期的には、ああなるほどとエンジニアに理解してもらえます。また、狙いや背景がわかることで、それならこういう実装方法が良い、こういう内容がいいのでは、というより良い案、エンジニアの意見が出てきます。

中期的には、こちらの考え方のクセが、徐々にエンジニアに伝わっていくので、コミュニケーションのロスも減っていくと思います。

 

狙いや やりたいイメージを伝えて、意見を聞く

やりたいイメージはあるけれど、自分で実装イメージや開発難度がイメージできない時は、狙いややりたいイメージを伝えて、エンジニアに聞きます。大抵、実現可能な良い案を考えて言ってくれます。

 

「できた」は、まだ「できてはいない」

開発がすむと、エンジニアから「できたよ」と言われます。でも、エンジニアの「できた」と、非エンジニアの「できた」は違うので、どこまでできているか確認します。

コーディングとユニットテストが終わった段階か、リリースまで終わった段階か。エンジニア的には、機能のリリース=自分の手から離れた、なので、そこからは非エンジニアである自分の出番で、必ず本番環境で触ってみてテストします。

 

たまに、無茶を言うようにする

エンジニアの「できる」は、「技術的に実現可能」「理論上、実現可能」なのですが、そのエンジニアの経験や持つ知識の範囲内であり、そのエンジニアが置いている制約の範囲内で、という暗黙の制約があります。

通常はその制約の範囲内で問題ないのですが、たまに、どうしても譲れない要望、必要と考える機能がある場合は、無茶を承知で、必要性をエンジニアに伝えます。

人は誰でも、自分の範囲内でものごとを捉えますので、その範囲の外で考えるために、たまに無茶を言います。非エンジニアとしての素人考えから、ああできないか、こうできないかと案も伝えます(大抵ダメな案ですが、ごく稀にブレイクスルーのきっかけになります)。

 

次に、何かしら問題が発生したとき、バグっぽいと思える事象に遭遇したときに気をつけていること。基本的には、エンジニアが適切に迅速に調査・対応できるように心がけてます。

事象と、仕様に基づく本来の挙動と、自分が想像する原因や感想を、分けて伝える

動くはずのものがきちんと動かないとき、要はバグやトラブルっぽい時、いくつかの情報をまとめて、ただし情報の位置づけが曖昧にならないように伝えています。

事象(例:男性ユーザーでログインできない。Mac Book AirChromeの最新バージョン。他の端末・ブラウザは見ていない)
・本来の挙動(例:男性ユーザーでログインできるはず)
・想像する原因(例:以前は男性ユーザーもログインできた。前回のリリースでログインの権限に手を加えたけど、それの影響???)

ただし、画面が開かないなどクリティカルな場合は、細かな確認などは後回しに、取りあえずすぐ伝えます。

 

事象をエンジニアの手元で確認・再現できるように伝える

不具合の事象確認・再現のために時間がかかると、対応の遅れに繋がるので、不具合画面のスクリーンショットを送り、その不具合が発生した際の操作手順(バグの再現方法)を伝えます。

 

できる範囲で、問題の切り分けをし、原因の範囲を狭める

先の例の場合だと、問題を伝えた後に、別ブラウザで同じ操作、別端末で同じ操作、女性ユーザーでログインなど試して、非エンジニアの立場からできる範囲で問題の切り分けをし、エンジニアに追加で伝えます。

 

 

その他、気にしていることは、バズっている記事にある通り、普段はチャットで非同期コミュニケーション。追加したい機能の説明は、まずは文面や図にして渡し、その後チャットや実際に話します。

私自身、自分の時間を遮られるのが苦手(特に営業電話は大嫌い。頼んでもないし、用事もないのに、こちらの時間と意識を止められるのが堪え難い)なこともあり、エンジニアとのやり取りは、できる限り非同期コミュニケーション。

 

以上が、非エンジニアとして、エンジニアとのコミュニケーションで気をつけていることです。エンジニアが日本人の場合はもちろん、アメリカ人でもメキシコ人でも、イタリア人や東欧の人でも、中国人でも、同じことを気にしてきました。相手の国籍が変わっても、こちらはあまり変わらない。

 

インターネットの界隈では、自分で作れない非エンジニア的には、エンジニアとの良好なコミュニケーションは極めて大事な事柄。気持ちよく、スピーディーに仕事を進めるために、こういうことも気をつけると良いよ、というアドバイスあれば、ぜひぜひ教えてください。

 

【補足:マイシェフご利用くださいね】

そんなマイシェフは、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

txbiz.tv-tokyo.co.jp

 
法人での利用も増えています。キャンペーンの景品・賞品や、福利厚生目的での利用など。絶賛ご利用ください。
■ マイシェフギフト券 法人プログラム :http://mychef.jp/business-gifts/case.html

 

個人向けの出張シェフサービス “マイシェフ” を始めた理由 - 出張シェフサービスのマイシェフ社長ブログ

組織運営、チームマネジメントなどの参考 - 出張シェフサービスのマイシェフ社長ブログ

米国スタートアップの日本参入・日本立上げ時に留意したこと - 出張シェフサービスのマイシェフ社長ブログ