パスワードを忘れた? アカウント作成
11492 story
ビジネス

納期を守るための裏技術、あなたもやってますか? 260

ストーリー by yoosee
そんなあなたにJoelOnSoftware 部門より

あるAnonymous Coward曰く、"@ITの連載記事の中で[ 「悪魔に心を売っても納期を守る! 裏技術」という興味深い記事が掲載されている。 記事は、300人のエンジニアに「納期に間に合わないと分かったときに使う裏技術」という題でアンケートをとったもの。

IT業界だけに限定した記事ではないようだが、「仕事が始まった時点で納期達成が絶望的」な仕事の多さ、それに対する「テストの間引き」や「段階リリース」など、体験したことのある人も多いのではないかという話が、多々掲載されている。 かくいうタレコミ者も、覚えのあるものが存在している(--;

昨今、システム障害が大きな社会問題として取り上げられることが多いが、納期を延ばすのが難しい中で、どうすれば納期を守りつつ、問題を減らしていけるだろうか? 各位の経験した事例や、対策・裏技術などを語っていただきたい。 なお、話題が話題だけに、暴露話をACで書いたつもりがID… ということの無いよう、ご注意ください。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 姉歯 (スコア:5, おもしろおかしい)

    by Anonymous Coward on 2005年12月22日 19時55分 (#853923)
    呼んだ?
  • by Anonymous Coward on 2005年12月22日 20時20分 (#853933)
    私のやり方は大きく分けて2通り
    どちらも、張り切り過ぎないのがポイント

    1.
    普段から頑張り過ぎず、6-7割の力or仕事量で留めておくことで
    普通以上の仕事が来ても、対処できるようにしておく。
    また、普段の余力を、事前準備、根回しなどの割く
    能無し・さぼりのレッテル貼られないような演技は大事だが
    余力が有るので、比較的楽に演技できる

    2.
    仕事が来たら、まず最大出力で雛形を上司に提出
    この場合早さ重視で、細部は完全に無視、
    締切り日よりどれだけ速く提出するかが、最大のポイント
    その後、上司の指示を受け、改訂を行うが
    どうせ、上の人の意見なんてコロコロ変わるので
    適当に意見を受け入れた改訂版を、なるべく手抜きで作製
    (頑張った結果を否定されたり、上司の指示通り修正した物が
     上司の一言で、反故になると、精神的にも負担になるので、手抜きを心がける)
    上記の手段で、体力・知力・精神力の温存を量り
    閉め切り直前だけは、120 %の力を出して、完成品に導く

    クリアランスを作っておくのも仕事のうち
    • Re:事前準備で乗切る派 (スコア:3, すばらしい洞察)

      by Anonymous Coward on 2005年12月22日 23時08分 (#854038)
      そして次回以降に能力ありと思われて地獄を見る

      #見たのでAC
      親コメント
      • Re:事前準備で乗切る派 (スコア:5, すばらしい洞察)

        by Anonymous Coward on 2005年12月23日 2時01分 (#854136)
        いや、おもしろおかしいじゃ済まないよ。

        うっかり120%の力を出しちゃうと、次からそれが基準になる。
        基準で済めば良いけど、何かあれば更に2割増しの頑張りを要求される。
        そのうち、2割増しN乗に応えなきゃサボってるとまで言われ出す。

        自分のスキルアップに伴うレベルアップなら良いんだけどね、背伸びは絶対しちゃいけない。
        そのうちスキルアップを図る余裕すらなくなるから。

        自動車のエンジンだって市販車はフルパワー続けるようにはできてないし、
        レーシングエンジンなら定期的な分解整備は当り前。
        マージンをとるのは義務だよ義務。
        マネージャーにその能力がなければ代わりに自分が管理しなきゃ。
        親コメント
        • by e2718 (23583) on 2005年12月23日 14時52分 (#854293) 日記
          #853933のACです
          http://srad.jp/comments.pl?sid=292872&cid=853933

          >うっかり120%の力を出しちゃうと、次からそれが基準になる。

          それを避けつつ、能なしのレッテルを貼られないようにしたのが
          2.で書いた方法です、中をさぼるのでトータルでは100%以下で仕事出来ます

          具体的には
          1. 雛形or骨組みを最速で提出
           とにかく速く出すことで、「出来る奴」の印象を与えることが出来ます
           また、上司も雛形・骨組みが無いと、まともな指示が出来ないので、
           はっきり言って、この時点から仕事がスターとと考える

          2. 細部は無視してとにかく速く
           上記骨組みから、上司の指示が始まりますが
           どうせ、上司からケチが付きます
           ですから、この時点で細部を詰めても無駄です
           また、細かい詰めをしていないので、
           上司も、色々ケチが付けやすく
           「出来る奴だが、まだまだ俺の助けが必要だな」
           と、上司に思わせることができ、上司は優越感に浸れます

          3. 途中の細かい指示は、形だけ合わせて適当に
           上司の指示は二転三転するのが当たり前なので
           まともに言うことを訊いていると、大変なことになる
           但し、表面上キッチリ上司の指示通りに直し
           「俺の言うことを素直に訊く、良い部下」の印象を与える

          3'.また、上司の指示と自分の考えが異なっていた場合
           表面上は指示された部分だけ、言われた通りに直し
           裏の部分は、自分の思惑通りになるよう、
           すこしづつ、軌道修正する
           上司は、自分の指示通りに動けば満足するので
           軌道修正部分は気付かない
           しかし、軌道修正部分を元に、新たな指示を出すので
           結果的には、自分の考えに誘導できる
           真っ正面から対立すると「反抗的な奴」のレッテルを貼られるので
           裏から、上司の思考を誘導するのがポイント

          2, 3. で時間・体力・精神力を温存
           要するに、働いているフリしてサボる
           但し、上司の言うことは(表面上)聞く

          4. 閉め切り間際で、120 %
           閉め切りの1-2日前だけ、徹夜して、完成させる
           そのことで、得られる効能は
           2,3で体力温存しているので、そんなに負担にならない
           最終的には、閉め切りに間に合う
           徹夜しているので、上司から「真面目な奴」と思わせる事が出来る
           でも、閉め切りギリギリなので、次回もこれ以上の量の仕事は回ってこない

          てな、感じです

          逆を考えると楽かも

          細部までキッチリした企画を閉め切りギリギリに完成
           仕事遅い奴と思われる
           この時点からまともな仕事開始なのに、既に閉め切りが迫っている
           頑張って作ったものが、上司に否定される
           嫌々修正、ここでも細部を詰めて、閉め切りが更に迫る
           嫌々やっているのが上司に伝わり悪印象
           再提出時、上司は指示とは180度違った指示を出す
           言ってること違う!!と上司への不満を募らせる
           それに気付いた上司は、悪印象を抱く
           既に、時間的・精神的・肉体的に追いつまれている
           でも、完成の目処は立っていない、時間だけが迫っている
           10日連続徹夜で、ギリギリ完成
           こんな状態で作った物だから、欠陥だらけ
           再修正が入り、結局間に合わない

           仕事遅い、反抗的、その割にまともな完成品作れない、
           と、結果的に上司に評価される
           でも、自分はボロボロ、同僚にも迷惑をかける
           その割に、自分の思惑通りの仕事になっていない

          こんなサイクルだと、仕事頑張っても評価が低くなるし
          肉体・精神を病みます
          親コメント
    • by Anonymous Coward on 2005年12月23日 0時10分 (#854079)
      事前準備と言うんでしょうか、私の場合、

      ・ そもそも納期が異常な仕事は受けない
      ・ 徹夜が必要な仕事はしない(徹夜は効率の敵)
      ・ テストの期間が入っていないような仕事はしない

      そのために、

      ・金額は一緒でも納期は通常の3倍長くさせる(スケジュールや人員に融通を利かせるため)
      ・いくつかのフェーズに分けてそれぞれの単位で動作するように仕様を分割、納品を複数回にさせる。(仕様変更対策)
      ・相手側に(バイトでもいいから)システムに詳しい人を用意させ、相手先での運用前テストに参加させる。(必要ならそのまま運用要員とするように勧める)

      あとは、
      ・それで多少仕事が少なくなっても我慢する(いい仕事をするために!)

      まぁそれでも食べてはいけるもんですよ。
      親コメント
    • by Carol (2812) on 2005年12月22日 23時11分 (#854040)
      最初にがんばりすぎてできるやつという印象を与えてしまうとその後も同じようなペースで仕事が回ってくるので、最初はこころもち遅れ気味ぐらいで最終的になんとか間に合うぐらいの力加減でやっとくのは大事かも。

      今かなりやられてるけどID
      親コメント
  • 納期・・・ (スコア:5, おもしろおかしい)

    by moromama (23126) on 2005年12月22日 20時22分 (#853934) 日記
    資材を特定のとこから納入しろといい、
    そこから買うと納期ぎりぎりにならないと入らない。
    たかい、遅い、それでも文句を言えない・・・

    途中納期で、中旬(11~20日)て書いてあって、いつまでに
    すればいいですかと尋ねると、11日に決まってるだろ!
    といわれ、
    資材納入が中旬(11~20日)て書いてあって、
    いつはいりますかときくと、20日に決まってるだろ!
    ・・・
    やけくそでID
    --
    Minder
  • 締切日時 (スコア:4, おもしろおかしい)

    by Anonymous Coward on 2005年12月22日 20時34分 (#853938)
    締め切りが23日内、と言われれば、

    23日の32時までは許容範囲内ですよね?
    • Re:締切日時 (スコア:5, すばらしい洞察)

      by Anonymous Coward on 2005年12月22日 20時37分 (#853942)
      つまり、今週中ということは、来週の月曜日の朝9時までってことです。
      親コメント
  • by Anonymous Coward on 2005年12月22日 20時43分 (#853948)
    開発中に煩雑に仕様変更を入れてくる顧客。
    こちらから仕様をあらかじめ提示しておいても、
    我々部品屋が開発してるときは前製品の検証や量産で手一杯、
    こちらの開発の後半になって、あれ変えろこれ追加してくれって
    要求が来始める訳で。
    なのに当然納期は変わらない(営業が納期交渉しようとも
    しないのも大きな問題なのだが)

    半導体は、そう簡単に修正して製造できないってのをあまり理解頂けて
    ないようで厳しいです。
  • 季節 (スコア:4, おもしろおかしい)

    by Anonymous Coward on 2005年12月22日 23時14分 (#854042)
    明確な「納期」というわけではないですが、
    「新バージョンはいつごろリリースされますか?」との問いに「夏頃にはリリースできます」と答えました。

    その年は梅雨明け発表が無いほどの冷夏でした。
    「夏が来なかったので…」と言い訳できました。
  • 保険確保が大事 (スコア:4, 参考になる)

    by Anonymous Coward on 2005年12月22日 23時56分 (#854072)
    たいていは、客先の無謀無茶強引な要求で納期遅れが発生するのだから、それらが発生する前に
    「本来の」納期をFixしておき、残りの要求は「追加仕様」という扱いで話半分にして開発続行。
    で、遅れそうになったら
    「本来の納期決まった後に追加仕様出すから予定の納期に間に合わないのは当然の事ですよ。」と
    きっぱりと言い切ります。
    追加仕様を含めても、わざとギリギリまで納品せず
    「今回は間に合いましたけど、次回はこう言う事は出来ませんよ。で、追加仕様分の請求は…」と
    絶対的に強気に押します。ここで弱音見せて、突っ込まれる事が無い様に身を守るのが大事かと。

    一度なんか、ソフトだけでも3人月、メカは組立どころか部品加工も全然終わっていないのに
    (本来の)納品日が2週間後という案件を頼まれた時は、最初から「こんな案件、やれるか」と
    わざと蹴って、仲介業者に仲とってもらって仕方無しに受ける事にして、「納期はお任せ」に
    させてもらった事も。

    #カンニング竹山の如く、「キレる」のも芸(交渉)のひとつですよ。
    #流石にACだよ
  • by pivo (27159) on 2005年12月23日 10時20分 (#854219) 日記
    記事ではこのように締めてますね。
     どうにも落としどころが難しいのですが、アンケートに「裏技術はなし」「徹夜・残業で間に合わせる」と答えた人が28人いたこともあり、少しは明るい終わり方にしたいと思います。スティーブ・ジョブズが6月に、スタンフォード大学の卒業生に語った一節を引用します。
     「人生には時として、レンガで頭をぶん殴られるようなひどいことも起こるものです。だけど、信念を放り投げちゃいけない。私がくじけずにやってこられたのはただ1つ、自分のやっている仕事が好きだという、その気持ちがあったからです」
     好きな仕事なら、やっぱり手抜きはいけませんよ。
    でも、この話題では、やはり当日のスピーチの中での別の一節がふさわしいと思う。
     私は17の時、こんなような言葉をどこかで読みました。確かこうです。
    「来る日も来る日もこれが人生最後の日と思って生きるとしよう。そうすればいずれ必ず、間違いなくその通りになる日がくるだろう」。それは私にとって強烈な印象を与える言葉でした。そしてそれから現在に至るまで33年間、私は毎朝鏡を見て自分にこう問い掛けるのを日課としてきました。「もし今日が自分の人生最後の日だとしたら、今日やる予定のことを私は本当にやりたいだろうか?」。それに対する答えが“NO”の日が幾日も続くと、そろそろ何かを変える必要があるなと、そう悟るわけです。
    今日があなたの人生最後の日でも、今のやり方で満足ですか?正しい事を正しいと主張しましょう。それが通用しない会社なら転職を検討してみては?
  • by Anonymous Coward on 2005年12月23日 12時16分 (#854252)
    atmarkitのページ、最後の纏めに以下のような文面があり、
    気分が悪くなりました。
    徹夜・残業は悪しき伝統だと思っており、少しも明るくありません。
    atmarkit>「裏技術はなし」「徹夜・残業で間に合わせる」と答えた人が
    atmarkit>28人いたこともあり、少しは明るい

    そういう現状を"あっけらかん"として認めることは
    「無理な納期」「サービス残業」等の問題に対して
    一石を投じることを放棄しているにも等しいでしょう。
    従って、以下の文面とは矛盾しています。
    atmarkit>スタート地点から納期達成は難しいということだ。
    atmarkit>それなら、こうした無理のある計画こそ問題視すべきではないか。

    自分の仕事に誇りを持っているので、サービス残業の強要は
    引き受けませんし、休日出勤も徹夜もしません。

    何に怯えて、引き受けるのでしょうか。
    本当に「プライドに賭けて」無償でやっているのですか?
    目を覚ませと言いたいですね。
  • by Anonymous Coward on 2005年12月22日 20時26分 (#853935)
    って本があれば済みそうだなぁ
  • いっそのこと (スコア:3, すばらしい洞察)

    by Anonymous Coward on 2005年12月22日 22時53分 (#854027)
    逃げるとか。

    そもそも、絶対間に合わないプロジェクトという
    ハイリスクな仕事でも受けなきゃ成り立たない組織に未来があるとは思えない。

    無理してやって、
    開発者が倒れるか(人を消耗品と思っている)
    納期が遅延する(信用問題、見積もり以上の開発コスト)
    バグが多発する(信用問題、アフターサポートで死ぬ)

    こんなリスクを抱えているプロジェクトでも
    受けなきゃいけない組織に未来があるとは思えないなー
    #そのリスクに見合うリターンってあるんかいなー

    と、思ってみるテスト
  • できれば (スコア:3, すばらしい洞察)

    by ta98 (10561) on 2005年12月22日 23時48分 (#854066) ホームページ
    「納期を伸ばすための裏技術」のほうがいいなあ。
    仕様がかわりました、資料が予定期日より大幅に遅れて届きました、
    「でも納期はそのままでやってくれ」
    いつまでもまかり通るってのはおかしいよ。

    #そんなこと言えるかってのが現状だが、
    #言ってずばんと辞めた過去あり
    #おかげで貧乏神が住むことになったが…
  • by Anonymous Coward on 2005年12月23日 2時50分 (#854150)
    こんなときには納期を守り(れ)ません
    ・納品方法が決まってない
    ・納品物が決まってない
    ・開発プラットフォームも決まっていない
    ・そもそも契約してなかった
    ・担当がずっと行方不明
    ・納入先に誰もあったことがなく、住所を調べたら架空のものだった
    ・お願いされたのが今日で、すでに納期を過ぎていた
  • by masayang (13412) on 2005年12月23日 5時52分 (#854169) ホームページ 日記
    この二年ほどXPやらSCRUMやらの開発手法をおっかけています。

    最近のシステムは昔より複雑化しているので、お客さん自身もどんなシステムが欲しいのか、要件定義段階では頭の中に描けなくなってきているし、開発する側も見積が困難になりつつあるわけです。

    そういう状況で納期と予算を定めて開発をするというのはお客さん側も開発側も相当なリスクを背負う必要があります。

    ならば優先度の高い要件から順次開発していくAgile型手法のほうがお客さんも開発側もハッピーになれるのではないかと。

    ちなみに件の「納期が決まっている場合」の対処は、Agile的には「機能を絞る」です。

    以下、愚痴。
    だいたいさー、後からねじこんでくる要件って多くはお客さん内部の特定担当者のエゴがほとんどで、そんな機能なくても日常業務にはまず影響ないし、せっかく作ってあげてもほとんど使われることなんてないわけよ。でもこういう「ねじ込み屋」って声はでかいから敵に回すと後々面倒。つまるところ対処するしかない。で、納期がきつい局面では、他の重要な部分に手間暇かける時間がなくなって、全体的には非常に迷惑。
    以上、愚痴。

    なんていう自分の経験をふまえて言えば、もっと開発者とお客さんが協力して開発を進められるような体制なり手法なりが理想なわけで、そうするとXPとかSCRUMちうのは良くできているなぁ、と思ってしまいます。でも、お客さん側の(それも意思決定層の)理解がないと、なかなか難しいのですね。。。
    --
    ---- 末は社長か懲戒免職 なかむらまさよし
    • by Anonymous Coward on 2005年12月24日 1時14分 (#854533)
      アジャイルという単語を出せば、なんか高評価をうけるご時世ですが、正直、疑問に感じています。
      まあ、私自身、アジャイルというのはあまりよく分かっていない部分もあるのですが。

      でも、斜め読みした書籍やサイトから、まず最初に感じたのは、
      なんか、アジャイルの話って、お客さんがあまりにも優秀で、物分りがいいという前提に立ちすぎており、
      結果、開発する方の、費用・納期・資源という部分の戦略に欠けていると感じていました。

      それでも、この前、顧客の要件が大まかな枠組みのみ決まっている案件に対して、実験的に顧客の担当者を
      スケジューリングや開発の現場にコミットさせてみたのですが、以下のような問題で大混乱となりました。
      (私は通常、プロマネや営業に近いことをしているんですが、今回は外から見ていました。)

      1. 顧客の中で全ての要件の優先順位づけが上手く行くことがない。
            優先度の高い要件はころころ変わり、開発は何も手をつけることができない。
            結果、時間と無駄なコードばかり量産されて成果物は上がらない。
            最終的には、納期に近づくにつれ、同じ順位づけを強制される。(全てやれとなる。)

      2. 顧客と開発者が直にやり取りすることにより、開発スコープが混乱し、本来契約や要件にない項目などが
            開発スコープにあらわれ、大混乱となる。
            情報共有にはある程度のタイムラグが存在し、また、全ての開発者が全ての要件や制約を把握しているわけではない。
            その状態で、要件を定めることに適切な開発者が拒否した要件を、顧客が別の開発者に持ちかけ、
            開発者誰かを騙せれば、仕様をねじ込むことが出来るという状態となり、仕様は肥大する。
            しかし、開発側が期間内に可能だとし、仕様変更を許可したという理由で納期は変わらない。

      3. ドキュメントが防波堤にならない為、顧客や開発者が過去に発言した事が
            顧客の都合のよい形で、それぞれ場面場面に採用されてしまい、仕様が肥大する。当然納期は(以下略。

      4. 2に関連して、顧客が雑談などで話したことが、なぜか仕様の一部になり、拒否できない状態となること多数。
            開発者は顧客と雑談をすることすら疑心暗鬼となり、コミュニケーション以前の問題となる。

      5. 2に伴い、開発スコープが勝手に肥大化することにより、営業的に大失敗となる。
            元の要件が曖昧である為、増えた仕様により、費用を取るのが難しい。

      6. 顧客が開発者のスケジュールなどを把握できる為、要件が膨らむ(納期に近づくにつれ)につれ、
            開発者が休みなどを取れなくなり、開発者の消耗が激しい。
            また、開発者が休みが取れるほど余裕がある場合は、顧客が新たな優先順位の高い要件を作り出す。
            納期まで、自動的にデスマーチとなる。

      7. 顧客の営業的な理由で、段階的な成果物のアウトプット自体が不可能。
            特に、夢を見ている顧客ほど、デカイものを一発リリースしたがる。

      8. 1-7の結果、モノが納期までに出来なかったとしても、結局のところ、顧客に責任はない。
            顧客の望むものを出せなかった開発側が非を背負う。

      今回は、自社のプロマネ全てを開発陣自身の任せてみたという点と、
      納期と見積もりを切った後の案件で行ったというのが大きな原因だったわけですが、
      だからといって、前者に関しては、プロマネと営業をプロジェクトにくっつけるのであれば、
      普通に顧客とは、プロマネと営業を介してやったほうが、混乱も負担も少ないように感じますし、
      後者に至っては、通常の会社の稟議システムの面倒さを考えると、それを変えること自体が営業的なリスクになります。

      また、蛇足ですが、この顧客の担当者、まったくの無能でもなければ、悪い人でもないです。
      でもまあ、担当者の能力や性格以前に、よくよく考えてみると、このスキームが上手く行くには、
      顧客自身もプロジェクトの開発側部分にも責任をもって、そして、顧客自身も費用や納期、リリースを柔軟さを求められるわけです。
      でも、そんなの、零細企業のワンマン社長でもなければ、無理だと判断しました。

      ということで、自社内案件以外、2度とアジャイルっぽいものには近づかない方向で。
      親コメント
      • by masayang (13412) on 2005年12月24日 3時54分 (#854573) ホームページ 日記
        果敢に挑戦した事例、興味深く読ませていただきました。直接関わったわけではないし、文面経由なので外しているかもしれませんが、いくつか鍵となる言葉を拾ってコメントを。

        >顧客の要件が大まかな枠組みのみ決まっている案件に対して

        どれくらいの枠組みなのかはこれだけではわかりませんが、顧客にとってのゴール(これができるようになる、何が改善される)が明確でなければ、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は日本の製造業が手本になっているわけです。そして日本のソフトウェア産業はなぜか建設業界を手本にしています。

        手本を間違えているから、いろいろ悲劇が起きているのではないかなぁ...

        長文、失礼しました。
        --
        ---- 末は社長か懲戒免職 なかむらまさよし
        親コメント
  • by jammer (22459) on 2005年12月24日 10時08分 (#854611)
    ファインマンさんは言いました

    //以下引用
    子どもが道のまん中に走り出たのを見た両親が怒って
    「危ないじゃないか!」と叱ったとする。
    すると子どもが戻って来て
    「だって何事も起こらなかったよ!」と言う。
    そしてまた道のまん中に走って出る。
    それを何回も繰り返すわけです。
    親はそのたびに「危ないぞ!危ないぞ!」と言い続けている。
    だが何事も起こらない。
    しかしその子が今まで何も起こらなかったということを、
    これからも決して何事も起こらないことと解釈したとすると、
    事故は必ず起こるに違いない。
    ブレーキが軋む音が二、三回は聞こえるでしょう。
    これはガス漏れ、シールをガスが焼き抜くというようなことのたとえですよ。
    //引用終り

    この場合母親は技師たち、子どもは管理職の連中のことらしい。

    が力関係が働いて母親が何も言えなくなっている?

    参考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]
  • by sameshima (10060) on 2005年12月22日 21時07分 (#853962) 日記
    2本の仕事を並行するときに
    1日を2で割ってticktimeを12時間にします。
    3時間スリープして、のこり9時間のうち 2時間を食事休憩にとって、
    残業無しで7時間働くと、1ヶ月が60日になります

    #やってみたのですがラウンドロビンになってしまい
    #うまくいきませんでした
    • by kitsune.info (18329) on 2005年12月22日 23時11分 (#854039) ホームページ

      納期を守るため、人材を二重化してみたら賃金が半分になりました。
      決済を早めるため、稟議書を回すルートを二重化したらパケットが行方不明になりました。
      仕方がないので一番優秀な人材を投入して二週間ほど昼夜を問わずぶん回したら、動作中に「お花畑がきれいだな」とか異音を発するようになりました。ちなみに昨夜から ping 無応答です。

      あかん、親コメの粋を壊してもーた orz

      --
      [わかってもらうことは難しい。わかってあげることは、もっと難しい。]
      親コメント
  • by Anonymous Coward on 2005年12月22日 22時06分 (#854000)
    デッドラインを決めた後に機能追加や工期短縮を申し入れるのは受託側の過失が無い限り禁止…とか(いや、適当に書いてみただけど)。双方に資格を持った交渉役を置くとか…。

    まぁ、平たく言うと我々IT土方に徹底的に有利な法整備をしてくれるような議員さんを国会に送り込もうというわけ(哀
  • by Anonymous Coward on 2005年12月22日 22時10分 (#854004)
    とりあえず倒れる・入院する。
  • by jtakano (13491) on 2005年12月22日 22時29分 (#854012)
    見積もりを出しているのなら、その後も営業に探りを入れていれば、
    進行状況もわかるので予測はできますよね。
    また、経営者は売り上げも当然ながら「効率よくすすめる」や
    「最大限の利益」という言葉が好きですから
    それらの言葉を組み合わせて、経営者も巻き込んで
    デッドラインを告げておく必要があります。

    少しでも気配りしておけば、納期を過ぎてから依頼が来ることは
    なくなると思います。
  • by Anonymous Coward on 2005年12月23日 0時27分 (#854087)
    「悪魔に心を売っても納期を守る! 裏技術」を読んだのですが、唖然。
    これって量産したら大変なことになるようなことがいっぱい。

    一品モノってこんなに手が抜けるのね…と羨ましくなってしまいました。

    #テストで手を抜くなんて考えられないのでAC
typodupeerror

犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー

読み込み中...