Martin Fowler's Bliki in Japanese - 朝会のパターン：立ってるだけじゃないよ
朝会（デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル*1、朝のロールコール*2）を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、そのチームはそれが何なのか分かっていなかった。 朝会の基本原則と詳細を意識していなかったのだ。 そのために朝会の問題について診断や解決がなされていなかったわけだ。 良い朝会を経験した人たちは、 うまくいってないときに何をすればいいかを知っている。 朝会に慣れていない人たちは、 うまくいってないときに何をすればいいかに気づかない。 「暗黙知なんだから、とにかく
院長室の秘儀 - レジデント初期研修用資料
レジデント初期研修用資料 引っ越し前の旧blogです。新しいアドレスは http://medt00lz.s59.xrea.com/wp/ になります 昔研修していた400床の民間病院では、一晩に当直する医師の数が12人。 救急外来4人。内科2人、外科2人、産婦人科、小児科が各2人。 病院の隣に「夜明かし」という飲み屋さんがあって、そこの奥座敷が整形外科の第2医局。 朝の5時ぐらいまでだったら、そこには必ず誰か常駐していたから、分からない骨折の人がきたときは、 電話一本で飛んできてくれた。 救急外来はいつもお祭り。ダブルCPRなんかになると病院中の当直医が集まってきて、 昼間以上のにぎわい。3日に1回は当直だったし、仕事は忙しかったけれど、 今はいい思い出。 救急車奪いあい。症例奪いあい。 救急医療の崩壊なんて、考えもしなかった、ほんの6年前のこと。 責任者を出せ フロントラインに立つのは研
わたしが知らないスゴ本は、きっとあなたが読んでいる: プロジェクトを成功させる魔法の言葉
あいにく銀の弾丸の持ち合わせはないが、うまくいくプロジェクトでよく使われていた言葉は確かにある。耳にしたときは聞き流していてた言葉を、この本は思い出させてくれた。ここでは、そんな「魔法の言葉」を紹介する。 ネタ元は「目標を突破する実践プロジェクトマネジメント」。ふつう、図書館で読んだ本はそれっきりだが、こいつは買って周りにばら撒く。薄くて分かりやすくて、すぐにやってみようという気にさせるところがいい。 ■ もし、問題があるとすれば、それは何ですか? 朝会や進捗会議で「何か問題はありませんか?」という質問はよくするしされる。けれども答えはいつも決まっている→「特にありません」。でもって、不具合が起きると、「あのとき聞いたのにッ」←→「こうなるとは思ってなかった」となる。 身に覚えない? これを、冒頭の質問にしてみると、アラ不思議、いくらでも出てくる。「問題ない?」には無反応だったのが、「これ
組織を腐らせる「キャンサー」の見抜き方：日経ビジネスオンライン
（Part3へ） 職業としての「社長」を自ら選び、活躍している人をお招きし、将来、経営層を目指す人々に、ご自身の経験を語っていただくトークセッション「Road to CEO」。今回は、世界最大の組織・人事マネジメント・コンサルティング会社、マーサー・ヒューマン・リソース・コンサルティングの日本法人を率いる柴田励司氏をゲストに迎え、組織運営の秘訣と人事の課題について語っていただいた。最終回では、会場との質疑応答をお送りする。 司会、山中（以下Y） この辺で皆さんからの質問に移らせていただきます。挙手をお願いいたします。 【Q】 私自身も人事を十数年やっていまして、人事の仕事って、給与計算をやる業務から、ヒューマンリソースという資源をどう再設計するかというところに行きました。 最後に柴田さんがおっしゃられた問題は、ヒューマンリソースという立場を超えていると思うんです。だから何というタイトル（名
＠IT：開発プロセス標準化への道（1）
この短期連載は、社内のソフトウェア開発プロセスの標準化に日夜取り組んでいるあなたにぜひとも知っていただきたいことをお伝えしていきます。理由は、それ（ソフトウェア開発プロセスの標準化）がうまくいっているという話を、少なくとも私はほとんど聞いたことがないからです。 標準化の目的 そもそもなぜ、開発プロセスの標準化に取り組むのでしょうか。ソフトウェア開発組織の使命は、顧客のビジネスの成功に対する貢献であると、わたしは考えています。そして、日々その貢献度を上げていかなければ競争を生き残れないと感じています。事実、多くの開発組織では、表現に違いはあるものの、同様の内容を自らの使命として掲げています。そして、貢献度を上げるための手段として、自身の開発力を高めていこうとしているのです。 開発力を高めるための手段としては、 特定の分野に特化する 開発期間の短縮 開発コストの削減 品質の向上 といったことが
ユーザー企業側プロジェクトチームの使命と役割
企業システム開発は、スケジュール／コスト超過を含めて考えるとかなり失敗が多い。システム開発そのものが難しいのも事実だが、導入サイド（ユーザー企業）の誤解や能力不足に起因する失敗例が少なくない。ユーザー企業の現役システム担当者がユーザーサイドにおけるプロジェクトの進め方を解説する ユーザーが行うべき作業を考える 大規模なコンピュータ・システムの開発プロジェクトには、多くの人が携わり、膨大なお金と時間が費やされます。それに値するだけのシステムが出来上がればよいのですが、実際には、稼働までに至らなかったり、使い物にならないシステムができてしまったプロジェクトが少なからずあります。また、ここまでひどいケースではなくても、当初計画した品質、コスト、納期を満たさなかった案件を失敗事例とすると、実に3/4以上のプロジェクトが失敗しているとも聞きます。 なぜ、コンピュータ・システムの開発プロジェクトはこれ
＠IT：初めてのプロジェクトリーダー
ソフトウェア開発チームを構成するメンバーは大きく2つの種類に分かれます。開発者とリーダーです。開発者にさまざまなスキルが必要なように、リーダーにもさまざまなスキルが必要です。多様なスキルの中で最も習得が難しいとされているのは、開発者と違う視点を持つことです。もし、（教科書どおりにやっているはずなのに）いまあなたがリーダーとしていま一つだと感じているのであれば、開発メンバーから、リーダーへの視点の切り替えが上手に行われていない可能性があります。 この連載を通じて私がお手伝いしたいのは、視点の切り替えです。切り替えというよりは、「もう1つの視点を持つ」といった方が適切かもしれません。メンバーとして、開発者としてプロジェクトチームに貢献してきたあなたが、リーダーとしてチームに貢献するために追加すべき視点を持つにはどうすればよいか？ 次の3つの切り口で説明していきたいと思います。 3つの切り口：「
＠IT：明日からできるプロジェクト管理（1）
デスマーチを止める進ちょく管理の現実解:GanttProjectの導入で進ちょくをコントロールする：明日からできるプロジェクト管理（1）（1/4 ページ） 開発プロジェクトは、何もしなければどんどん混乱していく。計画は破綻し、成果物は四散し、開発要員の心理はズタズタになる。混乱を収拾するのは容易ではない。開発プロジェクトの立ち上げ段階から秩序を導入し、整理整頓されたその状況をカットオーバーまで維持すること。もちろん、それは口でいうほど簡単なことではないのだが、まったく無理なことでもない。本連載では、プロジェクトに秩序をもたらすさまざまな手法を、開発プロジェクトの段階を追って解説していく。そして、手法の説明だけではなく、具体的なツールを使って「どうすれば効率的な管理が可能なのか」という現実的な提案も行うつもりである。ここで使用するツールはすべてオープンソースのプロダクトである。効果的な方法を
モチベーションを高めたいなら達成すればいい ― ＠IT情報マネジメント
第3回目となる今回は、第1回「優秀なプロマネはメンタルな働きかけもうまい」で触れたゴールアライメントについて、もう少し詳しくお伝えしようと思います。さらに、プロジェクト成功には欠かせないメンバーのモチベーションを高めるためのポイントや、当たり前過ぎてやっているプロジェクト、組織がほとんどないけれど、実は絶大な効果がある“ルール”についてもお伝えしますので、ピンと来た方は最後までお付き合いください。今回もオムニバス形式でお届けします。 ばかばかしいほど簡単で大切なルール あらためていうまでもないことですが、プロジェクトや組織を運営していくためにはルールが必要です。会議運営のためのルールや、個別の作業を行う際のルール、あいさつのルールなどなど、組織によって本当にさまざまなルールがありますが、私が非常に強力な効果があると感じているのは「言葉遣いのルール」です。小学生じゃあるまいし！ と驚かれた方
マネジメントの役割
要求定義というと，ヒアリングのやり方などユーザーの要求の把握の仕方/整理法やまとめかた，ドキュメントの手法などが話題になりがちで，マネジメントのあり方について議論されることはあまりないように思います。しかし，要求定義がシステム構築プロジェクトにおける工程のひとつであるという視点に立ってみると，要求定義に関するマネジメントのあり方にもいろいろと考えなければならないことに気づきます。 プロジェクト・リーダーやさらにその上で統括的なマネジメント・コントロールを行うマネージャは一体どんな行動を心がけ，またどんな行動は慎んだらよいのでしょうか。 ある基幹系システム構築のプロジェクトでこんなことが起きました。要求定義を進めてゆくうちに「どうもこれは当初出した見積もりよりも大きな開発規模なるかもしれない」と思った受注側の統括マネージャが，急遽介入してきたのです。それは全く唐突にスケジュールを変更したい，
現代という時代は、どのようなプログラミングを求めているのか？ - 分裂勘違い君劇場 by ふろむだ
Rubyを使うべき本当の理由は、根源的には、日本で自殺者が増えた理由と同じです。 今後日本が没落していく理由とも同じです。 団塊の世代に無能な人間が多い理由とも同じです。 サービス残業が増えた理由とも同じです。 日本の多くの若者たちが未来に希望を抱けない理由とも同じです。 いまの学校教育が無能な人間の製造工場になってしまっている理由とも同じです。 その理由は、根本的には、「単純ニーズの飽和」という環境変化に起因します。 そして、それによって、プログラミングが経営行為になってしまったことが原因なのです。 団塊の世代の仕事人生の大部分は、単純ニーズを満たすための仕事に費やされました。 冷蔵庫の普及率が低く、しかも誰もが冷蔵庫を欲しがった時代には、何をやるべきかは、明らかでした。 とにかく、額に汗して働き、安くてよい冷蔵庫をどんどん作れば良かったのです。 冷蔵庫に限らず、洗濯機、ラジオ、テレビ、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CommitBit-0.02 - A project administration tool - metacpan.org