開発前のヒアリングでの確認ポイントは？

質問

現在、私は、顧客の会社内で開発業務を担当しています。

そこで、顧客から、「～～のようなツールを作ってほしい」
と随時、依頼が入ります。

現職場では、そのような場合、「改善依頼ヒアリング」という
簡単なミーティングが行われるのですが、
いったい、どういうことを確認したらよいのでしょうか？

・技術要素（要求される昨日）
・急ぎかどうか
・急ぎじゃないなら、いつごろまでにほしいかどうか
・作れそうにない場合、いつまでに報告すればよいか

ざっと、上記４つのようなことは、前任者が確認していたので、
確認ポイントとして、私もなんとなく覚えているのですが、
もう少し具体的に、どういうところを詰めたらいいか、
この業界の諸先輩方に教えを乞いたいと思って
質問しました。

打ち合わせでは、
顧客としては、「～～のような機能が実現可能かどうか」
を知りたい、というのも目的の一つのようです。
ヒアリング中、「～～ってできますか？」と聞いて、
もちろんその場で即答はできません。

前任者の作ったソースがあって、それによって、
どのくらい工数がかかるかどうか変わるため。

というのも、現在、顧客が使うツールのほとんどは、
前任者が作ったものであり、それの改善（機能追加、修正）を依頼されるため、
私はまだ、すべてのツールのソースを把握しているわけではないからです。
（ほとんどのソースを把握してません）

そのような場では、どういったことを特に確認したらよいのでしょうか。

言語は、主に AccessVBA です。

回答No.1

めとろいと（@naktak） · ベストアンサー

相手から一方的に確認を受けるものではありませんが、
　予算感
　実現手段(提案・妥協案)
は必要でしょう。

> ヒアリング中、「～～ってできますか？」と聞いて、
> もちろんその場で即答はできません。
あなたが開発するなら、ほぼ即答できるようになっていないといけませんね。
システム改修だと、基本的に周辺機能に影響を及ぼす為、「できます」、
「できません」だけじゃ済まなくて、「どこどこでどうなっているが、そこの思想は
どう対応、もしくは変化するのか？」となると思います。
それはソースがどうのこうのではなく、あなたの技術的知識とシステム運用知識の
範囲内で、どの部分に影響を及ぼし、どう組み立てれば可能かどうかです。

その改修で工数がどのくらいかかるかは別問題です。
顧客が理想とする仕組みが予算を大幅に超えたりするならば、そこから妥協案で
工数が少なく済む方法を提案・見積りするなどでしょう。

お礼

ご回答有難うございます。

書いたお礼が消えてしまったので、再入力しています。

こちらのご回答が、もっとも私の現場に当てはめてイメージしやすかったため、ベストアンサーとさせて頂きました。

予算感とは、こちらの開発工数と、先方の業務にかける作業時間のというイメージですね。
妥協案の提案は、とても有効そうですね。
とても参考になりました。

有難うございました。

回答No.3

ninoue

次の@ITのサイトがシステム開発やソフト開発関連の情報が豊富なようです。(ご存知かとも思いますが)

http://www.atmarkit.co.jp/
@IT

http://jibun.atmarkit.co.jp/lskill01/index/index_all.html
==>
http://jibun.atmarkit.co.jp/lskill01/rensai/req/01/01.html
上を目指すエンジニアのための要求エンジニアリング入門

http://jibun.atmarkit.co.jp/lskill01/rensai/takumi/01/01.html
ソフトウエア開発の匠

具体的な回答ではないのですが、参考になるのではと思われます。
その他にも多数の記事がありますので調べてみて下さい。

お礼

ご回答有難うございます。

参考になるリンクを有難うございます。
こういう情報は、あとで時間のある時にじっくり勉強できるのでとても嬉しい情報です。

有難うございました。

回答No.2

lv4u

プログラムというか理系の場合、文系のように人間関係・情に訴える・相手の弱みを探して脅すなどの手法は、使えないこともないでしょうが、本来の問題解決にはなりません。
結局のところ、「できるか、できないか？、できるなら１日でできるのか、１週間か、１ヶ月かかるのか」ということが問われると思います。

ですので、「コードを調べないと分かりません」と、正直に言うのがいいとは思うのですけど、それが言える状況でないとしたら、とりあえずその場はハッタリをかまして、大きく違いが出るなら再報告するしかないように思います。

ただ、気になるのは、こういう質問をこのようなサイトに投稿していることです。バブル前の企業であれば、こういうことは、社内の先輩から教えてもらうことであり、企業は先輩が後輩社員を教育するのが当然でした。また、開発現場においては、他社の派遣社員であっても、新人であれば、いろいろと教えてあげていたものです。
担当が交代するときは、新しい担当が慣れるまで、先輩がある程度の期間、一緒に働くのが普通でした。

質問者さんの職場は、企業は新人教育をすることを放棄しているのでしょうか？質問する相手がいないのでしょうか？こういったサイトが企業内教育の代わりの機能を果たしているようになったのでしょうか？
どうも、社内でいろいろと先輩に質問していて、それでも疑問のある点をこのサイトに質問しているっていうなら、わかるのですけど、それとはちょっと違うような感じがしますので。

お礼

有難うございます。
結局のところ可不可と工期ですね。はったりも時には必要なのかもしれませんね。
現職場は、クライアントとの距離が近く、日頃から顔を合わせているため、歩み寄りも可能のようです。歩み寄りの提案をすることで、安心感・信頼感も高まるような気がしています。急ぎの場合、クリティカルな部分だけを先に作ってしまうとか、システム化できない部分は、人の手で（クライアントが作業時間を費やして）、なんとか運用してもらう、ということを妥協案として出すこともあるようです。

工数を見積もって、こちらが担当している他の開発案件のスケジュールなども示し、「残業が発生しそうだな」とか「手頃な仕事だな」というレベルのところまで伝えることで、あとは先方の予算感にゆだねるやり方、という感じでしょうか。

おっしゃる通り、こういったことは、先輩から教わるものだと思います。私の場合、前任者の方の退職が急に決まり、急きょ私が後任として配属された、という経緯があります。前任者が一人で作り上げたシステムなので、社内に残るのは、発注者と、ユーザーさんだけという状況なんです。

ご回答有難うございました。