タグ

managementに関するksagaのブックマーク (22)

  • 障害対応の工数は謎だらけ - rabbit2goのブログ

    開発現場では、新規の開発案件等に対して必要工数の見積もりを要求され、それはそれなりに難しいものが有るけれど、それ以上に難しいのは障害対応の工数見積もりだと思う。もちろん、内容を一目見て容易に原因と修正内容が分かるものがある一方で、原因の調査に難航し、さらに修正確認にも手間取るものが珍しくなかったりする。 何故そんなに時間がかかってしまうのだろうかと思って改めて考えてみたところ、対応に時間を要するものはこんな特徴を持っているようだ。 障害レポートに記載されている再現手順に従っても問題が再現しない。記載されていない情報に相違があるらしいので、レポートの報告者に詳細を問い合わせをする必要があり、そのやり取りに時間がかかってしまう。 原因調査のためにログ出力を追加したら問題が発生しなくなってしまう。ログ出力処理が、タイミングを何か変えてしまっているらしいが、その原因や影響理由が分からない。 不特定

    障害対応の工数は謎だらけ - rabbit2goのブログ
  • 時間や労力を消耗させるだけで、実のある成果につながらない「ニセ仕事」とは? | ライフハッカー・ジャパン

    モバイルバッテリーとは呼べない。「ほぼポタ電」なコレ1台で有事の時もアウトドアも大活躍!【AmazonスマイルSALE】

    時間や労力を消耗させるだけで、実のある成果につながらない「ニセ仕事」とは? | ライフハッカー・ジャパン
  • 「在宅勤務」に不安を覚える日本の会社員 日本的経営を改めて考えてみた(15) | JBpress (ジェイビープレス)

    ウイークデーの昼日中、30~40代くらいの男性が住宅街をウロウロしていれば不審者に間違えられかねない。知っている人にでも会えば、「あれ、リストラされたのか」などとあらぬ疑いをかけられることになる。 つまり日では、ウイークデーに働き盛りの男性が住宅街にいてはならぬのが「常識」なのだ。どこにいなければならぬのかと言えば、「会社」である。ウイークデーの昼日中には働き盛りの男性は、すべからく会社で仕事をしていなければならない、これが日の常識なのだ。 在宅勤務に消極的な日企業 この常識が邪魔してなかなか普及しないのが「在宅勤務」である。「周りの目が気になって、昼飯を買いにも出にくいんですよ」と、週に2日ほど在宅勤務をしている男性は苦笑まじりに言ったものだ。 かつては、自宅で仕事をするとなると、資料を会社から持ち出したりしなければならないので面倒だった。セキュリティーの面からも問題が多かった。

    「在宅勤務」に不安を覚える日本の会社員 日本的経営を改めて考えてみた(15) | JBpress (ジェイビープレス)
  • 「やりたいこと」から逆算するリバース・スケジューリング

    毎日夕方の5時半には職場を「お先に失礼」して、それでいて一線の研究者として成果を上げ、人気ブログを書く方法があるとしたら? そんな方法があるなら、私こそそれを真っ先に実践してみたいです。 Study Hacks の管理人で MIT のポスドクが業の Cal Newport さんのゲスト投稿がまさにこうした成果をたたき出すためのコツとマインドセットについて触れていて、うーんとうならされました。 まずは信じられない彼の活躍ぶりですが、MIT のポスドクとして研究を業とし、プロシーディングも含めて 10 の論文を書き、を執筆したうえで、Study Hacks のブログも維持しているというのに、彼が働いている時間は毎日 8:30 から 17:30 の間だというのです。かれはこの5時半以降を完全にフリーにしておくのが好きだということで、運動や犬の散歩の時間も含めてこの時間までには完了させるよ

    「やりたいこと」から逆算するリバース・スケジューリング
  • 3年使ったRedmineの使い方について共有したい10のこと

    前回は、1000人のエンジニアRedmineを使い出すまでの事例を紹介させていただきました。今回は、Redmineの使い方や、大規模に変化してくRedmineの運用について、2年間の運用や改善から得たナレッジや、気がついたことをまとめていこうと思います。 1. Redmineのオブジェクト構造を理解した方がいい Redmineは以下の構造になっているので、タスクの属性をうまく分類する必要があります。 プロジェクト > サブプロジェクト > バージョン > 親チケット > 子チケット > トラッカー > カテゴリ 注意したいのは、プロジェクト・サブプロジェクトには期限が設定できず、バージョンには終了日時、チケットには開始日時と期限をつけることができる点です。期限があるものには、期限のあるものを当てはめるのがすっきりします。Redmineを使って「何を」「どう」管理していきたいのかを、まず考

    3年使ったRedmineの使い方について共有したい10のこと
  • プログラマのためのGoogleプロジェクト35、+23、+34 | エンタープライズ | マイコミジャーナル

    Blog of 0x1fff 0x1fff: 35 Google open-source projects that you probably don't knowにおいてGoogle Codeでホスティングされているプロジェクトから35のプロジェクトが紹介されている。もとはポーランド語で記載された0x1fff: 34 projekty Open Source udost?pnione przez Googleを英訳したものとあるが、翻訳する段階で1つプロジェクトが追加されて35になっている。その後さらに25のプロジェクトが、その後さらに34のプロジェクトが追加され、合計92のプロジェクトがまとめられている。マイコミジャーナルでニュースやハウツーとして取り上げたものも多い。取り上げられているプロジェクトは次のとおり。 テキストファイル処理 Google CRUSH (Custom Repo

  • やがてくる大増税時代に豊かに生活するために準備すべきこと - 分裂勘違い君劇場 by ふろむだ

    現在の日の置かれた状況をよく考えてみると、数年〜十数年後に大増税を行わざるを得なくなる可能性がけっこう高い。 大増税時代になっても豊かに暮らせるようにするには、今のうちから準備しておかないと、あとで後悔することになることがある。 この記事では、それについてまとめてみた。 トピックハイライト 大増税を回避する政策はあるが、それが実行される可能性が低い理由。 中所得者と高所得者のどちらに大増税されるかは不透明。 高所得者を搾取して遊んで暮らす戦略。 具体的にどの税金を、どのように回避するために、今からどのような準備が必要か。 重い所得税を払わずに逃げ切る合法的な方法 重い消費税を合法的に回避する方法 高収入で贅沢をしても消費税も所得税もかからないようにする方法 税金を全く取られずに生産、流通、消費を行うさまざまなテクニック。 「高所得者に重税をかけると海外へ出て行く」というのは金持ちのポジシ

    やがてくる大増税時代に豊かに生活するために準備すべきこと - 分裂勘違い君劇場 by ふろむだ
  • 費用と期間を抑えて企業貢献度が高いシステムを開発するために、要件定義の課題を解決する新手法を確立 : 富士通

    当社は、システム開発で重要となる要件定義(お客様のビジネス要求をシステム機能に落とし込む工程)の質的な課題である、(1)要件の目的や要件を決めるべき役割の曖昧さの排除、(2)経営層・業務部門・情報システム部門における納得性の高い合意形成、(3)要件を洗練させ、十分な検討を経た上で期限内に確定させるマネジメントの3点を根的に解決するための3つの方法論を「新要件定義手法」として確立し、日より、当社が手がけるシステム開発に「新要件定義手法」の適用を開始します。 当社は、経営への貢献、業務部門の業務効率向上、情報システム部門の運用負荷軽減を実現する効果的なシステムを費用や期間を抑えて開発できるよう、お客様の要件定義の精度向上を支援します。 背景 昨今、お客様のシステム開発に対するニーズは、業務効率化だけでなく、競争力強化を見据えたものに変化しており、システムへの要求がますます多様化しています

  • @IT:シェルを使わずにシステムをシャットダウンするには

    何らかの原因でシェルからの入力が一切行えなくなった場合は、PCのリセットボタンを押してリブートするしかない。しかし、ハードディスクがクラッシュする可能性もあるので、可能な限り安全な方法でリセットしたい。そのようなときには、マジックSysRqキーを使う。 マジックSysRqキーを使うには、/proc/sys/kernel/sysrqが「1」になっていなければならない。「0」になっている場合は、rootで、 としておく。 コンソールからの入力を一切受け付けないような事態に陥ったら、[Alt]+[SysRq]キーを押しながら、[s]→[u]→[b]キーの順にキーを押す。すると、システムが再起動する。電源オフするときは、[Alt]+[SysRq]キーを押しながら、[s]→[u]→[o]キーの順にキーを押す。 主なマジックSysRqキーは、以下のとおりだ。それ以外のキーについては、/usr/src/

  • 【西康晴が語るソフト品質・第1回】組み込み開発は「ものづくり」になれるか?

    ソフトウエア・テストのカンファレンス「JaSST」の開催を主導するなど,ソフトウエア品質の分野で精力的な活動を続ける電気通信大学の西康晴氏に,現在の組み込みソフトウエア開発における問題点と解決策を解説してもらった。継続的に品質を高める体制を構築するための取り組みについて,プロジェクト・マネジメント,プロセス改善,テスト・レビューの3つの観点から概要を述べる。 この記事は,「日経エレクトロニクス」と「日経バイト」が刊行した別冊『組み込みソフトウエア2006---品質管理と開発技法の実践的改革A to Z』の掲載記事を抜粋したものです。別冊の詳細はこちらをご覧下さい。 筆者は,数年前までソフトウエアの品質コンサルタントをしていた。現在でも企業との共同研究を通して,ソフトウエアの品質向上手法の開発などを手掛けている。特にここ3~4年は,組み込み分野の企業からの相談が非常に増えてきている。家電や車

    【西康晴が語るソフト品質・第1回】組み込み開発は「ものづくり」になれるか?
  • @IT:明日からできるプロジェクト管理(4) - 単体テストの品質をチェックするには

    明日からできるプロジェクト管理(4) 単体テストの品質をチェックするには 1page|2page|3page 高野敦 2006/1/12 実装・単体テストの品質をうまくチェックするにはどうすればいいのだろうか。稿ではまず品質の考え方を概観し、その後、チェックを現実化するツールを紹介していく(@IT編集部) プロジェクトマネージャ(=PM)の石出さんは今日も悩んでいます。 石出さん談――。 今度のプロジェクトは実装・単体テストを一括発注することになった。でも一括発注だとどのように品質をチェックしたらいいのだろう。いつものように目の前で作業をしてくれれば分かるんだけれど……。 なるほど、石出さんは実装・単体テストの品質に関して悩んでいるようです。 ◆ 品質の考え方 品質には大きく分けて2つの考え方があります。製品(システム)そのものの品質と製品を作成するプロセス(作り方)の品質です。前者は、

  • 最適な工期は「投入人月の立方根の2.4倍」、JUASが調査 ― @IT

    2007/07/05 日情報システム・ユーザー協会(JUAS)は7月5日、ユーザー企業102社の357プロジェクトを調査した「ソフトウェアメトリックス調査2007」を発表した。システム開発の企画、開発計画に始まり、保守や運用管理まで実態を調査した内容で、企業情報システムの実態を伝える。調査結果からは“デスマーチ”となるプロジェクトの実態も浮かび上がった。 デスマーチ化するプロジェクトの条件の1つは工期の設定が不適切であることだろう。調査から導き出された標準開発工期は「投入人月の立方根の2.4倍」。調査対象のプロジェクトの全体工数と全体工期をグラフ化し、回帰直線によって求めた。この計算によれば1000人月のプロジェクトの場合は24カ月の工期を設定するのが標準的といえる。事情によってこの標準工期よりも短い工期しか取れない場合は、その短縮率を計算して対策を採るべきとJUASは提言。だが、「(短

  • 第7回 有能なリーダーのナレッジを組織展開:ITpro

    プロジェクト・マネジメントは重要な技術領域である。プロジェクトを成功させるための人材ビジョン,スキル,標準の管理プロセス,技術,支援システムが存在する。この新たな技術領域を拡充するにあたって,有能なプロジェクト・リーダーのナレッジを抽出し,他人に教育し,組織全体のプロジェクト・マネジメント力を底上げすることが有効である。 野間 彰 記事は日経コンピュータの連載をほぼそのまま再掲したものです。初出から数年が経過しており現在とは状況が異なりますが、この記事で焦点を当てたITマネジメントの質は今でも変わりません。 今,プロジェクト・マネジメントの強化が求められている。例えば,金融機関のように,今後開発プロジェクトが多数計画されている企業では,若手社員をプロジェクト・リーダーへ早期に育成することが重要課題である。大規模かつミッション・クリティカルなシステムを構築する企業は,予算と納期の厳格な管

    第7回 有能なリーダーのナレッジを組織展開:ITpro
  • クリティカルチェーン・プロジェクトマネジメント(くりてぃかるちぇーん・ぷろじぇくとまねじめんと)

    不確定要素の多いプロジェクト型業務に、TOC(注1)の基原理を適用したプロジェクト管理手法。クリティカルチェーン(注2)という制約条件の下、プロジェクト各工程の締め切り厳守を積み上げるアプローチではなく、プロジェクト全体の納期を守ること(あるいは短縮すること)を目的に、TOCの提唱者エリヤフ・M・ゴールドラット博士(Dr. Eliyahu M. Goldratt)によって開発されたTOCプロジェクトマネジメント(注3)ともいう。 PERT(注4)に由来する従来のプロジェクトマネジメント手法が大規模プロジェクトにおける複雑なスケジューリング問題の数理的最適化を志向しているのに対して、プロジェクトという不確定度の高い作業を行う場合の人間心理や行動特性、および社会的・組織的問題に配慮して、全体最適なプロジェクト管理(スケジューリング、タスクの実行、進ちょく管理)を行う実践的手法である。 従来の

    クリティカルチェーン・プロジェクトマネジメント(くりてぃかるちぇーん・ぷろじぇくとまねじめんと)
  • へ〜たのめも:Google のソフトウェア・エンジニアリング - livedoor Blog(ブログ)

    2007年06月07日 Google のソフトウェア・エンジニアリング Google Developer Day Tokyo の鵜飼さんのプレゼンより、「Googleエンジニアはどうやって開発しているのか?」 Google の研修 入社して最初の 3ヶ月は社(Mountain View)で研修 研修中は、メンターがついて「Google での開発の仕方」を学ぶ 内部ウェブ・サイトで社内共有ライブラリの使い方などを説明する動画があるので、それで自習 Googleプロジェクト・チーム 開発拠点は米国、スイス、オーストラリア、インド、日など 場所とプロジェクト・チームは関係なく、プロジェクト・チームが拠点をまたがることは普通。世界中の拠点全部合わせて、一つの Google エンジニアリング・チーム 開発はデザイン、コーディング、テスト、改善、デモの運用まで上流から下流まで同じチーム(同

  • Part2 意思決定支援システムの機能

    Part2では,(1)データ収集,(2)データ蓄積,(3)Query & Reporting,(4)データ分析(OLAP),(5)モニタリング(ダッシュボード)という5つのステージの順に,各ステージで利用するツールの機能を説明しよう。 パート1では,意思決定支援システムの歴史を述べてきた。パート2では,意思決定支援システムの機能について見ていきたい。 一般的な意思決定支援は,大まかに次の5つのステージに分類することができる(図3)。 (1)データ収集 (2)データ蓄積 (3)Query & Reporting (4)データ分析(OLAP) (5)モニタリング(ダッシュボード) そして,次のような各ステージに適したツールが利用される。 (1)データ収集…ETL(Extract/Transform/Load) (2)データ蓄積…データ・ウエアハウス/データ・マート (3)Query & Rep

    Part2 意思決定支援システムの機能
  • 「決断できない、いい人たち」経営の功罪 - ビジネススタイル - nikkei BPnet

    「決断できない、いい人たち」経営の功罪〜冨山 和彦 産業再生機構 元代表取締役専務兼COOに聞く(1) (聞き手:荒川 龍=ルポライター) 産業再生機構(以下、同機構)は4年間の活動を終えて、2007年3月に解散した。同機構は、日政府が100%出資する株式会社として誕生。政府の10兆円の資金保証を背景に、民間から資金を調達するという日初のユニークな取り組みとして注目を集めた。いわば、「日政府版企業再生ファンド」で、代表取締役専務兼COOとして陣頭指揮に立ったのが冨山和彦氏(45歳)だ。ダイエーやカネボウなどの大企業から地方企業まで、債務総額約4兆円の合計41企業の再生支援を手がけ、取得した株式の売却益で約400億円の利益を計上。それらは国庫に納入されるという。 冨山氏は、同機構解散後の4月に、経営共創基盤という人材投入型の企業再生会社を新たに設立したばかり。企業再生の4年間を振

  • ITプロジェクトを失敗させないための7つのガイドライン

    組織のリソースを無駄にすることなく、ITプロジェクトによって組織の価値を高める責任は、ITマネジャーに課されている。稿では、これから新たに進めるプロジェクトを破局に導かせないためのヒントを幾つか紹介することにしよう。 現在ないし過去に行われたITプロジェクトにまつわる経験談は、ITインフラの構築や改善を目論んだものの、巨額の資金やエネルギーを浪費したあげく、何らの実りなく終わった事例の宝庫である。そのように組織のリソースを無駄にすることなく、ITプロジェクトによって組織の価値を高める責任は、ITマネジャーに課されているといっていいだろう。 多くの場合そうした責任は、数ある選択肢の中から最も有益に寄与するであろうプロジェクトを選び出し、その実施と管理に必要な手はずを入念に整えておくことで達成できるものである。そこで稿では、これから新たに進めるプロジェクトを破局に導かせないためのヒントを幾

    ITプロジェクトを失敗させないための7つのガイドライン
  • 「この開発プロジェクトは中止!」の基準 ― @IT情報マネジメント

    「方向付け」フェイズで評価するもの 「方向付け」フェイズには以下の目標がある。 ビジネス、プロジェクト、資金のリスクを特定して緩和する 技術と財政の両面からプロジェクトの存続能力を評価する プロジェクトの範囲と目的の承諾 前進に向けた全体計画の作成 どのプロジェクトも、少なくとも「方向付け」フェイズの資金は確保しておく必要がある。それ以降のフェイズについては、「方向付け」フェイズの結果に応じて資金調達を行う。 「方向付け」フェイズでは、プロジェクトが経済的に好ましくないか、あるいは技術的に実行不可能といったリスクの軽減に重点を置く。このためチームは、前進のための堅実な判断を下せるよう、プロジェクトの費用と便益を探求する必要がある。「方向付け」フェイズの最後では、プロジェクトが計画どおりに進めばプロジェクトの業務事例が実現可能であることを利害関係者が承認する。プロジェクトが生き残れるという点

  • 失敗から学んだプロジェクトマネジメント ― @IT自分戦略研究所

    いま、現場で求められているキャリアやスキルは、どんなものだろうか。連載では、さまざまなITエンジニアに自身の体験談を聞いていく。その体験談の中から、読者のヒントになるようなキャリアやスキルが見つかることを願っている。 ITエンジニアの中に「自分はマネジメント志向か技術志向か」を考えたことがある人は多いだろう。マネジメントスキルを身に付けるのか、技術を追求していくのか。人それぞれ考え方が違う。 サイボウズのグループウェア「ガルーン2」の開発マネージャを担当する佐野大輔氏は「最初はどちらかというと技術志向でした」という。それがいまでは「マネジメントのプロになりたい」と話す。そこに至るまでの経緯を聞いた。 ■人に使われるものが作りたかった 大学時代に情報工学を専攻していたという佐野氏。しかし、どちらかというコーディングではなく理論的な研究をしていたという。格的にソフトウェア開発を始めたのは社