非エンジニアが持つべき発注者視点

kbdy555

4

重要なのは意見のすり合わせ、互いに歩み寄ること、思い込みで進めずコミュニケーションを密に取り合うことだと感じた。
互いの専門分野について基礎的な知識を有しておくことは、コミュニケーションを円滑にするために有効であると思うが、そこに時間をかけすぎるのは効率的ではないとも感じた。
自分の専門分野を、素人に分かりやすく説明するのはプロとして当たり前に有しているべきスキルであるため。受注者側も、要件定義等をスムーズに引き出すためのスキルを有しておくべきと考える。
社内外問わず、相手の立場に立った言動が大事であると改めて感じた。

g_im

4

プログラミング、エンジニアの話でしたが、ウェブデザインや紙媒体の発注や内製にも参考になる話でした。

shaftesbury

4

ちょうど某都銀のシステムがダウンしたニュースを見たところだったので、システム開発後の保守運用の際に適切な人材が社内にいないというのはどれだけ深刻かが分かった。また、エンジニアの視点を知らないで依頼すると議論が噛み合わなくなるリスクが大きいので、最低限の基礎知識を知ることが大事だと思った。丸投げ、ダメ、絶対

tsu_watanabe

3

エンジニアに寄り添うことの大切さはよくわかりますが、発注者にとっては社内への対応のほうが難しいように思います。発注者以外にもこれを見てほしいと思いました。

yukiko_w

2

エンジニアも発注者側も経験しました。
どちらの言い分も非常に良くわかりますね。
エンジニアには説明責任があると思いますし、発注者側は開発はできなくても社長の伝書鳩にはならない程度のPMO能力は持っているべきですね。
自社内でスキルを満たす発注者がいないのであれば、そこも業務委託などで外注することも考えてもいいと思います。
あと、画面見せるとどうでもいい指摘が山ほど来て、本質的な要件がおざなりにされるのは開発あるある過ぎる。（苦笑）

daisuke_i_2020

2

どの仕事でも同じことが言えるような内容であった。お互いに相手の領域の専門家になる必要はないが、ある程度どのくらいの大変さであるかを分かるくらいには予備知識を持っているようにすべきとおもう。

kameco

2

以前システムを新しくするときに、VTRの事例と全く同じことが起きました。
話が嚙み合わないというか、エンジニアさんのイメージとこちら（発注者）のイメージが共有できていないな、と思いながら打ち合わせに参加していました。
その時にこの講座を受けていたら…よかったです。

kobo0804

2

・自分は元？ネットワークエンジニアだけど、今はサービス企画担当に所属しており、サービス企画部門とネットワーク部門（開発担当や設備構築・保守担当）との橋渡しを行っている。具体的には、開発要望書いたり、フィールドテストしたり、バグあったらログとって一次解析し（そのあと開発部門に対して二次を依頼し）たり、リリースのための切替手順書書いたり、リリースに備え保守体制を準備したりなどなど。
・サービスや技術がそれぞれ専門的な領域となっている現在、私のような中道的な（よく言えば両方の意見が分かる）人間が必要になって生きているのだろうと思っている。
・自分も（心はまだ）エンジニアだからあえて言うけど、エンジニアの方からも歩み寄ってほしいと思うことは多々あるけどね。

oyok

2

内容としては最終的には両者が歩み寄ることが重要で、歩み寄ることによって最適なプロダクトが作られるということ。一方で、非エンジニアが食いついてしまうデザインということに関しては、いったいどのようなタイミングで、どのように伝えれば良いか？ということについて触れられていないのが残念でした

bibizu1217

1

どのような仕事であれ、相手の立場に立って一度振り返り、接する事が、お互い仕事がスムーズに進むと思う。

m_yae

1

プログラミング等のエンジニアへの依頼に限らず、デザイン関連の依頼も同じですよね。自分で行えない事を依頼するので、相手の立場が理解できる程度の知識が必要という事、単語や用語の共通認識を持てることが大事なのだとりかいしました。

hiro_yoshioka

1

んー　なんとも言えない。
こういうのは　一度体験してみないと、わからないですね。
百聞は一見にしかず

エンジニアの気持ちを理解するために、一度体験してみます。

taka0001

1

エンジニア市場だから、エンジニア側に立って合わせないと大変なんだよって事なんだろうな。一方で、エンジニア側にもお金をもらう側、受注側の姿勢を学ぶグロービスがあってもいいとも思った。

saito-yoshitaka

1

プログラミングを学ぶ観点は持ち合わせていませんでした。理解する歩み寄る事大事ですね。

kotoshis34

1

デジタル案件開発でベンダー様との間でよく起こるトラブルの一因が理解できたので気を付けたいと思います。一方で理解のギャップは必ず起こると想定して最善の解決策をエンジニアの方やベンダー会社と導けるように健全で緊張感のある関係を維持するようにしたい。

end-o

1

発注者と受注者のお互いが思う事の相違は良くあることです。しっかりと内容をお互いが話し合っていく必要を感じました。

kaz_2021

1

「認識は必ずズレる。」「コミュニケーションは『歩み寄り』が必須。」はどの領域でもいえる話にも関わらず、このような講座があるのは、ITエンジニアが「歩み寄り」が出来ない（しなくても仕事が取れる）のが背景と推測される。
顧客との認識のギャップを埋められるノウハウ・リエゾンもつIT会社が登場すれば、市場を取れると思う。

llasu_ito_0502

1

最後の方のQ&Aは、とても参考になりました。生の声で、切実な内容、対処方法の具体的な例について教えて頂きありがとうございます。
知見が深まりました。実践したい、と思います。ありがとうございます。

shoot-

1

実際に私もWEBサイトの構築をお願いしてるため、良くない発注方法を行っていた自覚がある。エンジニアに求めるだけでなく、こちらも理解して発注を行う必要がある事が理解できた。

ymmtr

1

私はエンジニア側の人間ですが、エンジニアリングについての知識のない発注者の方とのやりとりでトラブルになった経験もあり、今後そういったトラブルを未然に防ぎたく本講座を視聴させていただきました。エンジニア側から見ても「事前にこういった認識を合わせておくべき」という要の要素が簡潔に整理されており、開発の各段階でより適切なコミュニケーションをとっていけそうです。ありがとうございます。

132shiori-kato

0

今回はエンジニア対非エンジニアのコミュニケーションだが、通常業務にも当てはめることができると思った。
相手の状況や気持ちを考える、ただお金を払っているからお願いします、というだけではなくこの状態で大丈夫だよねと相互確認することが大事だと思った。

koichiro_130

0

非エンジニアは、エンジニアではないが、プログラミング言語について知る事や、一部を体験することによって、エンジニアの大変さや苦労を理解できる。また、会話においてもそれらは有効に作用する。実際エンジニアにどこまで理解できていれば、会話が成り立つか、仕事が円滑に行くかを聞いておくのも良い。

abe-misato

0

自分はどちらかと言うとエンジニア側の人間なので、発注者が気を遣ってくれていることを意識して仕事をしようと思った

kihiro-sato

0

発注者とエンジニアの認識は必ずズレるということを自覚することで出戻りの少ない開発ができるようになると感じました。
特にこれまではエンジニア側が必要な情報等を元に画面設計を行っていましたが、
発注者側に画面設計イメージを作ってもらうというのはエンジニアはデザイナーではないという点からも有効だと考えております。
ただ、UI等や画面遷移等はエンジニアも知見を持っているものなので、
画面設計イメージのたたき台を発注者が作成し、それを元に発注者・エンジニアでより具体的な画面設計を行うというやり方がいいのかなと思いました。

s_55tanaka

0

受注者側の守備範囲を理解することが非常に重要だと思います。開発担当のエンジニア、デザイナー、運用を担当するエンジニアなどの役割をまず発注者側が知ることが重要。

masami0717

0

WEBページ開発に携わったことがあり、同じ問題にぶつかりました。今回発注者としてどこに問題があったのか振り返ることができました。
プログラミングについて学ぶ機会を得たいと思います。

hk55555

0

最低限やりたいイメージを、出来るだけ具体的に伝えること、そのイメージをエンジニアと共有出来ていることを随時確認することが大事だと感じた。

umemoto28

0

外注する際は、言葉だけでなく図などを用いて相手に伝わりやすくする努力が必要だと感じました。

naga-mi

0

社内IT部に依頼する際には、想定しているシチュエーション、今の問題点をそれぞれ具体的にあげて説明しているつもりなのに、依頼結果がこちらの意図しないものになることが多かったので、自分の身につまされる思いで聞いていました。もっと具体例（デザインや仕様も含め）て最初からガンガン行った方がいいみたいです。
今回はエンジニア側に歩み寄ることを提案していましたが、エンジニア側から歩み寄りもあれば助かります（他部署優先しますとか、想定していないので開発しませんとか、現場使用者の声を黙殺されるので。そのような事例が起きたから依頼してるんですが）

tghikichi

0

設備更新時の提案当に活用できそう

koriono406

0

自分たちの意図を明確にし、相手の立場に寄り添う姿勢が、エンジニアとのコミュニケーションにおいても活用できそう。

mi-----mu

0

お互いの認識を合わせ合意を行うことを学べるよいコースでした。

hill_book

0

エンジニアの方に依頼する場合だけでなく、自分が専門でない分野の業務を専門家に依頼する場合にも役立つと思いました。
専門家になるためには努力している、その通りだと思いました。

k_ma2no

0

どこまで知ればいいかというコミュニケーションはなかなか難しいがチャレンジしてみたい。

s_tokairin

0

発注者といえど、決めつけずに、エンジニアの知見を尊重しながら接する必要があること

mizuto_nakano

0

システム開発は優秀なSEに巡り合えるか？で成果に差が出るという認識です。基本エンジニアは専門家ですから、上手く発注者の意図を汲み取るということは期待しすぎない方がよいですね。

oka-34

0

発注者、受注者ともに、自分の考えや状況を相手に分かるように伝えること。専門的なこと、細かいことはプロに任せてといった曖昧な認識だと必ず齟齬が生じる。これはＩＴだけでなく、他の仕事にも言えることだと思った。

dpmp_haruka

0

開発作業においては１番最初にこちらが想定していることをいかに具体的にイメージの齟齬なく伝えるかが重要だと思っていましたが、そのなんとなくが言語化されていてより、何を伝えるべきか意識が必要だと思いました。

ken711

0

発注者と受注者の視点のズレに気づかされた。発注者は仕様をある程度明確に伝えること、受注者も開発する上で必要な仕様などを発注者と協議する意識を持つことが必要だと思った。

cross0313

0

現在全社PJとして、SCM基盤の導入を検討していて自身は一つの製造部内のリーダー的立場である。実際にまだ要件定義を実施した段階で、実際の動きが良く分からないので見たいという要望を出してしまっていた…。
スケジュール感や修正等について、一旦ベンダーにどういった言語を用いて進めているのか？画面の修正の負担感などを直接聞いてみて、講座でもあった通り自分で簡単に該当する言語について少し触れてみるようにしていきたい。

shp0765

0

現部署において、発注者側になる立場であるためとても参考になりました。ただ、一方でエンジニア側からの視点で発注者とのコミュニケーションという側面も必要かと思います。

rl-masayuki

0

自社のイメージ動画を作成するとき内部に開発できる人がいない場合外部の動画作成会社に依頼する事になります、発注先業者と打ち合わせする際には事前に発注者側のイメージを具体化しておくこと（デザインや拘り）が大事であり事前に考えをまとめるミーティングをしっかり行う必要があるまた受注者側とのコミュニケーションをしっかり行い考え方の認識を合わせていく必要がある、さらに予算と納期を早め早めに伝えいく事が大事と認識しました。

coffee_user

0

社内システム開発においてエンジニアに依頼することがあるが、自身の業務だけでなく相手側の仕事についても理解することが大事である。来客システムにおいても社内ルールやユーザーの用途を把握したうえで発注しないと結局は使いにくいものになってしまう。

maglo

0

お互いの理解を確認しながら進めることがわかった。

kinchan62

0

こういうことを学ばないままに前の職場ではシステム開発のしごとに携わっていました。

yajima_keisuke

0

前に個人的にですが発注した時に、仕様も結果もぐちゃぐちゃなものができて困ったことがありました。結局お金をどぶに捨てる形になってしまい残念でしたが、技術には大きな差があるなと思いました。

toshi-iwai

0

非エンジニアもエンジニアの苦労を理解するためには色々プログラミングの勉強して会話に挑むことが大切だと思いました。

nao1006

0

エンジニアと話する際は一番最初に具体的なゴール、工数をお互いが同様の認識になるように記録として残すことが大事

cs1960

0

大変難しかった。でもがんばります。

020403

0

専門分野が異なる担当者と話すときには、お互いの認識が一致しているかを常に意識して打ち合わせをする必要がある。

ryoshima

0

私はエンジニアなので逆にうまく説明、共有ができるようにしていきたいとおもった

hiyamizu

0

わかりやすかったです

matsuking

0

受注者と発注者、つまり話し手と聞き手の間で、誤解や理解不足のないコミュニケーションをするためには
共有する領域によって、事前の準備や心構えが違ってくる。特に専門分野で言語も複雑な領域では
想像を超えるdiscommunicationが起こる。このことを常に頭に浮かべながら、丁寧、慎重に対応していきたい。

mamaru

0

とりあえず勉強ですね。

maikootaki

0

発注者にとっては社内への対応のほうが難しい

imahori1203

0

エンジニアとのコミュニケーションに限らず、ファジーな部分を如何に埋めておくかがトラブルを未然に防ぐ唯一の方法。

shirakaba2024

0

丸投げはダメだし、最初の時点でのイメージの共有、コストや時間、業務の範囲などの基本的なところをすり合わせておくことの大切さがわかりました。

munehira

0

１）発注者側から見て、すぐできそうだと思われる事でも、エンジニアとしては大きな労力がかかることがあることが分かった。２）納期についても、エンジニアの意見を聞いて設定することが大切であると認識できました。

yandy

0

新機能の開発を伴う案件の場合、どの程度のコスト・納期を見るかという場面で有効に活用できそうです。（営業サイドの見方）

fm_user

0

決められた予算に対してどこまでのものがアウトプットできるかを発注者側のエゴを取り除いた形で精緻に結論付けることが重要であると感じる。そこから予算の上方修正または当初描いていた開発レベルの抑制（最低限どこまで充足すればいいのかの優先付）を経営陣とシェアし、お互い無駄なストレスを抱えないプロジェクト進行が必要となる。

yotara

0

私の業務にはWebシステムの開発というものは直接関係しませんが、委託先との契約や取引条件でのトラブルの相談は有り得ます。
トラブルにならないように、事前に発注者視点と受注者視点が異なることや、トラブルの原因となる事象を取り除くこと、トラブルが発生した場合には、その原因が特定できるようになっていたいと思います。

satoru-onogi

0

DX担当として、外部に発注する際には参考になりました。また、ローコード、ノーコードのアプリを作成する場合にもその担当への伝え方を気を付けるべきと思った。

wayan

0

発注した際に、デモ画面を見ないとわからない、実際見てみるとイメージと違うというのは、実感があります。動画でもあったように、あそこはこうして、というようなことをチーム内で出して、開発者にぶつけるというようなことを確かにやっていました。
今回の動画で、エンジニアとデザイナーは担当が違うということを初めて知りました。同じ人が一連の作業でやっているものだと思っていましたが、今回そうではないことを知り、今後はそのあたりも意識して進めていきたいと思います。

yfujioka

0

「エンジニアと非エンジニアでは認識は必ずズレる」ため、「エンジニアへの歩み寄りが大切」であることを実感しました。

nabezo1962

0

システム開発プロジェクトの7-8割が失敗している、とも言われますが、この講義を聞いてみて理解できました。
落とし穴がありすぎてうまくいくイメージが持てません。

morimotosatoshi

0

認識のズレによるトラブル発生の懸念がある。業務を円滑に進めるために、依頼主が早合点せずに発注先に無理強いすることなくコミュニケーションを行い理解を深めた上で打合せを進めることが必要と考えられる。信頼関係の構築が円滑な業務進行には必要である。

naokika

0

私は業務として発注する立場であるため、勉強になりました。

takashiishimaru

0

エンジニアの立場ですが、発注者側の思いも認識した上で、今後の提案においてより一層工夫していきたいと思いました。

ootoshi

0

お互いの仕事を尊重することが、円滑に進めるための第一歩だと感じました。

ganko8

0

業務でシステムをエンジニアに発注することはないが、他部門と協業で業務をするときに当てはめて考えると、端的にはいかに相手の立場に立ち、気を配って業務を遂行するか、につきると思う。

hiroki_yonezawa

0

片側だけの寄り添いは、まっすぐ進めないので双方が寄れると良いなと思いました。とは言え、大概、最初の話から変わっていくのは発注側にありがちなところなので、そういう意味では良い学びでした。

kenta39

0

バックグラウンドが違うとそれに対する仕事の認識や進め方が違うので相手のことを知ることが円滑に仕事を進めるカギだと思った。

yokota69

0

現在、システム開発の発注を控えているので、今回学んだ発注者の注意点を意識して取り組みたいと思います。

ajihara

0

コミュニケーションが重要、但しそのコミュニケーションを成り立たせるためにも今回の動画のような共有認識が必要と学びました。

a_matuo

0

発注者の姿勢としてエンジニアが実際にどういう体制や手順で仕事をしているかをもっと知る必要があると感じました。ただ、発注者と成果物を提供するエンジニアのリテラシーのギャップがありすぎることもあり、行き違いを生む可能性があることも認識しました。

aokita

0

エンジニアだけじゃなく業者との打ち合わせは同じように細かいところまで打ち合わせないとならないと思います。理解されていないもしくは理解していない部分が後で出てきます。

tori000

0

エンジニアとのコミュニケーションの注意点が学べた

doradora_0112

0

エンジニアの仕事のすべてを学ぶことはできないという中で、どこまでを知っていったらいいのか、など非常に勉強になった。相手に聞いてしまうのも方法なのだと学んだ。

m-hirose

0

事例の各フェーズでのすれ違いは、いかにもありそうなシーンだった。特に、受注者側がシンプルなコードや機能に拘ってくれたのに対して、発注者側がデザインにばかり目がいってしまって嫌なムードになることは頻繁にありそうだと思った。
エンジニアとの会話に限らず、相手が何に重きを置いてどんな風にこちらに配慮してくれたのかを理解することは、一緒に仕事をする上ですごく大切なことだと再認識した。
私もここ数年で基本情報技術者試験を受けたりプログラミング講座を受講したりしているが、やり方に留まらず、仕事の進め方や価値観にまで思いを馳せながらエンジニアの世界を理解することも重要だと思った。

tomoaki_01

0

注文者と受注者（エンジニア）の認識のズレは多くある。注文者の知識不足もその要因のひとつであると思う。事前にインターフェイスの設計や保守内容についても書面で意識合わせを行い、互いにあゆみよることがプロジェクト成功の重要要素である。

shinici_matsuda

0

発注時齟齬が少なくなるよう気をつけます

coco1203

0

情報の非対称性という言葉が刺さった、人間関係でもビジネスでも同じようにお互いを知ることが大事だと改めて学ぶことができた

m_yuuki02

0

エンジニアとのコミニュケーションを大事にして行く

don-don

0

エンジニアとの接点が増えるなかその考え方を知ることは重要

atsushi_hara

0

エンジニアとのトラブルはあるあるの事例で参考になりました。

itanao

0

今から要件定義に入るプロジェクトがあるので、エンジニアとのコミュニケーションのポイントを把握できてよかった

saien0

0

エンジニアの身になるというのは相手の状況を理解するということなので他業務を行う方と連携する際に相手の業務がわかればマスコミュニケーションが減る要因になりそうだと思った

horiguchi_c

0

分からない事は聞くようにします

kouichi5614

0

お互いの小道をしっかりと理解して、相手に寄り添う感覚が必要だと思いました。それにより良いものができるのだと思います。

esatto

0

今いる職場の周りにはエンジニアはいませんが、今後エンジニアに何か依頼をする機会が発生した場合、学んだことに注意し対応したいと思いました？