イノベーション実践、コンセプチュアルスキル、プログラムマネジメント、プロジェクトマネジメント、PMOについての最先端の情報、研修、セミナー、コンサルティングをお届けします。
![マネジメント / PMstyleコラム](https://cdn-ak-scissors.b.st-hatena.com/image/square/8490ef779a7b159df3813675c80ade093cc3f37f/height=288;version=1;width=512/https%3A%2F%2Fpmstyle.biz%2Fsmn%2Fgif%2Fpmstyle_logo.gif)
ソフトウェア開発者達を育てるには、あなたのリーダーシップのスタイルを変える必要があるかもしれない。彼らは、一般的なマネジメントでは必ずしも輝かないのだ。何が一番重要か?前もってはっきりとした予測を立てる事、そして問題になる前に作業習慣の違いを考慮しておく事だ。 我々はYoung Entrepreneur Council (YECの11人の起業家達に、彼らが開発者を管理する上で経験したリーダーとしての大失敗と、同じ間違いを避けるためのコツを共有してもらった。彼らの回答は以下の通りだ。 彼らが意見を述べてくれると思い込む事ソフトウェア開発者達が自分の課題やアイディア、あるいは手柄についてさえも話してくれると思い込まない方が良い。多くの開発者達はチーム・ミーティングでこういった情報を進んでシェアしようとしない。開かれた、真摯なフィードバックは常にあなたから要求しなければならない。 自分の努力に対
どんなプロジェクト管理ツールを使うか 「プロジェクトの管理」を目的としたオープンソースソフトウエア(OSS)が、数多く登場しています。プロジェクトを成功させるために、これらのツールを「道具」として効果的に利用でき、そして実際にプロジェクトを効率化できれば、プロジェクトに直接かかわる人々(ステークホルダ)だけでなく、IT業界全体としてもメリットのあることでしょう。 最近のIT業界、特にソフトウエア開発のプロジェクトでは、まだまだデスマーチが繰り広げられているのが現実で、限られた期間で開発プロジェクトを予定通り完遂することは、相変わらず難しいことであるというのが実感です。そこで、プロジェクトを成功させるためには、失敗する原因をいかに排除していくかということを考えていく必要があります。 図1に示すように、プロジェクトの成功を支える要素としては、いくつか重要なものがあります。これらの要素が十分に考
困難にもめげず目標を達成する人と、物怖じしてしまう人。才能や技術がそれほど違わないと考えた時、この二人を隔てるものはなんでしょうか? 最初にことわっておくと、私はどちらかというと物怖じして、なかなか思い切りがつかないタイプです。でもたまにうまくいくこともあって、どうしてその違いが起こるのか興味があります。 今はちょっといろいろ自信をなくしているところでもあるので、自分に強壮剤を注射するつもりでこの手の話題を探していたら、Psychology Today に「目標を達成する人はどのように考えるのか」という記事が掲載されていました。 読んでいると最初少しへこんできますが、あまり自己批判的にうけとらずに、ベースとなる考え方を読み取ってみてください。小さなヒントがみえてきます。### 目標達成型の思考と、失敗回避型の思考の違い 困難に負けずに目標を達成するタイプの人を目標達成型とすると、物怖じした
社内向け開発標準の整備を手掛けるNECソフトの増田浩氏(生産技術部 経営品質推進シニアエキスパート)は,たびたび発生する赤字プロジェクトに危機感を募らせていた。プロジェクト計画に作業の抜け・漏れがあり,それが引き金となって赤字プロジェクトに陥るケースが目立っていたからだ。 例えばあるプロジェクトでは,当初の計画において移行時のマスター・データの作成作業が漏れていた。担当するプロジェクト・マネージャ(PM)は,ユーザー側で用意するものと考えていたのだ。移行フェーズに入って,PMがマスター・データの作成をユーザーに尋ねると,「こちらの予定にそんな作業はなかった。てっきりそちらがやるものと思っていた」という答えが返ってきた。結局,ベンダー側で追加メンバーを投入して難局を乗り越えたが,新たな人件費が発生し,コスト超過に陥った。 増田氏は「実施すべき作業内容を規定したWBS(Work Breakdo
Copyright© 2010 RENTACO. All Rights Reserved. RENTACORAC0122A2 PMBOKとCMMIから学ぶ プロジェクト管理手法 2010年8月 株式会社レンタコーチ http://www.rentaco.jp/ Copyright© 2010 RENTACO. All Rights Reserved. RENTACORAC0122A2 講座概要 受講対象者 ソフトウェア開発のプロジェクトマネージャ又はリーダー ソフトウェア開発のチームリーダー 習得事項 PMBOKとCMMIの概要と違い プロジェクトフェーズに沿った基本定石 立上げ、計画、実行、監視制御 フェーズ横断的に実施する基本定石 リスク管理、ステークホルダー管理、要員管理 関連講座 PMBOK概説 CMMI概説 逐次完成型EVMを活用する進
「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する。 SEはさまざまな文書を作成する必要があります。その中でも、提案書や要件定義書の作成に悩むSEは多いようです。なぜなら、これらは「顧客に読んでもらわなければならない文書」だからです。 本連載では、「誰にでも分かる」提案書や要件定義書を作成するための文章術を解説します。ただし、分かりやすい文書を作成するには、文章術だけでは十分ではありません。必要な情報を顧客から引き出すためのコミュニケーション、文書全体の構成も重要です。 第1回では、SEが作成する文書はどのようなものかを概観します。第2回では、情報を引き出すための顧客とのコミュニケーションのポイントを説明します。第3、4回
他の文書と同様、要件定義書はまず文書全体のアウトライン(骨格、構成)をしっかり作り上げてから内容を記述します。今回は、読みやすく分かりやすい要件定義書にするためのアウトライン作成方法を紹介します。 階層構造で読みやすい文書にする 要件定義書を作るためには、全体を大見出し=中見出し=小見出し(章=節=項)の階層構造にします。 「大見出し」「中見出し」「小見出し」の数を、それぞれ5から10程度にするのは、前回(第3回「分かりやすい提案書はアウトラインが美しい」)紹介した提案書と同様です。見出しの数が多すぎると、読み手が文書の全体像を把握できなくなります。また、1つの項目の記述量を1ページ内に収めるようにします。 要件定義書を構成する項目 要件定義書に必要な大見出しの項目としては、次のようなものが挙げられます。 システムの概要/システムの構想 機能要求 入力要求と出力要求 システム導入後の業務フ
なぜ、彼はPMになったのか ピクシブ株式会社が運営するイラストの投稿に特化したソーシャル ネットワーキング サービス「pixiv」は、2007年のサービス開始以来、着実に規模を拡大し、2014年7月末現在、会員数1100万人、月間PV数38億、投稿作品総数4700万を誇る一大人気サービスへと成長している。 そのピクシブにおいて開発マネージャーを務める小芝敏明さんは、過去にPM(プロジェクトマネージャー)への道を避けて転職した経験を持つ。そんな彼がピクシブでプロジェクト管理を担当するようになったのは、なぜだろうか。 小芝さんの転職体験は、エンジニアのキャリアパスに必ずと言ってよいほど付いて回るマネジメントという職務について考えるよい機会になるだろう。 【転職者プロフィール】 小芝敏明さん(33歳) ピクシブ株式会社 開発マネージャー(2013年11月入社) 【転職前】 金融機関向け基幹システ
第1回 プロジェクトで必要とされるスキル #プロジェクトマネージャー ここからは、PMを志望している人達向けに、PMとして要求されるスキルにはどんなものがあるか、そして、スキルアップしていくにはどうすれば良いか、についてお話します。 PMには、マネジメントスキル、リーダシップ、ニーズをまとめるスキル、アーキテクトスキルなど多様なスキルが要求されます。しかし実際には、プロジェクトの規模や性格やPMの立場によって、あるいは顧客企業の性格(端的に云えばお客様の性格)によってPMに要求されるスキルは違ってきます。 プロジェクトの規模が小さいと、PMは技術系のリーダやアプリケーションの開発リーダを兼ねることがあり、業務知識や技術知識が要求され、業務アプリケーションの仕様詰めに自ら率先して参加しなければならないこともあります。反対にプロジェクトの規模が大きくなると、PMは複数のサブチームから構成される
前回,タスクかんばんが,現在の状況を見える化するものであり,先を見通すような視点は持ち合せていないことを説明した。この「先を見通す視点」で「進ちょく状況の見える化」を実現するのがバーンダウン・チャートと呼ばれるチャートである。バーンダウン(burn down:燃え落ちる,全焼する)チャートは,一般的なチャートにありがちな右上がりではなく,右下りになっている。チャートを作成する際には,縦軸に残りの作業量を,横軸に時間を割り当てて日々の残り作業量をプロットしていく。右下,つまり残り作業量がゼロ(=全焼)になれば,すべての作業が完了するというわけだ。 バーンダウン・チャートは,元々リリースまでのバック・ログ(プロジェクトとして実施する必要があるすべての作業)の残量を視覚化するチャートだったが,現在はイテレーション単位でのタスクの残作業量(デイリー・バーンダウン・チャート)の見える化にも使われてい
「開発支援ツール徹底調査2013」の結果を参考に、この数年の間にIT現場の必須ツールとなると予測し、この三つを選んだ。いずれもオープンソースソフトで、手軽に導入できる。現場のツール活用を進めてほしい 日経SYSTEMSはこれらを、IT現場の「新3種の神器」と定める。いずれも本格的な普及はこれからという段階だ。しかし、統合開発環境(ビルドツールを含む)やソースコード管理ツールが今どのIT現場でも使われているのと同じように、Redmine、Jenkins、Chefも数年の間に必須のツールとなると予測する。システム開発に携わる読者のみなさんに、早くこれらを活用することを勧めたい。 導入の勢いでRedmineがトップ 聞いたことがないという読者の方もいると思うので、Redmine、Jenkins、Chefについて順に説明しよう。なぜ新3種の神器とするのかも併せて解説する。 Redmineは、PMツ
土木建築の作業工程や製造業の生産工程、プロジェクト作業などの手順(タスクやアクティビティ同士の依存関係、時間的従属関係)をネットワーク(有向グラフ)の形状に表した図のこと。スケジュール計画立案や工程短縮の検討などに利用される。土木建築の世界ではネットワーク工程表、プロジェクト管理ではプロジェクト・ネットワーク図、あるいはPERT図などとも呼ばれる。 PMBOKなどのプロジェクトマネジメント技法では、まずWBSですべてのアクティビティを洗い出し、各アクティビティの関係をネットワーク図で明らかにしてそれを実際に行う順序を定めるという形で、プロジェクト・スケジュールを計画する。 一方、クリティカルチェーン・プロジェクトマネジメントではあまり詳細に工程を分解せず、工程の後ろ(最終成果物)からネットワークを作成することを推奨している。 大別すると、AOA法とAON法の2つの表記法があり、現在では後者
QUICKTRANSLATE says ...... スピード翻訳 オフィシャルブログ : サービスのことだけでなく、翻訳や言語にまつわるちょっとした話題をお届けします こんにちは、maggy です。最近、海外で行われるイベントの準備や PR の仕事に関わっているのですが、企画書、プログラムやポスターの草案といった英語の資料の山に目を通したりと、てんやわんやの日々を送っています。 さて、講演の登壇者リストに目を通していたら、こんな一行を発見しました。 Mr XXX (TBC) 「Mr XXX」は恐らく誰かの名前でしょうが、さて、このカッコ内は? エステの会社の人……が来るわけもないイベントなのですけれど。一体何者なんでしょう。 さらには、別の人からの草案にも、こんな一行が……。 “Untitled” (TBD) 似たようなのが出てきて、一層に謎めいています。 気になったので、これらの「TB
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く