納期を守るための裏技術、あなたもやってますか？ 260
ストーリー by yoosee
そんなあなたにJoelOnSoftware 部門より
そんなあなたにJoelOnSoftware 部門より
あるAnonymous Coward曰く、"＠ITの連載記事の中で[
「悪魔に心を売っても納期を守る！ 裏技術」という興味深い記事が掲載されている。
記事は、300人のエンジニアに「納期に間に合わないと分かったときに使う裏技術」という題でアンケートをとったもの。
IT業界だけに限定した記事ではないようだが、「仕事が始まった時点で納期達成が絶望的」な仕事の多さ、それに対する「テストの間引き」や「段階リリース」など、体験したことのある人も多いのではないかという話が、多々掲載されている。
かくいうタレコミ者も、覚えのあるものが存在している(--;
昨今、システム障害が大きな社会問題として取り上げられることが多いが、納期を延ばすのが難しい中で、どうすれば納期を守りつつ、問題を減らしていけるだろうか？
各位の経験した事例や、対策・裏技術などを語っていただきたい。
なお、話題が話題だけに、暴露話をACで書いたつもりがID… ということの無いよう、ご注意ください。"
姉歯 (スコア:5, おもしろおかしい)
Re:姉歯 (スコア:2, すばらしい洞察)
＃リリースした製品にすら碌な書類が残ってないのでAC
Re:姉歯 (スコア:3, 興味深い)
では、どうやって工期に間に合わせるかというと、監督が「遅れてる分、お前らが自発的に毎日早く工事始めれば良いんじゃね？」的なことを言って、下請けは泣く泣く朝５時から工事を開始するとかいう話でした。
ちなみに、これって最近の都銀と同じ構図ですね。「残業代は出せないし、サービス残業は問題になるから早く帰りなさい。ところで、うちのビルの鍵は朝６時から開いてるよ」とか言われて、自発的に（←という名目で時間外労働扱いにしない）朝早くきて仕事をするんだそうな。
Re:姉歯 (スコア:5, 興味深い)
毎月多めの目標を課せられ、(当然こなせない訳ですが)「目標達成する責任感をもとう！」
とか訳分からない謳い文句でサービス残業/出勤させられます。
# 同時に「コンプライアンスで信頼される店へ！」とも謳っているのですが・・・
# 先輩、ここは突っ込むところですか？
もちろん納車・整備時の交通事故とか整備ミスとか頻発する訳ですが、上層部＋担当者が
黄金色っぽい菓子をもって「まぁ、まぁ。これで何とか・・・ねぇ、えへへ」と詫びて握りつぶ
し回っているようです。
人身事故はまだ(!?)数件しか無いようですが、いつか問題がおき内情が露呈したとき一発で倒産
してしまうんじゃないかとビクビクしています。
今日も行われる、現在進行中の話です。
# 訴え出る先が分からないので我慢してるAC
Re:姉歯 (スコア:3, 興味深い)
ということですが、普通の会社の就労規定では、出社中は職務専念義務があるのでは？
勝手に会社に来ているとしても、仕事をしているのなら残毎代は払わなくてはなりませんし、仕事をしていないなら就労規定違反になると思います。
ちなみに、明示的に残業を指示しなくても、残業しないとこなせない量の仕事を与えると、残業を指示したと同じと見なされます。「勝手に残っている/早く来ているんだから残業代は払わない」という理屈は通りません。
Re:姉歯 (スコア:2, 参考になる)
＞デスマーチとかはできなさそうなイメージがあるんですが，
そのような事態に陥らないよう努めていますが
万が一にそなえ日頃から地元の顔役の方に対して盆暮れの付け届けは欠かしません
Re:姉歯 (スコア:2, おもしろおかしい)
つまりIT業界でも，
迷惑を掛ける家族や連れ合いに対しての付け届けが必要ってことですね．
Re:姉歯 (スコア:2, 参考になる)
ロビーやよく使うところやの目立つところから
仕上げというのはよくあります。
電話やLANの配線はその後だったりします。
事前準備で乗切る派 (スコア:5, 興味深い)
どちらも、張り切り過ぎないのがポイント
１．
普段から頑張り過ぎず、6-7割の力or仕事量で留めておくことで
普通以上の仕事が来ても、対処できるようにしておく。
また、普段の余力を、事前準備、根回しなどの割く
能無し・さぼりのレッテル貼られないような演技は大事だが
余力が有るので、比較的楽に演技できる
２．
仕事が来たら、まず最大出力で雛形を上司に提出
この場合早さ重視で、細部は完全に無視、
締切り日よりどれだけ速く提出するかが、最大のポイント
その後、上司の指示を受け、改訂を行うが
どうせ、上の人の意見なんてコロコロ変わるので
適当に意見を受け入れた改訂版を、なるべく手抜きで作製
（頑張った結果を否定されたり、上司の指示通り修正した物が
上司の一言で、反故になると、精神的にも負担になるので、手抜きを心がける）
上記の手段で、体力・知力・精神力の温存を量り
閉め切り直前だけは、120 %の力を出して、完成品に導く
クリアランスを作っておくのも仕事のうち
Re:事前準備で乗切る派 (スコア:3, すばらしい洞察)
#見たのでAC
Re:事前準備で乗切る派 (スコア:5, すばらしい洞察)
うっかり１２０％の力を出しちゃうと、次からそれが基準になる。
基準で済めば良いけど、何かあれば更に２割増しの頑張りを要求される。
そのうち、２割増しＮ乗に応えなきゃサボってるとまで言われ出す。
自分のスキルアップに伴うレベルアップなら良いんだけどね、背伸びは絶対しちゃいけない。
そのうちスキルアップを図る余裕すらなくなるから。
自動車のエンジンだって市販車はフルパワー続けるようにはできてないし、
レーシングエンジンなら定期的な分解整備は当り前。
マージンをとるのは義務だよ義務。
マネージャーにその能力がなければ代わりに自分が管理しなきゃ。
Re:事前準備で乗切る派 (スコア:5, 参考になる)
http://srad.jp/comments.pl?sid=292872&cid=853933
＞うっかり１２０％の力を出しちゃうと、次からそれが基準になる。
それを避けつつ、能なしのレッテルを貼られないようにしたのが
2.で書いた方法です、中をさぼるのでトータルでは100%以下で仕事出来ます
具体的には
1. 雛形or骨組みを最速で提出
とにかく速く出すことで、「出来る奴」の印象を与えることが出来ます
また、上司も雛形・骨組みが無いと、まともな指示が出来ないので、
はっきり言って、この時点から仕事がスターとと考える
2. 細部は無視してとにかく速く
上記骨組みから、上司の指示が始まりますが
どうせ、上司からケチが付きます
ですから、この時点で細部を詰めても無駄です
また、細かい詰めをしていないので、
上司も、色々ケチが付けやすく
「出来る奴だが、まだまだ俺の助けが必要だな」
と、上司に思わせることができ、上司は優越感に浸れます
3. 途中の細かい指示は、形だけ合わせて適当に
上司の指示は二転三転するのが当たり前なので
まともに言うことを訊いていると、大変なことになる
但し、表面上キッチリ上司の指示通りに直し
「俺の言うことを素直に訊く、良い部下」の印象を与える
3'.また、上司の指示と自分の考えが異なっていた場合
表面上は指示された部分だけ、言われた通りに直し
裏の部分は、自分の思惑通りになるよう、
すこしづつ、軌道修正する
上司は、自分の指示通りに動けば満足するので
軌道修正部分は気付かない
しかし、軌道修正部分を元に、新たな指示を出すので
結果的には、自分の考えに誘導できる
真っ正面から対立すると「反抗的な奴」のレッテルを貼られるので
裏から、上司の思考を誘導するのがポイント
2, 3. で時間・体力・精神力を温存
要するに、働いているフリしてサボる
但し、上司の言うことは（表面上）聞く
4. 閉め切り間際で、120 %
閉め切りの1-2日前だけ、徹夜して、完成させる
そのことで、得られる効能は
2,3で体力温存しているので、そんなに負担にならない
最終的には、閉め切りに間に合う
徹夜しているので、上司から「真面目な奴」と思わせる事が出来る
でも、閉め切りギリギリなので、次回もこれ以上の量の仕事は回ってこない
てな、感じです
逆を考えると楽かも
細部までキッチリした企画を閉め切りギリギリに完成
仕事遅い奴と思われる
この時点からまともな仕事開始なのに、既に閉め切りが迫っている
頑張って作ったものが、上司に否定される
嫌々修正、ここでも細部を詰めて、閉め切りが更に迫る
嫌々やっているのが上司に伝わり悪印象
再提出時、上司は指示とは180度違った指示を出す
言ってること違う！！と上司への不満を募らせる
それに気付いた上司は、悪印象を抱く
既に、時間的・精神的・肉体的に追いつまれている
でも、完成の目処は立っていない、時間だけが迫っている
10日連続徹夜で、ギリギリ完成
こんな状態で作った物だから、欠陥だらけ
再修正が入り、結局間に合わない
仕事遅い、反抗的、その割にまともな完成品作れない、
と、結果的に上司に評価される
でも、自分はボロボロ、同僚にも迷惑をかける
その割に、自分の思惑通りの仕事になっていない
こんなサイクルだと、仕事頑張っても評価が低くなるし
肉体・精神を病みます
Re:事前準備で乗切る派 (スコア:3, 参考になる)
・ そもそも納期が異常な仕事は受けない
・ 徹夜が必要な仕事はしない（徹夜は効率の敵）
・ テストの期間が入っていないような仕事はしない
そのために、
・金額は一緒でも納期は通常の３倍長くさせる（スケジュールや人員に融通を利かせるため）
・いくつかのフェーズに分けてそれぞれの単位で動作するように仕様を分割、納品を複数回にさせる。（仕様変更対策）
・相手側に（バイトでもいいから）システムに詳しい人を用意させ、相手先での運用前テストに参加させる。（必要ならそのまま運用要員とするように勧める）
あとは、
・それで多少仕事が少なくなっても我慢する（いい仕事をするために！）
まぁそれでも食べてはいけるもんですよ。
Re:事前準備で乗切る派 (スコア:2, 興味深い)
今かなりやられてるけどID
Re:事前準備で乗切る派 (スコア:5, 興味深い)
上司も別に何も言わない。
たまに上司が資料持ってきて「これできる？」「いつまで？」「今日中」「無茶だなあ」などという会話をしている。
いままでマウスの音しかしなかったのにキーボードの音が聞こえる。
定時の15分前に資料を「こんなんでいい？」などといって見せている。
ダメ出しうけてるのを見たことがない。
そうやって作った資料はプロジェクトの中枢部の基本設計仕様だったりする。
その仕様が問題になったのも見たことがない。
そして定時になったら「あー疲れた」などと言って帰る。
あれは、正直すごいと思った。本人も上司も。
Re:事前準備で乗切る派 (スコア:5, おもしろおかしい)
上司も別に何も言わない。足を引っ張るよりマシだから。
たまに上司が資料持ってきて「こいつどこ？」「たばこ？」「一日中？」「コーヒーかも」などウロウロしている。遊ばせすぎると自分の評価に響くから。
いままでマウスの音しかしなかったのにキーボードの音が聞こえる。ただし、BS/Delキーらしき音がやけに多い。
忘れた頃に資料を「こんなんでいい？」などといって見せている。
どうせ無駄なのでダメ出するのを見たことがない。
そうやって作った資料はプロジェクトの盲腸部の基本設計仕様だったりする。
その仕様が使われたのも見たことがない。
そして定時になったら「あー疲れた」などと言って帰る。
あれは、正直すごいと思った。本人も上司も。
だって給料おなじだもん。
納期・・・ (スコア:5, おもしろおかしい)
そこから買うと納期ぎりぎりにならないと入らない。
たかい、遅い、それでも文句を言えない・・・
途中納期で、中旬(11～20日)て書いてあって、いつまでに
すればいいですかと尋ねると、11日に決まってるだろ！
といわれ、
資材納入が中旬(11～20日)て書いてあって、
いつはいりますかときくと、20日に決まってるだろ！
・・・
やけくそでID
Minder
締切日時 (スコア:4, おもしろおかしい)
２３日の３２時までは許容範囲内ですよね？
Re:締切日時 (スコア:5, すばらしい洞察)
Re:締切日時 (スコア:3, 興味深い)
ぢつは某 Notes メールシステムでは、読んだことが送信者に
通知されてしまうのですよ。
そのためある時刻以後は、読まなかったことにするのではなく、
本当に読まないという護身術が常識になってしまった某社は
実在します。
Re:締切日時 (スコア:5, 参考になる)
＞通知されてしまうのですよ。
某Notesシステムの場合、読む前にメールをテキスト
ファイルに保存してエディタで読む。こうすれば受信通知が
向こうに行きません:-)
＃↑実際にやった人
-----
スケーター12号〜(┌ ┌ ┌ ´Д｀)┘
Re:締切日時 (スコア:4, 参考になる)
納期が厳しいのもそうですが、 (スコア:4, 参考になる)
こちらから仕様をあらかじめ提示しておいても、
我々部品屋が開発してるときは前製品の検証や量産で手一杯、
こちらの開発の後半になって、あれ変えろこれ追加してくれって
要求が来始める訳で。
なのに当然納期は変わらない(営業が納期交渉しようとも
しないのも大きな問題なのだが)
半導体は、そう簡単に修正して製造できないってのをあまり理解頂けて
ないようで厳しいです。
追加・変更に対する第一声 (スコア:2, すばらしい洞察)
これをまず言うべきです。
そして
「時間と料金を追加いただけるならば検討いたします」
作った分は使わなくてもタダではない。
これがいえるようになった初めて一人前です。
Re:追加・変更に対する第一声 (スコア:2, 興味深い)
それは正しいと知っているが
次からそこには発注しません。
Re:追加・変更に対する第一声 (スコア:2, すばらしい洞察)
＞次からそこには発注しません。
こういう客を相手にしないほうが会社も技術者も幸せになれることを知らない人が多すぎるのが問題なのかも。
http://www.blwisdom.com/management/
季節 (スコア:4, おもしろおかしい)
「新バージョンはいつごろリリースされますか？」との問いに「夏頃にはリリースできます」と答えました。
その年は梅雨明け発表が無いほどの冷夏でした。
「夏が来なかったので…」と言い訳できました。
保険確保が大事 (スコア:4, 参考になる)
「本来の」納期をFixしておき、残りの要求は「追加仕様」という扱いで話半分にして開発続行。
で、遅れそうになったら
「本来の納期決まった後に追加仕様出すから予定の納期に間に合わないのは当然の事ですよ。」と
きっぱりと言い切ります。
追加仕様を含めても、わざとギリギリまで納品せず
「今回は間に合いましたけど、次回はこう言う事は出来ませんよ。で、追加仕様分の請求は…」と
絶対的に強気に押します。ここで弱音見せて、突っ込まれる事が無い様に身を守るのが大事かと。
一度なんか、ソフトだけでも3人月、メカは組立どころか部品加工も全然終わっていないのに
(本来の)納品日が2週間後という案件を頼まれた時は、最初から「こんな案件、やれるか」と
わざと蹴って、仲介業者に仲とってもらって仕方無しに受ける事にして、「納期はお任せ」に
させてもらった事も。
#カンニング竹山の如く、「キレる」のも芸(交渉)のひとつですよ。
#流石にACだよ
Steve Jobsのスピーチ (スコア:4, 参考になる)
でも、この話題では、やはり当日のスピーチの中での別の一節がふさわしいと思う。
今日があなたの人生最後の日でも、今のやり方で満足ですか？正しい事を正しいと主張しましょう。それが通用しない会社なら転職を検討してみては？
何に怯えて、引き受けるのでしょうか。 (スコア:4, すばらしい洞察)
気分が悪くなりました。
徹夜・残業は悪しき伝統だと思っており、少しも明るくありません。
atmarkit＞「裏技術はなし」「徹夜・残業で間に合わせる」と答えた人が
atmarkit＞28人いたこともあり、少しは明るい
そういう現状を"あっけらかん"として認めることは
「無理な納期」「サービス残業」等の問題に対して
一石を投じることを放棄しているにも等しいでしょう。
従って、以下の文面とは矛盾しています。
atmarkit＞スタート地点から納期達成は難しいということだ。
atmarkit＞それなら、こうした無理のある計画こそ問題視すべきではないか。
自分の仕事に誇りを持っているので、サービス残業の強要は
引き受けませんし、休日出勤も徹夜もしません。
何に怯えて、引き受けるのでしょうか。
本当に「プライドに賭けて」無償でやっているのですか？
目を覚ませと言いたいですね。
Re:何に怯えて、引き受けるのでしょうか。 (スコア:5, すばらしい洞察)
能力によって同じ仕事でも作業時間に差が出ます。
大量の仕事をこなしているのに、定時や少しの残業で帰って
いる社員よりも、少ない仕事を毎日終電まで残業し、終電を
逃したからといってタイムカード押さずに会社に泊まって
いたりする社員のほうが手取りが多かったりすることが…。
その結果、会社は労働基準監督署から残業させすぎと指導が
入り、残業規制を取り入れる。
あまり残業しない優秀な者がたまに残業をする必要が発生しても、
その残業規制のせいでサービス残業に。
もともと怠けて残業するヤツは残業規制ピッタシで帰る。
そういう悪循環があるんですよね。
残業する必要は無いのに、能力の無いやつ、生活残業をしている
他の社員に気を使って付き合いで仕方なく残業してる人も
けっこういるんじゃないでしょうか。
#部下が帰りにくいので、上司の人は早く帰りましょう。
マイクロソフトに学ぶリリース日の守り方 (スコア:3, おもしろおかしい)
Re:マイクロソフトに学ぶリリース日の守り方 (スコア:2, おもしろおかしい)
Windows Vistaなら2006年の30月位。
#もう一ひねり欲しいが、疲れてるので、これ位で
---------+---------+----------+
年をとるのは素敵なことです。
ケーススタディ (スコア:3, 興味深い)
【軍曹が】携帯電話開発の現状【語る】(後半) [2log.net]
いっそのこと (スコア:3, すばらしい洞察)
そもそも、絶対間に合わないプロジェクトという
ハイリスクな仕事でも受けなきゃ成り立たない組織に未来があるとは思えない。
無理してやって、
開発者が倒れるか(人を消耗品と思っている)
納期が遅延する(信用問題、見積もり以上の開発コスト)
バグが多発する(信用問題、アフターサポートで死ぬ)
こんなリスクを抱えているプロジェクトでも
受けなきゃいけない組織に未来があるとは思えないなー
#そのリスクに見合うリターンってあるんかいなー
と、思ってみるテスト
できれば (スコア:3, すばらしい洞察)
仕様がかわりました、資料が予定期日より大幅に遅れて届きました、
「でも納期はそのままでやってくれ」が
いつまでもまかり通るってのはおかしいよ。
＃そんなこと言えるかってのが現状だが、
＃言ってずばんと辞めた過去あり
＃おかげで貧乏神が住むことになったが…
納期を守らなくていい場合 (スコア:3, おもしろおかしい)
・納品方法が決まってない
・納品物が決まってない
・開発プラットフォームも決まっていない
・そもそも契約してなかった
・担当がずっと行方不明
・納入先に誰もあったことがなく、住所を調べたら架空のものだった
・お願いされたのが今日で、すでに納期を過ぎていた
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は日本の製造業が手本になっているわけです。そして日本のソフトウェア産業はなぜか建設業界を手本にしています。
手本を間違えているから、いろいろ悲劇が起きているのではないかなぁ...
長文、失礼しました。
---- 末は社長か懲戒免職 なかむらまさよし
チャレンジャー (スコア:3, 興味深い)
//以下引用
子どもが道のまん中に走り出たのを見た両親が怒って
「危ないじゃないか！」と叱ったとする。
すると子どもが戻って来て
「だって何事も起こらなかったよ！」と言う。
そしてまた道のまん中に走って出る。
それを何回も繰り返すわけです。
親はそのたびに「危ないぞ！危ないぞ！」と言い続けている。
だが何事も起こらない。
しかしその子が今まで何も起こらなかったということを、
これからも決して何事も起こらないことと解釈したとすると、
事故は必ず起こるに違いない。
ブレーキが軋む音が二、三回は聞こえるでしょう。
これはガス漏れ、シールをガスが焼き抜くというようなことのたとえですよ。
//引用終り
この場合母親は技師たち、子どもは管理職の連中のことらしい。
が力関係が働いて母親が何も言えなくなっている？
参考URL
http://shippai.jst.go.jp/fkd/Detail?fn=0&id=CA0000639&kw=%A5%E... [jst.go.jp]
http://www2g.biglobe.ne.jp/~aviation/kikenritu.html [biglobe.ne.jp]
http://www2g.biglobe.ne.jp/~aviation/kikenritu02.html [biglobe.ne.jp]
http://www.nuclear.jp/~madarame/lec1/challenger.html [nuclear.jp]
ラウンドロビンスケジューリング (スコア:2, おもしろおかしい)
1日を２で割ってticktimeを12時間にします。
3時間スリープして、のこり9時間のうち 2時間を食事休憩にとって、
残業無しで7時間働くと、1ヶ月が60日になります
＃やってみたのですがラウンドロビンになってしまい
＃うまくいきませんでした
Re:ラウンドロビンスケジューリング (スコア:2, おもしろおかしい)
納期を守るため、人材を二重化してみたら賃金が半分になりました。
決済を早めるため、稟議書を回すルートを二重化したらパケットが行方不明になりました。
仕方がないので一番優秀な人材を投入して二週間ほど昼夜を問わずぶん回したら、動作中に「お花畑がきれいだな」とか異音を発するようになりました。ちなみに昨夜から ping 無応答です。
あかん、親コメの粋を壊してもーた orz
[わかってもらうことは難しい。わかってあげることは、もっと難しい。]
法でなんとかできんのか (スコア:2, 興味深い)
まぁ、平たく言うと我々ＩＴ土方に徹底的に有利な法整備をしてくれるような議員さんを国会に送り込もうというわけ（哀
無理なものは無理なので (スコア:2, すばらしい洞察)
Re:無理なものは無理なので (スコア:2, 参考になる)
残された人は悲惨です。
見積もりは出しているの？ (スコア:2, 参考になる)
進行状況もわかるので予測はできますよね。
また、経営者は売り上げも当然ながら「効率よくすすめる」や
「最大限の利益」という言葉が好きですから
それらの言葉を組み合わせて、経営者も巻き込んで
デッドラインを告げておく必要があります。
少しでも気配りしておけば、納期を過ぎてから依頼が来ることは
なくなると思います。
単品モノはいいねぇ (スコア:2, 興味深い)
これって量産したら大変なことになるようなことがいっぱい。
一品モノってこんなに手が抜けるのね…と羨ましくなってしまいました。
#テストで手を抜くなんて考えられないのでAC
Re:東証の障害は？ (スコア:3, 興味深い)
*東証の要求仕様の一部が開発側に伝わっていなかった
*東証側のコンピュータに異常な売買注文をはじく機能を実装するのが納期に間に合わなかった
が一般紙の記事に載っていました．（毎日新聞の何日の記事かは忘れ）
Re:理想と現実の両立 (スコア:4, 参考になる)
「いえ、特急料金をいただきたいくらいです」でだまらせてきました。