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

 現在ないし過去に行われたITプロジェクトにまつわる経験談は、ITインフラの構築や改善を目論んだものの、巨額の資金やエネルギーを浪費したあげく、何らの実りなく終わった事例の宝庫である。そのように組織のリソースを無駄にすることなく、ITプロジェクトによって組織の価値を高める責任は、ITマネージャに課されていると言っていいだろう。

プロセスはITプロジェクトにとって最善の策とは限らない

 ITプロジェクトの成功には、優良で、繰り返し行なうのに適していて、確固とした「プロセス」(工程、マニュアル)が必要不可欠だ。確固としたプロセスがあるからこそ、プロジェクトというパズルの各ピースが組み合わさり、全体として一つのアウトプットを出すことができる。プロセスがあることによって仕事が毎回同じ方法で進められると期待することができ、それによってチームのメンバーや顧客は、何かが欠けている可能性を心配する必要もなく、信頼性が高く実用的で使い物になる結果を得ることができると確信することができる。

FOSSプロジェクトに時間ベースのリリースを勧めるMichlmayr氏

 前Debianプロジェクトリーダー(DPL)のMartin Michlmayr氏による、ケンブリッジ大学テクノロジ・マネージメント・センターでの博士論文が完成間近だ。論文の表題は「Quality Improvement in Volunteer, Free, and Open Source Project: Exploring the Impact of Release Management(ボランティア/フリー/オープンソースプロジェクトにおける品質向上:リリース管理が与える影響についての調査)」で、Debian、GNOME、Linuxカーネル、OpenOffice.org、Plone、X.orgといった 大規模なFOSS(フリー/オープンソース)プロジェクトの事例研究が基となっている。

Gentooプロジェクト、開発者間の対立解消に難航

 今月半ば、Gentooプロジェクトは「危機」に瀕しているのか日本語関連記事)と問う記事がSlashdotに投稿された。これに対しGentooプロジェクトでは、記事で議論された問題への対策の一環としてCoC(Code of Conduct;行動規範)を採択し、CoC違反を取り締まる「監督者」を置くことを決めた。しかしこれまでのところ、この対策の効果は限られているようだ。

IT企業における付加価値を持つリーダシップ能力の育成法

 ITスーパーバイザを務めるLynetteの働きぶりを見ると、正にエネルギッシュという表現がピタリと当てはまる。職務として課せられた本来の仕事はネットワーク管理なのであるが、何か特別なプロジェクトが発足すると真っ先に取り組むのはたいてい彼女であり、本業でもないのに頼まれれば率先してスタッフ用ガイダンスを開催するは、チーム全員が手本とすべき高い意欲を持って仕事を進めるは、といった具合だ。

与えるべきか否か:FOSSにおける報酬のトレードオフ

フリーおよびオープンソースソフトウェア(FOSS)プロジェクトが開発者のための報酬制度を導入しようとするとき、いったい何が起こるのだろうか。今なおFOSSは概して有志の活動に基づいているため、そうした制度によって報酬を受け取る者とそうでない者の双方の意欲が低下する可能性が大いに憂慮される。

フリーソフトウェア化を視野に入れたFedoraによるリポジトリの再編成

Red Hatの支援するFedoraプロジェクトは現在、次バージョンのリリースに先がけて様々な改変を進めているところである。例えば来るFedora 7ではCoreおよびExtraソフトウェアリポジトリが統合される予定であることを契機に、非フリー系および非オープン系ソフトウェアについてはプロジェクトのガイドラインに則していないものをリポジトリから取り除くべく、Fedora開発陣による監査が行われている。そして最終的に同プロジェクトは、そのパッケージガイドラインを“フリーソフトウェア”オンリーとした内容に改訂するかもしれないというのだ。

レンダリングエンジンの置き換えによるXara LXのフォーキング

先週、ベクトルグラフィックエディタのXara LXに関して大きな動きが見られた。このプロジェクトについてはオープンソースコミュニティの貢献者たちと同社の経営陣との間に意見の対立が存在し、ここ数カ月は膠着状態に陥っていたのだが、貢献者側の1人がコードベースをフォーキングした成果を公開したことで再び動き出したのである。この行為に対しては会社側からの承認も得られており、オフィシャルなSubversionリポジトリに登録することが申し出られている。

支持を求めてあがくAutopackage

1年2か月前、小規模ながらも活発な取り組みを行っていたAutopackageプロジェクトのメンバーは、自分たちの成功について楽観的な態度を示していた。この代替インストーラのプロジェクトは現在も活動を続けてはいるものの、進展はほとんど見られない。irc.oftc.netの#autopackageチャンネルは誰も訪れない日が大半を占め、開発者のブログで取り上げられているのはプロジェクト以外のことばかりで、ソースコード・リポジトリに対するコミットは滅多に行われていない。形のうえではまだ継続中であるが、主だった貢献者たちは1人残らず、プロジェクトが終焉を迎えつつあることに同意している。いったい何が起こったのだろうか。

プロジェクト管理計画の重要性

プロジェクトを完了させるまでに、プロジェクトマネージャのもとに押し寄せる仕事をもっと上手くこなす方法があるに違いない、と感じたことはないだろうか。チームのマネジメントや彼らの抱える問題への対処、出資者への対応、コミュニケーションの確保に振り回されてはいないだろうか。未知のものを管理する場合には尋常でない忙しさがつきものかもしれないが、本稿ではその仕事の忙しさを許容できる範囲に収める1つの方法を紹介する。

標準とデータベースによるプロジェクト管理の改善

ときとして組織がプロジェクト管理の標準(スタンダード)を採用したがらないのは、実践的な応用方法を理解できていないか、不必要なオーバーヘッドを恐れているためだが、いずれは標準化が必要なことを思い知ることになる。しかし、比較的容易に標準に従えるようにする環境を作成することは可能だ。本稿では、プロジェクト管理手順の採用と高品質な製品やサービスの提供をより簡単に行うための実用的なタスクをいくつか紹介する。

日本IBM、Eclipseの有償サポートなど開発環境を拡充

 日本IBMは2006年12月12日、オープンソースの開発環境「Eclipse」の有償サポート「Rational Elite Support for Eclipse」を発表した。6日から提供を開始している。開発環境製品のラインアップ拡充の一環で、このほかSOA(サービス指向アーキテクチャ)対応の開発ツール「IBM Rational Software Delivery Platform V7.0(SPD V7)」の出荷を12月23日から開始する。

新任のFedoraテストリード、仕事に取り掛かる

Fedoraプロジェクトの新任テストリードWill Woodsは、その地位に就いてまだ数週間なのに、もう明確な目標を定めている。SlashdotでFedoraの話が出ると彼はいつもこう指摘する。「FedoraはRed Hat Enterprise Linux(RHEL)のためのRed Hatによるベータテストに過ぎないと論う人が必ず出てくるものだが、それは事実に反する。そうした言われなき発言が二度と繰り返されぬようにしたいと思う」

「伽藍とバザールを融合した品質保証」について語るMichlmayr氏

2年前にDebian Project Leaderの任期を終えたMartin Michlmayr氏は、ケンブリッジ大学の技術経営センター(Centre for Technology Management)で博士号を取得するための研究生活を送っている。『Quality Improvement in Volunteer Free Software Projects: Exploring the Impact of Release Management(ボランティアベースのフリーソフトウェアプロジェクトにおける品質の向上:リリース管理による影響の調査)』というのが、彼の学位論文の暫定的なタイトルだ。Michlmayr氏は、多くのプロジェクトが評判を得て成熟度を高めていくには品質保証が欠かせないことに着目している、とNewsForgeに語っている。しかし、各プロジェクトが品質保証の必要性を正しく認識するためには、従来の「伽藍とバザール」という見方を改める必要があるだろう、と彼は信じている。

EtherealからWiresharkへの名称変更の経緯

世界で最も広範に使用されているネットワークプロトコルアナライザと喧伝されているEtherealプロジェクトだが、その創設者であるGerald Combs氏が先週水曜日にEtherealの開発者メーリングリストにて発表したアナウンスは、ユーザと開発者の間にちょっとした騒ぎを引き起こしている。その内容は、同氏が職場と居住地を他に移す予定であり、その際には同プロジェクトおよびコアスタッフを引き連れて出てゆくというものであった。

「CVSの言い訳」と途方にくれるユーザ

オープンソースソフトウェアで一番不満に思うことの1つは、CVSを盾にした言い訳がよく見られることだ。私はこれを「CVSの言い訳(CVS cop-out)」と呼んでいる。たとえば、私が何かの記事か会話の中で、あるオープンソースアプリケーションの短所を(正当に)批判すると、「それは間違いだ。その機能は4週間前にCVSで修正されている」と反論する人がいるのだ。