プログラミング言語Dartの「方向性」はやっぱり正しい

遅ればせながら(?)、Dartについて考えてみました。そしてソフトウェア開発のこれからを考えた場合、Dartの「方向性」はやっぱり正しいという結論になりました。

Googleは、もう少しちゃんとDartの意義を伝えた方がいいと思います。ほとんどの技術者に「同じような言語がまた一つ増えた」ぐらいにしか認知されていないのではないでしょうか。だから文法や機能不足など、表面的なところばかり批判されて、イマイチな印象になってしまっているように思えます。まだドラフトでバージョン0.04です。今の段階では機能不足や、さまつな仕様の欠点を論じるのではなく、言語のビジョンに注目するほうが正しく評価ができると思います。

なぜDartの方向性が正しいのか、まずその前提から書いていきます。

プログラミングの分野

プログラミング言語は、分野により向き不向きがあります。それをごちゃ混ぜにして議論しても仕方がありません。ここでは便宜上ソフトウェアを「基盤系・学術系」「組み込み系」「一般アプリケーション」と３つに分類します。あくまで説明を分かりやすくするための分類なので厳密ではありません。

基盤系・学術系など

• OS
• 言語処理系
• ファームウェア
• ミドルウェア
• 高度ライブラリ
• 科学技術計算
• 人工知能
• データマイニング
• 他、高度なアルゴリズムを必要とするソフトウェア

組み込み系

• 家電
• 医療用機器
• 産業用機器
• 専用ゲーム機
  など

一般アプリケーション

• 個人向けアプリケーション、ゲーム
• 法人向け、教育機関向け、官公庁向け、組織内アプリケーション
  など

多くの割合を占める「一般アプリケーション」

「基盤系・学術系」は重要ですが、ソフトウェア全体の開発ボリュームで考えると小さいですし、従事している団体や個人も限定的です。高度な知識を持った人にしか開発はむずかしい分野だと思います。
「組み込み系」はそれなりに従事しているプログラマの人口は多そうですが、ハードごとに事情が違い特殊なため、ここでは言及しません。
そしてソフトウェア開発で一番大きな割合を占めるのが「一般アプリケーション」です。多くの職業プログラマが従事することになる分野です。
そして当面はDartはこの分野をターゲットにすることになると思います。

オブジェクト指向ベースの言語が「一般アプリケーション」にはなじむ

基盤系・学術系などのソフトウェアには関数型言語が有効な場合が多いかもしれません。開発する人が優秀で数学的思考のスキルが高い場合はなおさらだと思います。

でも一般アプリケーションは、ヒト・モノ・コトをモデリングしシステム化する場合が多く、特にビジネスロジックの部分はオブジェクト指向ベースで考える方がしっくりくるのです。だって、実社会はオブジェクトとその連携で成り立っているんだもの。ビジネスロジックのソースコードは実社会の動きを表現したドキュメントですから、数学的な考えに置き換えて短く書くより、実社会をそのまま落としこむ方が自然で理解しやすくメリットが大きいのです。

もちろん関数型のアプローチが有効に使えるケースがあるでしょう。だからオブジェクト指向ベース言語で関数型も使えるハイブリッド言語が一般アプリケーション開発には現実的な解だと思います。
並列処理など複雑な処理の対処は基盤部分（フレームワーク）に集約し、ビジネスロジックは実社会をオブジェクトでシンプルに表現することが適切だと思います。フレームワークとビジネスロジックのプログラミングは頭の使い方が異なりレイヤーも違います。（この辺はまた後で整理しよう）

「文章」に例えてみます。どちらがよいというわけではなく、どちらが適切かは状況によりますね。

1. 短く簡潔だが、高度な学識がないと難しい文章
2. 多少冗長だが多くの人が読み書きしやすい素直な表現の文章

どちらが関数型言語で、どちらがオブジェクト指向言語・手続き型のメタファかは言うまでもありません。

私は関数型言語を深く理解しているわけではないので認識が間違っているかもしれません。でも概念では、大きく外してはいないと思います。

アプリケーション開発は覚えなきゃいけないことが多すぎ

現状はクライアントアプリはJavaScriptやObjective-C, Java, Flash(ActionScript)など、サーバ側はJava, Ruby, Python, Perl, PHPなどの組み合わせによる開発が一般的です。（Microsoft系は違うかもしれませんが全く書く気が・・・）。言語に加えHTMLやCSSなどもあります。それは多くの人にとって覚えなければならないことが多すぎて「アプリケーション開発は複雑で敷居が高い」と感じさせる原因になっています。いくつもの言語をマスターした人は「言語なんか覚えてしまえば簡単」と考えがちです。でも大半のプログラマにとって一つの言語を使いこなすようになることは大変なことなのです。ましてや、思想の違う言語ならなおさらです。
ソフトウェア開発をシンプルにするためには、クライアントとサーバの同一言語化はとても重要な要素なのです。

ソフトウェア開発のこれから

基盤系などは処理スピードが重要な場合も多いので、C,C++なども相変わらず使い続けられますし、Javaや関数型のプログラム言語や、もしかしたらGo言語なども使われるようになるかもしれません。

そしてあらゆるアプリケーション系は、これから「クラウド＋HTML5（もしくは、その後継）」に集約していくと思います。この大きな流れは着実に進んでいくでしょう。
クラウドに関しては自前サーバを捨ててクラウドへ向かえ！PaaSとSaaSでオールOKだよね？でも書きましたので、そちらも合わせて読んでください。
そう、これからはHTML5とクラウドに最適化した言語である必要があります。

スマートフォンアプリもHTML５へ

iOSやAndroidが全盛ですが、それすらもHTML5に置き換わっていく可能性が高いと思います。
Googleの最終目標はAndroidではなくChromeOSであることは有名な話ですが、AppleもHTML5のことは認めていたと思います。

カメラやGPSなどのデバイス制御の仕様もHTML5に追加されています。処理速度も向上していますし、オフライン用のクライアントアプリも作れます。ネイティブアプリでなくてもHTML5だけで実現できることは多いのです。

それにHTML5で作ればiOSであれ、AndroidであれWindows PhoneであれPCであれ、同じプログラムを利用でき、同じタイミングでリリースできます。工数が少くなれば安いコストで、早くサービスを作れます。そのエネルギーを付加価値や品質に注ぐことができれば、よりよいアプリにできるでしょう。開発者にとってもユーザにとってもメリットは大きいのです。

AmazonがKindleアプリをHTML5で作ったことも、その流れのさきがけです。もちろんAppleの制限から逃れるための苦肉の策ということはありますが、新たな道を開くきっかけになったことは確かです。

iCloud.comはWeb OSへ進化する。そしてアプリもHTML5へ

iOS5からiCloudが利用できるようになりました。そしてiCloudはWebでも管理できるようになっています。このiCloud.comはもう見た感じiOSそっくりではないですか？ これは将来"iCloudOS"などとよばれるものに発展していくように思えてなりません。そして未来のiPhoneやiPadのOSはiOSでなくChromeOSのようなWebOSになっていても何の不思議もありません。もしかしたらジョブスの残した置き土産の中に最終形としてあるんではないかと想像したりもしてみました。もしそうなればiCloudOSのアプリはHTML5で作れるようになっているでしょう。

Webアプリケーションのこれからの形

Webアプリケーションも、これからはサーバ側でHTMLを生成するタイプは減っていきます。もう既にクライアントアプリとサーバが連携する形式が普及しつつあります。コンテンツ(記事)を生成したり、検索エンジン向けのWebページを生成するアプリなどについての必要性は残ると思いますが、このへんは他にもいろいろあるので別エントリーで書くつもりです。

クラウド＋HTML5時代のWebプログラマは、クライアントアプリとサーバのバランスを考えながら実装できなければなりません。だからクライアントとサーバが同一言語の方が何かと効率的なのです。

「キー言語」としてのJavaScript

サーバ側はデファクトスタンダードな言語は存在せず、言語を選択しなければなりません。でもクライアントがHTML5になれば、クライアント側は必然的にJavaScriptになります。サーバ側の言語の置き換えは可能ですが、クライアントのJavaScriptを他の言語に置き換えることは難しいでしょう。アプリケーションを作るにはJavaScriptが必須となり、JavaScriptは鍵を握る「キー言語」と言うことができるかもしれません。そして代替の言語が主なプラットフォームに普及するまで、この時代は当分続くでしょう。

HTML5アプリをネイティブアプリに匹敵させるコンパイル型言語

速度向上中のJavaScriptですが、どうしてもネイティブアプリと比較すれば多少のモッサリ感は否めません。今後もどんどん改善されていくでしょうが、できればネイティブアプリと同じようにコンパイルして、速度的に全く劣らない仕組みがあれば完璧です。GoogleはまずChromeにDart専用ランタイムを乗せることによって、ネイティブアプリに全く遜色の無いアプリを先行して実現しようとしています。これは将来的に訪れる全WebOS化に向けての布石です。でもChrome以外のブラウザがDartを実装してくれるかはわかりません。だからJavaScriptにもコンパイルできる必要があるのです。

クライアントとサーバを同一言語にするメリットは想像以上に大きい

言語マニアでもない限り「サーバとクライアントが同じ言語だったらいいなぁー」と一度は考えたことがあるのではないでしょうか？その感覚は素直で正しいです。複数の言語だと、文法で混乱したり、しばらく使わないで忘れることも出てくるでしょう。学習コストや調査する時間もバカになりません。そういう思考中断の積み重ねが、プログラミングへの集中力を欠いて生産性にも大きく影響します。一つの言語に集中する方が生産性はあがりますし、ノウハウも蓄積しやすいのです。サーバとクライアントで同じクラスやチェックロジックを共有できれば、かなりDRYですっきりします。それにクライアントとサーバが同じ言語であることを利用した新しい効率的な開発手法が出てくる可能性も高いと思います。

これからプログラミングに入門する人にとっては、なおさらサーバとクライアントが同じ言語の方がとっつきやすいでしょう。できるだけ敷居は低くしたほうが、プログラミングの参入障壁が低くなり、アプリケーションのアイデアや付加価値を生み出すことへと比重が移ることになります。たくさん言語を覚えることがプログラマの目的ではないはずです。

サーバとクライアントで同じ言語を使うには

現状だとサーバとクライアントで同じ言語を利用するには以下のような方法があります。

1. GWTの利用
   サーバ側はJavaでGWTを使い、JavaからクライアントのJavaScriptを生成する
2. フルJavaScript
   サーバ側にもJavaScriptで実装されたnode.jsなどを使う
3. CoffeeScriptなど
   JavaScriptにコンパイルできるCoffeeScriptなどを利用する

個人的にはどれもすっきりする解決策でなく、中途半端に思えます。

1. GWTはサーバサイドJavaが前提でJavaアプリの複雑さが残る

GWTはサーバサイドJavaが前提条件で、クライアントサイドのみのアプリは想定していません。それにJavaアプリケーション独特の取っ付きづらさ、扱いづらさ、複雑さがあります。私はJavaの経歴が一番長いですが、Ruby(Rails)に触れてからは、そういう複雑さにとても違和感を覚えるようになってしまいました。

2. JavaScriptは自由すぎ、エンタープライズでの利用は難しい

サーバもクライアントもJavaScriptを使うことは現時点では現実的な選択肢だと思います。しかしJavaScriptは書き方が自由すぎてトリッキーなことがやりやすく、複数人での開発にはあまり向いていません。コールバックの多用でソースが追いづらくなったり。それにJavaScriptはクラスがなく実装者任せの擬似クラスになってしまいます。

これらのJavaScriptの欠点は少なくともエンタープライズといわれる領域で使うためには、かなりのマイナス要素に思えます。

3. CoffeeScriptはいい線いってるが

Node.js＋CoffeeScriptを使えば、クライアントでもサーバでもCoffeeScriptでプログラムすることができます。JavaScriptに比べ、シンプルでclassも利用できるのでいいと思います。でも出力されるJavaScriptを意識しながらつくらなければならず、実行時にはやはりJavaScriptの知識が必要になります。jQueryなどが利用できることも、場合によってはデメリットにもなると思います。知らない人は結局jQueryも覚えなければならなくなるからです。jQueryなどのライブラリはjavascriptとはいえ、ほとんど別文法の「お作法」を覚えなければなりません。また別のJavaScriptライブラリを利用すれば、それも覚える必要が出てきます。結局JavaScriptの技術を取り入れやすい柔軟性が逆に敷居を高くする原因になってしまいます。その点がシンプルではありません。

文法は好みの問題。それなら人口の多いプログラミング言語ライクに

文法は見慣れてくるとなじむので、致命的な欠陥がなければなければ、書き方はあまり大きな問題ではありません。もちろんシンプルでないものは大きなマイナスポイントです。私はRubyのend構文を最初見た時は「なんだこれ」と思いましたが、慣れてくると良く思えてきました。文法は個人の好みなので、細かいところにこだわってもしょうがないと思います。

ちなみに私はC,C++を経てずっとJavaがメインでしたが、その後Rubyをしばらくやってました。今はサーバ側はJavaやRuby, Google App EngineではPythonを必要に応じて使い分けています。クライアント(ブラウザ)側はFlash(ActionScript)を経て今はJavaScript一択です。ちなみに言語的にはやっぱりRubyが一番好きですね。

TIOBE人気プログラミング言語ランキングを見ると、Dartに文法的に近いJavaやC系, Javascriptが大きな割合を占めていることが分かります。それはDartが多くの人にとってなじみのある書き方ということになります。言語の学びやすさという点では、全く新しい記法やマイナーな記法よりは、大きなアドバンテージになります。 多くのプログラマは積極的に新しい書き方を覚えたいわけではありません。その言語が感覚的にわかりやすいかどうか、とっつきやすいかどうかがアーリーマジョリティに受け入れられるためにはとても重要な要素なのです。そして頭のよい人達に絶賛されたとしても、アーリーマジョリティに受け入れられなければ普及することはありません。

TIOBE Programming Community Index

エンタープライズの領域を狙うGoogle

Googleはコンシューマだけでなくビジネス（エンタープライズ）の領域を狙っています。今はSIerが担っている部分です。IT業界ではエンドユーザ向けのサービスを提供している会社が花形で目立っていますが、実際はビジネス取引の大半は地味なBtoB(会社と会社の取引）で成り立っています。そのパイを狙うのは当然のことです。大人数での開発は、自分が作るだけでなく、プログラムを他人に引き継いだときにメンテナンスしやすいかどうかも大切です。平均的な人にとっても敷居が高すぎず理解しやすいことが重要になってきます。

Web系やエンタープライズ系の両方で利用できる言語

Web・スマートフォン系アプリとビジネス（エンタープライズ）系のアプリの両方で使いやすい言語であれば、普及しやすくなります。人材のスキルも有効活用できます。そのためには小規模でも大規模でも対応できる言語仕様でなければなりません。大規模開発では型指定など、ある程度の「硬さ」が有効に働きます。型指定があれば、仕様も明確に伝えることができますし、コード補完も正確にできるのです。型の概念があればScalaのような「型推論」もできると思います。まだDartに「型推論」はないようですが、いずれ出来るのではないでしょうか？ 逆に小規模開発では型指定よりLLライクに柔軟に書きたい場合が多いかもしれません。ようするに全部のアプリケーションに対応するには、ある程度の硬さと柔軟さを併せ持っていなければならないのです。

いろいろ考えると新しい言語を作った方が手っ取り早い

それでは、何でわざわざ新しい言語にしなければならなかったのでしょうか？
今まで書いたことを元に条件を書き出してみます。

1. エンタープライズ分野のアーリーマジョリティにも受け入れられやすい文法
2. オブジェクト指向ベースで、関数型とのハイブリッド型
3. 大規模でも小規模でも使えるように静的型付けなどの適度な固さ、柔軟さを合わせ持つ
4. “キー言語”JavaScriptの機能を包括していて、JavaScriptに効率よくコンパイルできる
5. 専用ランタイム用にもコンパイルでき動作速度をネイティブと同等にできる
6. そして必須条件「シンプルで簡単である」

これらの条件を満たす言語は何かと考えたときにジャストフィットする言語がなく、新しい言語を作る方が早いと考えたのでしょう。現状を考えた場合、ゼロから作り直すというアプローチは正解に思えます。

そして他にも２つの大きな目的があると思います。

真の目的はGoogleのプラットフォームへの誘導と、開発者を思う気持ち

大きな目的の１つは、やはりGoogleのプラットフォーム(Chrome, ChromeOSやApp Engine)にDartをネイティブ実装し、「他の環境でJavaScriptとして動かすより、こっちが早いよー」と言って誘導することです。もちろんDartはオープンソースで他のプラットフォームでも取り入れれてかまわないというスタンスでしょう。ほとんどのプラットフォームに組込んでもらえれば、JavaScriptの完全置き換えも夢ではありません。どっちにしてもGoogleには有利に働くでしょうから。

でもそんな野望だけでなく、「Dartはアプリケーション開発を効率化し、開発者を楽にするポテンシャルがある」というGoogle技術者達の熱い想いがあってリリースされたのだと信じています。

総合力で新しい言語を普及させる可能性が一番高いのはGoogle

影響力の強いクラウド(PaaS)とブラウザの両方のプラットフォームを持っている組織は、やはりGoogleです。ChromeとAppEngineのコラボは強力です。App EngineでもDartはいずれネイティブにサポートされると思います。新しい言語を普及させる力があるのは、強力なプラットフォームを握っているGoogleがやはり本命です。

Dartが普及するかどうかはGoogleのマーケティング次第

もちろん方向性が正しいからって普及するかどうかはわかりません。Googleのマーケティング次第だと思います。Googleの数々のプロジェクト失敗は一般人の気持ちが分からないことが大きいと思います。高尚な思想はうまく伝えないと一般人は理解できません。もっと噛み砕いてキャッチーにシンプルに伝えないとまた失敗するかもしれません。

私はセンスがありませんが、思いつくコピーをあげてみます。センスのある人いいのを考えてください。

クライアントとサーバのプログラミング公用語 “Dart”
エンタープライズもウェブ開発も、もっと手軽にシンプルに。

コピーではありませんが、Railsが「15分で作るブログシステム」とか「１０分で作るRailsアプリ」などが普及のきっかけになったようにアーリーマジョリティに普及させるためには、そういうシンプルなメッセージがないと難しいと思います。

Dartはまだまだこれから

他の言語と比べるとまだ機能不足な点はまだあると思います。でもまだドラフトでバージョン0.04ですよ。「型推論」などの有用な機能はこれから徐々に実装されていくでしょう。

良いものでも、みんなが「様子見」を続けたら普及しません。良いものは少しでも普及するようにブログを書いてみました。非力でもやらないよりはマシです。Dartがいいと思った人は今後注目して、少しでも広まるアクションをしていきましょう。

三鷹の会社（兼自宅）から六本木“バーチャルオフィス”に引っ越した

今月引越ししました。会社＆ファミリーのはじめての引越しだったのでドタバタでした。まだ法人の移転は途中で、たくさん手続きが残ってます。。。('A`)ﾏﾝﾄﾞｸｾ
行政書士に頼んだほうが楽だったと思うのですが、ケチって自分でやったから自業自得か。

ガラパゴス受託開発から脱出したい

私の今の仕事は客先常駐の開発業務支援です。ほとんどフリーランスみたいなもんですが、法人でやってます。 法人はまだ景気が今ほど悪くなかったころ勢いで作りました。
以前は特別な実力がない人でも仕事があり、そんなやり方でそれなりの収入を得ることができたものです。 フリーランスでもよかったのですが、法人の方がユーザ企業や大きいSIerと直接契約できたり、社会的信用がフリーランスより高いというメリットがありました。
でもこれからは、そういう形式的な信用より、ネットで実質的な信用を築くやり方が一般化しないものかと、いろいろ考えています。
私の場合は特定のお客さんにひいきにしてもらっていますが、このままのやり方では日本のSIerとともに沈んでいくのが目に見えているので他の方法を模索しています。それについてはこれから書いていくつもりです。
早くガラパゴス受託開発でない方法で生計を立てれるようになりたいです。

私と同じような状況の方、もしいらしたら是非連絡ください！

バーチャルオフィスを使うことにした

引越し先は賃貸で住居専用のため法人登記ができませんでした。今まで自宅兼会社でやっていたので、このままでは会社の行き場がありません。ほとんど形だけの法人なので、わざわざ事務所を借りるのはもったいなくてできません。そこでできるだけ安く抑えるため、バーチャルオフィスを利用することにしました。
バーチャルオフィスは登記可能な住所を借り、郵便物は転送してもらうことができます。会議室を借りたりや電話秘書などのオプションもあります。
名刺に一等地の住所を書きたかったり、個人事業主でも名刺などで住所を公開したくない目的で利用する人もいるようです。

月1000円程度のバーチャルオフィスはダメだった

月1000円程度のバーチャルオフィスを２つほど見つけました。
一つは銀座で1050円プランがありましたが、「客寄せプラン」みたいで、できるだけ契約させたくないようでした。3ヶ月ごとに契約更新で、契約解除の条件が厳しいようでした。１度申込をキャンセルして、後でもう一度申し込んだら「同じ客からの２回の申し込み受付できない規則だ」と断られました。

もう一つは女性企業家専用でした。バーチャルオフィス経営者は男性だったのに何で？？？

要するに月1000円だと、たいした利益も得られないから、何か別の目的か下心でもないとやってられないってことでしょうねｗ

月2000円のバーチャルオフィスは犯罪に使われていた

次は2000円のバーチャルオフィスに申し込みました。
やたら簡単に審査がとおり、味気ないメールがさらっと送られてくるだけなので不審に思い、送られてきた貸し住所をネットで検索したら、振り込め詐欺やらパチンコ攻略法詐欺などの被害届で出るわ出るわで、こりゃダメだと思いキャンセルしました。
こういうのがあるからバーチャルオフィスは犯罪のイメージがついちゃうんですよね。

結局安さと信用のバランスで六本木のバーチャルオフィスMEWにした

MEWは月3480円から六本木の住所が借りれます。会議室も安く借りれるみたいです。
割引があったので一年分まとめて払いました。

バーチャルオフィスMEW

プログラマから見ると公的機関は非効率すぎる

公的機関で諸手続きをやっていると、あまりの非効率さに泣けてくることがしばしばあります。
本当に優秀なアーキテクトが集まって、国や地方の機関や制度をシガラミなしで（既得権者や衆愚は無視で）ゼロからモデリングし最適化＆システム化したら、どれほど日本が良くなるだろうって思います。
夢物語だけど、最高に面白いアーキテクチャの設計になるでしょうね。

今回の会社移転とは関係ありませんが、公的機関が作ったシステムは使いにくいです。
税務署が作ったe-taxの使いにくさに怒っている人も多いようです。個人事業主向けは少しはましなようですが、法人向けはダメです。地方版のeltaxは輪をかけて酷い出来で、ユーザビリティやユーザエクスペリエンスなどとは全く縁のない世界のシステムでした。

公的機関のインターフェースが悪いお陰で、公務員や行政書士などの仕事が成り立っているので、まあ全体効率化の方向には向かうのは抵抗にあって難しいんでしょう。公的機関は最も変化を嫌う世界ですから、きっとアジャイル開発などとは縁のない世界なんでしょうね。

法人移転の手続きメモ

まだいろいろあるなーorz

法務局（転出側）

必要書類は転出側に提出し、転入側に転送してもらいます。
新しい住所にはバーチャルオフィスでもらった住所を書きます。
今週中には手続き完了するって言われてたのに、今日電話したら来週水曜日って言わました。遅いなー。

• 本店移転登記申請書（管轄登記所外移転）の提出
  ※ 代表取締役の住所移転も同じ申請書に追加記入すればOKでした
  ※ 転出側と転入側の申請書が含まれています
• 転入側法務局への印鑑届書

【添付書類】

• 株主総会議事録（一人なのに）
• 取締役決定書
• 転入側法務局へ送る登記電子データをOCR用紙に手書きｗしたもの

【手数料】70,000円

• 転出側の本店移転手数料：30000円
• 転出側取締役の住所変更手数料:10000円
• 転入側の本店移転手数料:30000円

↑↑↑↑ 今ここまで完了 ↑↑↑↑

法務局（転入側）

• 登記簿謄本などの取得

税務署（転出側と転入側の両方）

• 異動届出書の提出

都税事務所（転出側か転入側のどちらか一方）

• 異動届出書の提出

市役所（転出側）

• 特別徴収義務者の所在地・名称等変更届出書の提出

社会保険事務所（転出側）

• 適用事業所所在地・名称変更届の提出
• 厚生年金保険被保険者 住所変更届／国民年金 第３号被保険者住所 変更届（家族全員の古い保険証の切替の手続き）

プログラマ70歳定年説

最近またプログラマ35歳定年説をよく目にするようになりました。
「日本の典型的なSIerの世界では」という前提であれば、35歳定年説はあながち間違ってないのかもしれません。でもその前提となっているSIerの体制自体には大きな疑問を感じます。いったい何が問題で、どうすれば生涯プログラマとして生きていけるのでしょう？

日本のSIerの不自然なカースト制度

プログラマ35歳定年説はPM・SE・PGといった日本のSIerの不自然な職種分離が最大の原因です。

PM/SE/PGは別のスキルが必要なのに、年齢とともにジョブチェンジしていかなくてはならないプレッシャーがあります。大手SIerではろくにプログラマを経ることなくいきなりSEとしてデビューしたりもします。

こんな変な仕組みが出来た原因はソフトウェア開発の本質があまりわかってないときに製造業モデルを無理やり当てはめたからではないでしょうか。

このモデルではPGは部品組立の「ルーチンワーカー」みたいなものです。プログラムのわからないSEの設計を元にプログラミングしなければならず、フラストレーションがたまります。

SEになれば、プログラムも組ませてもらえず、顧客の御用聞きのような要件定義もどきや、テンプレート通りの設計、プログラマの管理や指示が仕事になります。そして技術にも疎くなっていきます。

PMになれば、もう完全に技術者とは別スキルが必要になって、技術分野だけで活躍してきた人には、うまく実力が発揮できなかったりします。

終身雇用では、昇給もするので、いつまでも下っ端の仕事をやってないで、管理をやれという話になります。そして優秀なゼネラリストタイプの人間以外は、出世の過程でピーターの法則によって無能力化されていきます。それと似たようなことがこのPM/SE/PG階層でも起きてしまいます。

35歳定年説の大きな要因ー自分より年齢が上の人を使いたくない

PMやSEのサブリーダーなどは自分より年齢が上の人を使いたくないですから、採用しなくなります。PMやリーダーSEにならない限り、必然的にリーダーでないSEやPGは年齢が高くなると採用されないという結果になり仕事がなくなります。

社内で「できる人」だと、なんとかなる？

社内で結構「できる人」扱いになっていても、果たして会社の外に出たときにすんなり受け入れられると思いますか？
よほど貴重な専門スキルを持っていない限り、社外に放り出されたら「その他大勢」として見られます。会社に所属していると安心してしまい、年齢が高くなれば雇ってさえもらえないということに自覚がない人も多いのではないでしょうか。実力を見せる機会もなく、門前払いになってしまうことも覚悟しておくべきでしょう。
いっくら技術があると自負していても、一緒に仕事でもしなければ、なかなか伝わりませんから。
それにグローバル化でこれからの日本の状況は厳しくなることは避けれません。所属する会社だっていつまで存続するかわかりません。

要件のヒアリングから開発・テストまで行う「プログラマ」

もうずっと言われていることですが、SEとPGの区分けではなくて、要件からアプリケーションの開発・テストまでを一つの職種にすることは必須ですね。新しい考え方の会社だとあたりまえなのかな。そういう人は「本当の」という意味を含めて「プログラマ」と呼ばれることが多いですね。

PMにしろプログラマにしろ、ジョブチェンジせずに、それぞれの専門性を磨いて職種の中でランクアップしていくという形が好ましいでしょう。実際にアメリカなどではそうだと聞きます。

生き残る可能性のあるプログラマ

プログラマには「サラリーマン志向タイプ」と「プロフェッショナル志向タイプ」に大きく分けれます。イメージとしてはざっとこんな感じです。

サラリーマン志向タイプ	プロフェッショナル志向タイプ
ノルマをこなせばそれでいい 言われなかったらやらない ルールのおかしい点に気づかない コピペでも早く終わらせりゃいい プログラムのネーミングはどうでもいい コードが汚くても気にならない 給料がもらえればそれでいい ・・・	アンテナをはって新しい技術を取り入れる 自分から提案する ルールのおかしい点の改善を試みる 将来のメンテナンス性も考慮する プログラムのネーミングを重視する 美しいコードに感動する いいものを提供したい ・・・

「プロフェッショナル志向タイプ」だったら社外に放り出されても、生き残れる可能性はありますが、「サラリーマン志向タイプ」のままでは生き残りは難しいでしょう。人月計算の世界では理解されづらいことですが、これらの２つのタイプは決定的な差があることは分かる人には分かると思います。

プログラマの生き残り問題を考えると、どうしてもこれから確実に訪れる格差社会と切り離して考えるわけにはいきません。グローバル化でルーチンワーカーは間違いなく仕事がなくなり厳しい状況になります。プログラマにも確実にその波は訪れるでしょう。実現が難しいとはいえ、「ベーシックインカム」みたいな仕組みが、これからの日本には必要なのかもしれません。この問題は話がそれすぎるので、またいつか。

ベテランのメリット

ベテランは若くて使いやすいというメリットを上回る価値が提供できればなりません。プロフェッショナル志向のベテランの技術者のメリットはどういうものがあるでしょうか。個人差があると思いますが下記の点が経験の長さで得られる傾向があるかと思います。

• 豊富な知識／ノウハウ
• マクロの視点／ビジネスの視点
• チーム全体のことを考える（「俺が俺が」でなく）

プログラマはルーチンワーカーではなく知識労働者です。やり方次第であり、生産性や品質に１０倍以上の個人差が出てくるということは、プログラマなら感覚的に分かると思います。
そのような生産性のあるベテランの労働力を生かさない手はありません。

プログラミング能力的には70歳でも現役可能

常に変化を受け入れ、向上を続けていけば、能力的な面だけでは70歳までプログラマを続けることも全然可能だと思います。記憶力が低下しても、コンピュータが補完してくれます。タイピングのスピードが落ちても補完機能が進化しているので大した問題ではありません。
蓄積された経験とカンでカバーできる部分も多いでしょう。
現状に満足して新しいものを取り入れることをやめ、既得権を守ることだけに力を注ぐようになったときに、定年へのカウントダウンが始まるのだと思います。

今のままの日本のやり方ではプログラマの寿命は短い

これからは終身雇用がなくなり、経済の厳しさから同じ会社に居続けるという可能性は低いと考えていた方がよいでしょう。
所属する会社から出た場合仕事先を探さなければなりませんが、雇用者側は高い年齢のプログラマを正社員として同じ職場で雇用することは抵抗がある場合が多いと思います。アメリカのように年齢で採用を決めることがない文化になればいいですが、そう簡単に人々の意識は変わりません。
ですから今のままでは、若いうちしかプログラマとして生きていくのは難しいでしょう。

そうだ「プログラマ70歳定年」の実現を、これからのテーマの一つにしよう！

残念ながら今のままの業界では一生プログラマでいれるのは、特別な能力のあるほんの一握りの人しかいないと思います。

考えなければならないことは、雇用側の心理的な抵抗をなくす新しい雇用形態とネットを使った新しい仕事のスタイルです。雇用側にもプログラマにもどちらにもメリットがなきゃいけません。ちょっと考えがありますが、長くなるので、また次回にしたいと思います。

http://d.hatena.ne.jp/gothedistance/20110927/1317112120
http://blog.livedoor.jp/lalha/archives/50067277.html

自前サーバを捨ててクラウドへ向かえ！PaaSとSaaSでオールOKだよね？

ほとんどの企業のシステムは自前サーバで、クラウドは様子見のところがまだ多いようです。企業のシステムを提案するSIerはハードウェアごと売れないと死活問題になります。だから広めようとしないこともクラウドが普及しない大きな理由でしょう。でも自前サーバは構築や運用に莫大な時間と労力と費用がかかりますし、クラウドにないリスクもあります。本当はほとんどのシステムはクラウド化した方が圧倒的にメリットがあるのです。クラウド化のメリットとリスクの正しい認識が早く浸透して欲しいと願ってます。

Google先生！Google+実名問題の解決策はこれでどうでしょう?

Google+はすばらしいサービスです。それだけに実名ルールの強行が残念でなりません。本当に強制実名公開はベストな方法でしょうか？ Google先生にとっても、実名非公開派にとってもWin-Winな解決策は普通にあります。どうかもう一度、たくさんの人にとってのベストの策を考えなおしてください。