アカウント名:
パスワード:
フリーランスで長いことSE/PGをしていますが、以前いた現場に派遣PGとしてやってきたインド出身の男性。席が近かったので良く喋ったり、一緒に昼飯に行ったりしてましたが、諸々の事情からお金がもうちょっと必要だと言う話を聞き、それならと、私のツテのエージェントから個人で請け負える程度の仕事話をいくつかピックアップしてもらってそれを伝えたところ、出来たらやりたいと。
当然自然な流れでそのまま「どのくらいで行けそうと思う？（期間の事）」と尋ねると、「まぁ、二週間かな」と返事。
・・・ええと。その時点で彼に伝えていたのは、要件とざっくりとした環境のみであって、機能の数や詳細、サーバの様子なんかは一切話していない状態だった。
「そこは、『詳しく聞かないと見積もれないよ』と応えるべきでしょ（笑）」と言うと彼はものすごく真面目な顔になって、何故自分が二週間と答えたかをなんだかよくわからない理屈で、こちらを説得するような口調で話し始めた。ちなみに彼の日本語はとても流暢。
この感じ、別に偏見がある訳では無いんだけど、なんとなく似ている感じがするなぁと思いだしました。簡単に言うと、まぁ、雑なのかな。
うーん、ビジネスでのリクエストに関して、「わかんない」という回答が許されるのってどこか特有の文化ということはないですか？返事はYESじゃなきゃNOだし、他人に分かろうと分からなかろうと、自分の回答に対する何らかの「理屈」を説明しなくて済む世界というのがうまく想像できません。
いやそういう話では無いと思う。
わたしもそういう話ではないと思います。
回答するために必要な情報を与えられていない場合、１．XXXという情報がなければ回答できない２．一般的なケースとして（あるいはこれまでの経験から想定して）○○と仮定した場合、と前提条件を付けて回答する
上記のいずれか、あるいは両方。１は技術に暗いIT部門担当者が多い日本ではそれなりのリスクがあるし、２は回答した値だけを一人歩きさせるバカな連中がいるので、どちらも回答の仕方は熟慮するが（簡単に言えば双方が納得する形で記録に残す等ね）。
必要な情報を聞かずに回答する技術者は信用しないし、こちらが発注側の場合は逆にわざと情報を抜いて話して、そこを確認してくるかどうかで相手の力量を判断したりもする（相手が初見でいまひとつ人柄などが分からない場合はね）。
コメントありがとうございます。仰っていることは分かります。ただ、完全にオフトピックですけど、日本でAgile開発が定着しないのってこういう違いなのかな、と思いました。
雑でもいいからとりあえず作る。前提が変わる。直す。前提がまた変わる。また直す。
こういうAgileっぽいのって、元コメのインド人の方が得意だろうなと思うんです。それが良いとか悪いとかは別として…。
Agileっぽいのって別に悪いことだとはまったく思いません。むしろ時代の要求に応えるすごく分かりやすい手法だと思います。ただ日本で普及し難い理由として、少し別な要因を感じます。
Agileではシステムを互いに疎結合な小さなUnitに分割し、それを重要なものから開発していきます。仕様に変更が有ったら、その仕様に該当する部分の旧Unitを新しい仕様に合わせた新Unitに置き換えます。当然、旧ユニットは不要ですからばっさり廃棄するのが基本ですが、これが日本人（特にウォーターフォールで育った旧世代）には感情的になかなか受け入れ難いのではないかと。せっかく作ったのに勿体ないとか（その部分の作成にかかった費用を誰が持つんだと横槍が入ったり）。プロトタイプ式の開発がうまくいかなかったのも、同じ問題だったと聞きますし（捨てなきゃいけないプロトタイプを本番システムのベースに当然のように使い回していたらしい… そりゃ品質に問題でるでしょうね）。
コメントありがとうございます。「失敗が許されない」と言われる日本文化とウォーターフォール型開発って相性がいいんでしょうね…。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
とある実話 (スコア:2, 参考になる)
フリーランスで長いことSE/PGをしていますが、以前いた現場に派遣PGとしてやってきたインド出身の男性。
席が近かったので良く喋ったり、一緒に昼飯に行ったりしてましたが、
諸々の事情からお金がもうちょっと必要だと言う話を聞き、それならと、私のツテのエージェントから
個人で請け負える程度の仕事話をいくつかピックアップしてもらってそれを伝えたところ、出来たらやりたいと。
当然自然な流れでそのまま「どのくらいで行けそうと思う？（期間の事）」と尋ねると、
「まぁ、二週間かな」と返事。
・・・ええと。その時点で彼に伝えていたのは、要件とざっくりとした環境のみであって、
機能の数や詳細、サーバの様子なんかは一切話していない状態だった。
「そこは、『詳しく聞かないと見積もれないよ』と応えるべきでしょ（笑）」と言うと
彼はものすごく真面目な顔になって、何故自分が二週間と答えたかをなんだかよくわからない
理屈で、こちらを説得するような口調で話し始めた。ちなみに彼の日本語はとても流暢。
この感じ、別に偏見がある訳では無いんだけど、なんとなく似ている感じがするなぁと思いだしました。
簡単に言うと、まぁ、雑なのかな。
Re:とある実話 (スコア:1)
うーん、ビジネスでのリクエストに関して、「わかんない」という回答が許されるのってどこか特有の文化ということはないですか？
返事はYESじゃなきゃNOだし、他人に分かろうと分からなかろうと、自分の回答に対する何らかの「理屈」を説明しなくて済む世界というのがうまく想像できません。
Re: (スコア:0)
いやそういう話では無いと思う。
Re: (スコア:0)
わたしもそういう話ではないと思います。
回答するために必要な情報を与えられていない場合、
１．XXXという情報がなければ回答できない
２．一般的なケースとして（あるいはこれまでの経験から想定して）○○と仮定した場合、と前提条件を付けて回答する
上記のいずれか、あるいは両方。１は技術に暗いIT部門担当者が多い日本ではそれなりのリスクがあるし、２は回答した値だけを一人歩きさせるバカな連中がいるので、どちらも回答の仕方は熟慮するが（簡単に言えば双方が納得する形で記録に残す等ね）。
必要な情報を聞かずに回答する技術者は信用しないし、こちらが発注側の場合は逆にわざと情報を抜いて話して、そこを確認してくるかどうかで相手の力量を判断したりもする（相手が初見でいまひとつ人柄などが分からない場合はね）。
Re:とある実話 (スコア:1)
コメントありがとうございます。
仰っていることは分かります。
ただ、完全にオフトピックですけど、日本でAgile開発が定着しないのってこういう違いなのかな、と思いました。
雑でもいいからとりあえず作る。
前提が変わる。
直す。
前提がまた変わる。
また直す。
こういうAgileっぽいのって、元コメのインド人の方が得意だろうなと思うんです。
それが良いとか悪いとかは別として…。
Re: (スコア:0)
Agileっぽいのって別に悪いことだとはまったく思いません。むしろ時代の要求に応えるすごく分かりやすい手法だと思います。
ただ日本で普及し難い理由として、少し別な要因を感じます。
Agileではシステムを互いに疎結合な小さなUnitに分割し、それを重要なものから開発していきます。
仕様に変更が有ったら、その仕様に該当する部分の旧Unitを新しい仕様に合わせた新Unitに置き換えます。
当然、旧ユニットは不要ですからばっさり廃棄するのが基本ですが、これが日本人（特にウォーターフォールで育った旧世代）には感情的になかなか受け入れ難いのではないかと。せっかく作ったのに勿体ないとか（その部分の作成にかかった費用を誰が持つんだと横槍が入ったり）。
プロトタイプ式の開発がうまくいかなかったのも、同じ問題だったと聞きますし（捨てなきゃいけないプロトタイプを本番システムのベースに当然のように使い回していたらしい… そりゃ品質に問題でるでしょうね）。
Re:とある実話 (スコア:1)
コメントありがとうございます。
「失敗が許されない」と言われる日本文化とウォーターフォール型開発って相性がいいんでしょうね…。