アカウント名:
パスワード:
日本での事情に限定します（外国の状況には詳しくないので）が、記事の分析通り、要件定義を軽視しすぎていると感じます。要件は開発者側だけで決定できるものではありませんから、利用者側の都合で変更や追加が発生することはやむを得ないとしても、・十分なヒアリングや検討を行い、変更の可能性を最小限に抑える・それでも変更が発生してしまった場合は、工数を見直し、納期やコストが変動することに合意いただく・「なぜこの要件なのか（要件が変更されたのか）」を最前線の開発担当者にも伝え、利用イメージを共有するといったことが重要になると考えます。
私た
自社の管理職・上級職だけがネックならまだしも、客も同レベルだから救いようがない。しかも自分たちに問題ないと思ってるから、同じ失敗を何度も繰り返す。
受注側の作成する要件定義もあやふやなのは発注側の要件定義が不透明なのが原因
当然客に明確な答えがあるわけではないので要件を物理レベル近くまで具体化しなければいけない、時間をかけなければいけない。
が、見切り発車の炎上が常。
どんなに具体的に説明しても、客に「説明から出来上がりをイメージする力」がないから見切り発車せざるを得ず、ある程度進んでから「こうじゃない」と言われて要件を調整。というのが前提で、いかに巻き戻しを少なく見切り発車するかがミソというバッドノウハウ。
末端作業者がパソコンの操作もおぼつかないようだと、出来たモノに「こうじゃない」「こうしてくれ」という要求をアウトプットする能力すらないことも…
プロトタイプでも紙芝居でもいいので、画面レベルで動きを見せるのが必要だし、実際に行っていると思います。顧客に出来上がりをイメージする力がないのと同様、開発側には業務の隅々まで察知する力はないので、細部にわたって要件を詰めないといけないのですが、曖昧な部分が残ってしまい問題となるのが実情でしょう。
それを改善するためにどうするかを意識し、バッドノウハウで済まさないことが、要件定義工程に求められるスキルかな、と思います。
＞開発側には業務の隅々まで察知する力はないので、
これが、現状の最大の問題。最下層までは無理でも、開発側の中流には「顧客の用途」を知っている人間が関わるべき。何度も言ってるが、プログラマはプログラミングだけじゃなく、ユーザ側の業務知識が無いと無能なんだよ。
言語なんていくつ覚えても、例えば、帳簿の付け方を知らずに会計関連の仕事が出来る筈が無い訳。「公認会計士の資格を持ったプログラマ」なら、会計関連の仕事を高価に受注可能か思われるけど、如何？//逆も真なんだけどね。
無能という表現はどうかと思いますが、おっしゃることはわかりますし、同意できる部分はあります。要件が曖昧で設計者が業務を理解していないと、往々にして開発者の思い込みで機能が作り込まれ、顧客の要望から食い違ってしまうことがあるので、顧客に近い上流の段階で不明点はつぶしていかないといけないでしょう。
「公認会計士の資格を持ったプログラマ」なら、会計関連の仕事を高価に受注可能か思われるけど、如何？//逆も真なんだけどね。
どうだろう。当方、「中小企業診断士の登録を受けた開発担当者」ですが、実感として人月単価（客先常駐です）そのものはそれほど上がっていない印象です。業務自体は上流をやらせてもらえるようにはなったし、工程が上がることで人月単価は上がりましたが。
公認会計士の資格を持った中層から下層のプログラマがいれば、曖昧な仕様もカバーできるってこと？
設計者の怠慢の言い訳じゃないの？相当の知識がないと理解できない仕様じゃ、仕様書とは言わないんじゃない？
発注受注どちらでもなくコンサルの立場で間を持てないかと双方に提案したことがありますが、いずれにもノーと言われましたねえ。その前年には発注者側で火消しに入って業務終了時にはずいぶんと持ち上げられもしましたけど、第三者として間に入るとなると事情も違うようで。
炎上させといて発注元に常駐する他社の技術者に事態収拾を頼みにくるような所なんで、提案の翌年に「うちのメンバーとして入って欲しい」といわれた時もさすがにお断りしたなあ。
「プログラマ」を語義どおりにとれば設計担当者の怠慢となりますが。元の人、「開発側の中流」という言い方もしているので、設計も含めた開発側の要員を総じて「プログラマ」と呼んでいるかもしれません。（元の人の反応待ちです）
いずれにしても、要件や仕様が曖昧なまま実装に入れば、顧客との認識のずれや手戻りも多く、プロジェクトの遅延要因となります。実装者に業務知識があれば、要件を詰める必要があるとアラートが上がる可能性はありますが、実装者に業務知識にあるという前提に頼るのは危険ですし。（勉強会などで、十分な業務知識を積ませてあるならリスクは下がりますが）
アラートが上がってもそれを拒否して、不正確な仕様のまま実装を押し付ける要件決定者やPMもありますが、論外ですね。
呼ばれたので追記しておきます。
何事も、100%はありません。仕様書も100%文言通りに実装して済む様な代物は作成不能です。それでも、せめて実装可能な程度の仕様書は作成するべきでしょう。これは、上流側の責任だし、特にシステム全体の結合については、下層が把握するのは無理だからです。（下層には自分の担当範囲がシステムに与える影響を把握する義務が在るが、他チームの分まで担当するんじゃチーム分けの意味が無い）
顧客の要求の汲み出しは、本来は上流の仕事ですが、「実装する下層だから気付く問題」ってのも存在します。「実装するまで分からない」機能を要件定義の時点で決める事も現実的では無いので、その部分は「下層に任せる」事になります。
で、私の発言は、この状況での下層のレベルへの言及です。
但し、顧客と直接対話するのは上流だけでしょうから、上流側にも十分な能力は必須です。
＞実装者に業務知識にあるという前提に頼るのは危険ですし。
これも、100%を望むから危険なのです。実装者が失念する可能性は常に在るので、多階層でのチェックは不可欠です。逆に、多階層でのチェックを有効に実施するには、各階層に業務知識を持った担当が存在する事が前提です。
尚、「プログラマ」の呼称は、「相対的な下位担当」のつもりで使用しています。ごく小規模な場合を除いて、最終的なシステムの規模から必然的に階層化される筈で、規模に応じて階層が増えるので、上位と下位の作業を固定化するのは問題でしょう。現在は、作業を固定して運用して事が多いのでトラブルが絶えないと、私は考えます。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
要件変更と工数見直し (スコア:2)
日本での事情に限定します（外国の状況には詳しくないので）が、記事の分析通り、要件定義を軽視しすぎていると感じます。
要件は開発者側だけで決定できるものではありませんから、利用者側の都合で変更や追加が発生することはやむを得ないとしても、
・十分なヒアリングや検討を行い、変更の可能性を最小限に抑える
・それでも変更が発生してしまった場合は、工数を見直し、納期やコストが変動することに合意いただく
・「なぜこの要件なのか（要件が変更されたのか）」を最前線の開発担当者にも伝え、利用イメージを共有する
といったことが重要になると考えます。
私た
Re: (スコア:0)
自社の管理職・上級職だけがネックならまだしも、客も同レベルだから救いようがない。しかも自分たちに問題ないと思ってるから、同じ失敗を何度も繰り返す。
Re:要件変更と工数見直し (スコア:0)
受注側の作成する要件定義もあやふやなのは
発注側の要件定義が不透明なのが原因
当然客に明確な答えがあるわけではないので
要件を物理レベル近くまで具体化しなければいけない、
時間をかけなければいけない。
が、見切り発車の炎上が常。
Re: (スコア:0)
どんなに具体的に説明しても、客に「説明から出来上がりをイメージする力」がないから
見切り発車せざるを得ず、ある程度進んでから「こうじゃない」と言われて要件を調整。
というのが前提で、いかに巻き戻しを少なく見切り発車するかがミソというバッドノウハウ。
末端作業者がパソコンの操作もおぼつかないようだと、出来たモノに「こうじゃない」
「こうしてくれ」という要求をアウトプットする能力すらないことも…
Re:要件変更と工数見直し (スコア:2)
プロトタイプでも紙芝居でもいいので、画面レベルで動きを見せるのが必要だし、実際に行っていると思います。
顧客に出来上がりをイメージする力がないのと同様、開発側には業務の隅々まで察知する力はないので、細部にわたって要件を詰めないといけないのですが、曖昧な部分が残ってしまい問題となるのが実情でしょう。
それを改善するためにどうするかを意識し、バッドノウハウで済まさないことが、要件定義工程に求められるスキルかな、と思います。
Re:要件変更と工数見直し (スコア:2)
＞開発側には業務の隅々まで察知する力はないので、
これが、現状の最大の問題。
最下層までは無理でも、開発側の中流には「顧客の用途」を知っている人間が関わるべき。
何度も言ってるが、プログラマはプログラミングだけじゃなく、ユーザ側の業務知識が無いと無能なんだよ。
言語なんていくつ覚えても、例えば、帳簿の付け方を知らずに会計関連の仕事が出来る筈が無い訳。
「公認会計士の資格を持ったプログラマ」なら、会計関連の仕事を高価に受注可能か思われるけど、如何？
//逆も真なんだけどね。
-- Buy It When You Found It --
Re:要件変更と工数見直し (スコア:1)
＞開発側には業務の隅々まで察知する力はないので、
これが、現状の最大の問題。
最下層までは無理でも、開発側の中流には「顧客の用途」を知っている人間が関わるべき。
何度も言ってるが、プログラマはプログラミングだけじゃなく、ユーザ側の業務知識が無いと無能なんだよ。
無能という表現はどうかと思いますが、おっしゃることはわかりますし、同意できる部分はあります。
要件が曖昧で設計者が業務を理解していないと、往々にして開発者の思い込みで機能が作り込まれ、顧客の要望から食い違ってしまうことがあるので、顧客に近い上流の段階で不明点はつぶしていかないといけないでしょう。
「公認会計士の資格を持ったプログラマ」なら、会計関連の仕事を高価に受注可能か思われるけど、如何？
//逆も真なんだけどね。
どうだろう。
当方、「中小企業診断士の登録を受けた開発担当者」ですが、実感として人月単価（客先常駐です）そのものはそれほど上がっていない印象です。
業務自体は上流をやらせてもらえるようにはなったし、工程が上がることで人月単価は上がりましたが。
Re: (スコア:0)
「公認会計士の資格を持ったプログラマ」なら、会計関連の仕事を高価に受注可能か思われるけど、如何？
//逆も真なんだけどね。
公認会計士の資格を持った中層から下層のプログラマがいれば、曖昧な仕様もカバーできるってこと？
設計者の怠慢の言い訳じゃないの？
相当の知識がないと理解できない仕様じゃ、仕様書とは言わないんじゃない？
Re: (スコア:0)
発注受注どちらでもなくコンサルの立場で間を持てないかと双方に提案したことが
ありますが、いずれにもノーと言われましたねえ。
その前年には発注者側で火消しに入って業務終了時にはずいぶんと持ち上げられも
しましたけど、第三者として間に入るとなると事情も違うようで。
炎上させといて発注元に常駐する他社の技術者に事態収拾を頼みにくるような所なんで、
提案の翌年に「うちのメンバーとして入って欲しい」といわれた時もさすがにお断りしたなあ。
Re:要件変更と工数見直し (スコア:1)
「プログラマ」を語義どおりにとれば設計担当者の怠慢となりますが。
元の人、「開発側の中流」という言い方もしているので、設計も含めた開発側の要員を総じて「プログラマ」と呼んでいるかもしれません。
（元の人の反応待ちです）
いずれにしても、要件や仕様が曖昧なまま実装に入れば、顧客との認識のずれや手戻りも多く、プロジェクトの遅延要因となります。
実装者に業務知識があれば、要件を詰める必要があるとアラートが上がる可能性はありますが、実装者に業務知識にあるという前提に頼るのは危険ですし。
（勉強会などで、十分な業務知識を積ませてあるならリスクは下がりますが）
アラートが上がってもそれを拒否して、不正確な仕様のまま実装を押し付ける要件決定者やPMもありますが、論外ですね。
Re:要件変更と工数見直し (スコア:1)
呼ばれたので追記しておきます。
何事も、100%はありません。
仕様書も100%文言通りに実装して済む様な代物は作成不能です。
それでも、せめて実装可能な程度の仕様書は作成するべきでしょう。これは、上流側の責任だし、特にシステム全体の結合については、下層が把握するのは無理だからです。
（下層には自分の担当範囲がシステムに与える影響を把握する義務が在るが、他チームの分まで担当するんじゃチーム分けの意味が無い）
顧客の要求の汲み出しは、本来は上流の仕事ですが、「実装する下層だから気付く問題」ってのも存在します。
「実装するまで分からない」機能を要件定義の時点で決める事も現実的では無いので、その部分は「下層に任せる」事になります。
で、私の発言は、この状況での下層のレベルへの言及です。
但し、顧客と直接対話するのは上流だけでしょうから、上流側にも十分な能力は必須です。
＞実装者に業務知識にあるという前提に頼るのは危険ですし。
これも、100%を望むから危険なのです。
実装者が失念する可能性は常に在るので、多階層でのチェックは不可欠です。
逆に、多階層でのチェックを有効に実施するには、各階層に業務知識を持った担当が存在する事が前提です。
尚、「プログラマ」の呼称は、「相対的な下位担当」のつもりで使用しています。
ごく小規模な場合を除いて、最終的なシステムの規模から必然的に階層化される筈で、規模に応じて階層が増えるので、上位と下位の作業を固定化するのは問題でしょう。
現在は、作業を固定して運用して事が多いのでトラブルが絶えないと、私は考えます。
-- Buy It When You Found It --