Solution
概要
普通は、PMがスタッフを選別してプロジェクトを開始する。これを、スタッフの側からプロジェクトを選択する方式に変えたらどうなるだろうか。思考実験してみよう。思考実験
商談交渉
マネージャは、商談を持ってくるときに計画を立てる。このときに正確な見積もりは難しいので、おおまかな金額を算出する。金額を出すためには、自分で計画を立てないといけない。顧客から、おおまかな要件を聞いて工数見積もりを出すのだが、マネージャひとりではさすがに無理だし、リスクが大きいので、適切なツール（見積もりツール「１１１の法則」）を使い、適切な技術リーダ（まあ、だいたいこのぐらいの要件であれば過去から算出してこれぐらい）に尋ねて、工数計画を見積もる。
スケジュールを出して、必要な人数を割り出す。顧客が長期間すぎる、という話であれば、マネージャは極力調節する。顧客が要件を言わないのであれば、見積もりの誤差が大きくなる（場合によったら３倍以上）ので、できる限りマネージャは要件を出すように努める。
マネージャは、リーダーはどんなタイプ、スタッフはどんな人達、まあ、理想を言えば、誰がいいかもしれないが、誰それはどこどこのプロジェクトの関わっているから無理だし…、と思考錯誤を繰り返す。マネージャは、目標金額を設定している場合もあれば、なんらかの個人的な目標もあり、生活もあるので、ひとつだけのプロジェクトに関わっていればよい、というわけではない。もちろん、大きなプロジェクト（３年以上とか）になれば、複数のマネージャが必要になるかもしれないが、ここでは、１年程度のプロジェクトを目安に考える。
このリスクを負うかどうか、このリスクは回避すべきか、このプロジェクトを進行するためにはどんな技術要素が必要か、金額は妥当なのか、スケジュールは妥当なのか、などなど。
ひとつひとつの要素を検討していく。全体スケジュールを立てて、どこにリスクのターニングポイントがあるのか、どこに中間検収があるのか、納品の形態はどうなのか、製作時の負荷はどんな感じなのか、試験時に増員が必要であればアサインができそうか、を社内の情報掲示板を使って考察していく。
工数の見積もりやスケジュールの見積もりは、完全に正確に出せるわけではない。かといって、いい加減な楽観的なスケジュールでもない。リスクをひとつひとつピックアップしていき、そのリスクに対する策や、リスクが発生したときの遅れ（リスクツール「mh×(1+1/n)^nの法則」）、これに伴う長期化による金額の損失、スタッフが次のプロジェクトに移れないための損失、会社全体の経営的な損失、マネージャ自身の顧客評価の損失、などなど、を立てる必要がある。
各種見積もりは、ツールを媒介にして大雑把な概算（社内の過去のプロジェクト比較から算出）したり、マネージャが顧客に対して交渉する安全圏を残して、見積もりを煮詰めていく。
そして、最後には、マネージャの全責任を持って匂いと勘で、最終的な見積もりに行き着く。
スタッフ公募
最終的な結論に至れば、スタッフを公募する。これは、「プレ商談」として社内に公開して広くスタッフを公募する。マネージャの出した見積もりは、社内で公開される。機密情報だったらどうするのか、まだ商談になっていない情報を社内におおっぴらに公開していいものか、という議論はとりあえず置いといて……、公募する。こういう公募は、フリープログラマを集める方式で採用されているので一般的ともいえる。社内から人員を募集する分だけ安全性（機密保持性、スタッフのスキルなど）が保障されているので、無理矢理、外注さんを探してみたり（もちろん、探すときもあるが）、寄せ集めの人員でプロジェクトを構成したりするよりは、いいかもしれない。
マネージャが作った初期見積もりは、多くの人の目に晒されるので、安全性が高まる。無理なスケジュールや、楽観すぎる工数を避けることができるだろう。
もちろん、リスクの高いプロジェクトであっても人は集まる。高い技術を求めるスタッフや、仕事意欲の高いスタッフ、専門知識を持ったスタッフ、などが集まればプロジェクトは成功するかもしれない。（当然、スキルが高くても全体の統一が取れなくてプロジェクトは潰れるかもしれない）
そのあたりは、信頼関係も含めて、マネージャと一定人数のスタッフの間で話し合いを持つ。どういう方式で人を集めてもよい。強い管理方式をアピールするのもよし、仲間意識を高めた方法をアピールするのもよし、勤務時間が少ないプロジェクトをアピールするのもよし、危険の少ない安全なロードワークを約束するプロジェクトでもよい。会社にはさまざまな人がいるのだから、マネージャについていく人もさまざまである。
ただし、もし、公募に誰も応募しなかったのであれば、それはマネージャの責任である。誰もが潰れそうと思うプロジェクトに参加する人はいない。
商談成立？
一定人数のスタッフが集まり、プロジェクトが遂行できる用意ができたら、顧客と最終的な商談の場を持つ。マネージャは、自信を持って金額とスケジュールを持って出かけていくことができる。社内でさらされたスケジュールやリスクの数々、そのスケジュールに同意してくれるスタッフ、これらの要素があれば、金額とスケジュールに大きな根拠を持てる。顧客から「このような長いスケジュールでは困る。もっと短くできないだろうか」と懇願されたどうだろうか？
マネージャは「人員を増やせば、スケジュールを短くすることは簡単です」、とは容易に言えないだろう。なぜならば、人員を増やすためには、再び公募をしなければならないし、公募をするためには、また根拠ある資料作りをしなければならない。人の配置も大変だろうし、リーダー格が幾人かいないと、大人数（しかも工期は短くなっている）のプロジェクトは運営できない。最初に見積もったスケジュールの根拠が吹き飛ぶし、集めたスタッフの信頼も失う。
返す言葉は、「このスケジュールにはこういう理由があってこのようになっています。リスクはここで見積もりができていいますし、リーダーには誰を配置する予定になっています。このような配員の場合には、こういうスケジュールが一番安全になっています。リスクがいくつかありますが、これらのリスクはここでこういう風に解消していきます。無理にスケジュールを短くしないほうが、安全で確実にプロジェクトを終了させて、正確に動くプログラムが納品できます。それでも、短くしますか？」。
マネージャは、商談交渉の場において、どちらの立場にいるのか常に頭に入れておく必要がある。顧客の立場を理解しつつ、会社の存続のために（いわば自分の立場のために）、駆け引きをするのだが、スタッフを裏切ったスケジュールや金額調節をして帰ってきたら、言いなりの営業マンと変わらない。きちんと、説明をして帰ってくれる代表役なのだから、あんた、ちょっとしっかりやってきてよ、と陰口を言われないように頑張るしかない。
無論、最終的な金額調節やスケジュール調節で、微妙なところを組み替えていくのはかまわない。交渉の場に、責任を一任されているマネージャは、会社の看板を背負っているのだから。
なので、5%程度の揺れは許そう。交渉材料として、あらかじめ余裕を持っていくのもよし、その場で金額を調節してリスクを概算するのもよし。ノートブックに入っている、リスクツール「mh×(1+1/n)^nの法則」を使って、ささっとスケジュールの建て直し、それによるスケジュール遅れの確率を出してみよう。ほとんどの数値は入れてあるので、あとは少しスケジュールを短くして、再計算するだけだ。
５分と経たずに再計算終了（というかほとんど一瞬）。顧客との商談が成立すれば、この金額とスケジュールを以って、その後のプロジェクトを運営していく。
プロジェクト発足
プロジェクト発足のために、多少のスタッフの調節を行う。プレ商談に公募したスタッフを集めて、最終的に決定した金額やスケジュールを説明する。スケジュールが短くなれば、増員が必要なので新しいスタッフを公募する。商談の規模が小さくなり、金額が少なくなればプレ商談で集めたスタッフの幾人かはお引取り願うしかない。スタッフにとっても、仕事がないと食えない。口をあけていれば上からプロジェクトが降ってくるわけではないので、別のプレ商談や成立商談によるスタッフ公募に対して、応募していかないといけない。人はそれぞれだし、いろいろな価値観があるから、プロジェクトに対する希望のさまざまになる。マネージャとスタッフの面談によってもよいし、スタッフ全員の話し合いによってもよい。場合によったら、リーダー格を中核とした定常的なスタッフチームがあるかもしれない。
リーダーとスタッフの違いはなんだろうか。全体を統括するプロジェクトリーダーと、設計・製作・試験を担当するスタッフの違いは何かといえば、役割と責任範囲の違いになる。プロジェクト全体の進捗やリスクの部分を常に監視していく。遅れそうなスタッフがあったら、仕事の調節をする、再配分するフォローする。設計担当のスタッフと一緒に顧客、設計を煮詰めていく。製作スタッフにイテレーションの指示をする。顧客にフィードバックする。
プロジェクト運営
マネージャは、顧客とプロジェクトリーダーとの間に立ち、取りまとめ役になる。なんらかの資材が足りなくてプロジェクトが前進できないのであれば、マネージャが取り除く。顧客の反応が悪ければ顧客をつっつく。プロジェクトが遅れそうになっていれば、リーダーを含めて対策を練る。顧客に非があれば、顧客をつっつく。プロジェクト側に難点があれば、改善する方策を練る。マネージャの仕事は簡単だ。「どう順調？」とリーダーに聞くだけで済む。プロジェクトが順調であれば、マネージャはなにもしない。うまくいっているプロジェクトをこれ以上かき回してはいけない。「これこれこういう問題があるんです」とリーダーに相談されればしめたものだ。未然にリスクが分かったのだから、一緒に対策を練ればいい。問題なのは、「順調です…」とてんてんてんがついているリーダーの言葉だ。口ごもるリーダーは危険だから、慎重に対策を練っていこう。
プロジェクト運営にはさまざまな障害がある。大きな石ころが不意に出てきたり、雨が降ったりする。なぜか突然道が石ころまみれになったり、夜道を歩かないといけない羽目になるときもある。
そういうときには、自転車から降りて歩いたり、ライトをつけたり、わき道で一休みしたりする。夜に寝たり、つまみ食いをしたりして気晴らしをしよう。なにも前進だけの道でもない、少し後ろを振り替えて池の周りをうろついたりしてみたって構わない。
けれども、最終的なゴールは決まっていて、スケジュール通りにプログラムを完成させて、工数も大幅な増加はなく達成したい、気持ちは一緒のはずだ。
プロジェクトの運営方法にはいろいろある。古典的な管理主義でもよいし、対極にあるXPでもよい、RUPでも、CMMでも、FDDでも、スクラムでも、…（ここにあたなの好きなプロジェクト運営をいれること！）でも、よい。
誰も連日の徹夜は好まないし、険悪な人間関係は好まない、同じスタッフが離脱していくのを見るには忍びないし、失敗するプロジェクトにいたくはない。つまらない作業を延々と続けるのは気がめいるし、顧客と喧嘩別れになってしまっても困る。いろいろな妥協点があって、スタッフそれぞれの考えがあって、ひとつのプロジェクトができているのだから、なにかいい方策があるだろう。だから、プロジェクトに一番あった方法を選ぶ。
ルーキー
半年間の新人研修を終えたスタッフが入ってくる。これを「ルーキー」と呼ぶ。ルーキーには、新たにプログラマという世界が待っている。やる気は満々なのだが、スキルは足りない。スキルは足りているかもしれないけど、経験が足りない。スキルも経験は足りているルーキーがいたら…、それは最早ルーキーではない。
ルーキーを足手まとい、金食い虫、簡単なツールしか組めない厄介者と見るならば、それは間違いだ。ルーキーはレベル１なので、何でも吸収する能力を持っている。多かれ少なかれ、経験を積んだスタッフよりも素直に仕事をしてくれる。ときどき間違いをしてくれるけれども、フォローしていけばだんだんと形が出来上がってくる。３，４年目のスタッフとルーキーとの相性が一番よい。それ以上になると、先輩後輩の上下関係がルーキーの心に中に芽生えてしまって、素直に聞くというよりも強制的に聞かされている感じになってくる。１、２年上のスタッフだと、スキルや経験がまだまだだったりするので、元ルーキーが、新ルーキーと区別がつかなくなってしまう。
ルーキーに教えたプロジェクトの流れは、ルーキーの中で少しずつ育っていく。プログラムの世界は流れが早いから、数年後には陳腐化してしまうかもしれない。逆に、ひょっとすると、このプロジェクトがルーキーの良い成功体験になって、再びマネージャやリーダーの元に戻ってきてくれるかもしれない。
どちらにせよ、ルーキーには将来性に期待するのであって、目の前の即戦力を期待しているのではない。新しい目と新しい視点と、ルーキーの起こすちょっとした間違いが、プロジェクトの危機を救うこともある。まあ、救わないこともあるけど、ルーキーがヘマをしたところで、プロジェクトが潰れないことだけは確実だ。
