タグ

managementに関するytesakiのブックマーク (28)

  • プロジェクトの進め方について - ほぼ日刊イトイ新聞

    第30回 プロジェクトの進め方について 詳しく教えて。 前回、開発チームが小さい方が 開発効率が高まるという話をしました。 今回もそれに引き続いて、 プロジェクトの進め方や、生産性の話です。 僕がチームの生産性の向上に 一役買っていると思うやり方というのは、 プロジェクトチームの中で仕事を割り振るとき、 どうやって仕事を割り当てるかという方法です。 とはいっても、蓋を開けてみれば大したことではないので 改めて書くほどのことでもないかもしれませんが、 しかし理にかなった方法だと思うので、 紹介したいと思います。 1番のポイントは、 基的に誰が何をやるのかを決めるのは、 その仕事をする人だということです。 マネージャーに 「これをいついつまでにやれ」 と指示されるわけではないのです。 マネージャーやチームリーダーの仕事は、 次にチームが解決しなければならない問題を洗い出し、 テーブルの上に

  • 【レビュー】Eclipse Mylarってなに? - 基礎編 体験してみる? タスク指向UI (1) Mylarとは? | エンタープライズ | マイコミジャーナル

    MylarはEclipseのサブプロジェクトであるTechnology Projectで開発されているプラグインで、Eclipseに対してタスクに焦点をあてたユーザインタフェースを提供することを目的としている。 統合開発環境は開発者に対して作業効率を向上させる様々な機能を提供する反面、開発者は統合開発環境が提供する膨大な情報の中から現在行うべき作業に必要な情報を探し出す必要がある。Mylarは「タスク」にフォーカスをあて、現在行うべきタスクに関連する情報のみを表示するユーザインタフェースを提供する。 また、MylarはBugzilla、JIRAおよびTracといったバグトラッキングシステムと連携し、これらのバグトラッキングシステムに登録されているレポートをタスクとして扱うことも可能だ。 Mylarは最初のメジャーリリースである1.0が2006年12月にリリースされたばかりの比較的新しいプラ

  • http://www.eclipse.org/mylar/

  • Geekなぺーじ:アイディアを潰す上司、アイディアを引き出す上司

    「Idea killers: ways to stop ideas」 と 「Idea helpers: ways to grow ideas」 という記事がありました。 面白かったので一部訳してみました。 コメント欄にも色々書いてあって、その中の項目も訳してみました。 削ったり意訳しているものもあるので、詳細は原文をご覧下さい。 アイディアをつぶす人 これらの発言は考える事を阻害してしまいます。 また、これらの発言は理由を説明せずに意見を却下するために利用されます。

  • CSS 分割管理の実践編

    2006-12-13T09:47:51+09:00 数日前に行ったリニューアルでは、いくつか課題を設けました。ただただリニューアルしても張りがありませんし、ウェブデザインを行うものにとって自身のウェブサイトは自身の作品のようなものだし、好き勝手できるのも魅力なわけです。何回かの記事にわけて、リニューアルでおこなった作業をまとめていこうと思います。 前回、スタイルシートを分けて管理する方法をまとめるで CSS ファイルを分割管理するメリットや、どのように分割するか案を書いてみましたが、今回のリニューアルで実際に案を元に分割管理を実践し、結果はリストのようになりました。各ファイルの概要は案段階から変化がないので、そちら参照ください。以下のリストでは、テーマファイル以外の実際の CSS ファイルにリンクしています。 common.css component.css fonts.css scree

  • スタイルシートを分けて管理する方法をまとめる - 2xup.org

    comment 2006-10-17T21:15:00+09:00 お好みの言語が英語で無い場合は、日語でどうぞ。 In this PDF file, the order of the set format rule and property's appearing was announced. This time, the method of separately managing the CSS file used on the site is announced. Why is CSS divided? I think that most reasons are the improvements of the work efficiency. The access to the revision part becomes early They are combined and co

  • 管理と自由: DESIGN IT! w/LOVE

    不確実な時代をクネクネ蛇行しながら道を切りひらく非線形型ブログ。人間の思考の形の変遷を探求することをライフワークに。 昨夜の「「私にしかできない仕事というのは組織では幻想」というのは幻想」というエントリーにいただいたコメントの中で、「それを幻想としなければ生産管理が難しくなる」だったり、「第一 そんな仕事ばっかの企業って企業として成り立たない」といったコメントをいただきました。 おっしゃりたいことはわからなくもないのですが、ちょっとそれは企業だとか、経営だとかを悲観的にみすぎなのではないだろうかと感じました。当に企業がそんな風にしか活動できないとすると、ちょっと未来が感じられません。 しかし、別にちょっとくらい個の自由を認めたくらいで、生産管理やその他の面で企業が困ることなんてありません。実際、そういう会社で働いてますから、それは断言できます。それにすべてが自由だというわけでも、昨日もア

  • POLAR BEAR BLOG: 知識共有を阻む37の壁

    ブログの良いところの1つは、様々なブロガーによって過去の知識が掘り起こされることだと思うのですが、今日もそんなエントリがありました。 ■ Three-dozen knowledge sharing barriers (Anecdote) Gabriel Szulanski という方(INSEAD の教授?)が1996年に発表された「知識共有を阻む壁」を紹介しているエントリ。様々な阻害要因を網羅&個人・組織・技術の3つのレベルに分類してくれていて、参考になります。というわけで自分用に翻訳&メモ。 ※訂正 下のリストは Gabriel Szulanski 氏の論文からの 出展 出典(9/6 再修正しました -- ご指摘ありがとうございました!)ではなく、Andreas Riege 氏の論文、"Three-dozen knowledge sharing barriers managers mus

  • 【上級】失敗プロジェクトの共通項 第5回

    想定プロジェクトでは,多くのサーバーやミドルウエアが使われる。OS,Web/APサーバー,データベース,負荷分散装置などだ。プロジェクト内にこれらの製品のうちひとつでも利用経験者がいなければ,スケジュールは見直しを迫られる可能性が高い。使用方法を取得するのに多くの時間を要するからだ。多くの残業,休日出勤を招くことになり,納期にも影響を及ぼす。 スキルマップの整備が不可欠 プロジェクト技術者をうまくマッチングするには,社内での分野別スキル保有者リストが欲しい。スキル保有者がいなければ,社内からの協力を仰ぐといった運用が可能になる。 スキル評価の方法は,一般的には大分類から小分類へツリー構造で細分化していくのが使いやすい(図7)。 大分類としては「技術」「業務知識」「マネジメント」の3つが標準。技術なら「ハード」「ネットワーク」「OS」「開発言語」など中分類に分け,さらに開発言語なら「Jav

    【上級】失敗プロジェクトの共通項 第5回
  • 日本マクドナルド、ついに連結営業利益が651.3%増

    先日、日マクドナルドホールディングス株式会社が2006年12月期(2006年1月1日~2006年12月31日)の連結による中間期業績(2006年1月1日~2006年6月30日)を発表したのですが、どうやら今までのあらゆる対策が功を奏したようです。 既存店客数が前年比3.0%増、既存店売上についても4.4%増。あの巨体でこれだけの増加率を、あれだけの失態の後から生み出すというのはなかなかできるものではないので、「マクドナルドはよくやった」と言っていいのではないかと。 詳細は下記の通り。 2006年12月期中間期連結業績概況 具体的には以下の5つが利益増の原因。 (1)昨年度のバリュー戦略による客数の獲得および年度の価格の見直し (2)過去2年に亘る店舗開発および店舗運営に対する積極的な投資 (3)24時間営業を含む営業時間延長 (4)新規メニューの投入 (5)マーケティングを含むコミュニ

    日本マクドナルド、ついに連結営業利益が651.3%増
  • ウノウラボ Unoh Labs: ベンチャー流サーバ構築のススメ(ソフトウェア編)

    尾藤正人です ラボブログではウノウのエンジニアで1日1人1エントリ(早く書くのはあり)で書いてます。おかげさまでウノウも順調にエンジニアの数が増えて、僕の順番に回ってくるのが少しずつ遅くなってきました。でもまだまだウノウではエンジニアを大募集中です!!我こそはと思う方はぜひご連絡ください。 前回のベンチャー流サーバ構築のススメ(ネットワーク編)ではネットワーク周りについて書きました。前回のエントリで言ったように、今回はソフトウェア周りのことについて書きたいと思います。 ソフトウェア周りで重要なのは、同じ構成にする、これにつきます。web サーバにだけ apache をインストールしたりとか、DB サーバにだけ MySQL をインストールしたりだとかいうことはしません。全てのサーバに同じパッケージ、同じプログラムをインストールします。それによる管理コストの軽減ははかりしれないものがあります。

  • PHP5で書かれたWeb2.0風プロジェクト管理ツール:activeCollab:phpspot開発日誌

    activeCollab - open source project management and collaboration tool. activeCollab is an easy to use, web based, open source collaboration and project management tool. Set up an environment where you, your team and your clients can collaborate on active projects using a set of simple, functional tools. 100% free!PHP5で書かれたWeb2.0風プロジェクト管理ツールactiveCollabの紹介。 プロジェクトを作ってその下にマイルストーンを設定したり、その元でタスクを追加したり、

    ytesaki
    ytesaki 2006/07/10
    よさげかも?
  • 「ユーザー参加型サービス」と「社員参加型経営」 - Number7110

    最近、一つ考えていることがあります。 今日もとある講演でそんな話をしてきました。 近頃のうまくいっているサービスなり、トラフィック&ユーザーを集めているサービスの1つの共通点として 「ユーザー参加型サービス」 という考え方があります。 サービス運営側は「仕組み」にあたるサービスを提供して、 ユーザーはそこにコンテンツをアップしていくなり、集めるなりをして、サービスが拡大していくと。 従来のサービスだとコンテンツを集めてきて、一方通行で流して「見てもらう」という「見る型」サービスでした。 最近のうまくいっているサービスはユーザーがコンテンツを集めてくる、いわゆるユーザーにサービスを「使ってもらう」という「使う型」サービスになってきています。 いわゆるCGMというやつですね。 と、いまさらながらの話をあえて書いたのは、最近のうまくいっている(だろう)経営手法として 「社員

    ytesaki
    ytesaki 2006/07/02
    ここまで極端でなくても、マネジメントの透明性って凄く大事
  • TOYOTAで考えた、見える化の本質 (arclamp.jp アークランプ)

    arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 昨日、ご縁があってTOYOTAでチーフエンジニアを務められていた方から、自動車の開発プロセスについてお聞きする機会に恵まれました。 まずTOYOTAにおけるチーフエンジニアという役割を理解しなくてはいけません。チーフエンジニアは、ある車を開発する場合のコンセプト作り、役員プレゼン、車体コンセプト設計、予算・原価管理、プロジェクトマネージメント、販促、マーケティングまでの全てに携わります。単純に「車を設計すればいい」というものではなく、車を作って売るというプロセスの全てに関係するというものです。 今回の講演ではプロセス全般についてざっくり触れていただくという内容でした。なおTOYOTAの取り組みについては非常に多くのがあるかと思いますので、見える化をキーワードにして

  • 顧客が本当に必要だったもの

    Diabetes is a condition which requires constant monitoring. Keep in mind that when it comes to screening your blood sugar people who are diabetic are advised to ensure that they buy testing kits. When you receive the test strips they are usually in a box, someone only needs a couple of them and then other Read More

    顧客が本当に必要だったもの
  • Loading...

  • PF ふりかえりガイド

    Copyright (c) 2006-2022 ESM, Inc. Oblove, AMANO Masaru 1/60 プロジェクトファシリテーション 実践編 ふりかえりガイド (株)永和システムマネジメント オブラブ 天野勝 第 1 版 2006 年 6 月 7 日 第 30 版 2015 年 8 月 23 日 第 31 版 2015 年 8 月 30 日 第 32 版 2015 年 11 月 24 日 第 33 版 2016 年 4 月 25 日 第 34 版 2018 年 1 月 27 日 第 35 版 2021 年 5 月 13 日 第 36 版 2022 年 10 月 30 日 オリジナル:http://ObjectClub.jp/community/pf/#material このドキュメントは、クリエイティブ・コモンズ・ライセンス(帰属 2.0)の下 で提供しています。このライ

  • 内田樹の研究室: ナショナリズムと集団性

    2024 1月 - janvier 2月 - février 3月 - mars 2023 1月 - janvier 2月 - février 3月 - mars 4月 - avril 5月 - mai 6月 - juin 7月 - juillet 8月 - août 9月 - septembre 10月 - octobre 11月 - novembre 12月 - décembre 2022 1月 - janvier 2月 - février 3月 - mars 4月 - avril 5月 - mai 6月 - juin 7月 - juillet 8月 - août 9月 - septembre 10月 - octobre 11月 - novembre 12月 - décembre 2021 1月 - janvier 2月 - février 3月 - mars 4月 - avril 5

  • 近藤・家入・柳澤 「組織をツクレ」 トークセッション | 近江商人JINBLOG

    今日はカヤックさんが主催した、はてな近藤社長、ペパボ家入社長、カヤック柳澤社長の3人によるトークセッション『組織をツクレ』に行って来ました。 この面子でセミナーやるなら普通「これからのネット」や「サービスづくり」系の話にしてしまいそうなものなのに、そこをあえて「組織」という切り口でパッケージしてきたカヤックの柳澤さん素敵。 セッションの模様は、バスキュールさん開発(カヤックさん販売、ペパボのheteml上でサービス)のFLASHライブストリーム&チャットツール<オンライン参加システム>を通じてネット配信されていましたが、その仕組みがたいへんいい感じだったので、ちょうど次回のRTCでそれを使わせていただきたい、とお願いをしてきました。詳細調整中です。 以下、議事内容をざっくりとメモしたものを軽く成型しただけのものです。その場だけのネタトークもありますので、話半分で読んだほうがよいと思います。

    近藤・家入・柳澤 「組織をツクレ」 トークセッション | 近江商人JINBLOG
  • 請負開発を人月で見積もる理由 - ソフトウェア業界 新航海術 

    ************************************************************** _/_/_/_/_/_/_/ ソフトウェア業界 新航海術 _/_/_/_/_/_/_/_/_/ ************************************************************** 第123号 2006/4/17 ▼ まえがき ▼ [ブルックスの法則] 人月による見積もりの是非 ▼ [ブルックスの法則] 人月による見積もりは日独特の商習慣ではない ▼ [ブルックスの法則] 要員の最大数は独立したサブタスクの数に依存する ▼ [ブルックスの法則] プロジェクトの月数は順次的制約に依存する ▼ [ブルックスの法則] 人は時間に余裕があると、ますます時間をかける ▼ [ブルックスの法則] 期間を短縮するとコスト曲線は急上昇する ▼

    請負開発を人月で見積もる理由 - ソフトウェア業界 新航海術