わたしが知らないスゴ本は、きっとあなたが読んでいる: プロジェクトは冒険だ！「仕事を100倍楽しくするプロジェクト攻略本」
薄くて濃い一冊。 プロジェクトを「まわす」にあたり、本当に必要な内容だけを吟味してまとめてある。ある意味、いさぎよい。頁数を水増し→煽り文を追加→ハードカバーにして、2倍の値段で売っているそこらのビジネス本と180度違う。テクニックよりも心得を重視しており、トム・ピーターズのように読んだ側からソノ気にさせる。 プロジェクトは冒険だ、そして、キミは勇者だ。王さまの話を聞き、仲間を集めてパーティーを編成し、レベルアップに勤しみ、最高のクリアを目指す――なんのことはない、昔っからゲーム相手にしてきたことと一緒。 あのときの「ワクワク感覚」そのままに、プロジェクトの現場を捉えなおしてくれる。この視点はありそでなかった。いちいち激しく頷きながら読む。 本書のエッセンスは、デマルコの「マネジメントの4つの本質」に尽きる。「デットライン」に、こうある。 適切な人材を雇用する その人材を適所にあてはめる
GanttProject
Available for Windows, macOS and Linux. Downloads in seconds, installs instantly and ready to build projects immediately with zero setup. Simple, intuitive and uncluttered user interface will let you break down the work, build a Gantt chart, assign resources and calculate project costs in minutes. If you need some guidance into the basics of working with GanttProject, please watch this awesome vid
wisdom | あなたのビジネス思考に、ひらめきを。
北米トレンド 織田 浩一 連載 米国を中心にモノやサービスのデジタル化が進み、競争の鍵は顧客体験の向上と価値創造に移行しました。新たなトレンドに対応するため、北米の最新情報を毎月お届けします。
わたしが知らないスゴ本は、きっとあなたが読んでいる: いきなりコンサルタントに抜擢されたSEが読むべき5冊
上長から「来週からコンサルタントとして○○社に入ってくれ」なんて言われたときに、あわてないための5冊。以下の条件全部にあてはまる人のための選書なので、関係ない方はスルーしてくだされ。シリーズ化しつつあるエントリ（ [その1]、[その2] ）だが、ここらでまとめ。 システム開発チームのメンバーまたはリーダー 顧客の御用聞きを「コンサルティング」だと思っている ←これ誤り McKinsey や accenture といった「ファーム」と一緒に、顧客の中に入って仕事しなければならなくなった これまで、即効性と実用性で4冊レビューしてきたが、このたび5冊目として扱いたいガイドを見つけた（4冊目）のでまとめてご紹介。 ■最初に結論 コンサル会社がやっている「コンサルティング」は、決まりきった手順や方法を粛々と実行しているに過ぎない。目標に対して泥臭いぐらい愚直に反応する。そうしたメソッドと沢山持って
わたしが知らないスゴ本は、きっとあなたが読んでいる: プロジェクトを成功させる魔法の言葉
あいにく銀の弾丸の持ち合わせはないが、うまくいくプロジェクトでよく使われていた言葉は確かにある。耳にしたときは聞き流していてた言葉を、この本は思い出させてくれた。ここでは、そんな「魔法の言葉」を紹介する。 ネタ元は「目標を突破する実践プロジェクトマネジメント」。ふつう、図書館で読んだ本はそれっきりだが、こいつは買って周りにばら撒く。薄くて分かりやすくて、すぐにやってみようという気にさせるところがいい。 ■ もし、問題があるとすれば、それは何ですか? 朝会や進捗会議で「何か問題はありませんか?」という質問はよくするしされる。けれども答えはいつも決まっている→「特にありません」。でもって、不具合が起きると、「あのとき聞いたのにッ」←→「こうなるとは思ってなかった」となる。 身に覚えない? これを、冒頭の質問にしてみると、アラ不思議、いくらでも出てくる。「問題ない?」には無反応だったのが、「これ
プログラマのスキルレベルに依存しない体制ができたらプログラマはいらないような気がする件について - ブログは死なず、ただ放置されるのみ。
ところで まなめはうすさんのところで、おそらく今年最後のひっかかり。 個人的に大規模ではSEに依存し、小規模ではプログラマに依存すると思う。だから、大規模でしか仕事したことのない私はSEが重要だと思っているんだよね。プログラマのスキルレベルに依存しない体制を作り上げることが最強なのです。 あえて悪いほうに解釈すると『プログラマのスキルレベルに依存しない体制』って例えば、マニュアルどおりの対応しかできない人が頭数だけそろっても大丈夫な体制ってことでしょうかね。じゃあもしそういう体制ができたら、べつにプログラマじゃなくてもいいですよね。だってスキルに依存しないんだから。まあ、そこまでじゃなくて、じゃあ最低ラインスキルのプログラマさんたちだけ来ていただくことになるんですかね。 SEとなってしまった自分にとって、プロジェクトでもっとも重要なことは「メンバの個々のスキルを適切に判断し、適材適所に配置
【特集】使ってる Issue Tracking - trac 楽々ことはじめ (1) パニックプロジェクトを生まないために (MYCOMジャーナル)
プロジェクトの情報共有を支えるための重要なタスクにドキュメンテーションと文書管理がある。あなたのプロジェクトでは適切な文書管理がなされているだろうか。通常、プロジェクトからは日々多くの種類/フォーマットの文書が生み出されている。そのため、文書管理に統制の無いプロジェクトでは、どこにある何を見ればいいのかを把握することでさえ、たちまち容易ではなくなってしまう。 プロジェクトに関する情報が増えてくる前に、一人でプロジェクト開発に従事しているあなたも、チームで開発をしているあなたも、散在する情報を整理したいと考えることだろう。 「今、プロジェクトで何が問題になっていて、何を片付けないといけないか」という情報群--ToDoやタスクリストとも表現できるこれらの情報群は、プロジェクト中のさまざまなシーンで出現し、これが管理されていないプロジェクトは、ほぼ確実に混乱に陥る。問題管理で取り扱う情報の種類は
Geekなぺーじ : プログラマのモチベーションを高める9の事項
「Nine Things Developers Want More Than Money」という記事がありました。 面白かったので要約してみました。 誤訳や勘違いがあるかも知れないので詳細は元記事をご覧下さい。 1. 成功するプロジェクトであること 多くのプロジェクトはそもそも失敗するような計画で行われているという悲しい現実があると書いてありました。 成功の要素として、現実的な納期、安物のツールを使うことを強制されないこと、ろくでもないマネジメント・仕様変更・暗黙の仕様 などを要求する発注先にあたらないなどが重要だそうです。 2. すばらしいマネジメントが行われていること プロジェクトと人の両面ですばらしいマネジメントが行われていることが重要だそうです。 身を挺してチームを守るようなすばらしいマネージャに対してはプログラマはソフトウェアの品質で応えるそうです。 3. 新しいことを学べること
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソフトウェア開発の落し穴