プログラマ復権

日経コンピュータ　12/24号　 情報サービス産業協会(JISA）会長　浜口友一氏（NTTデータ取締役相談役）のインタビューで、下記のように語られていた。

(IT産業）84万人のうち、大半はプログラマです。生産性を上げればそれだけ評価が上がるようにすれば､プログラマにとってもやりがいのある楽しい職場になるのではないでしょうか。

現在のプログラマは、生産性を上げると、自分で自分の首を絞めることになります。はい、残業が減り、給与が減ります。生産性が低いほど、給与が増える仕組みです。なんか変です。本来なら、バグが無く、無駄のないアウトプットをどれくらい行ったかで評価されるべきですが。そのプログラムを評価できる人がいません。

日本ではSEが上で、プログラマがしたというイメージがあります｡単純労働というイメージでとらえられている。プログラマは重要な職種なので言葉の使い方を見直して、地位も高めていく必要があります。システムは､最後はプログラマが作るのですから。

プログラミングが単純作業としてしてとらえられています。プログラミングを単純作業とするための前工程が、SEが必死になってドキュメントを書きます。要求仕様ということで、顧客側に今から開発しようとしているものがこんなものですよと相互理解するための資料です。それを、プログラマが単純作業として作業できるように、プログラム仕様書を書きます。結構、膨大な時間と人を掛けています。分業体制で行っているためです。でも、大量生産するわけではないので、セル生産みたいに、一人で完成まで行う方が、効率的ではないのでしょうか。その方法論（アジャイル生産）が可能ではないのでしょうか。

以前、米グーグルを訪問したときに、プログラマの重要性を聞きました。彼らにとって大事なのはソースコードであり、それさえあればいいじゃないかと言うのです。逆に日本では設計書こそ大事であるという話になっている。あとは工場のラインで作るような感覚でソースコードを生産できると思っているのです。プログラマの価値をもっと認めるべきです。

現在のソフト開発の多くの工程はドキュメント作成です。でも、一番正確なドキュメントはプログラムそのものです。機械を作るのなら設計書が必要ですが、ソフトは製品自体が本来、稼働するドキュメントです。プログラム以外のドキュメントは本当に必要なのでしょうか。ほとんど使っていないケースが多いのですが。

どうも、ソフトの生産方式がなんか間違っているのではないかと、最近思うようになりました。業務に近いSE、コンピュータに近いプログラマという分業体制が、本当に正しいのかを議論すべき時に来ているような気がします。プログラミングが出来ないSE、業務が理解できないプログラマというのは、今から、無くなるような気がします。業務を理解し、プログラムが書ける役割の人が出てくるともっと、生産性、品質の高いソフトが出来るような気がします。

xpユーザ会 IT業界若手の集まり

昨日、日本XPユーザーグループ < http://xpjug.s270.xrea.com/ >主催の「アジャイルプロセスSCRUM(仮)」（スピーカ　orinoco エマーソン ミルズさん）に参加。19:30分からの開催であるが、多くの人が集まっていた。Scrumというのは、ソフト開発開発の方法の一つである。従来の開発が、定義された工程、手順を守ることで進められていく　という、大量生産方式のプロセスであるのに対して、scrumでは、ソフトウェアは、同じ工程、手順で作られるようなものではなく､一品作りのプロダクトであると見切る。それ故に、以前の方法などでは､うまくいくはずがない、絶えず、一歩前進してそれを確認して、次の第一歩を決めていく　という戦略がとられるべきだという。Step Wised Improvementと言えばいいのだろうか。ある程度のソフトウェア完成品に対する、プロダクトバックログをチーム全員で共有して、その優先順位を決めて、それを短期間（スプリント）で完成する。チーム全員は割り当てられたタスクの進捗を、壁などに掲示して、自分のステイタスを日々明確に､次に実行することを明言する。そのことで、完成するという達成感を感じながら仕事を進めることになる。その繰り返しで、新たなプロダクトが作られていくということになる。

という、どちらかというと実践的な内容を含む話であった。

私事で言うと、火を噴いた（納期が間に合わないなど）プロジェクトは、この方法で収束してきた。火を噴いている頃は、これも欲しい､あれも欲しいという外野からの声はなくなり（というか、だせなくなっているので）、火消し職人が、やるべき事を選択できる。そして、その職人が、全員を集めて、完成のためにやるべき事を記載して、一応、皆の意見を聞いて、やる順番を決める。そして、そのタスクの期間を見積もり、各人にアサインする。各人は､その作業が終わったら掲示してある白紙に日々のステイタスを書き込むことになる。後どれくらいで終わるかを記載させる。そして、進捗会議などの時間をとるのでなく、その紙を見ながら、やばいところを補強していくことになる。そして、完成だけに集中して、他の管理業務的なことは、例外的にオミットする。社内規則を非常時だと言うことで、ネグルのであります。（非常時は、誰も文句を言わない。ということは、本来は不必要な仕事だったのだ。）

ということで、火消しのやり方と同じである。しかし、根本的に異なるのは、火消しの場合、皆が疲労困憊しているのにたいして、scrumでは、日々の完成の喜びを感じながら、自分で自分の仕事をしているとい感覚になるという、決定的な違いがある｡

日本での文化にあった方法であるという感じはするが、SE、プログラマなど職制がある組織での対応は、それを壊すところから始まるのだろう。

でも会合に行って、予想通り、50歳を過ぎた人は私一人であった。みんなこんな年寄りが、と感心された。（喜んでいいのだろうか？？）

PUKIWKI の立ち上げ

niftyのレンタルサーバのサービスで､PUKIWIKI を立ち上げてみました｡自分の試行するためのノートとして使ってみたいと思います｡また､セキュリティ関連ではJISQ27001を仲間と一緒に､解説を作るために作っております｡知識共有というか､みんなでワイワイガヤガヤとやってみたらどうなるか実験してみたいと思います｡ノウハウが集まるか､どうにもならないか､どうなるんでしょうか｡

暇がある方は覗いてみてて下さい｡情報セキュリティ関連に､興味があれば､コメントや投稿もあればどうぞ｡

http://realdaddy.la.coocan.jp/saaj/index.php

続きを読む "PUKIWKI の立ち上げ"

システムのガバナンスとは

日経コンピュータという雑誌があります。その2006.06.20発行の記事に「東証事件から学ぶこと」というのがあります。みずほ証券からのご発注に関わる、東京証券取引所のシステムの話です。

その当時の、ＣＩＯ（Chief Information Officer)は下記のように言っています。

我々が構築してきたのは市場を支えるマーケットシステムであって単なるマッチングシステムではない。システムに負荷がかかることを承知で相場情報はもとより、売買注文の受付け状況など投資家や証券会社にとって有意義な情報をリアルタイムに近い形で提供してきた。これは投資家が取引をしやすいようにと考えたシステムだ。

これに対して、その後の西室CEOや、外部から招聘された鈴木CIOは一刀両断にこれを切り捨てる。

過剰なサービスはしないけれども頼りになる。こういったことが取引所が目指すべき姿だと思う。

システムができることはシステムで処理する｡人は見ているだけで良いという設計思想になっていた。

注文を受け付けたことを発注者に伝えるメッセージをわざわざ2種類送ったりするなど非常に細かい点まで気を使って作られている。

すなわち、顧客のサービスをかんがえるあまり、システムが巨大化し、処理が遅く、かつ、すぐに新しいサービスが始められない　という経営から見ると、全く使い物にならないシステムになっていると言うことだ。

今までのシステムは顧客の言うとおりに色んな機能を過剰に作ってきた。しかし、それが本当に経営にとって良いことかということが問い直されている。重たい、メンテができないシステムで経営そのものが動脈硬化を起こしているのは散見できる。システムに対するガバナンス、システムによるガバナンスが求められている。

次世代検索 ビルゲイツ

おかげさまでアクセス数が10000を越えました。はじめは、知り合いの閲覧が多かったのですが、ある時期から突然にアクセス数が増えました。どこからアクセスされているかを見ると検索でヒットして､そこからアクセスされているものが多くなっています。ある程度、情報が蓄積され、それが検索ツールで引っかかるようになるとアクセス件数が増えるみたいです。検索フレーズを見ていると、確かにこの検索にかかる情報は書いた、この検索フレーズでは単語自体のヒットはあるが、この組み合わせの情報は記載していないなどが判ります。6月のビルゲイツさんの「次世代検索を語る」で、

ビルゲイツさんの講演風景

http://promotion.msn.co.jp/search/billg/default.htm

続きを読む "次世代検索　ビルゲイツ"

デジタルペン

アエラで元同僚で今は作家の山之口洋さんがデジタルペンを紹介していた。彼は研究所で元々言語関係のソフトを作っていたソフト屋さんである。直木賞候補ともなっている｡彼の弁によると、家にこもって執筆と言うより、立ったりして書くのが自然と言うことで、

http://www.eva.hi-ho.ne.jp/nayamama/yoya/

続きを読む "デジタルペン"

支離滅裂な開発現場

本日は、久しぶりの雨だった。RDBのお勉強で、会場まで行くのに、傘をさしていたにもかかわらず濡れてしまった。コンピュータの世界では設計方式で、データ中心での設計と、オブジェクト中心の設計と分かれている。また、オブジェクト中心設計では、オブジェクトデータベース自体が未成熟のために（というかRDBが普及しているために）、オブジェクトをRDBとして格納するためにインピーダンスミスマッチという言葉で表される、

続きを読む "支離滅裂な開発現場"

ITの監査における難し言葉

今日も無事に帰宅できた。奇跡的なのかもしれない。

本日はシステム監査の研究会。今般、新しくシステム監査管理基準が改定された。その構成は、監査対象となるオブジェクトと、それに対する統制(コントロール）機能がつけられている。平たく言うと、「システム運用」というのが監査対象(オブジェクト)とすると、それについて考えられるリスクを洗い出して、そのリスクを軽減する方策がコントロールと言うことになる。統制(コントロール）という難しい言葉を使うから判らなくなるが、危ないと思ったことに対して、

続きを読む "ITの監査における難し言葉"

エンタープライズアーキテクチャ

エンタープライズアーキテクチャの話を聞く。官公庁では、エンタープライズアーキテクチャばやりである。各省庁とも民間からのCIO（チーフ　インフォーション　オフィッサー）を採用して、その対応をしている。横文字ばかりで何の話しか判らない、が、要は、今までの各省庁のシステム構築で、自分勝手に作ってきたので、バラバラで、無駄ばっかりだったり、

続きを読む "エンタープライズアーキテクチャ"