Knowledge base func

日本の大手SIerが建てた砂上の楼閣が崩れたというニュースが入ってきた。調査報告書がUPされたので読んだ。
そこには”設計要員”が450人動員されたと書かれいた。
あぁ、なんだファンタジー小説じゃないか！

費やした５５億円、水の泡に　特許庁がシステム開発中断

www.asahi.com/business/update/0124/TKY201201240616.html

特許庁は２４日、２００６年から始めた新たな情報システムの開発を中断することを決めた。これまでに５５億円の予算を投じたが、別のシステムを考える。
　新システムの開発期間は０６年１２月から１４年１月。設計を東芝ソリューションと、開発管理をアクセンチュアと契約した。
開発の遅れは、主に設計の不備が原因。特許庁は検証委員会を設け対応を考えてきたが、委員会は２３日、中断を求める報告書をまとめた。業者が今までに作ってきた設計情報は、特許庁の別のシステム開発に生かしていくという。

せっかくなので、Getting RealとFantasy SIerを題材に学んでみようと思う。
Getting Realは長すぎる。意訳をつくってみたけど長すぎるんだよね。
超訳だよ。

**日本のファントム vs Gettign Real
まるで大きな政府か小さな政府かの争いのようだ。
Gettign Realと特許庁の今回頓挫したシステムとの大きな違いの部分に注目して、書きだしてみようと思う。

１．機能はとことんまで削れ
他方、特許庁のシステムは「何でもかんでも」にしたようだ。当初６０Mステップの開発規模を予定していたそうだ。Gettign Realは７行のコードより４行のコードを美徳とする。７行を４行にするためには才能と努力が必要だ。三流プログラマが書いた１万行のコードは練度の高いプログラマの２００行に性能でも敵わないことがある。当然２００行のほうが保守性も拡張性も高い。
ステップ数でプログラムを評価すると、性能も低く拡張性も保守性もないプログラムを評価してしまうことになる。

２．チームは３人いれば十分
他方、特許庁のシステムは上流工程を重視し設計要員を450人体制とした。上流工程って（笑）
37signalが提案する３人のチームの中には当然設計だけしかできない要員は含まれない。そもそも設計だけの要員を想定していないのだろう。日本の現場をおもいうかべると、そもそも論理的に実装ができない設計がなされている様が目に浮かぶ。こんなの作れないだろと。実装もできない要員が設計をするケースがあるからだ。これは問題外だ。まず形にしないといけないのに形にできないひとがイニシアチブをもってはいけない。そのひと一人に任せて仕事がすすまないひとに仕事をまかせてはいけない。
仕事がメモとミーティングに埋まってしまぬよう独立して動ける規模までチームを小さくすることが必要だったのではないか。責任を分散するためだけに実質責任をとらない増員はじつに日本的。

３．皆を喜ばせようとすると、誰も喜ばない
誰のためのシステムだったのか調査報告書にない。事務費用が下がるというお題目での導入だが、利用者が不在なのではないか。何をつくろうとしているのか一言で言いあらわせたのだろうか？そのストーリーは１枚の紙に収めることができるほど洗練されていたのだろうか？
ビジョンはレガシーシステムからの次世代システムへの以降です！キリッ
じゃあその次世代システムをストーリで説明してごらんなさい？

４．ミーティングをしない
はっきりとした話の内容が決まっていないミーティングは絶対しないというルールがあったのなら、何年もやって何も決まらないということはなかったことだろう。大幹を定めることなく枝葉末節から積み重ねたのだろう。だがそんな木はたちあがらない。

５．仕様書などの書類はつくらない
Gettign Realでは仕様書は合意をしたという幻想にすぎないと切り捨てている。同じ文面のものを読んでいても、そこから考えることは人それぞれだからだ。仕様書に機能を書き加えればうるさい奴を静まらせることができる。だから機能が増え過ぎる。基本設計書は、サインされ同意されるもの。開発中アイディアが誤っていたと気付いても、そのまま進むしかない。結果、すすむことができなくなった。
彼らは書類しかつくらなかった。なんたることだ。

６．アイディアは実行しないと意味がない。
アイディアは形にしないと思いつかなかったのと同じ。形にしても公開しなかったら作らなかったのと同じ。
だがしかし、彼らはそもそもアイディアをまとめることすらできなかった。
設計すら終わらなかったものに１３３億投入した。これ以上残念なことはないと思う。

７．時間の細分化
Gettign Realでは何ヶ月も何年も先の見積もりはもはや空想だという。より現実的な6-10時間の単位で細かく考えるべきだ。一方、特許庁のシステムでは完成を６年先とした。
作らなければ利用者の評価は得られない。決断する時は必要な情報が手に入った時のはずである。優先順位をつけ、ものを作り、それがとりあえず形になってから次に何をしようかというまえに、まだ出来上がってもいないものの上に次を重ねた。やはり、もはや空想でしかない。

８．才能をさがす
遅延したプロジェクトに人を加えると、ますます遅くなる。（ブルックスの掟）
絵に描いたように２００人から一気に４５０人まで増やし、１０００人を超えたという。コミュニケーションコストはいかほどであっただろうか。文章がかけるからといって１０００人集めたところでシェイクスピアのハムレットが出来上がることはない。一騎当千の才能が混じればそれもあるかもしれないが、それはただの確率でしかない。

９．情熱
たとえ奇跡がおきて確率的にそのような才能家が混じっても、集中出来る環境と情熱がなければ事はなしえない。炎上しっぱなしの環境下でコミュニケーションチャンネルがやたら多ければ集中できる環境には程遠い。しかも作成には掛かられず、ミーティングや進捗の報告、基本設計書や詳細仕様書の雑務に追われる。現場に幸せを感じ新鮮な情熱を保つ道理はない。

**感想
とほほの一言だ。
日本の官公庁をはじめ大企業は間違いがあってはいけないと完璧なものを目指す。そのため、事態が硬直化し、間違っているとわかっても修正が効かない。それで何とか動いても、制度疲労をおこし、全体として機能しなくなる。震災後の一連の対応をみてもわかるだろう。餅は餅屋と専門家を待ち続けたが、どこからも事態を解決してくれる餅屋はでてこなかった。
何のために古いシステムがあるのか、なんのために職員がいるのか、なんのために責任を取るべき立場の人間がいるのか、なんのために新しいシステムをつくろうとしているのかを忘れて、（Getting Real）実現するわけがない。そしてそれを阻害しない環境づくりが必要だ。
だが、環境づくりも仕組み構築か。

This is Japanese Real but not getting real.

参照：：

特許庁情報システムの技術検証結果について www.meti.go.jp/press/2011/01/20120124001/20120124001.html

[続報］特許庁の基幹系刷新「中断が妥当」、外部委員会が報告書 itpro.nikkeibp.co.jp/article/NEWS/20120124/379194/

特許事務システムの刷新可能性調査結果 www.jpo.go.jp/cgi/link.cgi?url=/torikumi/hiroba/sisutem_kousin.htm

2010 年（平成 22 年）度 特許庁業務・システム最適化実施評価報告 www.kantei.go.jp/jp/singi/it2/cio/dai43/siryou2/55.pdf

「特許庁情報システムに関する調査委員会」からの調査報告書の提出について www.meti.go.jp/press/20100820003/20100820003.html

調査報告書(PDF形式：1,180KB) www.meti.go.jp/press/20100820003/20100820003-2.pdf

2011年1月のプログラミング言語ランキングが投票された。
このランキング順にプログラマーズカフェにくるような人たちや、他のICT企業を経営されている方々などからきく2011年現在の状況を書いてみようかとおもう。自分は現在はディベロッパーからもソフトハウスからも外れているので観測範囲も偏りがありあまり実態にそぐわないかもしれないが、他山の石にでもしていただければこれ幸い。

Java

ここ数ヶ月急速に単価があがり需要が高まっているらしい。原因はAndroid。
数十人から数百人の人数をつっこんでのSIer的な大規模開発に向く一方末端技術者だと自分が何をつくっているのかわからないままになってしまう可能性も高い。若い技術者がここしか知らずに進んでしまうと、10年後にCOBOL技術者のようなことになるのではないかと心配だ。実際同じJavaでも金融系などは大手が人員を数千人単位で大量放出するたびに単価変動の影響を受ける。大手SIerの仕事をするなら今はJavaだろう。Javaと一口にいっても大きいが故、系統がかなり別れる。はずれの行き止まり系統も多いので今から参戦するなら注意が必要。

C

組み込みなどハードよりの仕事をする人があつかっている印象がある。一昔まえはそれこそベタベタで開発効率が悪そうだったが今はだいぶ改善されたらしい。すべての基本にあるといっても過言でないカバー範囲の広さからどこにでも存在する。Cをやっている人ははずれ技術者は少ない印象。

C++

文字どおりCの開発効率をあげるために様々な工夫がなされているのがC++
ダイナミックリンクライブラリみたいな拡張としてつくったり、普通のおもて側にもつかえたり、用途は豊富。ゲーム系の業界などでもつかわれているし、Microsoftがつくった、MSのための言語といっても過言でない。DirectXやWindowsAPIなどを蹴ったりするのにとても使いやすい。いまだに根強い。MSDNのなかでは開発効率よりも確実性を要求されるアプリケーションにむくのではないか。

PHP

いまやXMLやHTMLと同じぐらいの扱いの言語になってしまっているような気がする。知識がいらず組み合わせだけでも動かせるので便利な一方、凶器にもなる。つかっている人が多いのがなによりの特徴。Javaが比較的業務向きのメジャーだとするとサービス向きのメジャーはこちらになると思う。バカにされることが多いのは致し方ないことだ。
だが、CMSのようなものの充実でいずれプログミラミングを理解しなくても同等のことができてしまう言語になりうる可能性はある。

Python

現在までのところ自分で仕様を策定＋開発できるエンジニアしかいない印象がある。一昔まえのRubyOnRailsと同じような印象。GAEで使えるのがなにより。2011自分のなかでいちばんやりたい言語。
でもまだ仕事でうけた案件をPythonでは納品したくない。インシデント時につぶしが利かなすぎる。

C#

6～7年前にC#にさわったきりMSDNから離れてしまっていたので、正直わからない。無料コンパイラがでてるの？
VisualStudio系はコンパイラの問題ではないと思うので選択の余地はないのだが、まだC++にとってかわれてないところをみるとC++をWindowsXPにするとC#はVistaみたいなものなのだろうか。7にアップグレードされる日はくるのだろうか？

(Visual)Basic

これは.netのだろうか？VB6はとても開発効率がよかった。またメインスキームさえ押さえてしまえばロースキルの人でも突っ込みやすかったので功罪はあったものの、一世風靡した。いまはまったく聞かないがどうなったのだろうか？あ、ExcelのVBAは何か恐ろしい独自進化を遂げつつあるように感じる。生半可なプログラマーよりも業務を理解したOLがつくったVBAのほうがよかったりする。決して侮れない。

Objective-C

ソースを眺めてFlashLiteぐらいやりたくないなとおもった。でもiPhone開発には現在これ一択。生殺与奪をAppleさんに預けられるひとのみが救われる。

Perl

1998年ごろcgiといえばPerlしかなかった関係から、もともとがWEB系なりたちでネット上のコミュニティがしっかり存在しているのが特徴のひとつ。Perlがレガシー化するのはいつだろうか。退出率と新規参入率の推移が気になるところ。もしかしたら2009年ごろが境いだったかもしれない。

Ruby(Ruby on Rails)

案件として出始めてきているような気がする。三鷹ではすくなくともちらほら話しをきくようになっている。
ただ、既存業務のリプレイスや大規模には超無理だなと思っている。DB設計から入れるのであればアリかな。
４～５年前は環境面でかなり不安があったけど、最近はずいぶん改善した印象。１年ぐらいまえにIDEをひさしぶりにいれたら感動した。Herokuなどもすばらしい。なにより夢がある。ただ社内に体系的な資産があるなら別だがエントリーレベルの技術者にはおすすめできない。理由はPythonと一緒。
唐突に宣伝だけどJoruriのセミナーが2/8と2/22に三鷹であるよ。細かいことは問い合わせしてください。

JavaScript

JavaScriptがちょっと面白い進化をしつつある。Prototype.jsからjQueryでクロスプラットフォームの吸収をおまかせできるようになったのと、それを利用した拡張ライブラリの充実により、コーディングよりも組み合わせの妙が重要になりつつある。また他方でJavaServletではなく、サーバーサイドJavaScriptみたいな進化の気配もあり、ちょっとよくわからない。多分そのうちFlexみたいにJavaScriptでコンパイルできて、Airみたいなアプリケーションを吐き出せる何かがでてくるのではないかとも思う。もちろんJavaとは別で。

あとはまとめてその他の言語

Delphi、Lisp、Pascal、Assembly、SAS、Transact-SQL、RPG(OS/400)、MATLAB、Ada
聞いたこともないような言語もちらほら。
Lispは日本だとScala、Ocaml、Haskellあたりなきがする。ただ、ここらへんはどのように進化するかまったくよめない。Fortran路線なんじゃないかな。
Transact-SQLか。SQL-serverさんは……。
2005年ぐらいまでだと、クライアントマシンにインストールできるDBサーバがコスト的にSQL-serverしか選択の余地がなかったので、例えば店舗サーバーに無料配布できるほうのSQL-serverをつっこんで、夜間バッチでセンターに集計でとかというパターンをするのが有効だったころあったよね。現代は通信環境向上したし、デッドロックとかで死ななくてよくなったから、中央だけですむようになったけど、いまも大規模系だと拠点ごとの構成になっているのかもね。
Transact-SQLまわりで、なにかGUIでうりうりするER図の化物にprocedureをつっこんでいくような機能あったよね。名前わすれちゃった。ストアド系は難しいですね。Pl-SQLとかはまだあるのかな？
mysqlでもストアドを書けたのでかれこれ5年ぐらい前に試したかぎりではカーソルもおかしくてfunction程度しか使い物にならなかったことしか覚えていないです。

あとここに出てこなかった言語だとActionScript（Flex）とか。まあ、みんながいくような言語ではないか…。

参考
 

2011年	2010年	プログラミング言語	レイティング	前年度比
1	1	Java	17.77%	0.29%
2	2	C	15.82%	-0.39%
3	4	C++	8.78%	-0.93%
4	3	PHP	7.84%	-2.24%
5	7	Python	6.27%	1.81%
6	6	C#	6.23%	0.46%
7	5	(Visual)Basic	5.87%	-1.49%
8	12	Objective-C	3.01%	1.63%
9	8	Perl	2.86%	-0.71%
10	10	Ruby	1.78%	-0.69%
11	9	JavaScript	1.59%	-1.12%
12	11	Delphi	1.29%	-1.10%
13	18	Lisp	1.11%	0.53%
14	17	Pascal	0.92%	0.29%
15	-	Assembly	0.86%	0.86%
16	14	SAS	0.77%	-0.04%
17	30	Transact-SQL	0.76%	0.38%
18	33	RPG(OS/400)	0.72%	0.40%
19	20	MATLAB	0.71%	0.17%
20	28	Ada	0.68%	0.29%

プログラミング言語人気TOP10の簡易解説
www.mwsoft.jp/column/program_top10.html

どのプログラミング言語が将来的に有望か　2009
www.oiax.jp/rails/zakkan/promising_programming_languages.html

Job Trends
www.indeed.com/jobtrends

GoogleトレンドでPHP,JavaScript,Java,C#,Pythonを並べてみた
www.google.com/trends?q=PHP%2CJavaScript%2CJava%2CC%23%2CPython&ctab=0&geo=jp&geor=all&date=all&sort=0
群馬県がんばってんな！