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

g_im

クリエイティブ

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

tsu_watanabe

IT・WEB・エンジニア

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

kbdy555

金融・不動産　関連職

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

wkiymbk

IT・WEB・エンジニア

「認識は必ずズレる。エンジニアとのコミュニケーションには、「歩み寄り」が必要。歩み寄りで問題発生を予防できる。」ということを学びました。
私はソフトウェアエンジニアなので、「あるある」と思いながら視聴しました。非エンジニアとのコミュニケーションに今回の学び「歩み寄り」を活用します。

oyok

IT・WEB・エンジニア

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

kameco

販売・サービス・事務

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

kobo0804

IT・WEB・エンジニア

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

daisuke_i_2020

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

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

kaz_2021

マーケティング

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

kotoshis34

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

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

llasu_ito_0502

人事・労務・法務

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

hiro_yoshioka

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

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

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

taka0001

販売・サービス・事務

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

saito-yoshitaka

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

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

shoot-

マーケティング

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

asaki_design

IT・WEB・エンジニア

これからフリーでウェブデザイナーをしていくので、こういった受注プロセスに対面することも数多くあると思います。その中でお互いに相手を思いやって仕事をすると言う注意点を知ることができてよかったです。私も受注者の方の気持ちに立って物事を進められるデザイナーになりたいです。

z_a_a

営業

ここで学んだ内容は、エンジニアとの話だけでなく、他業種の人と接するときにも必要なことだと思いました。知らないことはきちんと話し合って認識の相違を出来るだけなくして進めていくことが大事だと感じます。

mune1971

マーケティング

実際に社内でも頻繁に起きている課題であるが、あまり語られる事は少ない内容だと感じました。

tottokonkmr

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

発注者側が完成のイメージをもっておいて、それを受注者に説明できることが必要と再認識できた。
IT関係の業務受発注に関する研修だが、開発・運用と仕事全般に当てはまり非常に良い内容だと思う。

miss-me

その他

物流業務のシステムで、現場倉庫のオペレーションとの兼ね合いをうまく説明できるようにならねばと思いました。

cavalier_jun

メディカル　関連職

事業を進める上で、企画制作や広告、広報、法務といった方と接することも多いが、ついつい相手目線になれないシーンを見かける事がある。

同じ会社でビジョンは同じはずだが、部署が変わりミッションやバリューが少しづつ異なって解釈している事もあるが、まずはお互いに相手起点にものを考えること、伝えることが重要だと認識した。

fgl970101

資材・購買・物流

要件を正確に伝える、要件を正確に聞き出しまとめる、どちらも大切であることをあらためて認識できました。
今後の業務においても心掛けたいと思います。

yoko1013

コンサルタント

私にはエンジニアと発注者の双方を経験しているので、よくわかりました。
発注者は、エンジニアの仕事を理解しようとする姿勢はかなり大事です。エンジニアの作業を知らないばっかりに発せられる無邪気な追加要望は、エンジニアを傷つけます。負担を強いることにもなります。
予算の厳しいプロジェクトでは、発注者はエンジニアに対して、かなりドライな態度を取ることもあるかと思います。エンジニアを酷使してリリースまでこぎつけられたとしても、エンジニアは「二度とこの会社と仕事したくない」という気持ちになります。そういう悪い噂は、エンジニア内でもすぐに広まります。
やはり、発注者もエンジニアも双方の立場を尊重して、関係性を築いてプロジェクトを進めていくことが、一番大事だと思います。

onda-tsuyoshi

販売・サービス・事務

発注者は出来るだけ多くの事を求める反面、開発者は現実的なロジックから入る。良いシステム開発については相互の知恵と活用方法を話し合い穴を埋めていく作業により良いシステム開発につながるものと推察する。

yamataka0917

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

自分がエンジニアのため、非エンジニアの方にどの様に伝えれば良いか、接すれば良好にプロジェクトが進められるか理解出来た。相手の視点に立ったコミュニケーションを行なっていく。

masaki131

営業

何事もｺﾐｭﾆｹｰｼｮﾝですね。要点をまとめて視覚的に物事を伝えることが重要だと再確認しました。

bobby31

マーケティング

誰に対しても思いやりを持とうと思った

taku358

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

受注側の相手の立場に立って，考え行動することが大切であることを再認識させられました。

mttm

専門職

サイト構築やコンテンツ制作の際に外部業者との連携

yuki-ruru

その他

コミュニケーション能力の向上と、歩み寄りが必要であると感じた。

pepe0113

経営・経営企画

現在、他の担当者が開発に携わってきたシステムの担当窓口を引き継ぎ、途中から関わっています。
まさに動画で話が出ていたような対応をしている部分もあったので、今後は注意したいと思います。
引き継いだときのエンジニア側の冷めきった態度を思い出し、前任は誤って対応をしてきたのだと予想できました。

mimorin

経営・経営企画

エンジニアとのコミュニケーションは、社内の他の技術職とのコミュニケーションにも似ていると思う。
信頼関係を大切にすることが一番で、対等な関係を保てるように努めたい。

barakhan

金融・不動産　関連職

講師のお話ひとつひとつが身にしみます。社内ユーザーの要望をどこまで正確に理解・取捨選択し、それをSEさんにただしく伝えているか、またSEさんからの報告や質問をきちんと理解し、次に進められるよう会話をしているか・・・
反省ばかりです。

harryy

営業

どのような業務でも事前の段取りと日頃の進捗管理が重要だなと再認識しました。

2007

営業

エンジニアに限らずですが、自分の職種以外の方と仕事をするときは、相手の立場に立ってよりよい仕事をするという気持ちが大事なのではないでしょうか。お互いの仕事の内容や取り組み方を理解して仕事することが大事だいうことはどの職種でも変わらないと思います。

z-nishigaki

経営・経営企画

ＨＰ制作を外部の会社に依頼しているが、外部の会社（エンジニア）により沿った対応が必要なことは理解した。ただ、他の関係者はそのような理解はないので、ストーリーにあったとおり無理難題や気になる点をただただむやみに指摘してくることが予見される。

ueharanobuyuki

営業

エンジニアに限らずデザイナーと仕事をする際に、何とやったらどこまで手間がかかるか、金額がいくらかかって時間がどの程度かかるかを知っているだけで大きく仕事の進め方が楽になります。エンジニアやデザイナーと共通言語で話ができることが大切になるので、こちらも学ぶことが必要です。

matsuda-michiko

人事・労務・法務

　エンジニアの仕事＝システムの開発であり、非常に難しい専門知識が必要なので、一般事務や営業担当はエンジニアの仕事をイメージできなくて当然であり、そのように考えてしまう事は仕方のないことで、悪い事ではないと考えていました。
　しかし今回の研修で、その考え方ではダメだという事を認識しました。
　企業が独自アプリを持っている事が当然のようになっている中、事業を円滑に進め・運用するにはエンジニアに歩み寄る姿勢が重要だという事がわかりました。歩み寄るためにはエンジニアがどのような仕事をしているのか、認識すべき専門用語は何か、という事を相手の立場に立って考える必要がある事もわかりました。
　同時に、自分にはIT・DXに関する勉強が全く足りていない事を再認識しました。企業の一部の人間が理解していれば十分だと思っていたのですが、企業力を高めるには従業員一人一人がIT・DXに関する知識を身に着ける事が重要だと感じました。
　業務や日常の生活においては、アイデア・企画の視野が広がり、IT・DXを取り入れる事で業務効率化につながるのではないかと考えています。そして、エンジニアとのやりとりが発生した場合は、今回学んだ内容が大変役に立つと思います。

noriyuki_3241

マーケティング

自分が専門外の内容に対しての対応全般に繋がると感じて参考になった。

zin-124

営業

非エンジニアとして気をつける事が理解出来た。

yoshinho

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

エンジニアと非エンジニアが良い関係性を気付くためには、お互いに何が解らないのか、理解の溝を埋める気づかいと行動が重要だと感じた。発注側は、依頼のイメージを出来るだけ具体的に伝えられるよう前もって準備する事、受注側は依頼元が何を求めているのか、自分たちがそれに対して何ができるのか逆提案する事などできれば、開発・運用時に大きな課題に見舞われないのではないでしょうか？

hiro4725

資材・購買・物流

発注者側からすると何を聞いていいかもわからない。見積り一つにしても、一括ドーンではなく、工程毎の積み上げを表示して貰えれば、『ここが大変なんだな』とわかるのでより一層コミュニケーションを取ろうとすると思う。認識のズレは当然あるのだから、そこをどう埋めていくかが問題だと思う。

end-o

建設・土木　関連職

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

kurou

営業

非エンジニアの発注者視点で、受注側のエンジニアと円滑に仕事を進めるために、エンジニアの仕事を経験してみるという発想はなかった。是非経験してみたいが、どうしたらいいのだろう。

rinco

その他

最後のエンジニアとのコミュニケーション、どの仕事にも当てはまると思う。

ryo19860430

専門職

エンジニアの仕事は飽和状態。

zennoh-keita

営業

業務効率の向上につながると考える。

yamazaki-amane

営業

日エンジニアとしても寄り添うことが、受注側にメリットが生まれてくる

news1925

人事・労務・法務

業界用語についての基礎知識の最低限での習得

sakayosi

メディカル　関連職

日頃、プログラミングされたものを使用することが多い為、
中身までの理解はできていないことにより、
作成者側が苦労していることが多いという事を認識できた。

tomi_co

その他

実際に発注側としてシステム開発に関わっていく中で、こちら側の要求ばかりを押し付けがちだったことを、とても反省しながら受講しました。お互いの立場を尊重しながら、歩み寄ることが本当に大切だと実感しています。学びを今後に活かしていきたいです。

globis101

マーケティング

現在参加しているプロジェクトでも外部のエンジニアにシステム開発をお願いしていますが、これまで経験したコミュニケーションの難しさの要因について理解が深まりました。　ラウンチまでに必要とする最低限の機能の選定や、発注に際して準備しておく事を今回の学んだ内容にも続き試そうと思います。

kanak_16

その他

講義内容に即した行動をとりたい

shinichi_mae

営業

非エンジニアが発注時に気をつけるべき点について理解出来ました

ozawa-hiroyasu

建設・土木　関連職

仕事をイメージしながらアウトソーシングすることが重要であると再認識できた

_atsushi

営業

エンジニアとの接し方はわかりました。
エンジニアも発注者側に寄り添うことで同じ過ちが減ることにもなると考えます。

horihorihorihor

資材・購買・物流

どのような仕事もコミュニケーションが必要だと思うが、エンジニアとのコミュニケーションは特に注意する必要があると感じた

moo_5103

コンサルタント

発注する段階で、何がどれくらい必要でなのかを洗い出すのはもちろん商談フェーズでエンジニアと何を優先するかといった譲れないラインをお互い認識しておく必要があると感じた。

k-kajiyama

営業

現状ではエンジニアに対して発注するという業務には携わっていないが、今回の講義でエンジニアの考え方を勉強することができ、非常に有意義であった。

zennoh-oyama

営業

システム開発は滅多にない業務だが、参考になった。

d19740208g

その他

技術系の業務なので、役には立った。

kaaay_yaaak

コンサルタント

とても役に立ちました

t_yamaguchi3420

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

エンジニア/非エンジニア双方の歩み寄りが重要と感じました。非エンジニアの身としては、エンジニアと共通言語でコミュニケーションが取れるレベルの教養を身に付けなければと思います。

koyahiro

経営・経営企画

発注時の認識についてよく理解できた

ajipanda_t

人事・労務・法務

システム開発の想定されるリスクについては、予めスケジュールに盛り込んで、対応していかないとギリギリになってから、断念となるケースが多くあり、フェーズごとにマイルストーンを定めて、相互で確認していく事が重要である。

kgk_ys

経営・経営企画

自分がどのレベルの知識があるのか？わかるように最初にコミュニケーションしておくこと。重要はケースでは自分がどこまで知識をつけておくべきかも明らかにしておくこと。但し自分が納得できるようにしておかないと表面的な知識しかつかなくて会話にならなくなるので注意。

yokozuka-shouji

その他

エンジニアの気持ちに寄り添うことを意識していきたいと思います。

coyuki

その他

非エンジニアとしてエンジニアに依頼する時の心がけなど理解した。

miyaking

販売・サービス・事務

大変参考になりました

itonaoto

資材・購買・物流

システムエンジニアに発注する際は、決めつけはせず、相手の話しをよく聞いて連携して取り組んでいくことが望ましいと思った。

zennoh-mi

建設・土木　関連職

今のところ思い浮かばないが、将来、発注担当になった時に困らない程度の知識が必要と思います。

ara5505

販売・サービス・事務

運用フェーズをイメージせずに失敗したことがあります。勉強になりましたが、それでも実際は苦労が残るのでしょうね。

hideo_n

営業

発注する際に、具体的にイメージして、それを書き出す。
今回の例だと、必須機能・できれば装備したい機能など機能面と、画面のイメージや遷移などのデザイン面。
具体的に箇条書きにし、自分で考えたイメージで紙芝居を作れるくらいにしておきたいと感じた。

今回の発注者の視点だけでないが、より知識を持っている人に接する際は、教えてもらう姿勢で、且つ自分も自己学習をした前提で学ぶ姿勢が必要だと感じた。

takigamidaisaku

専門職

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

zennoh-ookubo

経営・経営企画

エンジニアのことを考えて（知って）発注業務を進めることが必用。

taka_4211

専門職

他社への外注だけではなくて、他部署とのやりとりでも活かせると思いました。

shigebo

人事・労務・法務

受託開発を前提としておりますが、私自身が務めるパッケージソフトの会社でも、開発部門と非開発部門の関係としてそのままオーバーラップします。職種別採用を行っているので、非開発部門の教育カリキュラムを作成する上で非常に参考になりました。

t_shiota

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

私は研究所所属ですが、どのように発注元（主に事業部）の方に説明・話せばよいかを改めて考えるきっかけになりました。ポイントは「わかりやすく・専門用語を極力使用せずに話す」ことかと思いました。

a022695

建設・土木　関連職

依頼側と受け手側の内容をより近づけておくことが重要だと感じました。

kenji_nagahama

資材・購買・物流

普段から耳にする言葉にもプログラミング用語がたくさんある事を知りました

tomizuka-toshio

営業

エンジニアとのコミュニケーションの重要性が理解できた

hiro0509

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

日常業務でソフト設計を依頼する際に留意点が学べた。よくいつまでにやってと言うが確かに仕事のボリュームが試算出来ないのにこちらの希望だけ伝えていたので反省です。

gantetsu013

営業

現時点で該当業務はない

tsuda5963

資材・購買・物流

分かりやすかったです。
社内にもSE担当の方がおりますが、何を言ってるのかさっぱり…
擦り合わせ、大事ですね。

mnakashima

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

発注者のプロになることが大事だと思いました。「形になってみないとわからない」は、どうしても否めないことがあると思います。ただ、これを少しずつでも手前の段階で理解し合える様になれば、すなわち相手への気遣いも生まれ、効率と出来栄えは明らかに変わってくると思いました。発注者プロになる勉強大事と思いました。

k_katoh

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

受発注の関係は現在ありませんが、専門性やバリューチェーンステージの違う関係者と仕事をすることが多く、少しでも相手の立場や基本的な考えを理解する(あるいは理解しようとする姿勢を見せる)ことでスムーズに進められそうです。

komai-hiroshi

その他

エンジニアに依頼する場面があれば、今回の内容を参考に進めていきたい

kawamata-satoru

専門職

プログラムを学ぶ観点は持ち合わせていませんが、非エンジニアとしての気をつけることが理解できた。

harunonikukyu

販売・サービス・事務

ユーザレベルで要件定義の打合せに出席することがあります。自分が全然方向違いのことを要望しているかも知れないという思いはいつもありましたので、プログラムや工数について学んでみたいと思いました。

kodebu

経理・財務

私が発注者に選ばれたら、間違いなく事例のような、いえそれ以上に悲惨な事になります。発注者は最低限のシステム開発の流れを学び、エンジニアは発注者が素人であることを踏まえた上で説明する。この歩み寄りの大切さを知りました。システムについて毛嫌いせず、踏み出していかないといいモノは作れない。