開発プロセス

→プロジェクト管理

→見積もり・発注

→CI/CD

サブトピック†

• アジャイル

話題†

• ウォータフォールはやめて2024年の開発をやろう！｜牛尾　剛 2024.6

• システム開発の基礎〜システム開発の全体像を捉えるV字モデル - Speaker Deck 2023.5

• XDDPとは 2017.4
  • eXtreme Derivative Development Process

• ソフトウェア開発プロセス残酷物語 2012.8.26
  • 鎖でしばってもダメエンジニアは使えなかった。」
  • 「それどころか、むしろ同僚や自分自身が鎖にしばられて、かえって組織全体の生産性を落としてしまったのではないか。」

• 日本型ソフトウェアファクトリーこそ真の敵 2012.7.12

• Web2.0時代のソフトウェア開発手法

• SW開発で火を噴くパターン 2009.3.15
  • SW開発ではいつも結合テスト以降で火を噴く。

• ソフトウェア工学」は矛盾語法か？
• 大規模プロジェクトの課題を解消する、たった1時間で行うふりかえりの工夫 | MEDLEY Developer Portal 2024.7
• ふりかえりを実践してみて 2008.12.27
  • 現場から問題点のフィードバックがあれば、管理者も開発者もその問題を解決しようという行動が自然に出てくる。
  • 「ザ・ファシリテーター2―理屈じゃ、誰も動かない!」では、人は問題に気付くと問題を解決しようと自然に動くものだ、という一節がある。
  • リスク管理に敏感な管理者ほど、リスクを嗅ぎ取るためのフィードバックを大切にするものだ。
  • すると、フィードバックする雰囲気作り、場作りが重要になってくる。
  • このフィードバックプロセスをマネジメントとしてフレームワーク化したものが「ふりかえり」だと考える。

• プログラミングファーストの開発のアキレス腱 2008.7.21
  • 客がそれを安易だと勘違いして、安価だと思いやすい
• プログラミングファースト開発の必要性 2008.7.21
  • 最初に要件定義をして概算の見積りを出す。これは準委任契約(成果物ではなく、人月で請求する)。
  • 次に顧客と仕様を実装に落とす部分(プログラミングファースト)も準委任契約で行なう。これも工数がどれくらいになるかは確定しにくいから、準委任契約が良い。
  • プログラミングファーストで仕様が固まったら、後は、一括請負(成果物ベースで請求する)でドキュメントやテストなどを行なう。
  • この形態なら、SIerでも契約しやすい。

• プログラミングファースト開発 2008.5.2

開発プロセスの種類†

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

プロセス改善†

• 週1時間の取り組み「KAIZENアワー」は技術負債の解消にとどまらない、エンジニアが成長する場として機能【デブサミ九州2017】 (1/2)：CodeZine（コードジン） 2017

• サイボウズの開発を支えるKAIZEN文化 2016

ウォーターフォール†

• 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ 2024.6

• ウォーターフォールの歴史 2012.7.20

• 「ウォーターフォール開発」、本当に日本でうまく行っているのか？

• 「ウォーターフォール型開発は80年代の技術」 2010.8.9

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

CMM†

• “開発のよくある問題”を解決するCMMIの3大メリット 2012.5.23
  • メリット1――情報共有
  • メリット2――定量分析による合理的な意志決定
  • メリット3――グローバル対応

• CMM5でもCMM1に劣ることがある 2008.9.6
  • プロセスの完成度とエンジニアリングの力は別だから

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

• CMMI Main Page
• CMM解説

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）調査研究により，プロジェクトの基本構想文書，基本方針書，基本図面を策定する活動

最新の50件