Annexソフトウェア技術系を中心に掲載していきます。最近は自分の情報Indexと化しているかも。フリーコメントは「コメント&足あとBox」カテゴリー記事にて歓迎します。[プロジェクト管理]この書籍は読み物としてとても面白い。『そうそう、こういう問題があるんだよ』『こうすればうまくいくんだよなー』『これをやれば改善できるかも』・・・本当に共感できる部分がたくさんあります。読んでいると稼働率に関する内容で「ザ・ベロシティ」で登場するようなシーンが出てきます。ソフトウェア開発でも製品製造でも同じなんだなーと実感します。読み物として面白いのは共感できるから。実践はというと・・・難しいところがあるんだろうなー。確かにできるものもあると思います。開発(とかアジャイル開発とか)ってやろうとすると社内の抵抗に遭いませんか?今までのやり方だとほぼ間違いなく失敗する、だからこそ新しいやり方で進めなければならないのに、「今までのやり方は標準だから変えてはいけない」的な圧力・抵抗が出てくる。開発(やアジャイル開発)はもうそれほど新しいものではありません。新しいものとして取り組まなければならない・・・。「読み物」としては面白い、となってしまうのです。実践しようとするならば、組織の抵抗を乗り越えるんだという強い意志が必要だと思います。組織の抵抗を乗り越えるためのヒントが掲載されていたのでそれを紹介しておきましょう。トヨタのかんばん方式を確立した大野耐一氏の言葉ということなので、その筋の方には説得力があると思います。「標準というものを最善だとおもったらもういかん。標準というのは、改善するためのひとつのベースであってね。」この言葉が強い味方になるはずです。見積もりといったところではないでしょうか。本書では見積り以外が対象になっていると思います。多数あるだけあって、書籍では事例がたくさんあります。私の経験と照らし合わしても「これが失敗要因だった」と合致するものがたくさん・・・。その『突破術』として記載されている内容は・・・正論が多いんですよねー。「それができれば苦労しない」「そもそも自社側の上司の指示・命令でそうせざるをえない」というものも結構ある。正論を押し通すことができれば苦労しないと言いたいところも多数ありました。言えば、これをまじめにやったらアジャイル開発は難しいだろうなーという感もあります。何らかの方法はあるのでしょうけれど。アジャイル開発に向かないのが日本の商慣習という面もあるかもしれません。いえ、やっぱりこうした失敗事例と「本来どうあるべきか」ということは知っておかなければなりませんから、本書のような内容はマネジメントを行う人にとっては結構参考になると思います。ちなみに、本書は「計画・管理編」となっていますが、それ以外の「~編」が出るんですかね~。[プロジェクト管理]プロジェクトマネジメントのPMBOK、ソフトウェア品質のSQuBOK、ビジネスアナリシスのBABOK。ここまでは知っていましたが、アウトソーシングの知識体系本があるそうです。[プロジェクト管理]本書はアジャイルメソッドをうまく企業内で利用していくための教科書のような存在ですね。私も数年前にアジャイルメソッドを使ってプロジェクトマネジメントをしようと試みたことがありました。その時は品質保証部門や上長の理解が得られずに断念。ウォーターフォール型管理をして結局大失敗に終わりました。リスクを早く察知して早期に解決していくアジャイルメソッドは企業レベルでも十分に利用できるはずです。ウォーターフォール型管理手法で標準化している組織では変化を怖れてしまい適用しない。「変化を怖れる、変化を受け入れない」というのは最大のリスクだと思うんですけどね~。実際にプロジェクトマネジメントに携わる方だけではなく、社内標準化(等)に携わっているすべての方々に本書をお薦めします。利点(と欠点)をしっかり把握しアジャイルメソッドをもっと活用してほしいものです。[プロジェクト管理]2007年に登場した「共通フレーム2007」その第2版が10月に出ていました。何かが追加になったとかではないと思いますが、同じものなら新しいほうがよいですものね~。今、読み始めたところなのですが・・・。この手の本はソフトウェア開発会社なら社内全部署に最低1冊ずつ、一般の会社でも情報システム部門には1冊、かならず置いて欲しいですね。今回は超上流も含んでいるようなので、とても重要な一冊になっていると思います。来年4月から受託ソフトウェア開発での工事進行基準適用によって、契約内容はより明確にしなければなりません。なると用語の差異も発生しないようにしなければなりません。この共通フレームはそうしたソフトウェア開発の各工程の用語の統一にも寄与すると思います。一応開発手法には依存しないよう配慮されているのでウォーターフォール、UP、アジャイルなどの手法にも対応できるでしょうし、それぞれの手法で適用するよう用語をマッピングするなどの配慮が必要かもしれません。内容を読んだら一応感想などは再度アップしたいと思います。[プロジェクト管理]ずっと前から「何か変だよ、ソフトウェアのメトリクス」と思っていました。プロジェクトの規模や進行状況を確認するのにステップ数って変じゃないのか(減ることだってあるでしょう)、といったものです。その中でも頭がぐちゃぐちゃになりそうなのがアジャイルのケース。それを解く鍵になるかもしれない記事がInfoQに掲載されていました。参考にさせてもらって、プロジェクトマネジメントをどうするべきか考えないといけないな~。『測定できないものは管理できない』というわけではないでしょうけど、進捗把握・報告をするうえでは具体的なものが欲しいですからね。作業負荷にならずに適切なもの・・・難しい課題です。[プロジェクト管理]PMBOKの第4版が10月30日出版。PMIのサイトのFAQによると・より明確な記述に・2つのプロセスの追加、2つのプロセスの削除、調達のプロセスを6から4に再編成。いったものになっているとのこと。前からAmazonで予約していましたが、在庫がなく発送がまた先延ばしになってしまいました・・・。[プロジェクト管理]オフショア開発だと開発コストが1/3とか言われていますよね・・・。確かにオフショアだけで考えればその通りなのですが、いろんなことを考えると実はそこまで安くはならない。日本語が通じればまだいいのですが、通じなければすべて英語に直さなければなりません。日本語が通じたとしても日本のあいまいな感覚がすべて通じるかといえばそれはない。日本語のあいまいさをなくすように仕様書も注意して書かなければなりません。ここで日本側のコストが上がります。どんなにうまくやってもやっぱりブリッジSEが必要になるんです。こちらの人材をオフショア側に送り込むか。どちらにしても日本でのコストがまたプラスされる。ここはうまくいかないものですよね。品質を上げる努力をしているうちにコストはどんどん上がっていく(主に日本側で)。やっているうちに結局日本でやったのと変わらないという結果が最初は出てくると思います。慣れてくると記事にあるように6割くらいにはなるかもしれません。中国も他の国も転職ありきの社会なんですよね。慣れてくれた・・・と安心した頃には転職してしまってまた最初から。効率があがって1/3に近づくってことはないんじゃないかと思います。最初の言語の問題、あいまいさの問題をクリアするとずいぶんと違ってくると思いますけどね。なると日本側の努力がコスト圧縮の最大の武器になる。なったらニアショアでやってもよいのでは???日本全体がグローバル化したときには開発コスト1/3という幻想が幻想でなくなるかもしれません。その頃にオフショア先はどこになっているでしょうね。[プロジェクト管理]PMBOK第4版の日本語版出版が遅れている中、実践本が先に登場してしまいました。「PMBOK第4版によるITプロジェクトマネジメント実践法」Amazonからの連絡によるとPMBOK第4版日本語版は10月発送になりそうだとのことです・・・。単行本PMBOK第4版PMBOKの第4版が出版される模様。PMIのサイトのFAQによると・より明確な記述に・2つのプロセスの追加、2つのプロセスの削除、調達のプロセスを6から4に再編成。いったものになっているとのこと。[プロジェクト管理]ソフトウェア工学で有名なトム・デマルコが「測定できないものは制御できない」というのは誤りであったと認めたそうです。正確には以前は正しかったのかもしれませんが、ソフトウェアの世界が進化し次第にあわない部分が出てきたということでしょう。それにしてもMetricsを重要視していたデマルコが「誤り」であったと認めることは衝撃ですね。ソフトウェアもいつまでもひとところにとどまるものではないので昔の常識が通用しないことがあるのは当然。それを素直に認めるデマルコもすごい人だなと思います。いえすべてのケースで間違いであるというわけではありませんのでその点はご注意ください。プロフェ..最近のコメントおはようございます。ソネットポイントこの広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。この広告は180日新規投稿のないブログに表示されます。