アジャイルがユーザーや顧客企業に嫌われる理由 80
ストーリー by hylom
それとこれとは話が別では 部門より
それとこれとは話が別では 部門より
あるAnonymous Coward 曰く、
「アジャイル」なソフトウェア開発がここ数年注目されているが、アジャイルなソフトウェア開発において特徴的な反復 (イテレーション) や柔軟性といった手法は、顧客やユーザーにとってはまとまりも終わりも無い開発手法に見えるという。これを取り上げたITWorldのブログが本家/.にて話題になっている。
アジャイル開発を好む開発者は多い。イテレーションはユーザのニーズを的確に反映できるだけでなく、対応すべき要件があがってきたとしても問題が大きくなる前に対処することが可能だ。各要件に一つずつ取り組むため、きちんとフィードバックを受けて問題が無いことを確認してから次の要件に着手することもできる。
しかしユーザにとってみると、アジャイル開発は不透明で分かりづらく、故に不安を生んでしまうもののようだ。まるで開発プロセスが無く、開発方針も定まっていないように見えると、アジャイルプロジェクトに加わったとある人はコメントしている。
顧客の不安はアジャイル開発の特徴の裏返しでもある。期日や予算が固定されたプロジェクトに慣れている顧客の目にはアジャイルプロジェクトは非常に曖昧にうつるものだ。これを解消するには開発者は顧客が不安を持っていることを念頭に置き、その時点で決まっている設計やスケジュールを共有することだという。ただ、共有した全体像が義務という足かせになってしまわぬよう注意が必要とのことだ。
/.J諸兄方はアジャイルプロジェクトに携わるにあたり気を付けていることなどあるだろうか？
既製品と受注品 (スコア:5, すばらしい洞察)
ソフトウェアに限らないけど、
たとえば「服」なら既製服と注文服で客のほうに「も」知識が要るのは圧倒的に注文服なんですが、
それは客も理解してるのよね。
事前に金を払ったからといって、早くできるわけでも、注文になかったものまで作ってくれるわけではないので、
作ってほしいものがあれば、きっちり注文内容にそれを入れることが必要。
でもソフトウェアになると、なぜかそれが分からなくなってしまう。
既製品(パッケージソフト)で間に合わないから注文品にしているはずなのに、発注側が受注側に何でもかんでも「察する」ことを求めてちゃいけないよね。
形として見えるものじゃないから、分割受注みたいな形(アジャイル)にして「客の」リスク(と受注側のリスク)を下げようとしているのに、
それを拒否されたら、どっちも不幸になるだけなのは散々説明されていると思うのです。
Re:既製品と受注品 (スコア:3, すばらしい洞察)
注文服の例えを使うと、アジャイルが避けられる理由(の１つ)も説明がついちゃいそうですね。
「着丈はもっと長いのがいい」とかの直しようのない要望に後から気づいたら、最悪全部やり直しですから、全体が見えない段階でゴーを出すのは勇気がいるでしょう。
それとやっぱり、値段が決まらない内に「買う」という決断はしづらいですね。
「これとこれは最初に決めないといけない。他は後で安く直せるから次のサイクルで検討すればいい」といった、一段上の判断ができてればリスクを抑えられるかな。
でもそれができる人なら、きっとウォーターフォールでもちゃんと仕様を出せちゃますね。
Re:既製品と受注品 (スコア:1)
なるほどなぁ。わかりやすい。
# 「開発方針も定まっていないように見えると～」、これが顧客側の軸のふらつきの反映みたいなもんなんだよな。
# 方針というか全体像/骨子が見えてれば、肉付けしてってるんだし。
## といえるほど、やったこともないのでエラいことは言えませんが。
M-FalconSky (暑いか寒い)
Re: (スコア:0)
ソフトウェアだとそういう部分の齟齬が良く起こる。
服と比べるのはちょっと違うな。
Re:既製品と受注品 (スコア:1)
注文服で寸法が合っているのが当然と言えるのは、採寸が必要であることが受注側・発注側の共通の知識になっているから。
ソフトウェアになると、受注側が必要だと思って問い合わせている事がなぜか発注側にちゃんと届かない。発注側はそんなこと知らないから、どこまでを当然のこととして伝える必要があるのかがいつまでも理解できない。業界の仕組みが、そういう共通の知識を蓄えていくことを阻害しているように思えます。
Re: (スコア:0, オフトピック)
それは元請けが上前を撥ねるだけはねて仕事をしているふりだけしていて本来すべき仕事をしていないだけなのでは。
Re:既製品と受注品 (スコア:2)
それならまだいいほうです。
発注側が理解していないために、受注側の意図が発注側に届いていないということのほうが多いですよ
発注側のシステム改修なのに、発注側どうなっているのかわからないことが多いため、受注側がこれでいいの？って聞いてもわからないので適当に答え、そして後からやっぱりこっち～と何度も修正を迫られる（もちろんタダで）
＃業務内容はちゃんと理解されているか、現場志向なので面倒くさい（だから確認してるのに、後から常識でしょっ！とか使えないよっ！て言われて修正させられたり）
Re:既製品と受注品 (スコア:2, すばらしい洞察)
＞背広作ってくれと言われて、袖のない背広を平気でつくってくるのがエンジニア。
だって、袖なし背広分の布しか用意してくれなかったじゃないか!
# 費用とか納期とか明らかに足りないのにフルスペックのものを要求されるってのも、この業界よくあるよね。
Re:既製品と受注品 (スコア:1)
＞背広作ってくれと言われて、袖のない背広を平気でつくってくるのがエンジニア。
さすがに背広ではそれはない。
そういうのはスーツ（笑）な人のいいがかり。
「水着」だったらいろいろだろうけどな。
男性用ならまだしも、女性用で「水着下さい」じゃ誰だって回答に困るわ。
Re: (スコア:0)
言われた通りなら、スーツ（笑）でも納品する、一般的に不完全な状態でも気にしない、
という揶揄としての袖なし背広なのに、わざわざ袖なし背広を背広ではないと力説する必要あるの？
Re:既製品と受注品 (スコア:1)
スーツ作ってくれと言われて痛スーツが出てきましたとか。
#それはまた別の問題
#存在自体がホラー
Re:既製品と受注品 (スコア:1)
>背広作ってくれと言われて、袖のない背広を平気でつくってくるのがエンジニア。
えっ？政治家じゃないの？
省エネルック [wikipedia.org]
#存在自体がホラー
Re: (スコア:0)
要件定義担当者を間におけばいいのに
Re: (スコア:0)
そしてウォーターフォール開発が最終解になります．
Re: (スコア:0)
うん、それで良いのでは無いでしょうか。困ることが無いならそれで。
Re: (スコア:0)
要件定義担当者を間におけばいいのに
その人が、要件の優先度や、どんなユースケースを想定してるのかを把握していれば良いけどね。
自分達が何をしたいのかもよく分からないからとりあえず手当たり次第に要件盛り込んで見積もりさせ、
納期と予算をベースに個々の機能を取捨選択するから、ちぐはぐで作ったは良いが使えないものが往々にしてできてしまう。
Re:既製品と受注品 (スコア:2)
要件定義後に要件が変わらないという前提ならこれでもいいんじゃないかな
＃みんなが困ってるのはそういうことでしょ
Re: (スコア:0)
http://d.hatena.ne.jp/redips+law/20120502/1335971526 [hatena.ne.jp]
仕様提示，説明の責任はユーザ側にあるのが原則
エンジニアが仕様を提案するのは、あくまでサービスなんよ。
んでも、提案をまとめてユーザにアボ取ってプレゼンテーションして、そのあげく
「そんなこと言われても分かんない、いちいち呼びつけないでよ」
とか給料泥棒的な発言されて、空気読めよって目で見られた・・・こちらが。
Re: (スコア:0)
現場では背広に袖がないのはあまりにも酷くね？って声が上がっててもどこかでもみ消されてしまうのはよくあること。
そもそも既存の型紙には袖が付いているものしか無くて、袖を付けたほうが双方の利益になるのではと指摘しても
「そもそもお客様の注文には袖が含まれてない。それで問題があるとは限らないのに袖を作るのはおかしい。文句があるのなら袖が無いと問題だという証拠を出せ」と言ってくるのがスーツです。
Re:既製品と受注品 (スコア:1)
「こちら、馬鹿には見えないシステムでございます」
#必要のないシステムを作らずにすませられるのならば、十分優秀なのかもしれない
#存在自体がホラー
まず一回回す (スコア:5, 興味深い)
> /.J諸兄方はアジャイルプロジェクトに携わるにあたり気を付けていることなどあるだろうか？
速攻でまず一回成果物を出す。動くモノを出すまでは半信半疑の視線も我慢する。
顧客にメリットを理解して貰うには、実際にサイクルを回しているところを見せるのが一番。
ウォーターフォールモデルでプロトタイプを検証して貰うのと同じノリで、まず成果を見てもらう。
それを見たお客さんは当然のように要望を出してくるわけだけれど、
そこで要望に対するスケジュールを笑顔で共有できると、その頃には、お客さんの意識も変わってくる。
（あれ？実は後出しで要件ねじ込んだのに、難なく話が通ったぞ？）なんて相手が思ってくれていたらしめたもの。
逆に、メリットを机上で愚直に説明しようとすると駄目だな。
「要件定義の変更による御社のリスクを下げるためにアジャイルを採用させて頂きたく」なんて言っちゃうと、
「お前らがちゃんと要件出せないから、お前らのためにわざわざこんな手段を取るんだよ」なんてニュアンスで受け取られて、
「何言ってんだ偉そうに、ちゃんと要件出すわ」みたいな反発をされかねない。
顧客2.0 (スコア:1)
後だしで要件ねじ込むのは当たり前じゃん、要求を飲むのが仕事だろう。なぜ疑問に思うの？
Re: (スコア:0)
そういう意識のお客さんは初めからアジャイルでやることを歓迎してくれるからいいんだよ。
Re: (スコア:0)
なるほど。この業界の人がやたらろくろを回す [naver.jp]のは、アジャイルのサイクルを回すことをイメージしていたのか。
他人に厳しく自分に甘い (スコア:1)
自分が受注するときは、期間も予算もきっちり決めて仕様変更は認めない。
自分が発注するときは、期間も予算も曖昧で毎日のように仕様変更を押し付ける。
そんな顧客ばかりだからじゃね。アジャイルなんてハイカラな手法は使ったことないけど
Re: (スコア:0)
まあ大概そんなのは仕様が不透明で、まとまりも終わりも無い開発になりますから
Re: (スコア:0)
発注側にこそスキルが求められると思うんだけど、概して発注担当するのはその分野じゃ素人さんか素人さんに毛が生えたレベルなんだよね。
プロがプロに頼む位なら自分でやるって…。
/*
自分で立てた要件定義や見積りが甘くて、上司やボスから頭越しにどんどん追加仕様が飛んで行って現場を火だるまにした経験なら何度かある。
逆側に立ってさんざん苦しめられて絶対やらないぞって誓ったのに、いざ自分が発注担当になったときにはその誓いが足下から音を立てて崩れていく様を見るのはあまり気持ちのいいものじゃないけど、逃げずに踏ん張ったら結構いい経験になった。
*/
Re: (スコア:0)
そうなりやすいのにも理由があって、
だいたい発注責任者に責任がない（笑えない）。
発注責任者に聞いても最終仕様が決まらない。突っ込むと「現場担当に聞いてくる」決定権が彼にないんですね。
でも現場はといえば「ソフトの細かいことなんか勝手に決めてくれ」→持ってくと「これうちの部署で使いたいのと違う」それを聞いてたのに。
そーゆー所は、ウォーターフォールだろうがアジャイルだろうが、まあ納期は伸びますよねｗ
Re: (スコア:0)
自分が開発した気になりたい。
自分が指揮をとった気になりたい。
自分がスケジュール管理した気になりたい。
自分がしっかり文句言っときましたって気になりたい。
実際には何もしない、どころか余計な説明資料を強要してくる。
管理といってもやった事の吸い上げだけで、フォローはしない。急げと言うだけ。
上司と一緒。管理のはずだが部下がお守りをさせられる。
Re: (スコア:0)
途中で仕様の変更や追加をどんどん付けてくる顧客に対応するには
アジャイルがいいんだけどな。
いったい何様だって感じ。開発会社は奴隷か？
発注時にしっかり・はっきりした「注文」を確定して出し、
それを最後まで変えないって言ってくれるならアジャイルは不要かもね。
Re:他人に厳しく自分に甘い (スコア:1)
それを自分で認識してる顧客ならいいんだよね。
自分でははっきり仕様を決め切れないくせに
納期と予算は決まってて、出来上がってきたものに文句を出す。
どうせ文句いうこと決まってんだったら、
仕様じゃなくてモノ見て決めようぜ
……とお互いぶっちゃけられる間柄で、アジャイルは生きると思う。
# と、そんな大人な間柄だったらウォーターフォール型でも上手く回るという……
進捗が判り難いから日本的社会では受け入れられにくい (スコア:1)
ある日突然「根本的に作り直します」とか言われても困るだけだし、
規模が大きいプロジェクトほどそんなの許可できない。
＃それもこれもプログラマの地位が低すぎるから
Re:進捗が判り難いから日本的社会では受け入れられにくい (スコア:1)
それを現物を見て判断できるようにしたのがアジャイルだろ。
Agileの思い出 (スコア:0)
Agileという商品名のソフトウェア(現在は買収されてオラクルの商品)を使ったとき、開発手法のアジャイルと混同されて苦労したことが。
# 検索しても情報みつけにくいし
Re:Agileの思い出 (スコア:3, すばらしい洞察)
アジャイル開発と言いつつ、中身は仕様変更の多いウォーターフォールだったこと。
いうまでもなく地獄だった。
たぶん、そういう現場は少なくない。
＃プログラミングをしない管理職には、
＃仕様変更が極めて多いウォーターフォールはアジャイルと見分けが付かない。
Re: (スコア:0)
Re:Agileの思い出 (スコア:3)
Re:Agileの思い出 (スコア:1)
そんな認識が問題プロジェクトを生んでいくのですね．．．。
# カッコよく聞こえると思ったら大間違いなだけとか。
Re:Agileの思い出 (スコア:2)
いや、例えばひとつのスプリントの設計～テスト～開発をウォーターフォールだとすると、
筋は通っているように思えますが。
アジャイル開発を理解している人も少ないのかもしれませんが、
逆にウォーターフォール開発のバリエーションをちゃんと把握している人もあまりいないとおもいます。
TDD でドキュメント作成を最後にもってくるウォーターフォール開発もありますよ。
1ヶ月単位でテーマを決めてエンハンスを繰り返す、こういったウォーターフォール開発は、
アジャイルとの境界に位置するとおもいます。
Re:Agileの思い出 (スコア:1)
違いをきちんと説明してもらえますか。
アジャイルとの違いは (スコア:0)
従来型のプロジェクトでも、期日や予算の見積もりは当てずっぽうみたいなものなのですが
これで出来ます！と言い切ってしまっているだけのような気がします。
対してアジャイルでは、見積もりは当てずっぽうなのでそれだけに頼らず、
少しずつ仕事を進めて確度の高い期日や予算を見極めて行きましょう
と、公にしているかの違いだと思います。
自社開発業務アプリなんてそんなもんじゃない? (スコア:0)
増築を重ねて5-10年もたつとどうにもならなくなってくるので、
新しいのを一から作り直し。
アジャイルなんて名前はなかったと思うけど、どこの会社もそんな感じ。
Re: (スコア:0)
5年後10年後に新しいものを最初から作り直すのはアジャイルとは言わない。
Re: (スコア:0)
１DK位の家を取りあえず作って住んで貰ってから他の部屋なり2階を増築する！それがアジャイル
Re: (スコア:0)
何となくサグラダ・ファミリアを連想した。
納期を気にせず100年以上作り続けるソフトウェアプロジェクトとか無いかな？
Re:自社開発業務アプリなんてそんなもんじゃない? (スコア:2)
100年間保守し続けられたソフトウェアですか。
なんか関わりたくねぇ。
式年遷宮のごとく、数年おきに作り直す事でシステムを継承してったほうがいいんでないかと思う今日この頃。
Re:自社開発業務アプリなんてそんなもんじゃない? (スコア:1)
二桁年ごときで年金やら特許なんて扱う化け物システムがありますね。
ニュースだけ見てても、あれは触りたくないと思う今日この頃。
あれこそ作り直しが大変だと思うんだよねぇ。
Re: (スコア:0)
400年アップデートを続けた環状都市東京がそんな感じかも。
ソリューション営業の極意は (スコア:0)
http://pro-eigyo.blogspot.jp/ [blogspot.jp]
プログラミング＝設計工程 (スコア:1)
やれやれ。
プログラミングを知らない人ほど、未だにこういうことをいうんだよね。
＞というか作り方をどうこう言ってる時点で、他の業界より30年ほど遅れてる自覚を持たんとね
建築学のたとえは百害あって一利無しだとあれほど。
既存製品の製造工程ではなく、新規製品の設計工程なんだってば。