アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
Agileでいこうよ... (スコア:3, 興味深い)
最近のシステムは昔より複雑化しているので、お客さん自身もどんなシステムが欲しいのか、要件定義段階では頭の中に描けなくなってきているし、開発する側も見積が困難になりつつあるわけです。
そういう状況で納期と予算を定めて開発をするというのはお客さん側も開発側も相当なリスクを背負う必要があります。
ならば優先度の高い要件から順次開発していくAgile型手法のほうがお客さんも開発側もハッピーになれるのではないかと。
ちなみに件の「納期が決まっている場合」の対処は、Agile的には「機能を絞る」です。
以下、愚痴。
だいたいさー、後からねじこんでくる要件って多くはお客さん内部の特定担当者のエゴがほとんどで、そんな機能なくても日常業務にはまず影響ないし、せっかく作ってあげてもほとんど使われることなんてないわけよ。でもこういう「ねじ込み屋」って声はでかいから敵に回すと後々面倒。つまるところ対処するしかない。で、納期がきつい局面では、他の重要な部分に手間暇かける時間がなくなって、全体的には非常に迷惑。
以上、愚痴。
なんていう自分の経験をふまえて言えば、もっと開発者とお客さんが協力して開発を進められるような体制なり手法なりが理想なわけで、そうするとXPとかSCRUMちうのは良くできているなぁ、と思ってしまいます。でも、お客さん側の（それも意思決定層の）理解がないと、なかなか難しいのですね。。。
---- 末は社長か懲戒免職 なかむらまさよし
Re:Agileでいこうよ... (スコア:3, 興味深い)
まあ、私自身、アジャイルというのはあまりよく分かっていない部分もあるのですが。
でも、斜め読みした書籍やサイトから、まず最初に感じたのは、
なんか、アジャイルの話って、お客さんがあまりにも優秀で、物分りがいいという前提に立ちすぎており、
結果、開発する方の、費用・納期・資源という部分の戦略に欠けていると感じていました。
それでも、この前、顧客の要件が大まかな枠組みのみ決まっている案件に対して、実験的に顧客の担当者を
スケジューリングや開発の現場にコミットさせてみたのですが、以下のような問題で大混乱となりました。
(私は通常、プロマネや営業に近いことをしているんですが、今回は外から見ていました。)
1. 顧客の中で全ての要件の優先順位づけが上手く行くことがない。
優先度の高い要件はころころ変わり、開発は何も手をつけることができない。
結果、時間と無駄なコードばかり量産されて成果物は上がらない。
最終的には、納期に近づくにつれ、同じ順位づけを強制される。(全てやれとなる。)
2. 顧客と開発者が直にやり取りすることにより、開発スコープが混乱し、本来契約や要件にない項目などが
開発スコープにあらわれ、大混乱となる。
情報共有にはある程度のタイムラグが存在し、また、全ての開発者が全ての要件や制約を把握しているわけではない。
その状態で、要件を定めることに適切な開発者が拒否した要件を、顧客が別の開発者に持ちかけ、
開発者誰かを騙せれば、仕様をねじ込むことが出来るという状態となり、仕様は肥大する。
しかし、開発側が期間内に可能だとし、仕様変更を許可したという理由で納期は変わらない。
3. ドキュメントが防波堤にならない為、顧客や開発者が過去に発言した事が
顧客の都合のよい形で、それぞれ場面場面に採用されてしまい、仕様が肥大する。当然納期は(以下略。
4. 2に関連して、顧客が雑談などで話したことが、なぜか仕様の一部になり、拒否できない状態となること多数。
開発者は顧客と雑談をすることすら疑心暗鬼となり、コミュニケーション以前の問題となる。
5. 2に伴い、開発スコープが勝手に肥大化することにより、営業的に大失敗となる。
元の要件が曖昧である為、増えた仕様により、費用を取るのが難しい。
6. 顧客が開発者のスケジュールなどを把握できる為、要件が膨らむ(納期に近づくにつれ)につれ、
開発者が休みなどを取れなくなり、開発者の消耗が激しい。
また、開発者が休みが取れるほど余裕がある場合は、顧客が新たな優先順位の高い要件を作り出す。
納期まで、自動的にデスマーチとなる。
7. 顧客の営業的な理由で、段階的な成果物のアウトプット自体が不可能。
特に、夢を見ている顧客ほど、デカイものを一発リリースしたがる。
8. 1-7の結果、モノが納期までに出来なかったとしても、結局のところ、顧客に責任はない。
顧客の望むものを出せなかった開発側が非を背負う。
今回は、自社のプロマネ全てを開発陣自身の任せてみたという点と、
納期と見積もりを切った後の案件で行ったというのが大きな原因だったわけですが、
だからといって、前者に関しては、プロマネと営業をプロジェクトにくっつけるのであれば、
普通に顧客とは、プロマネと営業を介してやったほうが、混乱も負担も少ないように感じますし、
後者に至っては、通常の会社の稟議システムの面倒さを考えると、それを変えること自体が営業的なリスクになります。
また、蛇足ですが、この顧客の担当者、まったくの無能でもなければ、悪い人でもないです。
でもまあ、担当者の能力や性格以前に、よくよく考えてみると、このスキームが上手く行くには、
顧客自身もプロジェクトの開発側部分にも責任をもって、そして、顧客自身も費用や納期、リリースを柔軟さを求められるわけです。
でも、そんなの、零細企業のワンマン社長でもなければ、無理だと判断しました。
ということで、自社内案件以外、2度とアジャイルっぽいものには近づかない方向で。
Re:Agileでいこうよ... (スコア:3, 興味深い)
>顧客の要件が大まかな枠組みのみ決まっている案件に対して
どれくらいの枠組みなのかはこれだけではわかりませんが、顧客にとってのゴール（これができるようになる、何が改善される）が明確でなければ、Agileもへったくれもないですよね。
>以下のような問題で大混乱となりました。
大混乱に陥いるということは、イタレーション単位がでかすぎたとか、イタレーションを見直す頻度が低すぎたとか、高すぎたとか、そういう問題があったのではないでしょうか？
>1. 顧客の中で全ての要件の優先順位づけが上手く行くことがない
これは顧客が神様でない限り不可能では？ 事前に要件を全て洗い出せないのと同様、優先順位も常に確定できるとは限りません。 となると見直しが発生するのは必須ですが、見直し頻度が多すぎれば完成できない機能が山積みになりますし、少なすぎれば「え、この機能ないの？」と後から騒ぐ羽目になります。
イタレーション周期が一週間なら、優先度見直しは一ヶ月、イタレーション周期が半月なら、優先度見直しは二ヶ月くらいが良いようです。それ以外は、ストーリの順序は固定させるべきでしょう。
>2. 顧客と開発者が直にやり取りすることにより、
これ、XP本などでは良く書かれている話ですけど、そんなにうまくはいかないでしょうね。顧客側の責任者(Product Owner)と、開発側の責任者(Scrum Master)が定期的に状況確認をするのが現実的ではないでしょうか。
>3. ドキュメントが防波堤にならない為、
なのでドキュメントを残せばよいわけですよ。うまくいってる事例では、ホワイトボードに書いた内容をデジカメで撮影して保存している、というのがありました。議事録の代わりです。ここから起こしたストーリは、紙媒体ならデジカメ、XPlannerなどのシステムだったら顧客が直接見るとか、他形式に変換して渡すとか、共有手段はあります。変更履歴（とその理由）が残るシステムならさらに良いわけですが、いまのところオープンソースでこういうのは見たことないです...
あと、ストーリの入れ替えはそれなりの課金をする、という契約方法もあります。コロコロ言うことが変われば、それなりに開発価格も高くなる、ということで一定の縛りをかけるわけです。
>4. 2に関連して、顧客が雑談などで話したことが、なぜか仕様の一部になり、
開発ストーリを決める場とそうではない場を明確にし、そこで話しあわれた内容を文書化することで解決するべきでしたね。方法は、デジカメでホワイトボードを撮影すれば充分でしょう。
>5. 2に伴い、開発スコープが勝手に肥大化することにより、営業的に大失敗となる。
米国では、請負開発価格をスライド式にして解決するのが最近の主流みたいです。もちろん、のんべんだらりと開発されたら顧客側が損するので、そのあたりはいろいろ工夫があります。必要なら別コメントで説明します。
ちなみに、ウォーターフォール開発での初期見積りがダメダメで営業的に大失敗する事例が多いので、Agileが台頭してきた、ってのが北米（なぜかカナダにAgile企業が多い）での背景です。
>6. 顧客が開発者のスケジュールなどを把握できる為、
これも顧客との関係がよくないからでしょうね。仕事を随時ネジこむのがAgileではありません。
>7. 顧客の営業的な理由で、段階的な成果物のアウトプット自体が不可能。
段階リリース＝段階本番リリースではありませんよ。段階的なアウトプットは内部リリースで評価してもらい、それが本番リリースに耐えうる内容・品質かどうかを顧客に確認してもらうのがAgileの本質ではないでしょうか。
>8. 1-7の結果、モノが納期までに出来なかったとしても、結局のところ、顧客に責任はない。
そもそもどんなモノを作るかが明確になってなければ、顧客に責任を問うことは不可能でしょう。
イメージを固めながら開発を進め、リリース時期をずらせるのならずらし、無理なら機能制限でリリースする。
これがAgileの良いところではないでしょうか。
自分の少い経験からも同意できるのは
>通常の会社の稟議システムの面倒さ
これですね。
課長とか部長とか執行役員とかいうのは、自分に課せられた責任を許される予算の範囲で、自分の判断で解決していく、というのが本来の姿なわけです。
でもそれだと失敗したときに責任問われちゃうので、稟議という形式にしちゃう。みんなが同意したんだから、自分一人に責任はないよね、というわけです。
当然、意思決定の速度はどんどん落ちてしまう...
まあ、銀行護送船団方式だった時代の日本ならいざ知らず、今後はこのあたりも変化してくるのではないでしょうか。
＞自社内案件以外、2度とアジャイルっぽいものには近づかない方向で。
まあ、ここまで原因が追求できているのなら、次はいろいろ打つ手もあるのでは？ たしかに自社内案件で実証、というのが正解でしょうね。
Agile管理手法の一つ、SCRUMは日本の製造業が手本になっているわけです。そして日本のソフトウェア産業はなぜか建設業界を手本にしています。
手本を間違えているから、いろいろ悲劇が起きているのではないかなぁ...
長文、失礼しました。
---- 末は社長か懲戒免職 なかむらまさよし
Re:Agileでいこうよ... (スコア:1, 興味深い)
>部分もあるのですが。
そのようですね。技術的な話が一切出ていませんから。
おそらくはアジャイルの形だけ真似ているだけで、実際には
全然アジャイルになっていないのでしょう。
>なんか、アジャイルの話って、お客さんがあまりにも優秀で、
>物分りがいいという前提に立ちすぎており、結果、開発する方の、
>費用・納期・資源という部分の戦略に欠けていると感じていました。
要は、良いシステム開発においては、良い顧客の存在が必要
不可欠ってことですね。それについてはアジャイルは特効薬では
ありません。
アジャイルは開発の効率を高められますが、そのためには良い
顧客や現場の高い技術力が求められます。今まで技術者を使い
捨てにしてきた現場に必要な技術などあるはずもなく、通常は
一から作り直す必要があります。いかにしてこれらを高めて
いくかについてはAgile開発の外、経営戦略などの部分です。
結局は経営不在のシステム開発ということ自体に無理があるんですよ。
Re:Agileでいこうよ... (スコア:0)
> 顧客や現場の高い技術力が求められます。今まで技術者を使い
> 捨てにしてきた現場に必要な技術などあるはずもなく、通常は
> 一から作り直す必要があります。いかにしてこれらを高めて
> いくかについてはAgile開発の外、経営戦略などの部分です。
その通りだと思います。素晴らしいですね。
ちょっと質問ですが「一から作り直す」というのは、
どのようなイメージをされていますか？
どうもアジャイルを現場からの改革に使おうとして
いる方が多いような気がしてならないのです。しかし
アジャ
Re:Agileでいこうよ... (スコア:0)
> なんか、アジャイルの話って、お客さんがあまりにも優秀で、物分りがいいという前提に立ちすぎており、
ある意味その通りですね
アジャイルは万能ではないです
ただ条件さえそろえば極めて有効な手法だと思います
> 結果、開発する方の、費用・納期・資源という部分の戦略に欠けていると感じていました。
資源という意味で、アジャイルを実践できる組織を育成するまでが一番難しいと思っています
ただその一線を越えて、かつ顧客との信頼関係を構築できれば、費用・納期は短縮できる、というのがここ数年実践してみての実感です
まぁお客さんに恵まれた、という点は否定できませんが...