タグ

manageに関するdlive1のブックマーク (20)

  • “働かないおじさん”がDXパーソンに!マッキンゼー流「成功の方程式」

    コロナ禍で加速した「仕事の可視化」。DXの一つであるテレワークは、仕事をしている人としていない人をくっきりとあぶり出した。企業内で吹きだまる“働かないおじさん”にとっては、ますます居場所がなくなる状況になっている。ただ、その多くはかつて現場でバリバリ活躍したビジネスパーソンたちだ。そこで今回は、ダイヤモンド・オンラインの大ヒット動画特集『マッキンゼー流!DX革命』(全7回)から、抽出したエッセンスを特別公開する。マッキンゼーの「DX成功方程式」を参考に、働かないおじさんからDXパーソンへの進化の道を探っていこう。(ダイヤモンド編集部 羽富宏文) >> 『マッキンゼー流!DX革命』(全7回)の動画はこちらから 働いていないことがバレバレの おじさん社員がコロナ禍で続出 みなさんの周りにも一人は必ずいるのではないか。ダイヤモンド・オンライン2020年3月30日配信号でご紹介した特集『当は怖い

    “働かないおじさん”がDXパーソンに!マッキンゼー流「成功の方程式」
  • 怠翻 - プロジェクトがオワタことを告げる102の証拠 : 404 Blog Not Found

    2007年07月17日20:15 カテゴリ翻訳/紹介 怠翻 - プロジェクトがオワタことを告げる102の証拠 元ネタはこちら。 101 Ways To Know Your Software Project Is Doomed アジャイル系、XP系の基礎知識がないと、結構すべるかも。 上司がウォーターフォールプロセスを「アジャイルウォーターフォール」に改名したZE☆ コンサルタントと契約したよ -- いざとなったら責任を取らせるためZE☆ 連続統合鯖が「もうだめぽ。オワタ\(^o^)/」というエラーメッセージを出したZE☆ 設定ファイルにXMLを採用したRubyフレームワークをつくっちゃったZE☆ 最古参の先輩が、Martin Fowlerのことを「鼻っ柱野郎」ってよんでるZE☆ ソース管理システムの中に、共有ドライブのフォルダが山ほどあるZE☆ ♪だからは次は絶対勝つために質疑問答だけは最

    怠翻 - プロジェクトがオワタことを告げる102の証拠 : 404 Blog Not Found
    dlive1
    dlive1 2007/07/18
    最後の項目に似た感じのやつは、忙しいときほど起きる気がする。というかよく思う
  • 能力成熟度モデル統合 - Wikipedia

    能力成熟度モデル統合 (のうりょくせいじゅくどモデルとうごう、英: Capability Maturity Model Integration, CMMI) は、組織がプロセスをより適切に管理できるようになることを目的として遵守するべき指針を体系化したものである[1] 。 平易な言い方をすると、ソフトウェア開発組織及びプロジェクトのプロセスを改善するために、その組織の成熟度レベルを段階的に定義したものである。 CMMIは、もともとは能力成熟度モデル (CMM; Capability Maturity Model) として開発された。 成熟度レベルの特性 CMMIは、プロセスの評価や改善をすすめるための枠組みであり、段階表現と連続表現の2つの表現方法がある。段階表現では、組織の実施プロセスを評価し、レベル1からレベル5までの5段階の成熟度レベルを(組織に対して)出すことができる。連続表現では

    能力成熟度モデル統合 - Wikipedia
    dlive1
    dlive1 2007/03/20
    組織がプロセスを適切に管理するために遵守すべき指針を体系化した物。5つの成熟度レベルで定義。1は非常に未熟、5は非常に成熟した開発プロセス。何から着手?開発Commuの経験から得た成果、共通の言語・ビジョンの共有
  • シックス・シグマ - Wikipedia

    この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。 出典を追加して記事の信頼性向上にご協力ください。(このテンプレートの使い方) 出典検索?: "シックス・シグマ" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL (2009年10月) シックス・シグマ(Six Sigma, Lean Six Sigma)とは、1980年代に米モトローラが開発した品質マネジメント(英語版)手法、または経営手法である[1][2]。 その適用範囲は、主に製造業が中心であるが、製造業の製造部門に留まらず、営業部門、企画部門などの間接部門への適用、更にはサービス業などの非製造業への適用も多い。統計分析手法、品質管理手法を体系的に用いて製品製造工程などの各種プロセスの分析を行い、原因の特定やそれへの対策を行っ

    シックス・シグマ - Wikipedia
    dlive1
    dlive1 2007/03/20
    ばらつき抑制に主眼を置いた品質管理、経営手法。統計学における標準偏差のσで,MAIC(測定、分析、改善、改善定着の管理(東芝などではDFACE(定義、状況認識、目標設定、設計、最適化、評価)))と呼ばれる行動Processの概念。
  • 起業する前に自問すべき10の質問 | POP*POP

    最近は「いずれ起業します」という人が多くなってきましたね。それ自体は良いことだと個人的に思っていますが、いろいろな人を巻き込む前にちょっとだけ冷静に状況を判断するのも悪くないはずです。 そこで今回は「起業する前に自問すべき10の質問」をご紹介します。起業する前に自問してみてはいかがでしょうか。今まで気づいていなかったリスクに対処できるようになるかもしれませんよ。 » How to Not Go Broke on Your Million Dollar Idea (via lifehack.org) さてその質問とはどういったものでしょうか・・・。 紙とクレヨンだけを使ってあなたのアイディアを他の人に説明できますか? あなたのマーケティング戦略を一つの文章で定義できますか? あなたのサービスを買ってくれるような人を6人以上知っていますか?その人たちのことをあなたは十分に知っていますか? もし

    起業する前に自問すべき10の質問 | POP*POP
    dlive1
    dlive1 2007/03/19
    紙と鉛筆でアイデアを説明できるか、Marcketing戦略を一つの文章で定義可能か、Serviceを買ってくれる人6人以上知ってるか、誰かがIdeaを今日盗んでも続けるか・・・などなど。研究とかも似たようなもんかも
  • To Doリストなんか書いている時間がない | タイム・コンサルタントの日誌から

    の製造業が景気回復の手応えを感じはじめてから、もう2年近くたつ。業種・地域ごとに濃淡の差はあれども、いまはどこの会社に行っても、多忙な状況だ。10年以上続いたひどい不況の時代に、企業は可能なかぎり人減らしをすすめたから、今さら急に業容が拡大したって、体制が追いつかないのは事実だろう。 製造現場はそれでも、派遣労働者をあつめてきて何とかしのいでいるみたいだが、技術者となると、そうはいかない。その業種・その会社の技術内容をよく知った人間でないと、エンジニアはつとまらないからだ。おかげで、どの会社でもエンジニアの労働時間がふえる一方だ、このままでは過労で倒れそう、と声なき悲鳴が聞こえる昨今である。 そんな現状があるからだろう。人・モノ・金につづく経営資源の第4の要素として、『時間』があらためて注目をあびるようになった。会社組織として、時間をいかに管理していくか。それは納期短縮にも製品開発競争

    To Doリストなんか書いている時間がない | タイム・コンサルタントの日誌から
    dlive1
    dlive1 2007/03/15
    TODOリストはTaskを貰った人間を書くものでなく指示する人間が書くものであるべき。グループTODOリストを使うべき という話。>受領したかどうかわからんから、メールでDesktop上のTODOリストへ。とかできるといいのか?
  • ウノウラボ Unoh Labs: 専用サーバを構築するときにまず行う4つの設定

    GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー!古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠

    ウノウラボ Unoh Labs: 専用サーバを構築するときにまず行う4つの設定
    dlive1
    dlive1 2007/03/15
    Fedora5では、sudoを使えるように。suを使えないように、rootでLoginできないようパスを削除、不要なPortにアクセスできないようiptablesを設定(ローカルだけおっけとか)。suで ALL(ALL)ALLなのか・・・
  • CACMの特集記事:ソフトウェアプロダクトライン工学(1) - ysakata's diary

    いつも(1)しかなくぜんぜん続かないと評判の俺のエントリ。またやってきました。Communications of the ACM 2006/12の特集記事、Software prductline engineeringの各記事を読んで気になった部分をメモするというコーナーの第一回目です。パチパチ。 今日は、特集記事のEditor Sugumaranらによる、特集の狙いなどを記述した部分を紹介しましょう。なお、いつものように網羅性は気にしていませんので、網羅的にソフトウェアプロダクトライン工学を知りたい方は別に自分でどうぞ。 記事概要 SPECIAL ISSUE: Software product line engineering Introduction オーサー Vijayan Sugumaran Oakland University, Rochester, MI Sooyong Par

    CACMの特集記事:ソフトウェアプロダクトライン工学(1) - ysakata's diary
    dlive1
    dlive1 2007/03/10
    最初1969年McIlroyに成果物の再利用とドメイン分析を問題提議。SPLの手法を提案したのがCMUのSoftwareEngineeringInstitute。現在の問題:Process,組織、技術の側面に問題がある。複雑性の管理、Future相互作用問題、RuntimeDynamism
  • 第1回 役立つシステムを育てよう

    企業の大小を問わず,情報システムは社員にとって身近な存在になっている。しかし,システムが当の威力を発揮しているかというと疑問である。連載では,情報システムの利用者や経営者にとって当に役に立つ道具に育て上げるための「工夫」に焦点を当て,これらを「15の鉄則」として紹介していく。鉄則は,情報化プロジェクトにかかわるメンバーに必要な「共通認識」と「やる気の維持」,そして「道具の準備」に大別できる。 サイトで,「失敗しない中堅企業の情報化」と題し,専任の情報システム担当者をなかなか持てない中堅企業にあって,情報化をどう乗り切っていくかについて連載してきた。具体的には,企画・開発・運用・定着といった各段階で「失敗に結びつく」問題点の数々を,簡単な事例と対応策を通して把握してもらう形をとった。 中堅企業の方々が,失敗につながる危険に対する防御措置をある程度想定して情報化を推進することで,トラブ

    第1回 役立つシステムを育てよう
    dlive1
    dlive1 2007/03/09
    目的の理解を、Give&Takeのバランスを、ソフトの融通は二の次、実力者を責任者に、利用者を配慮、完成直後は文句言うな、ノウハウを広げろ、目的と成果の共有、BBS使え、業務に密着した研修、良いマニュアル、HelpDesk
  • わたしが知らないスゴ本は、きっとあなたが読んでいる: プロジェクトを成功させる魔法の言葉

    あいにく銀の弾丸の持ち合わせはないが、うまくいくプロジェクトでよく使われていた言葉は確かにある。耳にしたときは聞き流していてた言葉を、このは思い出させてくれた。ここでは、そんな「魔法の言葉」を紹介する。 ネタ元は「目標を突破する実践プロジェクトマネジメント」。ふつう、図書館で読んだはそれっきりだが、こいつは買って周りにばら撒く。薄くて分かりやすくて、すぐにやってみようという気にさせるところがいい。 ■ もし、問題があるとすれば、それは何ですか? 朝会や進捗会議で「何か問題はありませんか?」という質問はよくするしされる。けれども答えはいつも決まっている→「特にありません」。でもって、不具合が起きると、「あのとき聞いたのにッ」←→「こうなるとは思ってなかった」となる。 身に覚えない? これを、冒頭の質問にしてみると、アラ不思議、いくらでも出てくる。「問題ない?」には無反応だったのが、「これ

    わたしが知らないスゴ本は、きっとあなたが読んでいる: プロジェクトを成功させる魔法の言葉
    dlive1
    dlive1 2007/03/09
    「これから問題が起きるならどんなのがある?」(言い出し易くなる)、進捗は「あと何日」(どれ位できたとは聞かない)、質問の対象として大事なのは目的、成果物、成功基準。この三つを頭文字でODSCと言うとか。
  • Railsで作られたプロジェクト管理ツール"redMine" (でぃべろっぱーず・さいど)

    redMine - project management and issue tracking Rubyで作られたプロジェクト管理ツールです。 GanttチャートやMyページなど、Tracにはデフォルトで備わっていない機能が付いてますね。 デモサイトはこちらです。 Tracよりも使いやすいのかしら。 サイトに書かれている特徴には以下のものが挙げられています。 ・Multiple users/multiple projects →多様なユーザ/プロジェクトに対応 ・Fully customizable role based access control →アクセス制御によるカスタマイズ可能な権限管理 ・Issue tracking system →問題課題追跡システム(トラッキングシステム) ・Fully customizable workflow →カスタマイズ可能なワークフロー ・Doc

    dlive1
    dlive1 2007/03/08
    GanttチャートやmyページとかTracにはない機能があるとか。RSS配信やPluginはまだみたいだ。まだ日本語未対応だがそのうちっぽい
  • ウノウラボ Unoh Labs: 失敗から学んだ効率のよい会議術

    GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー!古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠

    ウノウラボ Unoh Labs: 失敗から学んだ効率のよい会議術
    dlive1
    dlive1 2007/03/08
    時間通り、課題を用意、冒頭に目的を共有、議事録はProjectに詳しい人が、プロジェクタとホワイトボードを、発言に責任を持つ、最後にToDoを確認。
  • 「要努力領域」で努力しても凡庸にしかならない

    「要努力領域」で努力するのは凡庸にしかならない Kathy Sierra / 青木靖 訳 2006年2月6日 これまでの人生(学校、仕事、人間関係)で、「要努力領域」について人に言われたことはどれくらいある? その領域で努力するために、どれほどの時間とエネルギーを使った? あなたがマネージャなら、パフォーマンスレビュー でそういう領域についてどれくらい強調してきた? 弱点に取り組むのではなく、強みを伸ばし、磨いていくべきではないのだろうか? もし弱点に取り組むことの対価が、ずば抜けたものになる可能性を減らすことだとしたらどうだろう? (そもそも何が「弱点」だとかそうでないとか、誰が決めるというの?) このことについて書かれたがあって、私は読んではいないのだが、その考え方には興味を引かれる。 Teach With Your Strengths(強みで教える)というは、Amazonのページ

    dlive1
    dlive1 2007/03/06
    弱点に取り組んでも凡庸にしかならない。できるかぎり強みを伸ばした方がええんじゃないかという話。 まっ、結局必要とされる能力を把握する力は大切だということ。
  • 管理を完璧にしようとすればするほど、プロジェクトは失敗する

    「計画」「やる気」「変化」のプロジェクト失敗“3大要素”は完璧に管理できるのか――。“完璧な”プロジェクト管理を想定してみよう。 ほとんどのプロジェクトの失敗要因は、「計画」「やる気」「変化」という3つの要素です(2月14日の記事参照)。では皆さんは、これらの3つの失敗要因を発生させないようにできるでしょうか。 ここで単純にプロジェクト「管理」の立場で考えると、答えは一見簡単です。 事前の「計画」を完璧にプランニングする プロジェクトの「変化」を完璧に排除する メンバーの「やる気」を完璧に把握する でも、当にそうでしょうか? 私たちが直面しているのは、前回も書いたように、毎回“初体験”のようなプロジェクトで、正確な「計画」を立てるのが不可能に近く、「メンバー」の作業効率も把握しにくい上に、プロジェクトに変更や変化が頻繁に発生する――そんなプロジェクトなのです。 逆説的ではありますが、3つ

    管理を完璧にしようとすればするほど、プロジェクトは失敗する
    dlive1
    dlive1 2007/02/22
    以前の「管理、やる気、変化」が大事の話の続き。プロジェクトを完璧に管理するのはやめた方がいいよという話。んじゃどうすればうまくいくかは次回。
  • Geekなぺーじ : プログラマのモチベーションを高める9の事項

    「Nine Things Developers Want More Than Money」という記事がありました。 面白かったので要約してみました。 誤訳や勘違いがあるかも知れないので詳細は元記事をご覧下さい。 1. 成功するプロジェクトであること 多くのプロジェクトはそもそも失敗するような計画で行われているという悲しい現実があると書いてありました。 成功の要素として、現実的な納期、安物のツールを使うことを強制されないこと、ろくでもないマネジメント・仕様変更・暗黙の仕様 などを要求する発注先にあたらないなどが重要だそうです。 2. すばらしいマネジメントが行われていること プロジェクトと人の両面ですばらしいマネジメントが行われていることが重要だそうです。 身を挺してチームを守るようなすばらしいマネージャに対してはプログラマはソフトウェアの品質で応えるそうです。 3. 新しいことを学べること

    dlive1
    dlive1 2007/02/19
    Projectが成功しそう、Managementがいい、新しいことが学べる、意味のある難題に取り組める、意見に耳を傾ける上司がいる、大変さを理解してくれる、意味のあるProject、会議を開かなくてもいい、過去の遺産による制約がない
  • EIR (Entrepreneur in Residence = 客員起業制度)という制度について:Speed Feed:オルタナティブ・ブログ

    小川さんは起業準備中といいながらなぜVC(ベンチャーキャピタル)に入社したのか?とよく質問される。実は僕は、サンブリッジが用意してくれた EIR という制度を利用して起業準備をしているのだが、EIR自体がまだ世間的にはなじみがないらしいので、以下それを説明してみたい。 EIRとは、比較的経験豊かなビジネスパーソンが起業する際に有効となる仕組みであり、昨今注目されつつある手法だ。いわばWeb2.0時代の起業スタイルであり、起業2.0の典型的な手法になる気がする。 Calacanis Takes Position at Sequoia CapitalIndex Ventures EIR starts up Wikio What is an EIR? ■ 二つの意味を持つEIR EIRとは、Entrepreneur In Residence(アントレプレナー・イン・レジデンス)と、Executi

    EIR (Entrepreneur in Residence = 客員起業制度)という制度について:Speed Feed:オルタナティブ・ブログ
    dlive1
    dlive1 2007/02/19
    EIRとは、Entrepreneur In Residence(アントレプレナー・イン・レジデンス)と、Executive In Residence(エグゼクティブ・イン・レジデンス)という二つの意味を持つ略称.社内ベンチャー制度に近い。起業家と企業の双方にメリット
  • OBB vs AABB - Radium Software Development

    This domain may be for sale!

    dlive1
    dlive1 2007/02/19
    スケジューリングに大切なのは、正しい見積もりを行う洞察力と,それを予定通りに進行させる管理能力と,止め処ない変化に対応して行くだけの俊敏さだ。
  • 優秀な経営者になるのに管理職の経験は必要ない? - ネタフル

    経営職はジミ(2)“赤ちょうちん”は日独特の文化という記事より。 優秀な経営者になるために課長や部長の経験は必要か?管理職の延長に経営職があるのではない。全く違う素養の仕事です。 アメリカと日の経営者の違いが説明されています。日だと一般的には課長、部長と徐々にステップアップしていきますが、アメリカでは経営者と管理職は違う素養のミッションとみなされているそうです。見ている場所が違うのですから、確かにそう面もあるのでしょうね。 日企業の失われた15年,長期低落傾向の原因は調整型管理職が経営していることにあったのです。環境変化の時は,いくら現場が強くてもリーダーが適切な針路を示せなかったら,それこそヘッドレスチキン(首を刎ねられた鶏は強い足腰故アッチ行ったりコッチに来たり)です。 なるほど‥‥確かに現場を多く経験していることも大切なのでしょうが、こういう現実もあるのでしょうね。Apple

    優秀な経営者になるのに管理職の経験は必要ない? - ネタフル
    dlive1
    dlive1 2007/02/17
    管理職と経営者では必要な才能が違うという話。経営者には未来のビジョンが必要。しかし「ハーバードのビジネススクールでその事業でいらない人間を見つけ首を切るところから議論が始まる」という話は面白い
  • プロジェクトが“簡単に頓挫する”3つの要素

    そもそもなぜプロジェクトは失敗するのか――。前回、まずは1人でプロジェクトマネジメントをしてみようという話を書きましたが、プロジェクトを成功させるためのテクニックに入る前に、“失敗”を考えてみたいと思います。 前回も書いたようにプロジェクトマネジメントというと、何だか小難しい印象を受けますが、基的には複数のメンバーで実行するプロジェクトといえど、個人のタスクリスト管理の延長にあります。 まずは、プロジェクトが失敗する要素を押さえることで、成功のためのポイントを見つめなおしてみましょう。プロジェクトが失敗する要素――というと、いかにもたくさんありそうに思えるかもしれませんが、実はプロジェクトを失敗させる要素は大きく分けると3つしかないのです。 プロジェクトが簡単に頓挫する3つの要素 無茶な計画 メンバーのやる気 変化を認めない 最初に無茶な計画を立てる プロジェクトを失敗させる最も簡単な方

    プロジェクトが“簡単に頓挫する”3つの要素
    dlive1
    dlive1 2007/02/15
    計画性のなさ、メンバのやる気の消失、変化への柔軟性への欠如。やる気の管理は難しいんでは・・
  • 最近、あなたは職場で人を褒めましたか? - @IT自分戦略研究所

    将来に不安を感じないITエンジニアはいない。新しいハードウェアやソフトウェア、開発方法論、さらには管理職になるときなど――。さまざまな場面でエンジニアは悩む。それらに対して誰にも当てはまる絶対的な解はないかもしれない。連載では、あるプロジェクトマネージャ個人の視点=“私点”からそれらの悩みの背後にあるものに迫り、ITエンジニアを続けるうえでのヒントや参考になればと願っている。 ■リーダーシップトライアングルにおける位置付け この連載では、システム開発プロジェクトにおけるリーダーシップを中心に、「私の視点=私点」を皆さんにお届けしています。 今回の内容は、リーダーシップトライアングルのLoveとManagementに関係します。Loveについては、第10回「正しいことをし、行動力を発揮するココロ」を、Managementについては、第9回「ソフトウェアは目に見えない」を、それぞれ参照いただ

    dlive1
    dlive1 2007/02/13
    システム開発におけるリーダーシップ.目先の利益になるを教えるのではなく、長期的に利益になるを教えること。「やってみせて いって聞かせて やらせてみて ほめてやらねば 人は動かず」by山本五十六
  • 1