プロジェクト管理

見積もり・発注

話題

  • XDDPとは 2017.4
    • eXtreme Derivative Development Process
  • ソフトウェア開発プロセス残酷物語 2012.8.26
    • 鎖でしばってもダメエンジニアは使えなかった。」
    • 「それどころか、むしろ同僚や自分自身が鎖にしばられて、かえって組織全体の生産性を落としてしまったのではないか。」
  • ソフトウェア工学」は矛盾語法か?
  • ふりかえりを実践してみて 2008.12.27
    • 現場から問題点のフィードバックがあれば、管理者も開発者もその問題を解決しようという行動が自然に出てくる。
    • 「ザ・ファシリテーター2―理屈じゃ、誰も動かない!」では、人は問題に気付くと問題を解決しようと自然に動くものだ、という一節がある。
    • リスク管理に敏感な管理者ほど、リスクを嗅ぎ取るためのフィードバックを大切にするものだ。
    • すると、フィードバックする雰囲気作り、場作りが重要になってくる。
    • このフィードバックプロセスをマネジメントとしてフレームワーク化したものが「ふりかえり」だと考える。
  • プログラミングファーストの開発のアキレス腱 2008.7.21
    • 客がそれを安易だと勘違いして、安価だと思いやすい
  • プログラミングファースト開発の必要性 2008.7.21
    • 最初に要件定義をして概算の見積りを出す。これは準委任契約(成果物ではなく、人月で請求する)。
    • 次に顧客と仕様を実装に落とす部分(プログラミングファースト)も準委任契約で行なう。これも工数がどれくらいになるかは確定しにくいから、準委任契約が良い。
    • プログラミングファーストで仕様が固まったら、後は、一括請負(成果物ベースで請求する)でドキュメントやテストなどを行なう。
    • この形態なら、SIerでも契約しやすい。

開発プロセスの種類

  • CI(Continuous Integration) - 継続的インテグレーション
  • UP(ユニファイドプロセス)−フォーマルプロセス
  • XP エクストリーム・プログラミング - アジャイルプロセス
  • MSF (Microsoft Solutions Framework) マイクロソフトの開発プロセス
  • ICONIX ドメインモデルから始めるミドルアウトプロセス(???)

ウォーターフォール

  • なぜウォーターフォールは捨てられないのか? 2009.2.20
    • ウォーターフォール開発は、マネジメント的にもビジネス的にも楽なのである。計画的に人を積み、要件定義を(価値がなくとも)しっかりやり、それに基づき(必要なくとも)開発要員をどっぷり投入し、誰にも疑問を抱かせず、最初に定義された要求の実現だけを滝の流れに逆らわず行うだけで開発を終えられる。これほど、楽観的なマネジメント手法はない。
    • 実はこの方法は、ユーザー企業からも歓迎される傾向にある。なぜなら、契約面から考えても、ウォーターフォール開発は、最初に決まっていないリスクを排除できるように見えてしまうからだ。ユーザー企業とITベンダ双方ともリスクを取りたくないという逃げの姿勢の中で成立している開発プロセスなのであるが、実際には、そのリスクが高まっている事実に気が付かないでいるのだろう。あるいは、気が付いていてもこのビジネス形態を壊すのが怖いのかもしれない。

アジャイル

  • 海外でなぜアジャイル開発が普及しているのか? IPAが分析と提言 2012.6.13
    • 米国では、ソフトウェアに対する投資が「自社開発(内製)」「パッケージソフト」で約3分の2を占めており、IT技術者の7割以上がユーザー企業に属しているという特徴が見られました。つまり他国に比べて同一組織内でソフトウェア開発を行うことが多く、契約を交わす必要がないため、ソフトウェアの変更に対応しやすいと考えられます。
    • デンマークでは政府が発注するソフトウェア開発をアジャイル開発で行うことが推奨されており、できるだけ小さく始め、柔軟な計画変更ができるといった契約になっているそうです。
  • アジャイルって受託開発との相性が最悪な気がする 2010.2.12
    • 工程の分断が絶対許されないから、上流工程と下流工程を別会社が担当する今の日本の受託開発業との相性は最悪だね。自分たちで全部やれる人材が揃ってないといけない上に、コミュニケーションを綿密にとらないと成果物がグダグダになりそうだから、人月との相性も悪い。
    • 要件まとめてぽーんと丸投げしたほうがSIerとしては美味しいわけだから、なんでこんな苦労を別にしなくちゃならないの的な話になってる所がいっぱいいそうなんだけど、どうだろう。アジャイル導入って自己否定なんじゃないのかしら。だからやりたくても出来ないんだね、これ。
    • 滝には色々問題があるけれど、滝は契約体系としてはわかりやすいし、お金の積み方が合理的に説明しやすいという点はあると思う。リスクマネーが利益の源泉になることが多いしリスク取るからおカネを請求できるわけで、そこが不明瞭で不確かだろうが「○○円でいつまでにやります」とコミットするから契約を結ぶ価値が出てくるわけなんだけど、アジャイル開発のやり方だとどう説明するの?
  • アジャイルは二度死ぬ
  • Through 分類別INDEX
  • Agileが根付かないもう一つの理由 2009.2.28
    • 「1年間1.2億円」で見積もったプロジェクトがあったとしよう。
    • 下記筋書きのどちらが嬉しい?
      • 開始後一ヶ月で中止に追い込まれ、お客さんからは月割りで1000万円だけしか回収できなかった。ただし、デスマーチにはならなかった。チームは次の仕事に向けて鋭気を維持できた。
      • 1年間開発を続けたが完了せず、要因追加&デスマーチで2ヶ月超過。お客さんからは1.2億円もらったが、超過分の原価で赤字になった。チームの半分以上は病気になった。
    • ほとんどの受託システム開発業者は、後者を選ぶのではないかな。DDJの記事にあるように、Agileの失敗率は「20%」。2割の確率で予算未達が発生する、と考えるとビビる経営者は多いはず。
    • 予算達成重視主義も、日本におけるAgile普及の足かせになっているのではないかね。
  • 裏プロセスは並行プロセス 2008.2.20
    • 大規模プロジェクトでアジャイル開発を選択できない最大の理由は、機能分割するモデリング力が足りないからではないか、と推測している。
    • イテレーション毎にリリースしていくには、膨大で複雑な業務を、イテレーションが定める期間内かつリリースできる単位に機能分割して仕様へ落とさなければならない。

CMM

  • 「日本版CMM」へのパブリックコメントに絡むSEA-SPIN ML の議論
    • 中小ベンダーが直接応札するようになるか? これは、長い歴史と根強い慣習に基づく大変困難な問題と認識しています。しかも業界の多くを占める実質人月売りの低リスクビジネスにどっぷり浸かり、リスクのある、自立した請負いビジネスを避ける慣行は、国際的にも特異で、もし国際競争力をつけたいのならば、何としても改善しなくてはならない。
    • インドが優れているのは、プロセスのレベルではなくて、自立したビジネスマインド
    • 改善するには、荒療治が要るでしょう。つまり、どんどん、アメリカやインドにアウトソースして、ショックを与えて、いかに自分達が世界的な慣行からみて、おかしなビジネスをしているかを知らしめるしかないでしょう。もちろん、国際化しているところは問題ないわけです。このショック療法を経なければ、国際競争力をつけることはできません。

Software Factory

  • 製造業をモデルにしたソフトウェア開発
  • @ITの解説記事
  • 解説
  • MSの提唱する管理プロセス
    • Standish Group [Sta 94] によると、アメリカでは毎年、およそ 17 万 5000 のプロジェクトにおいて、約 2500 億ドルのソフトウェア開発費を費やし
    • これらのプロジェクトのうちスケジュールと予算の枠内に収まるのは 16 パーセント
    • その他のうち、主に品質の問題によりキャンセルされたものは 31 パーセント、その損失額は 810 億ドル
    • 予算を超過(平均で 189 パーセント)したものが 53 パーセント 損失額はおよそ 590 億ドル
    • 本来の計画にあった機能を満たして完遂したプロジェクトは平均 42 パーセント
  • art of project management@MSDN

P2M

  • 超上流を成功させる17か条 2007.5.9
    • 原理原則[1] ユーザとベンダの想いは相反する
    • 原理原則[2] 取り決めは合意と承認によって成り立つ
    • 原理原則[3] プロジェクトの成否を左右する要件確定の先送りは厳禁である
    • 原理原則[4] ステークホルダ間の合意を得ないまま,次工程に入らない
    • 原理原則[5] 多段階の見積りは双方のリスクを低減する
    • 原理原則[6] システム化実現の費用はソフトウェア開発だけではない
    • 原理原則[7] ライフサイクルコストを重視する
    • 原理原則[8] システム化方針・狙いの周知徹底が成功の鍵となる
    • 原理原則[9] 要件定義は発注者の責任である
    • 原理原則[10] 要件定義書はバイブルであり,事あらばここへ立ち返るもの
    • 原理原則[11] 優れた要件定義書とはシステム開発を精緻にあらわしたもの
    • 原理原則[12] 表現されない要件はシステムとして実現されない
    • 原理原則[13] 数値化されない要件は人によって基準が異なる
    • 原理原則[14] 「今と同じ」という要件定義はありえない
    • 原理原則[15] 要件定義は「使える」業務システムを定義すること
    • 原理原則[16] 機能要求は膨張する。コスト,納期が抑制する
    • 原理原則[17] 要件定義は説明責任を伴う
  • P2Mにおける「スキーム・モデル」とは
    • (1)プロジェクト目的・目標,
    • (2)基本運営方針,
    • (3)基本要求仕様書,
    • (4)プロジェクト協調関係,
    • (5)期待成果,
    • (6)制約条件,
    • (7)調査研究により,プロジェクトの基本構想文書,基本方針書,基本図面を策定する活動

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-06-20 (水) 21:22:27 (1037d)