アジャイルソフトウェア開発の契約 [プロジェクト管理]
アジャイルソフトウェア開発における契約。
やはりこの問題、まだ十分に解決されていないようですね。
この記事ではフェーズ開発契約や「money for nothing, changes for free（早期解約と無料変更）」契約を推奨しています。
money for nothing, change for free契約というのが実現できるのであれば一番Win-Winな気がしますが・・・。
進行基準などの会計処理はどうなるんだろう？？？とふと思ったりもします。まだまだ難しそう。
やはりこの問題、まだ十分に解決されていないようですね。
この記事ではフェーズ開発契約や「money for nothing, changes for free（早期解約と無料変更）」契約を推奨しています。
money for nothing, change for free契約というのが実現できるのであれば一番Win-Winな気がしますが・・・。
進行基準などの会計処理はどうなるんだろう？？？とふと思ったりもします。まだまだ難しそう。
アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
- 作者: Mike Cohn
- 出版社/メーカー: 毎日コミュニケーションズ
- 発売日: 2009/01/29
- メディア: 単行本（ソフトカバー）
アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣
- 作者: Venkat Subramaniam
- 出版社/メーカー: オーム社
- 発売日: 2007/12/22
- メディア: 単行本（ソフトカバー）
- 作者: 金子 智朗
- 出版社/メーカー: 日経BP出版センター
- 発売日: 2009/05/13
- メディア: 単行本
バグトラッキングは必要なのか？！ [プロジェクト管理]
先日「アート・オブ・アジャイル デベロップメント」を読んで、少し前のInfoQの記事を思い出しました。
『バグトラッキングシステムなんて捨ててしまえ？』
何をバグとするのか、どのレベルで管理するのかという問題になってしまうのですが「アート・オブ・アジャイル～」やInfoQの記事の通りに完全Done以降の問題をバグと考えるのがXPでは自然なような気がします。
このレベルでは問題の数が激減している”はず”。ならばおおげさなシステムは不要なのか？？？そんな気もします。
とはいえ、OSSではバグトラッキングである程度の成功をしている。まったく不要ということはないだろう・・・。
（そもそもバグと呼ぶべきか、イシュートラッキングのほうが正しいか？）
トラッキングしてその後どうするの？というところをちゃんと考えないと無用な作業になってしまうかもしれない。
何をもって品質管理するかという大きな問題なのかもしれないし・・・。
アジャイルを適用すると、今まで当たり前にやってきたことも本当に必要なのか考え直す必要があるんだな～。結構難しい。
こればかりは実践の経験をもっと積まないと議論に参加することもできないかな。
『バグトラッキングシステムなんて捨ててしまえ？』
何をバグとするのか、どのレベルで管理するのかという問題になってしまうのですが「アート・オブ・アジャイル～」やInfoQの記事の通りに完全Done以降の問題をバグと考えるのがXPでは自然なような気がします。
このレベルでは問題の数が激減している”はず”。ならばおおげさなシステムは不要なのか？？？そんな気もします。
とはいえ、OSSではバグトラッキングである程度の成功をしている。まったく不要ということはないだろう・・・。
（そもそもバグと呼ぶべきか、イシュートラッキングのほうが正しいか？）
トラッキングしてその後どうするの？というところをちゃんと考えないと無用な作業になってしまうかもしれない。
何をもって品質管理するかという大きな問題なのかもしれないし・・・。
アジャイルを適用すると、今まで当たり前にやってきたことも本当に必要なのか考え直す必要があるんだな～。結構難しい。
こればかりは実践の経験をもっと積まないと議論に参加することもできないかな。
「アート・オブ・アジャイル デベロップメント」
本書はXP（エクストリームプログラミング）をベースに書かれたアジャイル開発の本ですが、他のアジャイルメソッドでも十分に通用します。
この本を読むまでにアジャイルメソッドに係わるさまざまな本を読んできましたが、本書はそれを包含するだけでなく、擬似的な経験を通じて読者をある一定レベルのアジャイル開発者に導いてくれます。
この本を読んでいて、「こうやれば成功するな～」といったイメージが出来上がってくるのです。アジャイル開発を始めたばかり、もしくはこれからはじめようと考えている方にはぜひ読んでいただきたい。
以下略
アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング
- 作者: James Shore
- 出版社/メーカー: オライリージャパン
- 発売日: 2009/02/18
- メディア: 大型本
- 作者: クジラ飛行机
- 出版社/メーカー: ソシム
- 発売日: 2009/03
- メディア: 単行本
「アート・オブ・アジャイル デベロップメント」 [プロジェクト管理]
本書はXP（エクストリームプログラミング）をベースに書かれたアジャイル開発の本ですが、他のアジャイルメソッドでも十分に通用します。
この本を読むまでにアジャイルメソッドに係わるさまざまな本を読んできましたが、本書はそれを包含するだけでなく、擬似的な経験を通じて読者をある一定レベルのアジャイル開発者に導いてくれます。
この本を読んでいて、「こうやれば成功するな～」といったイメージが出来上がってくるのです。アジャイル開発を始めたばかり、もしくはこれからはじめようと考えている方にはぜひ読んでいただきたい。
そして、次のような従来常識と思っていたことが「やはり」間違いであったことがわかります
・ステップ数によるソフトウェア規模の見積もり
・実装ステップ数による生産性の管理
これらはアジャイル開発というものが今のようにメジャーになる前から私自身「おかしい」と感じていたものでした。
それでも日本のIT文化の中ではこれらがなかなか消えていかない。当たり前のように考えられています。そうした管理側の方にもこの本を読んで今までの常識は今では非常識であることを理解して欲しいです。
そして、なかなかアジャイル開発が適用できない現場の管理者の方々には「ソフトウェア開発もスループットが重要なのだ」ということをもっと理解して欲しいです。ウォーターフォールは決まった仕様の中で着実にプログラミングするには適したものかもしれません。しかし今の時代は決まった仕様というものは存在しない。「ある程度正しい」と思われる仕様しかないのが現実です。極論を言えばやってみなければわからない。または実行しながら改善するのが今の時代の経営スタイル。とにかく早期に実現していくことこそソフトウェアに求められることだと思います。このような時代に前世代的なウォーターフォールで開発すること自体、大きな経営リスクであるということをもっと理解して欲しいと思います。そして生産性はスループットで考えるべきである、ということも理解して欲しいです。
こうした様々なことを考えさせられる、非常に中身の濃いものでした。
この本を読むまでにアジャイルメソッドに係わるさまざまな本を読んできましたが、本書はそれを包含するだけでなく、擬似的な経験を通じて読者をある一定レベルのアジャイル開発者に導いてくれます。
この本を読んでいて、「こうやれば成功するな～」といったイメージが出来上がってくるのです。アジャイル開発を始めたばかり、もしくはこれからはじめようと考えている方にはぜひ読んでいただきたい。
そして、次のような従来常識と思っていたことが「やはり」間違いであったことがわかります
・ステップ数によるソフトウェア規模の見積もり
・実装ステップ数による生産性の管理
これらはアジャイル開発というものが今のようにメジャーになる前から私自身「おかしい」と感じていたものでした。
それでも日本のIT文化の中ではこれらがなかなか消えていかない。当たり前のように考えられています。そうした管理側の方にもこの本を読んで今までの常識は今では非常識であることを理解して欲しいです。
そして、なかなかアジャイル開発が適用できない現場の管理者の方々には「ソフトウェア開発もスループットが重要なのだ」ということをもっと理解して欲しいです。ウォーターフォールは決まった仕様の中で着実にプログラミングするには適したものかもしれません。しかし今の時代は決まった仕様というものは存在しない。「ある程度正しい」と思われる仕様しかないのが現実です。極論を言えばやってみなければわからない。または実行しながら改善するのが今の時代の経営スタイル。とにかく早期に実現していくことこそソフトウェアに求められることだと思います。このような時代に前世代的なウォーターフォールで開発すること自体、大きな経営リスクであるということをもっと理解して欲しいと思います。そして生産性はスループットで考えるべきである、ということも理解して欲しいです。
こうした様々なことを考えさせられる、非常に中身の濃いものでした。
アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング
- 作者: James Shore
- 出版社/メーカー: オライリージャパン
- 発売日: 2009/02/18
- メディア: 大型本
ITPro：プロマネになりたくないって本当？ にコメント [プロジェクト管理]
プロマネになりたくないって本当？
なんとなくわかる気がするので記事に対してコメント・・・。
「花形」？誰がそんなことを言ったのでしょうか？？ITベンダーなど会社側にとってはPMが重要だということは間違いないでしょう 。だからこそ会社側の指示・思惑でPMの資格に人気はあるのです。IT技術者当人たちの人気ではないと思います。
このあと記事にいろいろ書いてありますが、いっきに本論に入っちゃいます。
そもそも多くのIT技術者はプログラミングをしたい、プログラム／システムを作りたいという想いで就職していると思います。つまり技術者志向です。
しかし、PMというのは実際は技術者のキャリアではない。どちらかといえばマネジメント系に近い職種であると思います。そこに大きなギャップがあると思います。だいたいPMは当該技術を知らなくてもできる。PMはそれだけで専門職であるという意見もあるくらいですから。PMをやりたいという人はやりたくないという人と志向が違うのではないでしょうか。
ただ現実問題として多くのプロジェクトでは技術リーダであるアーキテクトとマネジメントリーダであるPMを分担してやるだけのコスト的余裕はありません。また前世代的考えから来るものとしてキャリアアップ＝マネージャになること、という路線があるようにも思います。このような様々な要素があいまってIT技術者のキャリアの先にはPMがある、という状況になっているのではないかと思います。
私もPMもやる人間です。会社の意向もあってPMPの認定も受けました（失効しましたが）。でもなりたくてなったわけではない。アーキテクトとしてのキャリアがあればそちらにいきたかった。今でもアーキテクトが第一義、PMはその次というような立場でやっている面があります。
こうしたことを考えていくと「プロマネになりたくない」という若手の意見は理解できる。
ただ今は避けて通れない道だということも理解してきました。「面白い仕事」とは思ったことはありませんが、必要不可欠な能力ではあると思っています。
若手の皆様。PM専業というのはやりたくはないという意見もあるとは思いますが、PM兼業というのが実態だと思うので頑張ってください。
なんとなくわかる気がするので記事に対してコメント・・・。
プロマネは，システム開発プロジェクトにかかわる人・モノ・金を動かし，プロジェクトを成功に導く重要な仕事だ。さまざまなIT職種の中で，「花形」といえる職種…のはずである。
中略
プロマネという職種が，ITベンダーやユーザー企業の情報システム部門にとって，重要であることは間違いない。そのことは，プロマネに関連する資格の人気ぶりからうかがえる。
「花形」？誰がそんなことを言ったのでしょうか？？ITベンダーなど会社側にとってはPMが重要だということは間違いないでしょう 。だからこそ会社側の指示・思惑でPMの資格に人気はあるのです。IT技術者当人たちの人気ではないと思います。
このあと記事にいろいろ書いてありますが、いっきに本論に入っちゃいます。
そもそも多くのIT技術者はプログラミングをしたい、プログラム／システムを作りたいという想いで就職していると思います。つまり技術者志向です。
しかし、PMというのは実際は技術者のキャリアではない。どちらかといえばマネジメント系に近い職種であると思います。そこに大きなギャップがあると思います。だいたいPMは当該技術を知らなくてもできる。PMはそれだけで専門職であるという意見もあるくらいですから。PMをやりたいという人はやりたくないという人と志向が違うのではないでしょうか。
ただ現実問題として多くのプロジェクトでは技術リーダであるアーキテクトとマネジメントリーダであるPMを分担してやるだけのコスト的余裕はありません。また前世代的考えから来るものとしてキャリアアップ＝マネージャになること、という路線があるようにも思います。このような様々な要素があいまってIT技術者のキャリアの先にはPMがある、という状況になっているのではないかと思います。
私もPMもやる人間です。会社の意向もあってPMPの認定も受けました（失効しましたが）。でもなりたくてなったわけではない。アーキテクトとしてのキャリアがあればそちらにいきたかった。今でもアーキテクトが第一義、PMはその次というような立場でやっている面があります。
こうしたことを考えていくと「プロマネになりたくない」という若手の意見は理解できる。
ただ今は避けて通れない道だということも理解してきました。「面白い仕事」とは思ったことはありませんが、必要不可欠な能力ではあると思っています。
若手の皆様。PM専業というのはやりたくはないという意見もあるとは思いますが、PM兼業というのが実態だと思うので頑張ってください。
プロジェクトマネジメント知識体系ガイド第3版 A Guide To The Project Management Body Of Knowledge
- 作者: Project Management Institute
- 出版社/メーカー: Project Management Inst
- 発売日: 2005/02/14
- メディア: ペーパーバック
アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)
- 作者: Scott Berkun
- 出版社/メーカー: オライリー・ジャパン
- 発売日: 2006/09/07
- メディア: 単行本（ソフトカバー）
Webプロジェクトマネジメント標準 PMBOK(R)でワンランク上のWebディレクションを目指す
- 作者: 林 千晶
- 出版社/メーカー: 技術評論社
- 発売日: 2008/08/28
- メディア: 大型本
「アジャイルな見積りと計画づくり 」 [プロジェクト管理]
この本を1/3くらい読んだところだったと思いますが、まさに「アハッ」体験をしたような気がします。
「なるほど、このやり方はいいな～」・「これならうまく出来る」そう思いました。
ソフトウェア開発においてこの本は貴重な知見をもたらすものと思います。
ただやっぱり課題なのは会計コンバージェンス・アドプションで変更される「工事進行基準」。
アジャイルな見積もり、計画と「工事進行基準」とをどうやって両立させるのか・・・。どこかの国でこれを両立させている事例はないのでしょうか？？？ぜひともそういったことも公開して欲しいですね。
参考資料：
魅力的品質と当り前品質
「なるほど、このやり方はいいな～」・「これならうまく出来る」そう思いました。
ソフトウェア開発においてこの本は貴重な知見をもたらすものと思います。
ただやっぱり課題なのは会計コンバージェンス・アドプションで変更される「工事進行基準」。
アジャイルな見積もり、計画と「工事進行基準」とをどうやって両立させるのか・・・。どこかの国でこれを両立させている事例はないのでしょうか？？？ぜひともそういったことも公開して欲しいですね。
参考資料：
魅力的品質と当り前品質
アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
- 作者: Mike Cohn
- 出版社/メーカー: 毎日コミュニケーションズ
- 発売日: 2009/01/29
- メディア: 単行本（ソフトカバー）
devsumi2009 : 「Eclipse-Way 分散アジャイル開発」 [プロジェクト管理]
Developers Summit 2009、「Eclipse-Way：分散アジャイル開発のためのプラクティスとその事例」
どうまとめようかと思っていたところ、CodeZineでほぼその内容すべてが公開されました。
詳細はそちらをご覧ください。
このセッションではIBMのJazz Projectの事例を紹介しています。Jazz ProjectではEclipseの経験を活用したそうです。それがEclipse-Way。オープンソースのような分散開発を前提としているところがいろいろ参考になります。
私の頭のなかに一番残っているのはTeam-First。分散したチームを如何にしてまとめていくかというのは難しい課題です。それをうまくまとめるのがTeam-Firstという考え方。地域・組織ごとにTeamを編成し、そこで一定のまとまった機能を実装していくというやり方です。
このやり方の特徴はチーム毎に多少方法論が異なっても構わないということ。それぞれのTeamがあらかじめ決められた枠内で自由に開発してよいという点があります。
この方法を使うとオフショア開発もかなりシンプルになるのではないかと感じました。
Jazz Projectの状況は今でもネット上で確認できるそうなので、分散開発を検討されている方はぜひ参考にしてみてはいかがでしょうか。
また、CodeZineではJazz Projectそのものの連載も行われています。こちらも参考になるでしょう。
どうまとめようかと思っていたところ、CodeZineでほぼその内容すべてが公開されました。
詳細はそちらをご覧ください。
このセッションではIBMのJazz Projectの事例を紹介しています。Jazz ProjectではEclipseの経験を活用したそうです。それがEclipse-Way。オープンソースのような分散開発を前提としているところがいろいろ参考になります。
私の頭のなかに一番残っているのはTeam-First。分散したチームを如何にしてまとめていくかというのは難しい課題です。それをうまくまとめるのがTeam-Firstという考え方。地域・組織ごとにTeamを編成し、そこで一定のまとまった機能を実装していくというやり方です。
このやり方の特徴はチーム毎に多少方法論が異なっても構わないということ。それぞれのTeamがあらかじめ決められた枠内で自由に開発してよいという点があります。
この方法を使うとオフショア開発もかなりシンプルになるのではないかと感じました。
Jazz Projectの状況は今でもネット上で確認できるそうなので、分散開発を検討されている方はぜひ参考にしてみてはいかがでしょうか。
また、CodeZineではJazz Projectそのものの連載も行われています。こちらも参考になるでしょう。
５Whyも使いよう・・・ [プロジェクト管理]
課題解決にトヨタ式と言われる「５Why」を活用されているところもあると思いますが、使い方を間違えると人間関係の悪化にしかならないということもあります。
使い方の基本は問題追求型ではなく、解決志向型。これを間違えなければ大丈夫。
型にはまったやり方もよいとは思いますが、状況を改善するためには型から外れるのも重要だと思います。このあたりを注意して活用しましょう。
使い方の基本は問題追求型ではなく、解決志向型。これを間違えなければ大丈夫。
型にはまったやり方もよいとは思いますが、状況を改善するためには型から外れるのも重要だと思います。このあたりを注意して活用しましょう。
「クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?」 [プロジェクト管理]
「クリティカルチェーン」。この本はTOC（制約条件理論）をプロジェクトマネジメントに適用したストーリーになっています。
この本の途中まで読むまではTOCの概要だけわかっていれば十分に理解できると思っていました。しかしやはりこの内容を自分のものにするためにはシリーズをちゃんと最初から読んでおく必要がありますね。付け焼刃のTOCの知識では言っていることは理解できても自分では実践できないと思います。
しかし付け焼刃のTOCの知識しかない私でもある程度ついていけましたし、TOCをプロジェクトに適用するのはかなり有用そうだということはわかりました。少なくともPMBOKでも出てくるPERT図などだけではとてもプロジェクトマネジメントなんてできないことははっきりと理解しました。次期PMBOKではぜひTOCを取り込んでもらいたいですね。
ここまで来たらもう一度TOCを基礎から押さえた上で今まで読んできたプロジェクトマネジメント関連書「アジャイルソフトウェアマネジメント」「リーン開発の本質」「Manage It!」を読み直したほうがよさそうです。
この本の途中まで読むまではTOCの概要だけわかっていれば十分に理解できると思っていました。しかしやはりこの内容を自分のものにするためにはシリーズをちゃんと最初から読んでおく必要がありますね。付け焼刃のTOCの知識では言っていることは理解できても自分では実践できないと思います。
しかし付け焼刃のTOCの知識しかない私でもある程度ついていけましたし、TOCをプロジェクトに適用するのはかなり有用そうだということはわかりました。少なくともPMBOKでも出てくるPERT図などだけではとてもプロジェクトマネジメントなんてできないことははっきりと理解しました。次期PMBOKではぜひTOCを取り込んでもらいたいですね。
ここまで来たらもう一度TOCを基礎から押さえた上で今まで読んできたプロジェクトマネジメント関連書「アジャイルソフトウェアマネジメント」「リーン開発の本質」「Manage It!」を読み直したほうがよさそうです。
クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?
- 作者: エリヤフ ゴールドラット
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2003/10/31
- メディア: 単行本（ソフトカバー）
- 作者: David J. Anderson
- 出版社/メーカー: 日刊工業新聞社
- 発売日: 2006/03
- メディア: 単行本
- 作者: メアリー・ポッペンディーク
- 出版社/メーカー: 日経BP社
- 発売日: 2008/02/07
- メディア: 単行本（ソフトカバー）
Manage It! 現場開発者のための達人式プロジェクトマネジメント
- 作者: Johanna Rothman
- 出版社/メーカー: オーム社
- 発売日: 2008/10/18
- メディア: 単行本（ソフトカバー）
「PSPガイドブック ソフトウェアエンジニア自己改善」 [プロジェクト管理]
PSP（Personal Software Process)はSEIが開発したソフトウェア開発の自己改善プロセスです。
ここに書いてあることはできらたらいい、いや出来たほうがいい。それが品質向上につながる、計画精度が向上する、そう思います。
でもね～、これを実行するためには大変な努力が必要です。
なんといっても自分のプログラミングミスを徹底的に記録していかなければならない。また、それぞれの作業をどれくらいの時間行っていたかをこまめに測定していかなければならない。この記録・測定ができなければPSPもちゃんとできないのです。
まずは記録・測定を自動化するためのツールが必須だな～と思います。そのツールが開発プロセス内に導入できれば・・・PSPも有用になるのかもしれない。PSPの延長にはチームで実践するTSP(Team Software Process)があり、チームとしての生産性向上が見えてくる。
なんとか一番最初のハードルを超えないといけないのですけどね・・・・。
それにしてもCMMIといい、PSPといい、SEIが取り組むプロセスってどうしてこうもヘビーなんだろう・・・。
もっとライトなプロセスを考えてくれればいいのに・・・・。
関連サイト：http://www.sei.cmu.edu/tsp/
ここに書いてあることはできらたらいい、いや出来たほうがいい。それが品質向上につながる、計画精度が向上する、そう思います。
でもね～、これを実行するためには大変な努力が必要です。
なんといっても自分のプログラミングミスを徹底的に記録していかなければならない。また、それぞれの作業をどれくらいの時間行っていたかをこまめに測定していかなければならない。この記録・測定ができなければPSPもちゃんとできないのです。
まずは記録・測定を自動化するためのツールが必須だな～と思います。そのツールが開発プロセス内に導入できれば・・・PSPも有用になるのかもしれない。PSPの延長にはチームで実践するTSP(Team Software Process)があり、チームとしての生産性向上が見えてくる。
なんとか一番最初のハードルを超えないといけないのですけどね・・・・。
それにしてもCMMIといい、PSPといい、SEIが取り組むプロセスってどうしてこうもヘビーなんだろう・・・。
もっとライトなプロセスを考えてくれればいいのに・・・・。
関連サイト：http://www.sei.cmu.edu/tsp/
PSPガイドブック ソフトウェアエンジニア自己改善 (IT Architects’ Archive)
- 作者: ワッツ・S・ハンフリー
- 出版社/メーカー: 翔泳社
- 発売日: 2007/08/07
- メディア: 単行本（ソフトカバー）
TSPiガイドブック (IT Architects’Archive ソフトウェア開発の課題 10)
- 作者: ワッツ・S・ハンフリー
- 出版社/メーカー: 翔泳社
- 発売日: 2008/06/19
- メディア: 単行本
ソフトウェア開発は「超上流」からが重要 [プロジェクト管理]
ソフトウェア開発は「超上流」、そして共通の用語が重要になります。
用語は『共通フレーム2007』がベンダー・ユーザー共通のものとして定義されておりこれを活用するのがよいとされています。
このあたりまでは2007年から2008年前半にこのブログでも掲載してきたと思います。
間違いなく超上流は重要です。しかし、そのあとのプロジェクト管理・構成管理が最近難関だと感じています。
「共通フレーム2007」のイメージも上記記事のイメージもおおよそウォーターフォール開発モデルを想定しているのではないでしょうか。これが難関だと感じている点です。
超上流で方向性は決められるでしょう。しかし個別の要件・仕様については最初に”決定”することは難しいだろうというのが今のソフトウェア業界で考えられていることです。ですからアジャイル開発などが注目されているわけです。
ここに若干ギャップがある。これをどう埋めていくのか。それがソフトウェア企業のこれからの課題なのかもしれません。
工事進行基準という会計上の課題もあり、プロジェクト管理はかなり高度なものになっていくのかもしれません。
（企業ごとに適当なプロセスが規定されていくのかもしれませんが・・・）
超上流、共通フレーム、アジャイル、工事進行基準、、このあたりを個別に考えるのは適切ではないな、と思っています。
用語は『共通フレーム2007』がベンダー・ユーザー共通のものとして定義されておりこれを活用するのがよいとされています。
このあたりまでは2007年から2008年前半にこのブログでも掲載してきたと思います。
間違いなく超上流は重要です。しかし、そのあとのプロジェクト管理・構成管理が最近難関だと感じています。
「共通フレーム2007」のイメージも上記記事のイメージもおおよそウォーターフォール開発モデルを想定しているのではないでしょうか。これが難関だと感じている点です。
超上流で方向性は決められるでしょう。しかし個別の要件・仕様については最初に”決定”することは難しいだろうというのが今のソフトウェア業界で考えられていることです。ですからアジャイル開発などが注目されているわけです。
ここに若干ギャップがある。これをどう埋めていくのか。それがソフトウェア企業のこれからの課題なのかもしれません。
工事進行基準という会計上の課題もあり、プロジェクト管理はかなり高度なものになっていくのかもしれません。
（企業ごとに適当なプロセスが規定されていくのかもしれませんが・・・）
超上流、共通フレーム、アジャイル、工事進行基準、、このあたりを個別に考えるのは適切ではないな、と思っています。
共通フレーム2007―経営者、業務部門が参画するシステム開発および取引のために (SEC BOOKS)
- 作者:
- 出版社/メーカー: オーム社
- 発売日: 2007/10
- メディア: 単行本
Manage It! 現場開発者のための達人式プロジェクトマネジメント
- 作者: Johanna Rothman
- 出版社/メーカー: オーム社
- 発売日: 2008/10/18
- メディア: 単行本（ソフトカバー）
IT業界のための『工事進行基準』完全ガイド 基礎と事例と18の特効薬
- 作者: 日経コンピュータ・日経ソリューションビジネス 合同取材班
- 出版社/メーカー: 日経BP社
- 発売日: 2008/10/16
- メディア: 単行本（ソフトカバー）
たーとる さん
-
nice! 475
記事 4429
テーマ パソコン・インターネット
プロフィール
ブログを紹介する
携帯版URL
