身長168センチの、ユゲタです。
「ベルグマンの法則」ってご存知ですか？
地球で温かい地域にいる生物と、寒い地域にいる生物を比べると、寒い地域に生息している生物の方が大きくなるという理論なのだそうです。
そんな馬鹿な・・・と思っていたけど、暖かい地方にいるクマと北極にいるホッキョクグマは、ベルクマンの法則によって、大きさが違っていると聞くと、なんだか納得することができました。
似たような法則で「アレンの法則」というのもあるらしく、
寒冷地法に住む生物は、体の特定の部位（首・足・耳など体外に出ている部分）が極端に小さくなるのだそうです。
ニホンザルよりも、インドサルの方が、尻尾が長いというのも、この法則のようです。
そんな生物の法則の話を、今回はプログラミング界隈に置き換えて考えてみたいと思います。
かなりユゲタの思考により偏った記事になっているので、おふざけ記事として読んでもらって、真に受けないようにしてもらいたいことをはじめに言っておきます。
エンジニア人数が多い技術チームほど開発進捗が遅い件
人数が少ないベンチャー企業は、時間が経過して、売上など成果が伸びてきた時に、それを経営する側の人から、
次から次へと、アイデアを言われて、やらなければいけないことが雪だるま式に膨らんできます。
そうした時に、「人を増やす」という安易な選択をしてしまうと、とんでもなくチーム崩壊を招くことがあるので、
しっかりと少人数でのマネジメントを構築しておく必要があります。
ポイントは、「責任と分担」で、マネジメントする人が全ての責任を追うという単一成果方式にしてしまうと、従業員は責任感のない仕事を繰り返すだけのロボットになってしまいます。
責任が無いので、失敗に対して叱責をしても、何の反省も無く、同じ失敗を繰り返すダメロボットになる事もこれまでたくさん見てきました。
それぞれに、責任を与えて、その責任の責任をマネジメントが背負うという構造を理解できていないマネジメント担当者は、この先ずっと意味のないストレスを抱えて生き続けてしまうでしょう。
分担というのは、もちろん作業分担ということですが、複数の作業のリンクポイントを極力少なくするということがミソです。
リンク点が少なくなると、コンフリクトが少なくなり、それぞれの責任範囲が明確になってくるということと、分割するセグメントを増やすことで、その分割されたセグメントの数に応じた人員配置が、適応人員数ということになります。
単純に人数を増やすというだけに注力していると、とんでもない目に遭うということを事前に理解しておきましょう！
業務の目標を定めない会社ほど、エンジニアのモチベーションが高く新技術が生まれやすい件
なんとなく、やることをリストアップして作業している会社って、普通ですが、ここで重要なのは、「期限と、やり方と、重要性」と言われています。
一般的に、スケジュールは、重要というのは分かっていますが、往々にして遅れてしまうという事はよくあると思います。
ここで、やり方が間違っていないか、本当にその方式が効率がいいのかという、理論思考ができるかどうかで、その後の全てが左右されます。
最後に、それらも含めた仕事が、その後の成果にどのように影響してくるかという重要性の理解が大事で、
これを理解せずに、ただ、「言われたから」というだけで仕事をしていると、まるで力の入らない仕事になりかねないという事です。
でも、こうして、ガチガチに目標管理をシステム化して行っている企業の方が一般的だとも思える一方。
ベンチャー会社の少人数制でやっていて、中にはエンジニアが１人や２人ぐらいでやっているチームの生産性の高いこと高いこと。
ここには、目標もなければ、締切もベストエフォートです。
重要性に関しては、誰に言われるまでもなく、120%理解しているに違いありません。
ようするに、モチベーションがスピードや成果に洗われるいい指標なのかもしれませんね。
仕事が忙しいと言うエンジニアほど、ミスが多く、学習能力が低い件
仕事が詰まってくるとストレスが貯まり、ミスも増え、やる気も無くなってくるものですが、
面白いことに、そうならないエンジニアも存在します。
ユゲタがゲーム業界にいた時に、眠らないプログラマーという人がいて、みんなから「鉄人」と呼ばれていたんですが、
その人はとにかくゲームが大好きで、自分が作るゲームは面白くなるに違いないと常に思っていたらしく、
そんな面白いゲームを作っている、核となる自分の作業が、遊びのように楽しくて仕方がなかったと言っていました。
なので、仕事をしている感覚などなく、お金をもらって、自分を楽しませてもらって、作った後に、そのゲームで遊んだ人から、いいコメントがもらえるということを想像していると、
寝ている事すら惜しくなって、会社にほぼ泊まりっぱなしで、プログラミングに没頭していたのだそうです。
ユゲタも、EFO商材の初期開発の時に同じような体験をしたので、この境地は非常によく分かります。
おそらくベンチャー企業の立ち上げ時のサービス開発などは、プログラマーの人たちは同じ感覚ないでしょうか？
この時に、「忙しい」という言葉は出てきません。みんな決まって「楽しい」と言っているでしょう。
ということでプログラマーが「忙しい」と言っていたら、「仕事がつまらん」と言っているのと同じだと考えてもいいかもしれませんね。
その言葉からは、生産性も感じないし、創意工夫すらもしないネガティブワードであると、考えても間違いではないでしょう。
結論
結果的に何がいいたいかと言うと、
「寒い地方の動物は巨大化する」
という法則のように、
・人数が少ないチームほど生産性は高い
・目標を定めず好きなものを作るエンジニアは化け物的に成長する
・モチベーションの無いエンジニアは"忙しい"と言う
と言う風に、ユゲタは勝手に考えています。
共感するかしないかは、あなた次第です。
