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

g_im

クリエイティブ

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

shaftesbury

専門職

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

kbdy555

金融・不動産　関連職

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

tsu_watanabe

IT・WEB・エンジニア

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

daisuke_i_2020

メーカー技術・研究・開発

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

kameco

販売・サービス・事務

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

kobo0804

IT・WEB・エンジニア

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

oyok

IT・WEB・エンジニア

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

bibizu1217

メーカー技術・研究・開発

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

m_yae

営業

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

yukiko_w

コンサルタント

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

hiro_yoshioka

メーカー技術・研究・開発

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

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

taka0001

販売・サービス・事務

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

saito-yoshitaka

メーカー技術・研究・開発

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

kotoshis34

メーカー技術・研究・開発

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

end-o

建設・土木　関連職

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

kaz_2021

マーケティング

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

llasu_ito_0502

人事・労務・法務

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

shoot-

マーケティング

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

ymcyr

メーカー技術・研究・開発

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

koriono406

金融・不動産　関連職

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

mi-----mu

コンサルタント

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

hill_book

経営・経営企画

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

k_ma2no

専門職

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

s_tokairin

IT・WEB・エンジニア

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

mizuto_nakano

経営・経営企画

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

oka-34

メーカー技術・研究・開発

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

dpmp_haruka

マーケティング

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

ken711

メーカー技術・研究・開発

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

cross0313

メーカー技術・研究・開発

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

shp0765

その他

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

rl-masayuki

その他

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

coffee_user

その他

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

oyobe_y

営業

開発側とのコミュニケーションはお互いの意図の共有と理解、認識の統一が必要と理解

maglo

その他

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

kinchan62

その他

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

yajima_keisuke

営業

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

toshi-iwai

経理・財務

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

nao1006

人事・労務・法務

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

cs1960

販売・サービス・事務

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

020403

その他

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

ryoshima

メーカー技術・研究・開発

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

hiyamizu

営業

わかりやすかったです

matsuking

その他

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

mamaru

クリエイティブ

とりあえず勉強ですね。

maikootaki

営業

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

imahori1203

営業

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

shirakaba2024

販売・サービス・事務

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

munehira

人事・労務・法務

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

yandy

営業

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

fm_user

経営・経営企画

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

yotara

人事・労務・法務

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

satoru-onogi

メーカー技術・研究・開発

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

wayan

販売・サービス・事務

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

yfujioka

販売・サービス・事務

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

nabezo1962

人事・労務・法務

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

morimotosatoshi

営業

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

naokika

経理・財務

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

takashiishimaru

IT・WEB・エンジニア

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

ootoshi

メーカー技術・研究・開発

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

ganko8

メーカー技術・研究・開発

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

hiroki_yonezawa

その他

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

kenta39

メーカー技術・研究・開発

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

yokota69

その他

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

ajihara

経営・経営企画

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

a_matuo

メーカー技術・研究・開発

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

aokita

その他

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

tori000

その他

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

doradora_0112

営業

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

m-hirose

金融・不動産　関連職

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

tomoaki_01

営業

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

shinici_matsuda

その他

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

coco1203

その他

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

m_yuuki02

その他

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

don-don

営業

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

atsushi_hara

その他

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

itanao

資材・購買・物流

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

ogawanamiko

販売・サービス・事務

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

horiguchi_c

販売・サービス・事務

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

kouichi5614

営業

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

esatto

その他

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

benkyousinakya

販売・サービス・事務

歩み寄りはどの領域・シーンでも必要なもの。
うーん。。。。

nikuyo

経理・財務

新システム導入やソフトウェア開発に関するプロジェクトチームメンバーとなった際に
ベンダーへの発注時に留意する点を学べた。
決められた予算、期限、最低限クリアする目標を実現するため、契約までにお互いの認識に
齟齬が生じないようベンダーとの十分な協議を重ね、議事録を共有するす等の措置を講じる。
リリース後の保守契約についても事前に契約に織り込む等し、運用開始後の不具合に備える。

shinji-yamamoto

人事・労務・法務

エンジニアの方とのコミュニケーションという内容でしたが、この内容は何かを人にお願いするにあたって重要な内容だと思います。
多分理解してくれているだろうとい状態で進めると、認識のずれで後で大慌てすることがあります。
具体的に伝える、認識違いが無いかを確認する。最初時間がかかってもそこを飛ばしてしまうと、後で更に時間やコストがかかる。
また、相手に対して感謝の気持ちを忘れないことが大事。

mi-ta-

メーカー技術・研究・開発

エンジニアと関わることはないが、打合せなどで、「少し・ちょっとした」などの感覚的な言葉、「あれ・それ」など、相手と齟齬を生みやすい言葉は具体的な言葉に置き換える必要があると思った。

chan_moki

人事・労務・法務

人事部に所属しております。
実際に今、人事情報を管理するシステムの開発、保守、運営をこれからどうしていくのか先輩方が業者とやり取りしているのを目の当たりにしています。
会議後に戻ってくる先輩方を見ていると、
いつも不満を口にしているので、私もそれに共感してそれは酷い話だ、と思うことが多かったのですが、今回のやり取りの例を見てもしかしたら受注者側の考え方が全然こちらもわかってないのかも？と少し考えさせられました。
とはいえ、当事者ではないのでどういうやりとりや説明の仕方を受けているのかは分かってはいないのですが、お互い歩み寄ることが出来ないといいものは出来ないということはよく分かりました。

zhong_ming

経営・経営企画

基本は知りましたが、でも実践の時に大変かも。

ryota0423

その他

SEさんの目線に立って折衝すべき

2023-tsuyoshi

その他

自分で学び理解力をつけていくことが大切。

canoek7

その他

業務フロー、画面イメージ、要件定義はできるように何から始めたらよいのか。そこから勉強したい。