2これは小学校で習った通り。現実世界ではこう上手くはいかないことが多いのです。プロジェクトマネジメントの世界もそのひとつです。遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせるだけだかの有名なブルックスの法則というやつです。祐子))デマルコの「4822280535」も同じ論調ですね。2ということになるでしょうか。マコネルは「4822282155」の中で「負の生産性プログラマ」の存在を指摘し、「プロジェクトを後ろ向きに引っ張っている」と指摘しています。0となる可能性もあるということです。これは決して驚くことではないのと思います。飛んでもないものが出来上がってきて、デバッグや作り直しで一から作るより時間がかかってしまったとか、モラルの低いプログラマが一人でもいることによってチーム全体の士気が下がってしまうとか。この辺は実感がありますよね。プロジェクトファシリテーションというのは個々人のスキルは重要です。ここで取り上げるのは、集まった個人のスキルを100%以上に発揮させるチーム作りとしての、「プロジェクトファシリテーション(PF)」です。その場その場の変化に対応し、チームが協力し合って創発的に成果を出していく、「リーダーシップ・コラボレーション型」の新しいチーム作りの形です。2にしようということです。し、100人のチームに50人投入するとかそいう大規模なケースは想定されていなくて、あくまでも10人以下とかそういう少人数の場合に上の式が成り立つようにしようというのがプロジェクトファシリテーションだと理解しています。2になる瞬間というのが時々あって、そういうときにこのメンバーでこのプロジェクトをやっていて良かったなあって思うんですね。その瞬間に生まれているプラスアルファの価値とか、メンバーの体験(Experience)とかを大事にしていきたいなぁと思っています。[時間で考えるとわかりやすいかもしれません。コードの共同所有に弱点はあるか?訳しました。http://www.infoq.com/jp/news/2008/05/weaknesses_collective_code今までXPとかやってきて、「誰も所有していない」という無秩序な状態になったことがないので、あまり実感はなかったですけど。InfoQの翻訳に関しては大物を自摸ったので、しばらくはそっちをやる予定です。通り、永和システムマネジメントの東京支社は神田に移転しました。(東京支社で作業するプロジェクトメンバーの席は固定席として残しています)。放浪することになります。35年の歴史の中で、自分の席を持たない最初の事業部長になりました。他に35年以上の社歴を持つ会社で、自席を持たない事業部長の方がいらっしゃれば、私までご連絡ください。お友達になれそうです。090-3495-3782よろしくお願いします。