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

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

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

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

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

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

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

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
メーカー メーカー技術・研究・開発 課長・主任・係長・マネージャ

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