生産性が高いエンジニアを評価するための２つの仕組み - レベルエンター山本大のブログ
仕事ができるプログラマって、できないプログラマに比べて「１０倍」も生産性が高い。とか言う話がありますよね。 僕も体感的に、本当にできるエンジニアは本当に生産性が５倍とか１０倍とか変わることを見てきました。 でも開発の現場では「残業しまくってる」ほうが、なんだか仕事してるように見えてしまう。 そんな中で久々にこの記事を目にしました（漫画なので1分ぐらいで読めます）。 ■「残業しないで帰るSEってやるきないんじゃない？」 http://next.rikunabi.com/tech/docs/ct_s03600.jsp?p=000800 2006年の記事ではありますが、こういう話って普遍的なので古くもありませんね・ 残業しないで定時に帰れるって評価するべきだし、残業をせず家庭を大事にする社風にしたい。 すごく生産性が高いっていうエンジニアを評価したい。 でも残業してるのって分かりやすいから評価さ
炎上プロジェクトの責任はプロマネが９割 - プロマネブログ
サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ 前回からの続きです。 以下、３部作の３本目となります。 ウォーターフォール開発とアジャイルの本質 - プロマネブログ サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ 炎上プロジェクトの責任はプロマネが９割 - プロマネブログ 追記)ブコメで誤字の指摘がありましたので、訂正します。。。お恥ずかしい NetPenguinさん、ご指摘ありがとうございます 改めて考えたいプロマネの仕事 プロマネの仕事とは、PMBOKのプロジェクト管理に関する観点をマネジメントする、と言えます。 統合 ・・・ チーム内の意思統一 スコープ ・・・ 目標、成果決定 タイム ・・・ 期限、スケジュール管理 コスト ・・・ 予算、費用管
プロジェクトマネジャーのための「プロセス設計術」
知識、技術、経験がいずれも豊富なエンジニアを多数抱えていても、プロジェクトはいとも簡単に失敗してしまいます。その根本原因は「プロセス」にあります。本連載は、主にプロジェクトマネジャー（PM）を対象に、プロセスとはどんなもので、どのように設計し、どうプロジェクトの成功につなげればいいのかを中心に分かりやすく解説します。 目次 プロジェクトコンサルタント。大手ソフトウエアハウスで長年、自動車部品メーカーや大手エレクトロニクスメーカーのソフトウエア開発に携わる。品質と納期が絶対の世界に身を置き、現場のリーダーとして100人以上の開発者を統率してきた経験を基に、プロセス設計からプロジェクトマネジメントに展開する独自のコンサルティングアプローチを編み出す。「品質は設計を超えることはできない」という信念のもと、「人と組織の実行品質を高める」ことを主眼に置いたコンサルティングを実践している。コンサルティ
リーダー不在で数万匹が整然と動く--昆虫の驚異に学ぶ組織を動かすシンプルなルール
大企業の硬直化した組織に、どうしようもない制度疲労を感じる人は多い。上層部に指示系統が集まる統制型組織では、絶えず変化する外部環境に対応できないからだ。不確実な時代には、変化に直面している現場社員が、自らの判断で行動できる組織が向いているのだ。 しかし、統制力の弱い分散型組織は、一歩間違うと放任状態に陥ってしまい、組織として機能不全に陥ることが多い。分散して権力を持つ人々を動かして、共通の目的を達成するためには、統制に代わるなんらかのメカニズムが必要だからだ。 では、分散型の組織を有機的に機能させるためのポイントは何なのだろうか。ここでは、はるか悠久の彼方から究極の分散型組織を実現させている社会性昆虫の世界を探訪し、その極意を学んでゆきたい。 小型戦略と多様化戦略に支えられた昆虫の隆盛 昆虫は動物種全体の6割を超え、地球上で最も繁栄している生命だ。恐竜は身体を、人類は頭脳を巨大化することで
三点見積もり | iseeit.jp 情報通信技術
『情報通信技術』に関するスキルのほかに、『情報セキュリティ』に関するスキルも重点テーマです。また、特に今後の『高速モバイル通信』と『インターネット』に注目していきます。 三点見積もりは、次の３種類の値から算出するものです。 最頻値 実現可能性が最も高いスケジュールアクティビティの所要期間またはコストの見積り値（見込み値）。 楽観値 最良のシナリオで実現されるスケジュールアクティビティの所要期間またはコストの見積り値（見込み値）。 悲観値 最悪のシナリオで実現されるスケジュールアクティビティの所要期間またはコストの見積り値（見込み値）。 三点見積もりについては、PMBOK®第３版では、主に、第６章のプロジェクト・タイム・マネジメントと第１１章のプロジェクト・リスク・マネジメントで取り上げられています。 一般に、次のような計算式が使われます。
スケジュールを立てられないとは
「『スケジュールを立てられない』なんて人が居るんだ！」と思っていた時代が僕にもありました。 何時までに、何をやるかが解れば、あとはそれをタスクに分解して、掛かる時間を想定して、先行タスク・後行タスクを考慮して並べれば、スケジュールを立てるまではできるよね。 実際にそのスケジュールを守っていくのは大変だけど。 なのにそれができない人が居るんだ！と驚いてた。 この4月に新しい職場に異動したんだけど、そしたら、なんと自分がその「スケジュールを立てられない」人になって驚いた。 上司からは「何時までに、何をやるかを並べて、問題点とか出してけばスケジューリングできるだろ！」とずっと怒られた。 その指摘はすごくもっともだから何とかしようと思った。 上司は僕のことを「『スケジュールを立てられない』人がいるなんて！」って見てるなと思った。 でもスケジューリングができなかった。 「何とかしなきゃ」と気ばかり焦
ScaleOut | Supership
「ミライリアルの幸せを、デジタルの力で創る」ことを目指すSupershipグループの社内報です。日々の出来事、メンバーの働く様子や声、未来への想いなど、Supershipグループの”Be Super”なストーリーをみんなでシェアしていきます。
CCPMの考え方 - プログラマの思索
CCPM（Critical Chain Project Management：クリティカル・チェーン・プロジェクト・マネジメント）の解説記事があったのでリンクをメモ。 【元ネタ】 CCPM とは：梅田弘之のプロジェクトマネジメント講座：【第６章】大型プロジェクトにはCCPMを取り入れよう サルでもわかるTOC/CCPM(第五回)｜ザ・プロジェクトマネジャーズ TOC流の開発型プロジェクト管理術「CCPM」（1）：なぜプロジェクトの進行計画はいつも壊れるの？ 「クリティカルチェーン・プロジェクトマネジメント」とは (1/3) - MONOist（モノイスト） TOC流の開発型プロジェクト管理術「CCPM」（2）：PDCAサイクルに潜むプロジェクト管理の問題点 (1/3) - MONOist（モノイスト） TOC流の開発型プロジェクト管理術「CCPM」（3）：TOCのPMが本当に管理すべきポイ
ソフトウェア開発の「新」3種の神器 - プログラマの思索
ソフトウェア開発の「新」3種の神器に関する記事を見つけたのでメモ。 日経Systems2013年6月号に掲載されている。 【元ネタ】 記者の眼 - 「新3種の神器」で開発現場を改革しよう：ITpro 記者の眼 - 「新3種の神器」で開発現場を改革しよう：ITpro 記者の眼 - 「新3種の神器」で開発現場を改革しよう：ITpro 【1】興味深いのは、アンケート結果では、「「Microsoft Project」（MS Project）で48.7％、2位はオープンソースソフトウエア（OSS）の「Redmine」で40.4％、3位も同じくOSSの「Wiki」で32.4％だった」こと。 他に、TracやTFSも上位に上がっている。 日本でRedmineの人気は高いのが意外だった。 Redmine 2.3新機能紹介: ガントチャートでチケット同士の関係とイナズマ線を表示 | Redmine.JP B
技術的負債を管理する
日付2013-5-18(Sat) 書いた人おかざわ (id:yujiorama) 書いた理由技術的負債はいつ読んでも面白いんだけどそろそろ普通に向き合いたくなったので。 技術的負債を管理する 技術的負債は悪いものとみなされている。避けるべきものであり、できるだけ早く支払うべきものなのだ。 あなたもそう思うだろうか？私たちはそうは思わない。最初に技術的負債と財政的負債を比較して、戦略の設計とステークホルダーにおける類似点について驚くべき点があることを説明する。それからコード中の技術的負債を識別するための様々な可能性について一覧にする。それらはきっとあなたが対処しなければならないものだ。 最後にプロジェクトが技術的負債を返済するために取りうるいろんなやり方について述べる。あなたが返済したほうがよいのか、負債を変換するほうがよいのか、ただ注意を払うだけでよいのかを考える時にきっと役に立つだろう。
チケット駆動開発で作業管理はしないほうがいい - arclamp
先日、2013/3/23（土）に弊社でチケット駆動と開発環境に関するイベントを開催しました。リンク先には資料も上がっていますので参照ください（※アトラシアン製品関連のイベントです）。 基調講演にはチケット駆動開発を推進されている関西XPUGのあきぴーさんをお招きして「チケット駆動開発をパターン言語で読み解く」という話をしていただき、最終枠ではパネルディスカッションをしました。 チケット駆動開発とウォーターフォール パネルディスカッションでは、僕が「チケット駆動開発を作業計画に使うのは難しく、WBSとの併用が現実的」と話し、あきぴーさんが「作業計画をチケット駆動開発で回していくには」というノウハウを紹介されていました。 この違いは僕がウォーターフォール的な新規案件を、あきぴーさんがアジャイル的な開発/保守運用案件を前提にしているためです。 僕自身はBTS（Bug Tracking Syste
CCPMを使って組織にアジリティを注入するのは冴えたやり方 - 勘と経験と読経
先日公開された「NTTデータはどうやってCCPMを導入したのか？」という資料を見ての感想。アジャイルという言葉を前面に持ってこずに、しかし結果として主にスクラムを中心としたプラクティスを現場に注入している(ような気がする)。CCPMを使って組織にアジリティを注入するのは冴えたやり方だなぁと思った。 そういえば、技術士の二次試験の口頭試問で自分のプロジェクトの進め方を説明した時に試験官から「制約理論を勉強されたのですか？」と聞かれたことを思い出した。自分としては(制約理論は知っていたけれども)プロジェクトの特性に合わせてアジャイルプラクティスをつまみ食いして運営していたつもりだった。結果としてCCPMに近いことをやっていたのかもしれない(ごっちゃになっていたのかも)。 部分最適が現場を悲惨にしている 制約理論(TOC)というとピンと来ないかもしれないが、10年以上前にベストセラーになったゴー
WBS は、作業分解構造ではないのよ。 - haradakiro's blog
ちょっと大人数で行うプロジェクトに参加したことがある人なら、WBS (ワークブレークダウンストラクチャー) を目にしたことがあるだろう。 日本語だと作業分解構成と説明されることが多い。Work(作業) Breakdown(分解) Structure(構造) というわけだ。日本語の説明では、そういう説明が主流のようだ。 でも、WBS の Work は実は作業ではない。 WBS を定義した標準の最新版MIL-STD-881Cを見てみると、"A product-oriented family tree composed of hardware, software, services, data, and facilities." 「WBS の定義は、ハードウェア、ソフトウェア、サービス、データ、設備などからなる成果物指向の分解ツリーである。」 ここでいう Work は、成果物のことだ。Workb
時間の見積もりをどうするか？ －「仕事が忙しい！」の9割は思い込みだった【2】
完璧にスケジューリングしたつもりなのに、なぜいつも時間が足りなくなるのか。それは時間リスクの見積もりが甘いからです。 仕事の計画を立てるとき、万が一に備えて手は打ってあると胸を張る人は少なくありません。しかし、その多くは危機（ハザード）管理であって、リスク管理でないことに気づいていない。 ハザードとは、災害や事故といった事態のことであり、危機管理ではハザード発生時のリカバリーに主眼が置かれます。一方、リスクはハザードと違い、日常の中で予定どおりに進まない可能性があるものすべてを指します。たとえば「仕事中に突然、顧客が来訪する」というイベントは、けっして災害や事故ではありませんが、日常的で不確実という点では立派なリスクです。時間のリスク管理とは、こうしたイベントを事前に把握してマネジメントすることをいいます。 普通に仕事をしていれば、さまざまな時間リスクに出合います。「いざ外で仕事をしようと
過剰品質に関する西先生と秋山さんのツイートをまとめ
Yasuharu NISHI @YasuharuNishi こないだSECの品質監査制度の偉い人が「日本は過剰品質なんですよ」と言っていた。でもそれは、間違った品質管理をやり続けた結果に過ぎない。その結果だけをみて過剰だから止めよう、と品質管理活動を止めると、すぐに致命的なまでに品質は低下する。過剰品質という表現は、とても危険なのだ。 2012-09-06 11:06:32 Yasuharu NISHI @YasuharuNishi 過剰品質論を振りかざす人たちが見ている現場は、間違った品質管理活動をたくさんしている。それは、顧客満足にも、技術力向上にも、生産性向上にも役立たない、自己目的化したエセ品質管理だ。その間違いを端的に表現する言葉はないだろうか、とずっと考えていた。 2012-09-06 11:08:09 Yasuharu NISHI @YasuharuNishi 過剰品質なので
ChiliProject - Homepage - ChiliProject
Latest Release¶ 3.8.0 (2013-03-19) 2.11.0 (2013-03-10) Live Demo Next Release¶ 3.9.0 Get ChiliProject¶ Download Official Files Github repository Installation Upgrade Using it¶ FAQ Why Fork? Using ChiliProject Plugins Developing for it¶ Contribute Development Teams Donate Wiki Start page Index by title Index by date ChiliProject is not maintained anymore. Please be advised that there will be no mor
ソフトウェア開発におけるムダ | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 Alan Shalloway氏のWastes of Software Developmentが良い記事でしたので、抜粋・意訳にてご紹介します。 僕のトレーニングではいつもトヨタ生産方式の話やStandishのレポートの話をしています。 7つのムダのうち特に作り過ぎのムダをなくすことはとても重要で（もちろんほかも重要）、これがないと頻繁に継続的に顧客に価値あるフィーチャーを届けることはできなくなるからです。 さらに開発のプロセスの中で、常にどこにムダがあるのかを考えて改善していくことはチームに課された責任でもあります。 例えば思いつく限り以下のようなものはムダです。 使わない機能たくさんのオプション設定読まない仕様書読まない報告書やたらと体裁にこだわった文書更新されない文書目的のない会議決定事項が守られない会議遅いPC小さいディスプレイ行動の監視目的
過剰チェックの悪循環からいい加減脱出しませんか、あるいは思考停止の罠：プロジェクトマジック：オルタナティブ・ブログ
★1つミスが起こると1つチェックリストが作られる SEとしてシステム開発にいそしんでいた頃、何かミスが起こると対策会議が必ず開かれていた。マジメな会社だったので。ミスの種類は色々で、本番システムを止めてしまったとか、計算が間違ってしまったので数字の修正が大変だったとか。 対策会議なので、毎回なんらかの対策を講じなければならない。課題への対策を考えだすのは本来、とてもクリエイティブな仕事である。だって、誰もが思いつくような対策があるならば、とっくに実行されているはずだから。 でもキラキラしたひらめきが毎回あるわけはなく、大抵何らかのチェックリストを作ろう、ということが決まって対策会議がお開きになった。 不幸な誰かにそれを作る仕事が押し付けられる。 ★過剰チェック施策の悪循環 僕が言うまでもなく、チェックリストは非常に有効なツールである。僕らの会社ではプロジェクトの方法論を大事にしているが、方
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PMBOK vs PRINCE2 vs Agile project management | CIO
Redmineチケットによるプロジェクト火消し戦略！
