![無料で使えるプロジェクト管理ツール「gantter」を使ってみて、これはもう手放せないと思ったポイント3つ | バシャログ。](https://cdn-ak-scissors.b.st-hatena.com/image/square/1f4390ea5b2b558adfd9c349b9a080aae407daff/height=288;version=1;width=512/https%3A%2F%2Fbashalog.c-brains.jp%2Fshared%2Fpublic%2Fimg%2Fcommon%2Ficon_ogp02.png)
2017年6月30日 便利ツール 「海外Webサイト・海外Web屋の特徴」でも少し紹介したプロジェクト管理サービス、Basecamp。「日本語版があれば使ってみようかな」という人がいたのですが、実は日本語に対応しているのです!アカウントの作成、言語の設定を含めた、Basecampの簡単な使い方を紹介します! ↑私が10年以上利用している会計ソフト! Basecampとは? Basecampは37signalsが提供しているオンラインプロジェクト管理ツール。「よりシンプルに使いやすく」をテーマに作られ、海外では企業やフリーランサーに大人気です。チームメンバーとタスクを共有することで、誰がどんな業務を持っているのか、どこでつまづいているのかなどがわかるようになり、結果プロジェクトの進行がスムーズになると思います。 Basecampの特徴 メッセージボード、ToDoリスト、マイルストーン、Whi
Kanon LABへようこそ Kanonは、プロジェクト管理のための総合ソリューションです。チケット(Trac)、バージョン管理(Git,Subversion,Mercurial,Bazaar)、CI(Jenkins)の3つの機能を統合して提供しています。 名前の由来 カノンとは、キリスト教の聖書教典のことで、クラシック音楽のカノン (同じ旋律が繰り返し演奏される輪唱)のことでもあります。クラシック音楽のカノンの 中でも有名なパッヘルベルのカノンは、本来弦楽器のために書かれたものですが、 ピアノ独創やポップ、ロックなど、様々な分野でそのメロディはモチーフとして使われ ています。Kanonは みなさんのプロジェクトの教典になるように プロジェクト毎にアレンジして使えるように カノンの用にメロディを変化させながら何度も詠唱できるように という意味をこめて名づけました。 インストール方法 # h
チームの業務を見える化してタスク漏れやスケジュールの遅延を防ぐ Backlogはシンプルな操作性と親しみやすい見た目で、誰でも直感的に使えるプロジェクト管理・タスク管理ツールです。 ※1:2023年12月末時点。サービス継続率は各前月の有料契約総数に占める解約数を引いた割合 ※2:スマートキャンプ株式会社主催 BOXIL SaaS AWARD 2024 BOXIL SaaSセクション プロジェクト管理・工数管理部門で受賞 /「BOXIL SaaS」上に投稿された口コミを対象に、「使いやすさ」においてプロジェクト管理・工数管理部門部門で最も高い平均点を獲得したサービスをスマートキャンプ株式会社が選出(対象期間:2022年7月1日~2023年6月30日) ※3:ITreview主催 Best Software in Japan 2024 TOP50入選 Backlogでプロジェクト・タスク管理
7 Common Project Management Problems (And How to Solve Them) [ad#ad-2] 下記は各ポイントをピックアップしたものです。 曖昧な要件 プロジェクトがある程度進行しないと、クライアントがどうしたいかはっきりしない場合は、マイルストーンを設定するようにします。明確なステップを設定することで、プロジェクトの最初から最後までが綿密に計画されるようになります。 もし途中で大きい修正や変更が入る場合は、それに必要な工数をクライアントに明確にし、請求の必要があれば行うようにします。 コミュニケーションによる遅延 クライアントの返答待ちで、プロジェクトを進めることができないことがあります。これはちょっとしたことで、クライアントの返答を早くもらえるようにする戦略があります。 それは、「Yes」か「No」で返答できるように質問することです。これ
プロジェクト管理を行う上で、そのスケジュールの作成や管理にどういうツールを利用しているだろうか。実際の現場では「Microsoft Office Excel」(以下、Excel)が圧倒的に使われているだろう。TechTargetジャパンが2008年に実施したプロジェクト管理ツールの利用状況調査でも、回答者の約68%が管理ツールとしてExcelを使用しているという結果が出ている。中には、独自に作成したマクロ機能を駆使して、プロジェクト管理用にカスタマイズしているユーザーもいる。 Excelは本当に、プロジェクト管理に最適なツールなのだろうか? 本稿では、プロジェクト管理専用ツールである「Microsoft Office Project」(以下、MS Project)とExcelの2つのツールにおいて、実際にスケジュールを作成・管理した場合に使用した機能や作業時間の測定結果などを紹介する。今回
情報処理技術者試験プロジェクトマネージャは、IT業界では技術者に取らせたい資格No.1、および営業効果の高い資格No.1 の座に輝いています(日経ソリューションビジネス 2007年11月15日号を参照)。名実ともに、重要で効果的な資格であることは間違いありません。 しかし、ただでさえ忙しいエンジニアの方が、プロマネ試験の勉強時間を確保することは容易なことではありません。事実プロマネの平均受験率は約56%(*1)であり、受験勉強を継続することすら難しいのが実状です。 (*1)IPA情報処理技術者試験センターの統計情報を参照。2008年4月 時点のデータ。 そして実はここにプロジェクトマネージャ試験合格の秘訣があります。実務経験が豊富な人ほど、試験勉強を継続してしっかり行えば、それほど難しい試験ではないのです。ですから、試験に合格するために最も重要なことは「プロジェクトマネージャ試
プロジェクトマネジメントの様々な側面から、業務を効率化するためのツールを公開しています。ここに公開するツールは、プロジェクトマネジメントの手法を使用しやすくツール化(アプリケーション化)したものや、テンプレート化したものです。 複数の知識領域にわたる手法を統合して活用できるようにしたツールは、実務で特に役立ちます。たとえば、WBSの作成から、メンバのアサイン、スケジュールの作成までを統合したツールなどです。また、テンプレートの例としては、”リスク管理簿”をExcelでテンプレート化したものなどがあります。 このようなツールを組み合わせて活用することで、自分独自のプロジェクトマネジメント道具箱を作ることができます。
既存のプロジェクトマネジメント手法の落とし穴とは?:プロジェクトは「やる気」で成功する(1)(1/2 ページ) これまでも数々のプロジェクトマネジメント手法が考案されてきたが、現在も数多くのプロジェクトが失敗に終わっている。それはなぜか? 制約理論を提唱したエリヤフ・M・ゴールドラット博士は工学的な視点で既存手法の問題点を指摘したが、竹之内隆氏は人間的な見地から既存手法の新たな落とし穴を指摘する。 人は論理のみでは動かない、動かせない 複数のメンバーが参加するプロジェクトをスムーズに遂行するためには、計画を策定するプロセス、それを実行するプロセスの両方において、全関係者が足並みをそろえなければなりません。そのためには、論理的な戦略と、それに基づく漏れのないWBSが不可欠とされています。しかしそうした要件を満たしていても、現実には数多くのプロジェクトが失敗に終わっています。 なぜうまくいかな
久しぶりに記事を書くなぁ。 しばらく忙しかったので、サボってました・・・ そしたら、年が明けてしまったよ。 さて、話は変わって、私はSEPGのリーダとして、いろいろなプロジェクトの進捗を見ることが常です。 そのような中で、 「進捗は何日(もしくは、何人日)遅れ?」 と聞くことは多い。 これは、顧客からも、そのような進捗報告を求められることが多いし、WBS線表では、遅れ日数が進捗を把握する対象となるため。 でも、進捗は、遅れだけ管理していても回復しない、というのが私の感覚。 遅れだけ見ていると、遅れが拡大していることには気づきにくい。 「タスクAは、3日遅れ」という進捗状況ならば、そのタスクは3日経てば完了しているはずだが、多くの場合は完了するまでに3日以上かかる。 そのような場合、「タスクAは、あとどれだけかかかるの?」という質問をすると、3日遅れであっても「5日ぐらい」という回答になるこ
MS Projectで学ぶプロジェクトマネジメントの基本:MS Projectで学ぶプロジェクトマネジメント(1)(1/3 ページ) 現在、IT業界の仕事のほとんどはプロジェクト形式で動いている。そこで、本連載ではプロジェクトで最も重要といえる進ちょく管理について、プロジェクトマネジメントツールの標準ソフトウェアといえる「Microsoft Project」の使い方を、具体的に分かりやすく紹介していく。 近年、IT業界で働いている方は「プロジェクト形式で仕事をしている」という方がほとんどではないでしょうか。 数あるプロジェクトの中には、うまくいくプロジェクトもあれば、失敗するプロジェクトもあります。では、なぜそのような差が生まれるのでしょうか? 原因にはいろいろな理由が挙げられますが、大きな理由の1つに「プロジェクトマネジメントがうまくいかなかった」という点が挙げられます。 IT業界で働く
しばらくブログ更新してませんでしたが、12月頭までプロジェクトが大変だった&その後燃え尽きてたのが原因です。 リハビリがてら、そのプロジェクトの反省でも書いてみます。長くなりそうなので、まずはプロセスや運用面の話から。 プロジェクトの概要 某サービス会社向けの Web アプリケーション開発 既存システムを置き換える形なので、要件のブレは少ない 今回はフレームワークとして Rails を使用 開発期間は 2009/08〜2009/11 の 4 ヶ月+α。その前に要件定義や調査は少し実施。 開発メンバは 4 人 1 人(私)は渉外やサーバ構築やデータ移行で時間を取られていたので、開発メンバは実質 3 人。 この 3 人は 全員 Ruby や Rails の経験なし。というか開発経験がない or 数カ月といったメンバばかり。 さらに本来アーキテクトとして入る予定だった私が全然そちらに関われなかっ
様々な事情によりソフトウェアのリリース時期が決まっているのは仕方ないにしても、出来もしない開発日程を無理に現場に押しつけると失敗の可能性が高まる。一般的に、プロジェクト責任者は早期のリリースを望むので短めの工程を出し、現場の担当者は様々なリスクを想定するので長めの工程を出しがちだ。立場の違いから見積もり工数の差が生まれるのは仕方ないにしても、その差を縮めて両者が合意できる日程に持ち込むのがリーダの役目だろう。しかしながら、リーダがそんな役割を放棄して一方的に工程を宣言して開発が始まってしまうと、これは危険プロジェクトの兆候だ。 特に、両者の違いが有ればあるほど失敗の可能性は高い。工程の見積もり差違が「3倍以上」というプロジェクトを見たことがあるが、案の定デスマーチとなり、リリース時期は延期に延期を重ねた挙げ句、最終的な工程は3倍を大きく超える結果となった。どうしてこんな開発プロジェクトにゴ
日々の新規開発をRedmineのチケットで進捗管理して気づいた点があったのでまとめてみる。 【1】ロードマップを見ると、進捗率が逆に下がる場合がある 下記のロードマップになるようにチケットを登録したと仮定しよう。 ◆ロードマップ1:5月1日現在 進捗:0% #1 機能Aの開発(新規) #2 機能Bの開発(新規) #3 テスト(結合テスト)(新規) すると、普通は、0%→33%→66%→100% と進捗率が上がって終わるはず。 ◆ロードマップ1:5月5日現在 進捗:100% #1 機能Aの開発(終了) #2 機能Bの開発(終了) #3 テスト(結合テスト)(終了) しかし、テストでバグが上がったり仕様変更が入った時、バグ報告をチケットに登録すると、下記のようになる。 ◆ロードマップ1:5月6日現在 進捗:42% ← 終了3件/全7件だから。 #1 機能Aの開発(終了) #2 機能Bの開発(終
みなさんこんにちは。@ryuzeeです。 アジャイルに関する間違った理解、よく聞く誤解について整理しました。 アジャイルだから仕様変更は自由?スプリント中で実装中のプロダクトバックログアイテムの変更とスプリント内で実装するプロダクトバックログアイテムの追加は開発チームが受け入れない限り勘弁してください。 それ以外のプロダクトバックログアイテムの追加は歓迎しますが、変更や追加を行えば行うほど費用はかかる可能性があります。 もしくは優先順位の低い他の機能と入れ替えになります。 無制限・無費用な変更はありえません。 アジャイルだから画面から決める?そうとは限りません。 何を表示したいか、何をさせたいかは決めますが、コテコテに画面遷移やUIから決める必要は必ずしもありません。 UIの層は一番変更かけやすく終わりもありません。 UIがビジネス上の大きな価値を持つので無い限り、UIの細かい調整は後回し
photo credit: Mackトラ ソフトウェア開発プロジェクトの現場では課題やバグ、タスクを管理するために、RedmineやTracなどのIssue Trackin System(課題追跡システム。以下ITSと表記)を使っていることが多いと思います。 ITSを使えばこれらの情報を一元化しプロジェクトメンバ間で共有できるため、うまく使えばとても役立ちますよね。 しかし、あまり深く考えずに導入すると、 「入力が大変だし余分な手間が増えただけだよ…」というメンバーからの不満の声 「この課題って本当に終わってるの?」といった疑心暗鬼 「このタスク、誰も進めてなかった!」という驚愕の事実が期限前日に判明 などといった状況に陥りがちです。 ここでは、いくつかのプロジェクトへ導入した経験から得た、ITSを運用する上で重要(と考える)な6つのポイントを紹介します。 ポイント1 チケット項目はマ
チケット駆動開発についてのFAQをまとめてみた。 他に聞きたい質問があれば、コメントして下さい。 チケット駆動開発のFAQを集めれば、チケット駆動開発を普及させるのに役立つと思うから。 【元ネタ】 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) TiDD:チケット駆動開発: ソフトウェアさかば RedmineとTracの機能比較: プログラマの思索 脱Excel! Redmineでアジャイル開発を楽々管理 - @IT自分戦略研究所 Tracのワークフロー: プログラマの思索 ワークフロー機能のカスタマイズ方法 - かおるんダイアリー そろそろTracのワークフローについて語っておくか - almost nearly dead チケット駆動開発は進捗報告作りをどのように解決しようとするか?: プログラマの思索
議事録をTracへ載せる話は「議事録はTracへ」に書いたけれど、今度は仕様書の話。ソフトウェア開発の構成管理にはSubversionを使っており、その中にはソースコードだけではなく、WordやExcelで作った資料も入れるようにしている。以前はサーバの共有フォルダに入れていたけれど、色々な面で問題が有ったのでSubversionとTracを使うようにした。目的は下記の通り。 仕様変更の確実な履歴管理 Wordファイル自体に変更履歴を管理する機能はあるけれど、ファイルを開いてみなければ分からないし、必ず履歴が残っているという保証も無い(誰かが変更箇所を承認してしまった等)ので、あまり使える機能ではない。確かに、短期的に変更点を知ってもらうには分かりやすくて便利なのだけど、長期的な保存に耐えうる機能ではないと思う。そこで構成管理へ入れるようにすれば、遙か昔の履歴も確実に残るので安心だ。 ソー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く