＼回答があります！／

• 

  北野勝久

  エンジニア

  2年前
  エンジニアリング的思考とは少し違うかもしれませんが、ものづくりにかかるコストでプロダクト開発の方向性を考えすぎないよう気をつけないとな…と思っています。
  
  最終的にプロダクトをつかう人がどういう価値・体験を受け取ってもらえるかを集中検討したい時に、実装段階で気にすれば良い観点が思い浮かんでしまうと、そもそも価値検証も終わっていないアイデアに対して蓋をしてしまうことになりかねないな、と。価値検証を進めるにあたっては、そもそもプログラムを実装することである必要はないですし。
  
  もちろん、最終的に何かしらの製品にしていくので、事前にリスク判断できているだけでは？と言われればそうなのですが、お客さんが欲しいと思えるなにかが見つかれば、ソフトウェア開発以外の方法で価値提供することを優先することもできますし、あまり実装の難しさ・コストで自分たちの思考を狭めるともったいないなあ、と。
  view数 14
  • 2
  • 1

• 

  和田健太郎

  エンジニア

  2年前
  若干質問に対する回答として直球ではないかもしれませんが
  「未成熟なエンジニアリング（？）的思考」がプロジェクトに良くない影響を及ぼすなあと思っているのは、「人月の神話」です。
  
  （書きながら「これはエンジニアリング的な思考」ではないなと思いつつ、である点はご容赦いただけると幸いです）
  
  プロジェクトを遂行するにあたって、「成果物を増やすためい人員を増やす」「人員が足りないためアウトプットが追いつかない」などのやり取りが発生している場合は「待った冷静に」という感じです。クライアントやビジネスサイドにて「どんな人が」「どんな役割で」みたいなものが抜け落ちて、ただプロジェクトに対して人月だけを当て込んでゴールまでの目算を納得してしまうことが意外にもあるという経験をしたことがあります。
  結果的は、コミュニケーションコストやスキル感などの配慮が足らず、思っていたスケジュールが達成できなかった、思ってたのと違って手戻り、みたいなことの発生要因になるよなあと思っているので、注意しなければならないなあと思っています。
  view数 11

• 

  山本隼汰

  エンジニア

  2年前
  どうしても発想が連続的になりすぎてしまうことですかね。PdM とエンジニアのロールを兼任していた時は特にそれを感じていました。
  
  具体的には、現場のシステムを知りすぎていることによって、発想に制約がかかってしまってしまい、本当はもっと高い理想を掲げて、その途中にあるMVPや試作品を作るべきなのに、「これは難しいな」とか「これはめんどくさいかも」とか逡巡してしまい、アイデイエーションで本来やりたいユーザーの課題解決に無意識的に制約を欠けている時がありました。
  
  それを回避するためには、ある種の二重人格を演じないといけないのですが結構難しくて、つい慣れている開発サイドの発想をしてしまう時はあった気がします。結果的に、現実的にできる連続的な解決策を提示しがちで、（これ自体は悪いことではないですが）アイデア出しや企画立案としてはお世辞にも良いとは言えないな、と感じていました。 （編集済み）
  view数 9

• 

  Shoichi Namba

  エンジニア

  2年前
  エンジニアは開発のプロであり、デザインや事業組み立てのプロではないので、そこの境界線をはみ出して色々と発言しすぎるとプロジェクトの妨げになるケースが増えると思います。
  
  例えば「普通こういうところはこういうUIで、だいたいこういうボタンが有るもんだ」と開発視点で話しても、実はその裏でちゃんとどういったUIがプロダクトにとって望ましいかという話し合いが行われて決まっていたりして、その結果MTGの時間を無駄に浪費して全員の時間を奪ってしまったりということはわりとありがちなことな気がします。
  
  もちろんエンジニア視点でしかきづいきにくい部分の指摘をしてあげることで改善が見込まれる場合もありますが、基本的にはそれ以外の他のメンバーの業務と考えを尊重して業務に臨むことも重要なことであると思います。（もちろんこれはエンジニアも良かれと思ってやってしまっていることだと思うのでそこがまたコミュニケーション的に難しいところでもあるのですが）
  view数 13

• 

  makoto tanaka

  プロジェクトマネジメント

  2年前

  エンジニア以外の方でエンジニアのこういう立ち振る舞いは少し悪影響があった

  エンジニアが実装する中で「よしなに実装」するケースがあると思いますが、良いケースと、悪いケースがありました。
  以下は、エンジニアだけの責任とは言えない話も含まれるので一事例としてです。
  
  ## 良いケース
  - PMやデザイナーがフロントエンドの動き・挙動までを細かく要件定義していない、リンク/リダイレクト先の指定など実装してみたら使いづらい、などの場合によしなに修正している
  
  ## 悪いケース
  - 自分が利用しやすいように実装し、出し戻し・全削除など
  　- what、whyを考慮されていない、他の人が使いづらい/利用ケース/機能の汎用性を考えられていないなど
  - 実装すべき内容とそれ以外にも気になった部分を追加実装してしまう
    - scopeを無視した追加実装により、実装確認とテスト項目が増えてリリースが遅延する （編集済み）
  view数 10
  • 1