ネットワークが接続されていません
zhenjizi
2019/02/17
IT・インターネット・ゲーム・通信 マーケティング 部長・ディレクター

最初の要件定義確認は以前からやっていたのでここでの大きなズレはないものの、例えば発注者と受注者とで「ちょっとした修正」の「ちょっと」が指す内容のイメージが違うというのは往々にして発生しうることだと思った。

個人的にエンジニアの仕事を理解するところまでのリソースは取りづらいためエンジニアの気持ちまではちゃんと把握できないかもしれないが、例えば口頭で確認し少し抽象的な内容だと思ったら意味の確認を取る、またデザイナーがいつ仕事をしてデザインの認識合わせをすべきかなどお互いの認識が合わせながら進捗管理をしていくことが大切だと改めて実感しました。

yokofujimori
2019/05/27
商社・流通・小売・サービス 経営・経営企画 課長・主任・係長・マネージャ

実際にアプリの開発に非エンジニア側の発注者としてプロジェクトに参加してましたが、エンジニアに歩み寄ることは、全く考えたこともなかったです。例に出てきた担当者の様に、デザイナーの仕事とエンジニアの仕事の分業もわからず、仕様を直してほしいと言ったこともあります。こちら側の期限もあり、いつまでに仕上げてほしいも言ってました。こちらは、発注しているのだから、要望を伝えないととは思っても、最初の設計段階では予想していなかった遷移になることもあり、エンジニアとのコミュニケーションは、エンジニアから言ってくれないと分からないと思ってました。自分がエンジニアの気持ち、考え方を全く知らなかったと反省して、今後は「歩み寄り」コミュニケーションしていきます。プログラミングも少し勉強します。

ikawamariko
2019/05/26
コンサルティング・専門サービス コンサルタント 課長・主任・係長・マネージャ

エンジニアの気持ちに寄り添うのはわかりますが、エンジニアも「わからない人に寄り添う」ことが大切で、エンジニアサイドにきちんと営業・説明職を設置することが大切だと、逆視点も感じました。同じような動画が、エンジニア向けの「非エンジニア」との会話のコツ、という感じであるといいですね。

toshi-kun
2020/01/06
メーカー 専門職 課長・主任・係長・マネージャ

言いたいことはよくわかる。でも、「一般論だよなー」が感想です。

norikazu0428
2020/08/06
商社・流通・小売・サービス 営業 課長・主任・係長・マネージャ

SEの仕事がわかる営業、営業の仕事がわかるSE、お客ときちんと意識合わせができるスキルの醸成が必要だと感じました。

k_moto
2020/08/04
メーカー マーケティング 課長・主任・係長・マネージャ

今回の話を伺って、今まで仕事をしてきた中でのあるある事例が多く、改めて自分自身プログラミングを知った上で、上手にコミニュケーションを取りながら、進めて行きたと思いました。ありがとうございます。

shuhibi
2020/08/03
金融・不動産・建設 営業 課長・主任・係長・マネージャ

あるあるですね。すごくよくわかります。
それを知ったうえでどう臨むかですね。

mirai80
2020/08/03
商社・流通・小売・サービス メーカー技術・研究・開発 部長・ディレクター

もっと早くにこの講義を受けていればよかったと思う場面が多々ありました。エンジニアのモチベーションの大切さの気づきがありました。

k_ushiroda
2020/08/01
インフラ・公共・その他 IT・WEB・エンジニア 課長・主任・係長・マネージャ

まさにシステム「発注側」の業務に就いていますが、社内でもこの講義で紹介されていた内容について、理解のある方がまだまだ少ないと感じています。
画面遷移のイメージや要件詳細を丁寧に説明し、「受注者」の知見を適切に受け取りながら今後の開発を進めていきたいと改めて感じました。

otobe711
2020/08/01
メーカー その他 課長・主任・係長・マネージャ

社内でシステム利用部署の立場からシステム開発部門に異動をしたことで、今回のテーマにある。利用部署側では見えない、わからないシステム開発側の事情を理解できるようになった。システム部門に異動してもシステム開発するわけではないですが、業務プロセス分析や実現したい業務をイメージし、それを具体的な要件や詳細仕様に落とすこと、また合格条件を最初に決めておくこと、また、最初から100点を目指すのか、ミニマムで立ち上げ順次改善・機能追加するのかは、利用者側として事業戦略立案の責任があることは、開発者の仕事(設計、製作、テスト)を学び、実際にやっている方のお話を聞くことで、非エンジニアでも理解できると思います。開発部門側としても、利用部署向けの開発に際して利用部署に行ってほしいことをガイドにまとめHPなどに公開することも大事ではないかと思います。また、今は、Agile開発の手法を取り入れ、最低限の機能で立ち上げ、順次改善・機能追加するビジネスモデルをとることも多くなっています。利用部署としての戦略をたてるためにも、プログラム開発、およびインフラサービス(OS、DBMS、認証システムなど)がどのようにつくられるか、アマゾンのAWSのYouTube動画などで学ぶこともできます。プログラム開発とはどういうことか、自己研鑽をすることも必要と思います。

shigebo
2020/07/31
IT・インターネット・ゲーム・通信 人事・労務・法務 その他

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

ryuji_001
2020/07/31
医薬・医療・バイオ・メディカル 営業 一般社員

こちらが伝えたいこと、相手が理解していることのギャップをコミュニケーションを通していかに縮めていくのかが重要であると思いました。

y_notou
2020/07/28
コンサルティング・専門サービス コンサルタント 課長・主任・係長・マネージャ

エンジニアに歩み寄るが第一。商談、開発、運用の各々で、受託者の気持ちや懸念にこたえ続けること、認識はずれる、という前提に立ちながら交渉すること。画面設計や要件定義、仕事の進め方と価値観、最低限必要な機能や緊急対応等、押さえるべきポイントを押さえ、発注者のロジックで物事を進めず、相手の頭になることが大事と捉えました

bkb_
2020/07/28
IT・インターネット・ゲーム・通信 メーカー技術・研究・開発 課長・主任・係長・マネージャ

コミュニケーションすることで必ず認識にズレが生じる。ズレに早く気付くようにしたい。

m_r_s
2020/07/27
メーカー メーカー技術・研究・開発 課長・主任・係長・マネージャ

現場実務経験を十数年、その現場へのシステム発注も十年以上経験してきた。100万円程度の小さなシステム改修や、数十億円規模の巨大なシステム開発に携わったりしてきた。システム開発する人を理解すると言った今回の講義は、非常に初歩的な事に過ぎず、それよりも、社内の要件・ニーズを的確に集約し、詳細な要件書を作り上げることである。そう言ったことができないと、意図が正確に伝えられず、システム開発する人の誤解や、見込み違いが生まれる。
また、システム要件だけではなく、社内の運用構築も重要。システムより運用検討が先なのは言うまでもない。システムは仮に素人だとしても、社内の運用構築はプロのハズ。運用構築がしっかりできれば、ある意味、システム要件も付いてくるし、システム開発する人にたいして、説得力が出る。運用が判ることで、システム開発する人が、イメージを明確にすることもできる。

amaetsu
2020/07/26
IT・インターネット・ゲーム・通信 営業 課長・主任・係長・マネージャ

自らがエンジニア業務を少しかじってみることが重要であり、その経験が対エンジニアへの気遣いにつながるとおう内容は大いに理解できました。

daisuke_i_2020
2020/07/19
メーカー メーカー技術・研究・開発 一般社員

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

yanagiox
2020/07/18
商社・流通・小売・サービス 人事・労務・法務 部長・ディレクター

発注者としてやり勝ちな事、そのままやっていました。自分をみているようで恥ずかしかったのですが、非常に良い振り返りになりました。具体性と細かいコミュニケーションをもっと大切にしたいと思います。

yoshn
2020/07/16
メーカー メーカー技術・研究・開発 部長・ディレクター

発注者と受注者の価値観、判断基準の差を認識し、対話していく重要性を感じた。

masahiro_0102
2020/07/14
メーカー その他 部長・ディレクター

仕事をする上で、双方の理解による歩み寄りが大事であることが分かった。

cozyhayakawa
2020/07/11
メーカー 営業 課長・主任・係長・マネージャ

実際に、社内システムの運用側の代表としてシステム開発に関わりました。
まさに、
・最低限必要な機能はなにか。
・工数は任せる
・言い直し、修正の場合のプログラム再設計のハードル高さは慎重に相談する
という点を意識する必要は感じました。

今回はデザインとの関係性(たまにデザイン担当のいないケースもある)、保守人員の持ち方の点は新たなしてんでした。
一度プログラムをやってみようと思います。

hiro_b
2020/07/10
メーカー マーケティング 課長・主任・係長・マネージャ

IT分野に限らず、開発や製造、運営などに理解を示すことは、プロジェクトの遂行はもとより、信頼関係構築など営業業務を行う上でも大事。改めて重要性を確認できた。

yukitk
2020/07/08
商社・流通・小売・サービス IT・WEB・エンジニア 一般社員

具体的に伝えておく、準備する。相手を理解する。
実際は仕事をしていく上で積み重ねていくものも多いですが、最初からこういった項目に留意しておけば多少のトラブルは防げそうかなと思いました。

「運用フェーズ」での追加なのか・込みの項目なのかというのは自分でもよく経験したトラブルなので、商談時にある程度すり合わせをするようにしています。

「知らない」ではなく、理解しようとする、同じ目線に立った歩み寄りが大事ですね。

ikemaru
2020/07/07
インフラ・公共・その他 資材・購買・物流 部長・ディレクター

新しいシステムの開発に際して、タイミング良くこの講義を拝聴できました。エンジニアも人間であり、二人三脚で創造物を作り上げるイメージが大事なような気がしました。そのためには、エンジニアに歩み寄れる知識も必要だと理解しました。

ina-yuzo
2020/07/05
医薬・医療・バイオ・メディカル 営業 課長・主任・係長・マネージャ

解析ソフトについて議論になる場合や新規ソフト開発やリリースのmeetingで意見を伝えたり、発言内容に今後生かせる研修内容であった
ユーザー側の意見と開発チームの意見の落しどころを見極める力やコミュニケーション力が求められる事を再認識できた

rorin310
2020/07/05
金融・不動産・建設 金融・不動産 関連職 課長・主任・係長・マネージャ

コミュニケーションはどの仕事でも大切。発注者は、専門用語など理解できないと外国語で打ち合わせをしているのと同じ。発注者も多少勉強が必要だが、何でも聞くことができる関係ができているかも重要だと思う。発注者と受注者がお互いにわかっているだろうと思って前に進むといけない。普段の仕事と一緒。

okarin74
2020/07/04
メーカー その他 課長・主任・係長・マネージャ

このメソッドは、エンジニアとのコミュニケーション以外にもあらゆる業務委託において使えると思った。

tauchan
2020/07/04
医薬・医療・バイオ・メディカル 販売・サービス・事務 課長・主任・係長・マネージャ

相手のご理解が大切ですね。

masaru36
2020/07/04
医薬・医療・バイオ・メディカル IT・WEB・エンジニア 課長・主任・係長・マネージャ

10年前の話であるが、当時の上司から突然のプロジェクト参加を命ぜられ、エンジニアでかつ発注者だった私が、対受注者のエンジニアとの密な打ち合わせを重ねることで、プロジェクトとしてはうまく行った経験を思い出せば、やはりお互いの歩み寄りが良く出来ていたと思われる。相性の問題も絶対有ると思われるがお互い納得がいくまでの話し合い、打ち合わせは重要であると思う。

cyborg009
2020/07/02
IT・インターネット・ゲーム・通信 IT・WEB・エンジニア 課長・主任・係長・マネージャ

とても発注側も受注側もレベルの低い内容という印象。
こんな知識レベルでシステム開発を依頼するところって多いんですか?

ohhara_chiba
2020/06/30
インフラ・公共・その他 資材・購買・物流 課長・主任・係長・マネージャ

システム発注依頼した時、こんなもどかしいやりとりあったなぁ〜と若い頃を思い出しました。具体的且つ明確に金額面での承認とってしっかりとしたシステムを初回でつくりたいとこです。

hotton
2020/06/29
金融・不動産・建設 建設・土木 関連職 部長・ディレクター

エンジニアは自分の仕事を安く見られたくない、非エンジニアは出来るだけ多くの事を詰め込もうとする。ここに一番の齟齬が発生しているのではないかと感じた。非エンジニアにもプログラミングを学んでもらう、エンジニアが何に注意してプログラムを制作しているか知ってもらう、工数をどのように推算しているか知ってもらう、これらのことを分かりやすい言葉で伝える。こうした努力が間に立つ者に期待されることだろう。優秀なプログラマーは優秀な伝達者とは限らない。多少プログラム技術に劣っても、システム全体を理解し、目的や運用まで含め考えられるエンジニアが求められる。

ogawa_koichi
2020/06/28
広告・マスコミ・エンターテインメント 人事・労務・法務 課長・主任・係長・マネージャ

どこまで行っても、仕事というのは「コミュニケーション」なのだと思う。
社内だけにとどまらずに社外との連携もコミュニケーション。
これを上手に行うことが、仕事の成否の鍵なのだ。
確かのこの講座の通り、発注者側がある程度開発について理解することが大事だろう。
そういうテクニック面も重要であるが、それ以前に、相手のことを思いやり、相手の人格を尊重し、仕事のこだわりを認め合う。これが出来ればあまりモメることはないような気がする。後は適宜の進捗確認。これもコミュニケーションの一環だったりする。昔であれば手土産持って「どう?順調?」なんて時代もあったが、手土産は時代錯誤としても「声がけ」くらいはあってもいい。
放っておかれるのが一番困ることなのだから。これだけ「コミュニケーションが大事」と言われているのになかなか出来ない。それだけ「コミュニケーションスキル」とは難しいものなのだろうと思う。

snufkin14
2020/06/28
インフラ・公共・その他 販売・サービス・事務 課長・主任・係長・マネージャ

例題がとても現実的で、非常に共感できた。
まずは発注者と受注者のズレが大きいということを、序盤のミーティングで認識合わせをする必要があることがとても大事だと感じた。

koike_123k
2020/06/28
コンサルティング・専門サービス コンサルタント 課長・主任・係長・マネージャ

発注者と受注者(エンジニア)の歩み寄りは大切だと感じました。それとあわせて、歩み寄りを行うタイミングや歩み寄りの仕様や機能をどこまで行うのかも予め設定することが必要だと考えます。

sho1971
2020/06/26
金融・不動産・建設 営業 課長・主任・係長・マネージャ

発注者=顧客、受注者=受託者という立場で考えるならば、費用を捻出する発注者が恣意的に指示を出すということが自然ではないかとも思った。だが、対等にビジネスを進め、良いものを構築していくことが重要とも思う。

str228
2020/06/24
メーカー メーカー技術・研究・開発 一般社員

かなり身をもって経験した内容でした。まず見ておきたかったし、これは開発を任される人間は見るべき内容だと思います。
要件定義や設計思想など、日本語はなんとなく理解できても具体的に何を指すのかよくわからないことも多いものです。

medamayaki
2020/06/21
金融・不動産・建設 経営・経営企画 課長・主任・係長・マネージャ

業務側とベンダー側それぞれが抱える情報の非対称性を理解し、知らない事を意識したい。コミュニケーションを取りかたに活用できそうだと思った。

daisuke_i
2020/06/18
メーカー メーカー技術・研究・開発 課長・主任・係長・マネージャ

以前システム開発のユーザー側として参加したことがありましたが、発生したトラブルや行き違いは大体ここに網羅されていたように思います。その時は経験のある先輩が開発プロジェクトの管理者であったので、アドバイスを受けながら対応していたのですが、この認識があったらもうすこし洗練されたものができていたのかもしれません。

hideki0515
2020/06/15
金融・不動産・建設 建設・土木 関連職 課長・主任・係長・マネージャ

プログラミングの開発も、他の仕事と同じくコミニケーションが重要なことが良くわかりました。

akagi1139
2020/06/15
メーカー マーケティング その他

プログラミングを体験することでコミュニケーションがとりやすくなるのですね

saze2020
2020/06/14
メーカー 人事・労務・法務 その他

本テーマはプログラミング開発に限らず、その他多くの商品の開発に共通する気づきがあります。発注側、受注側と立場は異なりますが共同で作り上げる作業だと理解し、受注側が下請けのマインドポジションではなく、お互い高いゴールを目指す信頼関係は何か、契約以外の影響要因が成功の鍵になる事実は、体験しないと気づきにくです。

yuka_ogi
2020/06/12
医薬・医療・バイオ・メディカル 人事・労務・法務 一般社員

エンジニアとのコミュニケーションだけではなく他ベンダーとのやりとりにも活用できそうな内容であった。

kazuma_0112
2020/06/11
金融・不動産・建設 コンサルタント 課長・主任・係長・マネージャ

相手を理解して仕事をすることは、スムーズに進捗させるために重要だと認識しました

mnakashima
2020/06/11
メーカー メーカー技術・研究・開発 その他

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

isaokawahara
2020/06/11
商社・流通・小売・サービス 人事・労務・法務 部長・ディレクター

20から30代のころは、人事給与システムで発注者としての業務を数多く行っていたので、内容的には非常に共感できる。

ryosexy2
2020/06/10
商社・流通・小売・サービス 営業 一般社員

商談段階では、画面設計イメージと要件定義イメージとあったが、要件定義の用意はエンジニア側へ伝えるにあたって当然だと思っていたが、画面設計までは考えが及ばなかった。実際には難しいと思った。
開発段階ではデザイナーの存在、運用段階では緊急時の想定がポイントになってくると思う。
いずれにしても、エンジニア側と誤差少なく開発していくには、プログラミングの勉強は誰でも少しはしなくてはいけないと思う。

koadin
2020/06/10
メーカー メーカー技術・研究・開発 一般社員

エンジニアへの歩み寄り、というのは、他の場面でも大切なことだと
感じました。

kanosan2192
2020/06/10
商社・流通・小売・サービス 営業 部長・ディレクター

コンピューターのシステムエンジニアと一般の人達とは、実質的に話す言語が違うくらい仕事の内容に対する理解が異なる分野。殆ど違う言語を話しているに等しい。商談段階での会話も実質的に意思疎通が成立していない印象。

spirytus3
2020/06/09
メーカー 経理・財務 一般社員

外部のエンジニアに発注する機会はありませんが、社内の開発部門に案件を依頼することはあります。その場合でも受注者の立場にたった視点も考慮して仕事を進めたいと思います。

emerald
2020/06/07
メーカー 資材・購買・物流 一般社員

「ちょっとした修正」が大変だったり、エンジニアの方の苦労は理解できますが、この動画については違和感がありました。
エンジニアを守るための講義?という感じがしました。
開発フェーズで「エンジニアとデザイナーの分業体制を知る」って遅すぎのでは?
通常、個人との契約なのか会社との契約なのかわかりませんが、会社の代表として商談しているのなら、社内でデザインのことも解決するべきなのでは?と疑問に思いました。
そもそもこういうところから理解不足なんでしょうね・・・

taka_4211
2020/06/05
金融・不動産・建設 専門職 一般社員

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

oge
2020/06/03
インフラ・公共・その他 経理・財務 一般社員

商談段階で画面イメージなどをなるべく具体的に共有すること、最低限のゴールを明確にすること
開発段階でなるべくエンジニアに歩み寄ること
運用段階で緊急時の対応を別途準備しておくこと
日頃からプログラミングを体験してその大変さを理解しておく
など、とても大切な点をいくつも学ぶことができた。

k164
2020/06/02
IT・インターネット・ゲーム・通信 資材・購買・物流 一般社員

認識にずれが生じないよう注意して打ち合わせをすすめていかなかればと思いましたが、発注者だけでなくエンジニアからの歩みよりもかなり大切なのではないかと思いました。

akira_okano
2020/05/30
メーカー メーカー技術・研究・開発 その他

発注側として、画面設計イメージと要件定義を書いてみる、というのは大変参考になりました。

s200068
2020/05/29
メーカー 専門職 一般社員

エンジニアと非エンジニアのすれ違いが発生するメカニズムとそれを防止する考え方は、大変勉強になりました。

yag
2020/05/28
IT・インターネット・ゲーム・通信 IT・WEB・エンジニア 一般社員

結局双方の歩み寄りかなと。
自分はエンジニア側ですが、ユーザが期待するものを提示する・アプリやシステムの大事なところを理解してもらう努力、できるだけ難しい言葉を使わないということに尽きるかなと。

shinji342
2020/05/27
医薬・医療・バイオ・メディカル IT・WEB・エンジニア 課長・主任・係長・マネージャ

確かにあたりまえのようだが、大事な話だとおもいました。

g_y_s
2020/05/25
メーカー マーケティング 一般社員

業務で活用するには、要求仕様を具体的かつ明確にする必要があると感じました。あと、費用範囲と仕様範囲、開発期間とリソースの兼ね合いも十分に検討しないと後々取返しが付かなくなる可能性があるため、都度確認しながら進める必要があると認識しました。
かと言って、開発側の提示した見積もりや期間を鵜呑みするのではなく、こちら側も理解した上で交渉する事がより良い開発に繋がると考えています。

m-yano
2020/05/25
広告・マスコミ・エンターテインメント その他 一般社員

非エンジニアの自分たちの価値観ではなく相手に訪ねてみることも重要だと感じた。

reviewforfuture
2020/05/25
金融・不動産・建設 経営・経営企画 経営者・役員

参考になったと思う。

mietama
2020/05/21
広告・マスコミ・エンターテインメント クリエイティブ 一般社員

ネット上でコンテンツを展開するにあたり、
依頼する和たちが簡単だと思うことが、実際に開発するにあたっては
非常に難しいことだということは多々ありました。

要件定義書を難しく考えていましたが、何をどういう風にやりたいか を
普通の言葉で書いて、リスト化することでいいということがわかったことがよかったです。今後に生かせます。

pon16
2020/05/19
金融・不動産・建設 経営・経営企画 一般社員

大変勉強になった。
エンジニアへの発注機会はないものの、自身でVBAを書いて部内のシステムを構築することが多く、ユーザー側の要望との擦り合わせに苦労する。
またそういったスキルについて「教えてもらえば」できると勘違いしている人、スキルを持っているのは特別な人だとはなから努力しない人がほとんどで講師がインタビューで言っていた「情報の非対称性」とはまさしくこのことだと考えさせられた。エンジニアでなくてもものを作り上げてマニュアルを作り、リリースしその後のメンテナンスまで非常に長い時間と試行錯誤の工程があり、そこへの歩み寄りは当然のマナーであると改めて感じた。

yuriyuri525
2020/05/18
商社・流通・小売・サービス 専門職 一般社員

私自身は発注者側を経験しているのですが、商談・開発・運用の3つのフェーズでよりスムーズに修正を少なく進める上で、エンジニア側に伝わりやすい伝え方、コミュニケーションの工夫が必要であり、定期的に認識合わせをし、乖離がどんどん広がってしまわないように軌道修正しながら進めていくことの重要性を理解しました。

kenji1959
2020/05/18
インフラ・公共・その他 メーカー技術・研究・開発 その他

アプリ開発ではないが、これまでの業務も、講習の中の発注者の立場での言動に思い当たることが多くあった。今後は、気をつけるべきところは気をつけ、受注者側の立場も考えて業務に当たりたい。

gyucci
2020/05/14
金融・不動産・建設 金融・不動産 関連職 一般社員

自社のシステムが使いにくいことも正直あるが、それは発注者側の意思と受注者側の意思の認識相違が根本にあるのかなと理解できました。
システム開発は難しいイメージがありますが、発注側も勉強をして相手側の苦労を理解し歩み寄りしながら一緒に作っていけるのが良いものを作る第一歩だと感じました。

w080859
2020/05/14
インフラ・公共・その他 メーカー技術・研究・開発 一般社員

今後、似たような立場になった場合は、この講義の内容を思い出したいと思います。

yot
2020/05/14
インフラ・公共・その他 経営・経営企画 課長・主任・係長・マネージャ

受発注者間のコミュニケーションでの留意点は、システム開発に限らず大切なことだと感じました。

piyo
2020/05/12
メーカー 資材・購買・物流 課長・主任・係長・マネージャ

発注側も購入するに際し勉強が必要でしょう。何を欲しているのか同じ言語で説明し、要求することが出来るようにならないとお互いが幸せにならない。中間に営業がいて、通訳をしてくれる事が多々あるから、勉強をサボってしまう事が多いけど反省します。

lucky_3515
2020/05/10
メーカー メーカー技術・研究・開発 一般社員

「非エンジニアが~」と言っているが、情報やプログラミングに明るくないエンジニアにも非常に役に立つ(むしろ知っていなくちゃいけない)内容だと思った。私自身SEではないが、設備設計で簡単なプログラムは書くことがあり、本当に強く同意できる内容だと思う。
エンジニア側からもある程度の歩み寄りは必要と思うが、プログラミングのプの字も知らず、また勉強もしようとしない発注者と仕事をすると、イライラしてしまうことが多い。上手に自分を抑えつつ、本講義の内容を相手に伝えていけるようになりたい。

boutarou
2020/05/10
広告・マスコミ・エンターテインメント 営業 一般社員

エンジニアに限らず、受発注において起こりえるコミュニ―ションロス。
思ったのは、例えばマッチングアプリを作って、発注者側はどれだけの売上を見込み、それがどれだけの重要度があるものかを共有する事、そしてそれを実現させるプログラムがどういうものかの認識をお互いで擦り合わせておく事かなと。
作って終わり。と思われないで仕事を受けてもらうように、発注者側のプレゼンも大事そうですね。

mino0512
2020/05/09
IT・インターネット・ゲーム・通信 クリエイティブ 課長・主任・係長・マネージャ

商談フェーズでどこまで具体的に伝えるかのイメージがよく理解できた。
また、抽象的なワードで指示するのではなく、双方の認識が合致するようにしっかりと言語化した上で伝えることが重要。よく社内でも、上司がこれくらいだったらすぐできるだろうと気軽に発言するが、実際にそれを実現するためにはどういった作業が必要なのかを理解したうえで、伝えるべきだと再認識できた。

yukime
2020/05/08
商社・流通・小売・サービス 営業 課長・主任・係長・マネージャ

WebサイトやECサイトの構築など社内外問わずオーダーする際にエンジニアに寄り添う気持ち、指示を受ける側へ寄り添って最高のチームを作る!
得意書名で残すイメージを伝える、要件定義はどんだけでも細かくていい。

kajikaji11
2020/05/07
メーカー 資材・購買・物流 課長・主任・係長・マネージャ

発注者として要件定義はしているつもりではありますが、受注者がさらに2次3次に仕事を回した際に、伝言ゲームのように、思いが少しづつずれていき、デモ段階で、修正を多数要するということは、実体験でありました。
改めて定期的なすり合わせの重要性を感じました。

igaas23
2020/05/07
IT・インターネット・ゲーム・通信 営業 一般社員

コースの中で特に重要と感じたのは、
自分が体験してみること、どこまで知っておくべきか明確にしておくこと

営業はプロダクトの技術的な知識をエンジニアほど持っていないので、
どこまで知ってるのか、知っておくべきなのかを曖昧にして会話することがある
上記の状態は認識に齟齬が生まれるので、円滑に進まないことが多い

お互いがどこまで理解していて、何を知りたいのかはいつも違うと思うので、
恥を忘れて必ず確認したほうが良い。

zig
2020/05/06
金融・不動産・建設 コンサルタント 課長・主任・係長・マネージャ

素人が外部のエンジニアにプログラムを作らせようと思ったら、RFPを出す前の段階でセカンドオピニオンとしてエンジニア入れないとダメだと思う(歩み寄りとか言ってる場合ではないと思う)。

自分自身、プログラミングブートキャンプでフロントからエンドまで勉強し、素人が外部のエンジニアを使ってプロジェクトを進めるのはかなりリスキーだと痛感した。

講師が主張するように発注者が考えているよりエンジニアにとって大変な作業も多いが、その逆で既存のAPIやSaaSを上手く組み合わせれば、エンジニアの提案よりも安く充実した機能を実装できることも多いと思う。

hiromi-10
2020/05/06
商社・流通・小売・サービス 専門職 一般社員

これは何においても言えることなのですごく理解ができました。今までも受注者が良く怒ってしまい、、よく喧嘩していましたが、、、
怒る理由が少しわかった気がします。
しかし、譲れない事は譲れないとも思います。
知っているだけに歩み寄れない事も、出てきますよね。

もう少し柔軟に、仕事を円滑にしていくために、日々の仕事に活かして「歩み寄り」していきます。

xanadue
2020/05/05
メーカー メーカー技術・研究・開発 課長・主任・係長・マネージャ

過去にシステム開発を発注したときに苦労したことを思い出しました。
元々手でやっていたことをシステム化するものだったので仕様はある程度
エンジニアにも理解してもらい易かったのですが、手でやる際に
自由度が高かった点をどこまでシステム上は限定するのか、また
システム化したときのデータ容量や反応速度についての要望が
はっきりしないまま進めたために、使われないシステムとなってしまいました。
今後システム開発をエンジニアに発注する際に要件定義をしっかりしたいと思います。

k_m_1623
2020/05/05
IT・インターネット・ゲーム・通信 IT・WEB・エンジニア 課長・主任・係長・マネージャ

自分は受注者側が主。大企業相手でも、システム構築PJの経験がない人はいまだに多く、そこから認識合わせが必要か、と思わされることが多い。受注者からも歩み寄りを行い、PJ通して啓蒙活動を行う必要があると感じた。

getting-better
2020/05/05
医薬・医療・バイオ・メディカル 営業 課長・主任・係長・マネージャ

相手の立場を理解してコミュニケーションを取るという基本的なことを意識して、エンジニアと接することが必要という事が分かった。

ryu-777
2020/05/04
コンサルティング・専門サービス コンサルタント 一般社員

仕事柄、エンジニアの人と接する機会が多いので受講しました!
相手に配慮して接することは、重要だと思いました!
まずは、プログラミングを自身で体験したいと思います!

hihiyama
2020/05/03
IT・インターネット・ゲーム・通信 IT・WEB・エンジニア 一般社員

今まで受注者側の勉強を中心にしてきていたので、視点を変えられたのは良かったです。

また、同じITエンジニアでもシステム開発の経験がないと、動画の受注者側になりかねないなと感じました(課内でのみ使うツールに、後出しでデザイン性求められたりすることがあるので…)。

toshi1048
2020/05/02
商社・流通・小売・サービス 営業 部長・ディレクター

エンジニアとの深いコミュニケーションが非常に重要と理解しました。自分自身もプログラミングにチャレンジしてみたいと感じました。

yys0ra
2020/05/02
金融・不動産・建設 IT・WEB・エンジニア 一般社員

発注者と受注者お互いが気持ちよく働けるには双方の歩み寄りコミュニケーション理解が必要だと改めて痛感した。
自身も受注者から発注者の立場になったがが、抜本的解決には上の方の教育、また納得させるうえでの自身のレベルアップが必要不可欠と最近つくづく実感しています。

senonikh
2020/05/01
広告・マスコミ・エンターテインメント 営業 部長・ディレクター

何か新しい自社サービスを開発してみたいと思いました。

matcho
2020/05/01
メーカー マーケティング 一般社員

エンジニア側への歩み寄りを行うことと、仕事理解を深めようと強く感じた。

pdpit
2020/04/30
メーカー メーカー技術・研究・開発 課長・主任・係長・マネージャ

システム開発の発注時の開発側、依頼側の具体的な事例でしたが、それぞれの懸念事項の例がよく分かりました。
このことはどの仕事でもあてはまることで、まずはお互いをのことを知り、互いを尊重し、Win-Winを目指すことが大事ですね。

sobc9296
2020/04/27
IT・インターネット・ゲーム・通信 人事・労務・法務 課長・主任・係長・マネージャ

エンジニア側の心理がよく分かりました。非エンジニアである発注者にとって、エンジニア目線での説明は難しく、その為コミュニケーション不足に陥る懸念を感じた経験があります。工数管理や開発ロジックの積上げなど、開発者目線を知ることで今後の商談にも役立てることができそうです。

kitakuma_8315
2020/04/24
メーカー メーカー技術・研究・開発 課長・主任・係長・マネージャ

非エンジニアとエンジニア、発注者と受注者のみならず、相互の理解を曖昧にせず、相互の認識・理解を一致させておくことは、ビジネスの基本だと思う。

yusahero
2020/04/22
商社・流通・小売・サービス 経営・経営企画 一般社員

今後業務でエンジニアの方にお願いすることが多々あると思うので、講座にあったような、発注者と受注者側の間の意識のギャップは必ず起こるものと認識しておこうと思います。そのことを踏まえて、どのパートナーを相手にする場合でも言えることですが、常に相手をリスペクトして言動、行動を考えていこうと思います。

penguinqueen
2020/04/21
金融・不動産・建設 その他 課長・主任・係長・マネージャ

社内でも、発注における仕様の確定や、後から変更しないことの研修があり、発注する際に、プログラム開発について理解していないと難しいということを痛感していました。一歩理解が進みましたが、さらにプログラミングについて学ぶことが必要であると考えます。

ruimasiko
2020/04/21
インフラ・公共・その他 その他 一般社員

システムの発注、運用の難しさを感じた。システム開発には、まず自分がプログラミングを経験する必要があるかもしれないと思った。他社でのシステム開発、導入事例なども、興味があります。

naoya69402
2020/04/18
メーカー 経営・経営企画 一般社員

工数って何だよ、いいからやれよ!
と怒ってしまうことはよくないことだと思いました。

ogawakazuhiko
2020/04/18
医薬・医療・バイオ・メディカル マーケティング 課長・主任・係長・マネージャ

ホームページの発注などの経験がありますが、まあほぼクリアされていたのではないかとおもいます。とにかくわからないことを丸投げせずに、関わっていくように致します。

yoko1013
2020/04/17
コンサルティング・専門サービス コンサルタント 一般社員

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

makemyday
2020/04/16
商社・流通・小売・サービス マーケティング 課長・主任・係長・マネージャ

とても面白かったです。
商談フェーズ、開発フェーズ、運用フェーズで、発注者としての自分自身は「ちゃんと仕事をしているつもり」で、相手方に伝えていること。
それがエンジニア側と、逆に溝を深めていることになる。
振り返ってみると、自分自身でも経験ありです。

発注にあたっては実際に「自分もその開発に携わる想像をしてみる。」どんなビジネスでも相手側の立場に立つことは基本かと思いますが、この領域でも正にそうですね。

makahi
2020/04/13
インフラ・公共・その他 建設・土木 関連職 一般社員

相手を思いやること、自分視点にならないこと、など
チームで仕事するときに忘れてはいけないことは同じなんだと思った。
また、分からないことは、素直に分からない・教えてくださいという
姿勢も忘れないようにします。

beg0339
2020/04/13
商社・流通・小売・サービス マーケティング 一般社員

昔、システム保守業者との会話がかみ合わなかったことがよくあったのですが、「こういうことだったのか!」と腹落ちしました。

user-246d30f51b
2020/04/12
メーカー マーケティング その他

一昨年、Azure/Power BI のシステム開発を発注する立場だったときにこの講座を受講していればもう少し開発の方々に寄り添った進め方ができていたかもしれない。後悔先に立たずです。

ymgt-3
2020/04/11
医薬・医療・バイオ・メディカル 経営・経営企画 課長・主任・係長・マネージャ

最近新しいシステム導入の担当となったので非常に参考になった。

dfzf07
2020/04/07
医薬・医療・バイオ・メディカル マーケティング 部長・ディレクター

今現在は発注者になることはないのですが、数年前はシステム設計とはどんなことなのか全く分からずSEの方との会話に苦労しました。娘がこの春からSEとして働くのでコミュニケーションの大切さを伝えてあげようと思います。

masamasa16
2020/04/07
メーカー 専門職 課長・主任・係長・マネージャ

自業務はエンジニアに属しますが、非エンジニアの方々に分かりやすく説明しお互いに歩み寄る努力をする必要があると感じました。

dragon_f
2020/04/07
メーカー メーカー技術・研究・開発 課長・主任・係長・マネージャ

相手の仕事に対する思いやりはどこでも大事ですね。
イメージをどこまで具体化できるか、将来まで見越した要件を明確にしておくこと、を実践したい。

ori_k
2020/04/07
IT・インターネット・ゲーム・通信 その他 課長・主任・係長・マネージャ

実際にギャップを感じていたが、具体的に整理してもらえると納得感がでてくる

hishii0225
2020/04/04
IT・インターネット・ゲーム・通信 IT・WEB・エンジニア 課長・主任・係長・マネージャ

普段の業務にそのまま活用ができると考えました。非エンジニア向けの講習でしたのが、私はエンジニアなので、非エンジニア・発注者が困りやすい状況や陥りやすい罠に落ちないように逆にリードするためにはという観点が養われました。動画内では、エンジニアに寄り添うというのがポイントとありましたが、私はエンジニアの立場として、良いエンジニアもまた発注者の立場に寄り添って考えられる人である考えています。お互いプロの領域は信頼して任されるべきであり、プロジェクト全体のリスクや優先度付けは早めにアラート洗い出し共に対策を考え丸投げせず有限のリソース内で適切に対処していく必要があると考えます。エンジニアとしては、非エンジニア、発注者が困りやすい点を意識したコミュニケーションや、後でどちらか一方が不幸にならないよう、契約や見積もり職掌をちゃんとするなど、必要な業務プロセスの品質向上に本コンテンツが役立つと考えました。

manabiyako
2020/03/30
商社・流通・小売・サービス 人事・労務・法務 課長・主任・係長・マネージャ

エンジニアの気持ちや価値観を理解する事は大事だなと思いました。
コミュニケーションを取る上で、エンジニアに直接何を知っておけばいいか・どこまで知っておけばいいかを直接聞くのが有効だと感じました。

take_chan
2020/03/29
メーカー 販売・サービス・事務 一般社員

エンジニアの方にお願いする場合は、言葉だけでなく形で完成イメージを伝えるようにすることは非エンジニアにもできるし、そのように努めていかないといけないと感じました。

dapan
2020/03/27
IT・インターネット・ゲーム・通信 IT・WEB・エンジニア 一般社員

エンジニアです。発注者視点の参考にと思い視聴しました。
基本はエンジニアからの歩み寄りだと思っているのです(難しい話をわかるように伝えることや、要求仕様をいかに引き出すかが腕の見せ所なので)が、発注者側からも歩み寄っていただけるとコミュニケーションしやすくなると思うのでありがたい提案です。
お話の中であったように、実現したいことの確認のために見せたデモで、機能ではなくデザインへの指摘をまっさきにされるのは、たしかに凹みます。ただ、それはエンジニアのプライドではなく、デモの目的が伝わらないんだなというガッカリです。
例に出てくる発注者もエンジニアも極端な例でしょうが、一般にはエンジニアはこういう話をすると思われているということなのでしょうね・・。

j-u-n
2020/03/25
インフラ・公共・その他 専門職 一般社員

使用者の要望を聴き、相互に話して、求められているプログラムを作る。

sho_0221
2020/03/22
コンサルティング・専門サービス コンサルタント 課長・主任・係長・マネージャ

発注者の立場です。VBAですが、実際に学んだことがあります。初級中の初級ではあると思いますが、一つ修正するだけでも苦戦するので、高度なものであれば工数はかなりかかると知りまさした。
なんでもいいので、まずは受注者側について実際学ぶことは大切だと実感しました。

masuyasumaya
2020/03/11
医薬・医療・バイオ・メディカル 営業 一般社員

自分の専門分野以外の方とコミュニケーションを良くしていくためには「歩み寄り」が必要と感じました。

masarukanno
2020/02/27
金融・不動産・建設 マーケティング 課長・主任・係長・マネージャ

相手の立場で考える視点は、エンジニアの方以外でも必要と分かっていてもついつい自分の立場を主張しがちです。より良い協力関係、成果を生み出す為に相手の立場視点によりフォーカスしなければならない事を再認識出来ました。

mitetsu
2020/02/24
メーカー メーカー技術・研究・開発 課長・主任・係長・マネージャ

システムエンジニアの仕事の進め方を知る事ができ、発注者としてコミュニケーションを取る際に活用できる。

kinu0404
2020/02/24
IT・インターネット・ゲーム・通信 営業 課長・主任・係長・マネージャ

共通の目標、ゴール設定、マイルストーンの設定を持ち、外部から見てもわかるような共通言語でのシンプルなドキュメント化が両者に必要。

shusaku_h
2020/02/23
商社・流通・小売・サービス その他 課長・主任・係長・マネージャ

エンジニアに限らないことだと思う。相手の見積内容のベースと、自分たちの発注内容のベースのすり合わせは、互いの用語のすり合わせを丁寧に行いつつ、慎重に進めたい。

hirohey
2020/01/29
商社・流通・小売・サービス 営業 部長・ディレクター

プロジェクトをしっかり進めるためにも件定義にて双方で内容を合意しておくこと。予算、スケジュール、目的、達成したい優先順位、また保守運用についても忘れず計画する必要ある。

koyakoya
2020/01/28
メーカー メーカー技術・研究・開発 課長・主任・係長・マネージャ

外注でなく、社内のエンジニアに対しても同様の対応が必要ですね。過去にデータ解析ツールを作った時は、解析手法よりもインターフェースに注目してしまい、エンジニアのモチベーションは地におちました。反省です。

take_32r
2020/01/22
メーカー IT・WEB・エンジニア 課長・主任・係長・マネージャ

業者に発注する際、見積の相場などでいつも困っていたが、そもそも自分自身が何かしらの体験をして、基準を持つことが大切だなと思った。しかし、見積の妥当性の見極めについては講義の中でこたえがなかった印象なので少し残念でした。

yoshiaki2019
2020/01/20
金融・不動産・建設 マーケティング 課長・主任・係長・マネージャ

小さな開発に対しても具体的な発注が大事だと学んだ。社内、業務委託に関わらず、発注者はイメージを持った会話をしていきたい。

ka_ke
2020/01/17
IT・インターネット・ゲーム・通信 販売・サービス・事務 一般社員

自分も非エンジニアですが、周りにはエンジニアがたくさんいます。
直接開発案件の発注に携わることはないですが、見積書などの書類を見ることはあるので少しは知識を身につけようと思いました。

jc61grom
2020/01/13
メーカー 営業 部長・ディレクター

最近 会社のホームページを外部委託する事になり発注者側の立場でエンジニアと打ち合わせを経験しました、機械工具を使って作業する分野であれば 大体の工数はイメージできるのですが 今回の講義の通りIT系の工数はイメージがしづらく 適正な価格もわからないことが実情です、理解するため実際の作業を見る必要を感じました。

mune1971
2019/12/26
メーカー マーケティング 一般社員

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

kyabetsu-taro
2019/12/17
広告・マスコミ・エンターテインメント 経営・経営企画 一般社員

発注という行為を、軽く考えていたと、痛感しました。
とはいえ、経験、場数も必要だと思いますし…。
アプリに限らず、発注に限らず、常に、相手の立場になること、思いやることは、相手のためのみならず、自分のためにも必要だと思いました。

kurokurokuro
2019/12/09
メーカー 営業 課長・主任・係長・マネージャ

エンジニアへの歩み寄りは意外でした。
発注者のみならず、受注者も、歩み寄りながら、限られた予算の中で、優先順位を決め、手戻りをなくすために、どうすべきかを考えるのが理想と思いました。

sekiryo
2019/12/07
コンサルティング・専門サービス 営業 一般社員

191207 非エンジニアが持つべき発注者視点
3段階で齟齬をなくす/発注者/開発/運用

①商談フェーズ
◆発注者
1、頼んだら必ず完成品ができるだろう(金額満額)
2、ちょっとした修正をしたい(修正は最初に話した金額だと思っている)
  →修正は数十万かかる。追加料金として請求するよ。

◆受注者
1、必要最低限を作ろう。(最低金額を創造)
2、修正は金額がかかるよ。
  →修正は数十万かかる。追加料金として請求するよ。

◆この齟齬をなくす方法
①画面の設計画面を整理。何画面必要か。どのように整理していくべきなのか、完成度は
②要件定期:文章や画面で定義。どのような大きさなのかなど詳細に伝えるべし。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

②開発フェーズ
◆発注者
1、デモをみせてもらわないとわからない
  とにかくエンジニアに細かく指摘をするようになってしまう

◆受注者
考えやこだわりを理解してもらいたい
追加事項を言われないようにドキュメントも提示

◆齟齬をなくす方法
①仕事の進め方と価値観を知る
②エンジニアとデザイナーの分業体制を知る

ーーーーーーーーーーーーーーーーーーーーーーーーーーーー
③運用フェーズ
◆発注者
1、ここで修正を言わないとなおらないからな
2、運用維持費や緊急時の対応が不安

◆受注者
1、一つ変えてと言われても時間がかかる。
2、保守をやるなら違う人にやってほしい。保守担当を非雇用でもいいから休め。

◆齟齬をなくす方法
1、緊急時を想定してあらかじめ雇用や契約を進める
2、本番リリースするための最小限の単位を決めておく

keta_y123
2019/11/30
IT・インターネット・ゲーム・通信 IT・WEB・エンジニア 課長・主任・係長・マネージャ

良好なコミュニケーションが大切で、取引先の立場でも考えられるように心がけようと思う。

ko0822
2019/11/29
商社・流通・小売・サービス 経理・財務 一般社員

発注側として、エンジニアへの歩み寄りが大事。要件とともに、発注側とエンジニアの役割分担を詳細に握っておくことが重要。また、運用フェーズでの必要な雇用と契約の検討も事前に。

mur
2019/11/18
メーカー 販売・サービス・事務 部長・ディレクター

エンジニアの視点や開発という仕事の進め方を知る「あゆみより」の必要性を理解。イメージや方向性をベースにする発注者とそれを具体的に論理的に展開・構築するエンジニアの隔たりは知識不足・伝達不足から発生する。

hirotomf
2019/11/05
インフラ・公共・その他 その他 部長・ディレクター

大変、勉強になりました。

runner_masa
2019/11/05
メーカー 経理・財務 課長・主任・係長・マネージャ

現業では発注者になりうる川ではあるが、セールス業務の省力化をするときには、受注者になる側面もあり、双方の立場を知っていたが、今回のような学びをすると、役割に応じた対応がとても重要だと感じます。

knhk
2019/11/03
メーカー 営業 課長・主任・係長・マネージャ

 マーケットから知りえた情報、ニーズをエンジニアにいかにして伝え形にできるか、情報の伝え方次第で、後のレスポンスにも影響を及ぼすことを改めて理解した。

tak5123
2019/11/03
金融・不動産・建設 販売・サービス・事務 課長・主任・係長・マネージャ

普段、エンジニアの方と直接話すことはないのですが、作る側の立場に立って最終的にどうなっていればよいのかのイメージを上手に伝えなければいけないことがよくわかりました。デザインやアクション、レスポンスタイム、結果が出るまでのステップなど、こちらで要求すべきことが何なのかを知っていることも大事なのだと思いました。

hacco
2019/11/01
金融・不動産・建設 マーケティング 課長・主任・係長・マネージャ

身につまされる。相手の状況を想像すること。仕事として当然。

user-201907
2019/10/12
商社・流通・小売・サービス 経営・経営企画 課長・主任・係長・マネージャ

新しい分野の仕事にあたる場合は、その中身をわかっていないと先方(エンジニア、取引先)と話が合わないのは、当然だと思う。IT関係の新しい技術は、画面での見栄えや評判で簡単そうに感じる部分もあるので、開発するときの苦労はなかなか想像しにくい。
自分も、プログラミングを少し学んでみようと思った。

taka-1115-75
2019/10/08
金融・不動産・建設 経理・財務 課長・主任・係長・マネージャ

自前で出来ないことを、外部に発注するのに、とかく偉そうにする人が、シニアに多い。もっと、自ら学ぶべき。

m1111
2019/09/08
インフラ・公共・その他 その他 一般社員

見積りや要件定義の内容についてはいつも問題になります。
エンジニアの作業を理解し、発注できればと思います。

watta45
2019/08/31
金融・不動産・建設 営業 課長・主任・係長・マネージャ

すべての業界でソフトウェア開発現場の理解が求められる今、非エンジニアの立場でありながらエンジニアとのコミュニケーションスキルを身に着けることは非常に重要なスキルと経験から思います。

misy
2019/08/29
金融・不動産・建設 金融・不動産 関連職 課長・主任・係長・マネージャ

発注者、受注者それぞれの意思疎通が難しいことが理解できた。

ui_imaiti
2019/08/29
インフラ・公共・その他 その他 一般社員

発注者がプログラミングを経験して、エンジニアの苦労を知るというのは、なかなか奥が深いです。発注者も広い意味での技術が分からないと、コスト、納期、品質、信頼性、拡張性、セキュリティなど考慮した発注ができません。
現実に、〇Payの様なシステムがリリースされています。

popo163
2019/08/27
金融・不動産・建設 金融・不動産 関連職 部長・ディレクター

どの業務であっても相互理解や成果物イメージ合わせは必要であり、それをどこまで自分事化できるか、想像力も必要と理解した。

doppon4510
2019/08/19
金融・不動産・建設 営業 課長・主任・係長・マネージャ

エンジニアの立場を踏まえた上で、意思疎通に齟齬を起こさない歩み寄りが大事だと感じました。

red_pine
2019/08/17
IT・インターネット・ゲーム・通信 メーカー技術・研究・開発 一般社員

フェーズごとに具体的に考えておくことがあることが分かった。自分が発注する場合には注意したいと思った。

nms_3523
2019/08/17
インフラ・公共・その他 専門職 一般社員

今後、IT技術はさらなる進化・発展を見せ、その中でエンジニアの方との関わりもより深化していくものと考えている。本講義における「非エンジニアのエンジニアとの関わり」は、両者がより密に、かつ有意義なコミュニケーションをとるために重要な知見であり、これからもよりその知見を深めていく必要があると感じた。

m_1989
2019/08/08
メーカー IT・WEB・エンジニア 一般社員

エンジニア側の人間として本講義を受けました。発注者側が何を思っているのか、何が分かっていないのかを知るためです。
エンジニア側ももちろん歩み寄りが必要だと感じました。

matt_iz7i
2019/08/07
金融・不動産・建設 IT・WEB・エンジニア 部長・ディレクター

発注者側ですが、講師の方が
おっしゃることは経験上ごもっともなことばかりでした。改めて整理でき今後に活かしたいと思った。

yuuu
2019/08/04
金融・不動産・建設 営業 課長・主任・係長・マネージャ

商品開発やデータ抽出依頼の際の注意点や視点がよく理解できた

hiro1234
2019/08/02
金融・不動産・建設 販売・サービス・事務 一般社員

実際に業務でエンジニアに依頼しています。エンジニアとのコミュニケーションを円滑にするために、実際にプログラミングで書いてみました。大変でしたが、エンジニアとのコミュニケーションにおけるポイントがつかみやすく、作業イメージも沸くようになり、業務がやりやすくなりました。

hatamoto_kohei
2019/07/26
メーカー メーカー技術・研究・開発 課長・主任・係長・マネージャ

私自身、Softwareエンジニアではないエンジニアですが、よくある事例で懸念点を再認識しました。また、Softwareは他のエンジニアとは違い出発点のコンセプトが違うだけで、運用方法、メンテナンスに多大な影響を与えるということが印象的でした。

ryo-83873
2019/07/23
商社・流通・小売・サービス 販売・サービス・事務 一般社員

思い当たる事が多々ありました。
どちらも自分の都合良く解釈してしまう。
まず、全体像を作って細かく具体的に仕様を決めていけると思いました。

miho1967
2019/07/14
コンサルティング・専門サービス コンサルタント 課長・主任・係長・マネージャ

プログラミングを学びたいと思いました。

federer
2019/07/11
金融・不動産・建設 IT・WEB・エンジニア 一般社員

経験者なので、お話はよく腹落ちしました。

aquitos
2019/07/10
コンサルティング・専門サービス 人事・労務・法務 課長・主任・係長・マネージャ

今まさにエンジニアとやりとりをしているので、それに役立つ気づきが非常に沢山あった。

n-mtmy
2019/07/09
メーカー 資材・購買・物流 課長・主任・係長・マネージャ

発注者としてプログラミングのプロセスについて
理解する事や自分たちの要求する事を可視化したり
より具体的に提示する事で相互理解を深め進めることが
重要だとわかった

hashizou
2019/07/05
広告・マスコミ・エンターテインメント クリエイティブ 部長・ディレクター

分かりやすく、整理がつきました。

yuki_0709
2019/07/01
コンサルティング・専門サービス コンサルタント 一般社員

発注者・エンジニア双方の言い分、どちらも良くわかるものでした。
発注者はドキュメントの読み方が分からないのであれば、発注者はその場で聞くべきでしたし、
エンジニアは開発の知見のない人間にデモを提示するとデザインにフォーカスされてしまうことは経験則として知っているはずなので、メインの作業(この場合はマッチングの機能開発)が終わるまでデモは見せないという作戦をとっても良かったのではないでしょうか。
発注者にPMOの能力がないのであれば、いきなりエンジニアに直接発注ではなく、PMOも雇っても良かったのではないかと思いました。

aki7
2019/06/26
インフラ・公共・その他 その他 一般社員

大体の話を聞いたら、発注者の側に、このような組織があったら良い、、とアドバイスができるくらいのスキルが、エンジニアの方にもあった方がいいのかな、

ojizo
2019/06/23
メーカー その他 一般社員

発注する側に開発経験などがない場合の事例として参考になりました。

tsunemi
2019/06/22
医薬・医療・バイオ・メディカル メーカー技術・研究・開発 課長・主任・係長・マネージャ

エンジニアの仕事のすすめ方を理解することが大事と思った。

yukiko_0709
2019/06/20
コンサルティング・専門サービス コンサルタント 一般社員

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

shin923
2019/06/17
金融・不動産・建設 マーケティング 課長・主任・係長・マネージャ

売り手と買い手の情報格差のようにエンジニアと発注者の格差があるのだと理解しました

hiroya14
2019/06/10
金融・不動産・建設 IT・WEB・エンジニア 一般社員

発注者として、受注者側に歩み寄りが必要だと理解した。

a-nya
2019/06/08
メーカー 販売・サービス・事務 一般社員

わたしは今まで開発者視点に歩み寄れていただろうか?
プログラムを理解しようとプログラムを学んだこともあったが、難しさに触れて苦手モードに。小さな動作を自動化するのに、プログラムをかくとこんなに大変なんだなって実体験として学んだ。
小さな自動化であくせくするのに、複雑な自動化なら尚更大変な修正になるのだなと意識がかわりました。

yamato2016
2019/06/07
コンサルティング・専門サービス コンサルタント 一般社員

発注者側と受注者側の事前のコミュニケーションの
大切さを認識できた。
お互いの立場や考えを把握したうえで、仕事を進めていく
いくことが、成功への近道だと思う。

taragon_02
2019/06/06
金融・不動産・建設 建設・土木 関連職 課長・主任・係長・マネージャ

いつも見積もりが一式計上で適正価格なのか疑問を持っていました。プロセス、工数をよく聞いて、納得した上で発注したいと思います。

takeshiketa
2019/06/05
金融・不動産・建設 販売・サービス・事務 一般社員

キーワードは、相互コミュニケーションかな。エンジニアという職種に限らず、「一緒に仕事をする」という観点から見ると、他の組織の人間(個人であっても)であれば、その相手の仕事に対してリスペクトして臨む、という基本的な姿勢を持つことから始めたい。

casbar33
2019/06/03
金融・不動産・建設 販売・サービス・事務 部長・ディレクター

エンジニアという相手の立場を理解し、ビジネス・パートナーとして尊重する視点が必要である、という点を学びました。

yae
2019/06/03
商社・流通・小売・サービス 営業 課長・主任・係長・マネージャ

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

bibizu1217
2019/06/02
メーカー メーカー技術・研究・開発 課長・主任・係長・マネージャ

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