GitHub連携なのに依存関係を表現できるプロジェクト管理ツールの決定版「CodeTree」（設定方法の解説つき） - Tech Blog
プロダクトマネージャーのわたです。メガネとウイスキーとコーヒーを愛するメガネです。最近はASYLUM ROASTERSのコーヒーがお気に入りです。今回は、プロジェクト管理ツールの話です。 ご紹介するのはCodeTreeです。GoodでGodなポイントは以下の通り。 GitHub複数リポジトリのIssuesをひとつの画面で管理できる 並び順で優先順位が表現できるリスト表示 GitHub Labelsと連動するカンバン表示 Issue間の依存関係がぱっと見でわかる このツールは「プロジェクトの全体像が見たいぜ」というマインドの人と、「開発作業中はGitHubだけ開いていたいです（それ以外に見るものを増やしたくないよ！）」というマインドの人が、平和的にSyncできます。 プロダクトのIssue/ユーザーストーリー管理をしたり、開発プロジェクトマネジメントに情熱を燃やすPM族の皆さんに、ぜひおすす
スケジュールを作るプログラマが一番効率が良い。 - レベルエンター山本大のブログ
現場の周りのプログラマさんたちが残業する中、 僕が毎日定時で帰って高品質なプログラムを作れる理由は、 僕が自分でスケジュールを作ってから仕事を始めるからだ。 僕が今の現場に入って始めにリーダーさんからこういわれた。 「スケジュールがきついので、 管理工数がもったいないから、管理資料に手間をかけたくありません。 イキナリ作業に入ってもらってかまいません。」 若い頃ならうっかりその言葉に惑わされているところだが、 そうはいかない。スケジュールがきつい時ほどコントロールが必要なのだ。 何を先にやっておかないといけないか、 今週末までにどこまで進めておけば安心か。 これらがわからなければ、不安に駆られるばかりだ。 不安を取り除くという意味だけでもスケジュールを組むことは非常に役に立つ。 ドラッカー風に言えば、 「ミッションに集中するにはマネジメントを駆使しなくてはならない」 ということだ。 プログ
朝会を15分で終わらせるには理由がある
前回（第2回 「なにはともあれ、まずはチームビルディング」）はチームの基本的な作り方を解説しました。今回のテーマはチームの運営に不可欠な「会議」の上手な行い方です。 会議・会議・会議 プロジェクトにかかわる以上、会議は避けて通れません。特にリーダーなら、なおさらです。いままでは、どこかしら「関係ないや」と感じていた会議にも参加しなくてはいけません。会議にも大小さまざまありますが、今回はその中から、「朝会」「進捗（しんちょく）会」を取り上げて、それぞれの運営のコツをお話しします。 ・朝会 まずは小さな会議代表として、朝会です。朝会は、チームの状況をチーム内部で素早く共有することを目的とした、非常に短時間の会議です。最近何かと話題の朝会ですが、その理由として、「手軽に、すぐに始められる」「効果が見えやすい」「ソフトウェア開発チーム以外にも有効」などがあるでしょう。以下、概要だけ説明します。 朝
第69回 たかが議事録、されど議事録
会議の進行どおりに発言を記録していくような議事録は、あえてムダだと言いたい。それぞれの会議には、それぞれの目的がある。その目的達成を助けるような議事録を作れなければ、議事録の作成時間は大いなるムダとなるはずだ。 後藤 年成 マネジメントソリューションズ マネージャー PMP 皆さんの仕事場では、議事録を残しているでしょうか。PMOとして仕事をしていると、会議のファシリテートと同じぐらい、会議の議事録をとる機会（仕事）が多く、筆者も議事録の作成をどのように効率化しようかといろいろ悩みました。 特に最初は、「どの程度まで議事を記録すればよいのか？」「何を言っているのか分からず議事録がとれない！」「議事録にしたくとも、結局、何も結論が出ていない！」など、議事録の作成で苦労した経験があります。今回はPMOとして議事録にどのように向き合い、どのような議事録を作成すればよいか考えてみたいと思います。
［コミュニケーション編］議事録を相手に任せてはいけない
議事録を一度も書いたことのない読者はいないだろう。おそらく誰もが新入社員時代に書き方を教わる文書で、誰もが書くのに苦労する文書である。一所懸命時間をかけて作成した議事録を上司や先輩に持って行ったら、真っ赤になって返ってきたという経験をした読者も少なくないはずだ。議事録とはビジネスに無くてはならない文書の一つで、それはシステム開発プロジェクトにおいても同様である。プロジェクト内で作成する数多くの文書の中で、議事録ほど数多く作成される文書はない。 初めてPMに抜擢された中堅社員Sさんの経験 Sさんは大手通信企業の情報システム部門で働く中堅社員である。若い頃はプログラマとして働き、数年前に社内SEとなり実績を重ねてきた。そして今回、自社のシステム再構築に当たり、初めてPMとして抜擢されたのだった。 今回のプロジェクトは開発規模が比較的大きいので、大手SIベンダーのB社と一緒に開発を行うことになっ
［報連相編］報告を受けておしまいにしてはいけない
PM（プロジェクトマネジャー）はとかくメンバーから報連相されるのを当然だと思いがちだ。しかし忙しいさなかに報連相をし続けるのは、メンバーにとって、それなりのエネルギーが必要だ。特に書類で報告する場合、手間も労力もかかる。 書類による報告をしたときにメンバーが気になるのは、「報告した内容をPMは読んでくれたのかどうか」「読んだ結果、PMはどう思ったか」だ。このとき、PMから的確な指示やアドバイスといったレスポンスが全くなく、報告がただブラックホールに消えていくような状況だと、あっという間に送り手のエネルギーは尽きて、正確な内容の報連相は途絶えてしまう。 「コミュニケーションはキャッチボール」という言葉がある。投げられたボールをつかんで投げ返す。ただそれだけのことなのだが、これができるかどうかで報連相がうまく機能するかどうかが決まるのである。 読んでいることを伝えなかったDさんのケース あるS
属人性排除の功罪 - 人と技術のマッシュアップ
ソフトウェアの開発においては長年、属人性の排除が叫ばれてきました。今回は属人性の功罪について考えてみます。 属人性の排除の目的 定められた成果物を作成することにより、他の人にも理解しやすいようにすること 誰が担当しても一定の品質を保つことを可能にすること 成果物が一定の形を為しているため工程管理しやすい だいたいこんな感じだと思います。私もメーカ時代には規約を作成したり、成果物の設計をしたりしていました。まぁその時は当たり前に良いことだと思って取り組んでいたわけですが・・・ 属人性の排除によるデメリット 製品品質としては安定するけれども、一方でコード品質は下がる プログラマとしての価値は一定となり、個人の生産性が無視される プログラマのスキルが低レベルで一定となり、優秀な人材が辞めていく どういうことかというと、こういった属人性の排除を行うには、規約を決めたりするなどの制約を課すことになり
開発プロジェクトのリカバリープラン - 勘と経験と読経
ソフトウェア開発プロジェクトでは、どんな開発方式をとっていたとしてもスケジュール等に遅れが発生することはある(それが人の御業である限り)。そんな時にはプロジェクトを立て直す(リカバリーする)ためのプランを立てて実行することになるが、これをリカバリープランと呼んでいる。リカバリープランを自分で立てることもあるし、人のリカバリープランを見ることもあるけれども、おさえておくべきポイントがあると思う。 科学的に取り組む。精神論で立ち向かわない。 単純にブラックであること以上に、精神論で状況に立ち向かうことは関係者に多大な迷惑をもたらす。サイコリバカリーはよくない。 利害関係者と状況を共有することができない。 「今やってます」という回答を繰り返す、いわゆる蕎麦屋の出前状況になってしまう。 何らかのタスクの終了を待っている人が見通しを立てられない。 利害関係者からの協力がやりにくい。 もし少しでも状況
計画性ゼロ＆コミュ障の私でもできるようになった!webディレクター1年生の時教わった進行管理の要所5点
小中学生時代、夏休みの宿題絵と作文を書くこと以外のほとんどを放置し、8月31日に泣きながらやる・・・ということを繰り返していた。やりたいことは集中しやりたくないことは徹底放置。しかもコミュニケーション苦手。そんな残念っぷりを如何なく発揮し成長したため、当然、大人になった今でも進行管理は苦手だ。「自分の管理さえままならないのに、他人も含めたプロジェクト管理なんて恐ろしすぎる。」そう思っていたけど、どういうわけか社会人になったら進行管理のお仕事もする必要にせまられ、無我夢中でこなし、現在に至った。 現職で進行管理ベテランの先輩に「進行管理苦手だ」と話したら、「え、あなたって進行管理苦手だったの？そうは見えなかった」といわれてびっくり。一応webディレクターのレベルには達したのかもしれない。その礎を築いてくれたのは、前職制作会社で私の教育役だった敏腕ディレクター、Yさんの功績だ。私の進行管理は今
mixiのコードレビューについてご紹介 - mixi engineer blog
こんにちは技術部たんぽぽグループのmasartzです。でも今日はコードレビューアのmasartzとしてお送りします。 mixiの開発フローにはコードレビューという工程が含まれています。 今回はこの工程を行うコードレビューアな人々と、その業務内容、今後（の予定）などをお話しようと思います。 コードレビュー業務 mixiのサービスがスタートしたのは2004年2月の事ですが、コードレビュー業務が始まった正確な日時は残念ながらわかりません。 レビューツールもemailのやりとり->Tracのチケット->JIRAチケットと変遷があるため、最古のものをトラッキングできないのですが、おそらく5年以上前から様々な変遷を経て、今に至ります。 開発者が増えると、開発されるコード量も増えます。つまりレビューする量が増えるため、コードレビューアも増加します。 そんなこんなで現在ではアプリ開発者に対して、コードレビ
DevOpsによるビジネスの改善をメトリクスとして計測する方法。DevOps Day Tokyo 2012
DevOpsによるビジネスの改善をメトリクスとして計測する方法。DevOps Day Tokyo 2012 DevOpsに関する国内最大のイベントとなった「DevOps Days Tokyo 2012」が5月26日に都内で開催されました。 前の記事「DevOpsを実践する企業に共通すること。DevOps Day Tokyo 2012」では、John Wills氏の講演を紹介しました。この記事では、企業の中でDevOpsを通してビジネスを改善するために欠かせないメトリクスについて解説した、Damon Edwards氏の講演のハイライトを紹介します。 DevOps Business Justification and Metrics DTO Solutionsの共同創業者、Damon Edwards氏。 普段はインフラについてのコンサルティングなどをしている。eコマース、金融、オンラインゲーム
ソフトウェア開発プロジェクトは「負ける」宿命なのか - 勘と経験と読経
「どうやったらプロジェクトの失敗を防げるか」について話していたら、後輩の一人が面白い事を言った。「システム屋は最初から負けている」。くわしく聞くと、こういうことらしい。 ソフトウェア開発プロジェクトの総予算は早い段階で確定していて、増額は困難である。 早期に全ての要求を見通すことは不可能であり、プロジェクトを始めていくとスコープは少しづつ増えていく。原価も増えていく。 プロジェクトを開始した以上、途中でバスを降りることは不可能である。収益が悪化しても走り続けるしかない。 故に、われわれシステム屋は「負ける」宿命を負っている。 いろいろとツッコミどころはあるのだけれど、想う所を整理してみたい。 じゃあビジネスアジャイルだ、ということではない アジャイル脳的な反応が容易に予測できる。 最初に大きく計画し一括で開発しようとすること自体が誤り。リスクを極小化しビジネス価値を最大化するために、アジャ
仕事の段取りはデッドラインから逆算して考える - rabbit2goのブログ
「時間が無い」という人に限って余計な話が多いのは、なかなか興味深い事実だけど、そんな人の世間話、愚痴話、無駄話、閑話、噂話に付き合っていたらいつまで経っても自分の仕事が片付かないので、ふんふんと適当に相槌を打って切り上げることにしている。そんな冷たい態度を取って人間関係が悪くなったらどうしよう？なんて言い出す人もいるけど、そのような考え方は余りにナイーブ過ぎるのではないだろうか。人は人、自分は自分と割り切って生きて行かない限り、ひたすら他人に流されるだけの人生になってしまうのだ。 とは言え、そんなドライな生き方をしていても、残念ながら自分の仕事は山積み状態。これを全部片付けるまで頑張らなきゃと、昔はまじめに取り組んでいたような気もするが（もう忘れた）、人間歳を重ねると要領を覚えてくるので、実はそれほど手間はかからなかったりする。そんな考え方の一例。 まずは80%を達成して目処を付ける 締め
海外でなぜアジャイル開発が普及しているのか？ IPAが分析と提言
海外ではなぜアジャイル型開発が普及しているのか、IPA（独立行政法人情報処理推進機構）が継続的に行っている非ウォーターフォール型開発についての調査や提言活動の一環として、海外でのアジャイル開発の背景などについての報告書「非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査報告書 （非ウォーターフォール型開発の海外における普及要因編）」が公開されました。 調査対象国は、アメリカ、イギリス、中国、ブラジル、デンマークです。アメリカはアジャイル宣言が行われたアジャイル開発先進国として、イギリスもアジャイル開発の先進国として選ばれ、中国は日本のオフショア先であり新しいソフトウェア開発市場が起こりつつある国として、ブラジルはアジャイルコミュニティが活発化しており、デンマークは政府がアジャイル開発を推進している国として選択されました。 報告書のハイライトを紹介します。 海外でなぜアジャイル
日本型ソフトウェアファクトリーこそ真の敵 - 勘と経験と読経
最近ネットで話題になったスライド「ウォーターフォールの歴史」を見ながら、むしろ皆の仮想敵はウォーターフォールではなく、日本型ソフトウェアファクトリーなのではないかと考えた次第。 最近アジャイル界隈でよく聞く話 「自分の現場がウォーターフォールで全然ダメで それをアジャイルなら変えられないかと思って」 いったい誰と戦っているんだ・・・・・・ History of WaterFall - Speaker Deck 真の敵はこいつだ！ ソフトウェアファクトリ software factory / ソフトウェア工場 / ソフトウェア生産工場 組織的ソフトウェア開発アプローチの1つで、ソフトウェア開発に関する手順、手法、ツールを標準化してノウハウや知識、成果物の蓄積と再利用を促進し、厳格な工程管理・品質管理を適用することで、ソフトウェア開発の生産性と品質を向上することを目指すコンセプトのこと。また、
プロジェクトの失敗パターン
今回は「世の中のプロジェクトの典型的な失敗パターン」をご紹介したいと思います。 私自身、これまでに数多くのプロジェクトを見てきましたが、うまく行っていないプロジェクトにはやはり共通したパターンがあります。これまでのおさらいも兼ねて、皆さんのプロジェクトにも同じようなパターンが見られないか、代表的なパターンと比較しながらチェックしてみてはいかがでしょう。 「プロジェクトのゴール」が曖昧 まずはコレ。「何のために行うのか」、「何が実現されれば良いのか」が曖昧なままにプロジェクトが進められるパターンです。 このパターンでは、プロジェクトに多くの影響が現れることになります。例えば、ゴールがないと最短ルートが見えずに非効率となりますし、プロジェクトのスコープを追加したいなどという要請があった場合の判断が難しいため、プロジェクト範囲拡大の要因となります。もっと言えば、プロジェクトの成功度合い（求められ
「開発現場における効果的な組織の動かし方」-GREE Platform Summer Conference 2012
同セミナーは下記スライドの項目で行われました。 ・急成長する組織での課題 ・目指すべき組織 ・組織を成長させるための仕組みづくり 新入社員の早期戦力化 ・組織を成長させる仕組みづくり ・組織のスケールアウト GREEは自立指向のできる分散型組織 ・たった一人でもプロダクト運用ができる所がゴール。 ・プロデューサーの意思決定を重視。 ・自分で考えられる組織に 統合型スキルセット ・エンジニア、ディレクターの組み合わせ。 ・全般的な企画分析は職を問わず行う。 仕組みづくり1：プロダクトをリードする人材育成 ・相互に不得意な所を補いながらProducerを育成する ・企画リード＋エンジニアリード＋組織マネジャー ・組織マネジメントを学んでいく。 しくみづくり2：自立思考できる仕組みづくり ・GREEとしては必ず達成してほしいミッションを提示。 ・プロセス自体は自分で
オンライン上で見積書・請求書の発行、タスク管理ができるツール「CLPRO」をリリース！ | PLUS
フリーランスとなって1年ちょっと。一人になってからは見積書・請求書の発行や、受発注管理、入金管理など、全てエクセルやメモ帳で管理していたのですが、件数が増えてくるとちょっと面倒になってきていました…。 そこで、ほぼ自分用にプログラムを作って、オンライン上でこれらの管理ができるツールを作りました。無料β版としてみなさんにも公開しましたので、宜しければご利用ください。 CLPROでは何ができる？ オンラインで見積書・請求書がつくれる オンライン上で見積書・請求書を作ることができるため、場所、パソコンを選びません。また、一度入力した項目は自動的に保存されるため、同じ項目名を入力する際にオートコンプリート機能が働きます。 見積書・請求書をPDFに変換できる 入力した見積書・請求書はワンクリックでPDFに変換可能です。自らの保管用に、クライアントへのメール添付に便利です。 プロジェクト・タスクの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ききやすい雰囲気をつくるのは、教える側の役目～質問しにくい上司、先輩は、自ら業務妨害している～
情報システム部門のタスク管理とIT全般統制 ～ Excel管理からの脱却 ～ (ITS Redmine #RxTstudy #5)
