■「計測できるものは改善される」、この名言の情報について。…
■「計測できるものは改善される」、この名言の情報について。 「管理されていないものは測定できない。測定されていないものは改善できない」 「計測されないものは、改善されない。」 「測定できないものは管理できない」 「測定できないものはコントロールできない」 「測定できないものは改善できない」 …各々の解釈によって上記以外にも多くの表現がありますが、 この言葉の原型、またもともとの出典（またはこの名言の主）を ご存じの方はいらっしゃいますか？ 出典もドラッカーなどさまざまで不明であります。 好むニュアンスの言葉なので、興味があります。 もし情報をお持ちの方がいらっしゃいましたら、 ご教授いただけますと幸いです。
MRJ計画失敗、技術者が「謙虚さに欠けていた」 元社長が激白 破綻の原因はたった1枚の書類
愛知を拠点に三菱航空機が開発していた国産初のジェット旅客機、MRJ。ニッポンの航空産業の中核として量産化が期待されていましたが2023年2月、ついに計画の中止が発表されました。 夢の開発プロジェクトがなぜ頓挫したのか。三菱航空機の元社長の川井昭陽氏が、当時の胸中を明かしました。 【動画・元社長が激白】MRJ計画失敗、技術者が「謙虚さに欠けていた」破綻の原因はたった1枚の書類 三菱重工が国産初のジェット旅客機として開発を決めたのが「三菱リージョナルジェット（MRJ）」です。 100席以下の小型機ながら、部品点数は車の30倍にあたる約95万点。県営名古屋空港を開発拠点にした夢の国産ジェット旅客機の生産は、この地方に新たな基幹産業の誕生を期待させるものでした。 しかし度重なる設計変更で、プロジェクトは6度にわたって計画延期。2019年には名前から三菱の“Ｍ”の文字も消えました。そして2023年2
一人前のプロマネってどんな人？ プロジェクトマネジメントのスキルセットとは - 誰も教えてくれないプロマネのコツ
今やあらゆる場面で必要とされるプロジェクトのノウハウを、300件以上成功させてきたプロフェッショナルがこっそりお伝えします。 先日、仕事で関わっている方から、「結局、プロマネって何ができないといけないんですかね？」という質問をされたので、その場でざっくり洗い出してみました。 世の中には PMBOK や ITSS, PRINCE2 などのスキル標準を定めたものはありますが、これらは大規模システム開発を志向しており、概念として抽象度が高いためベースの知識として利用できる環境は残念ながら非常に少ないという現実があります（もしこれらを利用できる環境にいるならとても幸せなことです）。 少なくとも日本で実施される一般的なプロジェクトは PMBOK や ITSS を元に共通認識を整備するどころか、「限られた予算で1年でクライアントのシステムを刷新する必要がある」とか、「社長の思いつきで何も決まっていない
GanttProject 日本語情報トップページ - OSDN
使い方 GanttProjectは簡単なスケジュール管理とリソース管理ができるソフトウェアです。 １．インストール方法 ２．プロジェクトの作成 ３．役割管理 ４．タスクの登録 ５．リソースの登録 使い方を見る ダウンロード 最新ダウンロードファイル ganttproject-3.2.3200.zip (日付: 2022-02-16, サイズ: 38.92 MB) ganttproject-3.2.3200.dmg (日付: 2022-02-16, サイズ: 115.35 MB) ganttproject-3.2.3200.exe (日付: 2022-02-16, サイズ: 110.77 MB) ganttproject_3.2.3200-1_all.deb (日付: 2022-02-16, サイズ: 49.93 MB) README.md (日付: 2022-02-14, サイズ: 6.
エンジニアのためのTrello徹底活用術！ Pairsのエウレカが、プロジェクトの透明性を確立できた理由 - エンジニアHub｜若手Webエンジニアのキャリアを考える！
エンジニアのためのTrello徹底活用術！ Pairsのエウレカが、プロジェクトの透明性を確立できた理由 ソフトウェア開発では、手法やフェーズに応じて適切にツールを使い分けることが重要です。株式会社エウレカが、主力サービスのPairs開発チームで実践しているTrelloを活用したタスク管理のノウハウや考え方を紹介します。 初めまして。株式会社エウレカのCTO Office責任者、梶原成親（@kajinari）です。 エウレカが目指すのは自立・自律した組織。全社でスクラム（Scrum）開発を推進し、強いチーム作りをするのが私のミッションです。 管理ツールもさまざまに使い分けていますが、スクラムに合っていると感じるのは、タスク管理ツールのTrelloです。私はもともとアトラシアンのユーザーグループで、東京代表のオーガナイザーを務めていました。Trelloは、アトラシアンが買収したのを機に使いは
みんなが嫌う「朝会」がプロジェクトマネジメントで大切な理由。 - プロジェクトマネジメントの話とか
前回、匿名で書いた記事 プロジェクトマネジメントで大切なたった3つのこと（記事移転しました） にて「情報共有」の重要性を偉そうに説いてみたところ、反応があったので今回は朝会について考えてみたいと思います。 ※記事は下記の自ブログへ移行しました。（同じ文章なのに、何故ブックマーク数がここまで違うのだろう……） プロジェクトマネジメントで大切なたった3つのこと。 - プロジェクトマネジメントの話とか スポンサーリンク 朝会が嫌われる理由 みんなが朝会に意義を感じられないのは、そもそもやり方がマズイからなんだと思うんですよ。 例を挙げます。 PM「はいAさん、進捗お願いします。」 A「○○が完了して××が30%程度、0.5人日遅延しています。 理由は△△が◎◎で、□□でリカバリーします。」 PM「あれ、何でですか？昨日の話では・・・」 ～15分経過～ PM「はい、次はＢさん、進捗お願いします。」
失敗を学びに変える「障害報告書」の書き方 ─ RettyのCTOがGoogleで学んだ「問題を隠さない文化」 - エンジニアHub｜Webエンジニアのキャリアを考える！
失敗を学びに変える「障害報告書」の書き方 ─ RettyのCTOがGoogleで学んだ「問題を隠さない文化」 人間は失敗するものです。エンジニアもまたしかり。Retty株式会社の樽石CTOが考える、失敗を学びに変える考え方とノウハウを紹介します。 はじめまして。Retty株式会社でCTOを務める樽石将人（ @taru0216）です。Rettyにおける技術の責任者として不確実性の高いシステム開発を成功に導くよう牽引したり、メンバーが働きやすくなるような仕組みづくりを行ったりしています。 子供の頃からパソコンに親しみ、新卒一期生でレッドハットに就職して、Rettyに入社するまでGoogleや楽天を経てきました。エンジニアとして活動して約30年。日々失敗し続けていますし、過去には大規模サービスを止めてしまったこともあります。 人間である以上、バグやエラーは必ず起こるもの。エンジニアは失敗を繰り返
デスマーチが起きる理由/anonymousさんへの回答 - 回答。
デスマーチが起きる理由/anonymousさんへの回答 - 回答。 目次 第一弾 １．作業者の賃金を、固定費として考慮に入れない、としていますが、本当にこれでいいのでしょうか？例えば、会社中から優秀なプログラマを集めて行われたプロジェクトと、新人が一人だけでやったプロジェクト、この二つを同じコストとみなせるのでしょうか？ ２．前の質問と関連しますが、優秀なプログラマを他プロジェクトから引っ張り込んでもマネージャが責任を問われないなら、どのプロジェクトのマネージャも「うちこそ人が足りない！」と主張して、他から引き抜きはやろうとするけれど、自分のプロジェクトの人材を他に提供するようなことを許そうとはしないのではないでしょうか？ ３．プロジェクトの進捗への貢献度によって人を評価する、とのことですが、技術的な知識のないマネージャが、その貢献度を正しく評価できるのでしょうか？評価基準はコードの生産量
デスマーチが起きる理由 - ３つの指標
デスマーチが起きる理由 - ３つの指標 目次 このページの更新履歴 デスマーチとは リンク wema デスマーチ 制約理論(Theory Of Constraints, TOC) このページから派生したページ コメント ３つの指標 鳥のさえずり声を聞いて、私は悪態を吐いた。今日の早朝に予定されていたミーティングのことをすっかり忘れていたのだ。 まったく、最悪の朝だ。着替えている間に、電話も鳴った。「高い金を払ってコンサルタントを雇った極めて重要なミーティングだ」と念を押されていたというのに。 それもこれも昨日のバグのせいだ。睡眠時間も、開発スキルも、人員も、私の現場には何もかもが足りていない。 それにも関らず、理解の足りない上司は「テスト工程を削ってでも早く納品しろ」とプレッシャーを与えてくる。 あの馬鹿どもめ。一体何を考えているんだ？ スーツに着替え終わった私は、冷蔵庫の缶コーヒーで空腹
デスマーチが起きる理由 - ３つの指標
デスマーチが起きる理由 - ３つの指標 著者： 青い鴉（ぶるくろ）さん @bluecrow2 これは結城浩さんの運用されていた YukiWiki に当時 Coffee 様 (青い鴉（ぶるくろ）さん）がかかれていた文章です。 ただ 2018 年 3 月 7 日に YukiWiki が運用停止したため消えてしまいました。その記事のバックアップです。 今は 404 ですが、もともとの記事の URL は http://www.hyuki.com/yukiwiki/wiki.cgi?%A5%C7%A5%B9%A5%DE%A1%BC%A5%C1%A4%AC%B5%AF%A4%AD%A4%EB%CD%FD%CD%B3 になります。 昔、自分がとても感銘を受けた文章なので、このまま読めなくなるのはとてももったいないと思い、バックアップとして公開しています。 お願い もしオリジナルの図を保存されていた方いら
定量的品質予測のススメ 1
03-3817-5670 FAX 03-3815-8199 1 刊行にあたって 独立行政法人 情報処理推進機構 （IPA）ソフトウェア・エンジニアリング・ センター（SEC） は、大規模・複雑化し、かつ社会生活への影響力が高まって いるソフトウェアの信頼性と生産性を向上させるために、2004 年 10 月 IPA に設立されました。 SEC では、産学官連携により広く収集・研究開発してきたソフトウェアエン ジニアリング手法や人材育成等について、手法、標準、ガイドブック等の形で 成果を取りまとめ、実証実験を行ってきました。これらの成果を広く活用して ソフトウェアの信頼性を確保していただくことにより、 「安心・安全」 な社会生 活を実現するための活動を展開しています。 顧客に対するサービスも企業内の業務も、今やソフトウェアなしでは実現で きない時代です。 「どんなソフトウェアシステムをつくるの
バッファをオープンにするマネジャー、隠すマネジャー
こんにちは、プロセスデザインエージェントの芝本秀徳です。 「バッファ」です。 プロジェクトの計画を立てるとき、進捗管理をするとき、そのプロジェクトやプロセスの不確実性に応じて、マネジャーはスケジュールに「バッファ」を持たせます。きょうは、この「バッファ」の取り扱い方についてです。 ■ バッファをどう取り扱うか バッファの取り扱い方には、２つのことを考慮しなければなりません。つまり、 「バッファをオープンにするか」 「誰にバッファを管理させるか」 の２つです。 バッファがあるということを、メンバーに知らせるマネジャーと知らせないマネジャーがいます。さらに、バッファがあることを知らせていても、そのバッファをマネジャー自身が管理するか、本人に管理させるかがちがうのです。 ■ バッファは「オープン」「本人管理」が基本 私は原則として、「バッファはオープンにして、本人に管理させる」ことが望ましいと考
バッファは諸刃の刃 プロジェクトマネジメントの基本 その２：芝本秀徳の『プロジェクトマネジメントの守破離』：オルタナティブ・ブログ
プロセスデザインエージェントの芝本秀徳です。 前回は『プロジェクトの本質』について書きました。プロジェクトの本質は「不確実性」にあり、プロジェクトマネジメントとは「不確実性を乗りこなすこと」だということでした。 では、どのように不確実性を乗りこなせばいいのかということで、今回は「バッファの考え方」についてです。 バッファは取り扱い方によって、プロジェクトによい影響を与えることもできれば、致命的な悪影響を与えることもあります。そして、バッファの取り扱い方を知ることは、プロジェクトのメカニズムを知るに通じる重要なテーマです。 前回の記事にも書いたように、プロジェクトが抱える不確実性に対処するには、３つのアプローチが考えられる。 １．不確実性そのものを軽減する ２．衝撃を減らす ３．徐々に不確実性を減らす の３つだ。 この３つのアプローチのうち、もっともお手軽で、もっともよく使われる手が「衝撃を
「元グーグル」という肩書はいつか外したい――及川卓也さんが考える、日本の「残念なIT」からの脱出法 | HRナビ by リクルート
DEC（デジタル・イクイップメント・コーポレーション）・マイクロソフト・グーグルと、時代を築いた外資系IT企業を渡り歩いた及川卓也さん。マイクロソフトではWindows NT、グーグル時代にはGoogle日本語入力やChrome OSなどのプロダクトに、エンジニアリングマネージャーとして携わっている。 今年5月にプログラマー向けの技術情報共有サービス「Qiita（キータ）」を運営するインクリメンツを経て、今年6月に独立。現在は、国内人材紹介大手のクライス＆カンパニーの顧問に就任し、CTO・IT技術人材の採用支援や組織変革活動に力を入れている。そんな及川さんに、「日本のITをどう見ているのか」という観点から話をお聞きした。 日本のIT産業はどこが残念なのか？ ――組織変革やIT活用という面で、しばしば「残念」と評価されてしまうこともある日本のIT産業ですが、いわゆる外資大手IT企業での経験を
ITプロジェクトの実践～リスク・マネジメント～ 最終回 リスク・マネジメントに挑戦してみよう｜建設情報クリップ｜けんせつPlaza
前月号ではWBS（Work Breakdown Structure）をもとに現実的なスケジュールを立てる方法を紹介した。 これによりプロジェクトは、あらかじめスケジューリングされた項目に従って作業を進めることができる。 しかし、しっかりした計画を立てても、予定外の事象により納期遅延につながることもある。 予定外の事象には、どの様に対処すれば良いのだろうか？ 運を天に任せるのではなく、「備える」ことが大切だ。 今回は、備えるための技術、リスク・マネジメントについて解説する。 「リスク」、「リスキー」という言葉は、日常会話の中でもよく使われますが、 その意味を問われると正確に答えられる自信がない方も多いのではないでしょうか。 プロジェクトマネジメント（PM）の世界では、リスクは、 「もしそれが発生すれば、プロジェクトにマイナスまたはプラスの影響を及ぼす不確かな事象」と定義されています。 「もし
Microsoft ProjectでマスターするＰＭ実践の極意 / PMstyleコラム
イノベーション実践、コンセプチュアルスキル、プログラムマネジメント、プロジェクトマネジメント、ＰＭＯについての最先端の情報、研修、セミナー、コンサルティングをお届けします。 第２３回 PMBOK（Ｒ）テンプレートの作成 その９（2008.12.19） アイ･ツー･マネジメント 代表取締役 岡野 智加 Tweet 今回のPMBOK(R)テンプレートの紹介は、プロジェクトマネジメント計画書に添付される各知識エリア毎のマネジメント計画書の最後のマネジメント計画書として、リスク・マネジメント計画書をご紹介したいと思います。PMBOK(R)のプロセスに従ってリスクをどのようにマネジメントするのかを記述したリスク・マネジメント計画書のサンプルを紹介します。 尚、ご紹介するテンプレートは、私が主査を行っております、PMI日本支部 PMBOK委員会 実用化ワーキング・グループで作成したもので、現在、PM日
PMBOK 9つの知識エリア......7.リスクマネジメント - 毎日定時帰りを目指す文系SEの日記
プラスのリスク(好機)を増大させ、マイナスのリスク(脅威)を低減させる。 リスクマネジメントって、「曖昧さ」との戦いというイメージが強い。トム・デマルコ先生もおっしゃってます。 計画プロセス群 リスクマネジメント計画 リスクに対してどのように取り組み、処理するかを計画する。 リスクの特定、分析、対応計画、監視の行い方の定義 リスクマネジメントを行ううえでの役割及び責任の明確化 リスクの発生確率と影響度の定義*1 リスク特定 リスクを「リスク登録簿」にまとめる。 プロマネチームでのブレスト 専門家へのアンケート 類似プロジェクト経験者へのインタビュー などの手法を用いる。 定性的リスク分析 リスクに「優先度」をつける。 次のような点を分析する 各リスクが発生する確率 各リスクがタイム、コスト、スコープ、品質などのプロジェクト目標へ及ぼす影響度 リスクの許容度、発生確率、影響度から優先順位をつ
書籍でたどる「リーン」の本質
先ごろ出版された「リーン開発の現場：カンバンによる大規模プロジェクトの運営」（ヘンリック・クニバーグ著／オーム社／2013年10月）は、アジャイル開発手法を実践事例の視点から解説した力作である。スクラム、カンバン、XPなどの手法に言及しているが、中でも「リーン開発」を正面から取り上げているのが大きな特徴となっている。 本書ではリーン開発現場の写真、会話をふんだんに使って事例解説がなされていたり、まさに現場でプロジェクトに立ち向かっているマネージャ、エンジニアたちによって訳されていたりと、実に臨場感あふれる仕上がりとなっている。ちなみに著者のヘンリック・クニバーグ氏は私の長年の友人であり、本書、日本語訳巻末の解説も私が担当した（詳細はこちらで紹介している／参考リンク：「リーン開発の現場」紹介ページ）。 ただ「リーン」という言葉は、米国で注目を集めた経営書「リーンスタートアップ」で広く知られる
非ウォーターフォール型開発に関する調査結果公開：IPA 独立行政法人 情報処理推進機構
SECは、短サイクルで設計からシステム稼動までを"機敏"に繰り返し、ニーズへ迅速へ対応するといわれる非ウォーターフォール型開発について、事例を含む適用分野や規模などの調査を行いました。あわせて、有識者に参画していただいて研究会を実施し、現状・動向の把握と課題の整理を行いました。その資料を公開します。 ・非ウォーターフォール型開発に関する調査 調査報告書 ・非ウォーターフォール型開発に関する調査 研究会報告書 ・非ウォーターフォール型開発に関する調査 エグゼクティブサマリー
Googleが発見した、最も成功しているチームに共通する5つの特性 | ライフハッカー・ジャパン
Inc.：長年にわたり、Googleは数え切れないほどの研究に取り組み、膨大なデータを集め、何百万ドルもをつぎ込んで自社の従業員をより良く理解しようと努めてきました。Googleの最も興味深い取り組みの1つであるプロジェクト・アリストテレス（Project Aristotle）は、社内で最高の業績をあげているチームに焦点を当て、チームの生産性を高める秘訣を探ろうというものでした。 なかでも、生産性の高いチームと低いチームの違いは何なのか？ を解明することに主眼が置かれました。 この調査をはじめる前、Googleの経営陣は、ほかの多くの組織と同じように、最高のチームをつくるということは、最高の人材を集めることであると信じていました。それは理にかなった考えです。最高のエンジニアに、MBA、博士を集めれば、最高のチームのでき上がり。そうですよね？ しかし、Googleの人事分析マネージャ、Jul
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
