先駆者に学ぶ「開発プロセス改善の原則」
「新しい秩序の確立は他の何にも増して困難である。なぜならば、改革者は旧秩序から利益を得ているすべての者を敵にまわし、新秩序から利益を受けるはずの者からは熱のこもらない支持しか期待できないからである」（1513年 ニコロ・マキャヴェッリ） ソフトウェアの開発プロセスを変えることは、規模の小さな試験的なプロジェクトに携わっているときでさえ難しいものです。ましてや、対象となるプロジェクトの規模や、部門、組織が大きくなると、これが飛躍的に難しくなります。 本稿は、開発プロセスの変更をこれほどまでに難しくしているものが何であるか検証します。そして、組織改編の際に形式にかなった「プロセス改善計画」が果たす役割を検討して、計画を成功させる確率の向上を目指し、適用可能な経験則をいくつか紹介しましょう。 プロセスの変更は組織の変更である 「プロセス改善計画」とその影響について検討する前に、まず、ソフトウェア
開発チームの改善効果を定量データでアピール！
開発チームの改善効果を定量データでアピール！：今日からできる“CMMI流”開発効率改善術（4）（1/2 ページ） ソフトウェアの測定は一般的に難しく、活用度も低いと言われる。どのように難しいのだろうか。それを明らかにするとともに、CMMIの考え方を適用した定量的なプロセス改善について解説する。 ソフトウェアの世界に定量的な評価は必要か 今回から2回にわたりCMMI（Capability Maturity Model Integration、能力成熟度モデル統合）の考え方を使った定量的なプロセス改善について説明します。 残念ながら、定量的な改善についてソフトウェアの世界ではあまり良い評判を聞きません。皆さんのプロジェクトでは、「この数字、自分にとっては用がないのだけど、何のために報告しているのだろうか」「バグ密度の水準って、いつも実際の数字の範囲とずれているのだけど、参考になるのだろうか」な
プロセス改善の基本｜AccuRev
改善の目的は何か？ プロセスを改善する活動は、効率・品質・納期といったQCD (Quality, Cost, Delivery)を向上させるために実施されます。 QCDが向上すれば、顧客のニーズに応え、さらに企業ブランドを維持・向上させ、結果としてビジネスを成功させることができます。重要なポイントは「プロセス改善は単なる手段であり、目的ではない」ということです。 短納期 ソフトウェア開発の受注（または開発の開始）からソフトウェアがリリースされるまでの期間が短いもの。 必要な理由 顧客のビジネススピードが早くなったため、そのニーズに応えるためになるべく早くソフトウェアをリリースする必要があります。開発に時間がかかってしまうと、開発開始時点で"最新"であった技術が、ソフトウェアのリリース時点では既に古い技術になってしまう可能性があります。 実現する一般的な方法 開発者を多く投入する（リソースを
「標準の開発プロセスが欲しい，でも自社にはない」
日経ITプロフェッショナルは，システム開発の現場でどんな開発プロセスが使われているのかを調べるために，Webサイト（IT Pro）上で「開発プロセスに関する実態調査」を実施した。その結果，「勤務する企業や組織に標準的な開発プロセスがあるのは5割強」「標準的な開発プロセスはウォーターフォール型が8割強」「Webシステム開発では反復型が6割を占める」――など，これまで知られていなかった実態が明らかになった。 調査では1542人から有効回答を得た。IT Proの読者にもご協力をお願いしている（関連記事）。回答していただいた皆さんに，この場を借りて感謝したい。なお，詳細な結果は日経ITプロフェッショナル7月号特集「決定版！開発プロセス大全」の中で掲載している。ここでは，その主要部分を紹介していこう。 「自社標準がある」は52.2％ 調査ではまず，企業，組織に標準的な開発プロセスが必要と思うかどうか
開発プロセスと開発標準化 | ITエンジニアが作るメディア Tech Fun Magazine
通常、受注をする前に営業やITコンサルタントが、エンドユーザのシステムに関する要望や、現状システムの問題点などをヒアリングします。要望や問題点を踏まえて企画を立て、エンドユーザにプレゼンをして内容のすり合わせを行います。 要件定義では、エンドユーザの現状業務をシステム分析し、業務要件とシステム化するために必要なことを定義します。また、要件定義を、システム方式設計と呼ぶ場合もあります。 エンドユーザは、システムについて詳しくない場合もあります。要求が曖昧だったり、矛盾することもあります。実現可能なものとして、エンドユーザの要求をITコンサルタントやSE（システムエンジニア）がとりまとめていきます。 エンドユーザとシステム開発者で認識のズレが生じると、致命的な設計上の欠陥や実装漏れにつながる可能性があります。
＠IT：開発プロセス標準化への道（1）
この短期連載は、社内のソフトウェア開発プロセスの標準化に日夜取り組んでいるあなたにぜひとも知っていただきたいことをお伝えしていきます。理由は、それ（ソフトウェア開発プロセスの標準化）がうまくいっているという話を、少なくとも私はほとんど聞いたことがないからです。 標準化の目的 そもそもなぜ、開発プロセスの標準化に取り組むのでしょうか。ソフトウェア開発組織の使命は、顧客のビジネスの成功に対する貢献であると、わたしは考えています。そして、日々その貢献度を上げていかなければ競争を生き残れないと感じています。事実、多くの開発組織では、表現に違いはあるものの、同様の内容を自らの使命として掲げています。そして、貢献度を上げるための手段として、自身の開発力を高めていこうとしているのです。 開発力を高めるための手段としては、 特定の分野に特化する 開発期間の短縮 開発コストの削減 品質の向上 といったことが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.ipa.go.jp/archive/files/000005368.pdf
https://www.ipa.go.jp/archive/files/000004771.pdf