GitHubが実践するオープンソース式マネジメント法
GitHubのミッションは、「1人で作業するよりも複数の人とコラボレーションしながら作業した方がいい。人のために、技術者のためにステキな環境を作ること」だ。GitHubは、2008年4月に「コラボレーションできる環境を作りたい」という夢を持った3人の想いが集まり始まったプロジェクトである。それから約5年経った現在では、300万人のユーザー数と500万のリポジトリが登録されている。 GitHubのはじまり 創業者の1人、ピージェー氏がプログラミングを始めたのは14歳のときである。ピージェー氏の父がパソコンを買ったことがきっかけで、「自分でいろんなものを作ってみたい」と好奇心が生まれたそうだ。 共同創業者のクリス・ワンストラス（Chris Wanstrath）氏と出会ったのは、「CNET Networks」で働いていたときであった。ピージェー氏とクリス氏は当時、Rubyを使ったプロジェクトやバ
＠IT：明日からできるプロジェクト管理（1）
デスマーチを止める進ちょく管理の現実解:GanttProjectの導入で進ちょくをコントロールする：明日からできるプロジェクト管理（1）（1/4 ページ） 開発プロジェクトは、何もしなければどんどん混乱していく。計画は破綻し、成果物は四散し、開発要員の心理はズタズタになる。混乱を収拾するのは容易ではない。開発プロジェクトの立ち上げ段階から秩序を導入し、整理整頓されたその状況をカットオーバーまで維持すること。もちろん、それは口でいうほど簡単なことではないのだが、まったく無理なことでもない。本連載では、プロジェクトに秩序をもたらすさまざまな手法を、開発プロジェクトの段階を追って解説していく。そして、手法の説明だけではなく、具体的なツールを使って「どうすれば効率的な管理が可能なのか」という現実的な提案も行うつもりである。ここで使用するツールはすべてオープンソースのプロダクトである。効果的な方法を
「管理」を勘違いするPMが、メンバーに翻弄される理由
「管理」を勘違いするPMが、メンバーに翻弄される理由：新任PMがついやってしまうNG集（4）（1/3 ページ） 1人で仕事をしているプログラマ時代は、ばりばり仕事がこなせたのに、PMになった途端に仕事がうまく進まない！ そんな新任PMの悩みを解決するTipsを紹介します。 こんなはずじゃなかったのに……ああ世知辛い、PMの嘆き プロジェクトを管理するプロジェクトマネージャ（PM）は、何かにつけ苦労する立場にあります。 「メンバーにガミガミ言うことに疲れた」「いくらチームに必要とはいえ、この役割はつらい」「ぶっちゃけプログラマの方が良かった」……このような声をPMからよく聞きます。 しかし、ここでいま一度思い出してみてください。形はさまざまあれど、PMは理想とする「管理」の姿を持っているはず。そして、それは決して「ガミガミ言うこと」ではなかったと思います。 「そんなこと言ったって、メンバーが
優秀なプロマネはメンタルな働きかけもうまい
PMBOKやCMMIなどには書かれていないけれど、「実はこれこそがプロジェクト成功の根底に必要なものだ」というポイントがあります。それは私自身がプロジェクトで実践し、コンサルティングの場でも効果を発揮してきた手法や考え方でもあります。 開発技術、管理技術以外の大切な何か 誤解のないようにいっておきますと、PMBOKやCMMIに対する知識や、それらに対する活動に効果がないということでは決してありません。それどころか先人の英知を引き継ぎ、それを実践することはとても意味のあることです。一方で、これらに代表されるような“マネジメント技術”だけを頑張っても、成功は簡単ではなく、心が疲弊してしまう人が減ることもないと考えています。開発技術にしても同様です。開発手法や開発ツールが日々進歩しているにもかかわらず、相変わらず過酷な状況が続いているということは珍しくありません。あなたにも心当たりがあるのではな
サイロ型のシステム監視が、問題解決を遅らせる
各システム構成要素を個別に監視する方法では、いざというときに問題個所の究明に時間が掛かってしまう。だが、エンドユーザー体感監視なら、システム全体から部分へと、問題個所を効率よく絞り込んでいくことができる。 企業の注目を集めつつある「APM」 前回は、ITシステム運用管理方法の1つのアプローチとして、ビジネス視点でシステムの安定稼働を担保する「エンドユーザー体感監視」の概要をご紹介しました。今回からは少しずつその内容を詳述していきたいと思います。 まず、本連載では、エンドユーザーの視点からレスポンスタイムを計測し、ITサービスのパフォーマンスを管理する手法を「エンドユーザー体感監視」と呼んでいますが、一般的には「エンドユーザー視点でアプリケーションのパフォーマンスを監視、管理する手法」はAPMと呼ばれています。 APMとはApplication Performance Management、
プロジェクトは失敗するのが当たり前！？ ― ＠IT情報マネジメント
ユーザー企業側プロジェクトマネージャの勘違い：超現場主義！ 失敗しないITプロジェクトマネジメント（2） 常に潜在化しているリスクをチェックしながら、プロジェクト進行中の早い段階でリスクマネジメントを行う。これが、「失敗を前提としたプロジェクトマネジメント」の本質である。「ヒト」という点でプロジェクトのリスクファクターをとらえた場合、それはプロジェクトにかかわるすべてのステークスホルダー（利害関係者）の利害を認識し、それぞれのステークスホルダーとビジネスの落としどころを交渉するということにほかならない。 リスクを早い段階から摘み取るためのマネジメント プロジェクトのステークスホルダーは大きく分けて4つにカテゴライズすることができる。 ユーザー企業側最高システム責任者 ユーザー企業側プロジェクトチーム ユーザー企業側その他システム関係者（他部門のシステム責任者） システム開発業者 2回目は「
プロジェクトは失敗するのが当たり前！？ ― ＠IT情報マネジメント
ITプロジェクトが失敗する理由は、成功することを前提としたマネジメントが行われているためである。ITプロジェクトの成功率は思いのほか低く、このような状況を改善するためには「失敗を前提としたマネジメント」を心掛けなければならない。失敗を前提としたマネジメントとは、リスクマネジメントに重きを置いたマネジメントということになる。 ITプロジェクトのほとんどは失敗に終わる 成功率16％。これはある開発ツールベンダが調査した米国におけるITプロジェクトの成功率である。その調査によれば、昨年米国で遂行されたプロジェクトは約17万件であり、そのうち、機能、予算、納期などが当初の想定内に収まったものは16％だったという。 日本においてもほぼ同じ状況であるといえる。「企業IT動向調査2006」（社団法人 日本情報システム・ユーザー協会）に調査によれば、システムの仕上がりに満足と回答したユーザーは10％前後に
アジャイル開発と反復開発の落とし穴
前回「『現状のソフトウェア開発は間違っていないか？』（プロセス編）」では、ウォーターフォール開発の問題点と改善方法を示した。さて、前回お話ししたようにウォーターフォール開発は本来、いくらプロセス改善をしたとしてもイノベーティブな開発がしにくい。ならば、反復開発（*1）やアジャイル開発に変えてしまおう、といいたいところ。しかし、導入するのであれば、それぞれのプロセスの特徴と弱点をしっかりと知っておくことが必要である。 ウォーターフォール開発からの乗り換えを考えている方々だけではなく、いまアジャイル開発や反復開発を実践している方たちにもぜひ一読してほしい。 （*1）反復開発とは例えばRUP（Rational Unified Process）やUP（Unified Process）のこと。 反復開発とアジャイル開発の違い 反復開発とアジャイル開発は、繰り返し型開発という意味では同じように思われる
トヨタが気前よくカイゼンを教える本当の理由（1/3） ― ＠IT MONOist
本連載ではソフトウェア開発／運用でのCO2排出量見える化と、製造業における取り組みのポイントや算定における留意点を3回にわたり解説する。第1回となる今回は、そもそも製造業がなぜCO2排出量算定へ取り組まなければならないのかを解説しよう。
5分で絶対に分かるプロジェクト管理 ― ＠IT情報マネジメント
プロジェクト管理ってよく聞くけれど…… ソフトウェアの開発は、よく家を建てることにたとえられます。家を建てる場合、顧客の要望を聞いて設計などが終わった段階から、施工のスケジュールを立て、さまざまな関係者が予定に沿って作業を進めていきます。作業が予定どおりに進んでいるかを施工業者がチェックしたり、作業の途中で建築士が品質をチェックしたりしながら、家の完成まで工事全体を管理します。その管理をせずに家がちゃんと建つ保証はありません。 ソフトウェアを開発する場合も、顧客の要望を聞いて設計をした後に開発やテストの作業があり、その作業をさまざまな関係者が予定に沿って進めます。途中で作業が予定どおりに進んでいるかをチェックしたり、品質をチェックしたりしながら、完成までプロジェクト全体を管理する必要があります。 家を建てることは、何千年も前から行われてきているため、どうしたらうまくいくのか、何を管理してお
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
