Rubyを使うべき本当の理由は、根源的には、日本で自殺者が増えた理由と同じです。
今後日本が没落していく理由とも同じです。
団塊の世代に無能な人間が多い理由とも同じです。
サービス残業が増えた理由とも同じです。
日本の多くの若者たちが未来に希望を抱けない理由とも同じです。
いまの学校教育が無能な人間の製造工場になってしまっている理由とも同じです。
その理由は、根本的には、「単純ニーズの飽和」という環境変化に起因します。
そして、それによって、プログラミングが経営行為になってしまったことが原因なのです。
団塊の世代の仕事人生の大部分は、単純ニーズを満たすための仕事に費やされました。
冷蔵庫の普及率が低く、しかも誰もが冷蔵庫を欲しがった時代には、何をやるべきかは、明らかでした。
とにかく、額に汗して働き、安くてよい冷蔵庫をどんどん作れば良かったのです。
冷蔵庫に限らず、洗濯機、ラジオ、テレビ、自動車、エアコンなど、とにかく、人々が欲しがるものは明らかでした。「何」をすればいいかは明らかで、「どう」すればいいかだけが問題でした。
それが、単純ニーズを満たす時代です。
この時代、経営は経営者だけがやっていればよく、労働者は、経営者の示す方針通りに、真面目に一生懸命働けばよいだけでした。
経営行為の本質である、「不確定性の中で意思決定する」能力が、労働者たちに求められることはいまよりもずっと少なかったのです。
あらゆることが、いまよりもずっと明確で、確定的な時代でした。
これは、ソフトウェア開発の初期の時代も同じです。
それまで電卓とノートでやっていた経理処理や在庫管理を、コンピュータシステムで置き換えるためのソフトウェアを開発するのは、あくまで、開発作業でした。
作るべきシステムは、いまよりもずっと明らかでした。
しかし、それらの明白で単純なニーズは、やがて、あらかた満たされてしまいました。
飽和してしまったのです。
もはや、単に冷蔵庫を作っただけでは、利益はほとんど出ません。
単純な冷蔵庫市場は、もはや飽和してしまったのです。
冷蔵庫だけでなく、あらゆる単純ニーズが飽和してしまったのです。
そして、長年にわたり、単純ニーズを満たすために働くスキルを蓄積してきた団塊の世代は、産業廃棄物になったのです。
そして、入れ替わりに入ってきた若者たちを待ち受けていたのは、飽和市場という地獄の扉でした。
飽和した市場では、価格競争によって、利益は極限まで消滅していきます。
同じ製品なら、消費者は、少しでも安い方を買おうとしますから。
飽和した市場で、利益を出すには、
(A)コストダウン
(B)差別化
(C)環境変化への対応
を行う必要があります。
これらは、単純ニーズを満たすことに比べると、どれも、もっとずっと苦しく難しいことです。
コストダウンをするには、まずは、徹底的に無駄を省く必要があります。
でも、単純な無駄の削減など、ライバル企業もみんなやってます。
すべての単純な無駄を取り除いた後、さらに絞らなければ、利益など出ません。
競争が進むと、それこそ、過去に20人でやっていた仕事を、3人でやれるくらいの勢いでやらなければなりません。
単に、一人が3倍激しく働くくらいでは、とても追いつきません。
すぐに、ハードワークだけでなんとかなるレベルではなくなるのです。
それを実現するために、ありとあらゆる「創意工夫」が必要になるのです。
いや、単なる創意工夫というより、根本的な業務システムの見直し、根本的な発想の転換すら迫られます。
事業部の方針の見直しから必要になります。
それは、もはや、単なる労働ではありません。もはや、それは、経営行為です。
しかも、そこまでしてコストダウンしても、ごく一時的にしか利益は出ません。
そのコストダウン努力の成果はすぐに、飽和してしまうのです。
なぜなら、飽和市場では、ライバル企業も同じことをやっているからです。
だから、どんなに革命的なコストダウンを達成しても、安住の地にはたどり着きません。
永遠に改革し続け創意工夫し続け、コストダウンし続けなければなりません。
そうしないと、コストダウン競争で、ライバル企業に負けて、滅び去るしか無くなるからです。
われわれは、地獄へ向かう火車に乗っているのです。
すんでの所で、この火車から飛び降りて逃げることのできる団塊の世代は、ほんとうにラッキーです。
残されたわれわれは、ほんとうにアンラッキーです。ほんとうにありがとうございました。
そして、飽和した市場で利益を出す方法の2つめは、(B)差別化です。
同じ冷蔵庫を作っても価格競争で利益が出ないのなら、消費者がより高いお金を出してでも欲しがるような冷蔵庫を作ればいいのです。付加価値のある冷蔵庫を作ればいいのです。
しかし、これは、とても難しい。
まず第一に、何が消費者にとって付加価値となるかは、なかなか分からないからです。
そもそも、付加価値であることが明白な機能やデザインなど、ライバル企業は、とっくに装備しているはずです。
そういう機能は、単なる重荷でしかありません。
なぜなら、それをつけないと売れなくなってしまう上、つけても差別化にならないからです。
ケータイへのカメラ搭載が、携帯電話メーカーの重荷になったのと同じです。
つまり、付加価値競争においては、ちょっとやそっとでは、思いつかないような独創的な商品やサービスを創造しなければ利益は出ません。
しかし、消費者の心は移ろいやすく、状況の変化の影響を受けやすく、付加価値の創造には多くの不確定要素がつきまといます。
付加価値をつけた製品を開発したつもりが、さっぱり売れ無くって、利益をだすどころか、大赤字になることなど、しょっちゅうです。
しかも、血のにじむような努力をし、危ない橋を渡りまくって、ようやく独創的な商品やサービスによって利益をだせたとしても、すぐにライバル企業が類似商品・サービスを出しますから、利益はあっというまに、消えていきます。
やはり、ここにも安住の地はありません。
企業は、永遠に付加価値創造をし続けなければ、単に存続し続けることすら出来なくなっていくのです。
そして、新しいサービスを可能とするために、新しい組織体制が必要になり、新しい意思決定メカニズムが必要になり、新しい業務フローを作りださなければなりません。
これらも、もはや、従来のような、単なる労働行為ではありません。それは、もはや、経営行為です。
そして、(C)の変化への対応もし続けなければ、やはり、あっというまに、滅びます。
たとえば、一時期、携帯電話に携帯メール端末を接続して、メールを10円で送れる10円メールの会社が、かなりの利益を出していました。しかし、iモードの登場で、あっというまに消えてゆきました。
つねに、ビジネスの前提条件は変化し続けており、その変化への対応が遅れたものは、存在を許されなくなるのです。
そして、前提条件の変化に対応するために、自らの組織構造や業務フローを変化させ続けることは、やはり経営行為そのものです。
そして、飽和市場で利益をだすための、3つの手段である、コストダウン、差別化、環境変化対応は、どれも経営行為であり、そこでの勝敗を分けるのは、2つのスピードです。
そして、その2つのスピードは、お互いに矛盾しているのです。
まず、一つめのスピードは、業務の回転スピードです。このスピードが遅いと、同じサービスを作り出すのに、より多くの人件費コストが嵩み、より長く顧客を待たせ、より多くの在庫をより長く抱えることになります。
このスピードを上げるために、企業は、それまで人手でやっていた業務フローをコンピュータネットワークに置き換えてきました。
そして、競争に勝ち抜くため、どの企業も、常に業務の回転スピード上げ続けています。終わり無き連続加速です。
このため、企業は、ますます多くの業務をコンピュータソフトウェア化します。
これに対応するため、プログラミングの生産性向上はつねに求められ、プログラマの人口も増え続けています。
そして、もう一つのスピードは、変化への対応速度です。飽和市場で利益を出すための、コストダウン、差別化、環境変化対応は、どれも、会社組織自らの変化を要求します。飽和市場では、変化の対応速度が遅いと、利益が出なくなり、市場から消滅させられることになります。
しかし、ソフトウェアシステムというのは、人間だけで構成される業務フローに比べ、変化への対応により多くのコストがかかります。
もちろん、人間でも、業務フローを変更したてのときは、一時的には、現場が混乱し、トラブルが出て、生産性も低下します。しかし、少しずつ混乱もトラブルも鎮静化し、しばらくすると、生産性も元にもどります。
これに対し、ソフトウェアシステムは、変更して、少しでもトラブルが出ると、システム全体がいきなり停止してしまったりなど、よくあることです。たった一バイト、いや、たった一ビットですら、システム全体を機能不全にしてしまうような、不安定なシステムなのです。
つまり、コンピュータソフトウェア化しなければ、業務の回転速度が遅くなり、利益が出ません。
一方で、コンピュータソフトウェア化すれば、業務フローの変更速度が遅くなり、利益が出ません。
矛盾そのものです。
この矛盾が、これからのソフトウェアエンジニアを待ち受けているのです。
これからのソフトウェアエンジニアは、絶え間ないソフトウェアの書き換えを要求し続けられる運命にあるのです。
しかも、バカでも幸せに生きられた単純ニーズの時代と異なり、どのようにソフトウェアを書き換えればいいのかが、とても不明確です。なぜなら、飽和市場で生き抜くのに必要な3つの手段である、コストダウン、差別化、環境変化対応のための、業務システムやユーザサービスの変化への対応における不確定性が、どっとコンピュータソフトウェアの世界へ押し寄せるからです。
この3つは、どれも、労働と言うより、経営行為そのものです。
そして、経営の本質は意思決定であり、意思決定の本質は、不確定性なのです。
そもそも、不確定性がない場合、意思決定など、必要ありません。
不確定性がないということは、やるべきことは、機械的に決められるということです。
機械的に決められるのなら、わざわざ誰かが何かを決断する必要など無いのです。
このため、どんなにがんばっても、コンピュータソフトウェアの要求仕様から不確定性を取り除く作業が、ますます困難になっています。
その要求仕様が、経営リソースである製造装置の要求仕様書ではなく、経営そのものの要求仕様書だからです。
本質的に不確定性の塊である経営という行為の要求仕様から、完全に不確定性を取り除くなんて、あり得ないのです。
そもそも、要求仕様を固める側だって、不確定性を可能な限り取り除きたいのはやまやまなのです。でも、状況が不確定性にみちており、しかも変化し続け、常に判断が難しいのです。そういう状況では、完全な要求仕様書なんて、まず作れません。かなりソフトウェアシステムができあがってから、要求仕様書の中の大きな問題にようやく気づいた場合、エンジニアに理不尽なことを言ってでも、むりやり要求仕様を変更せざるをえないのです。
こういう時代においては、プログラミング行為のほとんどは、物作りではありません。
それは、どうしても、経営行為にならざるをえないのです。
不確定性の中で意思決定をし続けるプロセスの中に、いやおうなく巻き込まれれしまう運命にあるのです。
すなわち、プログラマーが、経営に強制参加させられる時代になってきているのです。
そして、経営行為において、もっとも重要なのは、意思決定の質とスピードであって、量ではありません。
どれだけ賢い判断を、どれだけタイミングよくできるかが重要なのであって、どれだけたくさんのものごとを判断したかが重要ではないのです。
もはや、ソースコードの一行一行が経営判断そのものになる時代に突入しつつあるのです。
そういう時代においては、プログラミングとは、まさに、不確定性との戦いです。
そして、不確定性が巨大なとき、巨大なコンピュータソフトウェアを構築するのは、時として自殺行為です。
戦艦大和のように、史上最強の戦艦を造り上げた時には、もはや戦艦の時代は終わり、戦争も終わってしまっているというような、マヌケなことになりかねないのです。
一枚岩的な巨大システムは、高速で変化し続けることが生存の前提条件となるような社会には向いていないのです。
そして、経営行為的な、不確定性の多いコンピュータソフトウェアの開発においては、どのようなプログラムをどう書けばよいのかを考える作業が、プログラミング時間の多くを占めるのです。
経営の本質とは、機械的に決められないことを、決定し続けることです。
そして、そういう経営の本質が持ち込まれた、現代におけるプログラミングの本質も、機械的に決められないことを、頭を悩ませて、決めることが、プログラミング作業の中心になります。
できるだけ、質の高い判断を、スピーディーにし続けることが、よいプログラマの必須条件になります。
つまり、走りながら走る方向を調整し続けるのが、現代のプログラマーなのです。
なぜなら、要求仕様のレベルにおいてすら、不確定性が多すぎて、走る方向をきちんと固めるのが困難な時代になってしまったからです。
そういう、走る方向を見極めながらのプログラミングにおいては、JavaやC#のような強い型付けのコンパイラ型言語よりも、Rubyのような動的言語の方が、有利になるケースが多いのです。
なぜなら、走る方向を見極めるには、細かい型の整合性なんて後回しにして、バグだらけでもいいから、とにかく動くものを作ってみることが重要だからです。
なぜなら、プログラミングが、習字のようになっているからです。
習字においては、清書をするのは、ほんとうに最後のころだけです。
最初は、どのように書けば美しい字になるかを模索するために、字を書くのであって、はじめからいきなり完成品を作るために、書き出す人などいません。
それと同じように、プログラミングの最初のころのフェーズでは、どのようにプログラムを書き上げるかの考えを模索し、イメージを固めるために、プログラムを書くのです。
どのようなプログラムをどのように書くかが機械的に決められる単純ニーズの時代には、仕様書を書く段階で、不確定性の多くの部分は、取り除かれていたので、プログラミングは、たんなるコーディング作業でしかありませんでした。プログラミングの意味も目的も、いまとは、ぜんぜん別物だったのです。
しかし、不確定性の海の中で、迅速にソフトウェアを開発し続けなければならない現代のプログラマーは、要求仕様が石のように固まるのを期待できないばかりか、それが十分に固まるのを待っていたら、状況変化への迅速な対応を可能とする迅速なプログラミングができないのです。
だから、刻々と変化する状況と不確定性の海を泳ぎながら、とりあえず動くシステムを書き上げてしまい、できあがってから、系統だったテストをして「清書」する、というスタイルの方が、向いているのです。
そして、JavaやC#における強い型付けは、「清書」のときには、大いに役立ちますが、とりあえず走る方向を見定めようと、ラピッドプロトタイピングしながら思考を練っているプログラミングフェーズでは、思考を阻害し、生産性を下げる邪魔者でしかないのです。
そして、そういう、「不確定性の時代」に向いたプログラミング言語の中で、もっとも無難な選択の一つが、Rubyなのです。
なぜ、PerlよりRubyのほうが有利なケースが増えつつあるのかというと、プログラミングの前半の、走る方向を調整していくフェーズでは、プログラム言語は、ある種のアイデアプロセッサであり、思考を練るツールなので、ソースコードの書きやすさだけでなく、直感的な読みやすさが重要だからです。
また、この思考を練るプログラミングフェーズは、いろいろな情報をモデリングしながら思考を整理しているフェーズでもあります。
Rubyのオブジェクト指向オタク的な表記法は、モデリングや人間の直感的な思考と相性がよく、アイデアプロセシングプログラミング*1に向いているのです。
そして、もちろん、アイデアプロセシングに集中したいときに、publicだのprivateだのprotectedだのと言った細かいアクセス規則や、引数の型の整合性をごちゃごちゃ調整するなんて、たんに思考の妨げでしかない場合が多く、JavaやC#など、まさに論外になってしまうのです。
もちろん、これからも、JavaやC#のニーズがなくなることはありません。
しかし、少なくとも、Ruby、もしくは、Rubyと似たような特徴を備える、直感的に読みやすいシンタックスを備える、オブジェクト志向の、動的言語が、時代の流れとマッチしていることは、言えるのではないでしょうか。
補足
もちろん、オイラ自身は、当分Rubyを使う気はありませんし、職業プログラマさんたちの多くも同様でしょう。
だって、この記事にも書いたとおり、プログラミング言語自体は、目的を達成するために必要な無数の要素の一つにすぎず、開発環境だとか、レガシーだとか、使えるライブラリだとか、チームメンバだとかそういうたくさんの要素から、総合的に決まるモノだからです。
たとえば、目的を達成するのに、あるライブラリが必要で、それが、Windows上でしか動かず、しかも、インタフェースがActiveXしかなく、それの複雑な動作分析と制御が必要で、しかも複雑なテキスト処理をするので強力な正規表現ライブラリが必要で、かつ、Javaではデータのロードが遅すぎて使い物にならないとしたら、C#かC++が妥当な選択でしょう。
同様に、いろいろなやっつけ仕事をするのには、言語なんかより、ライブラリの充実が重要なわけで、べつにJava言語を使いたいから使っているのではなく、Javaのクラスライブラリを使いたいからJavaを使うわけです。C#やVisualBasicが必要なのではなく、単に.NETのライブラリが必要で、VisualStudioのエディタマクロを使いたいだけなのです。
別にPerl言語を使いたいわけじゃなく、単に、CPANを使いたいからPerlを使ってるだけなのです。もちろん、RubyからCPANが自由に使えるようになったら、Rubyに乗り換えますけど。
*1:オイラが勝手に作った言葉