「リーンソフトウェア開発と組織改革」 [プロジェクト管理]
この書籍は読み物としてとても面白い。
『そうそう、こういう問題があるんだよ』『こうすればうまくいくんだよなー』『これをやれば改善できるかも』・・・本当に共感できる部分がたくさんあります。
また読んでいると稼働率に関する内容で「ザ・ベロシティ」で登場するようなシーンが出てきます。ソフトウェア開発でも製品製造でも同じなんだなーと実感します。
読み物として面白いのは共感できるから。では実践はというと・・・難しいところがあるんだろうなー。
確かにできるものもあると思います。でも、リーン開発(とかアジャイル開発とか)ってやろうとすると社内の抵抗に遭いませんか?今までのやり方だとほぼ間違いなく失敗する、だからこそ新しいやり方で進めなければならないのに、「今までのやり方は標準だから変えてはいけない」的な圧力・抵抗が出てくる。リーン開発(やアジャイル開発)はもうそれほど新しいものではありません。なのに新しいものとして取り組まなければならない・・・。だから「読み物」としては面白い、となってしまうのです。
実践しようとするならば、組織の抵抗を乗り越えるんだという強い意志が必要だと思います。
ただ、組織の抵抗を乗り越えるためのヒントが掲載されていたのでそれを紹介しておきましょう。
トヨタのかんばん方式を確立した大野耐一氏の言葉ということなので、その筋の方には説得力があると思います。
「標準というものを最善だとおもったらもういかん。標準というのは、改善するためのひとつのベースであってね。」
この言葉が強い味方になるはずです。
『そうそう、こういう問題があるんだよ』『こうすればうまくいくんだよなー』『これをやれば改善できるかも』・・・本当に共感できる部分がたくさんあります。
また読んでいると稼働率に関する内容で「ザ・ベロシティ」で登場するようなシーンが出てきます。ソフトウェア開発でも製品製造でも同じなんだなーと実感します。
読み物として面白いのは共感できるから。では実践はというと・・・難しいところがあるんだろうなー。
確かにできるものもあると思います。でも、リーン開発(とかアジャイル開発とか)ってやろうとすると社内の抵抗に遭いませんか?今までのやり方だとほぼ間違いなく失敗する、だからこそ新しいやり方で進めなければならないのに、「今までのやり方は標準だから変えてはいけない」的な圧力・抵抗が出てくる。リーン開発(やアジャイル開発)はもうそれほど新しいものではありません。なのに新しいものとして取り組まなければならない・・・。だから「読み物」としては面白い、となってしまうのです。
実践しようとするならば、組織の抵抗を乗り越えるんだという強い意志が必要だと思います。
ただ、組織の抵抗を乗り越えるためのヒントが掲載されていたのでそれを紹介しておきましょう。
トヨタのかんばん方式を確立した大野耐一氏の言葉ということなので、その筋の方には説得力があると思います。
「標準というものを最善だとおもったらもういかん。標準というのは、改善するためのひとつのベースであってね。」
この言葉が強い味方になるはずです。
- 作者: Mary and Tom Poppendieck 著、 依田光江 翻訳、 依田智夫 監訳
- 出版社/メーカー: アスキー・メディアワークス
- 発売日: 2010/10/09
- メディア: 単行本(ソフトカバー)
「プロマネやってはいけない 計画・管理編」 [プロジェクト管理]
プロジェクトの失敗要因、特に統計情報を持っているわけではありませんが、原因は
要件定義および変更が管理できない
スケジュールの問題
見積もり
といったところではないでしょうか。本書では見積り以外が対象になっていると思います。
本書のテーマと失敗要因をマッピングすると
見積もり => 見積もり
計画 => スケジュール
進捗管理 => スケジュール
リスク管理 => スケジュール、要件定義・変更管理
課題・変更管理 => 要件定義・変更管理
クロージング => スケジュール、要件定義・変更管理
失敗事例が多数あるだけあって、書籍では事例がたくさんあります。私の経験と照らし合わしても「これが失敗要因だった」と合致するものがたくさん・・・。
では、その『突破術』として記載されている内容は・・・正論が多いんですよねー。正直、「それができれば苦労しない」「そもそも自社側の上司の指示・命令でそうせざるをえない」というものも結構ある。正論を押し通すことができれば苦労しないと言いたいところも多数ありました。
さらに言えば、これをまじめにやったらアジャイル開発は難しいだろうなーという感もあります。もちろん、何らかの方法はあるのでしょうけれど。アジャイル開発に向かないのが日本の商慣習という面もあるかもしれません。
とはいえ、やっぱりこうした失敗事例と「本来どうあるべきか」ということは知っておかなければなりませんから、本書のような内容はマネジメントを行う人にとっては結構参考になると思います。
ちなみに、本書は「計画・管理編」となっていますが、それ以外の「~編」が出るんですかね~。
要件定義および変更が管理できない
スケジュールの問題
見積もり
といったところではないでしょうか。本書では見積り以外が対象になっていると思います。
本書のテーマと失敗要因をマッピングすると
見積もり => 見積もり
計画 => スケジュール
進捗管理 => スケジュール
リスク管理 => スケジュール、要件定義・変更管理
課題・変更管理 => 要件定義・変更管理
クロージング => スケジュール、要件定義・変更管理
失敗事例が多数あるだけあって、書籍では事例がたくさんあります。私の経験と照らし合わしても「これが失敗要因だった」と合致するものがたくさん・・・。
では、その『突破術』として記載されている内容は・・・正論が多いんですよねー。正直、「それができれば苦労しない」「そもそも自社側の上司の指示・命令でそうせざるをえない」というものも結構ある。正論を押し通すことができれば苦労しないと言いたいところも多数ありました。
さらに言えば、これをまじめにやったらアジャイル開発は難しいだろうなーという感もあります。もちろん、何らかの方法はあるのでしょうけれど。アジャイル開発に向かないのが日本の商慣習という面もあるかもしれません。
とはいえ、やっぱりこうした失敗事例と「本来どうあるべきか」ということは知っておかなければなりませんから、本書のような内容はマネジメントを行う人にとっては結構参考になると思います。
ちなみに、本書は「計画・管理編」となっていますが、それ以外の「~編」が出るんですかね~。
アウトソーシングの知識体系本 [プロジェクト管理]
プロジェクトマネジメントのPMBOK、ソフトウェア品質のSQuBOK、ビジネスアナリシスのBABOK。ここまでは知っていましたが、アウトソーシングの知識体系本があるそうです。
それがOutsourcing Professional Body of Knowledge(OPBOK) - IAOP (english version)
どんな内容なんだろう??一度中身を見てみたい(できれば日本語で・・・)
それがOutsourcing Professional Body of Knowledge(OPBOK) - IAOP (english version)
どんな内容なんだろう??一度中身を見てみたい(できれば日本語で・・・)
「アジャイル開発の本質とスケールアップ」 [プロジェクト管理]
本書はアジャイルメソッドをうまく企業内で利用していくための教科書のような存在ですね。
私も数年前にアジャイルメソッドを使ってプロジェクトマネジメントをしようと試みたことがありました。しかし、その時は品質保証部門や上長の理解が得られずに断念。ウォーターフォール型管理をして結局大失敗に終わりました。
リスクを早く察知して早期に解決していくアジャイルメソッドは企業レベルでも十分に利用できるはずです。でも、ウォーターフォール型管理手法で標準化している組織では変化を怖れてしまい適用しない。でも「変化を怖れる、変化を受け入れない」というのは最大のリスクだと思うんですけどね~。
実際にプロジェクトマネジメントに携わる方だけではなく、社内標準化(等)に携わっているすべての方々に本書をお薦めします。利点(と欠点)をしっかり把握しアジャイルメソッドをもっと活用してほしいものです。
私も数年前にアジャイルメソッドを使ってプロジェクトマネジメントをしようと試みたことがありました。しかし、その時は品質保証部門や上長の理解が得られずに断念。ウォーターフォール型管理をして結局大失敗に終わりました。
リスクを早く察知して早期に解決していくアジャイルメソッドは企業レベルでも十分に利用できるはずです。でも、ウォーターフォール型管理手法で標準化している組織では変化を怖れてしまい適用しない。でも「変化を怖れる、変化を受け入れない」というのは最大のリスクだと思うんですけどね~。
実際にプロジェクトマネジメントに携わる方だけではなく、社内標準化(等)に携わっているすべての方々に本書をお薦めします。利点(と欠点)をしっかり把握しアジャイルメソッドをもっと活用してほしいものです。
アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)
- 作者: ディーン・レフィングウェル
- 出版社/メーカー: 翔泳社
- 発売日: 2010/02/18
- メディア: 大型本
共通フレーム2007 第2版が出ていました~ [プロジェクト管理]
2007年に登場した「共通フレーム2007」その第2版が10月に出ていました。
何かが追加になったとかではないと思いますが、同じものなら新しいほうがよいですものね~。
何かが追加になったとかではないと思いますが、同じものなら新しいほうがよいですものね~。
共通フレーム2007―経営者、業務部門が参画するシステム開発および取引のために (SEC BOOKS)
- 作者:
- 出版社/メーカー: オーム社
- 発売日: 2009/10
- メディア: 単行本
「共通フレーム2007」
今、読み始めたところなのですが・・・。
この手の本はソフトウェア開発会社なら社内全部署に最低1冊ずつ、一般の会社でも情報システム部門には1冊、かならず置いて欲しいですね。今回は超上流も含んでいるようなので、とても重要な一冊になっていると思います。
来年4月から受託ソフトウェア開発での工事進行基準適用によって、契約内容はより明確にしなければなりません。となると用語の差異も発生しないようにしなければなりません。この共通フレームはそうしたソフトウェア開発の各工程の用語の統一にも寄与すると思います。
一応開発手法には依存しないよう配慮されているのでウォーターフォール、UP、アジャイルなどの手法にも対応できるでしょうし、それぞれの手法で適用するよう用語をマッピングするなどの配慮が必要かもしれません。
内容を読んだら一応感想などは再度アップしたいと思います。
ソフトウェアプロジェクトマネジメントにおけるメトリクス [プロジェクト管理]
ずっと前から「何か変だよ、ソフトウェアのメトリクス」と思っていました。
つまり、プロジェクトの規模や進行状況を確認するのにステップ数って変じゃないのか(減ることだってあるでしょう)、といったものです。
その中でも頭がぐちゃぐちゃになりそうなのがアジャイルのケース。それを解く鍵になるかもしれない記事がInfoQに掲載されていました。
『よいアジャイルなメトリクスとは何か?』
参考にさせてもらって、プロジェクトマネジメントをどうするべきか考えないといけないな~。
『測定できないものは管理できない』というわけではないでしょうけど、進捗把握・報告をするうえでは具体的なものが欲しいですからね。作業負荷にならずに適切なもの・・・難しい課題です。
つまり、プロジェクトの規模や進行状況を確認するのにステップ数って変じゃないのか(減ることだってあるでしょう)、といったものです。
その中でも頭がぐちゃぐちゃになりそうなのがアジャイルのケース。それを解く鍵になるかもしれない記事がInfoQに掲載されていました。
『よいアジャイルなメトリクスとは何か?』
参考にさせてもらって、プロジェクトマネジメントをどうするべきか考えないといけないな~。
『測定できないものは管理できない』というわけではないでしょうけど、進捗把握・報告をするうえでは具体的なものが欲しいですからね。作業負荷にならずに適切なもの・・・難しい課題です。
PMBOK第4版 [プロジェクト管理]
PMBOKの第4版が10月30日出版。
PMIのサイトのFAQによると
・より明確な記述に
・2つのプロセスの追加、2つのプロセスの削除、調達のプロセスを6から4に再編成。
といったものになっているとのこと。
ずいぶん前からAmazonで予約していましたが、在庫がなく発送がまた先延ばしになってしまいました・・・。
PMIのサイトのFAQによると
・より明確な記述に
・2つのプロセスの追加、2つのプロセスの削除、調達のプロセスを6から4に再編成。
といったものになっているとのこと。
ずいぶん前からAmazonで予約していましたが、在庫がなく発送がまた先延ばしになってしまいました・・・。
A Guide to the Project Management Body of Knowledge (Pmbok Guide): Official Japanese Translation
- 作者: Project Management Institute
- 出版社/メーカー: Project Management Inst
- 発売日: 2009/06/30
- メディア: ペーパーバック
オフショア開発で費用「大幅」低減は難しいのです [プロジェクト管理]
オフショア開発だと開発コストが1/3とか言われていますよね・・・。確かにオフショアだけで考えればその通りなのですが、いろんなことを考えると実はそこまで安くはならない。
まずは仕様書。日本語が通じればまだいいのですが、通じなければすべて英語に直さなければなりません。
また日本語が通じたとしても日本のあいまいな感覚がすべて通じるかといえばそれはない。日本語のあいまいさをなくすように仕様書も注意して書かなければなりません。ここで日本側のコストが上がります。
次にブリッジSE。どんなにうまくやってもやっぱりブリッジSEが必要になるんです。またはこちらの人材をオフショア側に送り込むか。どちらにしても日本でのコストがまたプラスされる。
最後に品質・・・。なかなかここはうまくいかないものですよね。品質を上げる努力をしているうちにコストはどんどん上がっていく(主に日本側で)。
などとやっているうちに結局日本でやったのと変わらないという結果が最初は出てくると思います。慣れてくると記事にあるように6割くらいにはなるかもしれません。でも、中国も他の国も転職ありきの社会なんですよね。慣れてくれた・・・と安心した頃には転職してしまってまた最初から。どんどん効率があがって1/3に近づくってことはないんじゃないかと思います。
一番最初の言語の問題、あいまいさの問題をクリアするとずいぶんと違ってくると思いますけどね。こうなると日本側の努力がコスト圧縮の最大の武器になる。そうなったらニアショアでやってもよいのでは???
日本全体がグローバル化したときには開発コスト1/3という幻想が幻想でなくなるかもしれません。が、その頃にオフショア先はどこになっているでしょうね。
まずは仕様書。日本語が通じればまだいいのですが、通じなければすべて英語に直さなければなりません。
また日本語が通じたとしても日本のあいまいな感覚がすべて通じるかといえばそれはない。日本語のあいまいさをなくすように仕様書も注意して書かなければなりません。ここで日本側のコストが上がります。
次にブリッジSE。どんなにうまくやってもやっぱりブリッジSEが必要になるんです。またはこちらの人材をオフショア側に送り込むか。どちらにしても日本でのコストがまたプラスされる。
最後に品質・・・。なかなかここはうまくいかないものですよね。品質を上げる努力をしているうちにコストはどんどん上がっていく(主に日本側で)。
などとやっているうちに結局日本でやったのと変わらないという結果が最初は出てくると思います。慣れてくると記事にあるように6割くらいにはなるかもしれません。でも、中国も他の国も転職ありきの社会なんですよね。慣れてくれた・・・と安心した頃には転職してしまってまた最初から。どんどん効率があがって1/3に近づくってことはないんじゃないかと思います。
一番最初の言語の問題、あいまいさの問題をクリアするとずいぶんと違ってくると思いますけどね。こうなると日本側の努力がコスト圧縮の最大の武器になる。そうなったらニアショアでやってもよいのでは???
日本全体がグローバル化したときには開発コスト1/3という幻想が幻想でなくなるかもしれません。が、その頃にオフショア先はどこになっているでしょうね。
ネットベンチャーでもできるオフショア開発:「開発コスト数分の1」という幻想 (1/3) - ITmedia エンタープライズ
標準テキスト オフショアプロジェクトマネジメント 【SE編】
- 作者: 幸地 司
- 出版社/メーカー: 技術評論社
- 発売日: 2009/03/27
- メディア: 単行本(ソフトカバー)
PMBOK第4版によるマネジメント実践本 [プロジェクト管理]
PMBOK第4版の日本語版出版が遅れている中、実践本が先に登場してしまいました。
「PMBOK第4版によるITプロジェクトマネジメント実践法」
Amazonからの連絡によるとPMBOK第4版日本語版は10月発送になりそうだとのことです・・・。
「PMBOK第4版によるITプロジェクトマネジメント実践法」
Amazonからの連絡によるとPMBOK第4版日本語版は10月発送になりそうだとのことです・・・。
PMBOK第4版
PMBOKの第4版が出版される模様。
PMIのサイトのFAQによると
・より明確な記述に
・2つのプロセスの追加、2つのプロセスの削除、調達のプロセスを6から4に再編成。
といったものになっているとのこと。
A Guide to the Project Management Body of Knowledge: Official Japanese Translation
- 作者: Project Management Institute
- 出版社/メーカー: Project Management Inst
- 発売日: 2009/09
- メディア: ペーパーバック
ソフトウェアは進化、デマルコがソフトウェアメトリクスは誤りと認める [プロジェクト管理]
ソフトウェア工学で有名なトム・デマルコが「測定できないものは制御できない」というのは誤りであったと認めたそうです。
正確には以前は正しかったのかもしれませんが、ソフトウェアの世界が進化し次第にあわない部分が出てきたということでしょう。
それにしてもMetricsを重要視していたデマルコが「誤り」であったと認めることは衝撃ですね。
ソフトウェアもいつまでもひとところにとどまるものではないので昔の常識が通用しないことがあるのは当然。それを素直に認めるデマルコもすごい人だなと思います。
とはいえすべてのケースで間違いであるというわけではありませんのでその点はご注意ください。
正確には以前は正しかったのかもしれませんが、ソフトウェアの世界が進化し次第にあわない部分が出てきたということでしょう。
それにしてもMetricsを重要視していたデマルコが「誤り」であったと認めることは衝撃ですね。
ソフトウェアもいつまでもひとところにとどまるものではないので昔の常識が通用しないことがあるのは当然。それを素直に認めるデマルコもすごい人だなと思います。
とはいえすべてのケースで間違いであるというわけではありませんのでその点はご注意ください。
ポケット図解 トム・デマルコの「プロジェクト管理」がわかる本 (Shuwasystem Business Guide Book)
- 作者: 吉平 健治
- 出版社/メーカー: 秀和システム
- 発売日: 2007/06
- メディア: 単行本
ソフトウェアエンジニアリング論文集80's~デマルコ・セレクション
- 作者:
- 出版社/メーカー: 翔泳社
- 発売日: 2006/09/20
- メディア: 単行本(ソフトカバー)