分散構成管理ツール [プロジェクト管理]
少し前に分散構成管理ツールGitの記事を見て少し気になっています。
そんなときにちょうど@ITで記事が出ていました。
分散構成管理ツールの適用として、ソフトウェアのオフショア・ニアショア開発があるのではないかと思います。
例えば中国にオフショア開発を依頼した場合、できればソースコードは日本側で集中管理したい。しかし、日本のソースコードリポジトリを共有すると輸出管理上問題が出そう。こんなときに分散構成管理ツールが使えるのではないか？と考えました。
複数の企業共同で開発する際も同じように分散で管理するほうが楽な場合もあると思います。
もう少し詳しくなっておきたいな～。
そんなときにちょうど@ITで記事が出ていました。
分散構成管理ツールの適用として、ソフトウェアのオフショア・ニアショア開発があるのではないかと思います。
例えば中国にオフショア開発を依頼した場合、できればソースコードは日本側で集中管理したい。しかし、日本のソースコードリポジトリを共有すると輸出管理上問題が出そう。こんなときに分散構成管理ツールが使えるのではないか？と考えました。
複数の企業共同で開発する際も同じように分散で管理するほうが楽な場合もあると思います。
もう少し詳しくなっておきたいな～。
Pragmatic Version Control Using Git
- 作者: Travis Swicegood
- 出版社/メーカー: Pragmatic Bookshelf
- 発売日: 2008/12
- メディア: ペーパーバック
- 作者: Mario Danic
- 出版社/メーカー: Apress
- 発売日: 2009/03/23
- メディア: ペーパーバック
- 作者: Nico Schottelius
- 出版社/メーカー: Open Source Press
- 発売日: 2009/02
- メディア: Perfect
アジャイル、見積もり、計画・・・ [プロジェクト管理]
ソフトウェア開発の見積もり、計画というのは非常に難しいものです。
プロジェクト開始時にすべての要件が固まっているというのは、現在では非常に少ないのではないでしょうか。
そうしたソフトウェア開発の見積もり、計画をアジャイルにやってみようという本が登場しました。
イントロダクションより
アジャイルな見積もりと計画づくりとはどんなものなのか、ぜひ読んでみたいですね。そして「Manage It!」の内容と比べてみたいと思います。
プロジェクト開始時にすべての要件が固まっているというのは、現在では非常に少ないのではないでしょうか。
そうしたソフトウェア開発の見積もり、計画をアジャイルにやってみようという本が登場しました。
イントロダクションより
本書のタイトルを「アジャイルプロジェクトの見積りと計画づくり」とすることもできた。だが実際には「アジャイルな見積りと計画づくり」というタイトルになっている。2つの違いは些細に見えるかもしれないが、そうではない。採用した現在のタイトルは、見積りや計画づくりといったプロセスを、アジャイルに進めなければならないと謳っているのだ。見積りと計画づくりがアジャイルでないのに、プロジェクトがアジャイルであるということはありえない。 本書は主に計画づくりを扱っている。計画づくりとは「なにをいつまでに作ればいいのか?」という質問に答える作業だと私は考えている。しかし、この質問に答えるためには、まず見積りに関する質問(これの大きさは?)と、スケジュールに関する質問(「いつできるのか?」「このときまでになにができるのか?」) に答えねばならない。
アジャイルな見積もりと計画づくりとはどんなものなのか、ぜひ読んでみたいですね。そして「Manage It!」の内容と比べてみたいと思います。
アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
- 作者: Mike Cohn
- 出版社/メーカー: 毎日コミュニケーションズ
- 発売日: 2009/01/29
- メディア: 単行本（ソフトカバー）
Manage It! 現場開発者のための達人式プロジェクトマネジメント
- 作者: Johanna Rothman
- 出版社/メーカー: オーム社
- 発売日: 2008/10/18
- メディア: 単行本（ソフトカバー）
「新・ソフトウェア開発の神話 成功するプロジェクトチームの科学と文化」 [プロジェクト管理]
本書はプロジェクトのリーダー、マネージャー、そしてオーナーにぜひ読んでもらいたい。
まず一般的なプロジェクトマネジメントとソフトウェアの違いを説明しているがこれが非常にわかりやすい。
さらにリーダーとマネージャーの違いも説明されている。これもとてもわかりやすい。
なぜソフトウェアプロジェクトマネジメントではウォーターフォールではなく、反復型開発・アジャイル型開発のほうがよいと考えるのか。
見積もりの意味も述べられている。ここで規模の見積もりの意味があまりないことも紹介されている。
またチームのコミュニケーションのやり方にもポイントがある。これはソフトウェア開発チームには起こりがちな問題を捉えている。
これからのソフトウェア開発ではここで述べられている内容を理解していないと成功からどんどん遠ざかることは間違いない。
まず一般的なプロジェクトマネジメントとソフトウェアの違いを説明しているがこれが非常にわかりやすい。
さらにリーダーとマネージャーの違いも説明されている。これもとてもわかりやすい。
なぜソフトウェアプロジェクトマネジメントではウォーターフォールではなく、反復型開発・アジャイル型開発のほうがよいと考えるのか。
見積もりの意味も述べられている。ここで規模の見積もりの意味があまりないことも紹介されている。
またチームのコミュニケーションのやり方にもポイントがある。これはソフトウェア開発チームには起こりがちな問題を捉えている。
これからのソフトウェア開発ではここで述べられている内容を理解していないと成功からどんどん遠ざかることは間違いない。
新・ソフトウェア開発の神話 成功するプロジェクトチームの科学と文化 (IT Architects’Archive ソフトウェア開発の課題 11)
- 作者: ジョー・マラスコ
- 出版社/メーカー: 翔泳社
- 発売日: 2008/09/18
- メディア: 単行本（ソフトカバー）
ITの工事進行基準を再考する [プロジェクト管理]
先日のManage It!を読み、再度工事進行基準の適用について再考してみました。
もともと会計制度が求める工事進行基準の適用は方法論的には可能だと考えていました。
しかし、そのためにはユーザー企業に早い段階で要件を確定していただき、作業量を正確に見積もる必要があります。
方法論としては可能なんです。しかし、これをユーザー企業に求めるということはその企業のアジリティを損ねる可能性があるのではないかと感じます。市場に対してIT企業の透明化を図ろうとすると、そのしわ寄せがユーザー企業にいきユーザー企業の株主にとっては好ましくない状況になる。何かおかしい気がします。
Manage It!でも語られていましたが、そもそもITプロジェクトは建設業のようにウォーターフォールできっちりと設計できるものではありません。ウォーターフォールでやっても不確定性リスクは減少しないのです。もし不確定性リスクを減らそうとするならばユーザー企業のアジリティを犠牲にする必要があります（それでも不確定性リスクは残ります）。そもそもウォーターフォールでシステムを開発できる時代は終了しているのです。
であれば、工事進行基準を今適用することになんのメリットがあるのか？IT企業のプロジェクトマネジメントが（一見）うまくいっていますよというアピールのために工事進行基準が存在するのであればかなり意味は薄弱になります。
「ユーザー企業の利益を守るためには工事進行基準の適用は好ましくない」そういいきって適用をしない大手IT企業がいくつも登場すればみんな適用しなくなると思うんですけどね～。
ITの不確定性リスクをちゃんと説明すれば工事進行基準適用がいかに意味のないことなのか、市場や監査法人も理解してくれるのではないかと思うのですけど・・・。
工事進行基準適用まであと3ヶ月。大胆な方針転換をする企業は現われないものでしょうか・・・。
もともと会計制度が求める工事進行基準の適用は方法論的には可能だと考えていました。
しかし、そのためにはユーザー企業に早い段階で要件を確定していただき、作業量を正確に見積もる必要があります。
方法論としては可能なんです。しかし、これをユーザー企業に求めるということはその企業のアジリティを損ねる可能性があるのではないかと感じます。市場に対してIT企業の透明化を図ろうとすると、そのしわ寄せがユーザー企業にいきユーザー企業の株主にとっては好ましくない状況になる。何かおかしい気がします。
Manage It!でも語られていましたが、そもそもITプロジェクトは建設業のようにウォーターフォールできっちりと設計できるものではありません。ウォーターフォールでやっても不確定性リスクは減少しないのです。もし不確定性リスクを減らそうとするならばユーザー企業のアジリティを犠牲にする必要があります（それでも不確定性リスクは残ります）。そもそもウォーターフォールでシステムを開発できる時代は終了しているのです。
であれば、工事進行基準を今適用することになんのメリットがあるのか？IT企業のプロジェクトマネジメントが（一見）うまくいっていますよというアピールのために工事進行基準が存在するのであればかなり意味は薄弱になります。
「ユーザー企業の利益を守るためには工事進行基準の適用は好ましくない」そういいきって適用をしない大手IT企業がいくつも登場すればみんな適用しなくなると思うんですけどね～。
ITの不確定性リスクをちゃんと説明すれば工事進行基準適用がいかに意味のないことなのか、市場や監査法人も理解してくれるのではないかと思うのですけど・・・。
工事進行基準適用まであと3ヶ月。大胆な方針転換をする企業は現われないものでしょうか・・・。
「Manage It! 現場開発者のための達人式プロジェクトマネジメント」
この本はすごい！！
この本を読めばどうすればITシステムのプロジェクトマネジメントが成功したといわれるようになるかわかります。しかも理論的なものではなくとても実践的。PMもしくはサブリーダークラス、そしてそのマネージャ・スポンサーの方々にはぜひ読んでいただきたい。
ただこの本をそのまま適用すると工事進行基準は適用できませんね。というよりITシステム開発のような不確定要素の多いものを工事進行基準を適用するということ自体無謀だという感があります。
工事進行基準の運用はできるけれども、そもそも工事進行基準の基準となるスケジュールが確定できないのですから・・・。
私個人としては工事進行基準の運用はできるとは考えていましたが、一番基礎となる見積り・計画が最大の懸念事項だなとは思っていました。その最大の懸念事項を解決するためにはどうすればよいかがこの本には書いてあります。といってもここで見積り・計画を確定させる方法が書かれているのではありません。あくまで不確定要素がある、という大前提を受け入れその上でどうマネジメントすればいいかが書いてあります。結局工事進行基準適用そのものに無理があるということになってしまいました。
やっぱりこういった方法が現実的なんだよな～。でも政治的な問題で現実的な対応ができないのも事実で・・・。それをどう解決していくことが一番難しいかも。
「Ship It!」も良い本でしたが、この本も最高評価の本です！！
IT業界のための『工事進行基準』完全ガイド 基礎と事例と18の特効薬
- 作者: 日経コンピュータ・日経ソリューションビジネス 合同取材班
- 出版社/メーカー: 日経BP社
- 発売日: 2008/10/16
- メディア: 単行本（ソフトカバー）
- 作者: 岩谷 誠治
- 出版社/メーカー: 中央経済社
- 発売日: 2008/06
- メディア: 単行本
Manage It! 現場開発者のための達人式プロジェクトマネジメント
- 作者: Johanna Rothman
- 出版社/メーカー: オーム社
- 発売日: 2008/10/18
- メディア: 単行本（ソフトカバー）
「アジャイルレトロスペクティブズ」 [プロジェクト管理]
アジャイルという名称がついていますが、アジャイル開発でなければ使えないというものではありません。
本書は「ふりかえり」を通じて、ソフトウェア開発プロジェクト中に発生した課題や良い点などを見直していく手法です。
言ってみればプロジェクト管理のPDCAのCを支える手法ではないかと思います。
どんなことをやるのか、それはプロジェクト管理ならばだいたい何でも対象です。どうやるのか、それが本書の内容です。
必要な能力としてはファシリテーション能力です。テクニックとしてもファシリテーションのものが使えます。しかし通常のファシリテーションではあまり出てこない、「ふりかえり」独特のテクニックもあります。
この本で「ふりかえり」を実施していくことでPDCAサイクルがまわるようになり、そのチームが次第に成長していくようになると思います。
やりっぱなしのプロジェクトが多いと思いますので、こうした「ふりかえり」を活用してしっかりと改善すべきところは改善していくのがよいのではないでしょうか。
本書は「ふりかえり」を通じて、ソフトウェア開発プロジェクト中に発生した課題や良い点などを見直していく手法です。
言ってみればプロジェクト管理のPDCAのCを支える手法ではないかと思います。
どんなことをやるのか、それはプロジェクト管理ならばだいたい何でも対象です。どうやるのか、それが本書の内容です。
必要な能力としてはファシリテーション能力です。テクニックとしてもファシリテーションのものが使えます。しかし通常のファシリテーションではあまり出てこない、「ふりかえり」独特のテクニックもあります。
この本で「ふりかえり」を実施していくことでPDCAサイクルがまわるようになり、そのチームが次第に成長していくようになると思います。
やりっぱなしのプロジェクトが多いと思いますので、こうした「ふりかえり」を活用してしっかりと改善すべきところは改善していくのがよいのではないでしょうか。
アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き
- 作者: Esther Derby
- 出版社/メーカー: オーム社
- 発売日: 2007/09
- メディア: 単行本
ファシリテーション・グラフィック―議論を「見える化」する技法 (ファシリテーション・スキルズ)
- 作者: 堀 公俊
- 出版社/メーカー: 日本経済新聞社
- 発売日: 2006/09
- メディア: 単行本
ファシリテーターの道具箱―組織の問題解決に使えるパワーツール49
- 作者: 森 時彦/ファシリテーターの道具研究会
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2008/03/14
- メディア: 単行本
時代はリーンソフトウェアへ [プロジェクト管理]
時代はオープンソースからリーンソフトウェアへ(ITmedia)。
オープンソースでの変貌とリーンソフトウェア開発への変貌を同列に扱うのはおかしいのでは？？とは思いますが、時代はリーンソフトウェアへ、という部分は同意です。
これからの主流としているが、実際には今の主流といってもよいのではないでしょうか。
今の時代にウォーターフォールで開発するというのは、ソフトウェア開発の中でも最大のリスクを背負うのと同一ではないかと私は感じています。「Manage It!」でもアジャイル、リーン、イテレーティブといった手法を選択するのがよいとし、ウォーターフォールは避けるべき手法だとしています。
サービス化はリーン開発をより促進するものとも思いますし、積極的に取り入れていくべきでしょう。
オープンソースでの変貌とリーンソフトウェア開発への変貌を同列に扱うのはおかしいのでは？？とは思いますが、時代はリーンソフトウェアへ、という部分は同意です。
これからの主流としているが、実際には今の主流といってもよいのではないでしょうか。
今の時代にウォーターフォールで開発するというのは、ソフトウェア開発の中でも最大のリスクを背負うのと同一ではないかと私は感じています。「Manage It!」でもアジャイル、リーン、イテレーティブといった手法を選択するのがよいとし、ウォーターフォールは避けるべき手法だとしています。
サービス化はリーン開発をより促進するものとも思いますし、積極的に取り入れていくべきでしょう。
- 作者: メアリー・ポッペンディーク
- 出版社/メーカー: 日経BP社
- 発売日: 2008/02/07
- メディア: 単行本（ソフトカバー）
Manage It! 現場開発者のための達人式プロジェクトマネジメント
- 作者: Johanna Rothman
- 出版社/メーカー: オーム社
- 発売日: 2008/10/18
- メディア: 単行本（ソフトカバー）
「Manage It! 現場開発者のための達人式プロジェクトマネジメント」 [プロジェクト管理]
この本はすごい！！
この本を読めばどうすればITシステムのプロジェクトマネジメントが成功したといわれるようになるかわかります。しかも理論的なものではなくとても実践的。PMもしくはサブリーダークラス、そしてそのマネージャ・スポンサーの方々にはぜひ読んでいただきたい。
ただこの本をそのまま適用すると工事進行基準は適用できませんね。というよりITシステム開発のような不確定要素の多いものを工事進行基準を適用するということ自体無謀だという感があります。
工事進行基準の運用はできるけれども、そもそも工事進行基準の基準となるスケジュールが確定できないのですから・・・。
私個人としては工事進行基準の運用はできるとは考えていましたが、一番基礎となる見積り・計画が最大の懸念事項だなとは思っていました。その最大の懸念事項を解決するためにはどうすればよいかがこの本には書いてあります。といってもここで見積り・計画を確定させる方法が書かれているのではありません。あくまで不確定要素がある、という大前提を受け入れその上でどうマネジメントすればいいかが書いてあります。結局工事進行基準適用そのものに無理があるということになってしまいました。
やっぱりこういった方法が現実的なんだよな～。でも政治的な問題で現実的な対応ができないのも事実で・・・。それをどう解決していくことが一番難しいかも。
「Ship It!」も良い本でしたが、この本も最高評価の本です！！
この本を読めばどうすればITシステムのプロジェクトマネジメントが成功したといわれるようになるかわかります。しかも理論的なものではなくとても実践的。PMもしくはサブリーダークラス、そしてそのマネージャ・スポンサーの方々にはぜひ読んでいただきたい。
ただこの本をそのまま適用すると工事進行基準は適用できませんね。というよりITシステム開発のような不確定要素の多いものを工事進行基準を適用するということ自体無謀だという感があります。
工事進行基準の運用はできるけれども、そもそも工事進行基準の基準となるスケジュールが確定できないのですから・・・。
私個人としては工事進行基準の運用はできるとは考えていましたが、一番基礎となる見積り・計画が最大の懸念事項だなとは思っていました。その最大の懸念事項を解決するためにはどうすればよいかがこの本には書いてあります。といってもここで見積り・計画を確定させる方法が書かれているのではありません。あくまで不確定要素がある、という大前提を受け入れその上でどうマネジメントすればいいかが書いてあります。結局工事進行基準適用そのものに無理があるということになってしまいました。
やっぱりこういった方法が現実的なんだよな～。でも政治的な問題で現実的な対応ができないのも事実で・・・。それをどう解決していくことが一番難しいかも。
「Ship It!」も良い本でしたが、この本も最高評価の本です！！
Manage It! 現場開発者のための達人式プロジェクトマネジメント
- 作者: Johanna Rothman
- 出版社/メーカー: オーム社
- 発売日: 2008/10/18
- メディア: 単行本（ソフトカバー）
Ship It! ソフトウェアプロジェクト 成功のための達人式ガイドブック
- 作者: Jared Richardson
- 出版社/メーカー: オーム社
- 発売日: 2006/08/26
- メディア: 単行本（ソフトカバー）
ITPro書評：「Webプロジェクトマネジメント標準」 [プロジェクト管理]
Webアプリケーション開発ならばプロジェクトと考えることはできますが、Web制作側をプロジェクトと考えたことはなかったですね。開発ばかり見ていた私にとってはちょっと新しい視点かも。
「Webプロジェクトマネジメント標準」
「Webプロジェクトマネジメント標準」
Webプロジェクトマネジメント標準 PMBOK(R)でワンランク上のWebディレクションを目指す
- 作者: 林 千晶
- 出版社/メーカー: 技術評論社
- 発売日: 2008/08/28
- メディア: 大型本
プロジェクトマネジメント知識体系ガイド第3版 A Guide To The Project Management Body Of Knowledge
- 作者: Project Management Institute
- 出版社/メーカー: Project Management Inst
- 発売日: 2005/02/14
- メディア: ペーパーバック
工事進行基準、リスク分上積みは注意が必要 [プロジェクト管理]
「SIでの工事進行基準、“ノリシロ”の扱いに見える根深い問題」
SIの契約の際、リスク分を上積みするのはほぼどこでも行われている当然なことだと思います。ところがリスク管理のための分が後々の会計処理上のリスクになってしまう。つまり、その上積みが最悪の場合利益の先送りと税務署に判断されてしまうこともあるとは・・・。
せっかくうまくいったプロジェクトなのに今度は会計基準がそのプロジェクトを大問題に陥れるなんて。
こうしたことが工事進行基準適用には隠れているんですね・・・。
今後はリスクも工程別に分けておいて、工事進行に合わせてうまくいった場合には利益計上しておかないといけないのかな～。
「ノリシロ」が「ノリシロ」にならないじゃないか～！！この部分はなんとか認めてもらえないかな～ ＞ 国税庁様
SIの契約の際、リスク分を上積みするのはほぼどこでも行われている当然なことだと思います。ところがリスク管理のための分が後々の会計処理上のリスクになってしまう。つまり、その上積みが最悪の場合利益の先送りと税務署に判断されてしまうこともあるとは・・・。
せっかくうまくいったプロジェクトなのに今度は会計基準がそのプロジェクトを大問題に陥れるなんて。
こうしたことが工事進行基準適用には隠れているんですね・・・。
今後はリスクも工程別に分けておいて、工事進行に合わせてうまくいった場合には利益計上しておかないといけないのかな～。
「ノリシロ」が「ノリシロ」にならないじゃないか～！！この部分はなんとか認めてもらえないかな～ ＞ 国税庁様
ソフトウェアタグ（STagE）って何？？？ [プロジェクト管理]
文科省のソフト開発見える化プロジェクト、「ソフトウェアタグ」規格の正式版を公表。
どうやらソフトウェアのトレーサビリティなどを確保するためのものらしい。が、ITProの記事だけじゃよくわからない・・・。
急に顧客から話をされたら大変。ちゃんと解説資料を出してくれるといいのだけれど。
一度STagEプロジェクトを隅から隅までみないといけないか。
どうやらソフトウェアのトレーサビリティなどを確保するためのものらしい。が、ITProの記事だけじゃよくわからない・・・。
急に顧客から話をされたら大変。ちゃんと解説資料を出してくれるといいのだけれど。
一度STagEプロジェクトを隅から隅までみないといけないか。
たーとる さん
-
nice! 475
記事 4429
テーマ パソコン・インターネット
プロフィール
ブログを紹介する
携帯版URL
