プロジェクトが失敗に終わる可能性は非常に高く、 おそらく90–95%くらい

「オープンソースソフトウェアの育て方」という書籍があります。副題にフリーソフトウェアプロジェクトを成功させるコツとあるように、著者がオープンソースプロジェクトでの経験を元に実例を交えて説明されています。バージョン管理システムで有名なSubversionプロジェクトでの実際の経験から書かれています。 実践的な内容なので、ぜひソフトウェアエンジニアの方には読んで欲しい内容です。 （技術的な側面よりもオープンソースプロジェクトをうまく運営するための考え方やプロジェクト運営方法についての説明が多くなっています。）

さらに、うれしいことにウェブで全文を公開しているためだれでも読むことが出来ます（当然、日本語で）300ページにもなる専門的でためになる文書を公開された作者の方と翻訳者の方に感謝しなければいけません。

本の内容で特にビジネスアプリケーション開発の困難な点と共通する部分が多く（同じソフト開発なので当たり前ですが）さらに多くの課題に対処するための方法も参考になります。 「3. 技術的な問題」で紹介されているツールとその運用方法は、ビジネスアプリケーションの現場でも十分有効に使えるので、新入社員などに読ませるのも良いと思います。紹介されているツール群は若干古いですが、どのようなツールを、どのような場面で、どのように使っているのかを知る上でとても分かりやすいです。

また、「6.コミュニケーション」などは自分たちの開発でも学ぶべきコトが多いと思った部分で、読んでおくべき章だと思います。

• 書いたことがすべて
• 陥りがちな罠
• 付録C.なんで自転車置場の色まで気にしなきゃならないの？

ソフトウェアエンジニアに求められる能力として、はじめに思いついたことは、「文章を作成する力」です。コミュニケーション能力や提案力、プログラミング能力などよく言われる能力も必要であると思いますが、自分の考えを正確に正しく伝えるための書く力はインターネットが仕事に欠かせないツールになったことで重要であると考えています。

そのためには書く（まとめる）内容以前に考える力が重要になってきますが。。。

以前に読んだのですが、達人プログラマを読みましました。
とは言っても，読んだのが何年も前の話でよく覚えていません。 やはり古いで、8年ぐらい前の古い本ですが、いい本はいつまでもいい本です。普段、何気なく他の本を読んでいても、この本からの引用されている記述も多くみかけます。

さて，本の中では沢山のことが書かれています。多分，この本を読むのは，本が手に入りさえすれば簡単で，すぐに終る作業です。
でも，この本の中の１つでもちゃんとやろうとすると大変です。
例えば，知識のポートフォリオなんて，ちゃんとやろうと思ったら読書量は凄いことになります。
決してできない量ではないです。
ちゃんと勉強していない人にとっては続けるのは、つらい量と言うことです。

僕はちゃんとできていない派なのですが、少しでもいいので、ちゃんと続けてみたいと思います。たぶん、何年か後も同じことを思うのかもしれませんがw
できるだけ、過去の振り返りを行って改善できるように努力していきたいものです。

sugimotoです。

まだ途中ですが、「プログラマーのジレンマ」を読んでいます。

Lotus 1-2-3を開発したミッチ・ケイパー(Mitchell David Kaper)がOpen Source Applications Foundation(OSAF)を設立し、世界を変える夢のソフトウェア「Chandler」を開発する過程を描いた物語です。

作者のまえがきに「この本はソフトウェア開発者向けのハウツー本ではない」とある通り、OSAFをケーススタディとしたソフトウェア開発についての考察はなく、夢のある大義名分とソフトウェア時間の中で埋もれていく開発者たちの様子を淡々と描いています。

本を読んでいると、昔話のようですが、ミッチ・ケイパーのBlogや、OSAFのサイトを見ると現在の話なんだなと、思います。

ソフトウェア開発者に限らず、ものを作る人にとっては、自分の作るものを最高の状態で世の中に送り出したいと考えます。 しかし実際には、最高のものが世の中に出せることはほとんどなく、「折り合いをつけたもの」が世の中に出ていきます。

「この本はソフトウェア開発者向けのハウツー本ではない」ですが、開発者にとっては、とても考えさせられ、勉強になる本です。

• ChandlerのASPサービス、Chandler Hubに登録してみましたが、カレンダーが途中で固まり、操作できなくなってしまいました。。残念。。