なぜ人は思い通りに動かないのか（第2回）：日経ビジネスオンライン
気になる記事をスクラップできます。保存した記事は、マイページでスマホ、タブレットからでもご確認頂けます。※会員限定 無料会員登録 詳細 ｜ ログイン ■シリーズ記事 第1回「相手を説得できない――交渉下手は日本人の遺伝子？」 第3回「他人に合わせてしまう――自己と集団の間にある葛藤」 「3人寄れば文殊の知恵」ということわざがあります。1人で考えるよりも、何人もの人々が寄り集まれば、何倍もの知恵が出てくるというものです。果たして本当なのでしょうか。 もし本当ならば、大勢が集まる会議で意見を出し合えば、素晴らしいアイデアが出てくるはずです。しかし、実際にはそうではありません。会議は時間がかかるばかりで、その場で目覚ましいアイデアが出てくるようなことはあまりありません。1日に何度も会議に出席するような方々は、会議の結果が必ずしも望ましいものばかりではないことが骨身に染みていることでしょう。 「集
すごいKPT事後評価セッション
すごいKPT事後評価セッション 先週納品を終えてほぼ完了したプロジェクトについて、冷めないうちに事後評価セッションを行う。 「適応型ソフトウェア開発」に触発されて去年から主に自分の担当プロジェクトで導入しているセッションであるが、今回はこれにすごい会議の手法と、@ITの記事*1で紹介されていたKPT法を組み入れて実施してみた。 招待状 参加者には、以下の事前準備をメールでリクエストしておいた。 「あなたが、この会議で達成したい事を考えておいてください。」(すごい会議流) 各評価対象について「3つの成功点(良かった点)、3つの失敗点」を事前に考えてください。 (「適応型ソフトウェア開発流」) スコープ、スケジュール、リソース、欠陥レベル プロジェクト運営 コラボレーション (スタッフ間) 個人・チームとして学習した点 その他 (開発手法など) 問題点については「どのようにすれば〜(だろうか)
Microsoft Project Server 2007 実践セミナーに行ってきました: ある SE のつぶやき
Microsoft, 初めて使う、Project Server 2007 実践セミナー 日時：2007/03/09 10：00～17：00 場所：新宿住友ビル 今日は、Project Server 2007のセミナーに行ってきました。 現在は、Project Server 2003を使っているのですが、Project Server 2007で何が変わったのかということと、MS Project自体を使いこなせていないこともあり、情報収集も兼ねて行ってきました。 Project Server 2007で変わった点で、ほぅと思ったものメモ。 アーキテクチャーが大きく変わった Windows SharePoint Services (WSS)が必須になった サーバ側でスケジュールエンジンを実装した これで、進捗の承認時にProjectが起動しなくなる これはうれしい クライアント機能 Und
不完全なコードは推敲フェイズで潰しておきたい/プロジェクトの状態を評価する：パート2（前編）
本稿は、ソフトウェア開発プロジェクト管理の一貫としての評価戦略を解説する3回シリーズの第2回である。本シリーズの第1回「プロジェクトの状態を評価する：パート1」（翻訳記事「プロジェクトのはじめに計画を立てるのは無謀」）では、プロジェクトの健全性を評価するメカニズムとしての評価の概念を紹介し、「方向付け」フェイズにおいてプロジェクトの健全性評価に役立つ具体的な評価値について解説した。第2回は、「メインとなる」開発作業である「推敲」と「構築」の両フェイズの評価に焦点を当てる。 推敲と構築の両フェイズには、同様の評価アプローチへとつながる多数の類似点がある。いずれのフェイズも、主眼はシステムに望まれる機能を漸次インプリメントして増やしていく実行イメージの作成だ。両フェイズの最大の違いは、それぞれが取り組むリスクの違いに起因している。推敲フェイズは、ソリューションのアーキテクチャに影響を与える技術
ディスカッションテーマのおもちゃ箱（2）
前回に引き続き、情報システム企画やプロジェクト計画の段階における問題を中心に、仲間同士や上司と部下の間で行うディスカッションのテーマを集めてみた。今回は、プロジェクト管理（特にその基礎になる進ちょく管理）に関する問題を取り上げた。 前回から少し間が空いてしまったので、少し「なぜディスカッションなのか？」というおさらいをしておく。 昨今、多くの企業において、IT要員の企画力やプロジェクト管理力の能力開発が大きな課題になっている。しかし、企画や管理といった「概念構成力の占めるウエイトが大きい」これらの能力分野では、系統的に知識を覚える・理解するといった勉強では、なかなか実践に結び付く能力レベルには至らない。 また、「漫然と経験を積む」という方法で能力が向上するという問題でもない。意識と知識と行動を結び付け、脳を活性化させる方法が求められる。この観点から、OJTと併せ、オフJTとして、ディスカッ
＠IT Special：フローの重視～「Visual Studio Team Systemで実践するソフトウェアエンジニアリング」
フローに基づく計画とプロジェクトマネジメントの手法では、中間工程の進行中作業（Work in Process）を最小限に抑えることが求められる。そうすることで、問題の発見が遅れたり、想定外のやり直し作業が突然発生したりするリスクが軽減されるからだ。そしてフローを継続的に測定するとボトルネックの形成が明らかになる。 本記事は、日経BPソフトプレス社が発行する書籍「Visual Studio Team Systemで実践するソフトウェアエンジニアリング～成功する開発プロジェクト運営のために～」の第1章 1.3「フローの重視」を、同社の許可を得て転載したものです。 本書は Visual Studio Team System の開発チームにおいてプロダクト プランナーを務めた Sam Guckenheimer が Juan J. Perez と共著で書き記した書籍です。本書ではそもそも Visua
＠IT Special： 相対立するパラダイム～「Visual Studio Team Systemで実践するソフトウェアエンジニアリング」
プロジェクトマネジメントの不確実性を管理する手法として、従来の「ワークダウン手法」に代わり広がりつつあるのが「バリューアップ手法」だ。バリューアップ手法では、各時点での提供価値を測定し、入力情報を固定的集合ではなく可変フローと見なす。両者の違いを解説しよう。 本記事は、日経BPソフトプレス社が発行する書籍「Visual Studio Team Systemで実践するソフトウェアエンジニアリング～成功する開発プロジェクト運営のために～」の第1章 1.2「相対立するパラダイム」を、同社の許可を得て転載したものです。 本書は Visual Studio Team System の開発チームにおいてプロダクト プランナーを務めた Sam Guckenheimer が Juan J. Perez と共著で書き記した書籍です。本書ではそもそも Visual Studio Team System という
【コラム】Yet Another 仕事のツール (98) プロジェクト管理を効率化しよう - GanttProject | エンタープライズ | マイコミジャーナル
仕事には大抵、「納期」というものが決められている。このコラムにも「締め切り」という名の納期があり、毎週火曜になると、容赦なく担当編集O氏からの催促がメッセンジャーのウィンドウにポップアップする仕組みになっている。 納期というのはつまり、顧客に対して「これこれこういう仕事を、いついつまでに終わらせますよ」という約束である。約束を守らないとどうなるか。当然信用を失い、仕事を切られ、最悪の場合は失職して路頭に迷うハメになるのである。だから我々社会人は、どんなに辛くとも苦しくとも、なんとかして納期を守ろうと努めるわけだ。 が、原稿書きのような個人的な仕事ならば進捗は自らの努力次第だが、企業の仕事というのは、その大半がもっと大規模で複雑なものである。仕事の規模が大きくなれば、比例してプロジェクトを構成する要員の数も増える。人が増えればそれだけ、個々の担当する業務の進捗を厳密に管理する必要が出てくるの
プロセスはITプロジェクトにとって最善の策とは限らない | OSDN Magazine
ITプロジェクトの成功には、優良で、繰り返し行なうのに適していて、確固とした「プロセス」（工程、マニュアル）が必要不可欠だ。確固としたプロセスがあるからこそ、プロジェクトというパズルの各ピースが組み合わさり、全体として一つのアウトプットを出すことができる。プロセスがあることによって仕事が毎回同じ方法で進められると期待することができ、それによってチームのメンバーや顧客は、何かが欠けている可能性を心配する必要もなく、信頼性が高く実用的で使い物になる結果を得ることができると確信することができる。 しかしその一方でプロセスが過度に厳格である場合や不十分な構成である場合やコスト/スケジュール/品質にマイナスの影響を与える場合など、プロセス自体がむしろ思わぬ落とし穴となっている場合もある。以下では、プロセスを敵ではなく味方に付けるための定番で実用的なアイデアを紹介する。 ITの世界におけるプロセスの利
Andres' thoughts - Top ten things ten years of professional software development has taught me
Edit: My old server didn't really have the power to feed all the visitors. This is a static copy of the blog post. Unfortunately, no comments can be accepted. I was reading this top ten list yesterday, and I thought I can problably come up with my own list of things no-one told me before I started developing software for money. This is my list. Object orientation is much harder than you think May
できるPMの決め手は「リスクマネジメント」
メディア 連載一覧 連載まとめ読み＠IT eBook 記事ランキング ＠IT Special セミナー ホワイトペーパー クラウド AI IoT アジャイル/DevOps セキュリティ キャリア&スキル Windows 初・中級者向けAI その他 Server & Storage HTML5 + UX Smart & Social Coding Edge Java Agile Database Expert Linux ＆ OSS Master of IP Network Security & Trust System Design Test & Tools Insider.NET ブログ AI for エンジニアリング ローコード／ノーコード クラウドネイティブ Windows 11/365 その他の特集 ＠IT 自分戦略研究所 スキル創造研究室 できるPMの決め手は「リスクマネジメント
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発プロセスメモ - nDiki
High Availability Cluster Software - in Cloud or On-Premises | SIOS
笑わないプログラマ - 【軍曹が】携帯電話開発の現状【語る】
「リスクは上から3つだけ潰す」とツタヤで学ぶ (3ページ目)：日経ビジネスオンライン
http://unpan1.un.org/intradoc/groups/public/documents/unssc/unpan026017.pdf
Feature Driven Development : towards a TOC, Lean and Six Sigma solution for software engineering
女性ITマネジャーの告白Part2 バックナンバー｜転職応援サイト イーキャリア
6 Great Ways To Rid Yourself of Good Developers
プロジェクトの遅延を防ぐ(1)
