SH019：プロジェクトはチェックリストから始まりチェックリストで終わる | シゴタノ！
photo credit: alancleaver_2000 via photopin cc ここでいう「プロジェクト」とはGTDの定義に厳密なものではありません。また会社でいうプロジェクトに限定もされません。厳密には定義できないもので、 個人的に「やりたいなあ」と思ったちょっとした大ごと です。 このあいまいな定義の中に、この種の「プロジェクト」を扱うことの難しさがあります。 だいたい「ちょっとしたこと」のくせに「大ごと」とはなんのつもりでしょう？ これは認識の問題というやつです。 抽象化はしにくいけれど具体的には簡単です。 「ちょっと部屋を片付けたいなあ…と思って始めたらいつの間にか３時間！ しかも部屋は前より乱雑になっている！」という経験はありませんか？ これが「ちょっとした大ごと」です。 認識の中ではちょっとしたことに過ぎないのだけれども、実際にやるとなるとなかなか大ごと。プレイリ
「デスマ」になることを知る必要性 | おごちゃんの雑文
デスマ寸前のプロジェクトは無事納品出来た。まだいろいろ問題はあるのだけど、「区切りをつける」ことは大事だ。 件のプロジェクトをやっていると、この客は「デスマ体質」を持っていることがわかったので、そうならないように細心の注意… ってあたりは別エントリにて。 件のエントリのコメントに、頭の悪い反応があったので、あらためて反論… じゃなくて注意しておこう。 どんなエントリだったかあまり正確な内容は覚えてないんだが、要するに「デスマであるかどうかわかったところで、末端のプログラマには大した問題じゃない」的な話。まぁデスマであろうとなかろうと、厳しいプロジェクトになってしまえば、末端がキツいことは確かに大差ないから、「末端のプログラマ」の感想としては妥当なところかも知れない。 しかし、これが「末端のプログラマ」ではなくて、SEやPMの感想であるなら、 とっとと業界から足を洗え！ と言いたい。そんな奴
2011年度版「これは金払って使う価値有り！」と思ったWEBサービス色々 | バンクーバーのうぇぶ屋
先日、僕が有料で使っているWEBサービスをまとめる機会があって、見返してみると2011年は本当に沢山のWEBサービスを有料で使いだしました。 思うんですが、世の中には沢山のWEBサービスで溢れていますよね。 プロジェクトマネジメント、クラウドソーシング、SNS管理、リソース関連。沢山ありすぎてどれを使っていいか分からない人も多いと思います。 そこで今日はいい機会なので、僕がWEB屋として活動する中で、あえて”有料で使っているサービス”を紹介してみようかなと思います。 一応先に付け加えておきますが、サービスの宣伝とかではありませんので、素直な感想とかガンガン書いていきます。 あと、値段の表記は僕が支払っている値段です。他のプランがあるものもありますのでご注意ください。 Dropbox 有料版50GB $99/年 今30GBくらい使っていますが、もはやこれ無いとやっていけませんね。 使っている
契約なんかこわくない（３） 契約の論理の根底にあるもの - プロジェクトマネジメント ワンポイント講義
プロジェクト・マネジメント（ＰＭ）、タイム・マネジメント（時間管理術）、プロジェクト・スケジューリング、などの分野で理解すべき用語と概念を解説しています。 プロジェクト・マネジメント プロジェクト制の要件 ソフトブレーン（株） の会長・宋文洲氏はいつだったか、持論のプロセス・マネジメントに関連して、「プロセスは 線路 で、プロジェクトはそこを走る個別の 電車 である」と言われたことがあった。これはなかなか面白い喩えだと思う。プロセスはいったん路線を引いたら固定して変わらないが、プロジェクトは運転手も、乗せている客も毎回違う。行き先だって変わることもある。“だからプロセスの設計が重要なんだ”というのが宋さんの立論である。 しかし、これはある意味では例外的なケースだとも考えられる。通常の製造業においては、まず「 プロジェクト 」という仕組み自体が確立していない。製品開発や受注生産といった個別
地雷力 - steps to phantasien(2011-08-22)
地雷力のある人がいる. 簡単に直りそうなバグ, 一日で追加できそうな機能に手をつけたはずなのに, と当人はいう. バグがバグをよび, パッチがパッチをよび, 議論が議論をよんで, 目のまえに次々と刈るべき毛深いヤックが増えていく. そんな人がたまにいる. しかも話の流れでみつけてしまったバグをぜんぶ割り振られていたりする. 気の毒に...私が遠目にうかがうなかそのひとは毛を刈りだして, 刈るそばからバグや作業が次々と湧きだすけれど, しばらく経ってふと目をやるとあらかた片付いている. そして最後には歓声を耳にする: "おわった!" おめでとうと私は応じる. そのひとは次の仕事にとりかかかる, ああ, そのバグはやめておいた方が... けれどそのひとは動じない. いや一旦は動じるけれど, やれやれと仕事を再開する. そんな人には地雷力があるとおもう. 地雷体質, 羊毛フェチなど揶揄をこめるこ
yebo blog: Githubの人気プロジェクト50
2011/08/17 Githubの人気プロジェクト50 オープンソースのホスティングサイトGithubにはなんと260万のリポジトリ(プロジェクト)が存在するそうだが、BostInnovationが、リポジトリをウォッチしている人気のトップ50を掲載していた。ここで見られるわけだが、改めて見ると面白い。RailsとJavascript関係が多い。Ruby on RailsjQuery JavaScript Librarynode - evented I/O for v8 javascripthtml5-boilerplatehomebrew - The missing package manager for OS Xdisapora - Distributed and contextual social networkingthree20 - Three20 is an Objectiv
賞賛の採算性 - レジデント初期研修用資料
夏休みになると日記の宿題が出て、あれが嫌で嫌でしょうがなかった。 日記が大好きな子供なんて、今でもたぶん、決して多いはずがないのに、インターネットで文章を書く人はびっくりするぐらいに多い。 日記にはない、ネットが持っている大事な機能が「他人の目」なのだと思う。それがどんな形であれ、自分以外の誰かの反応が、できれば賞賛する側に返ってくることで、その人の振る舞いは大きく変化する。 ほめるのは難しい けなされれば人は腐るし、何かの能力をほめられると、時々人は大きく伸びる。「ほめて育てましょう」と言葉にするのは簡単だけれど、実際のところ、誰かをほめるのは恐ろしく難しい。 誰かをけなせばいいのなら、仕事を命じて、マニュアルを渡して、結果が出るまで放置して、規定に足りていない部分をあげつらえばいい。ところが誰かをほめようと思ったら、その人がどんな工夫をして仕事をこなすのか、ほめる人はずっと見張っていな
これくらいできるでしょ？という思い込み：THE SHOW MUST GO ON：オルタナティブ・ブログ
良い悪いは別にして、誰しも能力に差はあります。持って生まれたものもあれば経験値が左右する種類のものもあります。それを自分を基準に考えるとどうしてもイライラしたり強く当たったりするわけですが、それでは組織運用は出来ない。そんなの当たり前でしょ？というのは尤もな話。基本中の基本ではあります。でも、その基本に忠実に行動するというのは中々難しいものでもあります。 それがたとえ仕事の場であっても、あるいは家庭や仕事を離れた何らかの活動の場でも。 自分が出来る事を他人が同じように出来るわけではない 自分の経験はあくまでも自分のものです。勿論正確的なことやら何やらも全部自分のもの。それを忘れると「これくらいのこと普通できるでしょ？」と一様に思い込むこと事態は非常に危険なこと。何かしら物事に対処する場合、だれしも自分の立場と経験と思い、思い入れ、あるいは思い込みをベースにするわけですが、残念ながら自分と同
スルガ銀−IBM裁判に関する雑感 - GoTheDistance
週末スペシャル - “スルガ銀−IBM裁判”を振り返る：ITpro スルガ銀行がIBMを訴えたのは債務不履行とのこと。つまり、債権者であるスルガ銀行が「IBMの責任で」自分たちが望むシステムを作り上げることが出来なかったと言っております。債務者(IBM)の責任である場合は、スルガは契約の解除や、不履行により生じた損害を請求することが民法で認められているそうです。スルガから契約解除＆損害賠償という強烈なワンツーパンチが飛んでいます。 要件定義を3度もやり直すという記述がありましたが、恐らく要件と要求が入り交じった「こーゆーことができるようになりたいです！」という夢と現実の区別が付かない仕様書があって、結局そいつの着地点がスルガもIBMも決められず「そのうちどうにかなるやろ」と宙ぶらりんのまま続けていき、現行業務とのギャップが後から後からザックザク出てきて、そのギャップに＋αされた機能が特盛り
新しい契約形態での受託開発サービス「価値創造契約」での第1弾システムが無事稼働し始めました - Ruby x Agile
木下です。 昨年11月のニュースリリース以来、大きな反響をいただいている価値創造契約ですが、その第1弾として、首都圏を中心に理科実験教室を展開されているサイエンス倶楽部様の基幹システム開発を受託し、今年の1月より開発を行っていることはAgile Japan 2011のセッションでもご報告していた通りです。 その後、予定していた通り、今年の6月よりこのシステムは稼働を開始しています。サイエンス倶楽部様にはここ1ヶ月間、システムを使っていただいていますが、大きなトラブルがないのは言うまでもなく、現場のユーザーの方からも高いご評価をいただいています。 6月末にサイエンス倶楽部様と私たちの開発メンバーでふりかえりを行いました。ふりかえりの中でも多くのフィードバックや気づきを得ることができました。今回の開発については新しい契約形態でRubyを使ってアジャイルに開発した事例として、追々みなさまにも公表
ほぼ日刊イトイ新聞 - 西條剛央さんの、すんごいアイディア。
これも、考えかたはシンプルなんですよ。 たとえば自治体ベース、学校ベース、 なんでもいいんですけど、 「ここに、こういう家電が これぐらいの分量、集まりますよ」と 知らせてくれれば、 すでに運送業の青年組織の方々と ネットワークができあがっているので、 全国どこからでも、 直接、被災地に運んでしまうんです。
6月15日（水）大切なことは過ちをおかさないことではなく「被災者の支援」です - 西條剛央メッセージ | ふんばろう東日本支援プロジェクト
◆何もしないほうが無難で安全、でしょうか？ 先日のMTGでは、僕は大丈夫と直観していたのですが、「家電プロジェクト」を心配している人が強い反対意見を出していたので、まあそれほどいうならと、そうした意見を聞いて安全策を採ることにしました。でも結局蓋を開けてみれば、そうした方々が怖れていたようなことは何も起きませんでした（笑）。 「家電プロジェクト」についてテレビで出すのは止めるべきだという意見も複数あり、それはもちろん却下したわけですが（「止めるという選択肢をしたならば多くの行政と同じ道を歩むことになるため、その選択はない」と）、そうした方々が心配したようなことは何一つ起きなかったわけです。 これはそうした意見をくださった人を責めているわけでは全くありません。むしろ対等の立場で意見を言ってくださるのは大変ありがたいですし、そうした人は大切にしなければならないと本気で思っています。最後は自分で
ネットサービス系企業における、積み上げ型タスク管理の危険性
ネットサービスもそこそこの規模になると、後回しになっている、あっちゃこっちゃに細かい問題が積み上がってきます。 継続改善というサイクルの中で、改善していくわけですが、じゃぁこれをどのように処理していくか？という考え方の話。 一番最悪なのは、とにかく目についたものを全部直そうと言う考え方。 もはや維持フェーズに入っている事業担当の方なら、是非、どんどん直してくださいって話なんですが、多くのケースではそうではなく、未来に向かって、前に進むべきタスクが存在しているハズです。 事業の優先順位と連動せず、現場の開発者の判断で、気になったところを直していくと、必ず時間がかかります。見積もりには、判断ミスをするとか、考える時間やソースコードを検索するような時間が往々にして入ってませんからね。かつ、修正範囲が大きくなって、新しいバグの温床になることも少なくありません。 必ずスケジュールを切って、優先順位を
Rails3.1の初期化プロセスを細かく追いかけたRailsGuidesの記事を和訳したよ:ミームの死骸を越えてゆけ
This domain may be for sale!
無様にやるのは難しい - レジデント初期研修用資料
「戦力の逐次投入」という代表的な失敗パターン、問題を解決するための資源を過小に割り当てて、それでは足りない、という反応が返ってきても、なおも「足りない」資源だけを現場に送って、結果として貴重な時間を浪費してしまうあの状況というものは、作戦を指揮した将軍が戦力を「節約」しようとしただとか、相手を見くびっていただとか、そんな理由からは生まれない。 不足は見えない 診療をしていると、たまに「このままでは病気に追いつけない」という、いやな予感に襲われることがある。患者さんの治療はそこそこにうまくいっているけれど、ベストと言えるほどの反応は得られなくて、やることはやっているはずなのに、何か足りない。 このまま状況を放置すると、「ちょっと反応が少ない」ままに状況が進んで、気がつくとその「ちょっと」はさらに少なくなって、事態はむしろ悪化していく。気がつくと数日間という期間が、根本への対処を怠ったままに消
アジャイルな見積りと計画づくり：第1部：問題とゴール「３章 アジャイル手法」まとめ - 基本へ帰ろう
もし「む、この機能が必要かもしれないけど、これを追加すると言われた期日に間に合わないな・・・オーナーにはリリースまで黙っておこう・・要求にはないし」こういったことを、プログラマがしていると、いつまでたってもアジャイルなチームにならない。アジャイルチームで必要のは、「顧客が満足する本当の価値を提供する」ことであって「言われた期日」ではない。もちろん、「期日」も価値の内だが、バランスが大切なのと、顧客とのコミュニケーションをしっかりと取ることが重要だ。何か新しいことを発見したら、チームやプロダクトオーナー、顧客に共有して価値の探索をしよう。顧客やプロダクトオーナーとまったくコミュニケーションをとらないようではいけない、一丸となって一緒の方向を向こう。本当の価値を追い求めて、コミュニケーションをとっていき、定期的に成果を出すことで、信頼もどんどん厚くなっていくだろう。 目次 アジャイル手法 プロ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Agility@Scale(アジャイル開発のスケールアップ)を実現する14のベストプラクティス
Amazon.co.jp: アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~: Mike Cohn (著), マイクコーン (著), 安井力 (翻訳), 角谷信太郎 (翻訳): 本
Amazon.co.jp: アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE): James Shore (著), Shane Warden (著), 笹井崇司 (翻訳), 木下史彦(監訳) (読み手), 平鍋健児(監訳) (読み手), 木下史彦(監訳) (監修), 平鍋健児(監訳) (監修): 本
プロジェクトを成功させる 現場リーダーの「技術」
