タグ

managementに関するfivefourtyのブックマーク (32)

  • EPFプラグインでらくらく開発プロセス管理!(実践編)

    参考 稿で作成した開発プロセスのメソッド・ライブラリー(私のメソッドライブラリ.zip)およびパブリッシング結果(publish.zip)をダウンロードできます。ただし、この開発プロセスはEPFの機能を紹介するために作成したサンプルなので、実際の開発では活用できません。あらかじめご了承ください。 EPFの日語化 作業を開始する前に日語化対応させるための言語パックをインストールします。EPFのダウンロードサイトから言語パック(NLpack_epf-composer-1.0.1.zip)をダウンロードします。 言語パックを解凍すると、epf-composerというフォルダの中にfeaturesとpluginsというサブフォルダがあります。それらをEPF Composerのインストール先に上書きします。そのときに、フォルダの上書きを確認する意味のダイアログが表示されますが、[すべて上書き]

    EPFプラグインでらくらく開発プロセス管理!(実践編)
  • プロマネに必要な技術とは? - プログラマの思索

    以前読んでいた興味深い記事 「プロマネの鍵、貸します」 「プロマネに必要な三要素」を掘り出した。 この記事の内容がようやく腑に落ちるレベルまで辿り着いたので、自分の数少ない経験を交えながら、プロマネに必要とされる技術について考察してみる。 【1】経験から得たリスク感覚~リスク管理 管理職で働く人は、必ずリスク管理のスキルを持っている。必要条件といっていい。 リーダーと呼ばれる人は、チームメンバーを見て、お客さんを見て、スケジュールを見て、コストを見て、リスクを嗅ぎ取るのがうまい。 IT業界はリスク管理が甘いように思う。 どのプロジェクトでも、初めての技術、初めての業務をシステム化する時がすごく多い。 再利用できるライブラリやフレームワークがなく、いつも最初からスクラッチで作り始める。 同じ業界の業務経験があっても会社が違えば業務は大きく異なるのが普通だから、いつも最初から要件のヒアリングか

    プロマネに必要な技術とは? - プログラマの思索
  • Loading...

    Loading...
  • 小野和俊のブログ:IT業界の大企業での生々しい話を5つほど

    先日某所で講演をする機会があったのだが、 そこでお会いした大企業に所属されている方からの発言でいくつか印象的なものが あったので、ブログに書くことにした。 中にはぐったりしてしまうような内容のものもあるのだが、 会社が大きくなるとこういうことが起こりえるのだという自分への戒めも込めて。 とある大手 SI の方の話。 会社で 2ch へのアクセスを禁止したところ、開発の速度が目に見えて低下したので、 何が起こったのかと現場にヒヤリングしたところ、今までは困ったときに 2ch で聞いて問題を解決していたが、2ch にアクセスできなくなって、 はまってしまったときにどうにもならなくなってしまったとのこと。 これは Messenger / Skype を禁止している会社にも同様のことが言えるだろう。 プロが 2ch で聞くというのはどうなのかという意見もあるとは思うが、 会社の枠を超えた横のつなが

    小野和俊のブログ:IT業界の大企業での生々しい話を5つほど
  • わたしが知らないスゴ本は、きっとあなたが読んでいる: プロジェクトを成功させる魔法の言葉

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

    わたしが知らないスゴ本は、きっとあなたが読んでいる: プロジェクトを成功させる魔法の言葉
  • Ruby On Rails Bookmarks MOONGIFT

    Ruby on Rails製のブックマーク共有ソフトウェア ブックマーク毎の公開/非公開設定やスナップショット機能があるSBSです。 Ruby on Rails製のブックマーク共有ソフトウェア Ruby on Railsを使った開発案件をちらほらと聞くようになってきた。やはりこの開発の楽しさは一度体験すると手放せなくなる。 そこで、好例になりえるアプリケーションをご紹介しよう。 今回紹介するオープンソース・ソフトウェアはRuby On Rails Bookmarks、Ruby on Railsを使ったブックマークソフトウェアだ。 Ruby On Rails BookmarksはScuttleに似たインタフェースを持ったソフトウェアで、なぜかロゴが人の顔(作者?)になっている。ユーザ登録型なので、みんなで利用することができる。 特徴的なのは各ブックマーク単位で公開/非公開を切り替えられる事だ

    Ruby On Rails Bookmarks MOONGIFT
  • ITmedia Biz.ID:失敗しないプロジェクトマネジメント――Appleやはてな、Googleに学ぶ3つのヒント

    失敗しないプロジェクトマネジメント――AppleはてなGoogleに学ぶ3つのヒント:デジタルワークスタイルの視点 プロジェクトが失敗する要因は「計画」「やる気」「変化」の3つ。これらを管理しようとすればするほど悪いスパイラルに落ち込みます。AppleはてなGoogleなど、注目企業ではどのようなマネジメントを行っているのでしょうか。 「完璧に管理しようとすればするほど、プロジェクトは失敗する」という悪いスパイラルが存在します(2月21日の記事参照)。そこで今回は、どのようなプロジェクトマネジメントをすれば、プロジェクトを失敗させないようにできるのか考えてみたいと思います。 プロジェクトが失敗する要因は「計画」「やる気」「変化」の3つ。前回はそれぞれを完璧に管理しようとしていましたが、今回は考え方を180度変えてみましょう。それぞれの要因を最初からなくしてしまうのです。 失敗しない

    ITmedia Biz.ID:失敗しないプロジェクトマネジメント――Appleやはてな、Googleに学ぶ3つのヒント
  • 無料のプロジェクト管理ツール「activeCollab」をUSBメモリで動かす方法 - GIGAZINE

    前の記事、「The Uniform Serverを使ってUSBメモリタスク管理サーバを持ち歩く方法」では「The Uniform Server」をUSBメモリにインストールして使えるようにするところまでを解説しましたが、今度は実際にオープンソースのプロジェクト管理ツール「activeCollab」をUSBメモリで動かすことになります。 手順は以下の通り。簡単に「activeCollab」の動作画面も掲載しておきます。 ◆「activeCollab」のインストール まずは公式サイトにアクセスしてダウンロード activeCollab - open source project management and collaboration tool. http://www.activecollab.com/ ダウンロードしたら解凍し、wwwフォルダの中にまるごと移動 それから以下のアドレスにアク

    無料のプロジェクト管理ツール「activeCollab」をUSBメモリで動かす方法 - GIGAZINE
  • [ThinkIT] 第2回:「dotProject」をインストールする (1/3)

    第1回ではオープンソースのグループウェア「dotProject」の概要について解説しました。第2回では、dotProjectを実際にインストールしていきましょう。今回は以下のような流れでインストールを行います。 Webサーバ環境の構築 LinuxはRed Hat Enterprise Linux 4あるいはCentOS 4がインストールされていることとする 必要なRPM(RPM Package Manager)パッケージのインストールと設定をする各種サービスのサーバを起動する dotProjectのインストールと設定 dotProjectのダウンロード dotProjectのインストーラの実行 dotProject上で最低限の設定

  • [ThinkIT] 第1回:「dotProject」を知っていますか (1/3)

    「dotProject」を知っていますか。dotProjectはWebブラウザから利用できるグループウェアの1つです。ご存知のようにグループウェアは主に企業のプロジェクト管理、タスク管理、取引先の管理、社員の出退勤管理などで使用されています。グループウェアといえば、サイボウズ Officeやdesknet's、Lotus Notesなどをまず思い浮かべる方が多いと思います。 dotProjectの大きな特徴は、オープンソースソフトウェアであることです。dotproject.net(日語版はdotproject.jp)というコミュニティでソースコードが公開されており、開発も進められています。dotProjectは以下のWebサイトからダウンロードすることができます。

  • デモではものができあがっているように見せない

    Kathy Sierra / 青木靖 訳 2006年12月27日 (アルファ版のような)開発中のものを私たちが世間や、クライアントや、ボスに見せるときには・・・彼らの期待のレベルを設定することになる。これは3通りの方法でやることができる。磨き上げられたモックアップで幻惑するか、プロジェクトの現状に合ったものを見せるか、ほとんどできていないものを見せながら順調に進んでいるから「信用しろ」と言っていら立たせるかだ。 結論を言うなら: どれくらい「できている」ように見えるかは、実際どれくらい「できている」かに合わせるべきだ。 ソフトウェア開発者はみんなそのキャリアにおいてこのことを何度も思い知ることになる。しかしテクニカルライターもまた、デスクトップパブリッシングツールによって同様の問題に直面する——フォントやレイアウトが完璧に仕上げられたドラフトを誰かに見せるなら、その人はあなたが考えるよりも

  • 開発環境を学ぶということ (arclamp.jp アークランプ)

    arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 先日、稚北東京サテライトで客員教授会があったのですが、テーマの1つが「システム開発を学ぶ」というものでした。 すぐに気づくのは言語や実装方法を教えるだけでは足りないということです。Java開発を覚えるのであれば、Java言語を覚えるとかJavaEE(JSP、Servlet)とか、あるいはStrutsやSpringといったフレームワークというのは大きな一歩ではありますが、それだけでは足りません。 RUPにおける作業分野定義 RUPのdiscipline(作業分野)では、次の9つが定義されています(WikipediaのIBM Rational Unified Processより)。 Engineering Disciplines: * Business modelin

  • [ThinkIT] 第3回:プロジェクト進捗状況を「見える化」する (1/3)

    見える化がなぜ必要かを語った第1回、アイデアや思考をどのように見える化するのかを語った第2回、続く第3回ではプロジェクトの現状を把握する「プロジェクトの見える化」について解説する。第1回でシステム開発現場における混乱の原因の1つとしてあげられている「ソフトウェアの開発状況(進捗)が目に見えない」ことを解決するための見える化手法である。 タスクかんばんやバーンダウンチャート、にこにこカレンダーについては、第1回でも触れられているが、より詳しくそれぞれの目的と効果を解説する。 タスクかんばんは、タイムボックスマネジメントという考えに基づいて作られている。開発に限らず、プロジェクトには必ず存在する何らかの期限(顧客への納期、製品リリース日、広告の出稿期限など)を一定期間(タイムボックス)を単位として区切り、タイムボックスごとに、進捗を見極め調整をはかるチェックポイントを置く。 チェックポイントを

  • プロジェクト管理可能な日本語対応オンラインワープロ「solodox」

    現在はアルファ版なので無料提供中。主な機能としては、ワードプロセッサ機能、複数ユーザ同時編集コラボレート機能、ブログ投稿機能、ファイルダウンロード・アップロード機能、プロジェクト進捗管理機能、ドキュメント管理機能などを搭載。使用可能な言語は日語・中国語・英語。ちゃんと日語が通るだけでなく、エクスポート時も日語が化けないので、そういう意味ではかなりマトモに利用可能。 というわけで、実際に使ってみました。 Solodox http://www.solodox.com/ お試しで使うにはトップページにある「お試しはこちら」をクリック 「新規作成」をクリック 名前を入力後、「確定」をクリック こんな感じでドキュメントの作成が可能 作成したページはオンライン上に保存するだけでなく、HTMLファイル・RTFファイル・ワードファイル・テキストファイルとしてダウンロード可能 元に戻したり、検索や置換

    プロジェクト管理可能な日本語対応オンラインワープロ「solodox」
  • ウノウラボ Unoh Labs: チームリーダーが心掛けるべき10のポイント(テストチーム編)

    こんにちはー! やまもと@テスト番長です。 現在ウノウのテスト専任のスタッフは自分一人です。 いわば一人親方(建設業界用語)状態なのですが、 前職では総勢6人のテストチームを組織しておりました。 その頃心掛けていた、チームリーダー心得を書いてみたいと思います。 1.聞き上手になる 組織はコミュニケーションが命です。 話しにくいリーダーだと、必要な情報がうまく伝わりません。 気軽に相談を受ける・噂話が耳に入ってくるようでなくてはいけません。 そのためには聞き上手に徹すること。特に批判的な態度は控えることが重要です。 そんな相手には、誰も何も相談しないでしょう。 2.「おいしい仕事」を独り占めしない。 重要な判断や、やりがいのある仕事はなるべくメンバーに廻すようにします。 一見、重要な仕事はリーダーがこなすべき事のように見えますが、 その裏で他のメンバーがつまらない仕事

  • 「技術トレンドのおさえ方」を開発の現場に寄稿 (arclamp.jp アークランプ)

    arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 開発の現場 vol.006(2006年10月発売)の特集「はじめての開発リーダーToDoリスト」において、「技術トレンドのおさえ方」を寄稿しました。 つけていただいた副題は、 3つの力「見極める」「説明する」「活用する」で"使えるもの"を的確に把握しよう 少しだけイントロを。 優れた新しい技術をたくさん知っていれば技術を「おさえる」ことができるようになるのでしょうか。それは残念ながら違います。それに、それだけの技術情報をすべてチェックすることは難しいでしょう。 自動車業界を例に考えてみましょう。優れた最新の技術を結集したものの代表といえばF1カーが思い浮かびます。F1カーで使用する優れた技術を知っているというのは良いことです。膨大な労力をかけて得たその知識は大変貴重な

  • ITアーキテクトはリーダーかマネージャーか (arclamp.jp アークランプ)

    先日、チェンジ・マネージメント・コンサルティングの森さんにお話をお伺いする機会があったときに、リーダーとマネージャーの違いについて、こういわれていました。 リーダーとは、変革を起こす人 マネージャーとは、複雑さに対応する人 なんとなく腑に落ちたというか、やっぱり大きく異なる役割なのだなと納得しました。 例えば問題が発生した場合にでも両者の行動は異なります。マネージャーはスケジュールやリソースを調整し「対応」プランを考えます。リーダーは問題を問題(悪いこと)と捉えずに、これを機会としてより最適な成功につなげようとする気がします。 リーダーは未来を見つめ、マネージャーは人を見つめる ちょっとググってみると色々見つかりました。All About コーチング・マネジメント ガイドの「あなたはリーダー? それともマネジャー?」では、マーカス・バッキンガム氏の『最高のリーダー、マネジャーがいつも考え

  • Passion For The Future: ホワイトハウスの超仕事術―デキるアシスタントになる!

    « 複数のP2P検索サイトを一括してファイルを探せるTorrentCascade | Main | 運命ではなく » 書評:脳・こころ |書評: 企画・発想| 書評文化・文明|書評:経済・経営 |書評:子 供・教育|書 評:小説・戯曲|書評:ネット活用 |書評仕事・管理|書 評:メディア論|書評:その他|書評:思想・哲学 |書評 :文章・表現|書評:認知・心理 |書評:神 話・宗教|書 評:科学・技術書評:社会・世間 |書評教養 ・雑学 2006年度 年間オススメ書籍ランキング ノンフィクション部門 2006年度 年間オススメ書籍ランキング フィクション編 2005年度 書籍売り上げラン キング ベスト20 2005年度 年間オススメ書籍 ランキング ベスト20冊 2004年度 人気記事ベスト10 アクセス数が多かった記事とは? 2004年度 人気書評ベスト10 アクセス数が多か

  • 「ソフトウェア開発の名著を読む」を読む

    「めいちょ」と銘打たれるとなかなか手が出せないもの。大著であることも多いし、何より難しそうなイメージが先行してしまう。さらに、たいていは「古典」…なので、書店で平積みになってる賞味期限 1 年のハウツーみたく目に入ってこない(←こちらからアプローチをかけないと手に入らない)。 というわけで敬遠していた方へ朗報。「ソフトウェア開発の名著を読む」で手軽に「めいちょ」の品定めができる。この手のカタログだと、「コンピュータの名著100冊」が有名だが、これはたったの8冊の紹介、しかも新書なので30分で読める。 しかも、言語は問わない。もちろん FORTRAN や Pascal といった「古語」のコードが出てくるが無問題。伝えたい何か、例えば「プログラミング作法」や「よいコードを書くための習慣」を表現するための、レトリックとしてのコードなのだから。 とどめは、昔から、誰からでも、何度でも指摘されて

    「ソフトウェア開発の名著を読む」を読む
  • プロジェクトは失敗するのが当たり前!? ― @IT情報マネジメント

    ITプロジェクトが失敗する理由は、成功することを前提としたマネジメントが行われているためである。ITプロジェクトの成功率は思いのほか低く、このような状況を改善するためには「失敗を前提としたマネジメント」を心掛けなければならない。失敗を前提としたマネジメントとは、リスクマネジメントに重きを置いたマネジメントということになる。 ITプロジェクトのほとんどは失敗に終わる 成功率16%。これはある開発ツールベンダが調査した米国におけるITプロジェクトの成功率である。その調査によれば、昨年米国で遂行されたプロジェクトは約17万件であり、そのうち、機能、予算、納期などが当初の想定内に収まったものは16%だったという。 日においてもほぼ同じ状況であるといえる。「企業IT動向調査2006」(社団法人 日情報システム・ユーザー協会)に調査によれば、システムの仕上がりに満足と回答したユーザーは10%前後に

    プロジェクトは失敗するのが当たり前!? ― @IT情報マネジメント