ネットワークが接続されていません
ikawamariko
2019/05/26
コンサルティング・専門サービス コンサルタント 課長・主任・係長・マネージャ

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

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

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

zhenjizi
2019/02/17
IT・インターネット・ゲーム・通信 マーケティング 部長・ディレクター

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

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

tsh
2021/02/08
商社・流通・小売・サービス 営業 一般社員

エンジニアに対する姿勢だけにとどまらないが、たとえ発注者・顧客サイドであったとしても、相手の立場を理解し寄り添った対応をすることは必要であるとは思う。
しかし、今回の口座では、「エンジにはは嫌になってしまう」「エンジニアの気分を害する」といった、エンジニア本位の表現が目立ち、なぜ顧客サイドがそこまでエンジニアに気を使わなければならないのか、何様なのかと感じた。

エンジニアと発注者の意思疎通の祖語が発生し、それが発注者の心がけ次第だ、というのであれば、逆にエンジニアについても発注者が何を考え・欲しているかに寄り添い、必要な意識・情報の擦りあわせを提案する必要はないのだろうか。医者や弁護士といった高い専門スキルを持った人材でも、最終的な売上や実績を左右するのは営業力であるわけで、エンジニアにしても技術力だけではなく、それはベースとして対人折衝力・営業力が必要なのではないだろうか、と感じた。

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

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

pukai
2021/01/09
メーカー 人事・労務・法務 一般社員

システム発注に限らず、もし自分が詳しくない分野の業者と仕事を進めていく上で、その分野の言葉などを勉強していく事が相手にとっても、そして自社にとっても大切だと感じました。

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

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

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

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

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

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

shaftesbury
2021/08/21
金融・不動産・建設 専門職 一般社員

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

g_im
2021/03/24
商社・流通・小売・サービス クリエイティブ 一般社員

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

kameco
2020/08/12
広告・マスコミ・エンターテインメント 販売・サービス・事務 一般社員

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

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

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

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

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

kobo0804
2021/09/20
IT・インターネット・ゲーム・通信 IT・WEB・エンジニア 一般社員

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

tsu_watanabe
2021/08/23
IT・インターネット・ゲーム・通信 IT・WEB・エンジニア 一般社員

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

taka0001
2021/08/03
商社・流通・小売・サービス 販売・サービス・事務 部長・ディレクター

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

hiro_yoshioka
2021/07/20
メーカー メーカー技術・研究・開発 一般社員

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

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

kbdy555
2021/03/21
金融・不動産・建設 金融・不動産 関連職 課長・主任・係長・マネージャ

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

xg_w_120mpw
2021/10/21
メーカー メーカー技術・研究・開発 課長・主任・係長・マネージャ

受注者発注者の思考や行動において、それぞれの特徴がわかりやすく、非常に今後の参考になる。
ものづくりに置き換えれば、開発側と生産側との関係も似てるように思う。お互い歩み寄り、少しでも多く理解し合うことが、幸せに仕事できるコツだと、講師が仰る通りである

elev
2021/10/20
メーカー その他 一般社員

相手の立場に立って仕事を進める。

sohmura123
2021/10/19
メーカー 経営・経営企画 部長・ディレクター

本講義での内容はエンジニアリングか非エンジニアリングに関係なく、ビジネスを進めていくにあたっては基本的なことである。

hideki_1968
2021/10/18
メーカー メーカー技術・研究・開発 課長・主任・係長・マネージャ

今回の講義は直接的に自分の業務に結びつかなかったが、分野、スキルの異なる両者のビジネスコミュニケーションにおいて、相手の考え方、大事にしている価値観を理解して業務を進めることが重要と感じた。

yasusi_21
2021/10/17
メーカー その他 一般社員

エンジニアへの発注は本当に難しい。
なるべく具体的な実例を示して認識を共有する様にしているが、実物を見ることができるものでもないし、良い方法を常に模索している様な気がする。お互いに。

hina1234
2021/10/17
メーカー 営業 一般社員

外部委託などは、仕事を進めるうえで相手の仕事を理解しておくことはより重要だと感じた。

toshi148
2021/10/17
メーカー メーカー技術・研究・開発 部長・ディレクター

自身がプログラミングを全く経験したことがないので、講師のお話を聞きながら新たな視点、着眼点に気が付きました。

newone
2021/10/17
メーカー 販売・サービス・事務 その他

エンジニアリング時の障害解決は、歩み寄り、通訳、仲裁、人をつなげる場面で活用でき、ジェネレーションギャップを埋める手法にも応用できる。

chengshang
2021/10/15
メーカー 経営・経営企画 経営者・役員

受注者、発注側どちらも相手への敬意と尊重が必要ですよね。契約書で、費用や範囲を明確にして、委託業務内容も丁寧に共有しておくことが大切です。

hide_kkm
2021/10/11
メーカー マーケティング 課長・主任・係長・マネージャ

活用できるとおもいます。

以前、アプリのようなたいそうなものではないが、ある社内向け教育マニュアルを発注したことがある。費用は100万程度だっと記憶しています。
その構図は、発注者であるBが上長Aの指図により、発注先Zへ依頼。ZはデザイナーであるYとの分担作業。

その中で最も躓いた点は、Aの意見をしっかりとYまで伝えきれなかったこと。その理由はAとBがどこがゴールであるのかということを心底握っておらず、仕事を走らせてしまったことであった。Aからの要望は中間結果を出すごとに五月雨式に出てきて、更には以前言ったことと変わることもしばしば。
まずはお互いの最終イメージとその指摘の上限を徹底的に詰めてから、発注を出すことが大切だと痛感。

tando
2021/10/10
インフラ・公共・その他 営業 課長・主任・係長・マネージャ

今、私はITとは無縁の営業の仕事をしている。
しかし、5年後、10年後の世界を想像したときに、部下からIT関係のワードや仕事について当たり前のように相談される気がする。(今の時代、パソコンを使えるのが当たり前のように)
そのときに、無防備でいる(無視する、すべて任せる)のか、少しは理解できるのかで大きな差がつくと感じている。
自分自身エンジニアになるつもりはないが、ITリテラシーを高めるため、まずは基礎から勉強しようと準備している。

taku_n
2021/10/08
広告・マスコミ・エンターテインメント 人事・労務・法務 部長・ディレクター

発注者も受注者も経験しているため、事例含めて非常に納得できる話でした。
画面設計、遷移、要件定義は作業依頼をするには不可欠。
かつ、その際、金額、スケジュール、業務範囲の確認も同様に不可欠。
SLAではなく、発注者と受注者のコミュニケーションで互いのニースを探りながら接点を積み上げていくことをスキルとして身に着けていかない、といつまでも同じことが起きる。

tnkakm
2021/10/07
商社・流通・小売・サービス 人事・労務・法務 一般社員

エンジニア経験がある身からすると、エンジニアはめげずに発注者の考えを聴く努力が必要だと思います。
発注者がエンジニアに寄り添いたくなるコミュニケーション力・説明力が、エンジニアには必要だと思います。そうではないと、生き残れないと思います。

tak_197
2021/10/02
金融・不動産・建設 経営・経営企画 部長・ディレクター

新システムの改善にあたり作成当事者の立場も考慮したうえで要望することが大切、非現実的なリクエストばかりにならないように。

ricohiroto
2021/10/01
IT・インターネット・ゲーム・通信 IT・WEB・エンジニア 課長・主任・係長・マネージャ

わたしはお客様からお仕事をもらう立場であるのと、ビジネスパートナーへお仕事を発注させて頂く立場であるのと、両面の立場で考えさせて頂きました。相手の立場になって、如何に物事を考えるか、改めて考えさせられました。

sathga
2021/09/28
金融・不動産・建設 IT・WEB・エンジニア 一般社員

私も非エンジニアであるが、本コースを通じて受注者側の意図することがよくわかったので、今後の業務に役立てたい。また、講師の話にあったとおり、より開発について理解するために自分でもプログラミングに取り組みたい。可能であれば、発注者側、受注者側双方の立場をある程度経験したい。

kazu3264
2021/09/27
メーカー その他 一般社員

エンジニアではないですが、日頃のコミュニケーションを図る際にも活用出来ると思いました

kgk_ys
2021/09/27
メーカー 経営・経営企画 経営者・役員

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

masaya0803
2021/09/25
メーカー 営業 課長・主任・係長・マネージャ

経営者自身がエンジニアやプログラマーの経験があるというベンチャー企業経営者が目立つようになってきたようにも感じます。いかによりそいながら、全体をどのようにマネジメントしていくのかが重要だと感じた。

akirok
2021/09/25
メーカー メーカー技術・研究・開発 部長・ディレクター

発注者がエンジニアに歩み寄るということは非常に大事だと思う。相手の業務内容も理解していない状態で、こちらの希望だけを伝えてもうまくいかない。エンジニア側は言われたことを忠実に実施する事が求められているわけであり、認識がズレるということは確実にあると思う。多少プログラミングをするが、ユーザー側からは見た目の修正とちょっとした変更はすぐにできると思う傾向にあるので、発注者側になることも多くあるので、注意していきたい。

miytk
2021/09/25
IT・インターネット・ゲーム・通信 営業 一般社員

発注者とエンジニアだけでなく、どの部署においても相手と密にやり取りをしたり相手の認識が自分の認識と合っているのか確認をすることは必要

tetsuya_maekawa
2021/09/24
商社・流通・小売・サービス 営業 課長・主任・係長・マネージャ

エンジニアによりそう点に共感が持てました。

_atsushi
2021/09/23
商社・流通・小売・サービス 営業 課長・主任・係長・マネージャ

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

kss_mtr
2021/09/23
メーカー その他 課長・主任・係長・マネージャ

相手の視点で物事を考えてみるというのは、他の業務でも大切なことだと思いました。

eriyama
2021/09/22
金融・不動産・建設 金融・不動産 関連職 一般社員

小さい企業を対象にした話なのでしょうか?リスクの高い受発注を例に取り上げているな、という印象です。

dai666
2021/09/21
メーカー マーケティング 課長・主任・係長・マネージャ

自分は非エンジニアの発注者で今まさにシステムの開発フェーズなので、エンジニアの気持ちを理解し歩み寄る意識でプロジェクトを進めていこうと思った。

yuzuriha62778
2021/09/20
コンサルティング・専門サービス 営業 一般社員

共通言語がないことから、ミスコミュニケーションが起こりやすいことを予め理解した上で、エンジニアと会話をする必要があると感じた。

hiro_kitamura
2021/09/20
メーカー IT・WEB・エンジニア 一般社員

私は日々の業務で発注する立場だが、あらためて気づきがたくさんあった。特にエンジニアの仕事を知る、ということはとても大切だと感じた。システム開発にあたってユーザーとエンジニアの橋渡しを円滑に行い、リリース~運用まできちんとつなげられるよう、努めたい。

sei_2105
2021/09/19
メーカー 専門職 一般社員

ソフト開発を外注する際、お互いの持つイメージを合わせてから進めることが効率化につながることがよく分かりました。

anna_0419
2021/09/17
メーカー 人事・労務・法務 一般社員

契約書の審査の段階で、担当部署とエンジニアがきちんと具体的内容まで詰められているのか、仕様書などはできているのか確認する。

sayan_
2021/09/17
メーカー メーカー技術・研究・開発 一般社員

あとでもめないために、どこまでがいくらなのか、お金の話を明確に。時間とお金のロスを減らすため、イメージはできるだけ具体化しておく。商談の時はできるだけ具体的に伝える。

1173omo
2021/09/17
メーカー マーケティング 課長・主任・係長・マネージャ

発注者側にも最低限必要な知識は必要思いますし、物を開発する事は非常に大切なプロセスだと思います

tomohiro_883
2021/09/15
金融・不動産・建設 営業 課長・主任・係長・マネージャ

お願いするエンジニアの言語やツールを知っておくのはとてもよいことだと感じました。

hinsyou5
2021/09/14
メーカー 販売・サービス・事務 一般社員

理解しがたいブラックボックスの中身を見ようとせず、成果だけをお手軽に得ようとするのは良い仕事ではないことが分かった。自分はエンジニアではないしIT技術も難しく感じるが、認識のズレは必ずあるからこそ相互理解に努めることや、ブラックボックスの骨組みだけでも学ぶことでコミュニケーションが上手くいくのだと思った。理論的、具体的に話を進め思いやりを持って一緒にやり遂げようとする協働の精神で臨みたい。

kk_aj06
2021/09/14
メーカー 販売・サービス・事務 課長・主任・係長・マネージャ

別にソフトやシステム発注に限った話ではなく、どんなものの開発においても、発注する側のコンセプトのブラッシュアップ不足を棚に上げて、納期だけは変わらないということがままある。

nakazawa001
2021/09/13
商社・流通・小売・サービス 販売・サービス・事務 一般社員

用語をいかに分かりやすく相手に伝えるかが重要だと思った。

shun_3
2021/09/12
メーカー その他 課長・主任・係長・マネージャ

社内基幹システム構築メンバーのため、社内の要望と外注先との間に入るケースがあえい、プログラミンやDBなどの知識が無いと意思の疎通は難しいと実感している。
本カリキュラムの内容である、外注先のエンジニアがどのような視点で開発を行うか理解することの重要性をある程度は理解することが出来た。
実務レベルで対応できるようになるためには、プログラミングを学ぶ、エンジニア側が商談~納品・保守までをどのようなスケジュールと役割で計画を立てているかなど学ばなければならないと思う。

yan_s
2021/09/12
メーカー 人事・労務・法務 課長・主任・係長・マネージャ

社内外へ発注するシーンが多い為、工数の積上げ、開発後の運用フェーズの事まで視野に入れながらコミュニケーションを取りたいと思いました。

kurou
2021/09/12
メーカー 営業 部長・ディレクター

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

h_tkd
2021/09/11
金融・不動産・建設 人事・労務・法務 その他

・実際の業務に役立てていく。

ici
2021/09/10
メーカー メーカー技術・研究・開発 課長・主任・係長・マネージャ

畑違いの分野の作業は時間の見積もりが難しく、スクジュールを立てるときに的外れな見通しをしてしまうことはありますね。
自分でも経験してみて「相場」を知っておくというのが相手に対する配慮ができるかどうかという点でも重要だと思いました。

match-v
2021/09/08
メーカー メーカー技術・研究・開発 課長・主任・係長・マネージャ

発注者、エンジニアのどちらの経験もあるので、例題どちらの思いもよく分かった。そこに受注者側の営業が入ってくるので余計に難しくなる。

hironon
2021/09/07
金融・不動産・建設 マーケティング 課長・主任・係長・マネージャ

エンジニアにかかわらず、社外の専門業者や、社内調整の際に汎用的に通じるスキルだと感じた。

tsuyo_uchiyama
2021/09/04
メーカー 人事・労務・法務 一般社員

業務委託先に対応依頼する時に注意、意識すべき事項として学びました。

kosuke_86
2021/09/04
メーカー 専門職 一般社員

ヒトに発注や依頼をするにあたり、認識のズレが生じるのはエンジニアに限った話ではないように思う。自分自身の考えも決まっていない状態で、曖昧な指示をして、丸投げすることがないよう気をつけたい。

7010guchi
2021/09/03
メーカー 営業 一般社員

エンジニアとの会話のみでは、許攸kが難しいと思った。機会的な設備発注でも過去難しさを強く感じた。請求発注業務を担当した中で、使用ソフトの改善発注するときに、いっろいろと苦労したのを思い出した。

ysmokb
2021/09/03
メーカー 営業 一般社員

まず、紹介バイアスがかかりやすい状態にあると自己認識することから始める。開発フェーズで任せきりにならず、重要な考え方を伝え洩れていないか、常に確認していきたい。

masapon5
2021/08/30
医薬・医療・バイオ・メディカル 人事・労務・法務 一般社員

自社の命運を左右するようなプロジェクトについて、ユーザーの理解度を理解せず、エンジニアの理論に基づいてのみ提案するような、プロジェクトマネジメントができないエンジニアを選任すること自体がリスクではないかと感じました。発注者の仕事は、自社の要望をきちんと取り纏めて、正確にエンジニアに伝えることですが、それをするために、プログラミング言語やツールについて学び、自身もプログラミングを体験してみないと正確に伝えられない、では何のための外注なのかという気も致します。もちろん、人と人のことですので、エンジニアに対して歩み寄ることは重要だとは思いますが、どうすれば、ユーザーが希望していることを、エンジニアとっても負担なく実現できるのか(何十枚に及ぶ要件定義書やコードを読んでも実物をイメージできない中で、どうすれば齟齬をなくせるのか、いつまでに変更を提案すれば対応可能なのか)について、両者がきっちりと認識をすり合わせることが重要ではないかと思いました。

yasu-342
2021/08/28
IT・インターネット・ゲーム・通信 営業 一般社員

何事にも現在はインターネットが介在するので、色々なプロジェクトに携わっていく上で、エンジニアの知識は必要になると感じる

sonny_c
2021/08/26
金融・不動産・建設 金融・不動産 関連職 課長・主任・係長・マネージャ

発注者と、開発側エンジニアの、心理面も含めた関係性が、理解できた。

stomizawa004
2021/08/26
コンサルティング・専門サービス IT・WEB・エンジニア 課長・主任・係長・マネージャ

私は発注者経験もあり元エンジニアでもあるので、共感できる内容でした。発注者側がエンジニアの視点がないと要件定義もうまくいかないので、構想段階から開発に使う技術を把握する必要があるので、事例は極端ですが理解しやすさのためと思います。私の経験ですが、発注者としては開発物の外観、管理されるデータ構造、プログラムの規模は基本設計段階で明確にするのが通常です。

yoshi-c
2021/08/25
メーカー IT・WEB・エンジニア 課長・主任・係長・マネージャ

発注者と受注者との間に生じる認識のズレを無くすために、頻繁に打合せなどコミュニケーションが必要。発注仕様に対する見積、納期を把握、共有することが重要。

wado
2021/08/25
金融・不動産・建設 IT・WEB・エンジニア 課長・主任・係長・マネージャ

非エンジニアとエンジニアの心情を両目線が分かる方ならではの視点で解説していただいているので、俯瞰して理解することができました。
個人的には説明いただいた非エンジニア側でクライアントとして仕事をしているため、初めてエンジニアと関わることになった際の心掛け部分で道具と表現されたところを具体的にどういうところを抑えると成功しやすいかを実例いただけると尚良かったかなという印象でした

ikedokoji
2021/08/25
メーカー メーカー技術・研究・開発 一般社員

仕事内容をある程度把握して依頼するのはどの仕事も同じだと考えます。お互いを理解、尊重することが大切と思いました。

s-fukushima
2021/08/24
医薬・医療・バイオ・メディカル 営業 課長・主任・係長・マネージャ

社内ポータルの外部発注時

hanao4696
2021/08/24
メーカー 経営・経営企画 課長・主任・係長・マネージャ

私は非エンジニアで今にも自分が発注者になりそうなので、非常に有用でした。
まず自分がイメージ、言語化出来ないものを依頼すると言う事は自身のアウトプットや価格の適正性から言っても非常に危険で、受注者に取っても後戻りが、多く効率的に開発を進められない事に繋がる。
初期段階で目指す姿や絶対必要なもの、あった方が良いものを分けて、スケジュールや予算を考慮しながら双方納得の上コミュニケーションを取りながら進めると言う事が重要だと感じました。

yuuuua
2021/08/23
金融・不動産・建設 金融・不動産 関連職 一般社員

システム開発に携わっています。同じようなジレンマを抱えていたので見ていてとても納得しました。
発注者からすると、見映えや挙動の部分が大事で、安くない製作費を支払うため、最低限のことではなく、要望全てを叶えて欲しいと思い発言をしてしまいがちです。エンジニアの定義する細かい仕様についての質問をもらうときに、ここまで細かく定義するのか。と思いましたが、一つの機能を定義するのに、あらゆる挙動の想定をしながらシステムを作らなければいけないので、想像している以上に大変だと言うことを発注者は理解し、コミュニケーションをはかることが大切だと思います。また、それらを踏まえると、出来るだけ商談フェーズの中で発注者として、最低限の実現したいこと、ある程度の画面遷移や設計イメージ、機能の洗い出しが大事だと思いました。エンジニアとしても、商談フェーズときに開発するものの、大枠だけでなく目的なども知り、エンジニア、発注者双方が同じ方向に進めることが、開発最高の鍵となると思いました。

tetsu_10457
2021/08/23
メーカー メーカー技術・研究・開発 一般社員

業務委託するときの、発注者側とエンジニアとの意識の違いがあることは、感じていました。講義の内容のようにエンジニア視点で見ることと自分でやってみることも心掛けたいと感じました。

pelikan
2021/08/22
商社・流通・小売・サービス マーケティング 一般社員

相手がエンジニアに限らず受発注の関係で注意すべきところが網羅されていた。
「相手の立場になるために、実際にどんな仕事をしているのかを知る」というのが重要なポイントだと思うのだが、これは受注側に当てはまることだと思う。
「発注者側がどんな目的・理由でこの業務を依頼するのか」を知ることも大切。

双方が思いやりと相手への関心を持てばもっと円滑に進むはず。

y-takashima
2021/08/21
メーカー 専門職 課長・主任・係長・マネージャ

発注者側の視点として、受注者側に「おまかせ」はダメで、お互い齟齬がないか意識をもって順次確認しあう必要がある。
また、発注者側は強者、受注者側は弱者という構図だと結果的にそのプロジェクトは破綻する可能性が高くなってしまう。
相手への気遣いは当然必要ですが、ゴール(仕様・期日)の設定、実行予算や契約はきちんとしないと、期日までにズルズル仕様が定まらず、納期遅延等の泥沼にはまったプロジェクトを沢山見ているだけに、考えさせられる講義でした。

masaki3
2021/08/21
金融・不動産・建設 営業 課長・主任・係長・マネージャ

実際に発注する立場にはありませんが、全く異質の文化でビジネスが展開されていることが理解できました。自社の情報システム部とのコミュニケーションで役に立ちます。

k-ogawa
2021/08/19
メーカー 営業 一般社員

今回の内容に限らず、異なる職種同士の方々がお互いの意見を尊重し、相手を理解しようとする心掛けは必要だと思う。

hachi_sophia
2021/08/17
メーカー 経営・経営企画 部長・ディレクター

現時点で現在の業務にソフト開発を依頼するような状況はない。但し、以前の部署で数年前に発注者側として部下が対応し、なかなか受注者側とイメージが合わずスケジュールが大幅に遅延した苦い経験を思い出した。確かに発注者側として要件定義など認識合わせしていたが、実際のイメージがわかず、イメージが異なると色々厳しい事を言っていた記憶がある。という訳で、非常に現実的な納得性の高い話ゆえ、今後またそのような機会がある時の参考にしたい。一方、実際にプログラム基礎を体験することが大切というのは本当にそうなのだろうと思いつつ、なかなかそこまでは...と思ってしまう自分もいる。が、次回は体験もした上で業者との調整に望みたいと思う。

sadapon
2021/08/16
金融・不動産・建設 金融・不動産 関連職 課長・主任・係長・マネージャ

非エンジニアでEUC開発をお願いしています。自分自身も可能な限り、要求を伝える際は画面イメージや遷移については具体的にお願いすることを心掛けていましたが、言語まで入り込んでやったことはなかったため、今後はエンジニアの方の使用する言語で実際にプログラム等をしてみて、より深くエンジニアの方の実務につき理解に努めたいと思ました。

kunihiko-w
2021/08/16
メーカー 経営・経営企画 一般社員

エンジニアに寄り添うことの大切さが理解できました。エンジニア側も発注者側に寄り添う必要性もあると思います。またエンジニアと発注者という関係に限らず、どんな仕事でも共同で行っていくときには、寄り添うということがとても大切だということをよく認識できました。

4rau_gh
2021/08/15
商社・流通・小売・サービス 販売・サービス・事務 一般社員

エンジニアの方が持っているような知識がないからと言って、任せきりにするのでは問題が起こる。必ず一緒に確認をしながら作業を進める。

dx_2030
2021/08/15
医薬・医療・バイオ・メディカル メーカー技術・研究・開発 課長・主任・係長・マネージャ

わからないことは、わからないと言いたいと思います。

mayuge49
2021/08/15
金融・不動産・建設 金融・不動産 関連職 課長・主任・係長・マネージャ

日常の業務が開発要件提示ですが、外部に発注する際のコミュニケーションが非常に大切だと思いました。

n_ky
2021/08/10
メーカー 販売・サービス・事務 一般社員

具体的な要望、画面イメージなどは早めに認識合わせをして、エンジニアを尊重する事が大切だと思います

yamataka0917
2021/08/09
メーカー メーカー技術・研究・開発 部長・ディレクター

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

hkmk
2021/08/09
メーカー メーカー技術・研究・開発 一般社員

システム発注に限らず要件定義と受注者への業務量・難易度の理解は必須であると考える。他の一般業務でもこれが出来ずに揉めることは非常に多い。
ただし講義中にもあるように、ITエンジニアに対する現状では情報の非対称性が大きい。受注者と発注者がかなり密接に情報のやり取りをする必要があるという理解を持とうと思う。
社内でDX化が多く叫ばれいろいろなシステムが導入されているが、本当にこれができているのかとても不安に思う。
と同時にこれができるようになれば少なくともしばらくは重宝される存在になれるということかもしれない

nomurak
2021/08/08
メーカー 専門職 課長・主任・係長・マネージャ

まだコースの途中ではあるが、最も役に立つ内容だった。

kouji-1007
2021/08/07
商社・流通・小売・サービス 販売・サービス・事務 課長・主任・係長・マネージャ

クライアントと話をする中で、デジタル用語などが出てくることもあり、この動画のような状況も実際にあります。
参考になりましまた。

taiyotosaka
2021/08/06
IT・インターネット・ゲーム・通信 マーケティング 一般社員

kazuhisa-k
2021/07/30
商社・流通・小売・サービス 人事・労務・法務 部長・ディレクター

発注者側としての基礎知識を理解出来たから、それぞれのパートの続編が欲しいです。

0829koba
2021/07/29
商社・流通・小売・サービス マーケティング 課長・主任・係長・マネージャ

今回の講義は、エンジニアさんという職種に限った内容であるようだが、他の業種においても通じる話だと思う。発注者側のイメージと受注者側のイメージのすり合わせや契約の仕方、リリースまでの段取りなど、相互でコミュニケーションを取りながら進めることが大事である。自分のイメージの押し付けや自分都合のスケジュールでは、工程上無理が生じ、自分自身を追い込むことになる。

kuzuwa_h
2021/07/27
商社・流通・小売・サービス 販売・サービス・事務 課長・主任・係長・マネージャ

システム部門とのやり取りが、まさ
にこの講義の内容だった。
エンジニアの価値観は理解できない部分も多いが、理解するためのコツを学べたような気がする。

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

過去の経験で、それぞれのフェーズで課題となる点において、やってはいけないことをやってきていた事を改めて認識しました。あの時、さきにこの動画で課題点を認識できていれば、という思いと、今後はもう一度この動画の注意点にしっかり留意していこう、というリマインドになりました。

tsukasa_1496
2021/07/27
医薬・医療・バイオ・メディカル メーカー技術・研究・開発 一般社員

受注者側であるエンジニアの仕事の進め方の理解と目的達成のためのコミニュケーションが大切であることが分かりました。エンジニアの仕事・プログラミングがどういうものか知識がないので、発注者となる場合には少し勉強した上で仕事に臨みたいと思いました。

tomoyasu0306
2021/07/26
商社・流通・小売・サービス IT・WEB・エンジニア 課長・主任・係長・マネージャ

エンジニアも発注者もどっちも検討段階からずいぶんいい加減だなと感じましたので、反面教師としたいとかんじました。

aya_bunbun
2021/07/24
メーカー 販売・サービス・事務 課長・主任・係長・マネージャ

発注者としての姿勢や意識しておくべきことは非常に理解ができました。一方、受注者側も発注者側に歩み寄る姿勢が大事なのではと考えてしまいました。

mr24pons
2021/07/20
医薬・医療・バイオ・メディカル メーカー技術・研究・開発 一般社員

プログラミングについて全く知識はないですが、最後のインタビューの内容は顧客とのやり取りや部下とのコミュニケーションで活用してみようと思いました。

hasegwa86
2021/07/19
インフラ・公共・その他 メーカー技術・研究・開発 一般社員

部門システムを担当しています(技術部門ですがSEではありません。)一般論としての発注者あるあるが詰まっていたと思います。
特にインタビューの中にあった,エンジニアとの会話をそのまま社内報告しないというのはまさにその通りと思います。報告を受ける上の人が咀嚼できる内容に翻訳してあげるのが担当者の役割だとあらためて認識しました。

kurisaki1979
2021/07/17
金融・不動産・建設 金融・不動産 関連職 課長・主任・係長・マネージャ

自分がIT部署と協業する時に、要件定義とユーザー側の受け入れテストを入念にやること、また、スケジュールはIT 部署と相談しながら決める事。

k-m202106
2021/07/17
医薬・医療・バイオ・メディカル その他 一般社員

発注者側としてかかわったことがありその時の苦労を思い出しました。このような内容の講義があるということはみんな同じようなことを悩んでいたんだなと思いました。

goki-0920
2021/07/14
IT・インターネット・ゲーム・通信 営業 一般社員

エンジニアに要件しっかり伝えることの大切さを学んだ。

nori5013
2021/07/14
メーカー その他 一般社員

受注者視点の重要性が良く分かりました

tsukida
2021/07/13
IT・インターネット・ゲーム・通信 人事・労務・法務 一般社員

現在委託先に開発を発注する業務を担当していますが、発注者としての視点に加え、受注者側で考えていることも分かるきっかけとなり、参考になりました

nekoneko55
2021/07/12
メーカー 専門職 一般社員

発注者となったとき、受注者の認識のずれを起こさないよう、最低限の知識は持っていたい。たとえば修正が簡単なものなのか、複雑なものなのか、どれくらい大変なのか判るだけでも大きく違うと思う

kohikun_1729
2021/07/12
医薬・医療・バイオ・メディカル メーカー技術・研究・開発 一般社員

この講義を3年前に聞きたかったです.実際にシステム導入にあたり,社内のシステム管理部門,ベンダーさん,及び社内の管理部門との間で苦労しました...当時はユーザー側の要求を正確に伝えることに注力してしまいましたが,歩み寄る姿勢を大事にしたいと思いました.でもハードル高い....少なくとも価値観を大事にしたコミュニケーションを心がけようと思ました.

katagi
2021/07/11
メーカー 人事・労務・法務 課長・主任・係長・マネージャ

実際に業務として行う機会はないかもしれませんが、要点は忘れずにあとからコストが合わないことがない様に全体像を把握することが必要だと学びました

barakhan
2021/07/10
金融・不動産・建設 金融・不動産 関連職 課長・主任・係長・マネージャ

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

yas-t
2021/07/08
メーカー メーカー技術・研究・開発 課長・主任・係長・マネージャ

プログラミングを依頼したことがあります。
事前準備に時間をかけたので、問題になる事はありませんでしたが、テストでは依頼と異なる内容を多々修正しました。

holly-mao
2021/07/07
コンサルティング・専門サービス 人事・労務・法務 部長・ディレクター

たしかにエンジニアの人との会話は、よくわからないことがあり、こちらの言いたいことをうまく言えないことがあります。プログラミングを学んでみるというのは、新しい発想でした。

machikyo
2021/07/05
メーカー 営業 一般社員

以前発注者としてシステムの開発を依頼したことがあったが、私も専門知識が全く無い状態だったため、エンジニアの方には非常にご迷惑をかけた経験がある。発注者側としてもある程度の知識を持たなくてはいいものができないと本講義を受けて再認識した。

yokota-0413
2021/07/05
メーカー メーカー技術・研究・開発 課長・主任・係長・マネージャ

本講座は仕事の各フェーズで必要とする書類がない丸投げに近い状態の想定のように思えます。戦略、開発、移行、運用、改善の観点から見ていけばここまで極端なことにはならないのではないでしょうか?当然、技術者側からみた開発工数が予想できることにこしたことはないですが。

akiiira
2021/07/04
メーカー マーケティング 課長・主任・係長・マネージャ

自社ホームページの改修をやっており、あるあるだらけで共感できた。

hiro-1975
2021/07/03
商社・流通・小売・サービス 営業 課長・主任・係長・マネージャ

興味深かったです。

moritti
2021/07/01
商社・流通・小売・サービス 販売・サービス・事務 一般社員

プログラミングに限らず、業務のやり方が異なる方と仕事をする際には、相手の大事にしていることを尊重したうえで、行うことが大事であると理解しました。

tsukihara
2021/06/30
IT・インターネット・ゲーム・通信 クリエイティブ 一般社員

私は、エンジニアに直接発注する機会はあまりないのですが、エンジニアに限らず応用できる学びがあったように思います。
対話は、相手の事情や立場、スキル、リテラシーを踏まえて、尊重しながらするべきだと思いました。

aki_4442
2021/06/30
メーカー 営業 部長・ディレクター

自社が持つ通念まで共有しないと、思い通りのアウトプットが得られない気がします。
デフォルトで済まない部分が、非常に難しいところだと思います。

animals5
2021/06/30
メーカー IT・WEB・エンジニア 課長・主任・係長・マネージャ

本コースでご説明されていたことは、外注に依頼する上で、共通することではないかと思います。外注業者の行う作業を全て知っている訳ではないが、キーとなる部分は確実に抑えておかなければならない。自分でやったことは無くても、これぐらい掛かるとイメージしておくことが肝心ですね。

aji_yn
2021/06/29
メーカー 営業 部長・ディレクター

今まで複数のシステム開発に発注者としてかかわってきましたが、エンジニア側のモチベーションを下げるような言い方をしていたことに気づきました。一方でエンジニア側の歩み寄りも欲しい、とは思います。また、発注者とエンジニアの各々の意見・主張を翻訳できるようになりたい、と思いました。

mori124
2021/06/29
IT・インターネット・ゲーム・通信 その他 一般社員

・打合せの事例が、社内でも聞いていた感じだったので、開発の目的をはじめ、 
 ユーザーの利用場面、運用保守のイメージもすり合わせるのが大事だと改めて
 思いました。

ken_matsushima
2021/06/26
メーカー メーカー技術・研究・開発 課長・主任・係長・マネージャ

プログラミング経験者ですので、「よくいってくれた!」という感じです。情報の非対称性に関しては、この講座を受講すれば、分かるかと思いますが、会社の上層部(意思決定権がある人)こそ認識すべきかと思います。

k_katoh
2021/06/26
メーカー メーカー技術・研究・開発 課長・主任・係長・マネージャ

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

pepe0113
2021/06/25
商社・流通・小売・サービス 経営・経営企画 課長・主任・係長・マネージャ

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

hiro_19
2021/06/20
メーカー メーカー技術・研究・開発 課長・主任・係長・マネージャ

非ITエンジニアだが、仕様の明確化は重要だが、明確にすればするほどITエンジニアって必要なくなるのではないか?仕様書のコンピュータ言語化するだけのプログラマだけが必要で、闘争がない開発になってしまうのはどうかと思うが、

事例の話は、自分の業界の非IT開発において、社内工程でも発生していると思う。文書化できない。議事録が議事録になっていない。できるだろうで進む。などなど
学ばない相手にどう寄り添うのか?や声が大きい人への対応といった部分を考えていって、本学習事例に立ち戻りたいと思う。

kaicyou
2021/06/17
メーカー その他 一般社員

発注者側からすると、いつまでに完成と期日をまず考えてしまう。それは日常の業務の進め方からクセづいているため。
しかし、受注者側からすると、設計プロセスを立てた中での期日なり完成度が決まってくるため、結局「相手に対する思いやり」が大切だと感じる。
「いつまでにできそうですか?」「いつまでにやってもらいたい」と発注者視点の問いかけではなく、「色々との業務もあって大変な中、いつ頃が目途になりそうですか」と気持ちよく聞いてくれるようにしたい。
あとは、期日が正しいのかどうか受注者に確認して、自分の上司に伝えたほうがよい。上司もスケジューリングを立てることに浅はかかもしれない。

zzr400winered
2021/06/15
医薬・医療・バイオ・メディカル 経理・財務 課長・主任・係長・マネージャ

エンジニアの大切にしている事やこだわりは、発注者にはあまり関係ないかと思う。実際のユーザーの立場からしてみれば、どんなに作成が大変だったとしても関係なく、使いやすければ良い。
もちろん、発注者の歩み寄りがあれば早く、正確に作業が完了する事もあるかと思うのですが、受注者のコミュニケーション能力の向上も必要かと感じました。

sskmd28
2021/06/12
商社・流通・小売・サービス 経営・経営企画 一般社員

プロジェクトに携わるときに開発側の立場を考えてコミュニケーションをとれるようにする

k246
2021/06/12
医薬・医療・バイオ・メディカル メーカー技術・研究・開発 一般社員

エンジニアの視点を理解するために、まず自分でもちょっと学んでみると良いという話が最後に出てきたが、それがまず難しいのではないかと感じた。「今の時代ネットで調べればプログラミングの基礎を学べるサイトなども出てくる」という話は理解できるのだけれど、例えばアプリの開発を発注するにあたってどんなことを勉強すればエンジニアの視点を理解できるのか、すぐには想像がつかない。

momo-san
2021/06/07
メーカー 専門職 一般社員

楽しく講義を拝見させていただきました。
これからエンジニアの方とうまく連携できそうです。

sentry
2021/06/06
メーカー 専門職 課長・主任・係長・マネージャ

今回は非エンジニアからの視点でしたが、エンジニアからの発注でも起こり得るミスです。

自分の専門を超えるときは、独りでイメージだけで進めるのではなく、関係者とキーとなる確認事項を洗い出して、ゴールまでのサクセスストーリーを具現化してから、最初の一歩を踏むダンドリが重要だと改めて考えました。

kurocowup
2021/06/06
メーカー メーカー技術・研究・開発 一般社員

アプリのイメージ作りに役立ちそうです。

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

内容がよくわかりました

takashi_asukana
2021/06/04
メーカー その他 課長・主任・係長・マネージャ

当たり前かも知れませんが、お互い敬意を持って仕事していくことが改めて重要だと思いました。

66chiko99
2021/05/30
金融・不動産・建設 金融・不動産 関連職 一般社員

先を見据えてシステム開発していくのに役立つと思いました。

take_history
2021/05/30
メーカー 人事・労務・法務 課長・主任・係長・マネージャ

対エンジニアのコミュニケーションだけでなく発注者側の社内コミュニケーションにまで踏み込まれており、ICT以外での外部専門家を起用して実施する様々なコンサルタントへの業務の依頼、大規模な建屋、設備の発注等様々な場面に応用できる内容だと思いました。

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

プロジェクトを進めるに当たって、相手側の立場に立って考えること

n-k-qawse
2021/05/24
IT・インターネット・ゲーム・通信 経理・財務 課長・主任・係長・マネージャ

ここでいう歩み寄りっていうのは難しい表現で、ここを譲歩するとか、一方的に気を遣う、みたいなそういうとらえ方をすると少しおかしくなりそう。
あくまでも、エンジニアと呼ばれる人たちの(よくある)性質・気質・内在的論理を”理解する”ということかな。理解であって必ずいつでも共感しなければならないではない。のように理解した。

utsu_musako
2021/05/23
IT・インターネット・ゲーム・通信 販売・サービス・事務 一般社員

以下の各フェーズでつたえるべき項目は、
今後、エンジニアに業務を依頼する際に意識しようと思う。

□商談
・画面イメージをつたえる
・要件定義イメージ ※画面上に何があるのか?具体的に伝える
□開発フェーズ
・エンジニアの仕事の進め方や価値観を知る必要がある。
・エンジニアとデザイナーも違う、何が得意としている人なのか理解が必要
□運用フェーズ
・最低限に必要なモノはなにか?を決めておく
・緊急時のリソースを確保しておく。

nobu_agf
2021/05/23
メーカー 営業 課長・主任・係長・マネージャ

現状の仕事ではあまり思い浮かびませんが、営業施策、特に消費者キャンペーン企画を立案する場合の、販促物デザインや消費者キャンペーン事務局の発注などで活用できると考えます。

th0588
2021/05/22
メーカー その他 一般社員

たしきかに社内でプログラミングを依頼するときに、簡単にできると感じてお願いをする事があるので、発注する時には気をつけようと思いました。

k213243n
2021/05/21
メーカー 人事・労務・法務 課長・主任・係長・マネージャ

相手の立場や考え方を理解すること、最初に要件を明確にすることが開発を進めるうえで重要であると理解しました。

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

現在の業務では具体的にエンジニアに発注する機会は想定されないものの相手の立場を考えたコミュニケーションの重要性を改めてて感じた。

numatake
2021/05/17
メーカー 営業 課長・主任・係長・マネージャ

プログラミングに限らずエンジニアと仕事をするには、製品自体への知識・理解は欠かせないと思う。仕様や納期、変更時の契約条件などを事前に明確にするのはどの仕事でも大切なことと思う。

junko_125413
2021/05/16
メーカー マーケティング 一般社員

どんな業務でも相手の業務を理解することの大切さを学びました

tanaka_cototoki
2021/05/15
メーカー その他 部長・ディレクター

どの分野にも限らずエンジニアという職種にも限らず、お互いが先ず敬意を払い相手のことを理解しようとする姿勢が無ければ良い仕事は出来ないと思っています。
主に発注者側になるのでエンジニアそれぞれの時間軸を理解しプログラミングも学び良い仕事が出来ましたと言っていただくことを目指します。

hana_tsuza
2021/05/12
金融・不動産・建設 営業 一般社員

業務で活用するにはもう少しプラグラムについて理解しなければならないと思いました。変更を加えることができるのか、できないのか、エンジニアの話が理解できるようになりたい

markey0827
2021/05/12
コンサルティング・専門サービス 営業 一般社員

皆さんの気づきのコメントを拝見していても、この視点の有無の程度は企業によってさまざまなんだと感じました。エンジニアの仕事を知る、ということは需要がありそうですね。

今の職場では人事部主体の入社1年目研修(中途採用)に、プログラミング体験やテクノロジーの活用に関する内容がある。疎い自分にとっては大変ありがたかったが、実務においては更にエンジニアのかたを知る必要があると感じている。法人営業として、顧客の声を頂く機会は多いが、別部署へその声や要望を伝えるときには伝書鳩にしかなれていないと感じる。

今後、エンジニアのかたと協業するときにはこの動画を見直して実務に活かしたい。

keisuke_agi
2021/05/11
メーカー マーケティング 一般社員

他国の人と話す言語のようなものがまさにプログラミング言語と感じた。ある程度の言語理解が無いとコミュニケーションが成り立たず業務にならないのだろう。一方でそれを理解できる技術営業的な仲介者がいて欲しいというのが思う所なのでそういった立場になれるために何が必要かを学んでいきたい

cf_202104
2021/05/11
メーカー 資材・購買・物流 一般社員

アプリ開発ではないですが、RPA導入時に同じような体験をしました。先輩は「指摘をしろ」というタイプで、問合せるより先に指摘から入っていました。RPA導入後に自分でVBAマクロを少し書いてみて、かなりの工数が掛かること、細部をきをつけないと稼働しないことを理解しました。体系立った話を聞き、大変納得する内容でした。

kokorono-papa
2021/05/10
医薬・医療・バイオ・メディカル 資材・購買・物流 課長・主任・係長・マネージャ

なかなか興味深い。エンジニアの立場、非エンジニアの立場で受け取り方法が異なる。これはどの立場でも同じなのかもしれない。どこまで歩み寄れるのか、どちらの立場を優先に考慮した方がよりメリットが大きいのか考えさせられた。

zummy_0617
2021/05/09
金融・不動産・建設 金融・不動産 関連職 一般社員

今、システム担当ではないのですが、実務をやる担当者とエンジニアリングとの
寄り添いをすることは容易なことではないことがわかりました。エンジニアリングとのやり取りをした後、社内の従業員からは要望を聞かれても意見のかみ合わせはうまくいかないのが現実だと感じます。機械という道具が得意だからといってなんでもかんでもできるという思い込みは捨てたほうがいいと思います。

masanori_1974
2021/05/08
金融・不動産・建設 金融・不動産 関連職 一般社員

当社のビジネスに活用できそうです。

t_tomo23
2021/05/08
金融・不動産・建設 その他 課長・主任・係長・マネージャ

以前、会社の担当部署でデータベースを共有するということを平成6年頃に発注者側で経験しました。SEさんとの打ち合わせや資料は極秘データなので、秘密保持の契約、今後のメンテナンス等も交渉したことがあり、大変な思いをしました。
当時、この動画配信で学べば、短時間で効率よく発注できたのかなと思います。
パソコンはWin3.1の時代でしたからね、上司に理解してもらうのに苦労しました。

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

「エンジニアと発注者」に限らず、
「論語と算盤」、「社会主義と資本主義」など、
二者の対立関係で生じる問題は、どちらが一方の立場や主張が正解や絶対ではなく、お互いの主義主張を包摂して、バランスを保っていくとうまくいくと感じた。
言い換えると、「お互いの妥協点を見つける」。

発注者側は追加したい要望や機能を哲学して最小限に。
受注者側はできる範囲で最大限に発注者やユーザーの意図・真意をくみ取った実装を。

それを実現するためには「寄り添い、学び合う」ことが大切だっていうのが理解できたが、それができる人が世の中にあふれていたら戦争なんて起きないんだろうなーと。

hope94
2021/05/07
メーカー 営業 一般社員

まさに現実におっしゃっていることが起きていたことを実感する場面は多いと感じます。発注者側から開発途中でも要件定義を安易に追加、変更することはあり、走りながら変えることが求められている時代であることを、プログラムにも求めている様子があります。きちんと要件定義をし、お互いに歩み寄る姿勢はとても大事だと思いました。意識を持ち発注者側となりたい。

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

実際に発注することは、しばらく先とは思いますが、受注側のエンジニアとのコミュニケーションを気を付けたいと思います。

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

システム開発時の元請けや営業窓口の存在理由がよくわかります。素人相手に必要な情報を取り、わかりやすく説明する機能が必要。一般的な工事発注でも一緒です。

kawafuji
2021/05/06
医薬・医療・バイオ・メディカル 営業 課長・主任・係長・マネージャ

エンジニアとの発注やり取りは、プログラミング知識はある程度必要。

takayoshi64822
2021/05/05
メーカー 専門職 一般社員

以前、ソフトウェアの発注をした時にも、要件定義と、納期、費用だけに着目していましたが、プログラム上のカスタマイズに対する厳しい側面には目を向けていなかったと思います。最初の要件定義で不足していた内容の後日アップグレードの困難さなどもありますし、よくコミュニケーションを取って今後は進めたいと思います。

hara0902
2021/05/05
広告・マスコミ・エンターテインメント 営業 課長・主任・係長・マネージャ

相手のことを理解して、任せきりにせず一緒に作っていく姿勢が大事だと思いました。

masa_ara
2021/05/03
金融・不動産・建設 経営・経営企画 部長・ディレクター

予想以上に発生、受注サイドの差が大きいことがわかりました。

tsuyohi
2021/05/03
金融・不動産・建設 金融・不動産 関連職 部長・ディレクター

開発者と発注者の考えは一致していないことを前提に、開発者の考えを理解しつつ、要望を丁寧に伝えながら、システム開発を進める必要があることを学んだ。

bonjours
2021/05/02
金融・不動産・建設 金融・不動産 関連職 課長・主任・係長・マネージャ

システム開発者として経験を積んだ後にユーザー側に異動し発注者となったので、講師の方の言われることはよくわかります。ただ、本当にプログラミングの知識まで必要なのかは疑問に感じて見ます。システム開発・保守にはどのようなタスクがあり、その役割分担で開発者との間で齟齬が起きそうな部分、費用を落とすためにユーザーでもできることは何かなどを解説していただいた方が、より実践的な内容になった気がします。

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

社内でRPAによる業務効率化を検討する場面があらゆる部署で増加傾向にある。既発注の案件では、Windowsの仕様変更やタイムアウトエラー時の例外処理などが想定通りにいかなくて追加改修を依頼することになった。今後の発注時には特に、運用時に想定される問題について開発時点で要件に盛り込めるように留意していきたいと考える。

tsurutay
2021/05/02
医薬・医療・バイオ・メディカル 営業 一般社員

社内にもエンジニアと呼ばれる担当がいますが、今回、相手のスケジュールを知る事と気遣いを持ってどれだけ、相手が快く仕事を進めてくれるか?配慮する事が大事だと感じました。

yunnyutan
2021/05/01
メーカー マーケティング 課長・主任・係長・マネージャ

自身が発注者としてプロジェクトリーダーの立場でシステム開発にかかわった経験があるので、今回の事例は非常に腹落ちしました。受注者の状況を知る努力をしながらプロジェクトを円滑に進めていく秘訣や、リリース後の保守・運用まで踏まえた計画立案の重要性について再確認することができました。

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

プログラミングのことは分からないと諦めていた部分があったが、
・自ら体験すること
・エンジニアになるわけではないが、エンジニアの立場に立った視点をもつこと
は必要と感じた。

michiko_k
2021/04/28
金融・不動産・建設 経営・経営企画 課長・主任・係長・マネージャ

エンジニアとのやり取りでもどかしく思うことがありますが、自分からしたら簡単だろうと思うことがそうではないことがある、自分はプログラミングを全然わかっていないのだということを前提として、お互いに尊重して、仕事を進めていくことが大事だと思いました。

chilled8
2021/04/27
メーカー マーケティング 課長・主任・係長・マネージャ

直接エンジニアに発注することはないが、作業の工程から全体のスケジュール感を知っておくことは、認識合わせのために有効だと思う。

147258369
2021/04/23
金融・不動産・建設 営業 課長・主任・係長・マネージャ

重複する顧客データの管理をシステムを組んで省略可する際に、自分の言葉で伝えられるようにしたい。

u_taiki
2021/04/21
金融・不動産・建設 営業 一般社員

新卒でプログラミングのこともほとんど理解していない身ですが、今後IT関連の企画開発の上流工程を担うことになると思っています。エンジニアとの歩み寄りを大切に最低限の知識を身に着けて仕事を進めていければと思います。

sfurugane
2021/04/20
IT・インターネット・ゲーム・通信 IT・WEB・エンジニア 一般社員

何か作ってみるといいというのは確かにその通りだと思った。まだプログラミングの基本文法だけだが、かなり長い時間かけて習得していくもの。それがサービスプロダクトのものとなればコード量は膨大になる想像が少しついた

tomo1418
2021/04/19
商社・流通・小売・サービス マーケティング 部長・ディレクター

管轄外の分野に関する内容っはあったが、非常に興味深い内容であった。今後の参考になる情報が多かったと思う。

omso
2021/04/13
メーカー メーカー技術・研究・開発 課長・主任・係長・マネージャ

エンジニア、非エンジニアとかに限らないコミュニケーションの問題かと感じた。このような認識ずれはよくあること。いろいろ質問とかして聞いてみてもわからない用語が次から次へと出て、どんどんよくわからなくなって、結局曖昧なまま進めて話が違うじゃないかというのはよくあること。
やはり発注者側が専門じゃなくても、そのことに携わるには最低限のリテラシーを身に着けてからでないとうまく遂行することは難しいのかと感じました。

baakun
2021/04/13
メーカー 資材・購買・物流 部長・ディレクター

エンジニアが外国人に例えると、全く言語を理解できないレベルから、相手の国をイメージでき、片言でも意思疎通をしながら、同じ人間として相手を思いやる関係の構築が必要。

s0110032
2021/04/12
広告・マスコミ・エンターテインメント 経営・経営企画 課長・主任・係長・マネージャ

現場でエンジニアと接しており、締め切りやり取りなどうまくいかないことが多かったが、エンジニアが工数で計算するというのは非常に理解でき、こちらが相手の作業工数まで考えた締め切り提示ができていなかったと反省しました。

d-suke1001
2021/04/11
金融・不動産・建設 営業 課長・主任・係長・マネージャ

経験に照らしてみて、そうだよなと感じることがある。

発注者は丸投げはよくないと思いつつ、発注側は逐次の確認はできない。
ユーザーとして、全部ではなくても要件定義とそれを実現する画面イメージを持つこと、それを伝えておくことは絶対に必要。

そして、どういう技術が使われていて、それが何なのか、そしてどういう開発メンバー携わって工数見積もりができあがっているのか、知っていると、きっとコミュケーションも少しはよくなるんだろうな。

jus_nyaah5
2021/04/04
商社・流通・小売・サービス 経理・財務 課長・主任・係長・マネージャ

実際に発注者の立場となった際に、エンジニアと対峙し、キーポイント、会話の進め方等を学ぶことが出来ました。

take_kazu
2021/04/04
メーカー IT・WEB・エンジニア 課長・主任・係長・マネージャ

コミュニケーション。具体的に。

a_naito924
2021/04/02
商社・流通・小売・サービス 営業 課長・主任・係長・マネージャ

ブラックボックスだった裏側の部分(プログラマー側)の状況なり考え方、を知る事ができた。

j_watta
2021/03/31
メーカー メーカー技術・研究・開発 課長・主任・係長・マネージャ

自分の専門外の話をするときに、相手に寄り添う、分からないことをうやむやにしない、ことは色々な場面で共通のことと思いました。とくに、最初のステージ(商談)で、うまくいかなかった場合も想定して、幅広く詰めておくことが大事ですね。

chatani_k
2021/03/28
メーカー メーカー技術・研究・開発 部長・ディレクター

発注者視点で進めると、認識の違いが発生し、上手く行かない事が理解出来た。
相手を理解する歩み寄りの意識の必要性を感じた。

tomiyoshi
2021/03/26
IT・インターネット・ゲーム・通信 マーケティング 課長・主任・係長・マネージャ

事例の発注者の見識ではエンジニアへ直接発注するのは無理があると感じた。
自社内にエンジニアを雇うか、提案からやってくれる業者を探すのが賢明だと思う。

unja2700144
2021/03/16
IT・インターネット・ゲーム・通信 営業 課長・主任・係長・マネージャ

エンジニアの視点と、発注者の視点を分かりやすく理解することが出来ました。

daddyveroo
2021/03/14
メーカー 経営・経営企画 経営者・役員

エンジニアがどのように製品を製作して、非エンジニアの発注者との間に、どのような知識・思考のギャップがあるかが今回の講義でよく分かりました。その上で非エンジニアの発注者が、エンジニアに仕事を依頼するときに知っておくべきこと、エンジニア側に立って物事を考えたり、発言したりすることが大切なことが分かりました。
しかし問題の起きるケースでは、発注する側は初めての素人で、エンジニアはむしろそんな素人さんから受注を受けて仕事をするケースを何度も経験しているはずです。
この問題が素人発注者さんあるあるなのでしたら、エンジニアの方からこういう場合はこうするとか、専門用語についての解説を発注を受ける前に準備しておくとか、仕事を受けるための自助努力としてするべきものなのではないでしょうか。高い買い物なのですし、業務内容は購買契約書にもきちんと記載されるべきでしょうし、それができないエンジニアはむしろ淘汰されるだけようにも思えますが、いかがでしょうか。

bassa
2021/03/13
医薬・医療・バイオ・メディカル メーカー技術・研究・開発 一般社員

開発から上市までの全体像を把握し、発注者と受注者との役割分担を明確化することが重要であると認識しました。
受注者とスムーズなやりとりができるようにするためにも発注者もある程度の専門用語を理解する必要があると感じました。

akatsuki_89
2021/03/11
インフラ・公共・その他 建設・土木 関連職 一般社員

私はプログラミングではなく、公共工事の発注者の立場ですが、細かい内容こそ変わりますが、ベースとなる視点は全く同じだと感じました。

noririn_0218
2021/03/02
金融・不動産・建設 金融・不動産 関連職 課長・主任・係長・マネージャ

まさに、システム業務以外の業務を担当する発注者側の立場なので、まずしっかりと必要な要件を伝える事が大事なんだとあらためて思いました。口頭でざっくり伝えるより、こだわりがあるならばその部分を目に見えるようにして表して伝えるのがベストだと思い、今後に実践しようと思います。

eiji105291
2021/03/02
医薬・医療・バイオ・メディカル クリエイティブ 一般社員

自分はデザイナーとして、まさにエンジニアと発注者の間に位置することも多いので、実感としてすごいよくわかった。お互いに相手のことを理解しないで、自分の領域の中で話をするので、見ていてすれ違っていることが多いと常日頃から感じていた。

mari225
2021/02/28
金融・不動産・建設 マーケティング 一般社員

やりながら都度修正するタイプなので、前もって想定する、完成形のイメージをより具体的に持ち、認識の齟齬を最大限発生させない努力がとても大事だと改めて思った。

s_kaise
2021/02/28
インフラ・公共・その他 建設・土木 関連職 課長・主任・係長・マネージャ

日本のエンジニアの地位は低すぎますね。改善しないといけません。

vivavie
2021/02/23
メーカー メーカー技術・研究・開発 一般社員

「歩み寄り」のためにそれぞれが努力していくことが必要ということを学びました。

myukiko1007
2021/02/22
IT・インターネット・ゲーム・通信 経理・財務 一般社員

こちらが伝えたいことと、先方が知りたいことに食い違いがあると、
物事を進めるのは難しく、エンジニア対非エンジニアでは特によくおきると
いうことを再認識した。

massapy
2021/02/21
金融・不動産・建設 経営・経営企画 経営者・役員

今まさに自社の基幹システム開発をしており、もっと早く受講しておけば良かった、という思いです。。
これからは、発注者側も、ある程度のデジタル知識を広く浅くでも良いので、身に付けて、エンジニアとwin-winとなれるような取組を進めていきたいと感じました。

crecer
2021/02/21
インフラ・公共・その他 経営・経営企画 部長・ディレクター

事例が、「あるある」で非常にわかりやすかった。

ki_bo
2021/02/14
メーカー 経理・財務 課長・主任・係長・マネージャ

知らない分野の業務をする時には、まず自らやってみる!そうすると相手の気持ちに寄り添えるようになるかぁ。

satoru_xx
2021/02/10
商社・流通・小売・サービス 営業 課長・主任・係長・マネージャ

実際に受託開発の仲介を行う事が多々あり、非常に参考になりました。

masken
2021/02/10
金融・不動産・建設 経営・経営企画 課長・主任・係長・マネージャ

歩み寄りと社内から寄りすぎていると思われないバランス感覚が、発注担当者としては重要だと感じた。

tk1982
2021/02/09
金融・不動産・建設 金融・不動産 関連職 課長・主任・係長・マネージャ

常にエンジニアと意志疎通を図りながら事を進めないと齟齬が生じると強く感じた。プロだからと任せきりは変な方向性に行くため、これさエンジニアに限らず様々なプロジェクトでも同じ事と思うので、自身の業務でも実践したい。

fude3
2021/02/09
商社・流通・小売・サービス 人事・労務・法務 一般社員

この動画では、過去、会社の業務システムの開発に携わり、体験した失敗がほぼ述べられていました。発注者側担当は、業務を抱えながら担当する場合が多く、開発側の多くの質問や仕様決定に対応するためには、専任体制を整えるべきと考えます。

urkn
2021/02/09
コンサルティング・専門サービス コンサルタント 一般社員

本質的には双方の歩み寄りが最も重要なのではと考えます。
明確になっていないものに対しては、双方がそれぞれにとって都合のいいように解釈してしまうということを念頭に置いておかないといけないです。

hiroshi_5643
2021/02/07
メーカー 営業 課長・主任・係長・マネージャ

プログラマーとの関係構築

compo_8023
2021/02/07
メーカー 経理・財務 課長・主任・係長・マネージャ

発注者として、大失敗した経験がある。相手の気持ちを考慮して、仕事することが大前提だ。こちらからのリクエストにいつでも応えてもらえると勘違いしていた。
また、エンジニアとの会話を社内に逐一報告するのはNGだと言うことは、自分も経験したことがある。上司からの二次質問に答えられず、ドツボにハマる。

kfujimu_0630
2021/02/06
メーカー マーケティング 課長・主任・係長・マネージャ

エンジニア(開発者)なので、発注者(依頼者)にこの講義を是非聞いてほしいと思った。社長が言っているから、そこを何とか、等の言葉を並べられても、物理的に無理なものは無理なので、しっかりとこちら側の状況も把握した上で依頼して欲しい。

yutaka_tokunaga
2021/02/06
IT・インターネット・ゲーム・通信 経営・経営企画 経営者・役員

良いコンテンツだと思いました。

nabeaki0323
2021/02/06
商社・流通・小売・サービス 販売・サービス・事務 一般社員

エンジニアの気持ちへの歩み寄りの重要性がよくわかった。
相手の価値観やリソース、背景を理解したうえで歩み寄るという考え方は、受注者と発注者の立場だけでなく一般的な他部署や他社とのコミュニケーションにおいても不可欠であるためどんな場面においても意識して行動したい。

pomepoku
2021/02/02
金融・不動産・建設 その他 部長・ディレクター

自分が発注者となる時があるかもしれないため、参考にしたい。

kodai_1986
2021/02/02
医薬・医療・バイオ・メディカル マーケティング 一般社員

エンジニアに限らず土俵が違うと齟齬が生まれやすいので、認識を逐次すり合わせる必要があると思いました。これから世の中はますますエンジニアなしには成り立たなくなるので、一般教養としてプログラミング業務を理解しておくことは必須だと思いました。

rnakax
2021/02/01
メーカー 専門職 部長・ディレクター

アプリ開発を個人のエンジニアに任せせる際、その商談ベースではすべてアイデアを話す必要があるのか、秘密保持契約を結ぶのかが気になります。

yokoyoko4483
2021/01/25
IT・インターネット・ゲーム・通信 IT・WEB・エンジニア 一般社員

発注者が開発して保守するのが一番効率的という事になるが、それでは俗人化されるので、それも問題である。どこまでエンジニアに歩み寄れるかは、会社方針にも関わってくるので、答えが出づらいテーマだと感じました。

junichijoho
2021/01/24
メーカー 人事・労務・法務 課長・主任・係長・マネージャ

領域が違う分野の方とのコミュニケーションの難しさはエンジニアとの方とに限ったことではないかと思います。自分の知識の中で判断するのではなく先方との認識を都度確認していくことが重要であると感じました。

tada05
2021/01/23
IT・インターネット・ゲーム・通信 その他 課長・主任・係長・マネージャ

納期はエンジニアの意見を確認して最終決定する

mercy0415
2021/01/23
メーカー その他 課長・主任・係長・マネージャ

あらゆる業務に共通しているが相手の業務の進め方についての理解が必要。特に専門的な分野の場合は、それなりの勉強が必要。

takaakim
2021/01/21
メーカー 人事・労務・法務 経営者・役員

非エンジニアとして、エンジニアの仕事を理解し、一方で自分の業務の目標スケジュールと進行を両立させるために、プロジェクトで何事も早めに取り掛かる必要性を改めて感じた。

rym1008
2021/01/20
メーカー メーカー技術・研究・開発 課長・主任・係長・マネージャ

発注者として
購入仕様書品を外部に開発依頼することがあるが、餅は餅屋にお任せ状態で始めは先方の言う事を信用しきって進めるが次第に具現化していく中で軌道修正を細かく要求したことがあった。最低限の押さえどころと知識が必要である感じた。

上司として部下に仕事を依頼
日々、様々な仕事をハンドリングしており、初めて行う非定型業務も少なくない。一から工数を見積もって明確な期限とアウトプットレベルを明確に依頼すべきであるが、そこまで手をかけられず丸投げしてしまうことがある。
今後は意識して実践!

ponde
2021/01/18
IT・インターネット・ゲーム・通信 IT・WEB・エンジニア 部長・ディレクター

開発あるある事例、お互いの想像力とある程度可視化、ドキュメント化が必要。

yuka_matsumotos
2021/01/18
商社・流通・小売・サービス 販売・サービス・事務 一般社員

現在、業務システムの見直しと新システムへの要望などをまとめているが、どういった視点で伝えればいいかや、注意しなければいけない点、担当部署や担当者への思いやりと業務内容の想像が必要だと感じた。できる限り負担なく、スムーズに進めるにはどうしたらいいか日々考え、知識をつけていきたい。

hitonari-2020
2021/01/17
IT・インターネット・ゲーム・通信 経営・経営企画 経営者・役員

発注側・受注側双方の立場や状況によって事情は違うので「まずはできるだけ相手を知る」という一手間がコミュニケーションの齟齬を未然防止していくことになる、と最初にお互い合意形成していこう。
これは職種関係なく不可欠なプロセスで進捗の精度を大きく左右していくので。

具体的なアクションは最低限でも
・依頼内容の可視化と図式化
・議事録やドキュメントの作成

必要であれば
ステークホルダーへの進捗共有資料の内容まで
お互いに握り合うこと

自身も受発注両側の役割を担うので常にあせらず【相手目線】で状況認知していこうと思う。

mememeg
2021/01/16
商社・流通・小売・サービス 営業 一般社員

受発注の際には、かなり詳細な打ち合わせや質問・意見の交換が必要となる事が分かり、今まで以上に「難しいもの」という認識が強まりました。
確かに発注する以上、非エンジニアが用語を勉強する,エンジニアの仕事の進め方を知ろうとする,といった事が出来れば良いだろうとは思いますが、エンジニアが受注するに際して自分たちの考えを示す事によってスムーズに案件を進めることの方が現実的なように感じました。

masaq
2021/01/16
金融・不動産・建設 金融・不動産 関連職 課長・主任・係長・マネージャ

起点は全て発注者になるので、やりたいこと・やらなければいけないことを日頃から注意深く分析し、表現し続けることが大事になるのだなと改めて痛感した

toru_ok
2021/01/15
メーカー 経営・経営企画 課長・主任・係長・マネージャ

エンジニアに関わらず、専門性の高い業務を外部委託する際には全て同じことが言えると思う。委託側として最低限押さえるべきポイントを理解し、齟齬が発生しないように相手側の立場に立った密なコミュニケーションを心掛けるのが重要。

sugarkun
2021/01/13
金融・不動産・建設 その他 課長・主任・係長・マネージャ

仰ることはごもっともですが、自分でプログラムに触れるのはハードルが高いと思います。

hiro-t-1234
2021/01/12
メーカー マーケティング 課長・主任・係長・マネージャ

発注者としての理解、目的意識を持つことが最重要

pika_pika
2021/01/11
IT・インターネット・ゲーム・通信 マーケティング 部長・ディレクター

エンジニアとの歩み寄りが大事だとは常日ごろ思っていたので、非常に勉強になりました。ただ、何をどうすればいいのか、具体的にもっと知りたいと思いました。

sanyeihiraiwa
2021/01/09
商社・流通・小売・サービス 経営・経営企画 部長・ディレクター

コメントなど特になし

tatu3
2021/01/08
医薬・医療・バイオ・メディカル その他 一般社員

対エンジニアだけではなく、あらゆるプロジェクトには「最初の目線合わせ」は大事だということだと思います。
エンジニアと話をするには、この「目線合わせ」にコツがいるという話が非常によく分かりました。

elk
2021/01/08
メーカー 人事・労務・法務 部長・ディレクター

過去に発注者の立場で外部業者の方々と打合せした時のやりとりを思い出した。相手に寄っていく、それが大事であると理解出来た。

tani44
2021/01/06
メーカー メーカー技術・研究・開発 一般社員

ITとは別の分野の開発に携わっていますが、相手が何を求めているのかを理解するためにコミュニケーションが重要だということを改めて感じました。自分が発注者の立場になった時も気をつけようと思います。

masatomo_01
2021/01/04
コンサルティング・専門サービス 経理・財務 部長・ディレクター

システム部門とのミーティングの際、留意すべき点が明らかになった。

zico10
2021/01/03
メーカー 経営・経営企画 課長・主任・係長・マネージャ

タイトルがどのような状況を指すのか講義前わからなかったが、プログラムやシステム開発の社内担当者(as非エンジニア)となった場合の留意点といった内容でした。前の部署でまさにその経験をし、発注・開発および運用の3ステージでの経験と照らし合わせながら聞きました。システム・画面もプログラマーがソフトをいじれば簡単に修正できるとの思い込みが自分の失敗の元で、実際は全て改修にあたり費用も時間も余計かかる事、最低限の機能を開発に反映し、あとは運用フェーズで改善していけばよいという思いも全く開発と同じ考えの相違がありました。そういう意味で短い講座ですが実用的で参考となる講義でした。今後は時間があれば開発とは何ぞや?の無料体験でも受けたいと思います。

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

業務を円滑に進めるには相手の立場になって思いやりを持って接することが大切。そのために相手の業務を体験する事は非常に大切。
正直こんな当たり前の事は小学生で習うことだが、実際上に上がる人間は、
自分の都合だけ考えて、無理な納期や予算で、強引にプロジェクト進めるという悲しい現実があることも事実だと思う。

yonemura_t
2020/12/31
金融・不動産・建設 営業 課長・主任・係長・マネージャ

費用対効果を上げる上で外部発注する機会は今後増えていくことが想定される。それを前提にすると、共通言語力をつけておくことは大切だと感じた。

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

業務で実践できる内容ですごく理解できた。

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

実施する目的は何かを明確にし、最低限必要なことは何かを明確にしてから作業することが大事だと思いました。

shu4
2020/12/27
商社・流通・小売・サービス IT・WEB・エンジニア 一般社員

業務には日付が決まっている事もありますが、その場合であっても調整する事、調整する姿勢が大切だと思いました。

kitaguninnoreds
2020/12/26
医薬・医療・バイオ・メディカル マーケティング 経営者・役員

普段の仕事にも参考になりますね。ちょっとの意味は互いに違うことを意識しないといけない。

jun-tani
2020/12/26
メーカー 営業 課長・主任・係長・マネージャ

ゴールイメージを極力具体化し、自らが主体となってやりたいことを伝え、エンジニアの立場もよく考慮することが前提として大切であることを理解した。

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

自分で経験したり見たりすることで、作業のイメージがつかめるようになり、相手の立場で考えることができる様になるということは重要だと思います。この様なコミュニケーション能力は対エンジニアのみならず、様々な場面で重要なことだと思います。

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

いま開発の要件を詰めていますが、要件を文章で書き起こすことは、せずに実施していました。
渡していたのは開発したいイメージです。
この両方を具体的に先方へ連携する事の大切さゆ今回学びました。

roro_1
2020/12/20
商社・流通・小売・サービス その他 一般社員

現在、社内のエンジニアと対話する機会がありますが、噛み合わないことあったりしますが、エンジニアの方の考え方やどのように仕事をしているかが、すこしわかってよかったです。

yuki_hiro
2020/12/18
IT・インターネット・ゲーム・通信 人事・労務・法務 一般社員

発注する際、受注する際は、最終的な成果物を明確に定義してからにする。

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

エンジニアなので、当然の内容ばかりで
得られるものはなかった。
この企業には発注したくないと思った。

andy-hik
2020/12/12
金融・不動産・建設 金融・不動産 関連職 課長・主任・係長・マネージャ

気をつけるポイントが整理されていて、わかりやすかった。

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

逆にエンジニアはお客様視点を持ってお客様に寄り添うことが大事

okai
2020/12/10
商社・流通・小売・サービス 経営・経営企画 一般社員

具体的事例が分かりやすかった。

0725_e
2020/12/09
コンサルティング・専門サービス 営業 一般社員

案件ヒアリングの際、社内情シスの上流工程案件や、SIの開発案件などアサインするポジション事に何を求められているのか、表面的な部分だけでなく体制の裏側や背景もしっかり認識する必要があると感じました。発注者の立ち位置によっても思考が異なるので、求める要件を具体化することを意識したい。

keisuke08223
2020/12/09
メーカー 専門職 一般社員

発注者として、受注者の気持ちをしっかり汲み取って、“歩み寄り“が大切なことが良く理解できました。メンバーが気持ち良く働くためのコミュニケーションの工夫が大事だと痛感しました。

kero-hachi
2020/12/09
インフラ・公共・その他 販売・サービス・事務 課長・主任・係長・マネージャ

直接アプリ開発を発注する機会があるとは思えないが、委託など外注する際の注意点として学ぶ点が多かった。
スタート時に、きちんと仕上がりイメージを持って依頼する。相手の価値観をくみ取る。最低限の仕上がりイメージを持っておくなど。
どの仕事でも、工程をイメージすることと仕上がりは大事。

yone_15
2020/12/08
商社・流通・小売・サービス 資材・購買・物流 一般社員

エンジニアへの依頼に限らず、お互いの歩み寄りは必要。特に、エンジニアの仕事の取り組み方は初めて知ることが多かったので、今後依頼する際には気を付けていきたい。

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

エンジニアの考えを理解するために、プログラムを勉強する、というのは目から鱗でした。
プログラムを勉強する事はエンジニアになる事と思ってましたが、必ずしもその必要はないという事に気付かされました。

yakoringo
2020/12/05
商社・流通・小売・サービス 経理・財務 課長・主任・係長・マネージャ

工数削減のため予算システム刷新を行い、要件定義から運用まで実施してきたが、結果的にロジックの瑕疵や思っていたとおりのものが出来ず、また運用面でも工数削減できていないことになり失敗したことがある。選定時にはできるといっていたことが要件定義の段階でできないという話が違っていたこともあったので、今後は相手の営業と技術者とは違うということも気を付けたい経験でした。

kuma1203
2020/12/04
メーカー 専門職 部長・ディレクター

エンジニアでない人にとっては、依頼時に機能や要件をはっきり伝えるということは解っていても、網羅的に重要度も反映させながら伝えるのは困難かと思われます。
見積りも提示された積算工数が正しいのかなど、ほとんど不可能なのではと思いますがいかがでしょうか。
素人には、信頼できるエンジニアを社内に採用するしかなさそうですね。

toppy_osa
2020/12/02
医薬・医療・バイオ・メディカル メーカー技術・研究・開発 課長・主任・係長・マネージャ

運用フェーズのことは忘れがちなので、最初から意識して議論しておく。

nanadog
2020/12/02
金融・不動産・建設 経営・経営企画 一般社員

運用フェーズ以降の契約内容も具体的に詰めておくことが肝要。

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

その通りかと感じました

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

開発パートナーの企業との窓口を担当しているが、発注から納品まで、エンジニアさんがどんなプロセスの仕事をするのか、大事にしているポイントは何か、ということを知ることで、コミュニケーションしやすくなる。理解や認識の齟齬が減らせると思った。
また、自分が十分に説明出来ないことを、無理に社内に報告しなくてもいい、というアドバイスで気が楽になった。

maimai0606
2020/11/27
IT・インターネット・ゲーム・通信 人事・労務・法務 一般社員

システムの発注側として、開発者と一緒に仕事をする機会もたびたびありましたので、今回お聞きして「そういうことだったのか!」という答え合わせができました。今後も開発者と仕事を共にする機会があると思いますが、開発に関する基本的な知識を得られたと思いますので、前回よりはスムーズに進行できると感じました。

satou-kat
2020/11/26
商社・流通・小売・サービス 営業 課長・主任・係長・マネージャ

社内のシステム開発に携わる際に注意すべきことが、とてもわかり易く参考になった。

mise-a
2020/11/26
商社・流通・小売・サービス その他 課長・主任・係長・マネージャ

お互いが歩み寄る。お互いの価値観を尊重する。

yoshiharu2020
2020/11/25
商社・流通・小売・サービス IT・WEB・エンジニア 課長・主任・係長・マネージャ

発注者と受注者のどちらも経験していますが、立場変わればその時の感覚は分からなくなってしまうものだと改めて感じました、
今は発注者なので、久しぶりに受注者の気持ちを思い出せました。

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

互いの認識のずれがあることを前提にコミュニケーションを行うことが重要だと思う。そのためにも、ベースとなる文書や議事録は互いのギャップを認識するために必要はアウトプットであると考えます。

0n0
2020/11/18
金融・不動産・建設 IT・WEB・エンジニア 課長・主任・係長・マネージャ

理想論として、関係者全員が気持ち良く仕事をするための心構えが大切であることは理解できる。
ただビジネスとして発注者側の利益を最大化するためには、発注者の価値にならない無駄な作業を最低限に抑えた必要十分な開発をしてもらえるよう、能力あるエンジニアを選んだり、プロジェクトを導いたりする必要がある。
その際必要となる観点やコミュニケーション方法など、実際の場で使えるノウハウを聞けるとなお良かった。

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

エンジニア、非エンジニア  両方の立場での経験があるので両方の気持ちが分かります。
初めにきちんと準備するすこと、伝えること、歩み寄ること大切だと改めて感じました。

ri_ri
2020/11/16
金融・不動産・建設 その他 課長・主任・係長・マネージャ

相手の立場に立ってみる

yoshinho
2020/11/15
医薬・医療・バイオ・メディカル メーカー技術・研究・開発 課長・主任・係長・マネージャ

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

kakichan50
2020/11/15
医薬・医療・バイオ・メディカル 営業 課長・主任・係長・マネージャ

依頼側の最終目標をより明確にし、依頼先との事前打ち合わせを十分行う必要がある。また依頼先の業務内容も十分理解したうえ、お互いを尊重し業務を進めて行く必要があると感じた。

mami_0709
2020/11/13
インフラ・公共・その他 販売・サービス・事務 一般社員

社内でシステムを開発する部門と、実際に使用する部門があるので、意思疎通がうまくいかない…ということがあるというイメージはなんとなく分かりました。
特に使う側は、画面や動作の裏側を理解していないことが多いので、ある程度の知識を以て、要望の内容が無理なことを言っているんじゃないかというくらいは判断できないといけないなと思いました。

outback25ltd
2020/11/12
金融・不動産・建設 その他 部長・ディレクター

要件定義の重要さがあらためてわかりました。打ち合わせでイメージは伝えるもののそれがいつもうまく伝わるわけではないですし、細かなところまで伝えていなかったことがあるので、今後は意識して取り組んでいきます。

yoshi-0531
2020/11/10
メーカー 営業 課長・主任・係長・マネージャ

商談フェーズ、開発フェーズ、運用フェーズの注意点を理解した。

shirakawa_0729
2020/11/08
メーカー 販売・サービス・事務 一般社員

何においても当てはまると思ったが、まずは相手のことを知る、大変さを実際分かる努力をすることが大事。

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

通常のコミュニケーション不全と共通することが多い

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

今回のは一つのケースであると思いました。自分がアプリ開発に携わったことはありませんが、様々な場面で相手の立場のなって考えることは大切なことです。

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

部下とのコミュニケーションをとるのと同じだなと思いました。
相手への気遣いが大事。

aoki99
2020/11/05
メーカー メーカー技術・研究・開発 部長・ディレクター

以前システムを発注した際、事例と全く同じことが起き、思い出しながら楽しく拝聴しました。システム以外の発注でこのような経験はなかったので、???と思いましたが、よくわかりました。

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

お互いの立場を理解するために、一歩踏み込む。

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

会社で開発する際に要件定義書の作成を行います。なぜそれが重要なのかを再認識することができました。また、自分自身もプログラムを組んでみる、ぜひやってみたいと思います。

kenji_nagahama
2020/10/31
メーカー 資材・購買・物流 課長・主任・係長・マネージャ

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

zin-124
2020/10/29
IT・インターネット・ゲーム・通信 営業 課長・主任・係長・マネージャ

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

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

プログラムのエンジニアへの非エンジニアの発注に限らず、非専門家の発注者の立場で、専門家に委託をするときの問題でと感じた。できるだけ相手の業務内容や立場を正確に理解し、寄り添えるかということに尽きると思うが、どこまで本業じゃないことを学ぶことに時間が割けるかが課題だと感じる。インタビューにあるように、委託先とざっくばらんに「同じ土俵に立つには?」と聞ける信頼関係を構築できるヒューマンスキルが欲しい。

mu_kawa
2020/10/16
メーカー マーケティング 一般社員

新たなシステムのリクワイアメントを出すとき

hayamura8803
2020/10/15
商社・流通・小売・サービス 経理・財務 一般社員

発注時はこちらが主導権を握るのではなく、共に作り上げていくイメージで取り組む。また、発注時は素人なりに具現化できるポイントは目一杯具現化するという誠意を見せる。

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

受注者側として経験したパターンでした。
「発注者と受注者の認識は必ずズレる」常にこのことを意識して歩み寄り、コミュニケーションをとっていくことが大切だなと感じました。

keitarou_1234
2020/10/13
メーカー IT・WEB・エンジニア その他

エンジニアと必要なコミュニケーションにかかわるキーワードがたくさんでてきて、勉強になりました。変更点等の難易度について常に確認しながら進めていきたい。

gomamisozui
2020/10/11
医薬・医療・バイオ・メディカル 営業 課長・主任・係長・マネージャ

なぜそうなのか?
それはそこにいるひとに聞いてこそ真実が見えてくる。
木の上に立ってみているだけでは真実は知り得ない。

user-a0de8bc751
2020/10/11
  

IT専門家とコミュニケーションのずれが発生しないようにしなくてはならない。
ニーズの伝え方が実に大切。 開発のステップ、どのステップでプログラム上決定的になって、後戻りできなくなるのか、それを踏まえないと、工数が大変なことになる。

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

プログラミング学習が小学生において必修科目になる中、部署によってある程度知識がないと仕事を進められないケースが増えてくると思われる。

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

基本はやはりコミュニケーションなのかな
全てにおいて相手の事を考える利他の心が大切

cizawa
2020/10/01
メーカー 経営・経営企画 部長・ディレクター

仕事を委託するにしても相手の考え方、仕事の内容・進め方をお互いに理解することが良い仕事のアウトプットを出す為、誤解を避けて効率的に仕事を進める上で重要であることを認識した。

kojyo
2020/09/30
IT・インターネット・ゲーム・通信 その他 一般社員

分からない業務を他に依頼するより、自分で経験してある程度理解してから他に任す方が安心で、特に何も知識がなく他に仕事を依頼した場合は依頼先の思いで依頼先の都合で仕事されてしまうので結果大変なことになると思った。

teru1125
2020/09/28
医薬・医療・バイオ・メディカル 専門職 一般社員

xxvvvvvvvvvvvvvv

haruo0323
2020/09/28
IT・インターネット・ゲーム・通信 営業 一般社員

通常の業務においても、充分参考にできることと感じました。依頼する側も仕組みなどをそれなりに判って依頼するのとしないのでは大きく違います

mooo_1221
2020/09/28
インフラ・公共・その他 営業 課長・主任・係長・マネージャ

エンジニアとのコミュニケーションに限らず、どんな仕事でも、相手への「歩み寄り」=想像力や共感力、どうすればお互いがハッピーか考える力が、根底として重要であると思いました

chagezo
2020/09/28
インフラ・公共・その他 建設・土木 関連職 課長・主任・係長・マネージャ

発注者側の視点からのお願いしたいことや知りたいことと、受注者側の視点からの知りたいことや決めてほしいことには大きなギャップがあり、そこが進捗管理における認識の違いで合ったり、費用見積もりの認識の違いにつながってしまうという点がよく分かった。エンジニアの目線になって気持ちよく仕事をしてもらえるように歩み寄りたい。

tomopi
2020/09/22
メーカー IT・WEB・エンジニア 一般社員

企業で働くすべての人に知っておいて欲しい内容でした。
上手に周りを巻き込んで、仕事を進めたいです。

colonsabuna
2020/09/21
商社・流通・小売・サービス 営業 一般社員

社内システム開発についてシステム部と協議する際のポイントとして抑えておくべき点が良く理解できた。

441
2020/09/20
インフラ・公共・その他 その他 課長・主任・係長・マネージャ

現時点ではあまりにも知識がない状況であるため,まずは言葉だけでも理解できるよう知識を増やしたうえ,「どうしたい」を明確にして,技術者と接していきたい。

doberman21
2020/09/19
メーカー 営業 課長・主任・係長・マネージャ

過去、プロジェクトの営業をやっており、社内のエンジニアに任せっきりで後々、炎上し、顧客からかなりのクレームをもらった。自分は顧客からのクレームとほぼ同じ意見であり、その後、社内と顧客との対応がかなり大変だった。今回のカリキュラムとかなり似通っている。
今回、その時の反省と照らし合わせしながら学ぶことができ、今後に活かすことができそうだ。エンジニアの視点は大事にしていきたい。

tsk1820
2020/09/19
医薬・医療・バイオ・メディカル 専門職 課長・主任・係長・マネージャ

システム関係は簡単なことでも値段が高いと感じていました。
ここで学んだようにコミュニケーションをとって要望を伝え、相互に理解することが大事だと感じました。

yuna_p
2020/09/18
IT・インターネット・ゲーム・通信 マーケティング 課長・主任・係長・マネージャ

自分でやってみてある程度の知識と理解があることによって、エンジニアへの思いやりができることが大事だと思いました。

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

講義を聞いているだけでは、大変さが分からない。簡単な物?でもいいので
なにか良い教材を見つけて、プログラミングを経験してみたいと思いました。

baramasa
2020/09/13
IT・インターネット・ゲーム・通信 マーケティング 一般社員

エンジニアと非エンジニアの関係に限らず、上司と部下や顧客と店員など様々な関係に応用出来る良い講義だと思うので、枠組みを限定したような講義タイトルになっているのは少しもったいなく感じた。

tatsukist
2020/09/13
コンサルティング・専門サービス その他 一般社員

新規立上プロジェクトの部署にいるため、クライアントとエンジニア、クライアントとオペレーションの板挟みで心身不調で離脱するメンバーが後を立ちません。要件定義は発注者タスクなのは重々承知してはいるのですが、それこそ他の開発プロジェクトが複数同時平行して少人数で進めているなか、さっぱり上がってこない要件定義や使い物にならない要件定義に赤線引いて、実現可能なレベルに翻訳して、足りない要素を追加して、ご確認頂くループで疲弊する日々。営業サイドは何でもできますスタンスだったのに、我々の部署からは制約と追加費用の話ばかりされてうんざりの苦言ばかりで、本当に互いが不幸だなあと思ってます。当社として要件定義の在り方、抜本的に見直さないとと思いつつ、営業部のサービス範囲の説明を改善してほしい。

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

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

hashimoto-8006
2020/09/09
メーカー メーカー技術・研究・開発 一般社員

双方の歩み寄りと具体的なコミュニケーションでいいアウトプットが作れるんだなと認識しました。

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

おっしゃる通り。ただ企画時は発注側もそこまで明確に完成形が出来ていないので、最初のイメージ合わせはかなり難しいです。

ultrarunner4
2020/09/06
医薬・医療・バイオ・メディカル 経営・経営企画 課長・主任・係長・マネージャ

非エンジニアで日々発注をしている者として、発注前、開発開始前にエンジニアとは商品仕様、開発工数の話をしっかりとするようにしています。その中で、課題やリスクを洗い出し、お互いに共通認識をもってスタートすることが大事ではないかと考えています。

ma_2001
2020/09/05
インフラ・公共・その他 マーケティング 課長・主任・係長・マネージャ

エンジニアに歩みよるためには、一定量の知識が必要だと思いました。まずは、画面設計イメージと要件定義をどのように書き起こすかを考えるところから実践したいです。

sk-kdrni
2020/09/05
医薬・医療・バイオ・メディカル その他 課長・主任・係長・マネージャ

エンジニアとの会話を思い起こすとあるあるが多々あります。お互いの意思疎通が成り立つよう歩みよりが重要であることが理解できました。

thigashi
2020/09/02
メーカー 販売・サービス・事務 課長・主任・係長・マネージャ

現場システム担当的な立場なので非常によく判る内容で、部署でシステム導入等する場合にはいつもこのパターンです。が、これを理解できていても解決できないと断言できます。理由は決定権のある人間がシステムを理解しておらず、またそういう人はこの講座を見ることもないから。

og_8888
2020/09/01
メーカー 資材・購買・物流 一般社員

実際にシステムユーザー側として、要件定義、画面設計に携わったが、ユーザーとしてどのような機能があればより使い勝手が良いかにフォーカスして話をしていた。
最低限必要な要望はしっかりと伝えるべきだが、エンジニアにコミュケーションを取る上で最低限必要な知識レベルについて確認することも重要と感じた。

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

自分自身はエンジニアだが非エンジンアの視点に立って仕事をすることができるように仕事をすることが大切だと思った。

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

サービス企画時に発注側が仔細を詰めてから発注しないとこういったことになるんだと思います。
しかし、技術が急速に進歩していて、エンジニアの専業化分業化が進行し、非エンジニアの知識が全く伴っていない状況です。
相互の間に立つ「通訳」が必要になってきているんだと思います。

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

最初の要件定義にもっと力を入れるべきかと思います。

aji_haruka
2020/08/27
メーカー メーカー技術・研究・開発 一般社員

コミュニケーションをとるうえで、必要な知識を持っておくというのは、どのような仕事においても大切なことだと思った。情報の非対称性に留意して確認作業も大切だと思った。

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

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

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

yoshikatsu08
2020/08/26
IT・インターネット・ゲーム・通信 経営・経営企画 課長・主任・係長・マネージャ

同じ様な立場にいるので良く理解できました。

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

エンジニアやってる身としても知らないとそうなるのかという発見があった。

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

発注する場合、相手に任せるだけではなく、ポイントポイントで内容を確認できるようにする必要があることが理解できた。それには、全体まではわからずとも、ある程度内容を理解する知識が必要であることがわかった。

tottokonkmr
2020/08/25
医薬・医療・バイオ・メディカル メーカー技術・研究・開発 一般社員

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

masaha
2020/08/25
金融・不動産・建設 金融・不動産 関連職 課長・主任・係長・マネージャ

ビジネスサイドから見えにくい部分の説明が有益でした。

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

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

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

エンジニアの仕事の内容も少しは把握すれば、より優れたアプリ開発につながる要望もできるということを学びました。

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

私は文系ですが、実際に業務改善や、アプリ開発といったあたりに少しタッチしていますが、このケースで紹介されていた「ダメなコミュニケーション」を実際にやっているケースがあり身につまされました。

sano_wawa
2020/08/20
メーカー メーカー技術・研究・開発 部長・ディレクター

どのようなアプリでも言えると思うが、万人に最適なものはなく、最終的にはユーザーが慣れるしかないと思うので、発注者もそのような視点で割り切ったアウトプットイメージを持つべきだと思った。

penerope
2020/08/18
メーカー IT・WEB・エンジニア 課長・主任・係長・マネージャ

エンジニアの仕事内容やこだわり、言われると嬉しいこと、悲しむこと、これらを理解しておくことが発注者にとって大切であることが理解できました、

junbeat
2020/08/17
IT・インターネット・ゲーム・通信 マーケティング 課長・主任・係長・マネージャ

内容が薄く感じた。特に開発フェーズは最初の商談フェーズも重要だが、非常に重要なフェーズだと思うので、その点の対処策の内容がイメージが湧かなかった。

uppop
2020/08/17
IT・インターネット・ゲーム・通信 マーケティング 一般社員

目的を決めること、職種が違えば共通言語を持つことが大事

yuko_kamigaki
2020/08/16
メーカー 人事・労務・法務 課長・主任・係長・マネージャ

現在は自社アプリやソフトを開発する仕事は発生しなさそうなのですが、どんな仕事でも発注者・受注者双方の論理を知ることは大切だと思います。
「エンジニアへの歩み寄りが大事」というキーワードはとても印象に残りました。
プログラミングが義務教育にも取り込まれる時代ですから、「ここから先は委託したらいいんだよ」という丸投げ思想は捨てて、機会があったらプログラミングを学ぼうと思いました。

kazu168
2020/08/15
メーカー メーカー技術・研究・開発 部長・ディレクター

最初の要件定義できちんと議論をして、決めておくことが必要だと感じました。
ただ実際にできてくるもののイメージができていないと、その要件でよいのかが判断できない、実際に発注する側として、相手の考えをどこまで知ることができる技術を持つべきかは、まだよくつかめていません。

toshikamo
2020/08/15
金融・不動産・建設 販売・サービス・事務 課長・主任・係長・マネージャ

社内、社外問わず、業務要件をとりまとめ、
システム部、システム会社へ伝えることの
難しさを思い出させられました。

taka55555
2020/08/15
商社・流通・小売・サービス 経営・経営企画 部長・ディレクター

システム発注者との予算の打ち合わせや進捗管理時の参考にします。

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

非エンジニアとして、まさに発注をしているところであり、この動画で指摘されていた点について、まさに課題として直面しています。
非常に参考になりました。

jabe
2020/08/14
IT・インターネット・ゲーム・通信 営業 一般社員

納期を決めつけない。見積もりを信じるというのはなるほど思った。

jeanaugustchen
2020/08/14
メーカー 資材・購買・物流 一般社員

今の仕事はエンジニアと係わることがないのですが、将来そういった場面には役に立つだろうと思っております。エンジニアとのコミュニケーションというよりかは、違う仕事としている人たちと接する最低限のコミュニケーションを指しているではないかと思います。お互いに「当たり前」のことはお互いに理解できなかったのはそのコア原因だと考えています。勿論、お互いにしることは大切ですし、やるべきと思いますが、「専門家」からわかりやすい説明をした方が正直なところいいかと思います。うまれてから専門家になっているわけではないので、専門家自分自身の歩み寄りも当然理解していますし、非専門の人から一生懸命勉強するよりは、専門家からの「合わせ」は全プロジェクトを考えていくと早いのです。

haru-fu
2020/08/13
メーカー 経理・財務 一般社員

システム開発は発注者側として何度か関わってきました。今回のお話のような、進め方の基本やエンジニアさん目線を知った上で関われたほうが、もっと仕事はスムーズに進められたなと感じました。特に具体的イメージを伝える部分は、とても重要だと思います。今後は完璧でなくても、視覚的に伝えていくことを、きちんと意識していきたいと思いました。

saitoh_0830
2020/08/12
メーカー 経営・経営企画 一般社員

非エンジニアとして社内システムを構築していくためにも、最初の要件定義、と構築後の具体的なイメージを持つことが重要である。
エンジニアへの歩み寄りが大事ということはミスコミュニケーションによる成果物の完成のズレ、余計な費用の発生を防ぐことと理解して、発注者側になったときに気を付ける必要があると認識した。

sanzoboshi
2020/08/12
医薬・医療・バイオ・メディカル メーカー技術・研究・開発 部長・ディレクター

ITエンジニアとの協同作業を進める上で、エンジニアにどの位のレベルの知識があれば、理解し合えるかを聞き、発注者としての力量を付けると、過不足ない努力が行えるので良い。

ko1_yama
2020/08/12
メーカー IT・WEB・エンジニア その他

私もIT部門の立場で、ユーザ部門と開発委託者の間で、同じような場面に何度も遭遇してきました。システム開発において、ユーザ側は、要件定義の段階で、仕様を明確にするこはできないため、開発が進んだ段階で、追加要件があふれることは本当によくあることなので、最近は、プロトタイプアプローチで、早い段階で、ユーザとのGAPを埋めるこが有効であると感じてます。
一方、開発委託者に対しても、自己都合、技術用語を並び立てるのではなく、利用部門に寄り添った進め方をお願いしてます。
また、発注者側の立場で、開発費用や進捗状況の妥当性について、上司に納得するためは、自分自身が、当該開発について、しっかりとした理解、見識を有したもとで、説明することが必要だと思っています。

hottton
2020/08/10
メーカー IT・WEB・エンジニア 課長・主任・係長・マネージャ

商談のステージで、発注者側が画面イメージを持っていることが、その後の流れを止めないために最も重要と感じた。発注者としても、画面イメージを作る中で自ら何が必要かを改めて認識し、最低限必要なこと、システムに合わせて変えてよいこと、変えられないことを明確にすることができるだろう。

j_mitsu
2020/08/10
メーカー 人事・労務・法務 課長・主任・係長・マネージャ

エンジニアとのやり取りにおいて、同様のミス・コミュニケーションが起きた事例を身近に見たこともあり、エンジニアに歩み寄る姿勢が成果物の質に影響することを再認識させられた。プログラミングをもう少し学びたいと思う。

yuki_0719
2020/08/09
メーカー マーケティング 部長・ディレクター

システムについては知識がないため、納期やデザインイメージなどを伝えてマネージすることをしがちであったと思う。開発者の拘りや、仕事のプロセスを理解することで、よりよいシステムが作れるということが良くわかった。また運用フェーズについては事前での確認が重要であることを理解でき、今後のシステム開発にむけては注意しようと思った。

guchi2020
2020/08/08
メーカー 資材・購買・物流 部長・ディレクター

私も非プログラミングエンジニアですが、ITベンダーに発注する業務をしています。日頃から相互理解の難しさと大切さをかんじておりましたので、今回の講義がすんなりと腹におちました。

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

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

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

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

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

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

mirai100
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・インターネット・ゲーム・通信 営業 課長・主任・係長・マネージャ

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

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

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

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

hottton
2020/06/29
メーカー IT・WEB・エンジニア 課長・主任・係長・マネージャ

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

sakuranohana
2020/06/28
広告・マスコミ・エンターテインメント 人事・労務・法務 一般社員

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

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

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

koike_123456
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
メーカー マーケティング その他

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

saze2021
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
メーカー 経理・財務 一般社員

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

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
商社・流通・小売・サービス マーケティング 一般社員

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

退会したユーザーです
2020/04/12
  

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

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

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

gogo60
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
メーカー 販売・サービス・事務 一般社員

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

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

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

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

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

masuchan
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・エンジニア 課長・主任・係長・マネージャ

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

yoshiaki-s
2020/01/20
金融・不動産・建設 人事・労務・法務 課長・主任・係長・マネージャ

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

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

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

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

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

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

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

vegitaberu
2019/12/17
広告・マスコミ・エンターテインメント 人事・労務・法務 一般社員

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

hirotomf
2019/11/05
インフラ・公共・その他 その他 課長・主任・係長・マネージャ

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

runnermasa
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
金融・不動産・建設 販売・サービス・事務 一般社員

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

kohei0424
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
メーカー 資材・購買・物流 課長・主任・係長・マネージャ

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

hashizou01
2019/07/05
広告・マスコミ・エンターテインメント 経営・経営企画 経営者・役員

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

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

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

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

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

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

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

nishinomiya
2019/06/22
メーカー 経理・財務 課長・主任・係長・マネージャ

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

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

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

shinya923
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
金融・不動産・建設 販売・サービス・事務 部長・ディレクター

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

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

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

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

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