人人月の寓話
わたしがまだ新人プログラマだった頃、キックオフミーティングで渡された仕事の割り振り表のメンバーの欄に「X」と書かれていたことがありました。
「Xって誰ですか？」と尋ねると「そのうち現れるであろう誰か」という答えが返ってきました。要するにエンジニアを確保するつもりはあるんだけど見つかっていないということです。「ホントに現れるのか？」とわたしは疑っていましたが「X」は現れました。
ていうか、わたしでした。
リーダーから「X」と命名（？）された先輩とわたしは2人でその担当分を片づけることに（もちろん本来の担当分も片づけた）。
「結局見つからないんだったら、最初っからXなんて書かなければいいのに」とグチったら、一緒に担当分を増やされた先輩に「上の人間もぎりぎりまでがんばって探してたんだよ。いないものはいないんだから仕方ない。いる人間でがんばって片づけよう」と諭されました。
その後、さまざまなプロジェクトを経て、いない人を「X」と書いたあのリーダーは正直者だったんだなあ、と思うようになりました（苦笑）。
なんとかして頭数があっているようにみせかけますもんねえ、普通（←簡単にバレるけど）。
それからさらに数年経って、その時点でのリーダーに「X」の話をしたところ、「そうやって頭数を合わせるのも大変だけど、結局のところ重要なのは仕事量を合わせることなんだよ」という話をしてくれました。
リーダー「開発能力は足し算じゃなく掛け算だ。1の仕事ができる人と0.5しか仕事ができない人を組ませると、普通に考えれば1＋0.5で1.5だけど、実際には1×0.5で0.5になるんだよ。それなら1の人が1人で仕事をした方がマシ。もしくは0.8が2人で0.64の方がまだ数字がいい」
わたし「でもそれだと、1未満の人は数字を減らすだけだから、いない方がいいってことになりませんか？」
リーダー「うん、そうなる。だから労力と金をかけて人を足すより、できないヤツを引く方がいいってこともある。でも、今は1未満でも育てて1以上にしとかないと将来的に苦しくなるから我慢して使うという判断もある。それでも苦しい時は仕事の割り振りを変えて、掛け算の枠からはずれるように仕向ける。1未満でも足し算にすれば数字はあがる」
わたし「それと、その計算だと1の人はどれだけ集めても1にしかなりませんけど」
リーダー「いわゆる力仕事的なプログラムは話が別だけど、そうじゃないものは1の人間がどれだけ集まっても1の仕事しかできない。おかしいと思うかもしれないけど、そういうもんだ」
わたし「じゃあ、1ってのは一人前って意味じゃないんですね。人の足をひっぱらないレベルということですか？」
リーダー「まあ、そんな感じ」
わたし「これまで、そういうことまったく考えたことなかったです」
リーダー「君はそんなことまったく考えなくていいから、もっと自分の数字をあげておれを楽にしてくれ！」
要するに頭数「X」よりも、その人が持っている能力値の変数「x」の方が、リーダーとしては問題だということらしいです。
仕事量を現す「人月」（＝頭数×月数）という言葉がありますが、そのリーダーの計算方法は「人人月」（＝能力値×能力値×月数）ということになりましょうか（←「能能月」という言い方もできるけどなんか音の響きがイマイチ）。
人月計算は「頭数×能力の平均値×月数」な考え方なので、1の人が10人いて1カ月だと10になりますが、人人月計算方式でいくと1にしかなりません。これはものすごい差ですね。10の人が1人と1の人が9人で1カ月なら10になりますけど。
チームでシステムを作っている限り、人と人の係わり合いが作業量に影響するというのは自然なことで、この「人人月」理論の方がなじみやすいというか、納得しやすいというか。
評価する人間の考え方や、与えられる仕事内容で、数字はずいぶんと違ってくるでしょうし、そのリーダーだって厳密に部下を数値化しているわけじゃなくって、目安としてそういうとらえかたをしているだけだと思いますけど。
そんなリーダーの話をきいてから、わたしは折に触れ、そのことについて考えるようになりました。
わたしの「x」は今どれくらいなんだろうか。誰の「x」に助けてもらってるんだろうか。誰かの「x」を支えてあげられているんだろか。わたしはわたしの「x」をまだ上げることができるんだろうか。
それを考えたからって何がどうなるものでもないと思いますが、なんだかちょっと気持ちが落ち着くというか客観的になれます。
それに、誰かに「x」を補ってもらいながら、誰かを補う「x」を獲得していく。そうやってエンジニアたちの係わり合いはリレーされていくのだなあ、とか想像すると、なんか楽しい気分になったりしません？（←わたしだけかも）
ところで、そんな話を聞かせてもらった当時は、「1の人間はどれだけ集まっても1」の理由がさっぱりわからなかったんですけど、仕事を続けているうちに、それっぽい現象に何度か遭遇しました。
わたしが観察した印象では、推進力がないんですね。誰かが指示を出してあげればそこそこ仕事はできるんですけど、指示なしではどこに向かっていけばいいのかわからなくて、その場に立ち尽くしてしまう感じです。なるほど、その場に立ち尽くしてしまう人間が何人いても、やっぱりその場から動けないんだなあ、と納得してしまいました。
でも、こういう場合はここに向かえばいい、というパターンをある程度、覚えれば、そういう子たちもいつかは自分から動きだすようになります。それがレベル1からの脱却ということなのかもしれません。
エンジニアの頭数は有限、時間も有限（ていうか常にタイト）です。
けれどプログラマとしての「x」は自力で増やせるのだから、青天井を目指してしまおう！ とか元気な時には思ったりします（苦笑）。そして、年で「x」が減った、と定年までは言いたくないなあ、と常に思っているのです。
コメント
ちょびちょび
こんばんは。ちょびちょびです。
ひでみさんのところにもいらっしゃいましたか。「X」さん。机とパソコンまで手配されたのに、ついに現れなかった「X」さん。「X」さんは透明人間だったのかな～とか思ってましたが、そんなわけないですよね。会計データを扱うことが多いから「X」さんの気配は随所に感じます。まあ、請求単位が人月だったりするから、＋αの能力については「X」さんで対処するしかない業界の体質もありますが。
0.5前後の新人が2名でも、組み合わせによっては＋になったり÷になって一人前以上の仕事を仕上げちゃったり、人間って面白いですよね。ああ。人間観察している場合じゃないか。ちょびちょびも「x」増やさないと。
なんだか
ひでみさん
こんばんは、なんだかです。
リーダーさんの人人月の話は、日々私も感じている事です。
私の経験での人人月を計算式で表すと、
PLの能力 ×（メンバーの能力 × メンバーの能力）× 月数
でしょうか、、、本当は、PMやお客さんといった要素も入るのですが、シンプルに。
問題解決の早さも、メンバーのモチベーションも、PL次第で大きく左右される
大切な要因だと、最近痛感してます。
＃自分がPLの時も、そうじゃ無い時も。。。
がると申します。
なんといいますか…「真っ当な話だなぁ」と思ってしまったので、つい書き込みを(苦笑
大抵の場合。
５の能力を持つ人一人よりも「0.1の人を50人」のほうが「効率がよい」って思う人が多いんですよねぇ…で、後々「もの凄い事」になるのですが orz
お久しぶりです。ちょりぽんです。
これこそコラム。と思いながら、読んでいて安心感がありました。今後とも楽しみにしてます。私は特に書きたいこともなく、すっかりサボっていますが（笑）
まったりと平和な日々を過ごしています。
コラムの感想ですが、積算として振る舞えるのは中堅～ハイクラスに求められる資質で、もちろん自分のタスクは120%こなしていることが前提ですね。そして、能力が１未満の若手が居れば、それを周囲が配慮して、和算となるようコントロールするのがベターでしょうね。ポジションの縛りなく、これらが出来れば良いですね。
ちなみに私の身の回りですと、"能力3の3人"よりも、"能力10の人1人"を求める兆候が強いです（こういう3人は容赦なく切られています）。3人が逆立ちしても生み出せない成果を、能力10の1人は軽くアウトプットできたりしますから、信頼度やお金の面で考えても後者にニーズがありますよね。
何人も頭を抱えて悩んでる課題を、1人のスペシャリストの鶴の声が解決してしまうというケースが頻繁にあること、これもこの業界の愉快な一面でしょうか（笑）
でも本当に現実的に考えると、和算積算が適用できるのは工場ベースの考えが成り立ってのことですね（工場ベースというのは、製造の手法が固まっていて、あとは能率を追及することに集中できるという意味です）
我々はクリエイティブだと思っているので、なかなか思い通りに行かない現実があります（業界自体が未熟ということもある）。ですので、積算を巻き起こせる人間は一握りになっています。これがニアリーイコールで市場価値なのかなと。
それでは。
ひでみ
こんばんわです。ひでみです。
いつもながらお返事が短くてすみませんです。
ちょびちょびさん。
> 0.5前後の新人が2名でも、組み合わせによっては＋になったり÷になって
> 一人前以上の仕事を仕上げちゃったり、人間って面白いですよね。
組み合わせによってはゼロになるパターンもあったりしますね。
大ゲンカしたあげく、両方ともチームからいなくなってしまうという（←サイアクだ）。
これはもう能力が云々という問題ではないですが。
人と人の性格や能力の相性というものは、計算で出せるようなものではありませんが、マネージメントを任されている人たちはできるかぎりの近似値を出そうと、頭を悩ませているんでしょうね、多分。
なんだかさん。
> PLの能力 ×（メンバーの能力 × メンバーの能力）× 月数
PLの能力値が1未満だったりすると、かなりおそろしいことになりますよね、この公式（苦笑）。
リーダーがメンバーよりも大きな影響力を持つというのは当然ですけど。
がるさん。
> ５の能力を持つ人一人よりも「0.1の人を50人」のほうが「効率がよい」って
> 思う人が多いんですよねぇ…で、後々「もの凄い事」になるのですが
人数が増えれば増えるだけ本当にものすごいことになりますよね。
私がみてきた「人海戦術」はたいがい失敗に終わっています。
人を増やすとどうみても非効率なことになるのにどうしてそんなことをするのかきいたところ、「人を増やすと、とりあえずお客様が納得する」とかいうおそろしい返事がかえってきたことがありました。
バブリーな話です。
ちょりぽんさん。
> これこそコラム。と思いながら、読んでいて安心感がありました。
なっ、なんですかっ。私をおだてても何もでませんよっ（笑）。
> ちなみに私の身の回りですと、"能力3の3人"よりも、"能力10の人1人"を求める
> 兆候が強いです（こういう3人は容赦なく切られています）。
> 3人が逆立ちしても生み出せない成果を、能力10の1人は軽くアウトプットできたり
> しますから、信頼度やお金の面で考えても後者にニーズがありますよね。
“能力10の人”を求めるのは当然かと思いますが、たいていの場合“3の人”の時期を経て“10の人”になるので、その途中でへし折られるのはもったいない話です。まあ、3で頭打ちになる可能性も高いですけど。
チームの中に“能力10の人”がいるとして、そのチームのリーダーやメンバーがちゃんとその人を助ける振る舞いをするか、自分の能力をひきあげる努力をするかすればいいんですが、現実には頼れるだけ頼っちゃう人が多くて、大惨事を招いたりします。
ひでみさん、こんばんは。
> なっ、なんですかっ。私をおだてても何もでませんよっ（笑）。
サイト全体が、ＩＴ業界の人離れを助長するような方向に向かいつつあったもので、つい（笑）願わくば＠ＩＴ編集部にもこの辺を汲んだ月次テーマを考えてもらいたいかなーと思っていたもので（季節も踏まえて）。
業界のネガティブ要素を覆い隠そうとは思わないんですが、この時期にそのテーマ・・・っていう思いが個人的にあったもので。ネガティブなイメージを持って、選択肢から除外した４年生が少なくないんじゃないかなぁと、遺憾に思っていたところ前向きなコラムの内容にコメントした次第です。
新規参入が減るということは、それだけ有能な人材に巡り合える機会を損失してしまうので、会社組織の一員としての私は危機感を持たざるを得ないんですよね。
そんな中で当コラムが琴線に触れ、堪らなくコメントしました。他意はございません（笑）
Atsushi777
こんにちは。
感覚的にはとてもわかる気がします。
速度に対する加速度みたいな。
ただ、開発規模による影響は大きいのではないかと思います。
スーパーマンがいさえすれば1人や2人程度でできるものと、
どうやっても10人は必要なものと、
それこそ100人オーダーは必要なものとでは、
この話も少し違ってくるのかもしれないとちょっと思いました。
Jitta
私も安心して読めました。感想なんだか何が言いたいのだかよくわからないコラムが増えているなか、文章の構成もまとまっているし、どういう情報をもとに何に意見をしているか、一度読めばわかります。二度読むと、深みが出ます。
うちのブログも、こういう文章が書きたいなぁ。いつも言葉が、少なすぎるか多すぎるか。中庸にならないorz
本文、リーダーというか、マネージャーなのか、「まとめ役」の能力も、作用しますよね。最近、ミリタリー小説を読んでいるのですが、指揮系統がハッキリしています。上官の「理想」を、下へ具体化しながら命じて行きます。まぁ、理想と現実は、違っているものですが。
forseti
私も久しぶりに頑張ろうと思えるコラムに出会えました。
自分のコラムも何とかしないとorz
> 普通に考えれば1＋0.5で1.5だけど、実際には1×0.5で0.5になるんだよ
逆を言えば1より大きい人が連携すれば自分の能力も相手の能力も上回る良い結果が出るって事ですよね。
過去に 2 × 2 程度ですが3以上くらいのの成果が出た事があり、この時はやりがいもあっていい仕事してたなぁと思います。
よみこ
ひでみさんのコラムおまちしてました
「ググる～」からすっかり虜です
ひでみさんの構成力の良さも際立っていますが、こういう話が出てくる職場は良い職場だなと思いながら読ませていただきました
「目の前のことを片付ける・問題をクリアする・問題を起こらない工夫をする」
そういう話はもちろん当然だし、やるべきなんですが、こういう話はまたそれと少し違うような気がします
目の前の問題でなく、（人を育てる等）将来の話という感じですか
こういう話って、記憶に根付きますね
私ももっと×を増やせるように心がけていきたいなと思います
でも、凄く難しい（笑）
なんだか
ひでみさん
>PLの能力値が1未満だったりすると、かなりおそろしいことになりますよね、この公式（苦笑）。
>リーダーがメンバーよりも大きな影響力を持つというのは当然ですけど。
PLの能力値が1未満 って事は、サポートを必要とする人って事ですよね。
その人が1人でやっているってことは、失敗は火を見るより明らかだと思うので。
#後は「運」でしょうかね。でも運任せ自体、失敗してる気がするし・・・
船頭多すぎても回りませんが、船頭が迷走しては、船は確実に山を登ります。
そういう意味もこめての掛け算ですね。
この所、失敗している重要な要因がPLにあるケースが身の回りに増えている
気がするので、そのせいかも知れませんが・・・（苦
まぁ、メンバーの総合力が1未満では、PLが1以上でも効果が薄い。
やはりチーム全体の総合力が大事ですよね。
Buzzsaw
ランチ後の眠い中、本文中の「x」についてあれこれ考えてしまいました。
xを増やしたいと思いながら日々を過ごし、xがインクリメントされていって
いることをたまに実感しながら、けれど自分の思い上がりかも？と不安になりつつ、だけどたまに周囲の誰かによってxの値が思ったより高く評価されてちょっと
安心したり。どう考えても変数xは自分の中のプライベート変数なのに、なぜか
自分からはその値が見えない。いつどこで x++; となっているかもわからない。
不思議ですね。あ、もしかしたらスーパークラスに・・・（以下自粛）
ひでみ
こんばんわです。ひでみです。
Atsushi777さん。
> 開発規模による影響は大きいのではないかと思います。
それは確かにそうですね。
100人規模くらいになると、個々のプログラマの能力よりも、マネージャやリーダーたちの力量で大きく左右される印象があります。
Jittaさん。
ななななっ、なんですか。どこかで人を褒めて育てようキャンペーン中ですかっ。
自分、褒めれば伸びますよ（←間違った方向に（笑））。
forsetiさん。
> 逆を言えば1より大きい人が連携すれば自分の能力も相手の能力も
> 上回る良い結果が出るって事ですよね。
「こんな手はどうだっ！」「いや、それならここをこうすればさらにっ！」とか言い合っている時間はめっちゃ楽しいですよね。
自分にはなかった発想が相手から出てきたりすると「くやしい～っ！」とかわめいてみたり（←おとなげない）。
よみこさん。
> 目の前の問題でなく、（人を育てる等）将来の話という感じですか
> こういう話って、記憶に根付きますね
私はずっとプログラマなもので、マネージメント関係のことを私に話してくれた人はめずらしいので、特に印象に残っているのかもしれません。
目の前のコードばかりに夢中になってしまう傾向があるので、たまに思い返して、一人でやってるわけじゃない、と自分を戒めています。
なんだかさん。
> 船頭多すぎても回りませんが、船頭が迷走しては、船は確実に山を登ります。
迷走しているのに、自分が迷走していることに気づかないタイプが一番やっかいだと思います。
重要なのは、チーム全体の総合力というか、互いの能力を補いあおうという意識なのかもしれません。
Buzzsawさん。
> どう考えても変数xは自分の中のプライベート変数なのに、なぜか自分からはその値が見えない。
私にも自分の「x」はいまだにわかりません。
なんかもう漠然としすぎていて。
でも、漠然としているからこそ、いろいろなことについて考え直すいいきっかけになってくれているような気がします。