前回のエントリで、プログラマの業界が労働集約的なものと知識集約的なものにわかれてきているという話を書きました。
プログラマ業界の二分化 - きしだのはてな
前のエントリでは労働集約的なものと知識集約的なものに完全にわかれているように書きましたが、もちろん完全に労働集約的であったり完全に知識集約的であったりすることは少なく、どのような組織でもある程度は両方の性質をもっています。知識集約的な性質の強いSI会社というのもあります。 ただ、SIに労働集約的な、サービスに知識集約的な性質が強くなる傾向はあると思います。 また、知識集約的であればよくて労働集約的であればダメということもありません。労働集約的なSIでありながら良い会社というのもあります。
という断りをいれておかないと、SIで労働集約だからといって全部ひとからげにするなという、労働集約的なSIでありながら良い会社方面から鋭利なマサカリが飛んできます。いい会社であれば労働集約的SIの人のほうが切れ味するどく触れれば即死レベルのマサカリもってますから注意が必要です。
ということで、労働集約的な業界で生産性をあげるにはどうするかということを考えてみます。
この場合に生産性をあげるために必要なのは、残念ながらJava8やAnglarJSではありません。 よく、プログラミング言語で記述量が少ないほうが生産性が高いという話が出ますが、その差がでるのは知識集約の業界で、労働集約の業界であればおそらく差はでないでしょう。コピペにコストはかからないので。 また、新しいバージョンのフレームワークや言語の採用にはコストがかかり効率も悪くなるので、短期的には生産性を下げます。習得して生産性があがっても、初期の生産性低下のコストを回収したころには次のバージョンが出てきます。そのため、中期的にはバージョンアップしなくても生産性はかわらないと思います。
生産性をあげるには、上流工程、製造工程の作業の速さをあげること、精度をあげることが必要です。精度をあげるというのは、手戻りを少なくすることになります。 ここで製造工程と書きましたが、プログラミングを知識集約作業と考えれば違和感ありまくりだったこの言葉も、労働集約作業であれば納得です。 製造工程の速さをあげるには、自動化は有力な手段になり得ます。人為ミスが減るので精度もあがるでしょう。 ただし、ソフトウェア製造の自動化は、不勉強でもボタンを押せば完成というものではなく、それなりの技術力を要します。万能な自動化はないので、使いどころは適切に選ぶ必要があり、そこには技術力が必要です。 あと、知識集約的な観点から自動化は不可能と批判するのは、的外れであるばかりか活動を萎縮させて足をひっぱることにもなるので有害です。自動化団体に入ろうと思ったら条件が閉鎖的だったとか、そういう根拠ある批判をしましょう。
教育は、速さをあげることにも精度をあげることにも有効です。ここでの教育には自発的な勉強も含めます。 必要な作業時間を短くすることができ、完成したって報告をうけて実行してみたらコンパイルエラーとか、そろそろ納品できるかなと思ったら仕様が根本的なところから変わるとかいうのが減らせて精度があがります。技術力があれば自動化ツールを最大限に活かすこともできます。 ただし教育は、知識集約の業界であれば処理能力向上や機能強化が即利益に結びつくので、わかりやすいメリットがあり力を入れやすいですが、労働集約の場合、生産性向上のみが利益になり、教育から生産性向上、利益という道のりが長いため、なかなか教育には力が入りません。あと、教育して知識集約業界のほうに逃げてられてしまっては元も子もないというのもあります。 残業いとわず働きますという教育なら楽で即効性ありますが・・・。それではコスト対効果はあがっても、ここで生産性として話題にしている人月対効果はあがりません。
教育で得られるような処理能力向上や機能強化が利益になりにくいというのは、労働集約業界の特徴です。 2002年にリリースされたJava2 SE 1.4とStrutsを組み合わせたシステムと、今年2014年、来週にもリリースされるJava SE 8とAnglarJSを組み合わせたシステムとで、受注金額を変えることはできないでしょう。 生産性でいえば、逆に10年来のいろいろが煮込まれた不思議ノウハウでJ2SE1.4+Strutsのほうがリスクなく手早く作れるかもしれません。人も集めやすいです。Java SE 8+AnglarJSでは、いろいろ罠にはまって時間がかかってしまうでしょう。おそらく人も集まらないので人員教育の必要もあります。
先にも書きましたが、このように、労働集約な業界では、新しい言語、新しいフレームワークを使うメリットが短期的にはまったくないわけです。 しかし、技術更新しないということは、真綿で首を絞めるように、長期的なデメリットが出てきます。 古い言語、古いフレームワークを使いながら新しい要求に応えていくことには、どんどん無理がでてきて不思議ノウハウをもってしても生産性がさがってきます。というか、不思議ノウハウでは新しい要求に対応できないことのほうが多いと思いますが。 そして、Java2 SE 1.4とJava SE 8では、やはり書きやすさ、読みやすさ、品質の維持しやすさが違います。
ところが、こういったデメリットが顕在化してどうにもならなかったときには手遅れです。10年分の技術更新にはかなりのコストがかかります。 というか、教育の習慣のない組織が、いきなり言語覚え直しにも近い学習の機会を確保できるとは思えません。 全員参加の講座は無理でしょう。せいぜい、﹁精鋭﹂が選抜されて研修を受けることになります。それにしても、一番受けるべきエース、技術リーダーは忙しすぎて参加できず、日頃の業務についていけず再教育の必要がある人は選抜からはずれます。 そして1週間の研修が始まると、無理して参加した上役や技術リーダーは、初日の15時頃に電話がかかってなかなか帰ってこず、二日目の昼食後に作業が入ったからと抜け、三日目から姿を見せないということになります。
まあ、もちろんそれでも、ちゃんと時間をとって勉強することは大切です。 ただやはり、ちゃんと効果を出していこうとすると、短・中期的なメリットがないまでも継続的に教育・勉強していく必要があります。 労働集約的な組織で継続的に教育・勉強するというのは実は技術レベル向上としては最高です。マサカリも切れ味するどくとがれていきます。 もし素人がそのマサカリに触れれば即死でしょう。ぼくであれば、致命傷におさえることができますけども。
前のエントリでは労働集約的なものと知識集約的なものに完全にわかれているように書きましたが、もちろん完全に労働集約的であったり完全に知識集約的であったりすることは少なく、どのような組織でもある程度は両方の性質をもっています。知識集約的な性質の強いSI会社というのもあります。 ただ、SIに労働集約的な、サービスに知識集約的な性質が強くなる傾向はあると思います。 また、知識集約的であればよくて労働集約的であればダメということもありません。労働集約的なSIでありながら良い会社というのもあります。
という断りをいれておかないと、SIで労働集約だからといって全部ひとからげにするなという、労働集約的なSIでありながら良い会社方面から鋭利なマサカリが飛んできます。いい会社であれば労働集約的SIの人のほうが切れ味するどく触れれば即死レベルのマサカリもってますから注意が必要です。
ということで、労働集約的な業界で生産性をあげるにはどうするかということを考えてみます。
この場合に生産性をあげるために必要なのは、残念ながらJava8やAnglarJSではありません。 よく、プログラミング言語で記述量が少ないほうが生産性が高いという話が出ますが、その差がでるのは知識集約の業界で、労働集約の業界であればおそらく差はでないでしょう。コピペにコストはかからないので。 また、新しいバージョンのフレームワークや言語の採用にはコストがかかり効率も悪くなるので、短期的には生産性を下げます。習得して生産性があがっても、初期の生産性低下のコストを回収したころには次のバージョンが出てきます。そのため、中期的にはバージョンアップしなくても生産性はかわらないと思います。
生産性をあげるには、上流工程、製造工程の作業の速さをあげること、精度をあげることが必要です。精度をあげるというのは、手戻りを少なくすることになります。 ここで製造工程と書きましたが、プログラミングを知識集約作業と考えれば違和感ありまくりだったこの言葉も、労働集約作業であれば納得です。 製造工程の速さをあげるには、自動化は有力な手段になり得ます。人為ミスが減るので精度もあがるでしょう。 ただし、ソフトウェア製造の自動化は、不勉強でもボタンを押せば完成というものではなく、それなりの技術力を要します。万能な自動化はないので、使いどころは適切に選ぶ必要があり、そこには技術力が必要です。 あと、知識集約的な観点から自動化は不可能と批判するのは、的外れであるばかりか活動を萎縮させて足をひっぱることにもなるので有害です。自動化団体に入ろうと思ったら条件が閉鎖的だったとか、そういう根拠ある批判をしましょう。
教育は、速さをあげることにも精度をあげることにも有効です。ここでの教育には自発的な勉強も含めます。 必要な作業時間を短くすることができ、完成したって報告をうけて実行してみたらコンパイルエラーとか、そろそろ納品できるかなと思ったら仕様が根本的なところから変わるとかいうのが減らせて精度があがります。技術力があれば自動化ツールを最大限に活かすこともできます。 ただし教育は、知識集約の業界であれば処理能力向上や機能強化が即利益に結びつくので、わかりやすいメリットがあり力を入れやすいですが、労働集約の場合、生産性向上のみが利益になり、教育から生産性向上、利益という道のりが長いため、なかなか教育には力が入りません。あと、教育して知識集約業界のほうに逃げてられてしまっては元も子もないというのもあります。 残業いとわず働きますという教育なら楽で即効性ありますが・・・。それではコスト対効果はあがっても、ここで生産性として話題にしている人月対効果はあがりません。
教育で得られるような処理能力向上や機能強化が利益になりにくいというのは、労働集約業界の特徴です。 2002年にリリースされたJava2 SE 1.4とStrutsを組み合わせたシステムと、今年2014年、来週にもリリースされるJava SE 8とAnglarJSを組み合わせたシステムとで、受注金額を変えることはできないでしょう。 生産性でいえば、逆に10年来のいろいろが煮込まれた不思議ノウハウでJ2SE1.4+Strutsのほうがリスクなく手早く作れるかもしれません。人も集めやすいです。Java SE 8+AnglarJSでは、いろいろ罠にはまって時間がかかってしまうでしょう。おそらく人も集まらないので人員教育の必要もあります。
先にも書きましたが、このように、労働集約な業界では、新しい言語、新しいフレームワークを使うメリットが短期的にはまったくないわけです。 しかし、技術更新しないということは、真綿で首を絞めるように、長期的なデメリットが出てきます。 古い言語、古いフレームワークを使いながら新しい要求に応えていくことには、どんどん無理がでてきて不思議ノウハウをもってしても生産性がさがってきます。というか、不思議ノウハウでは新しい要求に対応できないことのほうが多いと思いますが。 そして、Java2 SE 1.4とJava SE 8では、やはり書きやすさ、読みやすさ、品質の維持しやすさが違います。
ところが、こういったデメリットが顕在化してどうにもならなかったときには手遅れです。10年分の技術更新にはかなりのコストがかかります。 というか、教育の習慣のない組織が、いきなり言語覚え直しにも近い学習の機会を確保できるとは思えません。 全員参加の講座は無理でしょう。せいぜい、﹁精鋭﹂が選抜されて研修を受けることになります。それにしても、一番受けるべきエース、技術リーダーは忙しすぎて参加できず、日頃の業務についていけず再教育の必要がある人は選抜からはずれます。 そして1週間の研修が始まると、無理して参加した上役や技術リーダーは、初日の15時頃に電話がかかってなかなか帰ってこず、二日目の昼食後に作業が入ったからと抜け、三日目から姿を見せないということになります。
まあ、もちろんそれでも、ちゃんと時間をとって勉強することは大切です。 ただやはり、ちゃんと効果を出していこうとすると、短・中期的なメリットがないまでも継続的に教育・勉強していく必要があります。 労働集約的な組織で継続的に教育・勉強するというのは実は技術レベル向上としては最高です。マサカリも切れ味するどくとがれていきます。 もし素人がそのマサカリに触れれば即死でしょう。ぼくであれば、致命傷におさえることができますけども。
