アジャイルにおけるプロジェクトマネジャーの役割
この記事では最初に一般的に産業界でのプロジェクトマネージャーの役割について説明し、それから、アジャイルにおけるコーチ/ファシリィテーターの役割にあてはめてみます。
News
すべてのプログラマが知っておくべき97のこと
作者 Mirko Stocker , 翻訳者 徳武 聡 投稿日 2009年9月22日 午後3時0分
すべてのアーキテクトが知っておくべき97のこと (InfoQの記事)に続いて、「97のこと」シリーズの続編はすべてのプログラマが知っておくべき97のこと、だ。これらはwikiに集められて、誰でも貢献できるしコメントも受け付けている。
このwikiには既に(この記事を書いた時点で) 88 のエントリが集まっていて読まれている。例えば、
- コードだけが真実を知っている by Peter Sommerlad氏
- スピードは命取り by Uncle Bob氏
- API設計の黄金律 by Michael Feathers氏
- 自分のIDEを知る by Heinz Kabutz
- 人々のためにテストを書くWrite Tests for People by Gerard Meszaros氏
InfoQは「すべてのプログラマが知っているべき97のこと」の編集者であるKevlin Henney氏に、このプロジェクトのことについて話を聞いた。
この「97のこと」シリーズは「すべてのアーキテクトが知っておくべき97のこと」から始まりました。その後「すべてのプロジェクトマネージャが知っておくべき97のこと」が続き、そして「すべてのプログラマが知っておくべき97のこと」が現在、集められています。これらは個々人のwikiに対する貢献によって形成されてきたプロジェクトで、この中から97の項目が選ばれて本にまとめられます。
執筆者はアナウンスを嗅ぎ付けて、または特定の招待や推薦、クチコミを通じてプロジェクトへ参加するようになりました。ソフトウエアアーキテクトとプログラマのプロジェクトはより大々的に参加を呼びかけました。興味とやる気がある人なら誰でも参加できるようにするためです。ブログやメーリングリストでも呼びかけましたし、今回のプログラマでは、Twitter (@97TEPSK)も使っています。
また、貢献内容や、参加への呼びかけにクリエイティブコモンズライセンスを適用することで、オープンソースのような性質を持たせています。本にまとめた後でも、プロジェクトの元になったwikiはそのままです。コメントやさらなる貢献を集めるためです。
アーキテクトの後、なぜ今プログラマなのですか。
順番が逆じゃないかって(笑)。 とにかく、ソフトウエア開発での役割は、アーキテクトよりもプログラマの方が多数派を占めますからね!
すべてのアーキテクトが知っておくべき97のことは初めての本で、本の体裁や作り方を探るのも初めてでした。この本は、まだシリーズのアイディアができる前に、私家版として考えていたものです。Bruce Eckel氏が管理しているメーリングリストで、Richard Monson-Haefel氏が"すべてのソフトウエアアーキテクトが知っておくべき10のこと"と題した話題について意見を求めていました。そこからこの本とwiki、そして究極的にはこのシリーズの着想が育ってきたのです。
プログラマに着目した本のアイディアが浮かんだのは、コードを読んでその中にある間違いについて、頭を悩ませていたときでした。そのとき私は、自分が"くそ、こんなことはプログラマが全員知ってくべきことじゃないか!"というようなことをつぶやいているのに気付きました(もっと、語気を荒げていたかもしれませんが)。この"すべてのプログラマが知っておくべき"という文句が引き金だったのです。私は、過去になされたプログラミングに関する忠告や洞察の類いを書き出してみました。しかし、すでにアーキテクトのプロジェクトに対する様々な貢献があったので、群衆の知の力を借りた方法が魅力的に思えました。
このプロジェクトの対象になるのはどんなプログラマなのでしょうか。
すべてのプログラマです。ハウツー本でも、入門書でも、すべてのプログラマが知らなければならないことを完全にあつめた本でもありません。この本には、どんなプログラマでも価値があると思えるような知識のかけらが、様々な範囲の視点や経験をふまえて書かれています。この本を読んで、知っていることや知りたいと思っていることを見つけ出すプログラマもいるでしょう。自身の経験の度合いに合わせて考えて、本に書かれている内容とギャップを感じて、その差を埋めたいと考えるプログラマもいるでしょう。自分の経験との矛盾を見つけたプログラマは話のネタにできるかも知れません。
つまり、この種の本はちょっとずつ読むこともできますし、グループで読んでもひとりで読んでも有用で、長椅子やベッドに寝転びながらでも読めます(こんなふうに読めるプログラマ向けの本はそう多くはありません...)し、空港、駅、バス停の待ち時間を有意義にしてくれるでしょう(天気が許せば、ですが)。
４冊目の本を既に計画中なのですか。
「97のこと」シリーズは続きます。なので次の本が出るのをきっと期待されるでしょう。とはいうものの、いくつかのプロジェクトを思いついたり、実験的に始めたりしていますが、現在のところ明確な形で新しいプロジェクトが存在するわけではありません。
– ソフトウエアアーキテクト、プロジェクトマネージャ、プログラマ、データベース管理者、業務分析家、UIデザイナ等 –のすべてに存在するギャップを埋めてようとする壮大な計画があるわけではありません。なので、そういう意味ではこのシリーズは計画性がありません。一方で、これらの本が着目するのはソフトウエア開発に関わる職種に限る必要はありません。個々のプロジェクトは個別にひとりの編集者によって計画され管理されます。なのでどんなプロジェクトを選び、運営するかは編集者の肩にかかっています。
そろそろ、読者は皆、97という数字がどこからきたのか、不思議がっているに違いないと思うのですが。
これはとても重要なことで(笑)。
もちろん、なにかの特定の意義や根拠はないのは事実ですが、97という数字は、100に近く、しかし100そのものでも100に近すぎもしません(99や101のように)。100の近辺の数字だと都合がいいのは、印刷した形式で、さまざまな短い項目を1項目あたり２ページにおさめても、妥当な大きさの本になるからです。この97と言う数字は、このシリーズの最初の本、アーキテクトが知っておくべき97のことの編集者であるRichard Monson-Haefel氏が選びました。– そして当然「97のこと」シリーズの他の本もこの形式を踏襲しているというわけです。
極端に項目が少ないと、どれも長い文になってしまい、その結果、多様で一般的な内容の記事は少なくなり、プロジェクトに対する貢献がしにくくなったり、本もパンフレットのようになってしまうでしょう。項目の数が極端に多いと、ひとつひとつを短くしなければなりません。要約より少し長いくらいでしょうか。そうしないと、実現しようとしている内容に比べて、長過ぎる本になってしまいます。
さらなる情報はすべてのプログラマが知っておくべき97のことwikiと、そして執筆記事一覧も見逃してはならない。
No comments
スレッド表示 返信