ポストモダンプロジェクトマネジメント - 思っているよりもずっとずっと人生は短い。
メモ。この前角谷さんと話した内容を下敷きに。 プロジェクトマネジメントはポストモダン化しつつある。 キーワードは「感情管理」。近代的なプロジェクト管理では、作業者は機械と同様、定量的なタスクをこなす装置（機械）と考えられていたが、現代的なプロジェクト管理では作業者の感情にフォーカスする。これはチームのメンバーにもリーダーにも当てはまる（リーダーの方がより強くあてはまる）。 ポストモダンプロジェクトマネジメント技法の代表例としてコーチングとファシリテーションが挙げられる。前者は規律訓練型、後者は環境管理型の側面が強い。コーチングが主にリーダーに対し、その振る舞いを規定し、強要する一方、ファシリテーションではその意図を不明確に・あるいは隠蔽し、メンバーの感情を暗黙のうちに管理しようとする。高度なファシリテーションではリーダーすらも暗黙のうちに管理されるようになる。 プロジェクトマネジメントがポ
テストを書かないと品質はやっぱり下がる - Be Happyman!!
私は今だにxUnitに代表される自動テストツールの効果が今ひとつ腑に落ちていなかったのですが、プロジェクトメンバーがその効果を調査・分析・見える化してくれたおかげですっきりしました。私の中だけに留めておくのはもったいないのでエッセンスを公開します。*1 対象プロジェクトに関する情報は以下の通りです。 業務系 画面数は60程度 帳票数は15程度 Java(Seasar2/S2Struts/S2Dao),Web系 クラス数は750程度 開発期間は約半年 最終的には総じて高い品質を実現した テストツールとしては、JUnit/EZmock/S2TestCaseを使っていて、それぞれ対象となるレイヤは、Actionクラス/Serviceクラス/Daoクラスです。画面のテストにはSeleniumも使いましたが、今回の調査の対象外としています。 目的 テストで重要なのは、要はそれぞれの工程で適切な粒度・
デスマーチ・プロジェクト - 新小児科医のつぶやき
昨日福島事件の第1回公判が行われ、何か書こうと思っていたのですが、さすがに去年最大の歴史的大事件だけあって、あちこちに書きたいことが書き尽くされています。情報的には報道経由以上の内容は無いようでしたが、マスコミの「過失である｣とのバイアスがかかった記事に強烈に咬みつかれていました。二番煎じ、三番煎じをするにも今朝の時点では出がらしもいいところなので、もう少し医師側からの情報が出てきたらエントリーしてみようと思います。それにしてもさすがにこの事件への反応は敏活ですね。 今日は昨日見つけたブログを紹介したいと思います。書かれているのはIT技術者で、これが医療関係者以外と思えないぐらいの医療危機への的確な分析がなされています。あまり簡潔明瞭さと理解の深さに驚かされたので、皆様にも是非ご一読頂きたいと思います。 1/25付ronSpaceエントリーより抜粋 医療崩壊について、以下に私自身の理解した
activeCollab日本語情報サイト
弁護士相談って、いったいどんなものなのでしょう。 例えば、もしあなたのご家族が交通事故に遭ってしまった時。 相手に賠償をしてもらうかもしれません。 何らかの犯罪に巻き込まれてしまった時。 相手との話し合いの中で、弁護士を呼ぶ必要があります。 離婚について相談したい時。 相手と争う必要があるかもしれません。 または、借金をしている時。債務について弁護士に相談することもありますよね。 他にも、遺言や、それに伴う相続について弁護士に相談したり、最近ではストーカーや家庭内暴力などについて相談したい！という時。 様々なことがありますね。 これらの被害や悩みについて、あなたが相談に行くと、弁護士はあなたに解決法を与えるために、寄り添って考えてくれます。 もし、事前の準備なしで相談をしに行ったらどうなるでしょうか？ せっかくあなたの味方になってくれる弁護士も、お手上げ状態になってしまうでしょう。 弁護士
プロジェクトは失敗するのが当たり前！？ ― ＠IT情報マネジメント
ITプロジェクトが失敗する理由は、成功することを前提としたマネジメントが行われているためである。ITプロジェクトの成功率は思いのほか低く、このような状況を改善するためには「失敗を前提としたマネジメント」を心掛けなければならない。失敗を前提としたマネジメントとは、リスクマネジメントに重きを置いたマネジメントということになる。 ITプロジェクトのほとんどは失敗に終わる 成功率16％。これはある開発ツールベンダが調査した米国におけるITプロジェクトの成功率である。その調査によれば、昨年米国で遂行されたプロジェクトは約17万件であり、そのうち、機能、予算、納期などが当初の想定内に収まったものは16％だったという。 日本においてもほぼ同じ状況であるといえる。「企業IT動向調査2006」（社団法人 日本情報システム・ユーザー協会）に調査によれば、システムの仕上がりに満足と回答したユーザーは10％前後に
SEにはマルチで仕事をさせよ
筆者が狙った，ビジネスができSEが育つ技術集団作りのポイントは2つあった。その 一つは，SEの常駐や特定顧客への専任アサインは原則しないこと，二つ目はSEが「マルチで 仕事をする」ことであった。常駐については後ほどお話しすることにして，今回は二つ 目の「SEのマルチ」を説明する。 一人が複数の顧客やプロジェクトを担当する SEのマルチとは，筆者の造語かも知れないが，コンピュータはOSがCPU時間をディ スパッチして同時に複数のジョブを処理する，それと同様に一人のSEが2，3件の顧客 やプロジェクトの仕事をすることを意味する。即ち，あるSEがA社のシステム開発とB 社の提案活動とかC社とD社のアプリケーション開発を行っていれば，そのSEはマルチ で仕事をしていることになる。マルチ度はそのSEの能力や仕事内容や顧客やビジネス の状況など色々な要素を考えて決める。 SEがこのマルチを行うことによ
『プロジェクト・オートメーション～コンピュータもチームメンバだ!!～』
■1 デブサミ2006:2日目 お、終わりました……。あとで書く、と書くのでいまは精一杯。 (追記)資料を置いときます: 『プロジェクト・オートメーション〜コンピュータもチームメンバだ!!〜』(PNG+HTML via Rabbit), アーカイブ(tar.gz) 検閲済。発表時にものから少しだけ変わってます(オーム社の応援を追加)。247枚。 『プロジェクト・オートメーション〜延長線〜』(PNG+HTML via Rabbit),アーカイブ(tar.gz) 時間が余ったときに備えて殴り書いたもの。当日は話してませんが、問い合わせが何件かあったので、置くだけ置いておきます。 2006/02/13追記(1): アーカイブも作成しておきました。 ナローバンドなt-wadaさん向け特製なのでtar.gzのみです。他形式が欲しい方はpullしてください。 2006/02/13追記(2): "「『単
conflict.rd
embrace the conflict -- 葛藤を楽しもう はじめに この文章は、 2003年の新入社員に「今後の技術動向とそれにそなえるために」というテーマで話したことからできたものです。 その時話した内容の中には重要な視点が含まれているような気がして、 整理しなおして文章にしてみようと思いました。 まとめながら、何を言いたかったのか自分で考え直してみた所、 「葛藤」という言葉がキーコンセプトとして浮かびあがってきました。 概略 これからのソフトウエア開発は多くの価値観が「葛藤」を起こすことが避けられない 葛藤はインターネットとオープンソースと社会、経済のかかわりから起きる 戦略、枠組みを持たないと技術者として成長していく過程で混乱してしまう 戦略の例としてT字型技術者というモデル 枠組みの例としてサラリーマンVSテクノロジストという観点 枠組みの例としてコンピュータの4つの文化とい
道具箱の整理
はじめに この記事は、mymy-mycompany分室の2005年10月に1ヶ月をかけて書いたものです。ブログだと後から参照するのが大変なので、ここにまとめておきます。また、ブログでは時間の都合で書けなかった話も追加していく予定です。 私の道具箱 ここ１ヶ月ほど、私的Ｗｅｂサイトプロジェクトなるものに参加しています。オープンソース方式ではなくて伽藍方式。以前、オープンソースのカンファレンスに出たときに、そこで発表していた学生が、ちらと「実はオープンソースよりも伽藍のほうがクオリティが高いものができると思っているんだよね～」と話していたのが、非常～に気になってはいるのですが、そのあたりは、各自のモチベーションと時間の取り方の違いでしょうね。オープンソースでもコミットする人数（アクティブな人）が限られていれば伽藍に近くなるし、伽藍にしてもうまくいかないプロジェクトごまんとあるわけなので。 で、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
not found