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

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

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

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

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

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

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

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

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

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

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

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

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