NTTデータの山下社長が日経コンピュータのインタビューに答えている記事を発見。

おぉ、さすがはNTTデータ。山下社長がやろうとしていることが壮大だ。「3倍速の開発」ということで、地球の自転に合わせて、仕様書とかソースコードといった成果物が世界中を飛び回る(…というよりは、地球上で、起きてる人たちが成果物を常にいじくり回してるって感じか…)ようなシステム開発をやるんだそうな。

会社が24時間眠らないで、24時間連続して開発を続けられる仕組みを作りたい。例えば、日本で8時間設計したら、インドかヨーロッパで8時間製造し、それを南米に持っていって8時間試験をする。日本から見ると、朝来ると、自分が設計したソフトが製造され、一通りの試験が終わって手元に来ている。

確かに、実現できれば、システム開発にかかる期間は短くなりそうだし、コスト削減効果も得られるのかもしれないなぁと思う。

…が、しかし(汗)

もし、NTTデータが受託するであろう規模の案件を、ウォーターフォール風の従来の開発プロセスのまま、「3倍速の開発」に放り込んだら、単なるオフショア開発みたいになるんじゃなかろうか。例えば、設計は日本で何ヶ月かかけてやるんだろうし、その後の製造、試験はインドや中国あたりに投げてやってもらうみたいな。…って、たいして速度は上げられなさそうだ(汗)。

ということは、例えば、「設計して、作って、テストして」というプロセスをかなり小さくして、反復するような開発手法になるんだろうな。それも1日分の仕事を世界で分散するとなると、相当、細かくすることになりそう。でも、ウォーターフォール風の開発プロセスに慣れまくってる組織が新しい開発プロセスになじめるのかな。

あと、山下社長は、さりげなく「日本で設計して…」とおっしゃっているが、日本だけが設計工程を担当するよりも、もし、設計工程を世界中で分散できれば、開発速度は上がるんじゃないだろうか。そして、おそらくは製造、試験工程も同じことが言える(…むしろ、製造、試験の方が適用可能性が高いか…)ような気がするわけで、仮に、ウォーターフォール風の開発プロセスを採用するとしても、もし、世界中で、同じ仕事を同じレベルで分担できるのであれば、まさに「3倍速の開発」が可能なのかもしれない。

例えば、製造、試験工程であれば、日本でソースを書いたら、そのレビューとか試験を中国でやってもらって、さらに、インドで追記し、インド追記分のレビュー、試験をヨーロッパでやって、アメリカでさらにソースを追記し、そのレビューを日本でやるといったプロセスを延々と繰り返す…といった感じだろうか。

それは、この辺で山下社長が語っていることかも。

今でも、製造工程に入っている案件で海外に渡しているものはあります。例えば、日本で書いたソースコードを北京の子会社に送ると、北京の方でソースコードのチェックをわーっとやって、ぱっと返してくれる。こういうサービスは社内ではやっているんですよ。

でも、それはあくまでもソースチェッカーのところだけなので、もうちょっとロジックまで追って、びしっとやってみたいじゃないですか。自動生成したものも含めて、全体のロジックがきちっと確認できるとか、業務知識がからむところまで世界各国でやれるようになったら、すごく効率が上がると思う。

もし、そうなってくると、おそらくは設計書は英語で書かなきゃならないだろうし、ソースコードのコメントも、試験報告書もバグ票も英語ってことになるわけで、実は、日本の開発者が英語ができないこと(…あと、もしかすると、ソースコードを書けないこともか?)が、最大の障壁になりそうだが…根が深そうなので、この辺は簡単には解消しないだろうな。

確かに、「3倍速開発」は、NTTデータなどの日本のSIerにとってはチャレンジではあるんだけど、一方、世界的なパッケージソフト屋さんって、普通に、そういう世界分業体制を敷いてそうな気がするけど、どうなんだろうと、ふと思う。

もとい。

山下社長が興味深いことを語ってた。「ずっと気になっていたのだが、そもそもNTTデータの社員は開発をしているのか」という問いに対して、

非常に危機感を持っていて、現状は何しろ内製率が低い。正直にお話すると全部合わせても3割とか3割5分ぐらい。残りは協力会社の方々に手伝ってもらっている。

とのこと。

私、NTTデータで30%～35%も内製してたことに驚いてしまいました(汗)とはいえ、Intramartなんかのパッケージを作ってる部隊の数字も併せて全社平均してるような気がしないでもない今日この頃。。。

内製化率を増やしたいという考えは前からあった。そもそも大昔、電電公社がDIPSというメインフレームを手掛けていた頃は、みんな自分たちの手でプログラムを作っていた。それこそ私なんかも入社してからずっとデータベース担当だったから、設計の中身にまで携わってアセンブラまで使っていた。

…おっと、どっかで聞いたことある話だなぁ(笑)山下社長のような方が内製化を進めて「内製=コスト高」が目に見えるようになった頃に勇退。で、その後の偉い人が「コスト削減」を旗印に、外注率を上げていって勇退。で、次の人が、また危機感を覚えて内製率を上げていくということの繰り返しにならなきゃいいけど。

人生のどこかでプログラムを作る仕事を経験した方が絶対に面白い。一生やれと言われると少し考えるけれど。20代あるいは30代の前半くらいまでに真水の仕事をどれだけやったか、その後の人生の豊かさにつながります。

えーと、そろそろマジメに真水な(汗)コーディングしますか…ね(笑)

Nagiosの設定をつらつらと書いていたときに、Serviceのチェックはしたいけれど、IPアドレスにPingを打って死活チェックして欲しくないケースに直面した。例えば、ICMPパケットが通らないけど、HTTPは通るようなネットワーク(例えば、イントラネットからルーターを経由して、データセンターに置いてあるWebサーバを監視したいけど、そのルータがご丁寧にICMPパケットを落としてくれる設定になっていていじれない…みたいな)を経由して、Webサーバの死活チェック(とレスポンスタイムのチェック)をやりたいようなケースとか。こんなケースでHostCheckすると、ネットワークが原因でPingのレスポンスが帰ってこないもんだから、DOWNと判断してくれるのでうっとうしいなぁと。

で、Nagiosのドキュメントを読んでみると、max_check_attemptsの項目のところにさりげなく

To bypass the host check, just leave the check_command option blank.

って書いてあったが、blankにしても、「blank」って書いても設定ファイルチェックでエラーが検出されて、さっぱり先にすすまない(汗)ので、仕方ないので「check_dummy」プラグインを使って、とりあえずOKを返すコマンドを自作した。

とりあえず、こんなコマンドを定義。

# ‘return_ok’ command definition

define command{

command_name return_ok

command_line $USER1$/check_dummy 0

}

define host{

use linux-server

host_name HOGE

alias HOGE

address XXX.XXX.XXX.XXX

check_command return_ok

max_check_attempts 1

}

みたいな感じで呼び出してあげると、HostCheckの結果はとりあえずOKになる。こんな対処でいいのか疑問はあるけれど、とりあえず、ま、いっか(汗)

最近、keepalivedなんかを動かすために、強烈なCPUパワーはないけれど、そこそこ動いて、低電力で小型なサーバがないものかと漁っていたら、SUPERMICROがAtomを搭載したマザーボードをリリースしたらしい。

「ページが見つかりませんによると、

サーバ向けをうたうSUPERMICRO製のAtomマザーボード。Atom 230搭載/デュアルチャネルメモリアクセス対応で、ICHには同種製品で初めてICH7Rを採用している。フォームファクタはFlex ATX。

紹介されているのは、Atom N230を搭載した安いモデルだけど、Atom N330(デュアルコア)で、かつ、オンボードでNICが2枚刺さっている上位モデル(「X7SLA-H」)がいい感じだと思われ。でも、NICが蟹さんってのがなぁ…あんまり好きになれないような気がするが、ま、仕方ない。

X7SLA-H

で、SUPERMICROは、このマザーボード用に(NECのハーフサーバ風の)1Uのシャーシもリリースするらしい。シャーシの奥行きが短いので、ラックの前と後ろと前からサーバを刺して、1Uなのにサーバが2台刺さっている状況が作れるのかも。

SC502L-200B

ま、Atomマシンなら、電源が200Wくらいあれば十分そうだし、3.5インチドライブ1個の代わりに、2.5インチドライブを2つ搭載して、RAIDってのも実現できそうだし。用途は慎重に選択する必要があるのかもしれないけれど、サーバを安く構築できそうで、なかなか悪くないような気がする。

gangliaでサーバを監視させようとしたら、gmond.confで監視対象とするmetricを設定するというところまでは、わかったんだけど、CPU関連の「cpu_aidle」と「cpu_idle」ってなんだろうというのがよくわからず。

…似たような名前で、遊んでるマシンを監視対象とした場合、(ぱっと見た感じ)似たような値を出力してくれてるので、どっちかでいいかなぁと思ったりして。

で、Google先生に聞いても教えてくれないので、gangliaのソースを解凍して、./gmond/modules/cpu辺りのmod_cpu.cをなんとなく眺めてみたら、それっぽい配列があった。

static Ganglia_25metric cpu_metric_info[] =
{
{0, "cpu_num",    1200, GANGLIA_VALUE_UNSIGNED_SHORT, "CPUs", "zero", "%hu",  UDP_HEADER_SIZE+8, "Total number of CPUs"},
{0, "cpu_speed",  1200, GANGLIA_VALUE_UNSIGNED_INT,   "MHz",  "zero", "%u",  UDP_HEADER_SIZE+8, "CPU Speed in terms of MHz"},
{0, "cpu_user",     90, GANGLIA_VALUE_FLOAT,          "%",    "both", "%.1f", UDP_HEADER_SIZE+8, "Percentage of CPU utilization that occurred while executing at the user level"},
{0, "cpu_nice",     90, GANGLIA_VALUE_FLOAT,          "%",    "both", "%.1f", UDP_HEADER_SIZE+8, "Percentage of CPU utilization that occurred while executing at the user level with nice priority"},
{0, "cpu_system",   90, GANGLIA_VALUE_FLOAT,          "%",    "both", "%.1f", UDP_HEADER_SIZE+8, "Percentage of CPU utilization that occurred while executing at the system level"},
{0, "cpu_idle",     90, GANGLIA_VALUE_FLOAT,          "%",    "both", "%.1f", UDP_HEADER_SIZE+8, "Percentage of time that the CPU or CPUs were idle and the system did not have an outstanding disk I/O request"},
{0, "cpu_aidle",  3800, GANGLIA_VALUE_FLOAT,          "%",    "both", "%.1f", UDP_HEADER_SIZE+8, "Percent of time since boot idle CPU"},
{0, "cpu_wio",      90, GANGLIA_VALUE_FLOAT,          "%",    "both", "%.1f", UDP_HEADER_SIZE+8, "Percentage of time that the CPU or CPUs were idle during which the system had an outstanding disk I/O request"},
{0, "cpu_intr",     90, GANGLIA_VALUE_FLOAT,          "%",    "both", "%.1f", UDP_HEADER_SIZE+8, "cpu_intr"},
{0, "cpu_sintr",    90, GANGLIA_VALUE_FLOAT,          "%",    "both", "%.1f", UDP_HEADER_SIZE+8, "cpu_sintr"},
{0, NULL}
};

これによると、

cpu_idle: Percentage of time that the CPU or CPUs were idle and the system did not have an outstanding disk I/O request

cpu_aidle: Percent of time since boot idle CPU

ってことのようだ。

後者の「cpu_aidle」がbootしてからの経過時間に対して、CPUがなんにもしてなかった時間の割合、前者の

「cpu_idle」はCPUがなんにもしてなかった時間-(ディスクIOを待っていた時間)の割合ってことだろうか。

…ただ、グラフを眺める限りでは、「cpu_idle」は、bootからの経過時間で計算って感じではなさそうなので、なにか単位時間に対して、値を計算しているような気がする。

「cpu_aidle」の値を、長い期間、監視しつづければ、CPUが使われることによって値が低下してくことになるだろうから、サーバリソースの追加投入時期の検討なんかに使えそうな気がする。

一方、いつ、CPUにどれくらいの負荷がかかったかは「cpu_user」とか「cpu_system」で取得できそうな気がするので、「cpu_idle」はCPU負荷の監視項目としては要らない気がするなぁ…。うーむ(汗)とはいえ、CPU空き率(?)を見ようと思ったら、「cpu_user」と「cpu_system」などを足し算して、100から引くみたいなことをせざるを得ないので、それはそれであってもいいかなという気もしてみたり。

…とはいえ、古めのPC(NorthwoodなCeleron機…涙)にCentOSを入れて、Gangliaでグラフを書かせてみたら、グラフを書く負荷で、そのマシンの負荷が閾値を超えたりする始末なので、とりあえず何でもかんでもグラフを書きやがれってのも、多少、危ないかなという気もするし…と。